2026 AI Gateway 비교: Kong, Portkey, LiteLLM, 그리고 TrueFoundry

요약 (TL;DR)

Kong, Portkey, LiteLLM은 AI 사용량이 여러 팀으로 확산될 때 각각 실질적인 한계에 부딪힙니다. 주로 비용 귀속 (cost attribution), 환경 격리 (environment isolation), 그리고 MCP/에이전트 거버넌스 (governance) 측면에서 그렇습니다.
이들 사이의 선택은 기능 목록보다는 현재 무엇을 운영하고 있는지에 더 크게 좌우됩니다.
TrueFoundry는 전체 스택 (라우팅 + MCP + 모델 배포)을 하나의 시스템에서 처리하여 구조를 단순화하지만, 초기 도입 시 더 많은 것을 채택해야 함을 의미합니다.

6개월 전, 우리 팀은 본격적으로 AI 게이트웨이 (AI gateways)를 평가하기 시작했습니다. 단순한 데모를 위해서가 아니었습니다. 우리는 5개의 스쿼드(squads)가 LLM 기능을 출시하고 있었고, 3개의 서로 다른 클라우드 제공업체가 사용 중이었으며, 보안 검토 과정에서 누가, 언제, 어떤 프롬프트로 어떤 모델을 호출했는지에 대한 까다로운 질문들이 나오고 있었습니다.

저는 스테이징 환경에서 실제로 Kong, Portkey, LiteLLM을 몇 주 동안 운영해 보았습니다. 제가 발견한 내용은 다음과 같습니다.

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

AI 게이트웨이는 애플리케이션 코드와 LLM 제공업체 사이에 위치합니다. 최소한 다음과 같은 작업을 처리합니다:

요청을 적절한 모델/제공업체로 라우팅 (Routing)
제공업체가 다운되었을 때 재시도 (Retrying) 및 장애 조치 (Failover)
사용자, 팀 또는 애플리케이션별 속도 제한 (Rate limiting)
토큰 사용량 및 비용 추적
일종의 액세스 제어 (Access control)

상황이 더 복잡해지는 지점은 에이전트 (agents)를 운영할 때입니다. 단일 대화 내에서 10개의 MCP 도구를 호출하는 에이전트 워크플로우는 단순한 채팅 엔드포인트와는 다른 거버넌스 요구 사항을 가집니다. 어떤 도구가, 어떤 에이전트에 의해, 어떤 신원(identity)으로 호출되었는지, 그리고 어떤 정책(policy)에 저촉되었는지를 알아야 합니다. 라우팅 프록시 (routing proxy)는 이를 커버하지 못합니다. 아래 도구 중 일부는 이를 지원합니다.

Kong AI Gateway

Kong은 수년 동안 Kubernetes 기반 마이크로서비스 (microservices)를 위한 기본 API 게이트웨이였습니다. AI 게이트웨이 계층은 해당 기반 위에 LLM 전용 플러그인 (plugins)을 추가합니다.

장점: 이미 Kong을 운영 중이라면, 동일한 제어 평면 (control plane)을 통해 AI 라우팅 (routing)을 추가하는 것은 진정으로 마찰이 적습니다. 플러그인 모델 (Lua 기반, 구성 가능)은 성숙하며 커스터마이징이 가능합니다. AI Rate Limiting Advanced 플러그인을 통한 토큰 수준의 속도 제한 (rate limiting)은 LLM 워크로드에 적합한 추상화입니다. 이는 HTTP 요청 횟수가 아닌 실제 토큰 소비량을 기준으로 제한을 겁니다. Kong 3.13+ 버전에서는 MCP 및 A2A (agent-to-agent) 프로토콜 지원도 추가되었습니다.

마찰 지점: 오픈 소스 버전에는 GUI, 고급 분석 또는 고급 AI 속도 제한 플러그인이 포함되어 있지 않으며, 이러한 기능들은 Konnect Enterprise에서 제공됩니다. 따라서 이미 Kong 비용을 지불하고 있지 않다면, 게이트웨이와 상용 티어 (commercial tier)라는 두 가지 요소를 동시에 평가해야 합니다. AI 라우팅을 위해 Kong을 처음 도입하는 팀들은 운영 오버헤드 (operational overhead)를 정당화하기 어렵다고 느끼는 경우가 많습니다.

구조적인 측면에서 더 살펴보면: Kong은 LLM 호출을 약간의 추가 메타데이터가 포함된 HTTP 요청으로 취급합니다. 프롬프트 생명주기 (prompt lifecycle), 에이전트 트레이싱 (agent tracing) 또는 MCP 서버 검색 (discovery)에 대한 네이티브 개념이 없습니다. 플러그인을 통해 요소들을 연결할 수는 있지만, 별개의 조각들을 조합하는 방식입니다.

적합한 경우: 이미 Kong을 운영 중인 경우. API와 AI 트래픽을 위한 단일 제어 평면 (control plane)을 원하는 경우. 처음부터 새로 시작하는 것이 아닌 경우.

Portkey

Portkey는 AI 네이티브 (AI-native)입니다. 일반적인 API 관리 도구에서 변형된 것이 아니라, 처음부터 LLM 애플리케이션을 위해 구축되었습니다. 이러한 점은 개발자 경험 (developer experience)에서 드러납니다.

장점: 설정이 진정으로 빠릅니다. 라우팅 설정 (routing config)이 읽기 쉽습니다. 관측성 (observability) 대시보드는 특정 모델이 왜 비용이 많이 드는지 디버깅할 때 실제로 유용한 방식으로 토큰 비용 내역을 보여줍니다. 플레이그라운드 (playground)를 통한 프롬프트 버전 관리 (prompt versioning)는 실질적인 삶의 질(quality-of-life) 향상을 제공합니다. 시맨틱 캐싱 (semantic caching), 재시도 (retries) 및 폴백 (fallbacks) 기능이 즉시 사용 가능한 상태로 작동합니다.

마찰 지점 (The friction): Portkey의 설계는 애플리케이션 범위 (application-scoped)로 되어 있어, 단일 팀에게는 괜찮지만 조직 규모 (org scale)에서는 공백이 발생합니다. 환경 격리 (Environment isolation, dev vs staging vs production)가 기본 개념으로 내장되어 있지 않습니다. 여러 팀에 걸친 비용 할당 (Cost attribution)은 우회 방법이 필요합니다. 조직별 예산 제한은 엔터프라이즈 (Enterprise) 플랜 기능입니다. 하위 티어의 팀들은 키별 (per-key) 예산을 설정할 수 있지만, 워크스페이스 수준의 강제 적용은 불가능합니다. 로그 보관 (Log retention)은 프로덕션 (Production) 티어에서 30일이며, 이는 업그레이드 없이는 대부분의 규제 산업 (regulated industries)의 컴플라이언스 (compliance) 요구 사항을 충족하지 못합니다.

언급할 만한 소유권 문제도 있습니다: Palo Alto Networks가 Portkey 인수를 완료했습니다. 이는 장기적인 평가 시 고려할 가치가 있습니다. 이는 더 나은 엔터프라이즈 통합 및 보안 도구를 의미할 수도 있습니다. 반대로 가격 변동이나 제품 개발 속도 (product velocity)의 저하를 의미할 수도 있습니다. 이는 미결정된 문제이며, Portkey를 핵심 인프라 (critical infrastructure)에 배치하기 전에 로드맵 (roadmap)을 확인하고 싶을 것입니다.

적합한 경우: 소규모 팀, 빠른 배포, 개발자 경험 (developer experience)이 우선순위인 경우, 거버넌스 (governance) 요구 사항이 단순한 경우.

LiteLLM

LiteLLM은 대부분의 AI 엔지니어들이 가장 먼저 시도해 보는 도구입니다. 100개 이상의 모델에 대해 OpenAI 호환 API를 제공하며, MIT 라이선스, Docker 이미지, 대규모 커뮤니티를 보유하고 있습니다. 진정으로 가장 쉬운 시작점입니다.

장점 (The good): 제공업체 커버리지가 넓습니다. 변환 레이어 (translation layer)가 깔끔합니다. 표준 OpenAI 형식의 요청을 작성하면 LiteLLM이 Anthropic, Bedrock, Gemini, 셀프 호스팅 (self-hosted) 모델 등 무엇이든 적절히 라우팅 (routing)합니다. 키별 예산 및 속도 제한 (rate limits)이 있는 가상 키 (Virtual keys)는 설정 시 작동합니다. 관리자 대시보드 (admin dashboard)는 기본적인 팀 관리를 처리합니다.

마찰 지점 (The friction): 규모가 커질 때 실제로 중요한 거버넌스 기능들 — SSO, RBAC (역할 기반 액세스 제어), 팀 수준의 예산 강제 적용 — 은 엔터프라이즈 (Enterprise) 라이선스 뒤에 숨겨져 있습니다. 오픈 소스 버전에는 Okta를 연결할 수 없습니다. 엔지니어가 20명일 때는 관리할 수 있는 수준입니다. 하지만 200명이 되면 라이선스 비용을 지불하거나, Slack에서 마스터 키를 공유해야 하는 상황에 놓이게 됩니다.

설정(Config)은 YAML 비중이 매우 높습니다. 엔지니어 한 명이 이를 관리할 때는 괜찮지만, 여러 팀이 독립적으로 라우팅 규칙(routing rules)을 수정해야 하는 상황에서는 깔끔하게 확장되지 않습니다. 분산 속도 제한(Distributed rate limiting)을 위해서는 Redis가 필요하며, 만약 Redis에 문제가 발생하면 속도 제한 강제 기능이 저하됩니다. 또한 오픈 소스 빌드에서는 SLA(Service Level Agreement)와 공식적인 감사 추적(audit trail) 지원이 없습니다.

LiteLLM은 최근 자신들의 지원 모델이 더 이상 규모에 맞지 않는다고 언급하며 지원 모델을 변경했습니다. 인프라 결정 과정에서 지원(support)을 중요하게 고려한다면 추적해 볼 가치가 있습니다.

적합한 경우: 개인 엔지니어 또는 소규모 팀의 프로토타이핑, 셀프 호스팅(self-hosted) 모델 액세스, 자체 인프라 관리에 능숙하며 추후 엔터프라이즈 라이선스 비용을 감당할 의사가 있는 경우.

TrueFoundry

TrueFoundry의 게이트웨이는 단일 OpenAI 호환 엔드포인트를 통해 1,000개 이상의 LLM(OpenAI, Anthropic, Gemini, Bedrock, Azure OpenAI, Groq, Mistral, xAI, Together AI, 셀프 호스팅 모델 등)에 연결됩니다. 라우팅 계층은 가중치 또는 지연 시간(latency)에 따른 부하 분산(load balancing), 자동 폴백 체인(automatic fallback chains), 그리고 재시도(retries)를 처리합니다.

중요한 아키텍처 세부 사항: 게이트웨이는 Hono를 기반으로 구축되었으며, 핫 패스(hot path) 내에 외부 호출이 없습니다. 인증(Auth), 속도 제한(rate limiting), 부하 분산(load balancing)이 모두 인메모리(in-memory)에서 실행됩니다. 설정은 NATS를 통해 컨트롤 플레인(control plane)으로부터 동기화됩니다. 속도 제한은 슬라이딩 윈도우 토큰 버킷(sliding window token bucket) 방식을 사용하며, 분 단위 윈도우와 5초 단위 버킷 세분화를 적용합니다. 이는 요청당 DB 조회를 수행하지 않고 모두 인메모리에서 강제됩니다. 벤치마크 결과에 따르면, 1 vCPU / 1 GB RAM 환경에서 트레이싱(tracing)을 켠 상태로 풀 로드 시 추가 지연 시간이 7~12ms이며 350+ RPS를 기록했습니다. 이러한 인메모리 설계 덕분에 RBAC(역할 기반 액세스 제어) 규칙과 예산 체크가 쌓여도 빠른 속도를 유지할 수 있습니다.

조직 규모의 문제 처리 영역: RBAC(역할 기반 액세스 제어)가 API 키뿐만 아니라 사용자, 팀, 애플리케이션 범위에 적용됩니다. 예산 제한은 사용자, 팀, 애플리케이션 수준에서 동시에 적용되며, 가장 제한적인 규칙이 우선합니다. 단순히 총 지출액만이 아니라 모델별 비용 할당을 확인할 수 있습니다. 가드레일(PII 감지, 프롬프트 주입 필터링, 콘텐츠 조정) 기능이 외부 자격 증명 없이 내장되어 있습니다. 특정 규정 준수 요구 사항이 있는 팀의 경우 Azure Content Safety, Bedrock Guardrails, OpenAI Moderations, Google Model Armor와 같은 외부 제공업체를 사용할 수 있습니다. 가드레일은 검증 모드(inspect, 선택적 차단) 또는 변형 모드(inspect 및 수정)로 적용되며, MCP 도구 결과뿐만 아니라 LLM 응답에도 적용됩니다.

MCP 레이어: 이 부분은 다른 도구들에서는 같은 깊이로 존재하지 않는 영역입니다. TrueFoundry는 모든 MCP 서버를 위한 중앙 레지스트리를 제공하는 전용 MCP Gateway를 갖추고 있습니다. OAuth 2.0 인증은 한 곳에서 관리되며, 등록된 모든 서버에 걸쳐 사용자당 하나의 토큰이 자동으로 새로 고침됩니다. 여러 실제 MCP 서버의 선별된 하위 집합을 노출하는 논리적 엔드포인트인

배포 옵션 (Deployment options): SaaS, VPC 호스팅 (VPC-hosted), 온프레미스 (on-prem), 그리고 에어갭 (air-gapped) (에어갭 설정은 아키텍처 문서에 명시된 포워드 프록시 (forward proxy) 구성을 사용합니다). SOC 2, HIPAA, ITAR 인증을 획득했습니다.

기능 비교 (Feature comparison)

	Kong	Portkey	LiteLLM	TrueFoundry
셀프 호스팅 (Self-hosted)	✅	제한적 (Limited)	✅	✅
...
이 표에 대한 몇 가지 참고 사항: "제한적 (Limited)" 및 "부분적 (Partial)"은 작성 시점의 문서를 바탕으로 제가 정의한 특성입니다. 결정을 내리기 전에 현재 문서를 확인하십시오. Kong 및 Portkey의 엔터프라이즈 기능은 귀하가 사용하는 가격 티어 (pricing tier)에 따라 달라집니다.

각 도구의 실제 위치

네 가지 도구를 모두 스테이징 (staging) 환경에서 실행하고 그 트레이드오프 (tradeoffs)를 직접 경험해 본 결과, 솔직한 견해는 다음과 같습니다:

Kong은 — 오직 — 이미 Kong을 운영하고 있는 경우에만 합리적인 답변이 됩니다. AI 플러그인 (plugins)은 기존의 투자를 잘 확장해 줍니다. 하지만 처음부터 시작하며 특히 AI 워크로드 (workloads)를 위해 게이트웨이를 평가하고 있다면, 목적에 맞게 제작된 (purpose-built) 옵션들이 존재하는 상황에서 Kong의 운영 오버헤드 (operational overhead)와 플러그인 조립 모델은 정당화하기 어렵습니다. Kong은 우연히 API를 수행하는 AI 게이트웨이가 아니라, 우연히 AI를 수행하는 API 게이트웨이입니다. 이 순서가 중요합니다.

Portkey는 빠르게 움직이는 단일 팀에게 진정으로 좋습니다. 개발자 경험 (DX)은 네 가지 중 가장 뛰어납니다. 하지만 Palo Alto Networks에 의한 인수는 단순한 각주가 아니라 실질적으로 고려해야 할 사항입니다. 제품이 대형 보안 업체에 흡수되면 로드맵의 초점이 이동합니다. 가격은 상위 시장 (upmarket)을 향해 상승하는 경향이 있고, 반복 주기 (iteration)는 느려지며, 개발자 우선 기능들은 엔터프라이즈 영업을 위해 우선순위가 밀리게 됩니다. 결과가 좋게 풀릴 수도 있지만, 지금 Portkey를 핵심 인프라로 고정하는 것은 그 결과에 도박을 거는 것을 의미합니다. 향후 2~3년 동안 안정적이고 활발하게 개발되는 게이트웨이가 필요한 팀에게, 그것은 오늘 내리기에 편안한 선택이 아닙니다.

LiteLLM은 대부분의 팀이 시작하는 지점이며, 그럴 만한 가치가 있습니다. 1인 엔지니어와 소규모 팀에게는 MIT 라이선스, 마찰 없는 사용성(zero friction), 광범위한 제공업체 커버리지 덕분에 이만한 대안을 찾기 어렵습니다. 문제는 조직 규모가 커짐에 따라 깔끔하게 함께 성장하지 못한다는 점입니다. 조직 규모에서 실제로 필요한 기능들(SSO, RBAC, 감사 추적(audit trails), 팀 단위 예산 강제 적용)은 모두 엔터프라이즈 라이선스 뒤에 숨겨져 있으며, YAML 중심의 설정 모델은 더 많은 팀이 이를 다루게 됨에 따라 조정(coordination) 문제를 일으키기 시작합니다. LiteLLM은 훌륭한 개념 증명(PoC) 도구이지만, AI 사용이 성숙해지면 마이그레이션 프로젝트가 되어버립니다.

TrueFoundry는 AI 사용이 여러 팀에 걸쳐 확산되고, 도구를 사용하는 에이전트(agents)가 포함되며, 컴플라이언스(compliance) 검토를 견뎌내야 한다는 가정하에 설계된 네 가지 도구 중 유일한 솔루션입니다. 인메모리 속도 제한(in-memory rate limiting), 계층적 RBAC, MCP 거버넌스 계층, 그리고 라우팅뿐만 아니라 배포(deployment)까지 아우른다는 점은 나중에 덧붙여진 기능이 아닙니다. 그것들은 바로 이 도구가 만들어진 목적 그 자체입니다. 솔직한 트레이드오프(tradeoff)는 초기 설정의 복잡성입니다. 하지만