코드로 말하는 매니페스토 — 지방정부 오픈데이터와 시스템을 엔지니어 시선으로 해부합니다

안녕하세요~ 오카무입니다! 오늘은 정부·지자체가 공개하는 데이터와 시스템을 코드와 엔지니어링 관점에서 뜯어보는 글이에요. "코드로 말하는 매니페스토"라는 콘셉트로, 정책 목표가 데이터로 어떻게 드러나고 있는지, 기술적으로 어디가 문제인지, 실무적으로 무엇을 고치면 좋은지까지 분석합니다.

• 이 글 3줄 요약

- 공개 데이터의 형식(특히 PDF vs CSV)과 API 유무가 재사용성을 좌우한다는 점은 핵심입니다.

- 많은 지방정부는 데이터 카탈로그(예: Tokyo Open Data Catalog)의 형태로 배포하지만, 스키마·버전·업데이트 정보가 빈약합니다.

- 개선안은 표준화된 스키마(CSVW/JSON‑Stat), 중앙 API 게이트웨이, 자동화된 ETL 파이프라인입니다.

결론

정책은 수치로 말하는 시대입니다. 그런데 그 수치가 PDF에 갇혀 있거나 포맷이 제멋대로면 실무에서 활용 못 합니다. 엔지니어적으론 "API 한 줄과 정량적 스키마"가 있으면 해결되는 문제가 많아요. 중앙화된 메타데이터(DCAT), 기계판독 가능한 형식(CSV/JSON/JSON‑Stat), 그리고 안정적인 API가 있으면 데이터 기반 정책 검증이 훨씬 쉬워집니다.

레포트 본문

현재 상태: 뭐가 공개되어 있고, 어떤 문제가 있나

これ見てくださいよ：도쿄 메트로폴리탄 오픈데이터 카탈로그(https://catalog.data.metro.tokyo.lg.jp/dataset)나 GovTech東京의 데이터 활용 사례(https://www.govtechtokyo.or.jp/services/data-utilization/)를 보면 데이터 공개는 활성화되어 있어요. 다만 현실은 다음과 같습니다.

• 형식 다양성 문제

- CSV로 잘 제공되는 경우도 있지만, 여전히 PDF에 표를 찍어서 올리는 케이스가 많습니다(예: 지자체 보고서). PDF에 묶여 있으면 파싱·재현산출(재현성)이 어려워요. 要するに, 기계가 읽을 수 없다는 뜻입니다.

- 문자 인코딩(Shift‑JIS vs UTF‑8), 구분자(コンマ vs タブ), 날짜 포맷(YYYY/MM/DD vs YYYY‑MM‑DD)도 제각각이라 전처리 비용이 큽니다。

• 메타데이터와 스키마 부재

- 데이터셋에 업데이트 주기, 정확한 스키마(컬럼 명세・데이터 타입), 버전 정보가 없는 경우가 많아요. 이러면 어느 시점의 수치인지 불분명해지고, 정책성과를 시간축으로 비교하기 어렵습니다。

• API 부재 또는 제한적인 API

- 정부 통계 포털(예: e-Stat)은 API를 제공하지만、多くの自治体は REST API를 전면적으로 제공하지 않음。結果として 스크래핑이나 수동 다운로드에 의존するケースが多いです。

• 조직간 데이터 파이프라인 부재

- 부서별로 서로 다른 포맷・タイミングでデータを提供するため、都道府県レベルでの集約や全国横断分析が難しいです。

사례로 보는 문제: 재난·방재 데이터 (Tokyo 예시)

도쿄 카탈로그에선 방재 관련 설문·조사 데이터(예: 防災意識調査)가 CSV로 공개되어 있기도 합니다(https://catalog.data.metro.tokyo.lg.jp/dataset)。하지만 다음 문제를 관찰했어요。

• 설문 문항이 버전마다 바뀌는데 메타데이터에 문항 맵핑 정보가 없음 → 시계열 비교 불가
• 지리정보(행정구역 코드)가 텍스트로만 제공되어 표준 코드(JIS X 0401 등)와 매칭 작업 필요
• 공개 빈도가 불규칙(연1回、季節ごとなど) → 정책 평가 지연

要するに、정책 목표(예: 주민의 방재 인식 5% 향상)가 있다고 해도, 그 성과를 자동으로 집계하고 검증할 수 있는 구조가 되어 있지 않아요。

기술적 검증: 파일→테이블로 자동화하는 방법(예시 코드)

エンジニア的に言うと、다음 도구·기법으로 상당부분 자동화됩니다.

• PDF 테이블 추출: tabula-py / Camelot
• CSV 스키마 검증: pandera / jsonschema
• API 제공: FastAPI + OpenAPI 스펙
• 카탈로그 메타데이터: DCAT / Data Catalog와 CKAN

아래는 예시 Python 코드(간단한 CSV fetch + 검증 흐름)

# placeholder 예시: Tokyo Open Data의 CSV를 가져와서 스키마 검증
import requests
import pandas as pd
from pandera import DataFrameSchema, Column, Check

url = 'https://some.tokyo.opendata/example.csv'  # 실제 URL로 교체
r = requests.get(url)
open('tmp.csv','wb').write(r.content)

df = pd.read_csv('tmp.csv', encoding='utf-8')

schema = DataFrameSchema({
'pref_code': Column(int, Check(lambda s: s>0)),
'year': Column(int),
'awareness_pct': Column(float, Check(lambda x: (x>=0)&(x<=100)))
})

validated = schema.validate(df)
print('validated rows:', len(validated))

PDF → CSV 추출은 추가로 OCR보정/레イアウト補正이 필요하므로 Tabula 등으로 배치 처리 파이프라인을 돌리는 게 현실적입니다。

정책 수치 목표 vs 실적의 갭 분석 방법

정책 문서에 명시된 목표(예: 子育て支援満足度をX年でY→Zへ)를 데이터로 검증하려면 다음이 필요합니다。

기준 데이터셋(국가/지자체별 동일 스키마) 확보

시계열 정렬 및 결측치 처리

동일 문항·지표의 문항 맵핑(버전업 시 재코딩 테이블 필요)

신뢰구간을 포함한 통계적 검증(유의미한 변화인지 확인)

이 절차가 자동화되어 있지 않으면 매번 사람이 손으로 엑셀을 뒤적여야 합니다. 엔지니어적으론 이걸 ETL 파이프라인으로 만들어 배포·검증하면 정책 피드백 사이클이 빨라집니다。

개선 제안 (구체적이고 실행 가능한 것)

• 표준 스키마 도입: CSVW 또는 JSON‑Stat을 공식 표준으로 채택

- 컬럼 타입, 의미(예: codeList), 단위(unit), 업데이트 주기 필드 등 포함

• 중앙 API 게이트웨이 구축

- 모든 공개 데이터에 대해 RESTful API 엔드포인트를 제공하고 OpenAPI 명세를 자동 생성

• 메타데이터 카탈로그(DCAT) 운영과 버전관리

- dataset마다 last_modified, version, provenance 링크를 명시

• 자동화된 ETL + 배치 검증

- PDF 업로드 → tabula 추출 → schema validate → 데이터베이스 적재 → API로 배포

• 가벼운 데이터 포맷 가이드 공개

- UTF‑8 권장, ISO 날짜 포맷, 행정구역코드利用を必須化

기술적으로 말하면, 위 작업은 작은팀(DevOps+Data Engineer 2~3명)과 오픈소스 툴로도 충분히 구현 가능합니다. 클라우드에 데이터 릴리즈 파이프라인을 올리고, GitHub와 연동해 공개 이력을 관리하는 방식이 현실적이에요。

정리

• 현재: 공개 의지는 있으나 형식·메타데이터·API 관점에서 미비한 곳이 많다
• 문제 핵심: PDF에 갇힌 데이터, 스키마·버전 부재, API 부족
• 해결책: 표준 스키마(CSVW/JSON‑Stat), 중앙 API, ETL 자동화, 메타데이터 카탈로그

오카무의 한마디

테크로 사회를 바꾸겠다는 건 거대한 이야기가 아니에요. 데이터가 읽기 쉬운 형태로 공개되고, 그걸 바로 가져다 쓸 수 있게 API 한 줄로 연결되는 게 핵심입니다. 작은 자동화부터 시작해보면 정책의 실효성을 바로 측정할 수 있어요. 열정과 코드로 정책을 말하게 해봅시다!