공공데이터 활용을 위한 개방 경로·품질·준수 설계
공공데이터를 OpenAPI·파일·대용량 경로로 활용할 때 필요한 거버넌스, 품질 검증, 보안 운영과 법적 준수 설계
2026-08-14 · 최초 발행 2024-04-29
공공데이터를 서비스 데이터로 다룰 때 생기는 문제
공공데이터는 공공기관이 생성·취득·관리하는 전자적 데이터 집합이다. 행정, 교통, 환경, 재정처럼 범위가 넓고, www.data.go.kr를 중심으로 OpenAPI 제공도 확산되고 있다. 접근의 평등성과 상업적 이용은 법·정책적으로 보장되며, 사실적 내용의 위조·변조·왜곡을 하지 않는다는 조건 아래 2차 활용도 가능하다.
다만 데이터가 공개돼 있다고 해서 어떤 방식으로든 바로 배포할 수 있는 것은 아니다. 포털 이용약관과 데이터셋별 이용조건을 확인해야 하며, 출처표시·변경내역 명시·비식별 유지 같은 요건이 붙을 수 있다. 공공기관은 특별법 또는 법 제28조 1항에 해당하는 사유 외에는 영리 목적 이용을 제한할 수 없다.
서비스 설계에서는 개방 여부보다 데이터의 갱신 방식, 오류 대응, 변경 추적, 개인정보 위험을 함께 다루는 편이 중요하다.
개방 원칙은 이용조건과 함께 읽어야 한다
공공데이터는 비식별과 공익성 기준을 충족하는 범위에서 OpenAPI, 파일, 대용량 데이터 등으로 제공된다. 누구나 차별 없이 접근할 수 있어야 하므로 신청·승인 과정은 기술적·운영상 최소화하는 방향을 지향한다.
상업적 이용 역시 허용될 수 있지만, 원문 사실관계를 왜곡해서는 안 된다. 데이터 출처와 생성일시 같은 메타데이터를 보존하는 방식이 권장되며, 실제 배포 전에는 각 데이터셋의 이용조건과 최신 약관·법령을 확인해야 한다.
제공 경로에 따라 운영 모델이 달라진다
OpenAPI는 실시간 질의와 갱신에 적합하다. 대신 쿼리 파라미터, 페이징, 호출 제한(Rate Limit), 공급자 변경의 영향을 고려해야 한다. 운영 SLA와 장애 공지 채널도 함께 확인할 대상이다.
파일 다운로드는 CSV, JSON, XML 형태로 정기 배포되는 데이터를 대량 분석하거나 백필(backfill)할 때 맞는다. 파일 크기, 레코드 수, SHA 등을 이용한 무결성 검증이 필요하다. 빅데이터 분석용 덤프나 객체스토리지·FTP 제공 사례는 대용량·배치 처리에 유리하지만, 스키마 버전 관리와 호환성 테스트가 필수다.
| 접근 방식 | 성능 | 확장성 | 일관성 | 안정성 | 운영 편의 |
|---|---|---|---|---|---|
| OpenAPI | 중~고, 실시간 지연 의존 | 수평 확장 용이, 할당량 제약 | 공급자 변경 영향 큼 | 외부 의존 리스크 존재 | 자동화 용이, 모니터링 필요 |
| 파일 다운로드 | 고, 대량 처리 유리 | 배치 중심 확장 | 배포 주기 내 일관 | 자체 인프라에 좌우 | 간단, 정기 스케줄링 |
| 대용량 덤프 | 고, 오프라인 분석 최적 | 스파크/분산처리 확장 | 스냅샷 기준 강한 일관 | 대역폭·스토리지 이슈 | 초기 세팅 비용 높음 |
호출부터 파생지표까지 추적 가능한 흐름
인증 정보는 API 키나 토큰으로 관리하고 HTTPS를 강제한다. 키 로테이션과 서버사이드 호출을 기본으로 두며, 대량 요청은 배치 윈도우에 맞춰 스케줄링한다. 캐시 레이어에서는 ETag, Last-Modified, TTL을 활용하고, 큐잉·리트라이·백오프를 결합한다.
응답을 받으면 일관된 스키마와 코드체계, 예를 들어 행정동 코드 매핑을 관리해야 한다. 원문은 보존하고 해시·서명값을 검증하며, 수집 시각·원천 API URL·쿼리 파라미터를 로그로 남긴다. 결측률, 최신성(Delay), 중복률, 참조무결성은 지속적으로 관찰하고 이상치 감지 룰도 운영한다.
장애와 변경을 전제로 하는 처리 절차
데이터셋을 고를 때는 포털 검색 결과만 보지 말고 스키마, 제공 주기, 이용조건을 먼저 검토한다. 키는 개발계와 운영계로 분리하고, 권한과 쿼터를 확인한다.
호출 단계에서는 429와 5xx 응답에 재시도를 적용하고, 타임아웃은 2~5초로 둔다. JSON 스키마와 누락 필드를 검증하며, 단위와 코드체계도 맞춘다. 원천 원문과 정제본은 이중으로 보관하고 버전과 해시를 함께 기록한다.
집계·정규화로 파생지표를 만들 때는 산식을 문서화하고 변경 시 버전을 갱신한다. 결과는 내부 API나 리포트로 제공하며, 캐시 TTL과 무효화 전략을 함께 설계한다. 호출량이 제한에 닿으면 요청을 스로틀링하고 대기열을 운영한다. 값 범위와 중복을 검사해 이상을 찾고, 공급자 이슈가 생기면 최근 스냅샷을 폴백으로 제공한다. 이용조건에서 금지한 항목이 감지되면 배포를 차단하고 법무 검토 워크플로우로 넘긴다.
OpenAPI 호출과 재시도 예시
전제: Python 3.10+, requests 설치, data.go.kr 발급 키 보유.
import os, time, requests
from urllib.parse import urlencode
API_URL = "https://api.odcloud.kr/api/xxx/v1/list" # 실제 엔드포인트로 교체
SERVICE_KEY = os.environ["DATA_GO_KR_KEY"] # URL-encoded 키 권장
PAGE_SIZE = 100
MAX_RETRY = 5
def fetch_page(page):
params = {
"serviceKey": SERVICE_KEY,
"page": page,
"perPage": PAGE_SIZE,
}
for attempt in range(MAX_RETRY):
r = requests.get(API_URL, params=params, timeout=5)
if r.status_code == 200:
return r.json()
if r.status_code in (429, 500, 502, 503, 504):
sleep = min(2 ** attempt + (attempt * 0.1), 30)
time.sleep(sleep)
continue
r.raise_for_status()
raise RuntimeError("Max retry exceeded")
def fetch_all(max_pages=10):
results = []
for p in range(1, max_pages + 1):
data = fetch_page(p)
items = data.get("data") or data.get("items") or []
if not items:
break
results.extend(items)
return results
if __name__ == "__main__":
rows = fetch_all()
# TODO: 스키마 검증 및 저장 로직 추가
print(f"rows={len(rows)}")
활용 서비스에서 확인할 지점
모빌리티 서비스는 실시간 버스·지하철 도착 OpenAPI를 연계하고 지역 단위 캐시를 둬 호출량을 60% 절감할 수 있다. 장애나 지연이 발생하면 T+X분 예측모델의 대체값으로 사용자 경험을 안정화한다.
상권·핀테크 분석에서는 상권·인구·기업등록 데이터를 결합해 점포 입지 스코어를 산출하고, 정기 배치로 최신성을 유지한다. 사실 데이터의 원문을 보존하고 파생지표 산출식의 버전을 관리해야 재현성을 확보할 수 있다.
기상·공기질·재난문자 API를 묶은 알림 서비스는 임계치 기반 푸시를 발송한다. 이때 서킷브레이커와 재시도를 적용해 외부 API 의존성으로 인한 가용성 저하를 줄인다.
최신성과 비용 사이의 운영 선택
키는 서버사이드에 보관하고 환경변수나 비밀관리 체계를 이용해 주기적으로 로테이션한다. 서드파티 호출이 필요한 경우에는 프록시 게이트웨이가 필요하다.
TTL과 ETag를 활용한 캐시는 비용을 줄이지만 최신성을 낮출 수 있다. 중요 지표에는 조건부 요청을 함께 적용한다. 호출 성공률, 지연시간, 스키마 오류율을 대시보드로 관리하고 폴백을 운영하면 외부 SLA 의존성을 완화할 수 있다.
비식별 보장과 재식별 위험 평가도 빠질 수 없다. 민감항목은 필터링·마스킹하고, 파생지표의 방법론을 공개하며 오용 방지 가이드를 제공한다.
표준 API와 배치 파이프라인을 도입하면 데이터 수집·정제 비용은 3060% 절감되고 초기 개발은 24주 단축될 수 있다. 신규 데이터셋 통합 시간은 50% 이상 단축될 수 있으며, 출처 추적과 버전 관리는 감사 대응과 오류 재현성을 강화한다.