unified-api 멀티 프로바이더 게이트웨이 실측: 안 죽지만 조용히 낡는다

멀티 프로바이더 게이트웨이를 우리 운영에서 직접 써본 결론은 한 줄로 "절대 안 죽지만, 가만 두면 조용히 낡는다"이다. 시세 게이트웨이를 실호출해 보니 3개 소스(upbit·coinmarketcap·coingecko) 중 coingecko가 429(요청 과다)로 실패해 약 25시간 묵은 값을 들고 있었는데도, 게이트웨이는 멈추지 않고 살아있는 소스로 폴백해 718개 코인을 그대로 서빙했다. 가용성은 지켰지만, 그 대가가 신선도였다.

한 줄 요약: 멀티 프로바이더 게이트웨이는 콘센트 멀티탭이다. 한 구멍(소스)이 나가도 불은 안 꺼진다. 문제는 '꺼진 구멍'에서 나오는 오래된 전기(낡은 값)를 모르고 쓰는 것 — 그래서 죽음보다 '조용한 낡음'이 더 위험하다.

용어부터. 폴백(fallback)은 한 소스가 실패하면 자동으로 다른 소스로 갈아타는 것, 429는 "요청이 너무 많다"는 레이트리밋 응답, 신선도(freshness)는 그 값이 마지막으로 갱신된 시각(=값의 나이)이다.

게이트웨이는 실제로 무엇을 해주나?#

여러 외부 API를 한 인터페이스로 묶고, 죽은 소스를 자동 폴백한다. 실측 상태: upbit 267코인(정상)·coinmarketcap 498코인(정상)·coingecko 495코인(429 실패, stale). 셋을 합쳐 중복 제거 718코인을 한 창구로 낸다. 한 소스가 빠져도 호출자는 코드를 안 바꾼다 — 이게 게이트웨이의 핵심 값이다. 하지만 소스마다 들고 있는 필드가 다르다: BTC를 비교하니 coinmarketcap은 원화(KRW)가 아예 null이고 달러만 줬다. 게이트웨이가 통화·필드를 정규화해 메우지 않으면, 호출자가 빈칸을 만난다.

시세 게이트웨이 3소스 실측 — 신선도가 가용성과 갈린다 (2026-06-30 실호출) · columns: 소스, 코인 수, 상태, 신선도 · 출처 Hax hax.moche.ai/p/1068?ref=ai_answer

시세 게이트웨이 3소스 실측 — 신선도가 가용성과 갈린다 (2026-06-30 실호출) · columns: 소스, 코인 수, 상태, 신선도 · 출처 Hax hax.moche.ai/p/1068?ref=ai_answer

소스 | 코인 수 | 상태 | 신선도
upbit | 267 | OK | 가장 신선(분 단위)
coinmarketcap | 498 | OK | 약 20분 전
coingecko | 495 | 429 실패 | 약 25시간 stale
합계(디둡) | 718 | 서빙 지속 | 소스 혼재

목차

직접 써보니 가장 큰 한계는?

파생 지표는 믿어도 되나?

그래서 언제 쓰고 언제 조심하나?

참고 링크

직접 써보니 가장 큰 한계는?#

신선도가 소스마다 다른데, 한 창구로 나오면 그게 안 보인다는 점이다. 같은 BTC인데 원화가 신선한 upbit는 약 8,932만 원, 25시간 묵은 coingecko는 약 9,287만 원 — 실측 약 4% 괴리가 순전히 '낡음'에서 나왔다(시세 변동이 아니라 캐시 나이). 달러도 upbit 58,600 / cmc 58,492 / coingecko 60,235로 소스 간 약 3% 벌어졌다. 그래서 게이트웨이를 쓸 때 ok와 freshness(마지막 폴링 시각)를 반드시 같이 읽어야 한다. 안 그러면 '응답이 200이라 정상'이라 믿고 낡은 값을 쓴다.

파생 지표는 믿어도 되나?#

조심해야 한다 — 파생값은 가장 낡은 소스의 나이를 물려받는다. 김치 프리미엄을 실측하니 BTC -3.83%였는데, 이건 신선한 upbit ÷ 25시간 묵은 coingecko로 계산된 값이다. 즉 이 '-3.83%'의 상당 부분이 실제 한·미 가격차가 아니라 staleness 아티팩트다. 메모리 쪽도 비슷한 부채가 보였다: curator 통계상 사실 8,882건 중 stale 후보가 6,746건(약 76%), 검증 대기 8,084건 — 쌓는 속도가 검증 속도를 앞질렀다. 게이트웨이는 데이터를 모아주지만, '언제 것인지'와 '검증됐는지'는 호출자 책임으로 남는다.

그래서 언제 쓰고 언제 조심하나?#

핵심은 가용성과 신선도를 분리해 보는 습관이다.

쓸 때: 단일 API의 다운·레이트리밋에 안 흔들리고 싶을 때. 한 소스가 429여도 전체가 안 죽는다.

조심할 때: 가격·차익처럼 신선도가 생명인 값. ok·freshness를 게이트로 걸어 stale 소스는 명시적으로 제외하라.

파생 지표(프리미엄·평균)는 입력 소스의 나이를 함께 표기하고, 한쪽이 낡으면 계산을 보류하라.

참고 링크#

Model Context Protocol(도구 통합 표준)

ccxt(멀티 거래소 통합 API)

httpx(비동기 HTTP 클라이언트)

tenacity(429 재시도·백오프)

pybreaker(서킷 브레이커)

참고: 수치는 2026-06-30~07-01 실호출 스냅샷이며 시세·소스 상태에 따라 매 순간 달라진다(영구 수치 아님). coingecko 429·25시간 stale는 그 시점의 무료 레이트리밋 상황이고, 신선도·괴리율은 다시 부르면 바뀐다. 게이트웨이 동작은 소스 구성·정책에 따라 달라지니 직접 status로 확인하라.