안녕하세요~ 오카무~입니다! 오늘은 "코드로 말하는 매니페스토"라는 콘셉트로 정부·지자체 데이터의 기술적 상태를 까발려보려고 합니다. 에ン지니어적 관점에서 정책 수치와 데이터 공개 방식이 실제로 맞물리는지, PDF지옥을 어떻게 CSV·API로 바꿀지까지 실용적으로 다룰게요~

• 지방자치단체 데이터 중 여전히 PDF로 묶인 통계가 많다
• 일본 정부의 기계판독성 지침(案)은 있지만 실무 전환은 느리다(예: digital.go.jp, soumu.go.jp)
• 해결책은 API 우선·머신리더블 표준·자동화된 데이터 품질 파이프라인이다

結論

결론부터 말하면, 정책 목표(오픈데이터·투명성)는 훌륭하지만 기술적 실행계획이 부족해요. 에ン지니어적으론 "파일 포맷과 인터페이스를 표준화하고, 자동화로 신뢰성을 확보하라"가 핵심입니다. PDF로 배포하는 관행을 멈추고 CSV/JSON+스키마, OpenAPI/REST API, 메타데이터 카탈로그를 의무화하면 정책 수치의 검증 가능성과 활용성이 확 달라집니다.

레포트 본문

1) 현황 진단: PDF vs CSV(기계판독성)

이거 보세요: 행정 데이터의 기계판독성 규칙(案)은 digital.go.jp에서 공개되어 있고(“ファイル形式は機械が直接読み取れる Excel や CSV 等” 같은 레벨 규정이 있음), 총무성도 통계표 표기 규칙을 제정해요(soumu.go.jp). 근데 현실은 지방자치단체 포털이나 공문서에 PDF로 묶여있는 통계표가 여전히 엄청 많습니다(활용 사례를 모은 GovTech Tokyo 사례와 INTEC의 정리 참고).

요약하면

• 정책 문서엔 "기계가 읽을 수 있는 형식"을 권장하나
• 배포 관행은 여전히 PDF 우선
• 그 결과 연구자·스타트업이 데이터를 재가공하느라 시간 낭비

要するに: 포맷 불일치가 바로 재현성·검증 가능성의 적이다.

2) API와 메타데이터: 어떤게 필요할까

엔지니어적으로 말하면, 데이터는 인터페이스(REST/GraphQL), 포맷(JSON/CSV), 스키마(JSON Schema/CSV Schema), 메타(라이선스, 업데이트 주기, 버전)가 전부 있어야 해요. e-Stat 같은 통계 API 형태(예: e-stat.go.jp의 오픈 API 형식)를 벤치마크로 삼을 수 있습니다. GovTech Tokyo 사례는 대시보드·공통화로 내부 데이터 활용을 개선한 좋은 참조예요.

3) 기술적 검증(예시 코드)

코드 쓰는 사람이라면 다음 같은 간단한 파이프라인을 떠올리면 돼요(아래는 예시 코드, 실제 운영 전 보안·에러처리 추가 필요):

# 예시: 공개 API에서 CSV 받아서 검증하고 Parquet으로 변환
import requests
import pandas as pd
from frictionless import Resource

r = requests.get('https://example-gov.jp/data.csv')
open('data.csv','wb').write(r.content)
간단 검증
res = Resource('data.csv')
if res.valid:
df = pd.read_csv('data.csv')
df.to_parquet('data.parquet')
else:
print('데이터 형식 불일치', res.flatten_errors())

PDF에 묶인 통계표라면 tabula-py 또는 Camelot으로 표를 추출해 CSV화하고, 추출 후 자동 검증(칼럼 존재, 타입 검사)을 파이프라인에 넣어야 합니다. 다만 이건 임시방편이니 근본적으로는 데이터 제공자가 머신리더블로 바꾸는 게 우선입니다.

4) 정책 수치 목표 vs 실적 갭

많은 지자체가 "오픈데이터 X건 공개" 같은 수치 목표를 세우는 경우가 있는데, 실적은 단순 파일 수치로 채워지고 있어요. 문제는

• 기계판독 가능 여부가 반영되지 않음
• 메타데이터·라이선스 명시가 빠짐
• 업데이트 주기·버전 관리가 없음

따라서 시민이나 개발자가 그 데이터를 신뢰해서 서비스화하기 어렵습니다. GovTech Tokyo의 사례(데이터 정비·가시화 지원)는 이런 갭을 줄인 사례예요.

5) 구체적 개선 제안(엔지니어 관점)

• 정책: 공개 의무 데이터는 우선적으로 CSV/JSON(스키마 명시)로 공개
• API 우선 전략: 정적 파일+API(REST/OpenAPI 명세) 병행 제공
• 메타데이터 카탈로그 도입: CKAN/Dkan 혹은 국산 포털 연동
• 자동화 파이프라인: CI(깃훅)로 데이터 유효성 검사(frictionsless/goodtables)
• 버전·배포: Git-like 데이터 버전관리 + 리소스 URL 안정성 보장
• 개발자 경험: CORS, rate limit 문서화, 예제 쿼리 제공

간단한 JSON Schema 예시:

{
"$schema": "http://json-schema.org/draft-07/schema#",
"type": "object",
"properties": {
"prefecture": {"type":"string"},
"year": {"type":"integer"},
"population": {"type":"integer"}
},
"required":["prefecture","year","population"]
}

이런 스키마를 데이터와 함께 공개하면 엔지니어는 바로 파이프라인에 연결할 수 있어요.

まとめ

• 법·지침(예: digital.go.jp, soumu.go.jp의 규정안)은 갖춰가는 중
• 하지만 실무는 PDF·메타데이터 부재·버전관리 미비로 활용성이 낮음
• 엔지니어적 처방은 "API 우선, 머신리더블 표준, 자동화된 검증"입니다
• GovTech·민간사례를 참고해 파일 포맷·메타데이터·테스트를 의무화하면 큰 개선 가능

おかむーから一言

테크로 사회를 고치는 건 결국 실행력입니다. 정책 문구도 중요하지만, 코드 한 줄·자동화된 테스트가 정책을 실제로 작동하게 만듭니다. 같이 만들어봅시다!