안녕하세요~ 오카무입니다! 오늘은 공공데이터를 코드 관점에서 파헤쳐볼게요~

• 도쿄도·지방자치체는 CSV 형태의 오픈데이터를 늘리고 있지만 품질 편차가 큽니다
• PDF에 묶여 공개된 데이터, 문자셋·스키마 미정의 등으로 자동화가 힘듭니다
• 해결책은 API 표준화·메타데이터·CI 기반 배포로, 정책의 수치목표 검증이 가능해집니다

결론

공공데이터는 이미 쌓여 있는데 엔지니어가 바로 쓸 수 있는 상태가 아니에요. 엔지니어적 관점으로 보면 CSV·API·스키마를 일관되게 제공하면 정책 검증과 서비스화가 단번에 가능해집니다. 즉, 데이터 공개의 '양'은 충분하지만 '질'을 지금 바로 개선해야 합니다!

레포트 본문

데이터 현황(증거 기반)

이 부분은 실제 공개 포털을 직접 훑으면서 본 내용입니다. 도쿄도 오픈데이터 카탈로그(https://catalog.data.metro.tokyo.lg.jp/dataset)에는 지역별·시설별 CSV가 다수 올라와 있고(검색 결과[1][4]) 하코다테나 니가타 같은 지방자치체도 CSV 가이드·목록을 갖추고 있어요(https://www.harp.lg.jp/opendata/dataset/79.html, https://www.city.niigata.lg.jp/shisei/seisaku/it/open-data/index.files/csv_manual_v1.1.pdf)。

이 데이터들, 겉보기엔 CSV인데 다음 문제가 많습니다:

• 문자 인코딩 불명(Shift_JIS vs UTF-8) → 자동 수집 파이프라인 깨짐
• 스키마 미기재 → 컬럼 의미 추론 필요
• 좌표계·코드(행정코드) 혼재 → 조인 어려움
• 업데이트 메타정보가 불충분 → 시계열 분석 신뢰도 저하

이건 엔지니어적으로 말하면 "API 한 줄로 해결 가능한데 파일럿이 폴더에 CSV 던져놓은 상태"인 거예요.

PDF vs CSV 문제

정부·지자체는 아직도 보고서 중심으로 데이터를 PDF에 묶어 공개하는 경우가 있어요(내각府 등에서도 CSV 제공처는 있으나 PDF 병존, 검색 결과[11][15])。PDF는 사람 읽기엔 좋지만 기계가 읽기엔 최악입니다. OCR·정제에 시간 뺏기는 건 곧 예산 낭비예요. 要するに, 기계가 읽을 수 있는 형식으로 공개해야 한다는 얘기입니다.

API와 메타데이터 평가

몇몇 데이터셋은 API 태그가 붙어 있어 프로그래밍적 접근이 가능하더라고요(도쿄 카탈로그의 API 노출 사례). 하지만 대부분은 RESTful 설계·페이지네이션·스키마 명세(OpenAPI, CSVW 등)가 부족합니다. 엔지니어적으로는 아래가 필요해요:

• OpenAPI/JSON Schema 또는 CSV on the Web(CSVW) 메타데이터
• 데이터 계약(스키마)의 버전 관리
• CORS·단일 엔드포인트로의 접근성

코드 예시: CSV 자동 수집 + 스키마 검증(Python)

import pandas as pd
import requests
from jsonschema import validate

url = 'https://www.digital.go.jp/assets/.../xxxxxx_hospital.csv'
res = requests.get(url)
open('hosp.csv','wb').write(res.content)

df = pd.read_csv('hosp.csv', encoding='utf-8')
간단 스키마 체크
schema = {"type":"object","properties":{"都道府県名":{"type":"string"},"緯度":{"type":"number"},"経度":{"type":"number"}}}
for _, row in df.iterrows():
validate(dict(row.dropna()), schema)

요건 단순 예시지만, 자동화 파이프라인에서 스키마 검증을 걸어두면 데이터 신뢰도가 확 올라갑니다.

정책 목표 vs 실적 갭 분석 방법

정책은 숫자 목표를 자주 갖고 있는데, 실제 성과를 검증하려면 관련 행정데이터(예: 공공시설 이용률, 재정지출, 인구통계)를 시계열로 정합해야 하죠. 예를 들어 공공투자 추세 데이터(내각府 CSV, 검색 결과[15])와 지역별 인구·시설 데이터(도쿄 카탈로그)를 조인하면 투자 대비 성과(예: 시설 이용률 증가 등)를 산출할 수 있습니다. SQL/데이터프레임으로는 다음과 같은 절차예요:

1) 데이터 수집(CSV/API)

2) 공통키(지자체코드·연월)로 정합

3) 결손치·단위(천원 vs 만원) 통일

4) KPI(예: 투자당 이용자 증가율) 계산

개선 제안(우리는 실무자니까 구체적으로)

• 모든 공개 데이터에 CSVW + JSON Schema 부착
• UTF-8 표준 도입과 파일 헤더에 인코딩 표기
• OpenAPI로 API 스펙 제공, CORS 활성화
• GitHub 연동 공개 레포지토리 + CI(스키마 테스트)로 배포 자동화
• 샘플 쿼리·데이터셋(Notebook) 제공으로 재현성 확보

기술적으로는 CKAN 같은 플랫폼을 쓰면 메타데이터 관리가 쉬워집니다. 그리고 데이터 라이センス도 명확히 해주면 민간 활용 촉진됩니다(디지털청 사례 참고: https://www.digital.go.jp/resources/data_case_study_private)。

정리

• 공개량은 늘었지만 기계가 바로 쓰긴 힘든 품질 이슈가 핵심
• CSV·API·스키마 표준화로 정책 검증과 서비스화가 쉬워짐
• 구체적 실행은 CSVW/JSON Schema, OpenAPI, CI 파이프라인 구축이 정답

おかむーから一言

테크로 사회를 바꾸는 건 결국 실행력입니다. 데이터 표준 만들고 CI 돌려서 바로 쓰게 해봅시다! 나는 그 현장에서 같이 뛰고 싶어요~