요약 (TL;DR): MCP 레지스트리는 MCP 서버의 중앙 집중식 카탈로그입니다. 즉, 서버가 무엇을 하는지, 어떻게 연결하는지, 어떤 도구(tools)를 노출하는지, 그리고 누가 이를 호출할 권한이 있는지를 관리합니다. 레지스트리가 없다면 모든 개발자와 에이전트가 해당 정보를 각자 별도로 유지해야 하며, 자격 증명 교체(credential rotation) 시 모든 것이 망가지고, 접근 제어(access control)가 존재하지 않게 됩니다. 레지스트리가 있다면 도구 검색(tool discovery)이 동적으로 이루어지고, 자격 증명이 중앙에서 관리되며, RBAC(역할 기반 접근 제어)를 통해 각 에이전트가 무엇을 보고 호출할 수 있는지 제어할 수 있습니다. 이 포스트에서는 MCP 레지스트리가 무엇인지, 어떻게 작동하는지, 그리고 이를 통해 방지할 수 있는 구체적인 실패 사례들을 다룹니다.

MCP 서버가 몇 개를 넘어 규모가 커지는 거의 모든 팀에서 반복되는 패턴이 있습니다.

처음 몇 개의 연결은 마법처럼 느껴집니다. 터미널에서 npx @modelcontextprotocol/server-github를 실행하고 Claude Code를 그곳으로 지정하면, 에이전트가 갑자기 저장소(repositories)를 검색할 수 있게 됩니다. 깔끔하고 빠르며, 별도의 글루 코드(glue code)도 필요 없습니다. 그다음에는 Jira를 추가합니다. 그다음에는 Confluence를 추가합니다. 그다음에는 Slack MCP 서버와 내부 데이터 API를 추가합니다. 이제 6개의 서버와 12명의 개발자가 생겼고, 각 개발자는 하드코딩된 연결 세부 정보와 자격 증명이 담긴 자신만의 ~/.cursor/mcp.json 또는 .claude/settings.json 파일을 가지고 있습니다.

서버 엔드포인트(endpoint)가 변경되면, 12개의 설정 파일을 수동으로 업데이트해야 합니다. 자격 증명이 교체되면, 이를 캐싱하고 있는 모든 개발자를 찾아다녀야 합니다. 새로운 엔지니어가 합류하면, 어떤 서버가 존재하고 어떻게 연결하는지 설명하는 데 반나절을 소비합니다. 누군가 퇴사하면, 6개의 시스템 각각에서 그들의 개별 토큰을 회수하는 것을 잊지 않았기를 기도해야 합니다.

이것이 바로 분산된 포스트잇 문제(distributed sticky-note problem)입니다. MCP 레지스트리는 이를 대체하는 인프라입니다.

MCP 레지스트리란 무엇인가

MCP 레지스트리는 조직 내 모든 MCP 서버에 대한 메타데이터를 저장하는 중앙 집중식 카탈로그입니다. 여기에는 서버가 무엇을 하는지, 어떻게 연결하는지, 어떤 도구(tools)를 노출하는지, 어떤 인증(auth) 방식을 사용하는지, 그리고 누가 접근 권한을 가졌는지가 포함됩니다.

제가 이해했을 때 딱 와닿았던 비유는 이것입니다. MCP 레지스트리는 IP 주소에 대한 DNS 서버와 같거나, 마이크로서비스 (microservices)에 대한 서비스 레지스트리 (service registry)와 같습니다. 모든 곳에 주소를 하드코딩 (hardcoding) 하는 대신, 모든 것이 어디에 있고 어떻게 도달할 수 있는지 알고 있는 단 하나의 권위 있는 장소를 갖게 되는 것입니다. 구성 요소들은 정보를 내장하는 대신 이를 조회 (look up) 합니다.

최소한, 레지스트리 엔트리 (registry entry)에는 다음 내용이 포함됩니다:

• 서버 식별 정보 (Server identity) - 이름, 설명, 소유 팀, 승인 상태
• 연결 상세 정보 (Connection details) - 엔드포인트 (endpoint) URL, 전송 유형 (stdio vs Streamable HTTP vs SSE)
• 인증 메타데이터 (Auth metadata) - 서버가 요구하는 인증 방식 및 자격 증명 (credentials) 획득 방법
• 도구 스키마 (Tool schema) - 서버가 노출하는 도구 및 각 도구가 허용하는 파라미터 (parameters)
• 액세스 정책 (Access policy) - 연결 권한이 있는 사용자, 팀 또는 에이전트 (agents)

연결 상세 정보와 인증 메타데이터를 분리함으로써 자격 증명 교체 (credential rotation) 비용을 낮출 수 있습니다. GitHub OAuth 토큰이 교체될 때, 레지스트리의 레코드 하나만 업데이트하면 됩니다. 레지스트리를 통해 연결되는 모든 에이전트와 개발자는 자동으로 새로운 자격 증명을 가져오게 되며, 설정 파일 (config file)을 찾아 헤맬 필요가 없습니다.

N×M 문제

레지스트리가 해결하는 문제는 분산 시스템 (distributed systems)에서 다음과 같은 이름으로 불립니다: N×M 통합 문제 (N×M integration problem).

만약 N개의 에이전트와 M개의 MCP 서버가 있고 이들을 직접 연결한다면, N×M개의 통합 지점 (integration points)이 발생합니다. 각 지점은 자신만의 연결 설정, 자신만의 자격 증명, 자신만의 에러 처리 (error handling), 그리고 "서버가 이동할 때 발생하는 상황"에 대한 자신만의 버전을 가져야 합니다.

에이전트 3개와 서버 3개라면 9개의 통합 지점이 생깁니다. 에이전트 8개와 서버 6개라면 48개가 됩니다. 엔지니어 240명과 서버 8개 규모—이것이 실제 운영상의 문제가 되는 규모—라면, 약 1,900개의 설정 항목을 수동으로 관리해야 합니다.

레지스트리는 이를 압축합니다. 각 서버는 단 한 번만 등록됩니다. 각 에이전트는 레지스트리 엔드포인트에 연결하여 필요한 것을 선언하고, 레지스트리는 적절한 자격 증명과 함께 올바른 서버로 라우팅 (route) 합니다. N×M이 아닌 N+M개의 통합 지점만 존재하게 됩니다.

두 번째 이점은 다음과 같습니다: 서버가 이동할 때(새로운 URL, 새로운 클러스터, 새로운 전송 방식(transport)), 레지스트리의 항목 하나만 업데이트하면 됩니다. 그 하위의 어떤 것도 중단되지 않습니다.

레지스트리가 아닌 것

"MCP 레지스트리"라는 용어가 맥락에 따라 서로 다른 의미를 가질 수 있으므로 명확히 짚고 넘어갈 가치가 있습니다.

공용 MCP 레지스트리 (The public MCP registry) (registry.npmmcp.com 또는 이와 유사한 곳에 있는 것)는 디스커버리 카탈로그(discovery catalog)입니다. 즉, 개발자들이 도구를 찾기 위해 검색할 수 있는 공개적으로 사용 가능한 MCP 서버들의 검색 가능한 목록입니다. 이는 앱 스토어의 목록 페이지와 같습니다. 연결을 인증하거나, 액세스 제어(access control)를 강제하거나, 감사 추적(audit trail)을 제공하지는 않습니다. 서버를 찾기에는 아주 좋은 장소이지만, 프로덕션 인프라(production infrastructure)는 아닙니다.

**엔터프라이즈 MCP 레지스트리 (An enterprise MCP registry)**는 이 포스트에서 다루고자 하는 주제입니다. 인증(auth), 역할 기반 액세스 제어(RBAC), 그리고 감사 로깅(audit logging)을 통해 특정 에이전트가 특정 서버에 연결되는 방식을 관리하는 비공개 운영 카탈로그입니다. 개념은 동일하지만(중앙 집중식 메타데이터), 운영 맥락이 다릅니다.

MCP 레지스트리는 프록시(proxy)가 아닙니다. 프록시는 전송(transport)을 처리합니다. 레지스트리는 메타데이터와 정책(policy)을 처리합니다. 실제로 이 둘은 종종 함께 배포됩니다. 레지스트리는 서버에 대해 알고 있고, 프록시는 실제로 트래픽을 서버로 라우팅(route)하지만, 이들은 별개의 구성 요소입니다.

가공되지 않은 MCP(Raw MCP)의 거버넌스 공백

가공되지 않은 MCP에는 내장된 액세스 제어가 없습니다. 서버의 연결 URL을 가진 에이전트라면 무엇이든 해당 서버의 모든 도구를 호출할 수 있습니다. 주니어 개발자의 에이전트와 시니어 엔지니어의 에이전트는 동일한 권한을 가집니다. 과도한 권한을 부여받은 하위 에이전트(sub-agent)는 이를 생성한 서비스 계정(service account)과 동일한 폭발 반경(blast radius)을 가집니다.

레지스트리가 추가하는 거버넌스 계층은 다음과 같습니다:

도구 수준에서의 RBAC. 단순히 "팀 A가 Jira 서버에 접속할 수 있다"가 아니라, "팀 A는 search_issues와 create_issue는 호출할 수 있지만 delete_issue는 호출할 수 없다"와 같은 방식입니다. 액세스 정책은 레지스트리에 정의되며, 도구 호출이 서버에 도달하기 전에 강제(enforce)됩니다.

도구 호출 전 가시성 필터링 (Pre-tool-call visibility filtering). 에이전트는 애초에 자신이 사용할 권한이 있는 도구만을 볼 수 있습니다. tools/list를 통해 사용 가능한 도구를 탐색하는 에이전트는 서버의 전체 기능 세트가 아니라, 자신의 신원(identity)을 기반으로 필터링된 목록을 받게 됩니다. 이는 매우 중요합니다. 파괴적인 도구가 존재한다는 사실을 모르는 에이전트는 실수로 해당 도구를 호출할 수 없기 때문입니다.

중앙 집중식 자격 증명 관리 (Centralized credential management). 사용자는 레지스트리에 한 번만 인증하면 됩니다. 레지스트리는 하위 자격 증명(downstream credentials) — GitHub를 위한 OAuth 토큰, Jira를 위한 API 키, 내부 API를 위한 서비스 계정(service account) 토큰 등 — 을 관리하며 이를 자동으로 갱신합니다. 오프보딩(Offboarding)은 단 한 번의 작업으로 완료됩니다. 사용자의 레지스트리 액세스 권한을 취소하면 모든 하위 시스템이 한 번에 보호됩니다.

도구 호출별 감사 추적 (Audit trail per tool invocation). 모든 도구 호출이 기록됩니다: 어떤 에이전트가, 어떤 사용자 신원으로, 어떤 도구를, 어떤 파라미터와 함께 호출했는지, 그리고 응답은 무엇이었는지, 그리고 언제 호출되었는지를 기록합니다. 보안 팀이 "지난달에 어떤 에이전트들이 운영 데이터 API에 접근했는가?"라고 물었을 때, 이틀 동안 로그를 발굴(log archaeology)하는 대신 간단한 쿼리 한 번으로 답할 수 있습니다.

가상 MCP 서버: 액세스 범위 지정의 기본 단위 (Virtual MCP Servers: the access-scoping primitive)

정말로 유용하기 때문에 반드시 이해해야 할 개념이 하나 있습니다. 바로 가상 MCP 서버(Virtual MCP Servers)입니다.

가상 MCP 서버는 하나 이상의 실제 MCP 서버로부터 도구의 일부를 노출하는, 큐레이션된 논리적 엔드포인트(logical endpoint)입니다. 에이전트에게 읽기 및 쓰기 도구가 모두 포함된 전체 Jira MCP 서버에 대한 액세스 권한을 주는 대신, 재무 워크플로우에 필요한 Jira 도구만을 노출하고 그 외의 것은 노출하지 않는 "finance-readonly"라는 이름의 가상 서버를 정의할 수 있습니다.

에이전트는 가상 서버 엔드포인트를 가리킵니다. 에이전트는 제한적이고 목적에 적합한 도구 표면(tool surface)만을 보게 됩니다. 실제 하위 서버로의 라우팅은 레지스트리/게이트웨이(registry/gateway) 계층 내부에서 발생하며, 에이전트에게는 보이지 않습니다.

이것이 바로 모든 에이전트가 각자 자체적인 액세스 필터링을 구현할 필요 없이 "과도한 권한을 가진 에이전트(over-permissioned agent)" 문제를 해결하는 패턴입니다. 정책은 에이전트 코드가 아닌 플랫폼에 존재합니다.

우리가 사용하는 것과 TrueFoundry의 역할

자격 증명 확산 (credential sprawl) 문제와 도구 호출 로그 (tool call logs)를 깔끔하게 제출할 수 없다는 컴플라이언스 감사 (compliance audit)를 겪은 후, 우리는 몇 가지 레지스트리 (registry) 옵션을 검토했고 결국 TrueFoundry의 MCP Registry 및 Gateway를 선택하게 되었습니다.

우리가 중요하게 생각했던 구체적인 요소들은 다음과 같습니다:

통합 자격 증명 관리 (Unified credential management). 개발자는 레지스트리를 위한 단일 개인 액세스 토큰 (Personal Access Token)을 받습니다. 레지스트리는 GitHub, Jira, Confluence 및 내부 API에 대한 OAuth를 처리하며, 토큰이 만료되기 전에 자동으로 갱신합니다. 오프보딩 (offboarding) 프로세스가 6단계에서 단 한 번의 작업으로 줄어들었습니다.

ID 제공자 (identity provider) 통합을 통한 RBAC. 액세스 정책 (access policies)이 기존의 Okta 설정과 연결됩니다. Okta의

• "지금 어떤 MCP 서버들이 실행 중인가요?"라는 질문에 여러 명에게 물어보지 않고는 답할 수 없습니다.
• 서버 엔드포인트(endpoint) 변경은 여러 개발자 머신의 설정을 업데이트해야 함을 의미합니다.
• 자격 증명 교체(credential rotation)는 해당 정보가 참조된 모든 곳을 찾아 업데이트하는 데 반나절을 소모하게 만듭니다.
• 개발자가 퇴사했을 때, 그들의 MCP 액세스 권한이 모든 곳에서 완전히 취소되었는지 확신할 수 없습니다.
• 컴플라이언스(compliance) 또는 보안 팀에서 어떤 에이전트가 어떤 도구를 사용했는지에 대한 로그를 요청합니다.

만약 이 중 두 가지 이상의 상황이 귀하의 상황을 설명한다면, 레지스트리(registry) 도입에 대한 논의는 이미 진작에 이루어졌어야 합니다. 분산된 포스트잇 문제(distributed sticky-note problem)는 $O( ext{developers} imes ext{servers})$로 확장되며, 비용이 빠르게 증가합니다.

현재 귀하의 MCP 서버 관리 설정은 어떤 모습인가요? 여전히 개발자별 개별 설정 파일을 사용 중인가요, 아니면 중앙 레지스트리로 이동하게 된 계기가 있었나요? 중앙 집중식 자격 증명 저장소(credential store) 없이 여러 서버에 걸쳐 자격 증명 교체(credential rotation)를 어떻게 처리하고 계신지 듣고 싶습니다. 댓글로 남겨주세요.