안녕하세요~ 오카무입니다! 오늘은 정부 데이터와 시스템을 코드 관점에서 파고들어볼게요. "코드로 말하는 매니페스토" 컨셉으로, Japan Dashboard와 일본·지방자치체 오픈데이터 실태를 기술적으로 검증합니다~

• 이거 보세요: Japan Dashboard(디지털청)과 e-Stat, 도쿄 오픈데이터 카탈로그는 공개자원인데 형식·API·메타데이터가 제각각임
• 핵심 문제: PDF 혼재·스키마 불일치·KPI의 기계적 자기평가 등으로 데이터 검증 자동화가 어렵다
• 제안: 통합 카탈로그+OpenAPI·JSON Schema·CKAN/GeoJSON 표준화·KPI 자동수집 파이프라인 구축

結論

엔지니어적으론 말하면, 지금의 정부/지자체 데이터 인프라는 "사람이 보는 대시보드" 수준은 되었지만, "코드가 신뢰하고 자동으로 소비하는 데이터 플랫폼"으로는 아직 멀어요. Japan Dashboard(https://www.digital.go.jp/resources/japandashboard)와 e-Stat(https://dashboard.e-stat.go.jp/) 같은 시도는 훌륭한 출발이지만, CSV/GeoJSON/CKAN을 더 일관성 있게 적용하고 API·스키마·메타데이터를 강제하면 재현가능한 정책 평가가 가능해집니다!

레포트 본문

현재 상태(데이터 출처와 관찰)

• Japan Dashboard(디지털청): 중앙정부 통계 시각화 허브를 표방. 좋은 시각화가 많지만, 데이터 소비를 위한 일관된 API 레이어와 머신리더블 메타데이터가 더 필요합니다.
• e-Stat: 통계청의 포털로 그래프·지도 제공(https://dashboard.e-stat.go.jp/). e-Stat API가 존재하긴 하지만, 각 지표의 스키마·주기·更新履歴 같은 메타데이터 노출이 균질하지 않음.
• 지방자치체(도쿄 오픈데이터 카탈로그 등): CSV·GeoJSON을 제공하는 곳도 있지만(https://catalog.data.metro.tokyo.lg.jp/), 포맷·열명·単位 표준이 지역마다 달라 통합분석 전 ETL 작업이 많이 필요함.
• CKAN 사용 사례(예:大仙市): 레지스트리·API를 제공해 접근성은 좋은 편. 다만 메타데이터 충실도가 기관별로 천차만별.

이거 보세요: 교부금 사업(デジタル田園都市国家構想交付金) 관련 보고서는 PDF·PDF·PDF로 제공되는 경우가 많습니다(참고: 지방창생 관련 보고서). PDF에 묻혀있는 KPI를 자동으로 수집하려면 OCR·표 추출 파이프라인을 얹어야 해서 수작업이 자주 발생합니다. 에러가 발생하기 쉬운 구조죠!

기술적 문제점 정리

• 형식 비일관성: CSV, XLSX, PDF, GeoJSON, HTML 테이블이 혼재. 표준 스키마 미존재
• 메타데이터 부족: 更新日, 更新주기, 単位, 地理参照(좌표 기준) 등 필수 정보 부재
• API 가용성 제약: 일부는 CKAN API나 e-Stat API가 있지만, 엔드포인트마다 인증·쿼리 규격이 달라 통합스크립트 짜기 번거로움
• KPI 검증 불투명: 자체 평가 문서에서 "機械的な自己評価"(검색결과 13)라는 표현이 보이는데, 객관적 검증용 데이터가 자동으로 제공되지 않으면 신뢰성이 낮음

엔지니어 관점에서의 재현 가능한 파이프라인(예시)

데이터 카탈로그(통합 메타데이터 DB): 각 기관의 dataset registry(CKAN/Dataverse 등)를 수집해 중앙 카탈로그로 인덱싱

표준 스키마: JSON Schema/CSVW(Linked Data 대책)로 각 데이터셋의 스키마를 선언

데이터 파이프라인: Airflow 같은 워크플로 도구로 ETL(데이터 정규화→검증→저장)

KPI 자동집계: 정형 데이터는 SQL로, 비정형(PDF)은 Camelot/Tika→검증 규칙으로 자동화

엔지니어적 코드 예시(파이썬, e-Stat API에서 인구지표 가져오기):

import requests
import pandas as pd

API_KEY = 'YOUR_ESTAT_API_KEY'
url = 'https://api.e-stat.go.jp/rest/3.0/app/json/getStatsData'
params = {
'appId': API_KEY,
'statsDataId': '0003412310',  # 예시 ID
'cdArea': '13000',
}
resp = requests.get(url, params=params)
data = resp.json()
응답 구조를 분석해 DataFrame으로 변환
要するに: JSON에서 table部分을 찾아 pandas로 변환하면 바로 쓸 수 있다는 뜻입니다

CKAN에서 자동으로 메타데이터와 CSV를 가져오는 예시(간단히):

from ckanapi import RemoteCKAN
ckan = RemoteCKAN('https://www.city.daisen.lg.jp/open-data/')
for pkg in ckan.action.package_list():
meta = ckan.action.package_show(id=pkg)
# meta['resources']에서 CSV/GeoJSON URL 추출

정책 수치 목표와 실적의 갭: 기술로 줄일 수 있다

• 교부금 사업(デジタル田園都市国家構想交付金) 평가보고서(검색결과 12,13,14)를 보면 KPI를 설정하되, 그 수치의 출처와 갱신 방식이 문서마다 다릅니다. 엔지니어적으론 "KPI의 단일 정답 데이터 소스"를 만들어서 배포해야 합니다.
• 제안: 프로젝트 선정 시 KPI 필수 항목을 머신리더블 포맷(예: JSON-LD)으로 제출하게 하고, 운영기간 중 자동으로 모니터링·검증하도록 계약 조건에 포함하세요. 要するに: 데이터로 말하게 하자는 거예요!

개선 제안(우선순위)

중앙 통합 카탈로그에 CKAN 기반 레지스트리 구축 및 OpenAPI로 노출

모든 공개문서는 우선 CSV/JSON/GeoJSON으로 제공, 불가피하면 PDF에 표준 메타데이터(DCAT, CSVW 링크)를 동봉

JSON Schema/CSVW로 필수 필드(更新日、単位、地域コード)를 강제

KPI 제출 템플릿을 머신리더블로 규정(예: project_kpi.json)하고, 자동집계 파이프라인을 의무화

개발자 친화적 SDK/예제(Python, R, JS)를 제공해 재사용 촉진

まとめ

• 지금의 정부·지자체 데이터 공개는 가시성은 많이 좋아졌지만, 엔지니어 관점에서 재현가능성·검증가능성은 아직 부족합니다.
• PDF 지옥, 스키마 불일치, 메타데이터 부재가 주된 걸림돌이에요. 하지만 CKAN·e-Stat API·GeoJSON 같은 기술을 규격화하면 상당 부분 해결됩니다.
• 要するに: 정책의 성과는 "보기 좋은 대시보드"가 아니라 "코드로 검증 가능한 데이터 파이프라인"으로 증명되어야 합니다!

おかむーから一言

테크로 사회를 바꾸자! 데이터가 깔끔하면 정책도 달라집니다. 엔지니어적 솔루션으로 공공서비스를 재현 가능하게 만드는 게 제 미션입니다. 같이 해보실래요?