コードで語るマニフェスト:政府データはもうちょっとエンジニアに優しくしてほしい

IT 정책 제안
コードで語るマニフェスト:政府データはもうちょっとエンジニアに優しくしてほしい

안녕하세요~ 오카무입니다! 오늘은 정부·지자체 공개 데이터들을 엔지니어 관점에서 훑어보고, "코드로 말하는" 방식으로 정책과 시스템을 검증해보려고 해요.

  • 이 글 3줄 요약
- 공개 데이터 중 CSV로 제공되는 건 있으나 인코딩·메타데이터 등 기계 판독성에서 아쉬움이 남음

- PDF 중심 보고서는 자동화 분석이 어렵고 KPI 실적 검증이 수작업에 의존하는 경우가 많음

- 해결책: 표준 스키마, API 우선 공개, 변환 파이프라인과 가벼운 포털(예:CKAN) 도입

結論

정책의 신뢰성은 ‘데이터가 기계로 읽히는가’로 크게 개선된다! CSV가 보이면 반가우나, 엔지니어적으론 API + JSON-LD/Schema가 있어야 진짜 재사용 가능해진다. PDF 보고서 중심의 공개 관행은 자동 검증과 재현 가능성을 갉아먹는다.

レポート本文

何を見たか(データソースの概観)

검색 결과를 보니 실제로 go.jp 기반의 CSV 파일들이 존재합니다:

  • notice.go.jp의 status_notice.csv — 공고 상태 데이터 (검색결과[1])
  • inpit, env, mhlw 등의 CSV 파일 (검색결과[2][3][4])
  • 総務省의 분류 항목명 CSV (検索結果[5])

이거 보세요: CSV로 공개된 건 좋은 신호인데, 엔지니어가 바로 쓰기엔 보통 다음 문제가 있어요.

문제점: 기계 판독성에서 자주 보이는 병목

  • 인코딩 불명(UTF-8 vs Shift_JIS) → pandas.read_csv에서 한 줄에 깨짐 발생
  • 메타데이터 없음(スキーマが公開されてない) → 컬ラム 의미를 수작업으로 해석해야 함
  • 업데이트 방식 불투명(버전·更新日時) → 데이터 신뢰성 검증이 어려움
  • PDF 보고서와 CSV가 혼재 → KPI 계산과 검증이 수작업

要するに: 데이터가 "기계에 읽히는 상태"로 제공되어 있지 않으면 재검증도 자동화도 어렵다는 것!

技術적検証: CSV를 받아서 최소 검증하는 코드 예

에러 케이스를 잡기 위한 간단한 파이썬 예시입니다. 인코딩 탐지 → 스키마 체크 → JSON으로 노출하는 기본 파이프라인.

import chardet

import requests

import pandas as pd

from jsonschema import validate, ValidationError

url = 'https://notice.go.jp/docs/status_notice.csv'

r = requests.get(url)

enc = chardet.detect(r.content)['encoding']

print('detected encoding', enc)

df = pd.read_csv(pd.compat.StringIO(r.content.decode(enc)))

expected_schema = {

'type': 'array',

'items': {

'type': 'object',

'properties': {

'notice_id': {'type': 'string'},

'status': {'type': 'string'},

'updated_at': {'type': 'string', 'format': 'date-time'}

},

'required': ['notice_id','status']

}

}

data = df.to_dict(orient='records')

try:

validate(instance=data, schema=expected_schema)

print('schema OK')

except ValidationError as e:

print('schema violation', e)

엔지니어적으론 이 파이프라인을 배포 가능한 ETL로 만들어야 재사용성과 신뢰성이 확보됩니다!

KPI와実績のギャップ検証

검색 결과에서 디지털田園都市構想의 KPI 문서(検索結果[11-14])를 보면, 정책별로 KPI가 설정돼 있지만 실제 성과평가 보고서는 PDF로 배포되는 경우가 많아요. 이러면 수치 근거를 자동으로 대조하기 어렵습니다. 예를 들어 교부금 집행·성과지표는 CSV/API로 공개하면 외부에서 독립적으로 재현 가능한데, 지금은 표 결합·스크래핑에 의존하죠.

提案: 현실적이고 구체적인改善案

  • API 우선 전략: CSV는 보완재, 진짜는 RESTful JSON API(페이징·ETag·CORS 지원)
  • 스키마 공개: JSON Schema / CSVW(Comma Separated Values on the Web)로 컬럼·타입 명세
  • 메타데이터·バージョン管理: 데이터셋별 URI, 발행일,更新履歴を明示
  • 포털 개선: CKAN같은 오픈데이터 플랫폼 도입으로 탐색성·메タ데이터を改善
  • 자동화 파이프라인: 인코딩 탐지→정규화→스키마 검증→API 노출 (CI로 자동화)
  • PDF 정책보고서는 기계판독 가능한 부속 데이터로 병행 공개
  • 技術的には、CSV→Parquet 변환 후 카タログ(예:DataHub)로 인덱싱하면 대용량 분석도 쉬워집니다. 또한 JSON-LD와 Schema.org를 붙이면 검색엔진과 AI가 더 잘 이해하게 돼요.

    まとめ

    • CSV 공개는 좋은 시작이지만, 인코딩·스키마·バージョン管理の欠如が再利用を阻んでいる
    • PDFだけで終わらせないで、APIとメタデータをセットで出すべき
    • 엔지니어視点の小さな改善(스키마·API·CI)이 정책의透明性と検証容易性をぐっと上げる

    おかむーから一言

    데이터는 정치의 약속을 코드로 증명하는 수단이에요! 작은 표준 하나가 거대한 신뢰를 만든다고 믿습니다. 기술로 정책을 재현 가능하게 만들자고요~

    공유하기