안녕하세요, 오카무(おかむー)입니다! 오늘은 정부·지자체 데이터와 시스템을 엔지니어 관점에서 까보고, '코드로 말하는 매니페스토'로 검증해 보려고 해요~

• 이 글 3줄 요약

- 공개된 행정 자료가 여전히 PDF에 묶여 있어 기계 가공성이 낮다. (Digital庁의 기계可読성ガイド라인 초안 참고)

- API나 CSV로 풀면 정책 성과를 지역 단위로 쉽게 비교·재검증할 수 있다. (デジタル田園都市交付金実績PDF가 사례)

- 실무적 개선안: 표준 스키마, API 제공, 자동화된 품질검증 파이프라인을 제안한다.

結論

행정 데이터는 '파일 형식'을 바꾸는 문제가 아니라 '데이터 인프라'를 설계하는 문제입니다. 엔지니어적으론 API·CSV·스키마·CI로 이어지는 파이프라인 하나면 대부분 해결되며, 지금 방식은 재현성(reproducibility)과 확장성에서 심각한 제약이 있어요.

レポート本文

현재 상태: PDF 중심의 공개 관행

이거 보세요, Digital庁에서 기계可読성에 관한 규칙 초안을 내놓았는데(https://www.digital.go.jp/...), 핵심은 "Excel/CSV 등 기계가 직접 읽을 수 있는 형식을 우선"이라는 점입니다. 그런데 실제로는 지방정부 실적 보고서가 PDF로 배포되는 경우가 많아요. 예: 山口県의 デジタル田園都市交付金実績보고서(https://www.pref.yamaguchi.lg.jp/uploaded/attachment/160746.pdf)에는 KPI와 실적 수치가 담겨 있지만 추출하려면 PDF 파싱이나 수작업이 필요합니다.

요컨대, 사람이 보기엔 괜찮아도 코드로는 쓰기 어렵다는 뜻이에요.

문제를 기술적으로 분석하면

• 형식 문제: PDF/スキャン 이미지 → 비구조화. CSV/JSON보다 파싱 실패 확률이 높다.
• 메타데이터 부재: 스키마(컬럼 의미, 단위, 날짜) 미기재 → 자동 검증 불가.
• API 부재 또는 파편화: 기관별로 엔드포인트 형식이 달라 통합이 어려움.
• 버전관리 부재: 변경 이력 추적 불가 → 재현성 저하.

이 모든 건 엔지니어적으론 "데이터 계약(data contract) 부재"라고 봅니다. 계약이 없으니 소비자가 신뢰할 수 없어요.

실제로 해보면? — 코드 예시

CSV가 제공된다고 가정하면 KPI 집계를 이렇게 바로 할 수 있습니다:

import pandas as pd
url = 'https://example.gov.jp/projects/dengen_kouhu.csv'
df = pd.read_csv(url)
KPI: 프로젝트별 집행액 합계
summary = df.groupby('prefecture')['amount_yen'].sum().reset_index()
print(summary)

반대로 PDF밖에 없을 때는 Tabula/Camelot으로 추출하거나 OCR 파이프라인을 돌려야 해요:

# 예: tabula를 이용한 테이블 추출
tabula -p all -f CSV https://.../report.pdf -o out.csv

이런 추가 단계가 들어가면 재현성도, 신뢰도도 떨어집니다.

정책 수치 목표 vs 実績のギャップ

デジタル田園都市交付金 같은 사업은 KPI를 설정하고 있지만, 성과 공시는 PDF 단위로 흩어져 있어 전국 단위 집계가 어렵습니다. 예컨대 山口県の実績は 15,289千円(報告書)로 명시돼 있지만, 이를 전국 비교 데이터로 넣으려면 수동 정제가 필요하죠. 정책 평가가 느려지고, 검증 가능성이 떨어집니다.

개선 제안(엔지니어 관점)

1) 기계 가독성 우선: 모든 실적·계약·지출 데이터는 CSV/JSON 또는 API로 우선 제공

2) 표준 스키마 적용: JSON Schema 또는 CSV 스키마를 공개해 소비자가 자동 검증 가능하게

3) 중앙 카탈로그: DCAT나 e-Stat 스타일 메타데이터 레지스트리(go.jp 도메인)로 색인

4) 간단한 REST API 제공: 조회·페이징·필터링 가능한 엔드포인트 한 세트

5) CI/CD로 데이터 품질 보장: 스키마 유효성 검사, 레코드 수 증감 알림, 월별 데이터 검증 리포트

6) 오픈소스 파이프라인 템플릿 제공: Tabula 대체가 아니라 최초부터 CSV를 생성하는 파이프라인

예: API 설계 샘플

GET /api/v1/grants?year=2024&prefecture=Yamaguchi

응답: JSON 배열, 각 항목에 schemaVersion, projectId, amountYen, kpiField, publishedAt 포함

구현 로드맵(빠르게 적용할 수 있는 90일 플랜)

• 0-30일: 우선순위 사업 3개 선정, 기존 PDF→CSV 수동 변환 및 스키마 설계
• 30-60일: 간단한 REST API(읽기 전용) 배포, 메타데이터 카탈로그에 등록
• 60-90일: CI 파이프라인 도입, 자동화 검증, 오픈소스 예제 제공

비용은 대규모 시스템 교체보다 훨씬 작고, 효과는 즉시 보입니다. 에ンジニア的に言うと、API一本で解決する話なんですよ。

まとめ

• PDF 중심 공개는 데이터 활용의 큰 장벽
• 기계 가독성 규칙(デジタル庁案、内閣官房提言)을 실제 운영으로 연결해야 함
• 기술적으로는 스키마·API·CI로 해결 가능하고 비용 효율적
• 지방정부의 실적 PDF(예: 山口県)같은 사례를 표준화하면 전국 단위 분석이 가능해진다

おかむーから一言

테크로 사회를 업그레이드하는 건 복잡한 정치 공론보다, 작은 인프라 개선부터예요. 엔지니어의 한 줄 코드가 행정의 투명성을 바꿀 수 있습니다. 함께 해보죠!