コードで語るマニフェスト:自治体データの今とエンジニア的処方箋

IT 정책 제안
コードで語るマニフェスト:自治体データの今とエンジニア的処方箋

안녕하세요~ 오카무입니다! 오늘은 정부·지자체의 데이터와 시스템을 코드와 엔지니어 관점에서 파헤쳐보는 시간이야~

  • 이 글은 지방정부 오픈데이터 포털(예: Tokyo, Yokohama 등)과 정부 가이드라인(총務省·デジタル庁 문서)을 기반으로 분석함
  • 핵심 문제는 기계가 읽을 수 있는 데이터(머신리더블) 비중 부족, PDF 고정·메타데이터 부재, API 부재·품질 문제임
  • 제안은 표준화(스키마·메타데이터), API 우선 공개, CI로 데이터 테스트 자동화하는 것

結論

결론부터 말하면, 정책은 열린 방향으로 가고 있지만 "코드로 바로 쓰기 좋은" 데이터는 아직 부족해요. 엔지니어 입장에서 보면 많은 사례가 PDF·엑셀 덩어리로 남아있고, 메타데이터·스키마가 표준화되지 않아 재현성 있는 파이프라인 구축이 어렵습니다. 개선은 기술적 노하우를 운영에 넣는 거예요: API 우선, CSV/JSON/GeoJSON 표준, 데이터 검증 파이프라인, 그리고 데이터 스튜어드 제도 도입!

레포트

현재 상태(레퍼런스 기반)

이거 보세요: 도쿄 오픈데이터 포털(portal.data.metro.tokyo.lg.jp)과 카탈로그(catalog.data.metro.tokyo.lg.jp)는 CSV·GeoJSON을 제공하는 좋은 예가 많아요. 하지만 현장에서는 PDF에 묻혀 있는 통계표, 메타데이터가 빈약한 데이터셋, API가 없는 자료도 여전히 많이 보입니다. 총務省(2020)은 통계표의 기계판독가능 표기 통일을 권장했고, 内閣官房 문서(2025 관련)는 AI-Ready 사회를 위해 행정데이터의 머신리더블화를 강조하고 있어요(참고: go.jp 문서들).

엔지니어적 포인트:

  • PDF → CSV 변환은 OCR·표 추출의 품질 문제(레이아웃 변경에 취약)
  • 엑셀은 버전·서식 문제로 자동화에 불리함
  • API가 있어도 스키마가 불명확하거나 페이징·정렬·필터가 없으면 실무에서 쓰기 어려움

기술적 검증 예시

이런 상황에서는 간단한 파이프라인으로 현황을 진단할 수 있어요. 예를 들어, 도쿄 카탈로그에서 CSV 다운로드 후 기본 검사:

# 예시: CSV 기본 검사 (Python)

import pandas as pd

url = 'https://example.city/data.csv' # 포털의 CSV URL

df = pd.read_csv(url)

print(df.info())

컬럼명 표준화

df.columns = [c.strip().lower().replace(' ', '_') for c in df.columns]

결측 비율

print(df.isna().mean())

PDF만 있는 경우엔 tabula-py나 Camelot으로 표를 추출하되, 자동화 실패 케이스를 로깅해야 해요. 추출 후에는 스키마 검증을 반드시 거치기:

# 예시: pydantic 같은 라이브러리로 스키마 체크

from pydantic import BaseModel

class PopulationRow(BaseModel):

year: int

population: int

정책 목표 vs 실적 갭(일반화된 관찰)

많은 지자체는 "오픈데이터" 선언과 함께 데이터 게시를 하고 있지만, 실제로 재사용 가능한 형태(머신리더블, 일관된 스키마, 오픈라이선스)는 아직 목표치에 미달하는 경우가 많아요. 예를 들면, 관광지·공공施設 목록은 CSV로 공개되기도 하지만, 좌표 형식이 제각각이거나 업데이트 주기가 불명확한 경우가 빈번합니다. 즉, 숫자(데이터셋 수)로는 성과가 나와도 실제 재사용 가능성은 낮을 수 있어요. 要するに, "수량(公開件数)"과 "품질(機械可読性/メタデータ)"이 따로 놀고 있다는 말입니다.

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

  • API 우선(REST/GraphQL): 모든 구조화 가능한 데이터는 API로 우선 제공. 필터·정렬·페이징 필수
  • 표준 스키마 채택: 지방표준에 더해 DCAT-AP-JP, JSON Schema를 이용한 명세화
  • 메타데이터 자동화: 데이터 발행 시 포털 메타데이터(作成日、更新日、ライセンス、カラム説明)를 강제
  • 데이터 CI/CD: Git-based 데이터 레포(또는 데이터 카탈로그) → PR로 검증 → 테스팅(스키마·품質) → 배포
  • 데이터 스チュワード와 SLO: 품질 목표(SLA 같은) 설정, 결함 비율·更新遅延을 모니터링
  • CSV/JSON/GeoJSON 우선, PDF는 아카이브용으로만 사용
  • 간단한 데이터 배포 CI 예시(GitHub Actions):

    # push 시 CSV 스키마 검사 트리거(개념)
    

    on: [push]

    jobs:

    validate:

    runs-on: ubuntu-latest

    steps:

    - uses: actions/checkout@v2

    - name: Setup Python

    uses: actions/setup-python@v2

    with: {python-version: '3.10'}

    - run: pip install pandas pydantic

    - run: python scripts/validate_datasets.py

    활용 가능성

    • 실시간 센서(수위, 방재) 데이터: GeoJSON+Timeseries API로 대시보드·알림 자동화
    • 오픈데이터 맵(위치 기반 검색): 현재 위치 기반 검색 서비스는 이미 사례(デジタル庁事例)로 존재하므로, 표준 스키마만 맞추면 민간 애플리케이션이 빠르게 만들어질 수 있음
    • 해석 가능한 정책지표: 예산·補助금의 지급 내역을 정형화하면 시민감시·정책평가가 쉬워짐

    まとめ

    이상적으로는 "모든 공개 데이터가 코드로 곧바로 쓰일 수 있는 상태"가 목표입니다. 현실은 아직 PDF·엑셀의 함정, 메타데이터 부족, API 미완비가 발목을 잡고 있어요. 하지만 표준 스키마, API 우선, 데이터 CI와 스튜어드 조직만 갖추면 재사용 가능성은 급속히 올라갑니다. 기술적으로는 복잡한 일 아닙니다—정책·조직적 의지와 약간의 엔지니어링 투자만 있으면 돼요!

    おかむーから一言

    기술로 사회를 업그레이드하는 건 결국 실행력 문제예요. 데이터는 공개하는 순간부터 유지관리의 책임이 생깁니다. 작은 팀이라도 API 하나, 스키마 하나부터 시작해보세요. 내가 보기엔 그 한 걸음이 정책의 현실을 바꿉니다!

    공유하기