MCP 게이트웨이: 대규모 환경에서 여러 MCP 서버를 관리하는 방법

대부분의 경우, 한 대의 MCP 서버로 시작합니다. 개발자가 GitHub를 Claude나 Cursor에 연결하면 바로 작동합니다. 그러다 누군가가 Slack을 추가하고, Jira를 추가하고, 내부 데이터베이스까지 추가하게 됩니다.

6개월이 지나면 모든 개발자는 각자 고유한 구성 파일, API 키, 서버 목록을 갖게 됩니다.

현재는 어떤 에이전트가 프로덕션 데이터에 접근할 수 있는지 알 수 없습니다. 엔지니어가 퇴사하면, 그 사람이 생성한 모든 토큰을 일일이 추적해야 합니다. 새로운 서버를 추가하려면 15개의 클라이언트 구성을 수동으로 업데이트해야 합니다.

무서운 점은, 에이전트가 예상치 못한 행동을 할 때, 애초에 왜 그런 일이 발생했는지 설명해 줄 수 있는 단일 로그가 없다는 것입니다.

토큰은 두 번째 비용입니다. 연결된 모든 서버는 도구 정의를 컨텍스트 윈도우에 불러옵니다. Anthropic은 서버 5대로 구성된 한 설정에서, 에이전트가 단 하나의 요청도 읽기 전에 도구 정의에 약 55,000개의 토큰이 소요되는 것을 측정했습니다.

따라서 여러 MCP 서버를 관리하는 일은 두 가지 작업으로 귀결됩니다. 바로 한 곳에서 액세스를 제어하고, 각 에이전트의 도구 목록을 간결하게 유지하는 것입니다. MCP 게이트웨이는 기본적으로 첫 번째 작업을 처리합니다. 두 번째 작업은 도구를 필터링하거나 검색할 때만 처리합니다. 이번 글에서는 평가해 볼 만한 5가지 게이트웨이와 각 게이트웨이의 비용, 그리고 에이전트에 차질을 주지 않고 게이트웨이를 도입하는 방법을 살펴보겠습니다.

MCP 게이트웨이란 무엇인가?

요청이 들어오면 게이트웨이는 요청자가 누구인지, 그리고 해당 사용자나 에이전트가 어떤 도구를 볼 수 있는지 확인합니다. 각 업스트림 서버에서 도구 정의를 가져와 이름 앞에 접두사를 붙여 github_create_issue와 jira_create_issue가 충돌하지 않도록 합니다. 필터링되어 제외된 항목은 모두 제거되므로, 모델은 하나의 깔끔한 목록만 확인하게 됩니다.

모델이 도구를 선택하면, 게이트웨이는 해당 도구를 소유한 서버로 호출을 라우팅하고 해당 서버의 인증 정보를 첨부합니다. 대부분의 제품에서 에이전트는 이러한 정보를 절대 보유하지 않습니다. 모든 호출은 하나의 지점을 통과하므로, 게이트웨이는 어떤 호출이 이루어졌는지, 누가 호출했는지, 그리고 어떤 결과가 반환되었는지를 기록할 수 있습니다.

tool 선택과 서버 보안은 여전히 필터링 및 권한 설정 방식에 따라 달라지며, 이에 대해서는 아래의 사용 방법 섹션에서 다루겠습니다.

MCP 게이트웨이는 레지스트리, LLM 게이트웨이, API 게이트웨이와 어떻게 다른가요?

이 네 가지 모두 클라이언트와 클라이언트가 필요로 하는 대상 사이에 위치하기 때문에, 팀들이 이를 혼동하는 것입니다.

차이점은 각 구성 요소가 처리하는 트래픽에 있습니다. MCP 게이트웨이는 에이전트가 tool을 호출할 수 있는지 여부를 결정하는 반면, 레지스트리는 클라이언트에게 어떤 서버가 존재하는지 알려줄 뿐 요청을 전달하지는 않습니다. LLM과 API 게이트웨이는 서로 다른 트래픽을 처리합니다. 전자는 프롬프트에 응답할 모델을 선택하고, 후자는 서비스로 전송되는 일반 HTTP 호출을 보호합니다.

실제로는 그 경계가 모호합니다. 예시로, Kong AI Gateway와 같은 tools는 LLM 및 MCP 트래픽을 하나의 제어 플레인을 통해 전송하며, ContextForge는 게이트웨이와 함께 레지스트리를 운영합니다. 제품을 비교할 때는 각 제품이 실제로 어떤 계층을 다루는지 확인하십시오.

Anthropic, GitHub, PulseMCP, Microsoft의 지원을 받아 2025년 9월에 출시된 공식 MCP 레지스트리는 1년이 지난 지금도 여전히 프리뷰 단계에 머물러 있습니다. 이 레지스트리를 사용하여 서버를 검색하되, 승인된 서버 목록은 직접 관리하십시오.

MCP 게이트웨이가 토큰 사용량을 줄여주나요?

네, 하지만 도구를 필터링하거나 검색할 때만 그렇습니다. 모든 MCP 서버에는 일련의 도구가 포함되어 있으며, 각 도구에는 AI가 사용하기 전에 반드시 읽어야 하는 설명이 작성되어 있습니다. 그리고 이러한 설명은 토큰을 소모합니다. 게이트웨이는 모든 서버를 한곳에 모아줍니다. 필터링하도록 설정하지 않는 한, 여전히 모든 서버의 모든 도구를 AI에 보여주기 때문에 AI는 이전과 똑같은 양의 설명을 읽게 됩니다.

게이트웨이가 해당 작업에 필요 없는 tools를 숨겨줄 때만 토큰을 절약할 수 있습니다.

비용은 문제의 절반에 불과합니다. 흔한 실패 요인은 모델이 잘못된 도구를 선택하거나 잘못된 매개변수를 전달할 때 발생합니다. 특히 ‘notification-send-user’와 ‘notification-send-channel’처럼 도구 이름이 유사한 경우 이런 현상이 자주 나타납니다. Anthropic의 문서에 따르면, 사용 가능한 도구가 30~50개를 넘으면 도구 선택 정확도가 떨어지기 시작하며, 서버 몇 대만으로도 이 한도를 쉽게 초과할 수 있습니다.

Anthropic이 권장하는 해결책은 검색 도구를 미리 불러온 다음, 작업에 필요한 3~5개의 도구만 불러오는 것입니다. 50개 이상의 MCP 도구를 사용한 테스트에서 총 컨텍스트는 약 77,000 토큰에서 약 8,700 토큰으로 감소했으며, Anthropic은 이를 85% 감소라고 보고했습니다. 내부 MCP 평가에서의 정확도도 상승했습니다. 도구 검색 기능을 활성화했을 때 Opus 4의 정확도는 49%에서 74%로, Opus 4.5는 79.5%에서 88.1%로 향상되었습니다.

MCP를 활용한 코드 실행에 대한 이 회사의 연구 결과는 여기서 그치지 않습니다. 에이전트가 도구 파일이 담긴 폴더를 탐색하여 필요한 정의만 읽어들였을 때, Google Drive에서 Salesforce로 전송되는 한 워크플로우의 토큰 수가 150,000개에서 2,000개로 감소했습니다. 하지만 이 접근 방식은 에이전트가 작성하는 코드를 실행하기 위한 샌드박스 환경이 필요하며, 이는 그 자체로 운영 비용을 발생시킵니다.

게이트웨이는 이에 대응할 수 있는 두 가지 방법을 제공합니다.

첫 번째 방법은 도구 목록을 수동으로 정리하는 것입니다. 도커(Docker)의 프로필을 사용하면 서버별로 개별 도구를 허용 목록에 추가할 수 있고, 컨텍스트포지(ContextForge)의 가상 서버는 여러 업스트림 서버에서 선별한 도구 세트를 공개하며, 컴포지오(Composio)의 툴 라우터(Tool Router)는 세션을 고정된 목록에 고정할 수 있습니다.

두 번째는 호출 시점에서의 검색입니다. AgentCore Gateway에는 에이전트가 자연어로 쿼리를 실행할 수 있는 내장형 의미론적 검색 도구가 포함되어 있으며, Composio 역시 런타임 시점에 tools를 찾을 수 있습니다.

Anthropic의 지침에 따르면, 정의의 토큰 수가 10,000개를 초과하거나 사용하는 도구가 10개 이상일 때 조치를 취해야 합니다. 대부분의 AI 워크플로우 자동화 설정은 이 기준을 빠르게 초과하며, 다중 에이전트 워크플로는 더 빨리 이 기준을 초과합니다.

가장 우수한 MCP 게이트웨이는 무엇일까요?

자신을 MCP 게이트웨이라고 칭하는 제품은 많지만, 그중 일부는 서버 디렉터리에 가깝습니다. 이 목록은 설정 구조의 중심에 위치하는 도구들만을 다루고 있습니다. 에이전트는 하나의 엔드포인트에 연결되고, 게이트웨이는 그 뒤에 있는 서버들에 접근하며, 사용자는 통과하는 트래픽에 대해 적어도 한 가지 실질적인 제어권을 갖게 됩니다.

이러한 제어 수단으로는 로그인, tool 허용 목록, 감사 로그 등이 있을 수 있습니다.

다섯 가지가 최종 후보로 선정되었습니다. 이 모두는 동일한 문제를 해결하지만, 그 방식은 각기 다릅니다. 어떤 것을 선택할지는 에이전트가 이미 실행되고 있는 환경, 즉 개발자의 노트북, 자체 인프라, 기존 Kong 설정, AWS, 또는 SaaS 앱에 따라 결정됩니다.

1. Docker MCP 게이트웨이 (Docker 데스크탑을 이용한 로컬 개발에 가장 적합)

Docker MCP 게이트웨이는 Docker 데스크탑의 MCP 툴킷을 뒷받침하는 오픈소스 엔진입니다. 이미 툴킷이 활성화된 상태로 데스크탑을 사용 중이라면, 별도의 설정 없이도 게이트웨이가 백그라운드에서 자동으로 실행됩니다. 서버의 무분별한 증설에 대한 이 솔루션의 해답은 바로 컨테이너입니다. 각 MCP 서버는 권한, 네트워크 액세스 및 리소스가 제한된 자체 컨테이너에서 실행되며, 에이전트가 해당 도구 중 하나를 필요로 할 때만 게이트웨이가 서버를 시작합니다.

프로필을 사용하면 설정을 한곳에 통합할 수 있습니다. 프로필은 프로젝트에 필요한 서버들을 그룹화하며, Cursor, VS Code, Claude 데스크탑, Claude 코드 등 연결하는 모든 클라이언트가 동일한 설정을 사용합니다. 프로필을 OCI 레지스트리에 푸시하여 팀원들이 풀 수 있도록 하면, 수작업으로 편집한 15개의 구성 파일을 하나의 공유 정의로 대체할 수 있습니다.

프로필 내에서 GitHub.create_issue와 같은 개별 도구를 활성화하고, 해당 서버의 나머지 기능은 비활성화할 수 있습니다. 이것이 바로 Docker가 모델의 도구 목록을 간결하게 유지하는 방식입니다.

인증 정보는 구성 파일에 포함되지 않습니다. 게이트웨이는 Docker Desktop의 시크릿 저장소에서 시크릿을 가져와 서버를 시작할 때 추가하며, 필요한 서버에 대해 OAuth 로그인을 처리합니다. 내장된 로깅 및 호출 추적 기능을 통해 어떤 도구가 실행되었는지 확인할 수 있습니다. 게이트웨이는 호출을 라우팅할 뿐이며, 실제 의사 결정은 자동화를 위해 실행하는 AI 에이전트에서 이루어집니다. 시작하기 위해 Docker MCP 카탈로그에는 200개 이상의 도구와 서비스가 목록에 있습니다.

한계점: 이 게이트웨이는 자신의 컴퓨터에서 서버를 운영하는 개발자를 위해 구축되었습니다. Docker AI Governance의 일부로 판매되는 거버넌스 버전은 Docker 영업 팀을 통해서만 초대제로 제공되므로, 팀 전체에 적용되는 정책 제어를 직접 신청할 수는 없습니다. 수동 설치를 통해 Docker 데스크탑 없이도 게이트웨이를 실행할 수 있지만, 시크릿 관리는 여전히 데스크탑에 의존합니다.

실제 사용자들은 Docker MCP 게이트웨이에 대해 어떻게 평가하고 있을까요?

한 사용자의 리뷰에 따르면:

Docker의 MCP 게이트웨이는 로컬 개발 환경에서는 정말 유용합니다. 서버별 컨테이너 격리 기능과 Docker 데스크탑에 내장된 자격 증명 관리 기능 등이 있지만, 팀 간 및 리전 간 기업 거버넌스를 위해 설계된 것은 아닙니다.

2. IBM ContextForge (자체 호스팅, 팀별 도구 세트에 가장 적합)

IBM ContextForge는 자체 인프라에서 실행하는 오픈소스 게이트웨이이자 레지스트리입니다. 이 솔루션은 MCP 서버, 에이전트 간(A2A) 서비스, 일반 REST 또는 gRPC API를 하나의 엔드포인트 뒤에 통합합니다. PyPI에서 설치하거나, 컨테이너로 실행하거나, 프로젝트의 Helm 차트를 사용하여 Kubernetes에 배포할 수 있습니다.

이 솔루션의 차별화된 점은 바로 가상 서버입니다. 게이트웨이에 등록된 모든 도구 중에서 필요한 것을 선택해 하나의 이름으로 묶은 다음, 클라이언트가 해당 번들의 엔드포인트를 참조하도록 설정합니다. 재무 담당자는 재무 도구를, 지원 담당자는 다른 도구 세트를 사용하며, 어느 쪽도 상대방의 정의 파일을 불러오지 않습니다. 각 가상 서버는 비공개로 설정하거나 팀과 공유하거나 공개할 수 있습니다.

또한 이미 보유하고 있는 API를 MCP 도구로 변환해 줍니다. REST 엔드포인트를 지정하기만 하면 JSON 스키마를 자동으로 가져옵니다. 이 tool은 서버 리플렉션을 통해 gRPC 서비스도 변환합니다. 덕분에 모든 내부 API에 대해 래퍼 서버를 직접 작성할 필요가 없습니다.

각 업스트림 서버는 자체 OAuth 설정을 유지하며, ContextForge는 사용자별로 토큰을 저장하므로 두 서버가 서로 다른 제공자를 사용할 수 있습니다. 관리자 UI에는 실시간 로그 뷰어가 포함되어 있으며, 추적 정보는 OpenTelemetry를 통해 Jaeger, Zipkin, Datadog과 같은 백엔드로 전송됩니다. 40개 이상의 플러그인이 추가 전송 프로토콜 및 통합 기능을 제공합니다.

한계점: 실행, 패치, 확장 작업을 모두 직접 수행해야 합니다. 강력한 비밀 키를 생성하기 전까지는 게이트웨이가 시작되지 않습니다. 이 프로젝트는 프로덕션 환경에서 PostgreSQL 사용을 권장하며, 지원은 GitHub 문제 및 토론을 통해 이루어집니다.

실제 사용자들은 IBM ContextForge에 대해 어떻게 평가하고 있을까요?

한 사용자의 리뷰에 따르면:

아파치 라이선스를 적용했으며, 이미 본격적인 쿠버네티스 인프라를 운영 중인 사용자를 위해 설계되었습니다. 이 솔루션은 진정한 거버넌스와 모니터링 기능을 갖추고, 회사의 다른 API와 함께 MCP를 관리할 수 있는 등 실질적으로 유능한 솔루션으로 성숙해졌습니다. 다만, 소규모 옵션들에 비해 구축이 더 까다로워 주말에 가볍게 해볼 수 있는 프로젝트는 아닙니다.

3. Kong AI Gateway (이미 Kong을 운영 중인 팀에 가장 적합)

Kong은 MCP 트래픽을 또 다른 종류의 API 트래픽으로 취급합니다. 팀에서 이미 Kong Gateway 또는 Kong Konnect를 운영 중이라면, MCP 지원 기능은 기존에 운영 중인 게이트웨이의 플러그인 형태로 제공됩니다. API에 적용 중인 것과 동일한 인증, 속도 제한, 로깅 기능을 활용하게 됩니다.

핵심은 AI MCP 프록시 플러그인입니다. 이 플러그인은 이미 운영 중인 MCP 서버 앞에 배치하거나, 맞춤형 코드 없이 OpenAPI 스키마를 사용하는 모든 API를 MCP 도구로 변환할 수 있습니다. 또한 여러 API의 도구를 하나의 MCP 엔드포인트로 통합할 수 있으므로, 에이전트는 서비스마다 한 번씩 연결하는 대신 한 번만 연결하면 됩니다.

액세스 제어는 도구별로 작동합니다. 소비자 또는 소비자 그룹별로 허용 및 거부 목록을 설정하면, 에이전트가 도구 목록을 요청할 때 Kong은 해당 호출자가 사용할 수 있는 도구만 반환합니다. 허용되거나 거부된 모든 시도는 플러그인의 감사 로그에 기록됩니다. 에이전트는 호출할 수 없는 도구는 절대 로드하지 않기 때문에, 필터링된 목록은 컨텍스트의 크기도 작게 유지합니다.

로그인은 OpenID Connect 및 AI MCP OAuth2 플러그인을 포함한 Kong의 인증 플러그인을 통해 처리됩니다. MCP 트래픽 로그에는 세션 ID, JSON-RPC 메서드, 페이로드, 지연 시간 및 오류가 기록되며, OpenTelemetry로 트레이스를 전송할 수 있습니다. 또한 Kong의 AI 게이트웨이를 통해 LLM 트래픽을 라우팅할 경우, 모델 트래픽과 도구 트래픽은 하나의 제어 플레인을 공유합니다.

한계점: Konnect에서 SSO 및 플랫폼 감사 로그는 Enterprise 에디션에서만 사용할 수 있습니다. AI MCP 프록시 플러그인은 WebSocket 또는 gRPC 업스트림을 지원하지 않으며, AI 가드레일은 MCP 요청에는 적용되지 않습니다. REST 변환을 위해서는 각 API에 대해 유효한 OpenAPI 스키마가 필요하며, 도구별 ACL을 사용하려면 Kong Gateway 3.13 이상이 필요합니다. MCP 클라이언트에서 발신되는 핑도 월간 요청 총량에 포함됩니다.

실제 사용자들은 Kong AI Gateway에 대해 어떤 평가를 내리고 있을까요?

한 사용자의 리뷰는 다음과 같습니다:

이미 Kong을 사용 중이라면 이 선택이 합리적입니다. 이는 더 이상 단순히 MCP를 덧붙인 수준이 아니라, 에이전트 간 트래픽을 포함한 진정한 목적에 맞게 설계된 지원이며, 7월 중순에는 AI 거버넌스 기업과 제휴하여 정책 검사를 게이트웨이에 직접 연동했습니다. 다만 일부 심층적인 기능은 유료 요금제가 필요할 수도 있습니다.

4. Amazon Bedrock AgentCore 게이트웨이 (AWS에서 실행되는 에이전트에 가장 적합)

Amazon Bedrock AgentCore Gateway는 AWS의 완전 관리형 옵션이므로 호스팅하거나 확장할 필요가 없습니다. 에이전트에게 도구를 위한 단일 엔드포인트를 제공합니다. 또한 AgentCore는 맞춤형 코드 없이 OpenAPI 및 Smithy 사양, Lambda 함수, 기존 MCP 서버를 MCP 도구로 변환합니다. Salesforce, Slack, Jira, Asana, Zendesk에 대한 원클릭 통합 기능도 포함되어 있습니다.

도구 검색 기능이 내장되어 있습니다. 게이트웨이를 생성할 때 시맨틱 검색을 활성화하면, 에이전트는 자연어로 쿼리를 실행할 수 있는 검색 도구(x_amz_bedrock_agentcore_search)를 얻게 됩니다. 이를 통해 에이전트는 전체 카탈로그를 불러오는 대신, 해당 작업에 필요한 도구만 가져옵니다. 이는 Anthropic이 설명한 것과 동일한 온디맨드 패턴으로, 클라이언트가 아닌 게이트웨이에서 실행됩니다.

인증은 양방향으로 이루어집니다. 요청이 들어올 때 게이트웨이는 AWS IAM 또는 ID 제공자의 JWT를 통해 호출 주체를 확인합니다. 요청이 나가는 과정에서 게이트웨이는 OAuth, API 키 또는 IAM 역할을 사용하여 각 도구에 로그인하고, 해당 자격 증명을 직접 추가하므로 에이전트는 이를 절대 보유하지 않습니다. 게이트웨이를 통해 사용할 경우 AgentCore Identity는 추가 비용이 들지 않으며, AgentCore Policy는 Cedar로 작성된 규칙에 따라 각 도구 호출을 검증할 수 있습니다.

이 게이트웨이는 CrewAI, LangGraph, LlamaIndex, Strands Agents를 비롯한 오픈소스 프레임워크는 물론, 어떤 모델과도 연동됩니다. 2026년 6월 업데이트를 통해 MCP 프롬프트 및 리소스, 스트리밍 및 세션 관리, 작업 중 승인 요청 기능, 그리고 OAuth 대리 토큰 교환 기능이 추가되었습니다.

단점: AWS에서만 실행되므로 자체 호스팅이 불가능합니다. 여러 AgentCore 서비스에 걸쳐 사용량 기반 요금제가 적용되므로, 정액제보다 월간 비용을 예측하기 어렵습니다. AWS가 제시한 예시에 따르면, 매월 5천만 건의 상호작용을 처리하는 에이전트(각 상호작용당 검색 1회, tool 호출 4회)의 경우 월 비용이 약 2,250달러이며, 이 중 검색 비용이 절반 이상을 차지합니다. 시맨틱 검색은 18개 AWS 리전에서 사용할 수 있습니다. 각 게이트웨이는 사용자가 구성한 MCP 프로토콜 버전만 허용하며, 가시성 기능은 CloudWatch를 통해 제공되므로 별도의 비용이 발생합니다.

실제 사용자들은 Amazon Bedrock AgentCore Gateway에 대해 어떻게 평가하고 있을까요?

한 사용자의 리뷰에 따르면:

복잡성은 여러 측면에서 비롯됩니다. 1) 사용자는 AWS 자격 증명과 환경을 설정해야 합니다. 2) 개발자는 AgentCore를 사용하기 위해 에이전트 코드를 직접 작성하고 주석을 달아야 합니다. 3) 컨텍스트 관리에는 모든 프레임워크에서 작동하지 않을 수도 있는 특정 프로그래밍 모델이 필요합니다.

5. Composio (서버를 실행하지 않고 에이전트를 SaaS 앱에 연결하는 데 가장 적합)

Composio는 에이전트를 Gmail, Slack, GitHub, HubSpot, Salesforce 등 1,500개 이상의 앱과 연결해 주는 관리형 플랫폼입니다. 별도의 서버를 운영할 필요가 없습니다. 에이전트나 AI 클라이언트가 하나의 MCP URL에 연결하기만 하면, Composio가 OAuth 흐름과 API 키부터 토큰 갱신에 이르기까지 각 앱의 로그인 절차를 모두 처리합니다.

게이트웨이 작업의 대부분은 툴 라우터(Tool Router)에서 이루어집니다. 사용자에게 필요한 툴킷을 포함하여 각 사용자별로 세션을 생성하면, Composio는 범위 지정된 MCP 엔드포인트를 반환합니다. 세션 내에서 정확한 툴 목록을 핀하거나, 특정 툴을 블록하거나, 읽기 전용(read-only)이나 파괴적(destructive)과 같은 MCP 힌트를 기준으로 필터링할 수 있습니다. 또한 툴은 런타임에 자체 카탈로그를 검색하여 작업에 필요한 툴만 로드할 수 있으므로, 에이전트의 컨텍스트를 작게 유지할 수 있습니다.

권한 설정에 따라 사용자가 도구 호출을 매번 승인하거나 세션당 한 번만 승인하도록 할 수 있으며, 도구별로 ‘항상 허용’ 또는 ‘항상 거부’로 재정의할 수도 있습니다. 세션은 사용자별로 생성되므로 각 사용자의 연결된 계정은 분리되어 유지되며, 한 사용자가 동일한 앱에 여러 계정을 연결할 수도 있습니다. 앱이 카탈로그에 없지만 MCP 서버가 있는 경우, 이를 맞춤형 서버로 무료로 추가할 수 있습니다.

이 서비스는 Claude, ChatGPT, Cursor, Claude Code 및 기타 모든 MCP 클라이언트는 물론, LangChain, LlamaIndex, CrewAI, OpenAI Agents SDK와 같은 프레임워크와도 호환됩니다. 다단계 작업의 경우, Composio는 각 실행이 자체적으로 격리된 샌드박스에서 수행되는 원격 런타임을 제공합니다. 이 회사는 SOC 2 Type II 준수 및 ISO 27001:2022 인증을 획득했다고 보고했습니다.

두드러지는 기능

가격

평가

한계점: 이 서비스는 관리형 서비스이므로, BYOC(Bring-Your-Own-Cloud) 배포를 설정하지 않는 한 도구 호출과 사용자의 저장된 인증 정보는 Composio의 클라우드를 통해 처리됩니다. MCP를 통해 연결할 경우, SDK의 도구 호출 훅과 스키마 변경은 실행되지 않으며, 맞춤형 코드에서 정의된 맞춤형 도구는 MCP 엔드포인트에서 사용할 수 없습니다. 2026년 5월, Composio는 활성 연결의 약 0.3%(대부분 GitHub 연결)가 노출된 보안 인시던트를 공개했으며, 이에 따라 고객들은 API 키를 갱신해야 했습니다. 보안 검토 시 해당 보고서를 반드시 포함하십시오.

실제 사용자들은 Composio에 대해 어떻게 평가하고 있을까요?

한 사용자의 리뷰에 따르면:

방대한 라이브러리를 갖춘 관리형 MCP 플랫폼으로, Gmail이나 Slack과 같은 1,000개 이상의 앱을 지원합니다. 가장 큰 장점은 모든 통합 기능을 직접 구축하고 유지 관리할 필요가 없다는 점이며, Composio는 유연한 배포 옵션을 위해 VPC 내 자체 호스팅 및 임베디드 SDK도 지원합니다.

MCP 게이트웨이의 비용은 얼마인가요?

가격은 관리형 서비스를 이용하는지, 아니면 인프라를 직접 운영하는지에 따라 달라집니다.

오픈소스 게이트웨이는 라이선스 비용이 들지 않지만, 호스팅, 유지보수, 보안 비용은 여전히 지불해야 합니다. 관리형 게이트웨이는 tool 호출, 검색, 제어 플레인 또는 기타 사용량에 대해 요금을 부과합니다.

어떤 게이트웨이가 비용이 더 저렴한지는 이미 운영 중인 환경에 따라 달라집니다. Composio와 Amazon Bedrock AgentCore Gateway는 인프라 관리 업무의 상당 부분을 공급업체 측으로 이전하며, 사용량에 따라 요금을 부과합니다. Docker MCP Gateway와 IBM ContextForge는 라이선스 비용이 없지만, 호스팅 및 유지보수 비용은 사용자가 부담해야 합니다. Kong은 팀이 이미 Kong을 운영 중인 경우 비용 면에서 가장 합리적입니다. MCP를 위해 Kong을 새로 도입할 경우, 새로운 플랫폼과 라이선스 비용이 추가되기 때문입니다.

MCP 게이트웨이 선택 방법

가격은 리스트를 좁혀주지만, 결정 자체를 대신해 주지는 않습니다.

더 나은 출발점은 여러분이 이 문제를 찾아보게 된 계기입니다. 대부분의 팀은 다음 두 가지 문제 중 하나를 안고 찾아옵니다. 누가 어떤 tool을 호출하는지 파악하거나 제어할 수 없는 경우, 혹은 에이전트가 너무 많은 tool 정의를 불러와 잘못된 tool을 선택하기 시작하는 경우입니다. 두 가지 문제를 모두 겪는 팀도 있습니다.

어떤 문제가 가장 큰 걸림돌인지 파악하면, 게이트웨이가 무엇을 잘 수행해야 하는지, 그리고 어떤 기능은 포기해도 되는지 알 수 있습니다.

에이전트가 이미 실행되고 있는 곳부터 시작하세요

이 가이드에 소개된 5가지 게이트웨이는 모두 동일한 기본 기능을 제공하므로, 결정적인 요소는 대개 이미 보유하고 있는 스택입니다.

에이전트가 주로 개별 사용자를 대신하여 SaaS 앱 내에서 작동하는 경우, Composio는 각 사용자의 OAuth 연결을 대신 관리해 주므로 가장 많은 일을 덜어줍니다. 단, 이러한 인증 정보는 Composio의 클라우드에 저장되므로 보안 팀의 검토가 필요할 수 있습니다.

개발자 노트북에 흩어져 있어 서로 연결되지 않은 워크플로우로 어려움을 겪는 팀에게 Docker MCP 게이트웨이는 당연히 선택해야 할 첫 번째 단계입니다. 이 솔루션은 이미 Docker 데스크탑을 사용 중인 팀에 적합하며, 모든 서버를 개별 컨테이너에서 실행하고 팀 전체가 하나의 프로필을 공유할 수 있게 해줍니다. 추후 팀 전체에 걸친 거버넌스가 필요해질 경우, Docker 영업 팀과 별도로 대화를 해야 합니다.

인프라를 직접 관리하기를 선호하는 플랫폼 팀은 IBM ContextForge를 선택할 가능성이 높습니다. 이 플랫폼의 가상 서버는 각 팀에 고유한 도구 세트를 제공하며, 내부 REST 및 gRPC 서비스를 MCP 도구로 전환할 수 있습니다. 또한 자체 호스팅에 수반되는 패치 적용, 확장 및 당직 일도 직접 담당해야 합니다.

Kong AI Gateway는 MCP 트래픽을 팀이 API에 대해 이미 적용하고 있는 정책과 동일한 정책 하에 관리합니다. SSO나 플랫폼 감사 로그가 필요한 경우, 두 기능 모두 Enterprise 버전에서만 제공되므로 Enterprise 버전을 위한 예산을 책정해야 합니다.

AWS 환경에서 개발하는 팀의 경우, Amazon Bedrock AgentCore Gateway를 사용하면 모든 것을 체계적으로 관리할 수 있을 뿐만 아니라 게이트웨이에서 시맨틱 도구 검색 기능도 활용할 수 있습니다. 검색 호출, 도구 호출, CloudWatch는 각각 별도로 요금이 부과되므로, 사용량 기반 요금 구조를 미리 파악해 두시기 바랍니다.

소규모 팀을 위해 안정적으로 작동하는 서버 몇 대만 운영한다면, 아직 게이트웨이가 필요하지 않을 수도 있습니다. 팀별 권한이나 중앙 집중식 로그가 필요해지기 전까지는 버전 관리 시스템에 저장된 공유 구성과 시크릿 관리 도구만으로도 동일한 기능을 대체할 수 있습니다.

커밋하기 전에 무엇을 확인해야 할까요?

유력한 후보가 정해지면, 계약에 서명하기 전에 실제 설정에서 테스트해 보십시오. 기능 페이지에는 나중에 중요해질 세부 사항이 종종 누락되어 있으므로, 보안 및 플랫폼 담당자와 함께 몇 가지 구체적인 질문을 하나씩 검토해 보십시오:

대개 그 비교 결과만으로도 결론이 나게 됩니다. 게이트웨이가 설정 변경 사항만 기록하고 에이전트가 실제로 어떤 도구를 사용했는지 보여줄 수 없다면, 감사 시 문제가 될 수 있습니다. 또한 서버를 연결할 때 도구 목록을 정리하지 않는다면, 에이전트는 여전히 모든 도구 정의를 불러오게 되어 토큰 사용량은 변함없이 유지됩니다.

기존 MCP 서버를 게이트웨이로 어떻게 마이그레이션하나요?

가장 안전한 배포 방식은 먼저 위험이 낮은 서버 한 대를 이전하고, 새로운 경로가 안정적으로 작동하는 것이 입증될 때까지 기존 경로를 계속 가동하는 것입니다.

먼저 현황 파악부터 시작하세요

각 서버에 대해 소유자가 누구인지, 어떤 tools를 제공하는지, 어떤 데이터에 접근할 수 있는지, 그리고 해당 tools 정의에 필요한 토큰 수가 대략 얼마나 되는지 확인하십시오. 이때가 바로 불필요한 요소를 정리할 때입니다. 대부분의 카탈로그에는 몇 달 동안 아무도 호출하지 않은 tools들이 포함되어 있으며, 마이그레이션 전에 이를 제거하면 거버넌스 대상 범위를 줄일 수 있습니다.

신뢰 경계에 따라 서버를 그룹화

비공개 데이터를 읽는 서버, 신뢰할 수 없는 콘텐츠를 처리하는 서버, 외부로 데이터를 전송할 수 있는 서버를 별도의 도구 세트로 분리하여, 하나의 에이전트가 이 세 가지를 모두 담당하지 않도록 하십시오. 이러한 조합 덕분에 Invariant Labs의 GitHub MCP 프롬프트 주입 데모가 가능했습니다. 또한, 각 서버가 여전히 유지 관리되고 있는지 확인하십시오. GitHub와 Slack을 포함한 초기 MCP 참조 서버 중 상당수는 현재 아카이브에 보관되어 있으며 더 이상 업데이트를 받지 않습니다.

그룹 설정이 완료되면 간단한 파일럿을 실행해 보세요

파일럿 단계가 성공적으로 완료되면, 쓰기 권한이 있는 서버를 한 대씩 순차적으로 이전하십시오. 각 이전 작업 전에 롤백 기준을 미리 설정해 두면, 인시던트 발생 중에 롤백 여부를 결정해야 하는 상황을 피할 수 있습니다. 게이트웨이 경로가 몇 주 동안 문제없이 원활하게 작동할 때까지 기존 직접 구성 방식을 유지한 후, 기존 인증 정보와 클라이언트 연결을 해제하십시오.

어떤 게이트웨이를 선택하든 적용되는 규칙이 하나 있습니다. MCP 사양은 토큰 패스스루를 금지합니다. 게이트웨이는 해당 게이트웨이를 위해 발급된 토큰만 수락해야 하며, 클라이언트의 토큰을 전달하는 대신 별도로 인증된 자체 자격 증명을 사용하여 다운스트림 서버를 호출해야 합니다. 프로덕션 트래픽을 이동하기 전에 게이트웨이 구성이 이 규칙을 따르는지 확인하십시오.

ClickUp은 MCP 게이트웨이와 어떻게 연동되나요?

ClickUp은 게이트웨이의 양쪽 끝에서 모두 MCP에 연결됩니다.

Claude, Cursor, ChatGPT와 같이 ClickUp 외부의 AI 앱은 다른 서버와 마찬가지로 게이트웨이 뒤에 위치한 ClickUp MCP 서버를 통해 작업 공간에 접근합니다. ClickUp 내부에서는 Super Agents와 Brain²가 사용자가 연결한 외부 MCP 서버의 tools를 사용할 수 있으며, 사용자의 게이트웨이도 그중 하나가 될 수 있습니다.

게이트웨이 뒤에 ClickUp MCP 서버를 배치하세요

ClickUp MCP 서버는 https://mcp.clickup.com/mcp에서 실행되며, ‘Free Forever’를 포함한 모든 플랜에서 이용할 수 있습니다. OAuth만 지원하므로, 게이트웨이에서 개인 API 키를 저장하거나 직원이 퇴사할 때 키를 갱신할 필요가 전혀 없습니다. 자체 클라이언트를 구축하는 경우, PKCE를 지원하는 OAuth 2.1을 지원해야 합니다. ClickUp은 승인된 클라이언트의 허용 목록을 관리하므로, 목록에 없는 클라이언트는 먼저 검토를 위해 제출해야 합니다.

연결이 완료되면 상담원은 작업을 생성 및 라우팅하고, 작업과 문서를 바탕으로 상태 업데이트를 작성하며, 근무 시간을 기록하고, 작업, 문서 및 댓글을 검색하고, 채팅 스레드를 요약할 수 있습니다. 이를 통해 상담원은 매번 프롬프트에 프로젝트 컨텍스트를 붙여넣기할 필요 없이 프로젝트 컨텍스트 자체를 직접 조회할 수 있습니다.

게이트웨이 뒤에서 이루어지는 속도 제한은 좀 더 자세히 살펴볼 필요가 있습니다. 이 한도는 전체 작업 공간을 포괄하며, 연결된 모든 클라이언트가 동일한 공유 할당량을 소모합니다. Everything AI 애드온이 없는 경우, ClickUp은 24시간 롤링 주기당 MCP 호출 횟수를 Free Forever 플랜에서는 100회, Enterprise 플랜에서는 최대 5,000회로 제한합니다.

애드온을 사용하면 MCP 요청은 공개 API의 분당 한도를 따르게 됩니다. 이 한도는 Free Forever, Unlimited, Business 요금제의 경우 분당 100회 요청에서 Enterprise 요금제의 경우 분당 10,000회 요청까지 범위가 다양합니다. ClickUp은 아직 MCP 사용량을 표시하지 않습니다. 여러 팀이 하나의 게이트웨이를 통해 ClickUp에 접속하는 경우, 게이트웨이에서 팀별 한도를 설정하여 한 명의 바쁜 에이전트가 다른 모든 팀원의 할당량을 소진하지 못하도록 하세요.

슈퍼 에이전트를 MCP 서버에 연결하세요

반대로, ClickUp 앱 센터에서 전체 작업 공간 또는 본인만을 대상으로 외부 MCP 서버를 연결할 수도 있습니다. 관리자는 각 연결 유형을 추가할 수 있는 사용자를 결정합니다. 서버가 연결된 후에는 각 슈퍼 에이전트가 사용할 도구를 모두 허용할지, 아니면 특정 도구만 허용할지 선택할 수 있습니다. 이는 이 가이드 앞부분에서 설명한 도구 목록 정리 방식과 동일한 개념으로, 작업 공간 내의 에이전트에 적용되는 것입니다.

연결하려는 서버가 게이트웨이인 경우, 먼저 두 가지 사항을 확인하세요. ClickUp은 변동하는 클라우드 IP 주소에서 연결되므로, IP 허용 목록만으로는 접속이 허용되지 않습니다. 또한 게이트웨이에는 OAuth 또는 API 키로 보안이 적용된 공개 URL이 필요합니다. ClickUp의 작업 공간 감사 로그에는 누가 서버에 연결, 업데이트 또는 연결을 끊었는지 기록됩니다. 각 에이전트가 실제로 어떤 도구를 호출했는지에 대한 기록을 확인하려면 게이트웨이의 로그가 필요합니다.

ClickUp에서 배포 진행 상황을 추적하세요

위의 인벤토리 및 파일럿 단계에서는 추적하기 쉬운 수많은 사소한 결정 사항들이 발생합니다. 각 서버를 리스트의 작업으로 추가하고, 소유자, 데이터 액세스, 신뢰 그룹, 토큰 비용에 대한 사용자 지정 필드를 설정하세요. 그런 다음 각 마이그레이션 작업에 연결된 문서에 롤백 기준을 기재하세요. 파일럿이 실패하거나 업스트림 서버가 아카이브될 경우, 소유자와 전체 이력이 한곳에 모두 정리되어 있습니다.

자신이 직면한 문제에 적합한 게이트웨이를 선택하세요

이 가이드의 모든 섹션은 결국 동일한 두 가지 업무로 귀결됩니다.

첫 번째는 제어 기능입니다. 단일 엔드포인트, 단일 인증 정보 저장소, 그리고 어떤 에이전트가 어떤 도구를 호출했는지에 대한 단일 기록이 제공됩니다. 이 가이드에 소개된 5가지 게이트웨이 모두 어떤 형태로든 이 기능을 지원하며, 가장 큰 차이점은 사용자가 직접 운영하는 인프라의 규모에 있습니다. 두 번째 역할은 각 에이전트의 도구 목록을 간결하게 유지하는 것이며, 게이트웨이는 필터링이나 검색 기능을 설정했을 때만 이 부분에서 도움을 줍니다.

무언가에 서명하기 전에, 사용 중인 tools를 확인하고 각 정의에 사용된 토큰의 수를 측정해 보십시오.

아무도 호출하지 않는 서버는 제외하고, 나머지는 신뢰 경계에 따라 그룹화한 뒤, 먼저 읽기 전용 서버 하나를 게이트웨이를 통해 이동시켜 보세요. 만약 ClickUp이 해당 서버 중 하나라면, ClickUp MCP 서버를 통해 연결하고 에이전트가 전체 프로젝트 컨텍스트를 바탕으로 작업, 문서, 채팅을 어떻게 처리하는지 확인해 보세요.

MCP 게이트웨이에 관한 자주 묻는 질문

가장 우수한 MCP 게이트웨이는 무엇일까요?

최적의 MCP 게이트웨이는 에이전트가 현재 어디에서 실행되고 있는지에 따라 달라집니다. Docker MCP 게이트웨이는 로컬 개발에 적합합니다. IBM ContextForge는 자체 호스팅을 원하는 팀에 적합합니다. Kong AI 게이트웨이는 이미 Kong을 사용 중인 팀에 적합하며, Amazon Bedrock AgentCore 게이트웨이는 AWS에서 실행되는 에이전트에 적합합니다. Composio는 여러 SaaS 앱에서 작동하는 에이전트에 적합합니다. 규제 대상 산업의 경우, 자체 호스팅 또는 프라이빗 배포 옵션, 도구별 액세스 제어, 개별 도구 호출 로그 기능을 확인하십시오.

MCP는 API 게이트웨이인가요?

아닙니다. 모델 컨텍스트 프로토콜(MCP)은 AI 앱이 도구 및 데이터에 연결하는 방식을 정의하는 사양입니다. MCP 게이트웨이는 해당 사양을 기반으로 구축된 소프트웨어입니다. 이 게이트웨이는 에이전트와 MCP 서버 사이에 위치하며, 액세스, 인증 정보 및 로깅을 처리합니다. 이는 HTTP와 API 게이트웨이와 같은 방식으로 작동합니다. HTTP는 요청에 대한 규칙을 설정하고, 게이트웨이는 어떤 요청을 통과시킬지 결정합니다.

MCP 게이트웨이가 필요하신가요?

여러 서버에 걸쳐 누가 어떤 도구를 호출할 수 있는지 제어하거나, 에이전트가 수행한 작업을 중앙에서 기록해 두고 싶다면 MCP 게이트웨이가 필요합니다. 소규모 팀이 안정적으로 운영되는 소수의 서버를 관리하는 경우, 버전 관리 시스템에 저장된 공유 구성과 시크릿 관리 도구만으로도 대부분의 기능을 대체할 수 있습니다. 팀별 도구 접근 권한이 필요하거나 자격 증명을 한 곳에서 관리해야 할 때 비로소 게이트웨이의 진가가 드러납니다.

게이트웨이 뒤에 위치한 MCP 서버의 보안은 어떻게 되나요?

게이트웨이는 MCP 서버의 보안을 강화하는 데 도움을 줍니다. 하지만 게이트웨이 자체만으로는 서버를 안전하게 만들지는 못합니다. 게이트웨이는 인증 정보를 한 곳에 보관하고, 각 호출자가 사용할 수 있는 도구를 제한하며, 호출 내역을 중앙에서 기록합니다. Invariant Labs가 GitHub의 MCP 서버를 통해 입증했듯이, 신뢰할 수 있는 서버를 통해서도 프롬프트 주입 공격이 발생할 수 있습니다. 비공개 데이터를 읽거나, 신뢰할 수 없는 콘텐츠를 처리하거나, 데이터를 외부로 전송하는 도구는 별도의 도구 세트로 분리하여 관리해야 합니다. 게이트웨이가 클라이언트의 토큰을 절대 전달하지 않도록 해야 합니다. 또한 더 이상 업데이트를 받지 않는 서버의 사용은 중단해야 합니다.

Tool search replaces access control.

아닙니다. 도구 검색은 에이전트가 특정 작업에 대해 어떤 도구를 볼 수 있는지 결정합니다. 접근 제어는 해당 에이전트가 해당 도구를 호출할 수 있는지 여부를 결정합니다. 예를 들어, Amazon Bedrock AgentCore Gateway는 시맨틱 검색과 인증을 별도의 기능으로 처리합니다. 호출자가 사용이 허용된 도구 내에서만 검색을 수행하고, 도구가 실제로 실행될 때 권한을 다시 확인합니다. 검색에서 도구를 숨기는 것이 유일한 보호 수단이라면, 그 도구는 실제로 보호받고 있는 것이 아닙니다.

MCP 게이트웨이 감사 로그에는 어떤 내용이 기록되어야 할까요?

MCP 게이트웨이 감사 로그에는 누가 각 호출을 수행했는지, 어떤 에이전트와 도구가 관여했는지, 어떤 서버가 이를 처리했는지, 호출이 허용되었는지 거부되었는지, 언제 발생했는지, 그리고 어떤 응답이 돌아왔는지가 기록되어야 합니다. 예를 들어, Kong의 AI MCP 프록시 플러그인은 허용 및 거부된 모든 도구 액세스 시도를 기록합니다. 구매하기 전에, 로그가 단순히 계정 및 구성 변경 사항뿐만 아니라 개별 도구 호출까지 포괄하는지 확인한 다음, 로그가 얼마나 오래 보관되는지 및 내보낼 수 있는지 확인하십시오.