엔터프라이즈 MCP 아키텍처와 중립 거버넌스

2024년 11월 Anthropic이 공개한 Model Context Protocol(MCP)은 누적 다운로드 9,700만 건을 넘어섰다. 엔터프라이즈 AI 에이전트의 78%가 MCP를 채택한 것으로 집계됐고, 공개된 MCP 서버도 9,400개 이상이다. 도구를 연결하는 규약에서 출발했지만, 이 정도 규모에서는 인증과 감사, 트래픽 제어, 장애 격리를 포함한 운영 아키텍처가 프로토콜 자체만큼 중요해진다.

거버넌스가 Linux Foundation 산하 Agentic AI Foundation으로 이전한 것도 같은 맥락이다. MCP는 Anthropic 단독 관리 체계에서 벗어나 중립적인 오픈 표준으로 전환됐고, 엔터프라이즈 도입의 쟁점은 연결 가능성에서 보안과 지속 가능한 운영으로 이동했다.

MCP 서버가 노출하는 것과 통제해야 하는 것

MCP 서버가 클라이언트에 제공하는 기본 요소는 도구(Tool), 리소스(Resource), 프롬프트(Prompt)다. 도구는 실행할 기능을, 리소스는 접근할 데이터를, 프롬프트는 재사용할 작업 템플릿을 나타낸다. 기업 환경에서는 이 인터페이스 바깥에 인증·인가·감사·레이트 리미팅을 담당하는 통제 계층이 필요하다.

도구는 JSON Schema 기반 명세로 등록된다. 이름과 설명, 입력 스키마, 출력 형식을 클라이언트에 알리면 클라이언트는 그 정보를 이용해 LLM의 도구 호출을 구성한다. 서버 기동부터 실제 실행까지의 흐름은 다음과 같다.

⤢✕

스키마를 변경할 때는 기존 클라이언트와의 호환성을 깨뜨리지 않도록 도구 버전 필드와 하위 호환성 정책을 명시해야 한다. 리소스는 mcp://server-name/resource-type/identifier 형식의 URI로 주소화해 클라이언트가 필요한 데이터에 선언적으로 접근하도록 구성한다.

반복해서 사용하는 작업 패턴은 서버가 프롬프트 템플릿으로 제공할 수 있다. 도구와 리소스마다 필요한 권한 범위(Scope)도 함께 선언하면 클라이언트가 최소 권한 원칙에 맞춰 접근 요청을 만들 수 있다.

기업 인증과 감사 기록을 서버 경계에 묶는다

엔터프라이즈 MCP 서버는 기업 ID 제공자(IdP)와 SSO로 연결되고, 모든 도구 호출을 추적할 수 있어야 한다. MCP 클라이언트가 OIDC ID 토큰을 HTTP Authorization 헤더에 담아 보내면 서버는 IdP 공개키로 서명을 검증한다. Okta·Entra ID·Keycloak과 연동하는 패턴이 여기에 해당한다.

인증이 사용자를 확인하는 절차라면, 실제 도구와 리소스 접근은 역할 기반 접근 제어(RBAC)가 결정한다. 서버는 토큰의 클레임(claim)을 해석해 사용자·그룹·역할별 허용 범위를 동적으로 계산하며, 이 구조를 부서별 데이터 격리에도 활용할 수 있다.

감사 로그에는 도구 호출의 요청·응답·오류와 함께 타임스탬프, 사용자 ID, 입출력 해시를 기록한다. 로그는 추가 전용(append-only)으로 보관하고 SIEM 시스템과 연동한다. 다만 기록 과정에서 PII(개인식별정보), 신용카드번호, API 키가 다시 노출되지 않도록 전처리 계층에서 민감 정보를 마스킹해야 한다.

게이트웨이가 트래픽과 장애를 분리하는 방식

여러 MCP 서버를 운영한다면 각 서버에 같은 통제 기능을 반복하기보다 앞단에 MCP 게이트웨이를 둘 수 있다. 게이트웨이는 라우팅·인증·레이트 리미팅·관측성을 중앙에서 처리한다.

처리량은 클라이언트별·도구별·전역 레벨의 3단계 토큰 버킷으로 제어한다. 버스트 허용 파라미터를 사용하면 단기 피크도 수용할 수 있다. 요청은 에이전트 등급인 실시간·배치·백그라운드에 따라 서로 다른 우선순위 큐로 보내 중요 에이전트의 지연을 관리한다.

특정 MCP 서버의 오류율이 임계값을 넘으면 서킷 브레이커가 연결을 차단하고 대체 서버로 페일오버한다. LLM API 호출 비용도 게이트웨이에서 추적할 수 있다. 일일·월별 예산 한도에 가까워졌을 때 처리량을 제한하는 비용 인식 스로틀링을 적용하는 방식이다.

JSON-RPC와 전송 계층이 만나는 지점

MCP는 JSON-RPC 2.0을 기반으로 하며, 전송 레이어로 로컬 프로세스용 stdio와 원격 HTTP용 SSE를 지원한다. 클라이언트와 서버는 초기 핸드셰이크를 마친 뒤 양방향 메시지 채널을 유지하면서 도구 호출, 리소스 구독, 알림을 주고받는다.

게이트웨이가 있는 구성에서는 초기화와 도구 호출이 다음 순서로 전달된다.

⤢✕

initialize 핸드셰이크에서는 클라이언트와 서버가 지원하는 프로토콜 버전 목록을 교환하고 공통 최신 버전을 선택한다. 실행 시간이 긴 도구는 SSE를 통해 중간 진행 상황을 전달하며, 클라이언트는 이를 진행 표시와 타임아웃 갱신에 사용한다.

여러 도구 호출을 단일 HTTP 요청으로 묶는 배치 모드는 네트워크 왕복(Round-Trip) 비용을 줄이는 데 쓰인다. SSE 연결에는 30초 간격의 하트비트 이벤트를 보내 중간 프록시의 연결 타임아웃을 방지한다.

도구 호출이 체인으로 이어질 때의 실패 처리

복잡한 태스크에서는 하나의 도구로 작업이 끝나지 않는다. 순차 체인은 앞선 도구의 출력을 다음 도구의 입력으로 넘기며, 중간 결과는 클라이언트 측 상태 객체에 저장한다. 서로 독립적인 호출은 병렬로 실행한 뒤 결과를 합치는 fan-out/fan-in 패턴으로 구성할 수 있다. 구현에서는 Promise.all 또는 asyncio.gather를 사용할 수 있다.

오류는 JSON-RPC 표준 코드와 MCP 확장 코드로 구조화한다. 표준 오류에는 ParseError(-32700), InvalidRequest(-32600), MethodNotFound(-32601), InvalidParams(-32602), InternalError(-32603)가 포함된다.

재시도 여부는 오류 성격에 따라 달라진다. 네트워크 단절이나 서버 과부하 같은 일시적 오류는 지수 백오프로 다시 시도하고, 권한 거부나 스키마 불일치처럼 반복해도 해결되지 않는 오류는 즉시 실패로 처리한다.

오래 걸리는 실행은 상태와 취소까지 설계한다

장시간 실행되는 도구가 연결을 계속 붙잡고 있을 필요는 없다. 서버가 즉시 태스크 ID를 반환하고, 클라이언트가 별도의 tasks/status 호출로 완료 여부를 폴링하거나 SSE 알림을 구독하도록 구성할 수 있다.

중복 실행을 막으려면 클라이언트가 생성한 UUID를 각 호출의 requestId에 넣는다. 서버는 같은 요청을 감지하면 작업을 다시 실행하는 대신 기존 결과를 반환해 멱등성을 보장한다.

연속된 도구 호출 사이에서 공유해야 할 정보는 서버 측 세션 범위 컨텍스트 객체에 둘 수 있다. 세션 만료 정책을 함께 적용해 남은 상태가 리소스 누수로 이어지지 않게 해야 한다. 실행 중단은 $/cancel 알림으로 전달하며, 서버는 취소를 받으면 리소스를 해제하고 RequestCancelled 오류를 반환한다.

다운로드 증가를 만든 생태계 조건

MCP는 2024년 11월 공개된 뒤 약 18개월 만에 9,700만 다운로드를 달성했다. 이 성장 속도는 Docker·npm 등 주요 개발자 도구의 초기 성장 궤적을 상회한다.

Anthropic이 Claude Desktop에 MCP 클라이언트를 내장한 것은 초기 사용자 기반을 확보하는 촉매가 됐다. 이후 Cursor·VS Code·JetBrains 등 AI 코딩 도구가 MCP 클라이언트를 포함하면서 수백만 명의 개발자가 일상적인 개발 환경에서 MCP를 사용하게 됐다.

클라우드 측 지원도 배포 장벽을 낮췄다. AWS Bedrock·Azure AI Foundry·Google Vertex AI는 MCP 서버 호스팅과 관리형 MCP 게이트웨이를 출시했다. 여기에 GitHub·Slack·Notion·Jira·PostgreSQL을 비롯한 서비스용 공식 및 커뮤니티 MCP 서버가 9,400개 이상 공개되면서 바로 연결할 수 있는 도구 범위가 넓어졌다. LangChain·AutoGen과 같은 프레임워크 통합도 생태계 확산에 작용했다.

Linux Foundation 이전이 바꾼 의사결정 구조

Anthropic에서 Linux Foundation 산하 Agentic AI Foundation으로 거버넌스가 넘어간 것은 관리 주체만 바뀐 사건이 아니다. 단일 벤더 프로토콜이 업계 공용 표준으로 전환되는 기준점에 가깝다.

중립 거버넌스는 OpenAI·Google·Microsoft 같은 경쟁 기업이 MCP를 채택할 때 느끼는 심리적 장벽을 낮춘다. 실제로 거버넌스 이전 이후 복수의 대형 AI 기업이 MCP 지원을 공식 발표했다.

기능 추가와 파괴적 변경은 RFC(Request for Comments) 기반의 공식 표준화 프로세스에서 커뮤니티 검토를 받는다. MCP 관련 특허와 상표는 Linux Foundation의 지식재산권 정책 아래 관리돼 구현자가 법적 리스크 없이 상용 제품에 통합할 수 있다. 특정 기업의 전략 변화와 무관하게 프로토콜을 유지·발전시키는 구조는 엔터프라이즈의 장기 투자 판단에도 영향을 준다.

표준화의 다음 대상은 운영 관행이다

엔터프라이즈 AI 에이전트의 78%가 MCP를 채택한 시점에서는 기능 호환성만으로 표준화를 설명하기 어렵다. 인증, 감사, 트래픽 제어, 데이터 거주성, 멀티 에이전트 신뢰 같은 운영 관행까지 공통 기준으로 다뤄야 한다.

Linux Foundation 산하 Agentic AI Foundation은 MCP 서버 구현의 보안·호환성·성능 기준을 정의하고 인증하는 공식 프로그램을 수립할 예정이다. 기본 MCP 명세에 SSO·감사·레이트 리미팅·데이터 거주성(Data Residency) 요구사항을 더한 엔터프라이즈 프로파일도 별도 사양으로 제정이 진행 중이다.

에이전트가 다른 에이전트를 대신해 MCP 서버를 호출할 때 필요한 신뢰 체인 검증 표준은 2026 H2 로드맵에 포함돼 있다. OpenTelemetry와 MCP 도구 호출 추적을 결합하는 표준 계측 방식도 정립돼 엔터프라이즈 APM 도구와 네이티브로 연동될 전망이다.

MCP의 9,700만 다운로드와 엔터프라이즈 에이전트 78% 채택은 AI 도구 통합 표준이 실질적으로 수렴하고 있음을 보여준다. Linux Foundation으로의 거버넌스 이전은 중립성과 지속성을 제도적으로 뒷받침한다. 구현자에게 남은 과제는 MCP를 연결하는 데서 끝나지 않는다. 보안 거버넌스, 비동기 실행, 게이트웨이 레이트 리미팅을 함께 갖춘 프로덕션 아키텍처로 운영해야 한다.