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

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

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

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

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

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

정규화(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개 프로바이더) 기준이며, 프로바이더·구성에 따라 달라진다. 키·내부 엔드포인트는 공개하지 않는다. 정확한 지연·비용은 내 트래픽으로 직접 측정하라. 분기별 갱신.