공공데이터부터 오픈뱅킹까지, Open API가 여는 생태계
서비스·데이터 인터페이스를 외부에 공개해 신규 서비스를 유도하는 Open API 전략을 정리한다. REST·SOAP·XML-RPC 프로토콜 선택, 인증·버전 관리, 공공데이터·오픈뱅킹·물류 활용 사례를 다룬다.
2026-08-12 · 최초 발행 2025-11-26
교통·기상·인구 데이터를 정부가 직접 서비스로 만드는 대신 API로 열어두면, 그 데이터를 조합해 새 서비스를 만드는 건 민간의 몫이 된다. Open API(공개 API)는 서비스·정보·데이터 인터페이스를 공개해 제3자가 접근하고 개발할 수 있게 하는 정책·기술 집합이다. 목적은 재사용 촉진, 파트너 생태계 확장, 사용자 중심 비즈니스 모델 구현이다. 이 흐름을 문서화·자동화 수준에서 뒷받침하는 것이 OpenAPI Specification(OAS)이며, RESTful API를 YAML/JSON으로 기계가 읽을 수 있게 기술해 Swagger 같은 도구군과 결합한다.
포털·공공기관의 데이터가 Open API를 거쳐 신규·복합 서비스로 이어지고, 그 서비스를 기업이 다시 재활용하거나 사용자가 이용하는 순환 구조다.
REST냐 SOAP이냐, 무엇으로 열 것인가
인터페이스 기본 기술로는 REST, SOAP, XML-RPC 세 갈래가 있다. REST는 URI와 HTTP 메서드로 리소스를 조작하는 무상태(stateless) 아키텍처로 JSON·XML 등 다양한 포맷을 전송한다. SOAP은 HTTP/HTTPS/SMTP 등에서 XML 기반 메시지를 교환하는 프로토콜로 엄격한 스키마와 WS-* 확장을 지원한다. XML-RPC는 XML로 원격 프로시저를 호출하는 경량 프로토콜로, 단순하지만 확장 기능이 제한적이다.
| 구분 | REST | SOAP | XML-RPC |
|---|---|---|---|
| 성능 | 경량 JSON, 무상태로 고성능 달성 용이 | XML·헤더 오버헤드로 상대적 무거움 | 경량이나 기능 제한 |
| 확장성 | 하이퍼미디어·확장 헤더로 유연 | WS-*로 표준화된 확장 풍부 | 확장성 낮음 |
| 일관성 | 베스트 프랙티스 의존, 규약 중요 | 스키마·계약 중심으로 강한 일관성 | 단순 호출 중심 |
| 안정성 | 무상태, 캐시·재시도 용이 | 트랜잭션/보안 등 표준 지원 | 최소 기능, 예외 처리 제한 |
| 운영 편의 | 도구·에코시스템 풍부 | 초기 설정·학습 비용 큼 | 단순하나 장기 유지관리 한계 |
실무에서는 REST를 우선 설계하고 필요할 때만 SOAP이나 XML-RPC를 선택하는 방식이 일반적이다. 메시지 포맷은 JSON Schema나 XSD로 표준화하고, 상태코드와 에러 코드로 일관된 응답 규약을 세운다.
공개할수록 더 지켜야 할 것들
인증·인가는 API Key, OAuth 2.0/OIDC, mTLS를 계층별로 선택한다. 공개 데이터에는 무인증에 레이트 리미팅만 걸고, 민감 데이터에는 강한 인가를 적용한다. 토큰 스코프는 최소화하고, 만료·회전 주기를 관리하며, 서명(JWS)이나 암호화(JWE)를 적용한다.
버전 관리와 수명주기는 명시적 버전(v1, v2)과 호환성 정책을 채택하고, 제거 예정(deprecation) 공지와 이행 기간을 제공한다. 설계→개발→샌드박스→운영→관찰→개선을 반복하는 라이프사이클로 운영한다.
문서화·발견은 OAS로 단일 소스 문서를 만들고 Swagger UI나 Redoc 포털을 제공한다. 예제·스키마·에러 사례를 포함하고, SDK·클라이언트 스텁을 자동 생성하며 샌드박스·Try-it 콘솔을 붙인다.
운영·거버넌스는 API 게이트웨이로 인증, 레이트 리미팅, 캐시, 로깅, 변환 정책을 일원화한다. SLA·Quota, 모니터링(SLI/SLO), 비용·청구 메커니즘도 함께 도입한다.
실제로 어디에 쓰이는가
공공데이터 포털은 교통·기상·인구 데이터를 REST로 공개하고 일 단위 호출한도를 설정한다. 민간 모빌리티·여행 서비스가 이 데이터를 결합해 신규 상품을 만든다.
금융·오픈뱅킹은 OAuth 2.0에 FAPI를 보강하고 JWS 서명으로 결제·조회의 안전성을 확보한다. 샌드박스 → 인증 → 프로덕션 순서로 게이트를 통과시킨다.
커머스·물류는 주문·배송·재고 API로 파트너 온보딩을 자동화하고 웹훅으로 상태 변경을 알린다. SKU·주문 이벤트 규격을 통일해 서드파티 확장을 가속한다.
스마트시티·IoT는 센서 데이터 스트리밍 API와 히스토리 조회를 조합하고, 캐시·TTL로 비용을 최적화한다. 멀티테넌시와 테넌트 격리, 쿼터 정책을 함께 적용한다.
요청 하나가 처리되는 과정
입력은 URI, 메서드, 헤더(인증·추적), 바디(JSON/XML), 쿼리 파라미터다. 처리는 인증·인가 검증 → 스키마 검증 → 비즈니스 로직 → 외부 연동 → 응답 생성 순서로 진행한다. 출력은 상태코드, 표준 에러 구조(code, message, details), 추적 ID, 캐시 지시자로 구성한다.
인증 실패는 401/403과 함께 명확한 에러 코드와 재시도 지침을 반환한다. 유효성 오류는 400과 함께 필드 단위 오류 목록을 반환한다. 일시 장애는 429/503과 Retry-After 헤더, 지수 백오프 권고로 대응한다. 멱등성은 POST의 Idempotency-Key와 PUT/PATCH 설계로 보장한다.
코드로 보면 이렇다
환경은 macOS/Linux, curl 7.68+, Python 3.10+, requests 2.31+를 전제로 한다.
REST로 공개 데이터를 조회할 때는 다음과 같다.
curl -s -G "https://api.example.com/v1/weather" \
--data-urlencode "city=Seoul" \
-H "Accept: application/json" \
-H "X-API-Key: $API_KEY"
# pip install requests==2.31.0
import requests
r = requests.get(
"https://api.example.com/v1/weather",
params={"city": "Seoul"},
headers={"X-API-Key": "YOUR_KEY", "Accept": "application/json"},
timeout=5,
)
r.raise_for_status()
print(r.json())
SOAP으로 간단히 조회할 때는 XML 바디를 구성해 보낸다.
curl -s https://soap.example.com/Service.svc \
-H "Content-Type: text/xml; charset=utf-8" \
-H "SOAPAction: \"urn:GetCustomer\"" \
-d '<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:urn="urn:example">
<soapenv:Header/>
<soapenv:Body>
<urn:GetCustomer><urn:id>123</urn:id></urn:GetCustomer>
</soapenv:Body>
</soapenv:Envelope>'
설계할 때 남는 트레이드오프
인증·인가는 공개 데이터에 키 기반과 쿼터를, 민감 데이터에는 OAuth 2.0/OIDC와 mTLS를 권장한다. 키 단순성과 토큰 보안성 사이의 트레이드오프다. 데이터 보호는 전구간 TLS, PII 마스킹·필드 레벨 암호화, 로그의 민감정보 제거로 이뤄지지만 보안 강화는 운영 복잡성 증가로 이어진다. 트래픽 제어는 레이트 리미팅, 버스트 제어, 동적 쿼터로 사용자 경험과 인프라 보호 사이의 균형을 잡는다. 일관성은 새 필드를 optional로 추가하고 제거는 주요 버전에서만 하는 스키마 진화 전략으로 개발 속도와 하위 호환성을 절충한다. 아키텍처는 API 게이트웨이를 중심으로 정책화하고 내부는 서비스 메시로 세분 제어하되, 단일 진입점의 안정성과 단일 장애점 위험 사이에서 다중 AZ·리전으로 보완한다. 운영은 분산 추적(TraceID), SLI/SLO 정의, 에러 버짓 기반 릴리즈로 관찰성을 강화하는 대신 비용이 늘어난다.
열어두면 얼마나 달라지나
표준화·자동화를 기반으로 개발 기간이 3050% 단축되고, 파트너 온보딩 비용은 2040% 절감된다. 타임 투 마켓이 빨라지고 신규 파트너 수는 2~3배까지 늘어날 가능성이 있다. 가용성·품질 지표는 성공률 99.9%를 목표로 하고 MTTR은 50% 감소하며 장애 범위도 줄어드는 것으로 나타난다. 데이터 재활용이 늘면서 신규·복합 서비스가 다양해지고 사용자 만족도와 전환율도 함께 오른다.
REST 중심 설계에 인증·거버넌스·관찰성을 결합하고, 표준화된 수명주기를 적용하는 것이 실무의 기본 틀이다. 공공·포털 데이터에서 민간 서비스까지 단계적으로 열어가며 생태계와 수익 모델을 함께 확장하는 접근이 현실적이다.