MCP 게이트웨이 패턴: 정신을 잃지 않고 13,000개 이상의 서버를 관리하는 방법

47개의 MCP 서버가 실행 중입니다. 당신의 에이전트(agent)는 GitHub용, Postgres용, Slack용 서버가 필요하지만, 이 작업에 전혀 필요하지 않은 다른 44개의 서버에도 접근할 수 있습니다. 당신은 지난주에 이것을 프로덕션(production) 환경에 배포했습니다. 누군가 에이전트에게 "우리 저장소(repos)를 확인해줘"라고 요청했고, 에이전트는 호기심을 갖게 되었습니다.

MCP 생태계는 13,000개의 등록된 서버와 월간 9,700만 건의 다운로드를 기록했습니다. 이는 엄청난 능력인 동시에, 엄청난 공격 표면(attack surface)이기도 합니다.

이것은 가설이 아닙니다. 제가 본 모든 진지한 AI 에이전트 배포 사례는 이 문제를 무시하거나(모두가 모든 것에 접근), 시작 시 허용 목록(allowlist)을 하드코딩(hardcode)합니다(경직되어 있으며, 서버 업데이트 시 작동이 중단됨). 더 나은 방법이 반드시 있어야 합니다.

게이트웨이 패턴 (The Gateway Pattern)

전용 MCP 게이트웨이가 에이전트와 서버 생태계 사이에 위치합니다. 게이트웨이는 다음을 처리합니다:

1. 서버 검색 및 등록 (Server discovery and registration) — 어떤 서버가 존재하며, 어떤 도구(tools)를 노출하는가?
2. 요청 라우팅 (Request routing) — 이 특정 에이전트/작업이 호출할 수 있도록 허용된 서버는 무엇인가?
3. 감사 로깅 (Audit logging) — 각 에이전트가 언제 무엇을 호출했으며, 어떤 결과가 돌아왔는가?

이것을 AI의 도구 접근을 위한 리버스 프록시(reverse proxy)라고 생각하십시오. 에이전트는 게이트웨이와 통신하고, 게이트웨이는 실제 서버들과 통신합니다.

다음은 공식 MCP SDK를 사용한 Python 기반의 최소 기능 게이트웨이 예시입니다:

from mcp.server import Server
from mcp.types import Tool, CallToolResult
import mcp.server.stdio
...

핵심 통찰: 에이전트는 호출이 허용되지 않은 도구를 절대 볼 수 없습니다. 게이트웨이는 프롬프트(prompt) 수준이 아니라 프로토콜(protocol) 수준에서 필터링합니다.

요청 라우팅 (Routing Requests)

에이전트가 도구를 호출하면, 게이트웨이는 네임스페이스(github:create_issue)를 추출하고 그에 따라 라우팅합니다:

@server.call_tool()
async def call_tool(agent_id: str, name: str, arguments: dict) -> CallToolResult:
    allowed = AGENT_POLICIES.get(agent_id, [])
...

목록에 도구가 없으면 = 에이전트가 발견할 수 있는 도구도 없습니다. 이것은 완만한 가이드라인이 아닙니다. 프로토콜에 의해 강제됩니다.

이것이 실제로 해결하는 문제

폭발 반경 (Blast radius) 문제. 만약 에이전트가 13,000개의 도구에 접근할 수 있고 그중 하나를 악의적으로 사용한다면, 이는 재앙적인 폭발 반경을 초래합니다. 게이트웨이를 사용하면 프롬프트 (Prompt) 수준이 아닌 프로토콜 (Protocol) 수준에서 최소 권한 원칙 (Least-privilege)을 강제할 수 있습니다. 프롬프트는 탈옥 (Jailbreak)될 수 있지만, 프로토콜 강제는 그럴 수 없습니다.

감사 추적 (Audit trail). 모든 도구 호출 (Tool call)이 게이트웨이를 통과하므로, 자동으로 구조화된 로그 (Structured logs)를 얻을 수 있습니다:

{
  "agent_id": "code-review-agent",
  "server": "github",
...

이를 재생 (Replay)하거나, 이에 대해 알림을 받거나, 비용 할당 (Cost attribution) 용도로 사용할 수 있습니다.

드리프트 (Drift) 문제. 새로운 MCP 서버들이 생태계에 끊임없이 추가되고 있습니다. 등록 모델 (Registration model)을 갖춘 게이트웨이를 사용하면 새로운 서버가 자동으로 사용 가능해지지 않습니다. 반드시 명시적으로 등록되고 정책 (Policy)이 할당되어야 합니다. 예상치 못한 도구 접근은 발생하지 않습니다.

한계점

이것이 완벽한 해결책인 척하지는 않겠습니다. 몇 가지 실제적인 문제들이 있습니다:

지연 시간 (Latency). 모든 도구 호출이 추가적인 네트워크 홉 (Network hop)을 거칩니다. 지연 시간에 민감한 워크플로 (예: 수십 번의 빠른 도구 호출을 수행하는 코딩 에이전트)의 경우, 이 지연이 누적됩니다. 배포 전에 프로파일링 (Profile)을 수행하십시오.

단일 장애점 (Single point of failure)으로서의 게이트웨이. 게이트웨이가 다운되면 에이전트는 어떤 도구도 호출할 수 없습니다. 고가용성 (High availability)을 확보하려면 게이트웨이를 중복 실행해야 하며, 이는 가능하지만 비용이 들지 않는 일은 아닙니다.

대규모 정책 관리 (Policy management at scale). 서로 다른 권한 수준을 가진 50개의 에이전트를 운영하게 되면, YAML 파일 방식은 한계에 부딪힙니다. OPA, Casbin 또는 전용 서비스와 같은 실제 정책 저장소 (Policy store)가 필요합니다. 이는 더 많은 인프라를 의미합니다.

인적 요인 (Human factor). 만약 에이전트가 동적으로 새로운 권한을 요청할 수 있다면, 공격 표면 (Attack surface)을 "어떤 도구를 사용하는가"에서 "어떻게 새로운 접근 권한을 요청하는가"로 옮긴 것에 불과합니다. 이는 또 다른 문제입니다.

배운 점

MCP 생태계는 빠르게 움직이고 있습니다. 9,700만 회의 다운로드는 장난이 아닙니다. 도구는 실재하며, 능력 또한 실재하고, 보안상의 영향도 실재합니다. 게이트웨이 패턴이 새로운 것은 아니지만 (단순한 리버스 프록시 (Reverse proxy)일 뿐입니다), 이를 에이전트의 도구 접근에 적용하는 것은 문제 영역 자체가 새롭기 때문에 새롭게 느껴집니다.

지금 당장 할 수 있는 가장 실질적인 일은 다음과 같습니다: 여러분의 프로덕션 에이전트(production agents)가 실제로 어떤 MCP 서버에 접근 권한을 가지고 있는지 감사(audit)하십시오. 저는 그들이 필요로 하는 것보다 훨씬 더 많은 권한을 가지고 있을 것이라고 확신합니다.

만약 여러분이 멀티 에이전트 시스템(multi-agent system)을 운영하면서 이 부분을 고려하지 않고 있다면, 여러분은 검증되지 않은 토대 위에 시스템을 구축하고 있는 것입니다. 허용 목록(allowlist)부터 시작하십시오. 정적인 목록이라 할지라도 "항상 모든 것에 접근"하는 것보다는 훨씬 낫습니다.

Tags: ai, llm, agents, llmtools