• 데이터 접근성은 좋아졌지만 머신리드성은 아직 개선 여지 많음
• API 존재는 긍정적이나 스키마·メタ데이터 표준화가 필요
• PDF→CSV 문제, 인증·속도 제한, 시계열 공개가 핵심 개선 포인트

結論

서울·도쿄 레벨의 GovTech 시도는 확실히 진행 중이고 API 카탈로그(e-Gov, Tokyo Open Data 등)가 마련되어 있다. 다만 엔지니어 관점에서 보면 데이터의 머신리드성(포맷·스키마·メタ데ータ)이 일관되지 않아 재현 가능한 분석을 바로 하기 어렵다. 要するに、API는 있지만 '개발자가 바로 붙여서 쓸 수 있는' 품질로 정착되려면 추가 작업이 필요하다.

レポート本文

どうも~ 오카무-입니다! 오늘은 정부·지자체 데이터의 기술적 품질을 코드를 중심으로 훑어보는 시간이에요. 엔지니어적으로 말하면, 데이터 신뢰도는 포맷·스키마·운영(버전·레ート 리밋) 세 축에서 평가해야 합니다.

1) 현황 스냅샷

• 참고 리소스: e-Gov API 카탈로그(https://www.e-gov.go.jp/digital-government/api)、東京都オープンデータカタログ(https://portal.data.metro.tokyo.lg.jp/opendata-api/)、GovTech東京 사례 노트
• 긍정적 요소: 중앙 카탈로그와 API 제공으로 접근성은 대폭 향상됨. 예: Tokyo Open Data의 PublicFacility API로 휠체어 화장실 목록을 JSON으로 받음 가능
• 문제점: 많은 정책·보고서는 PDF로 배포돼 있고, CSV/JSON으로의 병렬 제공이 없는 경우가 많음

これ見てくださいよ：정책 보고서가 PDF로만 공개되어 있으면 데이터 엔지니어는 자동화 파이프라인을 못만듭니다. PDF→CSV 변환은 가능하지만 에러와 수동 보정이 산재해요。

2) 기술적 분석

• 포맷: JSON/CSV/GeoJSON이 이상적. PDF는 아카이빙 용도로 남겨두고 원천 데이터는 구조화된 포맷으로 제공해야 합니다. 要するに、機械が読めるデータを先に出すべきということです。
• スキーマ・メタデータ: 각 API에 JSON Schema 또는 OpenAPI 명세가 필요. 현재 카탈로그 링크만 있고 세부 스키마가 부족한 경우가多い
• 運用: 버전 관리(major/minor), 레ート 제한, 인증 방식(API Key/OAuth)、SLA 정보가 문서화되어いないことが多い

サンプルコード: Tokyo Open Data에서 JSON 받아와서 처리하는 간단한 예（Python）

import requests

import pandas as pd

url = "https://portal.data.metro.tokyo.lg.jp/opendata-api/PublicFacility"

params = {"format": "json"}

resp = requests.get(url, params=params, timeout=10)

resp.raise_for_status()

data = resp.json()

데이터 구조를 확인한 뒤 필요한 필드로 DataFrame 구성

records = [ {"name": r.get("facilityName"), "lat": r.get("latitude"), "lon": r.get("longitude")} for r in data.get("items", []) ]

df = pd.DataFrame(records)

print(df.head())

이 코드 쓰는 사람이라면 알겠지만, 핵심은 "items" 필드 등 리스폰스 구조가 문서와 일치하는지 확인하는 단계가 항상 필요하다는 점입니다!

3) 정책 목표 vs 実績のギャップ（例示的アプローチ）

정책 문서에 목표(예: 공공데이터 80% 기계판독 가능 형식 공개)와 실측(실제로 몇 퍼센트가 CSV/JSON인지)은 별도 산출이 필요합니다. 접근법:

• 카탈로그에서 엔드포인트 목록 수집
• 각 엔드포인트 응답 포맷 파싱(HTML/PDF/JSON/CSV)
• 전체 중 구조화 포맷 비율 계산

샘플 파이프라인: 크롤러 → 형식 판별(HTTP Content-Type + 파일 시그니처) → 변환(필요 시 tabula/camelot로 PDF→CSV) → 카운팅

4) 개선 제안（엔지니어 관점）

중앙 API 게이트웨이에서 OpenAPI(또는 JSON Schema) 명세 배포

모든 통계・목록성 데이터는 CSV/JSON(시계열은 NDJSON)으로 우선 공개

메타데이터 표준(カラム説明、更新頻度、ソース、ライセンス) 적용

API 품질지표 공개(レスポンス時間、エラー率、バージョン)とSLA

サンプルコード＆SDK 제공(Python/R/JS)で障壁を下げる

간단한 OpenAPI 스니펫(예시):

openapi: "3.0.0"

info:

title: PublicFacility API

version: "1.0.0"

paths:

/PublicFacility:

get:

responses:

'200':

description: OK

content:

application/json:

schema:

$ref: '#/components/schemas/PublicFacilityList'

要するに、これでクライアントライブラリ自動生成が楽になるということです。

5) 活用可能性とエコシステム

• 민간 앱/서비스와의 연계: 표준 스키마 + サンプルデータがあれば 민간 개발자가 빠르게 가치 있는 서비스를 만든다
• 데이터 유틸리티: 시계열 공개로 추세 분석, 머신러닝 모델 학습, 정책評価 자동화 가능

まとめ

• API 제공은 큰 진전이지만 '바로 쓸 수 있는' 품질로 가려면 스キーマ・メタ데ータ・運用情報の整備が必要
• PDF 단독 배포는 자동화의 적。CSV/JSON 우선 공개하자
• OpenAPI/JSON Schema, サンプルコード、SDK 제공、SLA 공개가 우선순위

おかむーから一言

스타트업 두 번 창업하고 코드를 뚫어본 사람으로서 말하는데, 기술로 사회를 바꾸려면 "데이터를 바로 쓰게" 하는 게 가장 빠릅니다. 부디 API 하나로 끝나는 게 아니라 품질까지 같이 올려주세요！