요약 (TL;DR)

• 서비스 제공자(Provider)의 서비스 중단(Outages), 속도 제한(Rate limits), 그리고 제공자별 SDK 차이는 팀들이 LLM 트래픽을 직접 호출하는 대신 게이트웨이를 통해 라우팅하게 되는 세 가지 구체적인 이유입니다.
• 게이트웨이는 모델을 추가하거나 교체할 때 애플리케이션 코드를 변경하지 않고도, OpenAI 호환 엔드포인트(OpenAI-compatible endpoint) 하나, 자동 폴백(Fallback) 기능이 포함된 로드 밸런싱(Load balancing), 그리고 시맨틱 캐싱(Semantic caching)을 제공합니다.
• 또한 게이트웨이는 예산, 속도 제한, 가드레일(Guardrails)을 강제하기에 가장 자연스러운 장소이기도 합니다. 따라서 이러한 기능을 지원하지 않는 게이트웨이를 선택하기 전에 이 점을 반드시 알아두어야 합니다.

가장 먼저 나타나는 세 가지 문제

서비스 중단 (Outages). OpenAI와 Anthropic 모두 2025년 2월에서 5월 사이에 공개 상태 페이지(Public status pages)에 여러 차례 장애 사례를 기록했습니다. 특별한 것은 아니며, 타인의 인프라에 의존할 때 발생하는 일반적인 현상입니다. 만약 당신의 앱이 하나의 제공자에게 직접 호출을 보내는데 그 제공자에게 문제가 생긴다면, 당신의 앱도 함께 문제가 생깁니다. 기본 제공자가 다운되었을 때 두 번째 제공자로 장애 조치(Fail over)를 할 수 있는 게이트웨이를 통해 라우팅하는 것은, 20년 전 사람들이 웹 서버 앞에 로드 밸런서(Load balancers)를 두었던 것과 같은 본능적인 조치입니다.

속도 제한 (Rate limits). Azure OpenAI는 대부분의 제공자와 마찬가지로 모델별, 지역별로 분당 토큰 수(Tokens-per-minute) 및 분당 요청 수(Requests-per-minute) 할당량을 적용합니다. 정상적인 부하 상태에서는 이것이 보이지 않습니다. 하지만 트래픽이 급증하거나, 에이전트(Agent)가 재시도 루프(Retry loop)에 빠지는 버그가 발생하면 한계치에 도달하여 429 에러를 받기 시작합니다. 속도 제한을 이해하는 게이트웨이는 단순히 요청을 실패시키는 대신, 초과된 트래픽을 다른 모델이나 제공자로 라우팅할 수 있습니다.

벤더 종속성 (Lock-in). 모든 제공자의 SDK는 조금씩 형태가 다릅니다. 만약 당신의 코드베이스가 40군데에서 원시 OpenAI SDK와 통신하고 있다면, 6개월 후에 더 저렴하거나 더 나은 모델로 교체하기 위해 40군데를 모두 수정해야 함을 의미합니다. OpenAI 호환 게이트웨이 엔드포인트를 사용한다는 것은 애플리케이션 코드가 아닌, 단 하나의 설정에서 모델 이름만 변경하면 된다는 것을 의미합니다.

실무에서 "게이트웨이"가 의미하는 것

구체적으로, 대부분의 팀은 이러한 기능들의 조합을 원하게 되며, 특정 게이트웨이를 도입하기로 결정하기 전에 해당 게이트웨이가 실제로 어떤 기능들을 갖추고 있는지 확인해 볼 가치가 있습니다.

• 모든 제공자(Provider)를 위한 단일 엔드포인트. TrueFoundry의 AI Gateway는 여러 제공자에 걸친 천 개 이상의 모델 앞에 OpenAI 호환 스키마 (OpenAI-compatible schema)를 노출하므로, 애플리케이션 코드가 벤더별로 서로 다른 클라이언트 (Client)를 가질 필요가 없습니다.
• 부하 분산 (Load balancing) 및 폴백 (Fallback), 이를 통해 특정 모델이 다운되거나 느려지더라도 애플리케이션이 함께 중단되지 않도록 합니다. 라우팅 문서에서는 가중치 기반 라우팅 (Weighted routing), 지연 시간 기반 라우팅 (Latency-based routing), 그리고 새로운 모델을 전체 트래픽에 적용하기 전 일부 트래픽에 대해 테스트하는 카나리 배포 (Canary rollouts)에 대해 설명합니다.
• 속도 제한 (Rate limiting), 사용자별, 팀별 또는 애플리케이션별로 적용되어, 하나의 폭주하는 스크립트나 소란스러운 고객 한 명 때문에 다른 모든 사용자가 자원을 할당받지 못하는 상황을 방지합니다. 상세 내용 확인.
• 시맨틱 캐싱 (Semantic caching), 이미 처리한 요청과 의미론적으로 유사한 요청에 대해 비용과 지연 시간 (Latency)을 절감합니다. 관련 문서.

사람들이 예상하지 못하는 부분: 정책의 병목 지점 (Policy chokepoint)이 됩니다

모든 모델 호출이 한 곳을 통과하게 되면, 그곳은 자연스럽게 예산, 액세스 제어 (Access control), 그리고 가드레일 (Guardrails)을 강제하는 지점이 됩니다. 이는 게이트웨이가 거버넌스 (Governance)를 "위한" 것이기 때문이 아니라, 어떤 팀이나 어떤 모델이 요청했는지와 관계없이 모든 요청을 볼 수 있는 유일한 구성 요소이기 때문입니다. 거버넌스 측면은 그 자체로 매우 큰 주제이기에, 이에 대해 별도로 작성한 후속 글이 있습니다.

여기서는 배포 (Deployment) 방식도 중요합니다. TrueFoundry의 게이트웨이는 배포 모드 문서에 따라 완전 관리형 (Fully managed), 하이브리드 (사용자 인프라, TrueFoundry의 컨트롤 플레인), 또는 사용자의 VPC 내에 완전히 자체 호스팅 (Self-hosted) 방식으로 실행할 수 있습니다. 귀사의 컴플라이언스 (Compliance) 정책상 "SaaS 게이트웨이"가 허용되지 않는지 확인해 볼 가치가 있습니다.

만약 직접 무언가를 먼저 실행하고 싶다면, TrueFoundry의 LLM 게이트웨이에 관한 자체 글에서 제품 측면의 관점으로 동일한 내용을 다루고 있으며, 시작 단계에서 가장 자주 언급되는 두 가지 오픈 소스 (Open-source) 옵션은 LiteLLM과 Bifrost입니다.

제 논리에 반론을 제기하고 싶은 부분

게이트웨이는 움직이는 부품이 하나 더 늘어나는 것이며, 속도가 느려지거나 오류가 발생할 수 있는 요소가 하나 더 추가되는 것입니다. 만약 단일 사용 사례(Use case)를 위해 단일 제공업체(Provider)를 낮은 볼륨으로 호출하고 있다면, 아직은 이것이 필요하지 않을 수도 있습니다. 하지만 멀티 제공업체(Multi-provider), 멀티 팀(Multi-team) 환경이 되거나, 제공업체의 서비스 중단(Outage)으로 인해 실제로 손실이 발생하기 시작하면 필요해질 것입니다. LLM 게이트웨이 vs 프록시 vs 라우터에 관한 이 글은 실제로 어느 정도의 수준이 필요한지 파악하려는 경우 그 경계가 어디인지 잘 분석해 놓았습니다. 또한, 전체 게이트웨이를 도입하기 전에 코드상에서 페일오버 (Failover) 패턴을 확인하고 싶다면 에이전트(Agent)에 자동 제공업체 폴백 (Fallback) 연결하기에 대한 확실한 가이드도 있습니다.

게이트웨이 계층을 추가하게 된 실제 계기는 무엇인가요? 서비스 중단이었나요, 속도 제한 (Rate limit) 벽이었나요, 아니면 다른 무엇이었나요? 서로 다른 팀의 설정 간에 그 이유가 일치하는지, 아니면 제가 완전히 놓치고 있는 카테고리가 있는지 궁금합니다.