요약

• 수백 개의 모델 앞에 위치한 단일 HTTP 엔드포인트로, creator/모델명 문자열로 참조하며, 다른 제공업체의 동일 모델로 자동 장애 조치(failover)가 이루어지고 토큰에 마크업이 없습니다. 심지어 자체 제공업체 키를 사용하더라도 마찬가지입니다.
• Vercel과 AI SDK를 이미 사용하는 팀을 위해 구축되었으며, 모델 전환은 새로운 클라이언트 설치가 아닌 문자열 변경만으로 가능합니다. 하지만 이는 거버넌스 레이어가 아니라 라우팅 및 비용 가시성(spend-visibility) 계층일 뿐입니다: 팀별 RBAC(Role-Based Access Control), 예산 강제 적용, MCP 접근 제어는 없습니다.
• 독립적인 벤치마크에 따르면 Anthropic 네이티브 SDK가 작은 프롬프트에서는 게이트웨이보다 약 15~20% 더 빠했지만, 컨텍스트가 커지면 그 차이는 거의 사라집니다. 따라서 고정된 세금(tax)이라고 가정하기보다는 자체 워크로드에서 테스트해 볼 가치가 있습니다.

실제로는 무엇인가

이 게이트웨이는 모든 주요 제공업체의 모델 앞에 위치한 단일 엔드포인트, https://ai-gateway.vercel.sh/v1입니다. 모델은 creator/모델명으로 참조합니다. 예를 들어, anthropic/claude-opus-4.8, openai/gpt-5.5와 같이 사용하며, AI SDK에서 이 문자열을 모델로 전달하면 호출이 자동으로 게이트웨이를 통해 라우팅됩니다. 게이트웨이 자체를 위해 별도로 설치해야 하는 클라이언트는 없습니다. 이미 AI SDK를 사용하고 있다면, 이는 주로 설정 변경에 불과합니다.

구체적으로 얻게 되는 것은 다음과 같습니다: 채팅 완성(chat completions)과 함께 임베딩(embeddings), 구성한 모든 제공업체 전반의 비용 모니터링, 자동 재시도(automatic retries), 대상 간 부하 분산(load balancing across targets), 그리고 Vercel의 계정 대신 자체 제공업체 계정을 사용하고 싶을 때를 위한 Bring Your Own Key 기능입니다. 제가 특별히 언급할 한 가지는 다음과 같습니다: 하나가 성능이 저하될 때 다른 제공업체의 동일 모델로 자동 장애 조치되는 것입니다. 단순히 더 저렴한 모델로 폴백(fallback)하는 것이 아니라, 정확한 모델을 유지하고 요청이 리라우팅되더라도 출력이 변하지 않도록 어떤 인프라가 서비스를 제공할지만 전환됩니다.

OpenAI, Anthropic, Google 전반에 걸쳐 제로 데이터 보유(Zero data retention) 기능이 제공되지만, 기본적으로 무료는 아니라는 점을 아는 것이 중요합니다. 팀 전체의 제로 데이터 보유 기능은 Pro 및 Enterprise 플랜에서 성공적인 요청 1,000건당 $0.10가 부과되며, 팀 전체의 Provider Allowlist 또는 Custom Reporting에 대해서도 유사한 건별 추가 비용이 발생합니다.

가격 정책을 간략히 설명하자면

모든 Vercel 팀 계정은 처음 사용 시 월 $5 상당의 AI Gateway 크레딧을 받습니다. 그 이상으로는 토큰 마크업이 없다는 것이 가장 큰 장점입니다. 따라서 직접 키를 가져와 사용할 때조차도 제공업체가 명시한 요율을 지불하게 되며, 이는 일정 비율을 떼어가는 게이트웨이와는 근본적으로 다른 모델입니다. 의무적인 재갱신 없이 언제든지 추가 크레딧을 구매할 수 있습니다. 현재 금액은 이 스냅샷을 신뢰하기보다는 Vercel의 자체 가격 페이지에서 확인하시기 바랍니다.

지연 시간(Latency)에 대한 질문, 솔직하게 말하자면

제가 찾은 벤치마크 중 하나는 게이트웨이를 네이티브 Anthropic SDK와 직접 비교한 것이었습니다. 작은 프롬프트(약 10 토큰)의 경우, 네이티브 SDK가 약 15~20% 더 빨랐지만, 큰 컨텍스트(120K 토큰)에서는 두 방식 간의 격차가 거의 사라졌습니다. 이는 한 사람의 벤치마크일 뿐 작업 부하에 대한 보장은 아니지만, 기대할 수 있는 유용한 경향성을 보여줍니다. 즉, 라우팅 오버헤드는 모델 추론 시간이 이미 지배적인 큰 요청보다는 작고 지연 시간에 민감한 호출에서 비례적으로 더 중요하게 작용한다는 것입니다.

적합하지 않은 경우

이것은 라우팅 및 지출 가시성(spend-visibility) 계층이며, 이것이 포함하지 않는 것이 무엇인지 정확히 아는 것이 중요합니다. 어떤 모델에 대해 다른 그룹이 호출할 수 있는지에 대한 팀별 또는 사용자별 RBAC(Role-Based Access Control)은 없습니다. 예산 강제 집행 기능도 없는데, 지출 모니터링은 무슨 일이 일어났는지 알려줄 뿐이며, 하드한 예산 상한선처럼 요청을 미리 차단하지는 않습니다. MCP 서버 거버넌스나 PII(개인 식별 정보) 또는 프롬프트 인젝션에 대한 내장 가드레일도 없습니다. 이 모든 것이 제품의 결함은 아닙니다. 단지 RBAC, 예산 및 가드레일을 갖춘 전용 AI 게이트웨이가 해결하는 문제와는 다른 문제를 (하나의 API, 하나의 청구서, 자동 장애 조치) 해결하고 있을 뿐입니다.

만약 Vercel에서 배포되는 소규모 팀이고 인프라를 추가하지 않으면서 모델 라우팅을 원한다면, 이것은 정말 좋은 선택지입니다. 하지만 여러 팀과 많은 앱에 걸친 회사 전체의 거버넌스가 필요하고, 단지 하나의 Vercel 프로젝트 지출에 대한 가시성만 필요한 것이 아니라면, 그것은 다른 종류의 도구 범주에 속합니다.

이것이 바로 '지출 모니터링'만으로는 충분하지 않고 실제로 팀별로 [예산 및 호출 제한(rate limits)을 강제 집행]해야 하며, 또한 애플리케이션 코드 내에서가 아니라 게이트웨이에서 적용되는 [PII 및 프롬프트 인젝션 가드레일]이 필요한 경우 제가 선택할 곳이 바로 TrueFoundry의 AI Gateway입니다. 두 제품은 실제로 같은 구매자를 두고 경쟁하는 것이 아닙니다. Vercel AI Gateway는 트래픽이 Vercel에서 배포된 앱이고 AI SDK가 이미 인터페이스인 경우 적절한 선택이며, TrueFoundry의 게이트웨이는 여러 팀이나 여러 배포 대상을 일관되게 관리해야 할 때 모든 것(Vercel에 배포된 앱 포함) 앞에 위치하도록 구축되었습니다. 제가 이 비교에 있어 중립적인 출처가 아니기 때문에 솔직하게 말할 가치가 있습니다.

만약 프로덕션 환경에서 Vercel AI Gateway를 운영하고 있다면, 자동 모델 장애 조치(automatic same-model failover) 기능이 실제 제공업체 서비스 중단 시 실제로 도움이 되었나요? 아니면 대부분 작동하지 않고 대기 상태에 머물러 있었나요? 이 특정 기능이 보험처럼 존재하는 것과 비교하여 얼마나 자주 실제로 발동되는지 궁금합니다.