Linux Foundation 거버넌스로 읽는 엔터프라이즈 MCP 아키텍처
MCP의 Linux Foundation 거버넌스 전환과 엔터프라이즈 보안, 서버 생태계 관리, A2A 협업 아키텍처를 분석한다.
2026-08-14 · 최초 발행 2026-05-24
MCP를 연결 규격으로만 보면 운영 단계에서 필요한 통제 지점을 놓치기 쉽다. 공개 서버가 10,000개를 넘어섰고 엔터프라이즈 AI 에이전트의 78%가 MCP를 채택한 상황에서는 어떤 서버를 신뢰할지, 누가 어떤 도구를 호출할지, 실행 기록을 어떻게 남길지가 프로토콜 자체만큼 중요해진다.
단일 벤더의 프로토콜에서 산업 표준으로
Anthropic이 2024년 11월 발표한 Model Context Protocol은 출시 18개월 만에 공개 서버 10,000개와 월 9,700만 다운로드를 기록했다. AI 도구를 연결하기 위한 프로토콜로 출발했지만, 이 성장 속도는 MCP가 에이전틱 AI 인프라의 사실상 표준으로 자리 잡았음을 보여준다.
2026년 초 Anthropic은 MCP 스펙을 Linux Foundation에 기증하고 Agentic AI Foundation(AAF)을 설립했다. 이는 단일 벤더가 주도하던 실험적 프로토콜을 중립적인 산업 표준으로 옮기는 결정이자, AI 인프라 표준화를 둘러싼 생태계 경쟁에서 주도권을 확보하려는 전략적 포석이다.
거버넌스 체계도 달라졌다. Technical Steering Committee(TSC)가 구성되면서 특정 벤더에 대한 종속성을 줄였고, RFC 프로세스와 공식 버전 관리 체계가 도입됐다. OpenAI, Google, Microsoft는 AAF 프리미엄 멤버로 합류했으며, 기여 정책은 Apache 2.0 라이선스를 기반으로 명문화됐다.
초기에 OpenAI와 Google은 자체 Function Calling 메커니즘을 MCP의 대안으로 내세웠다. 그러나 엔터프라이즈 시장의 MCP 수요가 커지면서 전략을 바꿨다. 2026년 H1 기준 OpenAI는 GPT-5 API에서 MCP 클라이언트 모드를 공식 지원하고, Google은 Gemini 에이전트 플랫폼에 MCP 서버 호환 레이어를 제공한다.
A2A와 Stateless 서버가 바꾸는 연결 구조
AAF의 2026년 하반기 로드맵은 A2A(Agent-to-Agent) 통합, Stateless 서버 아키텍처, Server Cards에 초점을 둔다.
A2A 핸드셰이크 스펙이 추가되면 MCP 서버의 역할은 도구 노출에 머물지 않는다. 에이전트가 다른 에이전트와 직접 협업할 수 있는 연결 계층으로 범위가 넓어진다.
Stateless 모드는 세션 상태를 유지하는 기존 MCP 서버의 상태를 외부화한다. 수평 확장과 멀티 클라우드 배포를 고려한 변화다.
Server Cards는 npm의 package.json과 비슷한 표준 메타데이터 포맷이다. MCP 서버가 제공하는 기능과 보안 정책, 의존성, 신뢰도 지표를 선언하며, 서버 자동 발견과 거버넌스 자동화의 기반으로 쓰인다.
게이트웨이에서 신원과 정책을 함께 검증한다
엔터프라이즈 환경에서는 API 키 관리만으로 MCP를 통제하기 어렵다. MCP 게이트웨이의 인증·인가 계층을 기존 IAM 체계와 연결하고, 모든 요청을 정책 평가 대상으로 다뤄야 한다. 엔터프라이즈 AI 에이전트의 78%가 MCP를 채택한 이면에는 보안 사고 리스크도 78% 이상으로 증가했다는 현실이 있다.
제로트러스트 원칙을 적용한 게이트웨이는 요청을 사전에 신뢰하지 않는다. 에이전트 신원과 도구 권한뿐 아니라 호출 시점의 IP, 시간대, 이상 행동 패턴까지 함께 평가한다.
권한은 업무 수행에 필요한 범위로 제한한다. OIDC 스코프와 MCP 도구 ID를 1:1로 매핑하면 에이전트별 도구 접근을 세분화할 수 있다. 정책 평가는 Open Policy Agent(OPA)나 Cedar 정책 언어로 런타임에 수행하며, 변경된 정책은 에이전트를 다시 배포하지 않아도 반영된다.
공개 서버를 내부 통제 범위로 들이는 방법
공개 MCP 서버가 10,000개에 이르면 검증되지 않은 서버가 함께 유통될 가능성도 상당하다. 엔터프라이즈에서는 외부 서버를 곧바로 연결하기보다 Private Server Registry를 두고 승인과 검증 과정을 통과시켜야 한다.
내부 레지스트리에는 사전 승인된 MCP 서버만 등록한다. Server Cards에 선언된 기능과 실제 동작이 일치하는지는 자동화된 테스트로 검사한다. MCP 서버 패키지에는 SBOM(Software Bill of Materials)을 요구해 의존성 취약점을 스캔하고, 배포 바이너리의 무결성은 Sigstore/cosign을 이용한 코드 서명 검증으로 확인한다.
이 구조에서 Server Cards는 단순한 소개 문서가 아니다. 등록 심사와 배포 승인, 런타임 정책을 연결하는 관리 데이터가 된다.
호출 기록과 비용 통제를 같은 계층에 둔다
금융, 의료, 공공처럼 규제 준수가 필요한 환경에서는 모든 MCP 도구 호출을 추적할 수 있어야 한다. 감사 로그는 호출 주체와 사용 도구뿐 아니라 입력의 해시, 출력 데이터의 민감도, 적용된 정책까지 남겨야 한다.
| 필드 | 설명 | 규정 연관 |
|---|---|---|
agent_id |
호출 에이전트의 식별자 | SOC2, ISO27001 |
tool_id |
호출된 MCP 도구 ID | GDPR Art.30 |
input_hash |
입력 파라미터의 SHA-256 해시 | 데이터 최소화 원칙 |
output_classification |
응답 데이터의 민감도 분류 | DLP 정책 |
latency_ms |
실행 시간 | SLA 모니터링 |
policy_decision |
적용된 OPA 정책 ID | 감사 추적 |
레이트 리미팅도 단일 RPS 제한으로 끝나지 않는다. 에이전트별, 도구별, 컨텍스트별로 제한을 나누고, 데이터베이스 대량 조회나 결제 API처럼 비용이 큰 외부 API를 호출하는 도구에는 별도의 엄격한 정책을 적용해야 한다.
서버 카탈로그가 자동 발견의 기준점이 된다
공개 서버 10,000개와 기업 내부의 수천 개 서버를 관리하려면 패키지 레지스트리와 API 게이트웨이의 역할을 결합한 아키텍처가 필요하다. MCP 서버 카탈로그는 npm registry나 Helm chart repository와 비슷한 역할을 맡는다.
AAF의 Server Cards 스펙을 기준으로 제공 기능, 보안 정책, 신뢰도 지표, 호환 버전, 의존성을 표준화하면 에이전트가 런타임에 필요한 도구를 찾을 수 있다.
자동 발견은 DNS-SD(Service Discovery)와 유사하게 작동한다. 에이전트가 필요한 기능을 의미론적으로 검색하면 카탈로그가 조건에 맞는 서버를 추천한다.
호환성과 신뢰도를 운영 데이터로 관리한다
MCP 프로토콜 버전과 개별 서버 구현 버전이 섞이면 호환성 관리가 주요 운영 과제가 된다. MCP 서버는 Semantic Versioning을 따르고, 마이너 버전에서는 하위 호환성을 보장하며 메이저 버전에는 마이그레이션 가이드를 함께 제공한다.
구버전 MCP 클라이언트가 신버전 서버를 사용할 때는 게이트웨이의 호환성 어댑터가 요청과 응답을 변환한다. 이 호환 레이어는 클라이언트와 서버의 업그레이드 시점을 분리할 수 있게 한다.
서버 신뢰도는 여러 지표를 가중 합산해 산출한다.
- 다운로드와 사용량으로 확인한 실제 채택 규모: 가중치 25%
- CVE 발생 빈도와 패치 속도를 포함한 보안 감사 이력: 가중치 30%
- 공급망 무결성을 보여주는 코드 서명 여부: 가중치 20%
- GitHub 스타와 이슈 해결율을 포함한 커뮤니티 평가: 가중치 15%
- Agentic AI Foundation의 공식 검증 여부: 가중치 10%
도구 호출을 넘어 에이전트 협업으로
A2A가 MCP에 통합되면 단일 에이전트가 도구를 사용하는 구조에서 에이전트들이 역할을 나눠 협업하는 구조로 확장된다.
오케스트레이터-서브에이전트 패턴에서는 상위 에이전트가 전문화된 서브에이전트를 MCP 도구처럼 호출한다. 각 서브에이전트는 자신의 업무에 맞는 독립적인 MCP 서버 집합을 사용한다.
피어투피어 구조에서는 두 에이전트가 MCP 서버를 매개로 컨텍스트를 공유하며 공동 작업을 수행한다. 이때 공유 컨텍스트의 접근 제어와 데이터 격리가 핵심 보안 과제가 된다.
이벤트 기반 연쇄 구조도 가능하다. MCP 서버가 이벤트를 발행하면 이를 구독한 에이전트들이 자동으로 반응하며, 복잡한 비즈니스 워크플로우를 이어서 처리한다.
MCP가 산업 표준화의 궤도에 들어선 뒤에는 연결 가능한 서버의 수보다 통제 가능한 서버의 범위가 더 중요해진다. 엔터프라이즈 78% 채택은 활용 기회와 함께 보안 거버넌스와 생태계 관리 책임도 키운다. 제로트러스트 접근 제어, Server Cards 기반 신뢰도 평가, A2A 협업 구조를 하나의 운영 체계로 묶어야 MCP 생태계를 지속해서 활용할 수 있다.