MCP 게이트웨이와 레지스트리(MCP Gateways and Registries) — 엔터프라이즈 제어 평면(Enterprise Control Planes)

엔터프라이즈(enterprise) 환경에서는 모든 개발자가 임의의 MCP 서버를 설치하도록 둘 수 없습니다. 게이트웨이(gateway)는 인증/인가(auth), 역할 기반 접근 제어(Role-Based Access Control; RBAC), 감사(audit), 속도 제한(rate limiting), 캐싱(caching), 도구 오염(tool poisoning) 탐지를 중앙화한 뒤, 병합된 도구 표면(tool surface)을 하나의 MCP 엔드포인트로 노출합니다. 공식 MCP 레지스트리(Official MCP Registry; Anthropic + GitHub + PulseMCP + Microsoft가 함께 운영하며 네임스페이스 검증(namespace-verified)을 거침)는 표준 업스트림(canonical upstream)입니다. 이 lesson은 게이트웨이가 어디에 놓이는지 짚고, 최소 구현을 단계별로 살펴보며, 2026년의 벤더(vendor) 지형을 훑습니다.

유형: Learn
언어: Python (표준 라이브러리, 최소 게이트웨이)
선수 학습: Phase 13 · 15 (도구 오염), Phase 13 · 16 (OAuth 2.1)
소요 시간: 약 45분

학습 목표

• MCP 게이트웨이가 놓이는 위치를 설명합니다. 즉, MCP 클라이언트와 여러 백엔드(backend) MCP 서버 사이에 위치합니다.
• 게이트웨이의 다섯 가지 책임을 구현합니다. 인증(auth), 역할 기반 접근 제어(RBAC), 감사(audit), 속도 제한(rate limit), 정책(policy) 다섯 가지입니다.
• 게이트웨이 계층에서 고정된 도구 해시 매니페스트(pinned-tool-hash manifest)를 강제합니다.
• 공식 MCP 레지스트리(Official MCP Registry)와 메타레지스트리(metaregistry; Glama, MCPMarket, MCP.so, Smithery, LobeHub)를 구분합니다.

문제

포춘 500(Fortune 500) 규모의 기업에는 승인된 MCP 서버 30개, 개발자 5,000명, 컴플라이언스(compliance)와 감사 요구사항, 그리고 중앙 집중식 정책을 원하는 보안팀이 함께 존재합니다. 이런 환경에서 각 개발자가 자신의 IDE에 마음대로 서버를 설치하도록 두는 것은 시작부터 불가능합니다.

게이트웨이 패턴(gateway pattern)은 다음과 같이 동작합니다.

1. 게이트웨이는 개발자가 연결하는 단일 Streamable HTTP 엔드포인트로 실행됩니다.
2. 게이트웨이는 각 백엔드 MCP 서버의 자격 증명(credential)을 보관합니다.
3. 모든 개발자 요청은 게이트웨이 자체의 OAuth를 통해 인증되고 범위(scope)가 정해집니다.
4. 게이트웨이는 정책을 적용하면서 호출을 백엔드 서버로 라우팅(routing)합니다.
5. 모든 호출은 감사를 위해 로그로 남습니다.

Cloudflare MCP Portals, Kong AI Gateway, IBM ContextForge, MintMCP, TrueFoundry, Envoy AI Gateway는 모두 2025-2026년 사이에 게이트웨이 또는 관련 기능을 출시했습니다.

한편 공식 MCP 레지스트리(Official MCP Registry)는 표준 업스트림으로 출시되었습니다. 게이트웨이가 끌어다 쓸 수 있는, 선별되고 네임스페이스 검증을 거친 서버 목록으로, 모든 서버는 역 DNS(reverse-DNS) 형식의 이름을 갖습니다. 메타레지스트리(Glama, MCPMarket, MCP.so, Smithery, LobeHub)는 여러 출처의 서버를 한데 모아 제공합니다.

개념

게이트웨이의 다섯 가지 책임

1. 인증(Auth). OAuth 2.1로 개발자를 식별하고 사용자 역할(role)에 매핑합니다.
2. 역할 기반 접근 제어(RBAC). 사용자별 정책입니다. 어떤 서버, 어떤 도구, 어떤 범위를 허용할지 정합니다.
3. 감사(Audit). 모든 호출에 대해 누가, 무엇을, 언제, 어떤 결과로 수행했는지를 기록합니다.
4. 속도 제한(Rate limit). 사용자별, 도구별, 서버별 한도(cap)를 두어 남용을 막습니다.
5. 정책(Policy). 오염된 설명을 거부하고, 둘만의 규칙(Rule of Two)을 강제하며, 개인 식별 정보(Personally Identifiable Information; PII)를 마스킹합니다.

단일 엔드포인트로서의 게이트웨이

개발자에게 게이트웨이는 하나의 MCP 서버처럼 보입니다. 내부적으로는 N개의 백엔드로 라우팅합니다. 세션 ID(session id; Phase 13 · 09)는 이 경계에서 다시 쓰입니다.

자격 증명 금고화(Credential vaulting)

개발자는 백엔드 토큰을 절대 직접 보지 않습니다. 게이트웨이가 이 토큰을 보관하거나, 보관 역할을 대신 수행하는 신원 공급자(identity provider)로 프록시(proxy)합니다. 게이트웨이에서 notes:read 권한을 가진 개발자는 게이트웨이가 가진 자체 백엔드 자격 증명을 통해 노트 MCP 서버에 전이적(transitive)으로 접근할 수 있습니다. 단, 그 전이적 접근을 묶어 두는 정책이 있을 때에만 가능합니다.

게이트웨이의 도구 해시 고정(Tool-hash pinning at the gateway)

게이트웨이는 승인된 도구 설명의 매니페스트(SHA256 해시)를 보관합니다. 도구 발견(discovery) 시점에 각 백엔드의 tools/list를 가져오고, 해시를 매니페스트와 비교한 뒤, 설명이 변경된 도구를 제거합니다. 이는 Phase 13 · 15에서 다룬 러그 풀(rug pull) 방어를 중앙에서 적용한 것입니다.

코드로서의 정책(Policy-as-code)

고급 게이트웨이는 OPA/Rego, Kyverno, Styra 같은 도구로 정책을 표현합니다. 예를 들어 "사용자 alice는 조직 acme의 저장소에 대해서만 github.open_pr를 호출할 수 있다" 같은 규칙을 선언적(declarative)으로 인코딩합니다. 단순한 게이트웨이는 Python으로 직접 정책을 작성합니다. 두 가지 모두 유효한 형태입니다.

세션 인식 라우팅(Session-aware routing)

한 사용자의 세션에 여러 서버가 섞여 있으면 게이트웨이는 이를 다중화(multiplex)합니다. 개발자의 단일 MCP 세션이 서버마다 하나씩 N개의 백엔드 세션을 함께 보유하는 형태입니다. 어떤 백엔드에서 온 알림(notification)이든 게이트웨이를 거쳐 개발자 세션으로 라우팅됩니다.

네임스페이스 병합(Namespace merging)

게이트웨이는 모든 백엔드의 도구 네임스페이스(namespace)를 병합하며, 보통 충돌이 발생하면 접두어를 붙이는 방식(prefix-on-collision)을 사용합니다. 결과적으로 도구 이름은 github.open_pr, notes.search처럼 표시됩니다. 이 방식 덕분에 라우팅이 모호하지 않습니다.

레지스트리

• 공식 MCP 레지스트리(Official MCP Registry; registry.modelcontextprotocol.io). Anthropic, GitHub, PulseMCP, Microsoft의 공동 운영(stewardship) 아래 출시되었습니다. 네임스페이스 검증(역 DNS 규칙: io.github.user/server)을 거치며, 기본 품질이 사전에 필터링됩니다.
• Glama. 여러 출처를 모으는 검색 중심 메타레지스트리입니다.
• MCPMarket. 벤더 목록을 제공하는 상업적 성격의 디렉터리(directory)입니다.
• MCP.so. 공개 제출을 받는 커뮤니티 디렉터리입니다.
• Smithery. 패키지 매니저(package manager) 스타일의 설치 흐름을 제공합니다.
• LobeHub. LobeChat 앱 안에 UI 통합 레지스트리를 제공합니다.

엔터프라이즈 게이트웨이는 기본적으로 공식 레지스트리에서 서버를 가져오고, 관리자가 선별한 메타레지스트리 항목을 추가로 허용하며, 해시가 고정(pinned)되지 않은 것은 거부합니다.

역 DNS 네이밍(Reverse-DNS naming)

공식 레지스트리는 공개 서버에 역 DNS 형식의 이름을 요구합니다. 예: io.github.alice/notes. 이렇게 네임스페이스를 두면 이름 선점(squatting)을 막고 신뢰 위임(trust delegation)이 더 명확해집니다.

벤더 조사(Vendor survey), 2026년 4월

Phase 17(프로덕션 인프라)에서는 게이트웨이 운영을 더 깊이 다룹니다.

사용해 보기

code/main.py에는 약 150줄로 구성된 최소 게이트웨이가 들어 있습니다. 가짜 Bearer 토큰으로 사용자를 인증하고, 사용자별 RBAC 정책을 보관하며, 요청을 두 개의 백엔드 MCP 서버로 라우팅하고, 모든 호출을 감사 로그에 기록하며, 속도 제한을 강제하고, 백엔드 도구 설명 해시가 고정 매니페스트와 일치하지 않으면 호출을 거부합니다.

살펴볼 지점은 다음과 같습니다.

• RBAC 딕셔너리(dictionary)는 user_id를 키로 하여 허용된 server_tool 항목을 보관합니다.
• AUDIT_LOG는 추가만 가능한(append-only) 이벤트 목록입니다.
• 속도 제한에는 사용자별 토큰 버킷(token bucket)을 사용합니다.
• 고정 매니페스트는 server::tool -> hash 형태의 딕셔너리입니다.

산출물 만들기

이 lesson은 outputs/skill-gateway-bootstrap.md를 만듭니다. 사용자, 백엔드, 컴플라이언스 제약을 포함한 엔터프라이즈 MCP 계획이 주어지면, 이 스킬(skill)은 그에 맞는 게이트웨이 설정 명세(configuration spec)를 만들어 냅니다.

연습문제

1. code/main.py를 실행합니다. 허용된 사용자로 호출하고, 허용되지 않은 사용자로 호출하고, 속도 제한을 초과할 만큼 짧은 시간에 몰아서 보내는 버스트(burst) 호출까지 세 가지 흐름을 모두 확인합니다.

2. 결과를 클라이언트에 반환하기 전에 결과에서 개인 식별 정보(PII)를 마스킹하는 정책을 추가합니다. 주민등록번호(Social Security Number; SSN) 모양의 문자열에는 단순한 정규식 한 번(regex pass)을 사용합니다. 이메일이나 전화번호 같은 다른 형식은 이 단순 방식으로는 처리되지 않는다는 빈틈도 함께 메모해 둡니다.

3. 감사 로그가 OpenTelemetry GenAI 스팬(span)을 내보내도록 확장합니다. 정확한 속성(attribute) 정의는 Phase 13 · 20에서 다룹니다.

4. 다섯 개의 백엔드(notes, github, postgres, jira, slack)를 사용하는 50명 규모의 개발자 팀을 위한 RBAC 정책을 설계합니다. 각 백엔드에 대해 누가 읽기 전용 권한을 가지며, 누가 쓰기 권한을 가져야 하는지 정합니다.

5. Cloudflare의 엔터프라이즈 MCP 글을 처음부터 끝까지 읽습니다. 이 표준 라이브러리 기반 게이트웨이가 제공하지 않는 Cloudflare 기능을 적어도 하나 찾아 정리합니다.

핵심 용어

더 읽을거리

• Official MCP Registry — 네임스페이스가 검증된 표준 업스트림
• Cloudflare — Enterprise MCP — OAuth와 정책을 포함한 게이트웨이 패턴 소개
• agentic-community — MCP gateway registry — 오픈소스 참조 게이트웨이 구현
• TrueFoundry — What is an MCP gateway? — 게이트웨이 기능 비교 글
• IBM — MCP context forge — IBM이 공개한 엔터프라이즈 게이트웨이