안녕하세요~ 오카무입니다! 오늘은 공공데이터를 엔지니어 시선으로 까발려 보는 글이에요. 코드로 말하는 매니페스토, 시작합니다!

• 이 글 3줄 요약

- Tokyo 오픈데이터 포털은 CSV·API 노출이 늘었지만 기계가 읽기 쉬운 표준·메타데이터는 여전히 들쭉날쭉임

- PDF에 묻혀 있는 지표나 KPI는 자동 분석이 안 돼 정책 평가에 한계가 있음

- 제안: 표준 스키마·API 우선 공개·定期更新パイプライン으로 실시간 검증 루프 만들자

結論

Tokyo 포털(https://portal.data.metro.tokyo.lg.jp/, https://catalog.data.metro.tokyo.lg.jp/dataset)을 보면 'CSV 공개'가 많아졌고 API 태그도 보이지만, 데이터 품질(스키마 불일치·누락 메타데이터)과 PDF 의존이 여전해요. 엔지니어적 관점에서는 "데이터가 열릴 때 정책도 열린다"가 핵심입니다. 要するに, 기계가 읽을 수 있는 일관된 인터페이스(API + JSON Schema)가 정책 검증의 출발점이라는 이야기입니다.

레포트 본문

1) 현황 스케치 — 무엇이 공개돼 있나

これ見てくださいよ。Tokyo 오픈데이터 카탈로그에서 조직·데이터 생성일·업데이트일이 붙은 CSV 항목들이 보입니다(예: 総務局, 江東区의 公共施設一覧 등). 몇몇 데이터는 "APIあり" 태그가 붙어 있어 실사용 가능성이 높아요. 다만 항목별로 라이선스·フィールド説明이 일관되지 않음.

• 장점

- CSV·API로 전환된 항목 증가 → 기계 가공성 향상

- 업데이트 타임스탬프 제공 → 신뢰도 검증 가능

• 단점

- PDF에 묻힌 KPI 문서(デジタル田園都市国家構想交付金 관련 보고서 등)는 자동 수집 불가(참조: 総務省ガイドラインや自治体実績PDF)

- 스키마 표준(DCAT-APやJSON Schema) 부재 → ETL 파이프라인에서 매번 스키마 매칭 로직 필요

2) 기술적 문제점(좀 디테일하게)

• 메타데이터 미흡: カラム説明 없음 → 같은 컬럼명이지만 의미가 다른 경우가 잦음
• 日付フォーマット 불일치: 'YYYY/MM/DD' vs 'YYYY-MM-DD' vs 'YYYY年M月D日' 혼재
• 地理情報의 표준화 부족: GeoJSON vs WKT vs 緯度経度別カラム 혼용
• PDF에 담긴 KPI: 交付金의 実績보고서(参考: デジタル田園都市国家構想交付金関連資料)처럼 수치가 PDF로만 공개되면 시계열 자동분석 불가

エンジニア的に言うと, 이건 API 하나로 해결되는 문제에요. 要するに, 표준화된 API와 스키마가 있으면 데이터 수집→검증→시각화까지 자동으로 처리할 수 있다는 뜻입니다.

3) 코드 예시 — CSV·API를 받아서 검증하는 간단한 파이프라인

# requirements: requests pandas jsonschema
import requests, pandas as pd
from jsonschema import validate

url = 'https://catalog.data.metro.tokyo.lg.jp/dataset/xxxx/resource/yyy.csv'
df = pd.read_csv(url)
간단한 정규화 예: 날짜 통일
df['date'] = pd.to_datetime(df['date'], errors='coerce').dt.strftime('%Y-%m-%d')
스키마 검증 예시
schema = {
'type': 'object', 'properties': {
'id': {'type':'integer'}, 'name': {'type':'string'}, 'lat': {'type':'number'}, 'lon': {'type':'number'}
}, 'required': ['id','name']
}
for row in df.to_dict(orient='records'):
try:
validate(instance=row, schema=schema)
except Exception as e:
print('schema error', e)

이 코드는 기본적인 정규화·검증 루틴이에요. 실제 운영에서는 스키마 레지스트리와 자동 스키마 매핑이 필요합니다.

4) 정책 평가: KPI와 실적의 갭을 코드로 검증하기

検索結果에 보이는 デジタル田園都市国家構想交付金のKPI報告や自治体実績(都道府県PDF)같은 문서를 자동화하려면:

• 원칙: KPI는 기계판독 가능한 표(CSV/JSON)로 공개
• 제안 툴체인: OCR->테이블 추출(TABULA/ocrmypdf) -> 데이터 정제(pandas) -> 스키마 검증(jsonschema) -> 대시보드(마이크로서비스)

예를 들어,交付金의 목표액과実績の年次変化는 CSV로 제공되면 자동으로 정책달성률을 계산할 수 있어요. 지금은 PDF가 원본이면 사람 손으로만 집계해야 해서 투명성·신속성이 떨어짐!

5) 개선 제안 (구체적이고 실용적으로)

• 모든 KPI·予算·実績은 CSV+JSON Schema로 우선 공개
• DCAT-AP 스타일의 메타데이터 카탈로그 적용: 각 리소스에 license, updateFrequency, contactPoint를 표준 필드로
• GeoはGeoJSON推奨、属性はUTF-8、日時はISO8601
• API設計: RESTful + Pagination + OpenAPI 명세서 자동 노출
• CI/CD 기반 데이터 파이프라인: 데이터 커밋→自動検証→ステージング→公開

技術スタック例: GitHub Actions(데이터 테스트) + nginx 캐시 + PostgREST(표준 API) + Grafana

まとめ

• Tokyo 오픈데이터는 양적 확장은 진행 중이지만 품질·표준화가 병행되어야 실효성 생김
• PDF에 묻혀 있는 KPI는 자동 검증을 막아 정책 평가를 느리게 함
• 엔지니어적 해법: JSON Schema·OpenAPI·DCAT-AP 적용, 자동화 파이프라인 구축, 그리고 실시간 대시보드

おかむーから一言

테크로 사회를 업그레이드합시다! 데이터가 열린 곳에 시민의 결정도 열린다는 걸 잊지 마세요. 저는 코드로 정치 검증하는 걸 멈추지 않겠습니다!