프로덕션 환경을 위한 5가지 MCP 게이트웨이 평가를 통해 배운 점

Anthropic이 2024년 11월에 Model Context Protocol (MCP)을 출시했을 때, 초기 논의는 주로 프로토콜 자체에 집중되었습니다. 즉, AI 에이전트가 모든 API에 대해 맞춤형 통합을 구축하지 않고도 도구를 발견하고 호출할 수 있는 표준화된 방식에 대한 이야기였습니다. 그 문제는 실재했으며, 프로토콜은 그 문제를 대부분 해결했습니다.

하지만 MCP 도입은 2025년 중반쯤부터 팀들이 직면하기 시작한 두 번째 문제를 야기했습니다. 수십 개의 MCP 서버 연결을 대규모로 어떻게 관리할 것인가, 에이전트가 무엇에 접근할 수 있는지 어떻게 제어할 것인가, 그들이 실제로 무엇을 하고 있는지 어떻게 확인할 것인가, 그리고 보안 팀이 밤잠을 설칠 필요 없이 자격 증명 로테이션 (credential rotation)을 어떻게 처리할 것인가 하는 문제입니다. 기본 프로토콜은 이 중 어느 것도 다루지 않습니다.

그것이 바로 MCP 게이트웨이가 메우는 간극입니다. 저는 몇 주 동안 주요 옵션들을 평가하는 데 시간을 보냈습니다. 이 글은 각 도구가 가진 진정한 강점과 부족한 점을 포함하여 제가 발견한 내용을 다룹니다.

MCP 게이트웨이를 평가할 때 실제로 중요한 것

대부분의 비교 게시물은 지연 시간 (latency) 벤치마크나 기능 체크리스트를 먼저 내세웁니다. 그것들도 중요하지만, 실제 상황에서 도구들을 차별화하는 데는 다음 세 가지 질문이 더 큰 역할을 했습니다.

기존 스택의 어디에 적합한가? 일부 게이트웨이는 독립형 인프라 (standalone infrastructure)인 반면, 다른 것들은 특정 클라우드 제공업체나 컨테이너 런타임 (container runtime)과 긴밀하게 통합됩니다. 올바른 선택은 현재 무엇을 실행하고 있는지에 따라 크게 달라집니다. 잘못된 아키텍처 적합성을 채택하는 것은 절약하는 것보다 더 많은 작업을 만들어냅니다.

어떤 보안 모델을 강제하는가? 도구 오염 (tool poisoning), 자격 증명 노출, 승인되지 않은 에이전트 접근은 이론적인 문제가 아니라 프로덕션 환경의 문제입니다. 게이트웨이들은 의미 있게 다른 접근 방식을 취하며, 그 차이는 단순히 외관상의 차이가 아닙니다.

대규모 환경에서의 운영 오버헤드 (operational overhead)는 어느 정도인가? 중앙 집중식 관측성 (observability) 없이 5개의 MCP 연결을 관리하는 것은 괜찮습니다. 하지만 그것 없이 50개를 관리하는 것은 그렇지 않습니다. 설정하기 쉬운 솔루션은 워크로드가 증가함에 따라 운영하기 고통스러워지는 경우가 많습니다.

제가 평가한 5가지 도구

1. TrueFoundry

TrueFoundry의 MCP 게이트웨이 (MCP gateway)는 특정한 아키텍처적 가설을 바탕으로 구축되었습니다. 즉, LLM 워크로드를 관리하는 팀이 MCP 오케스트레이션 (orchestration)을 위해 별도의 인프라를 운영할 필요가 없어야 한다는 것입니다. 통합 플랫폼이 이 두 가지를 모두 처리하며, LLM 호출과 도구 호출 (tool calls) 모두에 동일한 보안 (security), 관찰 가능성 (observability), 및 속도 제한 (rate-limiting) 메커니즘을 적용합니다.

문서에 명시된 성능 수치는 구체적입니다. 데이터베이스 조회 대신 인메모리 인증 (in-memory auth) 및 속도 제한 덕분에 단일 vCPU에서 *3ms 미만의 지연 시간 (latency), 350+ RPS (초당 요청 수)*를 달성한다고 주장합니다. 아키텍처상 이는 타당해 보이지만, 이러한 수치에 대한 공개된 벤치마크 방법론이나 테스트 구성 (test configuration)은 없습니다. [필요 사항: 독자들이 직접 재현하거나 자신의 워크로드와 비교할 수 있도록 페이로드 크기 (payload size), 모델 크기, 인프라 사양, 테스트 하네스 (test harness) 등의 테스트 구성 상세 정보가 필요합니다.] 지연 시간이 엄격한 요구 사항이라면, 용량을 계획하기 전에 직접 테스트를 수행하십시오.

진정으로 강력한 부분은 다음과 같습니다: LLM 및 도구 사용 전반에 걸친 통합 빌링 (billing) 및 관찰 가능성 (observability), 별도의 게이트웨이 배포 없이 팀별 격리를 제공하는 MCP 서버 그룹 (MCP Server Groups), 그리고 여러 언어에 걸쳐 프로덕션 준비가 된 클라이언트 코드를 생성하는 대화형 플레이그라운드 (playground)입니다. 만약 이미 TrueFoundry의 AI 게이트웨이 (AI gateway)를 통해 LLM 비용을 추적하고 있다면, 동일한 대시보드에서 통합된 도구 호출 데이터를 얻는 것은 단순한 기능 체크박스 이상의 실제적인 운영상의 이점입니다.

약점: 이것은 풀 플랫폼 (full-platform) 제품이므로, 더 광범위한 의존성을 채택하게 된다는 것을 의미합니다. 만약 가볍고 독립적인 MCP 프록시 (proxy)를 원한다면, TrueFoundry는 필요 이상의 과한 도구입니다. 또한 상용 제품이기에, 가격 정보가 소규모 팀이 빠르게 평가하기 쉬운 방식으로 공개되어 있지 않습니다. [필요 사항: 가격 정보 또는 최소한의 규모 범위 정보 필요.]

가장 적합한 경우: 이미 TrueFoundry에서 상당한 AI 워크로드 (workloads)를 실행 중인 팀, 또는 통합된 비용 가시성을 바탕으로 LLM 라우팅 (routing)과 MCP 오케스트레이션 (orchestration)을 모두 단일 벤더가 관리하기를 원하는 팀.

2. Docker MCP Gateway

Docker는 자신의 핵심 역량인 컨테이너 격리 (container isolation) 기술을 MCP 문제에 적용했으며, 그 결과는 일관적입니다. 각 MCP 서버는 CPU 1코어 제한, 메모리 2GB 제한, 그리고 기본적으로 호스트 파일 시스템 접근이 차단된 자체 컨테이너 내에서 실행됩니다. 암호학적으로 서명된 컨테이너 이미지 (container images)는 이 목록의 다른 어떤 도구도 대등한 수준을 갖추지 못한 방식으로 공급망 보안 (supply chain security) 문제를 해결합니다.

Docker MCP 카탈로그 (Catalog)에는 현재 300개 이상의 검증된 사전 패키징 서버 이미지들이 포함되어 있습니다. 이는 여기서 제시된 옵션 중 가장 큰 규모의 사전 구축 라이브러리이며, 새로운 도구를 시도하는 장벽을 크게 낮춰줍니다. 수십 개의 서버를 동시에 평가할 때, "이 이미지를 가져오기(pull)\

최적의 활용 사례: 컨테이너 우선 인프라 팀, 코드 실행 또는 높은 격리 요구 사항이 포함된 유스케이스(이 경우 리소스 제한(resource caps)이 매우 중요함), 그리고 커스텀 배포 스크립트를 관리하지 않고도 많은 MCP 서버에 걸쳐 표준화된 패키징을 원하는 팀.

3. IBM ContextForge

다른 일부 글에서 볼 수 있는 프레임워크에 대해 한 가지 중요한 정정 사항이 있습니다: IBM ContextForge는 더 이상 알파/베타 단계가 아니며, "상업적 지원 없음"이라는 표현도 더 이상 정확하지 않습니다. IBM은 v1.0.0-GA를 출시했으며 상업적 배포를 위한 IBM Elite Support를 제공합니다. 이 프로젝트는 현재 100명 이상의 오픈 소스 기여자(open source contributors)를 보유하고 있으며, 160,000명 이상의 사용자에게 서비스를 제공하는 IBM Consulting Advantage의 기반이 되고 있습니다. 이는 실험적인 사이드 프로젝트가 아닙니다. 그러한 프레임워크는 시대에 뒤떨어진 것입니다.

정정된 내용을 바탕으로 보면: ContextForge의 연합(federation) 기능은 여기서 소개된 그 어떤 옵션보다 아키텍처적으로 가장 정교합니다. mDNS를 통한 자동 검색(Auto-discovery), 게이트웨이 인스턴스 전반의 상태 모니터링(health monitoring), 그리고 여러 게이트웨이가 하나의 통합된 엔드포인트(endpoint)로 나타날 수 있게 하는 기능 병합(capability merging)은 여러 팀이나 지역이 각각 자체 MCP 인프라를 관리하는 진정으로 복잡한 배포 환경에서 매우 중요한 기능들입니다. 가상 서버 구성(Virtual server composition)을 통해 여러 MCP 백엔드를 하나의 논리적 엔드포인트로 결합할 수 있어, 백엔드를 재구조화하지 않고도 에이전트(agent)와의 상호작용을 단순화할 수 있습니다.

인증(Authentication)의 유연성 또한 주목할 만합니다: JWT Bearer, 기본 인증(Basic Auth), 커스텀 헤더 스킴(custom header schemes), 도구 자격 증명을 위한 AES 암호화, 그리고 멀티 데이터베이스 백엔드 지원(PostgreSQL, MySQL, SQLite)이 포함됩니다. 기존의 엔터프라이즈 ID 시스템과 통합해야 하는 경우 이 점이 중요합니다.

ContextForge가 약한 부분: 개발자 경험(developer experience)이 Docker나 TrueFoundry보다 까다롭습니다. 설정에는 더 많은 인프라 전문 지식이 필요하며, 지연 시간 오버헤드(소스당 100–300ms, 벤치마크 기준 [NEEDS: methodology])는 더 가벼운 옵션들보다 유의미하게 높습니다. 또한, 클라우드 불가지론적(cloud-agnostic) 배포와 비교했을 때 IBM 자체 클라우드 서비스와 얼마나 긴밀하게 통합되는지도 평가할 가치가 있습니다.

최적의 용도: 여러 환경이나 지역에 걸쳐 다중 게이트웨이 배포를 예상하는 대기업 — 이 도구는 처음부터 연합(federation)을 위해 설계된 유일한 도구입니다. 인프라 복잡성에 익숙한 팀이 필요합니다.

4. Microsoft MCP Gateway (Azure)

Microsoft의 접근 방식은 단일 제품이 아닙니다. 게이트웨이 책임을 함께 처리하는 Azure 서비스 전반의 통합 지점(integration points) 세트입니다. Azure API Management은 정책 집행(policy enforcement) 및 OAuth 흐름을 처리하고, Azure App Service 및 Functions는 서버 호스팅을 담당하며, Microsoft Entra ID는 인증 및 RBAC(역할 기반 액세스 제어)를 처리합니다. 최근 Build 2026 업데이트에서는 Azure App Service를 위한 내장형 MCP가 추가되었으며, 네이티브 Entra 인증을 통해 Functions MCP 확장 기능이 개선되었습니다.

Azure 네이티브 조직의 경우, 이러한 네이티브 통합은 실질적인 이점입니다. OAuth 흐름이 추가 구성 없이 작동합니다. Entra ID 정책이 직접 적용됩니다. Azure Resource Manager(ARM) MCP 서버는 에이전트에게 인프라 운영에 대한 퍼스트 클래스(first-class) 액세스를 제공합니다. 즉, 다른 게이트웨이를 사용할 때 상당한 커스텀 통합이 필요한 방식인 ARM을 통해 Azure 리소스를 쿼리, 배포 및 관리할 수 있습니다.

Microsoft가 확실히 승리하는 지점: 보안 및 컴플라이언스 태세가 Entra ID를 중심으로 구축되어 있고, 에이전트가 주로 Azure 호스팅 서비스와 상호 작용하는 경우, 네이티브 ID 흐름은 단순한 외관상의 차이가 아닌 실질적인 가치를 제공합니다. 여기 있는 다른 어떤 도구도 Azure 네이티브 시나리오에서 이와 대등하지 않습니다.

취약한 지점: Azure 생태계 외부의 모든 것. 멀티 클라우드 또는 하이브리드 배포에는 상당한 커스텀 작업이 필요합니다. 운영 표면(operational surface area)이 넓습니다. 즉, 단일 게이트웨이 제품을 관리하는 것이 아니라 여러 Azure 서비스를 관리해야 하며, 포괄적인 모니터링을 구현하려면 Azure Monitor, Application Insights 및 서비스별 로깅을 서로 연결해야 합니다.

가장 적합한 경우: Entra ID 투자를 직접 활용할 수 있는 Azure 전용 조직. 멀티 클라우드 아키텍처나 단일 콘솔에서 빠른 설정 및 중앙 집중식 관측성 (Observability)을 필요로 하는 팀에게는 적합하지 않습니다.

5. Lasso Security

Lasso (2024 Gartner Cool Vendor for AI Security — 검증됨)는 다른 도구들이 부차적으로 취급하는 문제, 즉 AI 에이전트가 도구와 상호작용할 때 대부분의 게이트웨이 인프라가 해당 상호작용이 정당한지 아니면 악의적인지에 대해 거의 아무런 가시성 (Visibility)을 제공하지 못한다는 문제를 중심으로 구축되었습니다.

주요 기능:
MCP 도구에 도달하기 전에 악의적인 입력을 차단하는 실시간 프롬프트 인젝션 (Prompt Injection) 탐지; 행동 패턴, 코드 분석 및 커뮤니티 데이터를 기반으로 한 MCP 서버 평판 점수 산정 (플래그가 지정된 서버를 자동으로 차단하여 탈취된 도구 패키지로부터의 공급망 공격 (Supply Chain Attack)에 대응); 도구 호출 로그에서 자격 증명 노출을 방지하기 위한 토큰 마스킹 (Token Masking). 플러그인 기반 아키텍처를 통해 조직은 모든 기능을 한꺼번에 도입하는 대신 보안 제어 기능을 점진적으로 추가할 수 있습니다.

이 도구는 에이전트 보안을 주요 설계 축으로 삼아 구축된 유일한 도구입니다. 이는 보안 기능의 깊이뿐만 아니라 일반적인 게이트웨이로서 부족한 부분에서도 나타나는데, 완전한 오케스트레이션 (Orchestration) 인프라라기보다는 보안 오버레이 (Security Overlay)에 가깝습니다.

Lasso가 확실히 우위를 점하는 분야: 에이전트의 도구 접근이 중대한 보안 위협 표면 (Security Surface)이 되는 규제 산업 및 환경. 민감한 데이터를 다루는 의료, 금융 서비스 및 법률 분야는 범용 보안 도구가 제공하지 못하는, AI 에이전트 행동 패턴에 특화된 위협 탐지 기능을 사용할 수 있습니다.

약점: 보안 스캐닝으로 인해 지연 시간 (Latency) 오버헤드가 발생하며 (소스별 벤치마크 기준 100~250ms 범위 [방법론 필요]), 이는 빈번한 도구 호출 시 누적됩니다. 또한 완전한 게이트웨이 대체재는 아닙니다. 대부분의 팀은 라우팅 및 관리 계층을 위해 Docker 또는 TrueFoundry와 함께 이를 병행하여 실행할 것입니다.

최적의 용도: 규제 산업, 에이전트 도구 접근과 관련된 보안 사고가 심각한 후속 영향을 미칠 수 있는 모든 팀. 단독 솔루션보다는 다른 게이트웨이와 병행하여 사용될 가능성이 높음.

선택 방법

순위가 매겨진 목록 대신, 상황별로 도구를 매칭하는 방법은 다음과 같습니다:

• 이미 LLM 라우팅을 위해 TrueFoundry를 사용 중이며, 통합된 비용 관리 및 관측성 (Observability)을 원하는 경우 → TrueFoundry
• 컨테이너 우선 인프라 (Container-first infra)를 사용 중이며, 코드 실행 격리 (Code execution isolation)가 필요하고, 이미 구축된 방대한 서버 카탈로그를 원하는 경우 → Docker
• 여러 환경이나 지역에 걸쳐 다중 게이트웨이 배포가 이루어지며, 연합 (Federation)이 실제 요구 사항인 경우 → IBM ContextForge
• Azure 네이티브 환경이며, Entra ID가 ID 체계의 중추이고, 에이전트가 주로 Azure 서비스와 상호작용하는 경우 → Microsoft
• 규제 산업이며, 에이전트 보안 위협 탐지 (Security threat detection)가 타협 불가능한 필수 사항인 경우 → Lasso Security (위의 도구 중 하나와 계층적으로 함께 사용될 가능성이 높음)