안녕하세요~ 오카무-입니다! 오늘은 정부·지방자치단체 데이터와 시스템을 엔지니어링 관점에서 뜯어보는 시간이에요. “코드로 말하는 매니페스토”라는 콘셉트로, 정책 수치와 시스템 설계가 실제로 열람·재활용 가능한지 확인해볼게요.

• 이 글의 핵심만 3줄 요약

- 중앙과 지방의 표준화 정책은 진전 중이지만, 실무 데이터는 여전히 PDF 중심으로 묶여 있어요. CSV/JSON 제공이 핵심입니다.

- API·스펙 부재와 형식 불일치 때문에 자동화·검증이 어렵습니다.OpenAPI·스키마가 필요해요.

- 간단한 ETL 패턴과 가벼운 API 레이어로 KPI 추적·재현 가능성을 대폭 올릴 수 있습니다.

결론

정책은 표준화·공개를 외치고 있지만, 현실은 PDF·個別報告書 중심이라 엔지니어링으로 바로 재현하기 어렵습니다. 要するに(요약하면) 문서 중심 공개를 데이터 중심 공개로 전환하면 검증 가능성과 활용성이 크게 올라갑니다.

레포트 본문

데이터 소스와 현황

참조한 자료들: Digital庁(https://www.digital.go.jp/)의 지방공공단체 정보시스템 표준화 안내, 관련 법령(地方公共団体情報システムの標準化に関する法律), 디지털田園都市交付金 실적 PDF(山口県 등) 등입니다. 이들 문서는 권위 있지만 실제 KPI·실적 데이터는 PDF 보고서에 묻혀 있거나, 기관별로 포맷이 달라 재활용이 어려워요.

これ見てくださいよ: 예를 들어 교부금 실적은 PDF 표로 공개되어 연도별·사업별 KPI가 들어있지만, CSV로 내려받을 수 없어서 자동 집계·검증이 불가능합니다.

기계가독성(PDF vs CSV) 문제

• 현상: 핵심 수치가 PDF에 테이블로 포함.
• 문제점: OCR/테이블 추출이 필요해 오류 발생률↑, 업데이트 추적 불가.
• 엔지니어적으로 말하면: 데이터 파이프라인의 첫 단계(ingest)가 사람이 손으로 하는 작업이라 자동화가 깨집니다.

참고로, PDF에서 표를 추출하는 간단한 예시(참고 코드):

# 참고용: tabula-py로 PDF 표를 CSV로 변환하는 예시
import tabula
pdf_path = 'report.pdf'
tables = tabula.read_pdf(pdf_path, pages='all', multiple_tables=True)
tables는 pandas DataFrame 리스트
for i, df in enumerate(tables):
df.to_csv(f'table_{i}.csv', index=False)

요약: 이 방법은 일회성으론 쓸 수 있지만 신뢰성·재현성이 낮아요. CSV/JSON 공개가 정답입니다.

API·스팩의 부재와 영향

• Digital庁의 표준화 정책은 ‘표준準拠システム’ 도입을 의무화하는 쪽으로 가고 있어요(좋은 방향).
• 하지만 표준 스펙이 있어도 데이터 배포 방식(OpenAPI, JSON Schema, CSV 등)이 명확하지 않으면 소비자는 각 기관 API마다 파서·변환기를 써야 합니다.

엔지니어적 제안: 모든 KPI·교부금·실적 자료에 대해 OpenAPI 명세와 JSON Schema를 제공하세요. 그러면 아래와 같은 이득이 있습니다:

• 자동 검증(스키마 기반)으로 데이터 품질 개선
• CI 파이프라인에서 배포 전 검수 가능
• 외부 개발자가 재활용하기 쉬움

정책 목표와 실적의 갭(예시 기반 가설적 분석)

디지털田園都市構想交付金 지침에는 KPI 설정과 연차별 개선 요구가 나와 있어요(ガイドライン PDF 참조). 하지만 실적보고서(山口県 예시)만 봐도, KPI 정의가 문서마다 달라 표준화가 덜 된 흔적이 있습니다. 要するに, 목표·지표·計測方法을 기계적으로 쿼리할 수 있게 정의해야 비교·검증이 가능합니다.

구체적 개선 제안(기술적 로드맵)

1) 데이터 발행 표준화

- 모든 실적·KPI는 CSV/JSON으로도 제공(원본 PDF 병기)

- JSON Schema/CSV 스키마 공개

2) 경량 API 레이어

- OpenAPI 제공, 페이징·필터·메타데이터 포함

- 예: /api/v1/kpis?year=2024&pref=Yamaguchi

3) ETL 파이프라인 예시

- 수집: S3에 원문(PDF)+구조화 데이터 업로드

- 변환: Lambda/Batch에서 표 추출→정규화→스키마 검증

- 배포: 정적 CSV/JSON + API Gateway 제공

4) 운영·품질관리

- 스키마 변경 시 버전 관리(semver)

- 변경 로그 및 데이터 카탈로그(データカタログ) 공개

5) UX/서비스 개선

- 행정UI 가이드라인(デジタル庁) 활용해 개발자 포털·샘플 코드·샌드박스 제공

간단한 ETL 패턴(의사코드)

• 행동: 주기적으로 PDF를 내려받아 표를 추출→스키마 검사→CSV 업로드

# 의사코드
files = list_remote_reports()
for f in files:
pdf = download(f)
tables = extract_tables(pdf)
normalized = normalize_tables(tables, target_schema)
if validate_schema(normalized, schema):
upload_csv(normalized, bucket)
else:
notify_team(f)

이런 패턴이면 최소한의 자동화로 재현 가능하고, 정책 실적을 매번 수동으로 재계산하지 않아도 돼요!

まとめ

• 정책 문서는 늘어났지만, 기계가 읽을 수 있는 데이터는 부족하다.
• PDF 중심 공개를 CSV/JSON + OpenAPI로 바꾸면 검증·활용성이 크게 올라간다.
• 현실적 해결책은 표준 스키마·경량 API·작은 자동화 파이프라인을 단계적으로 도입하는 것.

オカムーから一言

엔지니어적으론 해법이 명확하다고 봐요. 작은 API 하나, 몇 개의 스키마 정의로 정책의 투명성과 재현성이 훨씬 좋아집니다. 테크로 사회를 업그레이드합시다!