LiteLLM은 진정으로 훌륭한 소프트웨어입니다. 무료이며 오픈 소스(open source)이고, 100개 이상의 제공업체를 하나의 OpenAI 호환 형식으로 통합하며, 많은 팀이 가장 먼저 찾는 기본 도구입니다. 또한 직접 실행하고 패치하는 셀프 호스팅 프록시(self-hosted proxy)이기도 하지만, 거버넌스(governance) 기능은 기본적으로 제공되기보다는 대부분 사용자가 직접 구축해야 하는 형태입니다. 아래 소개할 7가지 옵션은 바로 그 간극을 메워주는 도구들입니다.

요약 (TL;DR)

• LiteLLM은 라우팅(routing), 비용 추적(cost tracking), 기본적인 가드레일(guardrails) 기능은 잘 수행하지만, RBAC(역할 기반 액세스 제어), 예산 집행(budget enforcement), MCP 거버넌스, 도구 수준의 정책(tool-level policy) 등은 LiteLLM이 제공하는 기능이 아니라 사용자가 직접 구축해야 하는 영역입니다.
• 만약 직접 구축할 필요 없이 관리형(managed), 하이브리드(hybrid), 또는 완전한 셀프 호스팅(self-hosted) 배포 환경에서 거버넌스 계층(RBAC, 감사 우선 출시를 지원하는 예산 관리, PII/프롬프트 인젝션 가드레일, 네이티브 MCP 게이트웨이)을 원한다면 TrueFoundry가 최선의 선택입니다.
• 하지만 비용이 전혀 들지 않고 가장 큰 오픈 소스(OSS) 커뮤니티를 원하거나, 이미 Cloudflare/Kong/Vercel/Databricks를 사용 중이라면 나머지 6가지 중 하나가 솔직히 더 나은 선택일 수 있으며, 이 리스트는 각각의 용도에 맞는 위치를 정확히 짚어줍니다.

1. TrueFoundry

TrueFoundry의 AI Gateway가 여기서 최고의 선택인 이유는 단 한 가지입니다. LiteLLM이 사용자가 직접 구축하도록 남겨둔 기능들, 즉 팀 및 사용자별로 범위가 지정된 RBAC, 강제 차단 기능을 활성화하기 전 감사 우선 출시(audit-first rollout)를 지원하는 예산 관리, 그리고 PII/프롬프트 인젝션/콘텐츠 모더레이션 가드레일 등이 이곳에서는 일급 시민(first-class) 기능으로 제공된다는 점입니다. 또한 적절한 인바운드/아웃바운드 인증 처리, 파괴적인 작업에 대한 도구별 승인 게이트, 그리고 LiteLLM에는 전혀 대응하는 기능이 없는 Cedar/OPA 기반의 도구 정책을 갖춘 완전한 MCP 게이트웨이를 함께 제공합니다.

배포(Deployment)는 또 다른 차별화 요소입니다. 관리형(managed), 하이브리드(hybrid), 또는 자체 VPC에서 완전히 셀프 호스팅(fully self-hosted)할 수 있습니다. 따라서 '내 트래픽이 다른 사람의 인프라를 건드리는 것이 싫다'는 이유로 순수하게 호스팅되는 옵션을 배제할 필요가 없습니다.

적합하지 않은 경우: 무료가 아니며, 커뮤니티에서 유지 관리하는 오픈 소스 프로젝트도 아닙니다. 즉, 벤더의 로드맵을 신뢰해야 합니다. 만약 실제 요구 사항이 제로 비용(zero cost)과 가장 큰 OSS 커뮤니티 지원이라면, 그것은 LiteLLM 자체이지 그 대안 중 어느 것도 아닙니다.

3. Portkey

Portkey의 게이트웨이는 회사가 호스팅 제품을 통해 하루에 1조 토큰 이상을 처리한다고 밝힌 후, 2026년 3월 Apache 2.0 하에 완전히 오픈 소스로 전환되었습니다. 이제 셀프 호스팅 사용자들은 유료 버전과 동일한 기능 세트(feature set)를 얻게 됩니다: 서킷 브레이커(circuit breakers), 사용량 정책(usage policies), OAuth 2.1을 갖춘 MCP 게이트웨이, 그리고 라이선스 키가 필요 없는 전체 모델 카탈로그입니다. 거버넌스에 더해 오픈 소스가 필요한 특정 조합이라면 진정으로 강력한 옵션입니다.

적합하지 않은 경우: Palo Alto Networks는 2026년 4월 Portkey 인수를 발표했으며, 이 거래는 2026년 7월경에 마무리될 것으로 예상됩니다. 오늘날 이것이 결정적인 결격 사유는 아니지만, 프로덕션 환경에서의 베팅에는 실제 물음표가 될 수 있으므로 현재의 오픈 소스 방향성에 전념하기 전에 고려해 볼 가치가 있습니다.

4. Bifrost

Bifrost는 Maxim AI에서 제공하는 Go 기반의 오픈 소스 게이트웨이로, 원시 성능(raw performance)을 핵심으로 마케팅합니다. README에 따르면, 초당 5,000 요청 시 오버헤드가 100마이크로초 미만인 상태에서 LiteLLM보다 50배 빠른 처리량(throughput)을 주장하며, 적응형 로드 밸런싱(adaptive load balancing)과 가드레일(guardrails) 기능도 제공합니다. 이 수치들은 Bifrost가 자체적으로 발표한 것이며, 여기서 독립적으로 재현된 것은 아니므로, 배수(multiplier)를 사실로 간주하기 전에 반드시 자체 트래픽 패턴에 맞춰 검증해야 합니다.

적합하지 않은 경우: 극도의 RPS에서 원시 처리량이 실제로 병목 현상이 아니라면, 결코 알아차리지 못할 수 있는 성능 여유분 때문에 Go 인프라를 채택하게 됩니다.

5. Cloudflare AI Gateway

모든 Cloudflare 플랜에서 무료로 제공되며, Cloudflare 자체 엣지 네트워크 (edge network)에서 실행됩니다. 만약 귀하의 앱이 이미 Cloudflare 뒤에 위치해 있다면 캐싱 (caching), 재시도 (retries), 모델 폴백 (model fallback), 그리고 분석 (analytics) 기능을 사용할 수 있습니다. 이 경우 진정한 의미의 제로 설정 (zero setup)이 가능합니다.

적합하지 않은 경우: 내장된 RBAC (역할 기반 액세스 제어), 정책 코드화 (policy-as-code), 팀별 비용 귀속 (per-team cost attribution) 기능이 없습니다. 이는 거버넌스 (governance)가 아닌 라우팅 (routing) 및 캐싱 (caching) 도구입니다. 이것만으로 충분하다면 괜찮지만, 그렇지 않다면 적합하지 않습니다.

6. Kong AI Gateway

이미 API 게이트웨이 (API gateway)로 Kong을 사용 중이라면, AI 라우팅을 플러그인 (plugin)으로 추가하는 것이 별도의 LLM 전용 도구를 구축하는 것보다 새로운 관리 영역 (surface area)을 줄이는 방법입니다.

적합하지 않은 경우: Kong의 자체 포지셔닝에 따르면, 여기서의 AI 기능은 범용 API 게이트웨이의 확장 기능일 뿐 LLM 트래픽을 위해 특화되어 설계된 것이 아닙니다. 즉, 실제 지연 시간 기반 라우팅 (latency-based routing), 비용 인지형 폴백 (cost-aware fallback), 내장된 가드레일 (guardrails) 기능이 없습니다.

7. Vercel AI Gateway

단일 엔드포인트 (endpoint)를 제공하며, 귀하의 자체 제공자 키 (provider keys)를 사용하더라도 토큰 (tokens)에 대한 추가 비용이 없습니다. 또한 이미 Vercel AI SDK를 사용 중이라면 한 줄의 설정 변경만으로 적용 가능합니다.

적합하지 않은 경우: 이는 라우팅 및 지출 가시성 (spend-visibility) 계층이지, 거버넌스 계층이 아닙니다. 팀별 RBAC, 예산 강제 (budget enforcement), MCP 서버 거버넌스 기능이 없습니다. Vercel에서 배포하는 소규모 팀에게는 훌륭하지만, 여러 팀에 걸친 전사적 정책을 위해 구축된 것은 아닙니다.

LiteLLM 대안들의 공통점과 차이점

LiteLLM 자체를 제외한 위의 모든 옵션은 LiteLLM이 제공하지 않는 거버넌스 기능을 추가하거나 (TrueFoundry, Portkey), 이미 사용 중일 가능성이 높은 생태계에 내장됨으로써 거버넌스 기능을 완전히 포기합니다 (Cloudflare, Kong, Vercel). 이들 중 어느 것도 모든 차원에서 LiteLLM에 대한 엄격한 업그레이드 버전은 아닙니다. 각각 LiteLLM이 특별히 우선순위를 두지 않는 문제를 해결하고 있을 뿐입니다. LiteLLM 대안에 대한 이 다른 요약은 동일한 질문에 대해 다른 관점을 확인하고 싶을 때 살펴볼 가치가 있으며, 이 목록에 없는 몇 가지 옵션도 다루고 있습니다.

어떤 격차(gap)가 실제로 당신이 대안을 찾게 만들었나요? 거버넌스(governance), 성능(performance), 아니면 단순히 인프라를 직접 운영하고 싶지 않아서인가요? 그 이유들이 제가 예상하는 대로 군집을 이루는지, 아니면 제가 완전히 놓치고 있는 카테고리가 있는지 궁금합니다.