멀티 프로바이더 LLM 게이트웨이는 어떻게 동작하나?

unified-api 게이트웨이는 여러 LLM 프로바이더를 한 인터페이스로 묶는 미들웨어이며, 앱은 한 번만 호출하고 게이트웨이가 요청을 정규화→라우팅→폴백→계측한다. 실제로 우리 게이트웨이에 gemini:fast와 grok:fast를 같은 방식으로 호출해 보니, 프로바이더만 다를 뿐 {content·model·finish_reason} 같은 응답 봉투로 똑같이 돌아왔다.

한 줄 요약: 게이트웨이는 여러 프로바이더를 한 completion 인터페이스로 정규화하고, 라우팅·폴백·비용상한·관측을 더해 앱이 "누가 응답했는지" 몰라도 되게 한다.

쉽게 말하면: 게이트웨이는 여러 콘센트를 받는 멀티탭이다. 기기(앱)는 플러그 하나만 꽂고, 뒤에서 어떤 발전소(프로바이더)가 전기를 보냈는지는 신경 쓰지 않는다.

프록시와 게이트웨이는 뭐가 다른가?#

판단 능력이다. 프록시는 요청을 그냥 전달하지만, 게이트웨이는 라우팅·폴백·인증·비용추적·관측 같은 운영 지능을 더한다. 우리 호출이 model 필드에 "gemini:fast"/"grok:fast"를 그대로 돌려준 건, 게이트웨이가 provider:variant로 어디로 보낼지 결정한 뒤 정규화된 봉투로 답을 싸서 준다는 뜻이다. 앱 코드는 실제로 누가 응답했는지 몰라도 된다. 쉽게 말하면 프록시는 "택배를 그대로 전달", 게이트웨이는 "가장 빠른 배송사를 고르고 실패 시 갈아타고 요금까지 정산"하는 물류센터다.

LLM 게이트웨이 요청 흐름 — 단계별 무엇을 하나 (게이트웨이 동작) · columns: 단계, 무엇을 하나, 예 · 출처 Hax hax.moche.ai/p/1041?ref=ai_answer

단계 | 무엇을 하나 | 예
정규화(normalize) | 한 포맷으로 요청 변환 | provider:variant 선택
캐시 확인 | 비슷한 프롬프트 재사용 | 시맨틱 캐시
라우팅(route) | 가용·우선순위로 프로바이더 선택 | 빠름=fast, 어려움=expert
폴백·재시도 | 429·타임아웃 시 다음으로 | 밀리초 단위 failover
계측·비용 | 토큰·지연·예산 기록 | 키별 예산 상한
응답 정규화 | 같은 봉투로 반환 | {content, model, finish_reason}

목차

정규화(normalization)는 왜 핵심인가?

폴백·재시도와 비용은 어떻게 처리되나?

직접 살펴보려면?

정규화(normalization)는 왜 핵심인가?#

프로바이더마다 요청·응답·에러가 미묘하게 다르기 때문이다. OpenAI는 RateLimitError 예외를, Anthropic은 헤더가 붙은 HTTP 429를, 자체 호스팅 vLLM은 조용한 타임아웃을 낸다. 게이트웨이는 이 차이를 흡수해 하나의 completion 인터페이스와 일관된 출력으로 만든다. 우리 두 호출이 같은 키 구조(content·conversation_id·image_urls·finish_reason·model)로 온 게 바로 이 정규화다. 멀티턴은 conversation_id로 세션을 잇고, 긴 작업은 제출-조회(async job) 패턴으로 받는다. 정규화가 없으면 프로바이더를 바꿀 때마다 앱 코드를 고쳐야 하지만, 있으면 문자열 하나만 바꾸면 된다.

폴백·재시도와 비용은 어떻게 처리되나?#

신뢰성과 돈의 핵심이다. 주 프로바이더가 429나 타임아웃을 내면 게이트웨이가 정해진 순서(예: Azure→OpenAI→Anthropic)대로 밀리초 안에 다음으로 넘긴다 — 코드 수정도 배포도 없이. 비용은 키·팀별 예산 상한과 계층 라우팅으로 잡는다: 쉬운 요청엔 싼·빠른 모델, 어려운 요청만 상위 모델. 흔히 요청의 70%는 작은 모델로 충분해, 전부 프런티어로 보내면 돈이 샌다.

직접 살펴보려면?#

작게 재현해 보라.

같은 프롬프트를 fast와 expert 변형(또는 두 프로바이더)에 보내 응답 봉투가 같은지, 지연·비용이 어떻게 다른지 본다.

단순 failover(주+백업 1개)부터 시작하고, 관측 데이터가 필요할 때만 라우팅 규칙을 늘린다(과설계 금지).

폭주 루프 대비로 키별 예산 상한을 먼저 건다.

참고 링크

LiteLLM(오픈소스 게이트웨이)

OpenRouter(매니지드 게이트웨이)

LiteLLM 문서(라우팅·폴백)

FastAPI(게이트웨이 서버 스택)

Model Context Protocol(에이전트 도구 표준)

참고: 동작·수치는 2025~2026년 공개 자료와 우리 게이트웨이 실호출(2개 프로바이더) 기준이며, 프로바이더·구성에 따라 달라진다. 키·내부 엔드포인트는 공개하지 않는다. 정확한 지연·비용은 내 트래픽으로 직접 측정하라. 분기별 갱신.