MCP 거버넌스(MCP governance)는 AI 에이전트가 어떤 Model Context Protocol (MCP) 서버에 접속할 수 있는지, 해당 서버들이 에이전트를 대신하여 무엇을 할 수 있는지, 그리고 그 과정에서 무엇이 기록되는지를 결정하는 통제 체계입니다. 이는 프로토콜 그 자체는 아닙니다. MCP는 에이전트와 도구 서버(tool server)가 서로 어떻게 통신하는지를 정의합니다. 거버넌스는 그러한 대화가 실제로 일어나야 하는지, 그리고 어떤 조건 하에서 이루어져야 하는지를 결정하는 계층입니다.

이러한 구분은 특정한 이유로 인해 시급한 과제가 되었습니다. MCP가 막 단일 벤더(single-vendor) 단계를 벗어나 인프라 단계로 진입했으며, 거버넌스의 대상이 되는 생태계가 대부분의 조직이 무엇이 무엇에 연결되어 있는지 추적할 수 있는 능력보다 더 빠르게 성장했기 때문입니다.

MCP 거버넌스가 해결하는 문제

MCP 서버는 AI 에이전트의 범위를 캘린더, 데이터베이스, 티켓팅 시스템, 소스 제어(source control), 그리고 내부 API로 확장합니다. 이러한 서버 하나하나가 에이전트가 데이터를 읽거나 작업을 수행할 수 있는 새로운 지점이 되며, 현재 대부분의 조직은 누군가가 목록을 작성한 것보다 더 많은 서버를 보유하고 있습니다. 개발자는 시간을 아끼기 위해 자신의 코딩 어시스턴트에 개인용 MCP 서버를 추가합니다. 팀은 워크플로우를 위해 내부 MCP 서버를 구축하고 이를 문서화하는 것을 잊어버립니다. 에이전트가 도구 설명(tool descriptions)이 하룻밤 사이에 변경될 수 있는 제3자 MCP 서버를 가리키게 되면, 에이전트가 허용되었다고 믿는 작업 내용이 조용히 변경될 수 있는데, 이는 'MCP 러그 풀(MCP rug pull)'이라고 알려진 실패 모드입니다.

이 중 어느 것도 가설이 아닙니다. 이는 10년 동안 보안 팀의 골칫거리였던 섀도우 IT(shadow IT)와 동일한 패턴이지만, 이제는 '섀도우 MCP(shadow MCP)'가 되었으며, 승인되지 않은 도구를 사용하는 주체는 행동하기 전에 허락을 구하지 않는 자율 에이전트(autonomous agents)라는 점이 다릅니다. 거버넌스가 없다면 조직은 일반적으로 세 가지 기본 질문에 답할 수 없습니다: 회사 전체에 어떤 MCP 서버가 존재하는가, 어떤 에이전트가 어떤 서버에 연결되어 있는가, 그리고 그 연결이 실제로 무엇을 하는 데 사용되고 있는가. MCP 거버넌스는 이 세 가지 질문에 모두 답하기 위해 구축된 계층입니다.

비유: 네트워크에 대한 ID 및 액세스 관리(IAM)와 MCP에 대한 거버넌스의 관계

가장 명확한 비교 대상은 기업의 ID 및 액세스 관리 (Identity and Access Management, IAM)입니다. 기업 네트워크는 연결되는 모든 장치를 신뢰함으로써 작동하지 않습니다. 네트워크는 누가 연결되는지 인증(Authenticate)하고, 역할(Role)에 따라 무엇을 만질 수 있는지 권한을 부여(Authorize)하며, 나중에 검토할 수 있도록 수행한 작업을 기록(Log)합니다. MCP 거버넌스는 이 세 가지 구성 요소 모델을 에이전트와 도구(Tool) 간의 연결에 구체적으로 적용합니다. 즉, 어떤 에이전트나 사용자가 호출을 수행하는지 인증하고, 해당 ID가 접근할 수 있는 도구와 데이터에 대해 권한을 부여하며, 감사를 위해 모든 호출을 기록하는 것입니다.

이 비유가 "MCP 거버넌스는 단순한 관찰 가능성 (Observability)이다"라는 설명보다 더 적절한 이유는, IAM이 선택 사항이거나 사후 조치가 아니기 때문입니다. 액세스 제어(Access Control)가 없는 네트워크는 보안이 약한 네트워크가 아니라, 사실상 전혀 제어되지 않는 네트워크입니다. MCP도 마찬가지입니다. 중재 정책(Intermediating policy) 없이 MCP 서버에 직접 연결된 에이전트 군단은, 보안 공백이 있는 거버넌스 체계가 갖춰진 군단이 아니라, 그저 대부분의 경우에 작동할 뿐인 거버넌스가 없는(Ungoverned) 군단입니다.

이것이 AI 에이전트에 구체적으로 적용되는 방식

에이전트는 전통적인 IAM이 처리하도록 설계되지 않았던 두 가지 문제를 야기합니다. 첫째, 에이전트가 사용할 수 있는 도구 세트가 인간의 승인 없이 변경될 수 있습니다. 예를 들어, 서버 측에서 도구 설명(Tool description)이 수정되면 에이전트는 다음 호출 시 새로운 기능을 바로 습득하게 됩니다. 둘째, 무엇이 무엇에 연결되어 있는지에 대한 공유된 카탈로그(Shared catalog)가 없기 때문에, 동일한 회사 내에 있더라도 한 에이전트의 MCP 연결 상태가 다른 에이전트를 관리하는 팀에게는 보이지 않는 경우가 빈번합니다.

에이전트를 위해 MCP를 거버넌스한다는 것은 구체적으로 다음 사항들을 다루는 것을 의미합니다:

1. 서버 카탈로그 및 디스커버리 (Server catalog and discovery) — 승인 여부와 관계없이 사용 중인 모든 MCP 서버의 실시간 인벤토리를 관리하여, "섀도우 MCP (shadow MCP)" 서버가 사고 발생 후 발견되는 대신 사전에 찾아낼 수 있도록 합니다.
2. ID 기반 액세스 제어 (Identity-based access control) — 모든 도구 호출 (tool call)을 특정 에이전트, 사용자 및 세션으로 추적할 수 있게 하며, 추적을 불가능하게 만드는 공유 자격 증명 (shared credential)을 사용하지 않습니다.
3. 도구 핑거프린팅 및 드리프트 탐지 (Tool fingerprinting and drift detection) — 각 도구가 수행해야 하는 작업에 대한 기록된 기준선 (baseline)을 설정하여, 도구의 설명이나 동작이 조용히 변경될 경우 기본적으로 신뢰하는 대신 경고를 보냅니다.
4. 도구 경계에서의 프롬프트 인젝션 스캐닝 (Prompt injection scanning at the tool boundary) — 주입된 지침이 사용자의 프롬프트뿐만 아니라 도구의 출력값을 통해서도 전달될 수 있으므로, 도구의 설명과 결과물 자체를 검사합니다.
5. 파괴적 작업에 대한 휴먼 인 더 루프 (Human-in-the-loop holds for destructive actions) — 모든 호출을 무인 상태로 실행하게 두는 대신, 쓰기, 삭제 또는 전송을 수행하는 도구 호출에 대해 승인 단계를 거치도록 합니다.
6. 내구성이 있는 감사 로깅 (Durable audit logging) — 허용되었거나 거부된 모든 호출에 대한 기록을 남기며, 이는 에이전트 자체의 메모리보다 오래 유지되어 컴플라이언스 검토 (compliance review)에 활용될 수 있어야 합니다.
7. 표준 준수 인증 (Standards-compliant authentication) — 원격 MCP 서버를 서버마다 별도의 임시방편 (bespoke workaround)이 아닌, 사양 (specification)에서 실제로 요구하는 방식대로 인증합니다.

마지막 지점에 대해서는 현재 MCP 사양(2025-11-25) 기준으로 구체적이고 확정적인 답변이 존재합니다. 기술적으로 프로토콜 수준에서 인가 (authorization) 자체는 선택 사항이지만, 일단 HTTP 기반 서버가 이를 지원하기 시작하면 사양의 요구 사항은 더 이상 선택 사항이 아닙니다. 인가 서버 (authorization servers)는 OAuth 2.1을 구현해야 하며, MCP 클라이언트 (clients)는 S256 챌린지 방식을 사용하는 PKCE를 구현해야 합니다. 모든 인가 서버 엔드포인트 (endpoints)는 HTTPS를 통해 실행되어야 하며, 서버는 발견 (discovery)을 위해 OAuth 2.0 Protected Resource Metadata (RFC 9728)를 구현하는 동시에 RFC 8707에 따라 토큰 대상 (token audience)을 검증해야 합니다. 동적 클라이언트 등록 (Dynamic client registration, RFC 7591)은 여전히 존재하지만 하위 호환성을 위한 폴백 (fallback)으로 격하되었습니다. 사전 관계가 없는 클라이언트와 서버를 위한 사양의 권장 경로는 이제 OAuth Client ID Metadata Documents입니다. 실제로 민감한 도구(tools)나 데이터를 처리하는 모든 원격 서버에 있어 "선택 사항"이라는 말은 이론적인 것에 불과합니다. 순수하게 로컬이며 단일 사용자용이 아닌 모든 것에 대해, 이것이 현재 프로토콜 수준에서 "거버넌스 (governed)"가 의미하는 바입니다.

Linux Foundation으로의 전환, 그리고 이것이 거버넌스에 중요한 이유

2025년 12월, Anthropic은 Block의 goose 및 OpenAI의 AGENTS.md를 창립 기여물로 하여, Model Context Protocol을 Linux Foundation 산하에 새로 설립된 Agentic AI Foundation (AAIF)에 기부했습니다. 이제 이 프로토콜의 법적 본거지는 "Model Context Protocol, a Series of LF Projects, LLC"이며, 기여물은 Apache 2.0 라이선스 하에 관리되고 전략적 방향은 AAIF 이사회 (governing board)에 의해 설정됩니다.

두 가지는 변했고, 한 가지는 변하지 않았습니다. 변한 점은 다음과 같습니다: MCP는 더 이상 단일 벤더의 로드맵(roadmap)에 의해 관리되지 않습니다. 이는 일부 엔터프라이즈 아키텍트(enterprise architects)들이 MCP를 표준으로 채택하는 데 신중하게 만들었던 '단일 벤더 리스크(single-vendor risk)'를 제거합니다. 이는 Kubernetes와 PyTorch가 광범위한 기업 도입 이전에 거쳤던 것과 동일한 경로입니다. 또한 변한 점은 프로토콜 자체의 내부 거버넌스(governance)가 문서화된 구조를 갖추게 되었다는 것입니다. 즉, Maintainers, Core Maintainers, 그리고 Lead Maintainers가 함께 MCP Steering Group을 구성하며, 모든 결정과 논의는 투명하게 이루어집니다. 변하지 않은 것은 일상적인 의사결정 모델 그 자체입니다. 재단(foundation)으로의 이동은 누가 책임을 지는지(accountable)를 공식화한 것이지, 통제권을 새로운 단일 당사자에게 넘긴 것이 아닙니다.

MCP 거버넌스 툴링(tooling)이나 정책을 구축하려는 모든 이들에게 이 점은 매우 중요합니다. 이는 명세(specification) 자체가 이제 더 예측 가능한 릴리스(release) 및 관리(stewardship) 주기(cadence)를 갖게 되었음을 의미하기 때문입니다. 발표된 2026년 로드맵은 전송 진화(transport evolution), 에이전트 통신 라이프사이클(agent communication lifecycles), 거버넌스 성숙(governance maturation), 그리고 엔터프라이즈 준비성(enterprise readiness)을 4대 우선순위 영역으로 명시하고 있으며, 이는 고정된 날짜가 아닌 워킹 그룹(working group) 단위로 구성됩니다. 프로젝트로서의 MCP 조직 거버넌스(organizational governance)와 사용자의 자체 환경 내에서 배포된 프로토콜로서의 MCP 기술 거버넌스(technical governance)는 서로 다른 것이지만, 전자가 이제 후자가 구축할 수 있는 더 안정적인 토대를 제공합니다.

Waxell이 이를 처리하는 방식

Waxell의 MCP Gateway는 바로 위에서 설명한 변화를 중심으로 구축되었습니다. 즉, 에이전트나 어시스턴트가 수행하는 모든 MCP 도구 호출(tool call) 앞에 관리되는 단일 접점(governed surface)을 두는 방식이며, 각 에이전트가 업스트림 서버(upstream servers)에 직접 연결하는 방식이 아닙니다. 테넌트(tenant)당 하나의 URL을 사용함으로써, 조직이 서버별로 일일이 추적해야 했던 모든 업스트림 MCP 설정을 대체합니다.

도구 핑거프린팅 (Tool fingerprinting)은 검토 대기 (Pending review), 드리프트 감지 (Drift detected), 신뢰함 (Trusted), 차단됨 (Blocked), 제거됨 (Removed)의 5가지 신뢰 상태에 걸쳐 실행됩니다. 따라서 처음 승인된 이후 변경된 도구 설명은 암묵적으로 신뢰되는 대신 드리프트 (drift)로 플래그가 지정되며, 이는 위에서 설명한 러그풀 (rug-pull) 문제에 대한 직접적인 해답이 됩니다. 프롬프트 인젝션 스캐너 (Prompt injection scanner)는 에이전트가 도구를 호출하기 전, 핑거프린팅 시점에 도구 설명을 대상으로 실행되며, 휴먼 인 더 루프 (human-in-the-loop) 승인 절차를 통해 파괴적인 작업(쓰기, 삭제, 외부 전송)이 무인으로 실행되지 않고 사람의 확인을 위해 대기 상태로 유지됩니다.

ID 식별 (Identity resolution)은 세 가지 인증 모드인 대행 OAuth (on-behalf-of OAuth), 공유 서비스 계정 (shared service account), 사용자 토큰 지참 (bring-your-own-token)을 지원하며, 오프보딩 (offboarding)은 모든 업스트림 OAuth 권한을 한 번에 취소하는 단일 트랜잭션으로 처리됩니다. 정책 변경은 30초 이내에 전파되며, 감사 로그 (audit log)는 내구성이 있고 CSV로 내보낼 수 있으며 페이로드 (payload)를 저장하지 않습니다. 이는 대부분의 팀이 컴플라이언스 (compliance) 검토를 위해 실제로 필요로 하는 보관 기간을 훨씬 넘어서까지 유지되도록 설계된 기록입니다. 이 모든 기능은 160개 이상의 업스트림 커넥터 (upstream connectors) 뒤에 위치하므로, 게이트웨이 (gateway)는 재구축이 아닌 실용적인 드롭인 (drop-in) 방식으로 도입될 수 있습니다.

Waxell Observe는 코드 측면에서 게이트웨이를 보완합니다. 단 두 줄의 계측 (instrumentation) 코드로 200개 이상의 프레임워크 (frameworks), LLM, 벡터 데이터베이스 (vector databases)를 자동으로 커버하며, OWASP LLM Top 10, NIST AI RMF, ISO 42001, EU AI Act, GDPR/HIPAA를 포함하여 프레임워크에 매핑된 50개 이상의 정책 카테고리에 대해 강제 적용을 수행합니다. 따라서 에이전트의 노출이 MCP 도구 호출을 통해 발생하든 직접적인 모델 호출을 통해 발생하든 거버넌스 (governance)가 적용됩니다.

FAQ

MCP 거버넌스는 MCP 게이트웨이와 동일한가요?

정확히는 아닙니다. 게이트웨이는 MCP 거버넌스를 구현하기 위한 하나의 일반적인 아키텍처 패턴입니다. 즉, 모든 도구 호출이 통과하며 정책이 강제되는 단일 지점입니다. 거버넌스는 더 넓은 목표(제어, 가시성, 감사)이며, 게이트웨이는 이를 달성하는 가장 효과적인 방법 중 하나입니다. 왜냐하면 모든 개별 에이전트가 스스로를 감시하도록 맡기는 대신, 트래픽 경로 자체에 강제 적용 기능을 배치하기 때문입니다.

Linux Foundation가 제가 구축하거나 사용할 수 있는 MCP 서버를 통제하게 되나요?

아니요. Linux Foundation와 AAIF는 사양 (Specification) 및 오픈 소스 프로젝트를 관리합니다. 즉, 표준이 어떻게 진화하는지, 누가 커밋 권한 (Commit access)을 갖는지, 분쟁이 어떻게 해결되는지 등을 관리합니다. 개별 기업이 어떤 MCP 서버를 구축하고, 연결하며, 내부적으로 관리하는지에 대해서는 관여하지 않습니다. 그 부분은 전적으로 각 조직의 결정에 달려 있습니다.

내부용 단일 사용자 MCP 서버에도 OAuth 2.1이 필요한가요?

사양 자체에서는 권한 부여 (Authorization)를 선택 사항으로 취급하며, 로컬 STDIO 전송 방식을 사용하는 서버는 이 흐름을 구현하는 대신 환경 변수에서 자격 증명 (Credentials)을 가져오도록 명시적으로 안내됩니다. OAuth 2.1-plus-PKCE 요구 사항은 HTTP 기반 서버가 권한 부여를 지원하기로 결정하는 순간, 즉 사실상 한 명 이상의 사용자가 있는 모든 원격 서버에서 적용됩니다. 순수 로컬 단일 사용자 서버는 현재 더 많은 재량권을 가지고 있지만, "현재의 내부용"이 액세스 제어 (Access controls)가 재검토되는 속도보다 더 빠르게 "내일의 더 많은 사람에게 노출되는 것"으로 변하는 경우가 많습니다. 따라서 그 경우에도 표준화된 인증 (Auth)을 기본값으로 취급하는 것이 더 안전한 선택입니다.

MCP 연결을 관리하지 않을 때 발생하는 실제 위험은 무엇인가요?

가장 자주 언급되는 패턴은 MCP 러그 풀 (Rug pull)입니다. 에이전트가 이미 도구에 대한 액세스 권한을 부여받은 후, 해당 도구의 설명이나 동작이 변경되는 경우입니다. 이때 변화를 감지할 메커니즘이 없는 에이전트는 더 이상 승인된 대로 동작하지 않는 도구를 계속 신뢰하게 됩니다. 두 번째로 흔한 패턴은 단순한 확산 (Sprawl)입니다. 어떤 MCP 서버가 어떤 에이전트에 연결되어 있는지에 대한 최신 목록을 아무도 생성할 수 없게 되며, 이는 사고 대응 (Incident response)과 감사 (Audit)를 사실상 불가능하게 만듭니다.

이것이 단순히 승인 전에 MCP 서버 코드를 검토하는 것과 어떻게 다른가요?

코드 리뷰 (Code review)는 승인 시점에 서버가 수행하는 작업을 포착합니다. 하지만 승인 후 서버의 설명이나 동작이 변경되었을 때 서버가 수행하는 작업이나, 애초에 아무도 연결된 사실을 몰랐던 서버를 포착하지는 못합니다. 거버넌스 (Governance)는 일회성 관문이 아니라, 지속적이고 런타임 (Runtime)에서 강제되어야 합니다.

MCP 거버넌스 (Governance)가 에이전트 (Agent) 개발 속도를 늦출까요?

수동 승인 대기열 (Manual approval queue)이 아닌 인프라 (Infrastructure)로서 구현된다면 그렇지 않습니다. 게이트웨이 기반 (Gateway-based) 접근 방식은 개발자가 승인된 서버 (Sanctioned servers)에 즉시 연결할 수 있게 하는 동시에, 새로운 서버나 파괴적인 동작 (Destructive actions)과 같은 비정상적이거나 고위험인 호출 (High-risk calls)에 대해서만 검토를 위해 일시 중단되도록 합니다. 목표는 안전한 경로가 곧 빠른 경로가 되도록 만드는 것입니다.

출처 및 검증 노트