코드로 말하는 매니페스토: 일본 정부 오픈데이터를 엔지니어링 관점에서 해부합니다

안녕하세요~ 오카무(おかむー)입니다! 오늘은 정책을 코드와 데이터로 검증하는 '코드로 말하는 매니페스토' 시리즈예요~ 엔지니어적 관점으로 일본 정부·지자체 공개 데이터의 현재와 개선안을 파헤쳐봅시다!

• e-Stat·디지털청 같은 포털은 있지만, 데이터 품질·포맷 일관성에서 과제가 많음
• CSV/Shift-JIS, PDF 산재로 자동화 파이프라인 구축에 추가 비용 발생
• 표준화(UTF-8, OpenAPI, DCAT), 데이터 계약·검증 파이프라인으로 해결 가능

結論

일본 정부는 방대한 공개 데이터를 이미 제공하고 있다(e-Stat, Japan Dashboard, 法人番号 등). 하지만 엔지니어 시각에선 "기계가 신뢰해서 바로 쓰기"에는 부족해요. 인코딩·스키마·메타데이터·API 지원을 표준화하면 정책 검증과 혁신 서비스가 훨씬 쉬워집니다.

데이터 소스와 현재 상태

これ見てくださいよ — 대표적 공개소스들:

• e-Stat(https://www.e-stat.go.jp/) : 포털·대시보드 제공, API도 있지만 데이터 품질이 혼재
• Digital Agency / Japan Dashboard(https://www.digital.go.jp/) : 시각화 주도
• 国税庁 法人番号 다운로드(https://www.houjin-bangou.nta.go.jp/download/) : CSV(Shift-JIS/Unicode), XML 제공
• 厚生労働省介護 서비스 오픈데이터(https://www.mhlw.go.jp/stf/kaigo-kouhyou_opendata.html) : 큰 CSV 묶음
• 지방·부처별 개별 CSV/CSV 링크 (예: env.go.jp, jinji.go.jp)

문제는 파일 포맷과 인코딩, 메타데이터의 불일치입니다. 어떤 건 UTF-8, 어떤 건 Shift-JIS/CP932로 제공되어서 파싱 단계에서 골치 아파요. 정책 검증을 위해서는 동일한 스키마와 안정적인 식별자(法人番号, 사업ID 등)가 필수입니다.

기술적 분석

• 인코딩 문제: 法人番号은 Shift-JIS와 Unicode 둘 다 제공한다고 명시되어 있는데, 실제로 파이프라인에선 encoding 오류로 중단되는 경우가 많아요. 엔지니어적으로 말하면, 자동화 단계에서 인코딩 감지/변환 로직을 넣어야 하는데 이게 반복 작업이라 비용이 큽니다.
• 포맷 다양성: CSV, XML, 때로는 PDF. PDF에 정책 수치가 들어가면 사실상 기계가 읽기 힘들죠. 要するに, 데이터가 기계 친화적이지 않다는 뜻입니다.
• API 부족/문서 부족: e-Stat 같은 API가 있어도, 레ート 리밋·스키마 버전 관리·메타데이터 표준(DCAT 등)이 약하면 재사용성이 떨어집니다.
• KPI와 실적 연결 어려움: 예를 들어 디지털田園都市交付金 관련 KPI는 문서화돼 있지만, 실적 측정 데이터가 프로젝트 단위로 정형화되어 있지 않으면 목표 대비 실적 계산이 번거롭습니다.

코드 예시 — 실제로 CSV 가져와 처리하기

다음은 国税庁의 CSV(Shift-JIS)를 안전하게 가져와 pandas로 읽는 예시입니다.

import requests
import io
import pandas as pd

url = 'https://www.houjin-bangou.nta.go.jp/download/zenken/20230401/zenken.csv'
resp = requests.get(url)
resp.encoding = 'cp932'  # Shift-JIS 계열
buf = io.StringIO(resp.text)
df = pd.read_csv(buf)
print(df.columns)

스키마 검증은 pandera나 great_expectations를 쓰면 좋습니다. 예:

import pandera as pa

schema = pa.DataFrameSchema({
'法人番号': pa.Column(pa.String),
'商号又は名称': pa.Column(pa.String),
'都道府県': pa.Column(pa.String)
})
schema.validate(df)

要するに, 데이터 수집 → 인코딩 정규화 → 스키마 검증 → 저장(테이블) 흐름을 자동화해야 해요.

정책 수치(목표 vs 실적) 검증 방법

• 정책별로 고유 project_id를 부여
• KPI를 시계열 데이터로 수집(월별/분기별 측정값)
• 목표(target) 테이블과 실적(actual) 테이블을 조인해 달성률 계산

SQL 예시:

SELECT p.project_id, p.kpi_name, p.kpi_target, a.period, a.kpi_value,
(a.kpi_value / p.kpi_target) as achievement_rate
FROM projects p
LEFT JOIN kpi_actuals a ON p.project_id = a.project_id

개선 제안(우선 순위)

모든 공개데이터 기본은 UTF-8로 제공

모든 데이터셋에 DCAT/JSON-LD 스타일의 메타데이터 제공(更新日、スキーマ、ライセンス、バージョン)

RESTful API + OpenAPI 스펙 공개(스키마·例·レートリミット 표기)

고정 식별자 도입(法人番号 등) 및 표준화된 지오코딩

PDF안의 수치·표는 구조화 데이터로 병행 제공

데이터 계약(consumer-provider contract) 도입 → 스키마 변경 시 알림

운영 관점의 제안(엔지니ア視点)

• ETL 파이프라인: Airflow/Prefect + dbt 조합으로 버전 관리
• 데이터 검증: Great Expectations로 배포 전 계약 테스트
• 모니터링: 수집 실패·스키마 변화 탐지 알림
• CI: 데이터 파이프라인도 코드처럼 PR→테스트→배포 흐름

まとめ

요약하면, 일본 정부는 이미 풍부한 데이터를 가지고 있다. 하지만 엔지니어가 바로 쓰기엔 인코딩·포맷·메타데이터·API 설계에서 개선 여지가 큽니다. 간단한 표준(UTF-8, OpenAPI, DCAT, 고유ID)과 데이터 파이프라인의 자동 검증을 도입하면 정책의 실효성 검증과 민간의 혁신 서비스가 훨씬 가속됩니다.

おかむーから一言

테크로 사회를 바꾸는 건 가능해요! 데이터를 믿고 코드로 검증하면 정책도 훨씬 투명해집니다. 같이 만들어봅시다—오카무였습니다!