MCP의 벤더 중립 거버넌스와 에이전트 통합 아키텍처

MCP가 줄이는 통합 복잡도

AI 애플리케이션이 데이터베이스, 파일시스템, 외부 API와 연결될 때마다 전용 커넥터를 구현하면 통합 지점이 빠르게 늘어난다. 에이전트가 N개이고 연결할 서비스가 M개라면 필요한 통합 코드는 최대 N×M개다. MCP(Model Context Protocol)는 에이전트 쪽에 MCP 클라이언트를 두고 서비스 쪽에 MCP 서버를 노출하는 방식으로 이 구조를 N+M으로 줄인다.

MCP는 AI 에이전트와 외부 도구·데이터 소스·서비스가 상호작용하는 방법을 정의한 오픈 프로토콜이다. 서로 다른 하드웨어를 공통 규격으로 연결하는 USB-C처럼, 에이전트와 외부 시스템 사이에 범용 통합 레이어를 제공한다.

통신 기반은 JSON-RPC 2.0이며, 프로토콜이 노출하는 대상은 Tools, Resources, Prompts로 구분된다. Tools는 데이터베이스 쿼리나 폼 제출처럼 LLM이 실행할 수 있는 함수다. Resources는 파일이나 API 응답처럼 부작용 없이 읽는 데이터 소스를 뜻한다. Prompts는 서버가 제공하는 재사용 가능한 명령 템플릿으로, 에이전트의 역할과 작업 방식을 형성한다.

단일 기업의 프로토콜에서 공개 거버넌스로

Anthropic은 2025년 12월 MCP를 Linux Foundation 산하 Agentic AI Foundation(AAIF)에 기증했다. 소스 코드를 공개하는 데 그치지 않고 프로토콜의 의사결정 구조까지 벤더 중립 재단으로 옮긴 조치다.

AAIF는 Linux Foundation의 directed fund로 설립됐으며 Anthropic, Block, OpenAI가 공동 창립에 참여했다. AWS, Google, Microsoft, Cloudflare, Bloomberg 등은 플래티넘 멤버로 합류했다. 2026년 중반 기준 회원사는 170개 이상이다.

단일 벤더가 표준을 관리하면 그 기업의 이해관계가 기술의 발전 방향에 개입할 수 있다. AAIF로의 이전은 경쟁 관계에 있는 기업도 동등한 위치에서 MCP에 기여할 수 있는 기반을 마련했다.

MCP와 함께 Block의 로컬 우선 오픈소스 AI 에이전트 프레임워크인 goose, OpenAI가 제안한 AI 코딩 에이전트용 프로젝트 지침 표준인 AGENTS.md도 AAIF에 기증됐다. 각각 프로토콜, 실행 프레임워크, 프로젝트 지침을 공개 표준 생태계 안에서 다루려는 흐름이다.

⤢✕

MCP에 공식 ISO/IEC 또는 IETF 표준 번호가 부여된 상태는 아니다. Microsoft가 IETF 공식 표준화를 주도적으로 추진하고 있다. 2026년 로드맵에는 Stateless HTTP, 세션 처리와 서버 검색을 포함한 전송 계층 진화가 들어 있다. 비동기 작업과 멀티에이전트 조율, 기여자 사다리와 위임 모델, 감사 추적·OAuth 2.1·게이트웨이 동작·구성 이식성도 추진 범위에 포함된다.

호스트와 서버 사이에서 클라이언트가 하는 일

MCP 연결은 호스트, 클라이언트, 서버라는 세 역할로 나뉜다. 호스트는 Claude Desktop, Claude Code, Cursor 같은 LLM 애플리케이션이며 내부에서 하나 이상의 MCP 클라이언트 인스턴스를 관리한다.

클라이언트는 호스트 안에서 특정 서버와 1:1 연결을 유지한다. LLM이 만든 도구 호출을 MCP 서버가 처리할 수 있는 요청으로 변환하는 지점이다. 서버는 파일시스템, 데이터베이스, 외부 API 같은 시스템 앞에 놓이는 경량 프로세스로, 해당 시스템의 기능과 데이터를 Tools, Resources, Prompts 형식으로 공개한다.

⤢✕

세 프리미티브는 실행 여부와 제공하는 정보의 성격이 다르다.

프리미티브	역할	부작용	예시
Tools	LLM이 호출하는 실행 함수	있음	DB 쿼리, 이메일 발송, API 호출
Resources	컨텍스트 제공 데이터 소스	없음	파일 읽기, API 응답 캐시
Prompts	재사용 가능 명령 템플릿	없음	분석 스타일 가이드, 역할 정의

이 구분은 단순한 명명 규칙이 아니다. 데이터를 읽는 동작과 외부 상태를 바꾸는 실행을 프로토콜 수준에서 분리하고, 반복해서 사용할 지침은 별도의 템플릿으로 제공한다.

로컬 프로세스와 원격 서버를 잇는 전송 방식

MCP는 stdio와 Streamable HTTP라는 두 전송 메커니즘을 정의한다.

stdio 방식에서는 호스트가 MCP 서버를 서브프로세스로 실행한 뒤 표준 입출력 스트림으로 JSON-RPC 메시지를 주고받는다. Claude Desktop, Claude Code, Cursor의 로컬 통합에서 기본값으로 사용된다. 구성이 단순하고 프로세스 단위로 보안 경계를 구분하기 쉽다.

Streamable HTTP는 2025년 11월 스펙에서 도입돼 레거시 SSE 전송을 대체했다. 원격 MCP 서버, 서버리스 배포, 엔터프라이즈 게이트웨이 통합을 다루는 방식이다. 2026년 로드맵에서는 Stateless 운용이 우선순위로 제시됐다.

전송 방식은 달라도 Tools, Resources, Prompts와 JSON-RPC 2.0이라는 프로토콜 모델은 유지된다. 로컬 도구와 원격 서비스를 같은 추상화로 연결할 수 있는 이유다.

서버와 클라이언트가 함께 커진 생태계

2025년 초 약 10만 건이었던 MCP SDK 월간 다운로드는 2026년 3월 Python과 TypeScript SDK 합산 9,700만 건에 달했다. 증가 폭은 970배다.

공개 MCP 서버는 레지스트리 기준 10,000개를 넘어섰고, 커뮤니티 및 프라이빗 추정치까지 포함하면 13,000개 이상이다. 공식 레지스트리도 2026년 4월 기준 800개 서버를 돌파했다. 클라이언트는 300개 이상이며 편집기, 채팅 애플리케이션, 엔터프라이즈 플랫폼으로 범위가 넓어졌다. ChatGPT, Claude, Cursor, Gemini, Microsoft Copilot, VS Code 등이 여기에 포함된다.

기업 환경에서도 채택이 진행되고 있다. 엔터프라이즈 AI 팀의 78%는 최소 하나 이상의 MCP 지원 에이전트를 프로덕션에서 운용하고 있으며, Fortune 500 기업의 28%는 프로덕션 AI 워크플로에 MCP 서버를 배포했다. Gartner는 2026년 말까지 엔터프라이즈 애플리케이션의 40%가 태스크 특화 AI 에이전트를 포함할 것으로 전망한다.

이 성장에는 AAIF의 벤더 중립 거버넌스, 주요 클라이언트의 네이티브 지원, stdio와 HTTP JSON-RPC를 이용한 구현 방식, 검색 가능한 공식 레지스트리가 함께 작용한다.

MCP와 A2A가 나누어 맡는 통합 영역

MCP와 Google이 주도하는 A2A(Agent-to-Agent)는 같은 문제를 놓고 경쟁하는 프로토콜이 아니다. 연결 방향이 다르다.

MCP는 하나의 에이전트가 외부 도구와 데이터에 접근하는 수직 통합을 정의한다. A2A는 에이전트끼리 통신하고 작업을 위임하는 수평 조율을 다룬다. 도구 접근은 MCP로 통일하고, 벤더나 조직의 경계를 넘는 에이전트 조율이 필요할 때 A2A를 더하는 것이 2026년 엔터프라이즈 모범 사례다. 두 프로토콜은 모두 현재 AAIF에서 거버넌스되고 있다.

구분	MCP	A2A
문제 영역	에이전트 ↔ 도구/데이터	에이전트 ↔ 에이전트
통합 방향	수직	수평
성숙도	높음 (2024 론칭)	중간 (2025 론칭)
클라이언트 수	300+	성장 중
거버넌스	AAIF	AAIF

두 프로토콜을 함께 사용하면 에이전트는 MCP를 통해 필요한 도구를 실행하면서 A2A로 다른 에이전트에 서브태스크를 넘길 수 있다. MCP가 모든 에이전트 통신을 대신하는 것도, A2A가 도구 연결 규격을 대체하는 것도 아니다.

기존 아키텍처 개념으로 읽는 MCP

소프트웨어공학의 관점에서 MCP는 인터페이스 표준화로 N×M 통합 복잡도를 N+M으로 낮추는 구조다. 전송 계층, 프로토콜 계층, 애플리케이션 계층을 분리한다는 점에서는 계층화 설계와 연결되고, Linux Foundation과 IETF를 통한 전개는 벤더 중립 표준화 사례로 볼 수 있다.

Resources는 데이터 소스의 차이를 공통 인터페이스 뒤에 감춘다는 점에서 DBMS 독립성을 위한 데이터 추상화 레이어와 닮았다. OAuth 2.1 통합, 감사 추적, 게이트웨이 동작은 인증·인가·접근제어 프레임워크와 이어진다.

디자인 패턴으로 보면 외부 시스템의 복잡성을 단일 인터페이스로 감추는 Facade, 서로 다른 시스템을 호환 가능한 형태로 바꾸는 Adapter, 분산 컴포넌트 사이의 통신을 조율하는 Broker의 성격이 함께 나타난다. 멀티에이전트 설계에서 MCP와 A2A를 조합한 구조는 서비스 메시 패턴과도 유사하다.

2026년 IETF 표준화가 완료되면 MCP는 HTTP나 REST API와 같은 인터넷 표준의 참조 사례로 정보관리기술사 시험에서 다뤄질 가능성이 높다.

Stateless 운용과 자동 발견이 향하는 곳

MCP 2026년 H2 로드맵은 Stateless 서버 운용, MCP Server Cards, 멀티에이전트 A2A 조율 성숙화를 핵심 항목으로 둔다.

현재 MCP 서버는 세션 상태를 유지해야 하는 경우가 많아 서버리스 배포에 제약이 있다. Stateless HTTP 지원이 완성되면 AWS Lambda와 Cloudflare Workers 같은 엣지·서버리스 환경에도 배포할 수 있게 된다.

MCP Server Cards는 서버가 기능, 인증 요구사항, 버전 정보를 표준 형식으로 게시하는 자동 발견 메커니즘이다. 이를 통해 에이전트는 런타임에 새로운 도구를 동적으로 발견하고 통합할 수 있다.

MCP와 A2A의 통합 운용 패턴이 표준화되면 한 에이전트가 MCP로 도구를 사용하면서 A2A로 다른 에이전트에 작업을 위임하는 워크플로도 공통 방식으로 구현된다. IETF 공식 표준화가 완성되는 시점에는 MCP가 AI 인프라의 HTTP 역할을 맡고, A2A와 함께 멀티에이전트 오케스트레이션의 표준 레퍼런스 아키텍처로 확립될 것이다.