이미 전 세계에는 수만 개의 MCP 서버가 존재합니다. 하지만 그중 단 하나라도 실제 기업에 도입하려면, 커넥터마다, 직원마다 개별 사용자 OAuth, 동의 화면, 그리고 IT 티켓 처리가 수반되는 경향이 있습니다. 그것이 실제 걸림돌이며, 프로토콜은 결코 문제가 아니었습니다. 문제는 ID (Identity)입니다.

이 글은 Model Context Protocol (MCP)에 대한 15부작 심층 분석 중 파트 11입니다. 지금까지 다룬 모든 내용 — 서버, 클라이언트, 도구 (tools), 인증 (auth), 권한 부여 (authorization), 보안 (security), 스트리밍 (streaming), 관찰 가능성 (observability) — 은 MCP를 '작동하게' 만드는 것에 관한 것이었습니다. 이번 파트는 이를 '기업 전반에 배포(ship)'하는 것에 관한 것이며, 이는 완전히 다른 문제인 ID (identity), 프로비저닝 (provisioning), 그리고 거버넌스 (governance)에 관한 것입니다.

요약 (TL;DR)

엔터프라이즈 MCP 아키텍처

                    ID 제공자 (Identity Provider) (Entra / Okta)
                    관리자가 커넥터를 그룹에 프로비저닝함 -> 그룹
                                   |
...

1. 엔터프라이즈 관리형 권한 부여 — 한 번 프로비저닝하여 로그인 시 상속

모든 직원이 모든 커넥터에 대해 IT 티켓을 통해 개별 사용자 OAuth를 수행하는 방식은 확장성이 없습니다. 500명의 직원을 20개의 커넥터에 온보딩하는 것은 10,000개의 개별 승인과 영구적인 대기열을 의미합니다. 대신, 관리자는 ID 제공자 (IdP)에서 커넥터를 단 한 번 프로비저닝하고 이를 그룹에 할당합니다. 로그인 시 직원들은 커넥터와 그 권한 범위 (scopes)를 상속받습니다. 티켓도, 동의 화면도, 사용자별 OAuth도 필요 없습니다.

// 관리자 작업, 단 한 번: IdP에서 스코프 (scope)가 설정된 커넥터를 그룹에 부여함.
public sealed class ConnectorProvisioning(IIdentityProvider idp, IMcpCatalog catalog)
{
...

직원의 실제 의존성은 연결(connection) 자체가 아니라, 중앙에서 프로비저닝(provisioning)되고 로그인 시 상속되는 ID(identity)와 정책(policy)입니다. 기업 관리형 권한 부여(Enterprise-Managed Authorization)는 "티켓 발행 후 커넥터당 사용자별 OAuth 설정"(며칠 소요)을 "로그인하면 즉시 사용 가능"(몇 초 소요) 상태로 전환합니다. 액세스 권한을 취소하는 것은 토큰을 추적하는 것이 아니라 그룹 멤버십을 제거하는 작업이 됩니다.

2. 무분별한 사용이 아닌, 중앙 집중식 MCP 카탈로그 (Central MCP catalog)

조직 규모에서는 관리되지 않는 커넥터가 데이터로 연결되는 네트워크 경로를 가진 섀도우 IT(shadow IT)가 됩니다. 검증된(vetted) 커넥터들로 구성된 단일 조직 카탈로그를 구축해야 합니다. 에이전트는 개발자가 임의로 연결한 것이 아니라, 레지스트리(registry)로부터 권한을 부여받은 도구 세트를 가져옵니다.

// 승인된 커넥터들의 단일 조직 카탈로그. 에이전트는 그룹 멤버십에 따라 일부 하위 집합에 대한 권한을 가집니다.
public sealed class McpCatalog(ICatalogStore store) : IMcpCatalog
{
...
}

"우리 에이전트들이 어디까지 접근할 수 있는가?"라는 질문은 모든 팀을 일일이 조사하는 것이 아니라, 레지스트리에 대한 쿼리(query)가 됩니다.

3. 제3자 서버 검증 및 핀 고정 (Vet and pin third-party servers)

공개된 MCP 서버는 신뢰할 수 없는 데이터를 반환하는 신뢰할 수 없는 코드이며, 이제는 에이전트 루프(agent loop) 내부에 존재합니다. 서버는 **보안 검토(security review)**와 체크섬 핀(checksum pin)(파트 8에서 다룬 rug-pull 방지책)을 거친 후, 위험도에 따라 계층화되어 카탈로그에 등록됩니다.

// 제3자 서버는 검토 및 핀 고정된 체크섬을 거친 후에만 허용됩니다.
public async Task<AdmissionResult> AdmitAsync(ExternalServer server, CancellationToken ct)
{
...
}

도구 정의(tool definition)가 변경되면, 모든 에이전트에 조용히 영향을 미치는 대신 해당 커넥터를 다시 검토 대상으로 불러옵니다. 파트 8에서 다룬 에이전트별 rug-pull 방지책이 조직 차원의 승인 프로세스로 확장됩니다.

4. IdP를 통한 정책 프로비저닝 (Provision the policy through the IdP)

파트 7에서는 에이전트별 ID 및 정책을 구축했습니다. 파트 11에서는 이를 조직 규모로 프로비저닝(provisioning)합니다. 사용자의 IdP **그룹(group)**은 에이전트가 상속받는 스코프(scopes)에 매핑됩니다.

IdP 그룹             ->  상속된 커넥터 스코프 (inherited connector scopes)
---------               --------------------------
"Analysts"          ->  { campaigns:read, events:read }
...

누군가를 새로운 팀으로 이동시키면, 해당 사용자의 에이전트 권한도 함께 따라갑니다. 티켓 발행도, 배포(deploy)도 필요 없습니다. 단 한 번의 수정으로 조직 전체에 적용되며, 감사(audit, 파트 10 참조)가 가능하고, 몇 초 만에 되돌릴 수 있습니다.

5. 플랫폼 차원에서 비용, 데이터 및 감사를 관리하십시오

기업은 관리할 수 없는 에이전트를 출시하지 않습니다. 거버넌스(Governance)는 **플랫폼 기능 (platform capability)**입니다. 팀별 토큰 예산, 커넥터(connector)별 데이터 유출 방지(DLP) 및 데이터 거주성(data-residency) 규칙, 그리고 조직 전체에 걸친 단일 감사가 이에 해당합니다.

// 거버넌스는 플랫폼 기능이지, 팀별로 사후에 고려할 사항이 아닙니다.
gateway.SetTeamBudget(team, monthlyTokens);          // 비용 거버넌스 (cost governance)
gateway.RequireRegion(connector, allowedRegions);    // 데이터 거주성 (data residency)
...

팀별 예산은 통제 불능의 지출을 막고, 거주성 규칙은 규제 대상 데이터를 해당 지역 내에 유지하며, DLP는 민감한 데이터의 유출을 방지하고, 조직 전체의 감사는 "누가 무엇을 했는지"에 대한 답을 제공합니다. 거버넌스는 유망한 파일럿 프로젝트를 전사적 도입으로 전환하는 핵심 요소이며, 거버넌스의 부재는 수많은 파일럿 프로젝트가 상용화 단계로 넘어가지 못하는 이유입니다.

6. 빅뱅 방식이 아닌 리스크 계층별로 배포하십시오

"모든 곳에 MCP를 활성화하라"는 방식은 모든 빅뱅(big-bang) 방식이 그렇듯 실패합니다. 첫 번째 사고가 발생하는 순간 프로그램 전체가 중단되기 때문입니다. 대신, 플랫폼 팀이 공유 게이트웨이(gateway)와 카탈로그(catalog)를 소유하고, 커넥터는 **리스크 계층 (risk tier)**에 따라 배포됩니다.

계층 1 (읽기 전용, 저위험)   -> 분석, 문서, 검색       -> 광범위한 셀프 서비스
계층 2 (쓰기, 되돌리기 가능) -> 보고서 생성, 티켓 업데이트 -> 범위 제한 그룹 + 감사
계층 3 (파괴적/규제 대상)   -> 관리, 재무, 개인정보(PII) -> 단계별 인증 + 검토 + 제한된 그룹
...

거버넌스가 우선이고, 범위 확장은 그다음입니다. 저위험 읽기 전용 권한은 가치를 빠르게 증명할 수 있도록 광범위하게 배포합니다. 쓰기 및 파괴적 권한은 범위 제한 그룹, 단계별 인증(step-up), 그리고 검토를 통해 통제된 상태를 유지합니다.

수치 요약

지속 가능한 모델

커넥터 (Connectors)가 쉬운 80%라면, ID (Identity), 정책 (Policy), 그리고 거버넌스 (Governance)는 에이전트가 기업 내부에서 실제로 배포될 수 있을지를 결정하는 나머지 20%입니다. IdP (Identity Provider)를 통해 ID와 정책을 한 번만 프로비저닝 (Provision)하고, 직원들이 로그인할 때 이를 상속받도록 하세요. 모든 커넥터를 하나의 관리되는 게이트웨이 (Gateway)와 검증된 카탈로그 (Catalog) 뒤에 배치하십시오. 비용, 데이터, 그리고 감사 (Audit)를 플랫폼 기능으로서 관리하십시오. 그렇게 하면 모두가 집착하는 부분인 프로토콜 (Protocol)은 정말로 쉬운 부분이 됩니다.

MCP를 기업 전반에 배포할 수 있게 만드는 세 가지 습관:

1. IdP를 통해 ID와 정책을 중앙에서 프로비저닝하십시오. 사용자별, 커넥터별이 아니라 로그인 시 한 번에 상속되도록 해야 합니다.
2. 에이전트와 서버 사이에 검증된 카탈로그와 관리되는 게이트웨이를 배치하십시오. 임시적인 (Ad-hoc) 연결이나 검토되지 않은 서버는 허용하지 마십시오.
3. 플랫폼 팀과 함께 리스크 계층 (Risk tier)별로 배포하십시오. 광범위한 읽기 전용 (Read-only), 제한된 파괴적 작업 (Destructive), 가드레일 (Guardrails) 내에서의 셀프 서비스 (Self-service) 순으로 진행하십시오.

원문은 prepstack.co.in에 게시되었습니다. 파트 12에서는 다시 코드로 돌아가 C#과 .NET 9를 사용하여 MCP 서버를 구축하는 방법을 다룹니다.