"근데 API 그거, 이미 있다고 하지 않았어요?"
회의실에서 자주 나오는 두 번째 질문입니다. 누군가 "공공데이터포털에 있던데", "그 회사도 API 연다고 발표했던데"라고 말합니다. 맞는 말입니다. 시중에 API는 이미 많습니다. 그런데 막상 가져다 쓰려고 하면, 한 화면에 보여줄 수 있는 모양이 안 나옵니다.
"API가 없어서" 막히는 회사보다, "여러 API를 합쳐줄 사람이 없어서" 막히는 회사가 훨씬 많습니다.
시중에 API는 이미 많습니다
공공 영역만 봐도 공공데이터포털, 도로공사, 기상청, 국세청, 통계청에 이르기까지 수천 개의 API가 공개돼 있습니다. 상용 영역에는 네이버·카카오·구글 같은 플랫폼 API와 금융권의 오픈뱅킹·간편결제 API가 있고, AI 영역에서는 검증된 클라우드 모델·OCR 엔진의 API가 거의 모든 회사에 열려 있습니다.
회사 입장에서 "API가 부족해서 못 한다"는 상황은 사실 드뭅니다. 더 흔한 상황은 그 많은 API를 회사 안에서 의미 있는 한 가지 응답으로 묶어줄 사람이 없다는 쪽입니다.
그런데 그대로 가져다 쓰면 잘 안 됩니다
각각의 API는 그 자체로는 잘 동작합니다. 문제는 조합입니다.
- 응답 형식이 제각각입니다. 어떤 곳은 JSON, 어떤 곳은 XML, 사내 시스템은 SOAP. 같은 JSON이라도 키 이름과 중첩 구조가 다릅니다.
- 인증 방식이 제각각입니다. API Key, Bearer 토큰, OAuth, 서비스키, IP 화이트리스트. 한 화면을 만들려고 다섯 가지 인증을 동시에 관리해야 하는 상황이 생깁니다.
- rate limit·장애·버전 변경에 회사 코드가 직접 노출됩니다. 외부 API 한 곳이 1분 다운되면 자체 서비스 화면도 같이 비어 보입니다.
- 한 화면에 의미 있는 응답을 만들려면, 보통 2~5개의 API와 사내 데이터를 합쳐야 합니다. 합치는 코드가 클라이언트 쪽에 흩어지면 다음 변경이 그만큼 어려워집니다.
한 화면을 만들어 본다고 가정해 봅시다
자체 앱 화면에 카드 하나를 새로 만든다고 가정해 보겠습니다. 고객이 등록한 매장 주소를 기준으로 날씨, 도로 정체, 주변 시세, 경쟁사 위치를 한 번에 보여주는 카드입니다.
내부에서 호출해야 하는 데이터를 정리하면 다음과 같습니다.
| 데이터 | 출처 | 형식 / 인증 |
|---|---|---|
| 매장 좌표 | 사내 DB | 사내 인증 |
| 실시간 날씨 | 기상청 API | XML / 서비스키 |
| 도로 정체 | 도로공사 API | JSON / API Key |
| 주변 시세 | 공공데이터포털 부동산 | JSON / 서비스키 |
| 경쟁사 위치 | 상용 지도 API | JSON / OAuth |
이 다섯 곳에서 받은 응답을 한 가지 형식으로 합쳐서, 자체 앱 클라이언트가 호출 한 번으로 받게 만들어야 합니다.
합치는 일을 자체 앱이 다 한다면
자체 앱이 다섯 개의 외부 API를 직접 호출하는 구조입니다.
자체 앱 코드 한쪽에 다섯 가지 인증·다섯 가지 응답 파싱·다섯 가지 장애 처리가 모입니다. 외부 한 곳의 응답 구조가 바뀌면 자체 앱을 수정·재배포해야 합니다.
사이에 한 계층을 두면
자체 앱은 시온랩 API Market 한 곳만 호출합니다. 다섯 개의 외부·내부 소스는 시온랩 쪽 어댑터가 병렬로 호출하고, 결과를 표준 envelope으로 합쳐 돌려줍니다.
자체 앱 입장에서는 한 가지 인증, 한 가지 응답 형식, 한 가지 장애 응답만 다루면 됩니다. 외부 API 한 곳이 바뀌어도 시온랩 쪽 어댑터만 수정합니다.
사이에 들어간 계층이 실제로 하는 일
하는 일은 크게 세 가지입니다.
- 형식 통일. 외부의 XML·SOAP·이질 JSON을 표준 envelope(
status,data,error,meta)으로 변환합니다. 자체 앱 코드는 같은 모양만 다룹니다. - 인증·키 관리. 다섯 가지 인증 방식을 한 개의 시온랩 API 키 뒤에 숨깁니다. 외부 키 회전, 만료, 추가 발급은 시온랩 쪽에서 처리합니다.
- 장애·버전 흡수. 외부 한 곳이 다운되거나 응답 구조가 바뀌어도 자체 앱은 영향받지 않습니다.
error.partial같은 부분 응답으로 어디까지 받아왔는지 표준화된 형태로 알립니다.
그럼 이게 그냥 게이트웨이 아닌가
비슷한 자리이지만, 시온랩 API Market은 일반 게이트웨이에서 한 걸음 더 나갑니다.
- 일반 API 게이트웨이는 트래픽 라우팅, 인증, rate limit 관리에 무게가 있습니다. 기술 컴포넌트입니다.
- 시온랩 API Market은 같은 작업을 처리하면서 위에 한 층을 더 얹습니다. 상품 단위 카탈로그로 묶어 비즈니스 응답을 조합 후 전달하고, 호출량 정산도 상품 기준으로 분리합니다.
- 즉 외부에서 보면 "기술 인프라"가 아니라 "비즈니스 단위로 패키징된 데이터 카탈로그"입니다.
어떤 회사에 이 구조가 맞는가
- 외부 데이터(공공·상용·파트너) 의존도가 높은 회사
- 자체 앱·파트너 시스템·자회사용 도구 등 호출처가 다수인 회사
- 외부 API 장애가 자체 서비스 장애로 직결되는 구조를 끊어내고 싶은 회사
다시 한 번 정리하면
API는 이미 많습니다. 시온랩이 더하는 가치는 새 API를 만드는 일이 아니라, 이미 있는 여러 API와 사내 데이터를 회사가 부를 단일 형식으로 전달하는 일입니다.
- API Market 개요: /api
- 상품 카탈로그: /api/market
