이용 절차 분석 — 사람·AI 에이전트가 data.go.kr를 쓰기까지

20+

OpenAPI 활용신청까지 세부 액션 수 (화면 기준 9~13단계)

3~5회

여정 중 인간 개입 필요 횟수 (본인인증·약관·심의)

≈13.3만

검색 결과 1페이지의 원문 HTML 토큰 (465KB 실측)

사실상 불가

에이전트 단독 완전 자율 이용 (본인인증 하드 블록)

1. 시나리오별 여정 총량 — 무엇을 하려느냐에 따라 벽의 높이가 다르다

같은 포털이라도 이용 시나리오에 따라 절차 부담이 크게 다릅니다. 네 가지 대표 시나리오로 분해하면 다음과 같습니다.

시나리오	주요 단계 수	세부 액션	인간 개입	자동화 가능성
A. 단순 파일 다운로드 공개 CSV/JSON 내려받기	3~5	5~8	0~1회	높음 — 대부분 자동화 가능
B. OpenAPI 시험 이용 개발계정 활용신청 → 첫 호출	9~13	20+	3~5회	중간 — 발견~인가 구간 30~50%
C. 상용 서비스 운영 운영계정 전환·트래픽 증량 포함	14~20	30+	5~8회+	낮음 — 20~40%
D. 다중 API 조합 여행 추천 에이전트: 날씨·관광지·숙박·행사·교통·주차·충전소·음식점·축제·응급의료 10종	시나리오 B × 10	60~100+	10회+ (API별 반복)	매우 낮음 — 일괄 신청 불가

A. 파일 다운로드5~8 액션

B. OpenAPI 시험20+ 액션

C. 상용 운영30+ 액션

D. 10개 API 조합60~100+

시나리오 D가 결정적입니다. 실제 응용(여행 추천, 생활 안전, 지역 상권 분석 등)은 거의 항상 여러 API의 조합인데, data.go.kr에는 묶음 신청·일괄 승인 개념이 없어 API마다 검색→신청→승인→키 관리를 반복해야 합니다. 인간에게는 "귀찮음"이지만, 에이전트에게는 선형적으로 누적되는 비용이자 실패 확률입니다.

2. OpenAPI 활용신청 상세 여정 — 어디서 사람이 필요하고, 어디서 에이전트가 멈추는가

가장 흔한 시나리오 B(OpenAPI 시험 이용)를 단계별로 분해했습니다. 각 단계에 에이전트 관점의 자동화 판정을 붙였습니다: 자동화 가능 부분 가능 인간 필요 대기

1
포털 접속·키워드 검색 자동화 가능
단, 검색 결과 페이지가 465KB(≈13.3만 토큰)의 스크립트 중심 HTML — 가시 텍스트는 그중 약 1.7%뿐이라 에이전트는 브라우저 렌더링 또는 대규모 파싱이 필요합니다. 2026-08-03부터 검색창 기본 동선이 AI 대화형 검색으로 바뀌었습니다(아래 §3-1 브라우저 실측 참조) — 사람의 발견 단계는 개선됐지만, 채팅 UI 기반이라 에이전트용 표준 API 경로는 여전히 없습니다.
2
후보 API 비교·선정 부분 가능
유사 API가 기관별로 난립(전국 단위 vs 지자체별 분할)해 있고, 카탈로그를 기계가독 형태로 한 번에 받을 공식 방법이 없어 페이지를 순회해야 합니다.
3
상세 페이지에서 스펙 확인 부분 가능
상세 페이지 203KB(≈5.8만 토큰). 요청/응답 명세가 HWP·DOCX 첨부로 제공되는 경우가 많아 표준 OpenAPI 스펙 파싱이 불가능한 API가 다수입니다.
4
회원가입 (아이디·이메일 인증) 부분 가능
폼 입력 자체는 자동화 가능하지만, 계정이 '개인'에게 귀속됩니다 — 서비스·에이전트 명의 계정 개념이 없습니다.
5
휴대폰 본인인증 / 아이핀 인간 필요 — 하드 블록
실명 기반 본인확인은 에이전트가 대행할 수 없고, 대행해서도 안 되는 설계입니다. 이 지점에서 완전 자율 여정은 구조적으로 종료됩니다.
6
이용약관·활용 조건 동의 인간 필요
법적 책임 주체가 동의해야 하며, 약관이 기계가독(machine-readable) 형태가 아니라 에이전트가 조건을 해석·판단하기 어렵습니다.
7
활용신청서 작성 (활용 목적 등) 부분 가능
자유서술 입력은 채울 수 있으나, 신청을 제출할 관리용 API가 없어 화면 자동화에 의존해야 합니다.
8
승인 대기 — 자동승인 vs 심의승인 대기
API마다 자동/심의 여부가 다르고 기준이 사전에 기계가독으로 공개되지 않습니다. 심의는 수 시간~수 일.
9
serviceKey 발급 확인 자동화 가능
단, 키 조회도 화면 로그인 후에만 가능 — 키 발급·회전(rotation)용 API가 없습니다.
10
키 활성화 대기 대기
발급 직후 일정 시간 동안 인증 실패가 정상 동작인 경우가 있어, 에이전트는 "키가 잘못된 것인지 아직 안 열린 것인지" 구분할 수 없습니다.
11
첫 호출·시행착오 자동화 가능 (비용 큼)
URL 인코딩된 키 이중 인코딩 문제, XML 기본 응답, 표준화되지 않은 에러 포맷 등으로 재시도 루프가 발생 — 호출당 시행착오 토큰이 추가됩니다.
12
쿼터 관리 (개발계정 일일 한도) 부분 가능
사용량 조회·증량 신청 모두 화면 전용. 표준 RateLimit 헤더가 없어 에이전트는 한도 초과를 사후에야 알게 됩니다.
13
운영계정 전환 신청 (상용화 시) 인간 필요
별도 심사·서류가 필요한 인간 중심 절차입니다. 장애 시 문의도 전화·게시판 등 인간 채널을 전제합니다.

3. 토큰 비용 실측 — 에이전트에게 이 여정은 얼마인가

2026-08-04에 여정의 실제 페이지들을 그대로 받아(curl) 크기를 측정하고 토큰으로 환산했습니다. 원문은 measurements.json과 evidence/journey/의 HTML 스냅샷으로 공개합니다.

페이지 (여정 단계)	실측 크기	원문 HTML 토큰≈	가시 텍스트 토큰≈	비고
data.go.kr 메인 (단계 1)	169 KB	48,300	1,265	가시 정보율 ≈2.6%
data.go.kr 검색 결과 (단계 1~2)	465 KB	132,810	4,249	JS 렌더 필요 · 가시 정보율 ≈3.2%
data.go.kr API 상세 (단계 3)	203 KB	57,998	2,872	스펙 본문은 HWP/DOCX 첨부인 경우 다수
data.go.kr 로그인·회원가입 (단계 4~5)	14 + 21 KB	10,145	449	이후 본인인증에서 자동화 중단
🇺🇸 api.data.gov 메인 + 키 신청 폼	14 + 12 KB	7,317	833	폼 1개 제출로 통합 키 즉시 발급
🇸🇬 data.gov.sg 카탈로그 API 응답	5.8 KB	1,647	—	무로그인 · 순수 JSON
🇫🇷 data.gouv.fr 전체 API 스펙 (swagger.json)	238 KB	67,993	—	기계가독 스펙 — 1회 취득 후 캐시 가능

3-1. 브라우저 실측 검증 (2026-08-04, 실제 접속)

curl 기반 추정을 검증하기 위해 실제 브라우저 자동화로 여정 앞 구간을 직접 밟으며 전체 리소스 전송량·요청 수·소요 시간·클릭 액션 수를 측정했습니다 (원자료).

단계 (실제 수행)	HTTP 요청	전체 전송량	DOM 노드	소요 시간
메인 페이지 로드	81건	4.97 MB	897	로드 2.3초
검색 실행 → AI 검색 결과	+45건	+3.15 MB	1,211	AI 답변 생성 27.3초
검색까지 실제 액션 수: 4회 (공지 팝업 닫기 → 검색창 클릭 → 키워드 입력 → Enter). 첫 방문 시 공지 팝업이 입력을 가로채 액션 1회가 추가로 강제됨을 확인.

curl 추정이 하한이었음이 확인됐습니다. 메인 페이지의 원문 HTML은 169KB지만 실제 브라우저가 받는 전체 리소스는 4.97MB(요청 81건) — 약 30배입니다. 스크린샷 기반(비전) 에이전트든 DOM 기반 에이전트든, 페이지당 실제 다운로드 비용은 추정치보다 큽니다.
새 발견 — AI 대화형 검색 시범 운영 (2026-08-03 개시). 검색창 입력이 aiAssistant.do로 라우팅되어, 파일데이터/오픈API를 구분해 분석 정보·추천 이유와 함께 제시합니다. 사람의 발견(단계 1~2) 경험은 눈에 띄게 개선됐습니다. 다만 (1) 답변 생성에 27.3초가 걸리고, (2) 채팅 UI 전용이라 에이전트가 쓸 표준 검색 API·스펙은 여전히 공개되지 않았으며, (3) 같은 공지에서 "인증서·정부통합인증 로그인 안정화 작업 중"을 안내 — 인가 구간의 하드 블록은 그대로입니다.
API 상세·활용신청·로그인 이후 구간은 실측 중 브라우저 세션이 종료되어 이번 라운드에서는 HTML 스냅샷 실측(상세 203KB)으로 대체했고, 활용신청은 계정 상태를 바꾸는 행위라 제출 직전까지만 검증하는 것을 원칙으로 합니다.

여정 전체로 환산하면

시나리오 B(20+ 액션)를 에이전트가 브라우저 자동화로 완주한다고 가정하면:

원문 HTML을 읽으며 진행: 액션당 평균 4만~6만 토큰 × 20+ 액션 + 재시도 ≈ 80만~120만 토큰. 대형 모델 컨텍스트(20만 토큰)를 여러 번 갈아끼워야 하는 규모입니다.
접근성 트리·텍스트 추출 최적화 시: 액션당 1.5천~4천 토큰 ≈ 3만~8만 토큰. 그래도 본인인증(단계 5)에서 인간에게 제어를 넘겨야 하므로 "무인 완주"는 불가능합니다.
시나리오 D(10개 API): 위 비용 × 10 — 최적화해도 수십만 토큰 + 인간 개입 10회+.

🇸🇬 data.gov.sg≈2천

🇺🇸 api.data.gov≈5천~1만

🇫🇷 data.gouv.fr (MCP)≈1만

🇰🇷 data.go.kr (최적화)3만~8만

🇰🇷 data.go.kr (원문 HTML)80만~120만

결론적으로 첫 데이터 획득까지의 에이전트 비용은 해외 선도 포털 대비 최소 수십 배, 비최적화 시 수백 배입니다. 게다가 이 비용을 다 치러도 인간 개입 없이는 끝나지 않습니다.

4. 왜 이렇게 되었나 — 여섯 가지 구조적 장벽

절차가 긴 것은 표면이고, 원인은 포털이 인간 방문자만을 전제로 설계되었기 때문입니다.

#	장벽	내용	에이전트에 미치는 영향
1	인간 중심 계정 체계	자격증명이 개인에게 귀속. 서비스·조직·에이전트 계정 없음	위임·자동 갱신 불가, 본인인증 하드 블록
2	관리 API 부재	활용신청·키 발급·쿼터 증량을 위한 표준 엔드포인트 없음	모든 절차를 화면 스크래핑으로 대행 → 토큰 폭증·취약
3	승인 정책 비일관	API마다 자동승인/심의 기준이 다르고 비공개	결과 예측 불가 → 계획 수립 불가
4	문서 포맷 파편화	스펙이 HWP·DOCX·HTML·일부만 Swagger로 혼재	스펙 파싱 실패 → 시행착오 호출로 비용 전가
5	서비스 보증 불안정	제공기관 백엔드 장애가 포털 통제 밖에서 발생	표준 상태 정보 없이는 자동 복구 판단 불가
6	인간 의존 에스컬레이션	장애·문의 채널이 전화·게시판 전제	무인 운영의 마지막 고리가 끊김

자동화 가능성 종합 평가

키 취득 후 운영 구간70~90%

발견 → 인가 구간30~50%

상용 배포 전 과정20~40%

완전 자율 (무인)사실상 0

즉, 병목은 데이터 호출부가 아니라 "발견 → 계약 → 인가"라는 중간 구간입니다. 이 구간을 처리할 인프라가 현재 비어 있습니다.

5. 해외는 어떻게 하고 있나

🇺🇸 미국 — api.data.gov (GSA)

이메일 폼 1개 제출로 즉시 발급되는 단일 API 키로 수백 개 연방 API를 호출. 표준 rate limit(기본 시간당 1,000회)과 표준 에러 포맷을 게이트웨이가 일괄 제공.

GovInfo는 정부 공식 MCP 서버를 공개해 에이전트가 도구 호출로 바로 접근.

교훈: "우산형 게이트웨이 + 통합 키"가 신청 절차 자체를 1단계로 압축한다.

🇫🇷 프랑스 — data.gouv.fr

카탈로그 전체가 swagger.json으로 기계가독 공개, 대부분의 조회는 키 없이 호출 가능. 4만여 데이터셋을 다루는 정부 공식 MCP 서버(datagouv-mcp)를 운영.

교훈: 스펙의 기계가독화 + 공식 MCP만으로 에이전트 여정이 "스펙 1회 취득 → 즉시 호출"로 줄어든다.

🇸🇬 싱가포르 — data.gov.sg

실시간 API 다수가 무인증·무신청. 응답은 순수 JSON(카탈로그 조회 실측 5.8KB). 개발자 문서가 곧 스펙.

교훈: 저위험 공공데이터는 신청 절차 자체를 없애는 것이 최선의 최적화다.

🇬🇧 영국 — GDS API 표준 + api.gov.uk

전 부처에 OpenAPI 스펙 공개·버저닝·OAuth 2.0 등 공통 API 기술표준을 의무화하고 api.gov.uk에 카탈로그를 집약.

교훈: 포털 개선이 아니라 "표준 강제"가 기관 간 편차(승인·문서 파편화)를 없앤다.

🇪🇺 EU — data.europa.eu

27개국 카탈로그를 DCAT-AP 표준 메타데이터로 연합(federation)하고 SPARQL·REST로 기계 탐색 제공. High-Value Datasets는 API 제공을 법으로 의무화.

교훈: 메타데이터 표준화가 되면 "발견" 단계는 에이전트에게 공짜가 된다.

공통 트렌드 (2025~2026)

① 정부 공식 MCP 서버(프랑스·미국 GovInfo 등) ② OpenAPI-first 의무화 ③ llms.txt·기계가독 약관 실험 ④ 샌드박스 공용 키.

방향은 하나: "사람이 읽는 포털"에서 "기계가 계약하는 플랫폼"으로.

6. 개선 제안 — Agent Access Layer

필요한 것은 화면 개편이 아니라, 데이터 발견과 API 호출 사이의 비어 있는 구간(인가·계약·운영관리)을 담당할 에이전트 접근 계층(Agent Access Layer)입니다. 6개 층위로 제안합니다.

층위	제안	해소되는 장벽	해외 선례
L1 계정 체계	조직·서비스·에이전트 계정 유형 신설, 인간 관리자가 권한을 위임하는 구조 (본인인증은 위임 시점 1회로 집약)	#1 인간 중심 계정	OAuth 2.0 client credentials 관행
L2 관리 API	활용신청·키 발급/회전·쿼터 조회/증량용 표준 API (OAuth 2.0 scope 기반)	#2 관리 API 부재	api.data.gov 셀프서비스 키
L3 스펙 표준화	OpenAPI Specification·JSON Schema·DCAT 메타데이터·RFC 7807 에러 모델을 전 제공기관에 의무화	#4 문서 파편화, #5 보증	영국 GDS 표준, EU DCAT-AP
L4 패키지 인가	관련 API 묶음(예: "여행 패키지")을 단일 계약으로 일괄 승인 — 60~100 액션을 1회 신청으로	시나리오 D 조합 비용	api.data.gov 통합 키
L5 공용 샌드박스	신청 없이 쓰는 저쿼터 공용 시험 키 — "먼저 써보고 나중에 계약"	#3 승인 예측 불가	싱가포르 무인증 API
L6 자동 승인	저위험 API는 기준(개인정보 무관·출처표시·쿼터 준수) 충족 시 기계 판정으로 즉시 승인	#3 승인 비일관	프랑스 무키 조회 API

단계적 로드맵

단기 (6개월) — L5 공용 샌드박스 키 + 인기 상위 API부터 OpenAPI 스펙 병행 게시 + 정부 공식 MCP 서버 파일럿(프랑스 datagouv-mcp 모델). 기존 시스템 개조 없이 게이트웨이 앞단에서 가능한 것들입니다.
중기 (6~18개월) — L2 관리 API와 L6 자동 승인 도입, RFC 7807 에러·RateLimit 헤더 표준화(가이드라인 기둥 1·5와 동일 방향).
장기 (18개월+) — L1 에이전트 계정 체계와 L4 패키지 인가. 법·제도(전자서명·본인확인 제도) 정비가 함께 필요한 영역입니다.

이 여섯 층위 중 어느 하나만 도입해도 여정이 눈에 띄게 줄어듭니다. 예컨대 L5(샌드박스 키) 하나만으로 시나리오 B의 앞 10단계가 "스펙 읽기 → 즉시 시험 호출" 2단계로 압축되고, 에이전트 토큰 비용은 실측 기준 수만 토큰에서 수천 토큰 수준으로 내려갑니다.