MCP 표준화와 AAIF 거버넌스: AI 에이전트 도구 연동의 운영 전략

MCP가 벤더별 도구 연동을 표준 계약으로 바꾼 과정

Model Context Protocol(MCP)은 LLM 애플리케이션이 외부 도구, 데이터, 프롬프트를 공통 방식으로 연결하기 위한 개방형 프로토콜이다. 2024년 11월 Anthropic이 오픈소스로 공개한 뒤, 2025년 초 OpenAI와 Google DeepMind가 채택하면서 AI 에이전트와 외부 시스템을 잇는 사실상 표준으로 부상했다.

표준의 지속성에 대한 우려는 2025년 12월 9일 MCP가 Linux Foundation 산하 Agentic AI Foundation(AAIF)에 기증되면서 다른 국면으로 넘어갔다. MCP는 Block의 goose, OpenAI의 AGENTS.md와 함께 창립 프로젝트로 편입됐으며, AWS, Anthropic, Block, Bloomberg, Cloudflare, Google, Microsoft, OpenAI가 Platinum 창립 회원으로 참여한다.

2026년 기준 생태계도 빠르게 커졌다. 월간 SDK 다운로드는 2026년 3월 9,700만 건을 넘었고, modelcontextprotocol/servers 저장소의 GitHub 스타는 2026년 6월 87,500개를 초과했다. 커뮤니티가 구축한 서버는 2026년 3월 기준 5,000개 이상이다.

이 구조의 핵심은 클라이언트 비종속성이다. 사양을 따르는 서버는 다시 작성하지 않아도 Claude Code, Cursor, Windsurf, Codex CLI, Cline 등 호환 클라이언트에서 사용할 수 있다.

호스트와 서버가 맺는 MCP 세션

MCP는 JSON-RPC 2.0 기반의 클라이언트-서버 구조를 사용한다. 호스트 애플리케이션은 여러 격리된 MCP 클라이언트 세션을 만들고, 각 세션은 자신의 MCP 서버와 상태 기반 JSON-RPC 채널을 유지한다. 신규 사양은 상태 비저장 프로토콜 코어로의 전환도 포함한다.

서버가 노출하는 기능은 세 가지 프리미티브로 나뉜다. Tools는 외부 API 실행이나 파일 수정처럼 부수효과를 수반하는 모델 호출 대상이다. Resources는 문서, DB 레코드, 로그처럼 읽기 전용 컨텍스트를 전달한다. Prompts는 사용자 워크플로를 안내하는 사전 정의 템플릿이다.

전송은 배포 위치에 따라 구분된다. stdio는 로컬 프로세스 간 통신에 쓰이며 Claude Desktop과 Claude Code에서 로컬 서버를 실행할 때 기본값이다. Streamable HTTP는 2025년 11월 사양에서 도입돼 레거시 SSE(Server-Sent Events)를 대체했고, MCP 서버를 원격 서비스로 운영할 수 있게 한다.

⤢✕

2026년 7월 28일 발표된 차기 사양 릴리스 후보(RC)는 상태 비저장 코어를 중심에 둔다. Streamable HTTP는 Mcp-Method, Mcp-Name 헤더를 요구하므로, 로드밸런서·게이트웨이·레이트리미터는 본문을 검사하지 않고도 오퍼레이션 단위 라우팅을 수행할 수 있다.

RC에는 Extensions 프레임워크, Tasks(장기 실행 작업), MCP Apps, 인가 강화(authorization hardening), 공식 폐기 정책(deprecation policy)도 포함된다. 방향은 코어를 얇게 유지하고 부가 기능은 확장으로 분리하는 것이다.

프로덕션 도입에서 먼저 통제할 범위

서버를 설계할 때는 노출할 능력을 Tools, Resources, Prompts 중 어디에 둘지 명확히 나눠야 한다. 로컬 도구에는 stdio를, 원격 서비스에는 Streamable HTTP를 선택한다. 사양 버전을 명시하고 Mcp-Method, Mcp-Name 같은 신규 요구사항을 반영해야 게이트웨이 환경과의 호환성을 확보할 수 있다.

원격 서버에서는 OAuth 2.1 + PKCE가 사양상 필수다. 하지만 실제 채택률은 8.5%에 그치며, 구현이 쉬운 정적 API 키에 의존하는 사례가 많다. 최소 권한 원칙을 적용해 과도하게 넓은 권한을 차단하고, 상태 비저장 코어 전환에 대비해 세션 의존 로직도 줄일 필요가 있다.

커뮤니티 서버를 가져오는 과정은 별도의 보안 검증 절차로 다뤄야 한다. 공식 레지스트리는 보안 스캐닝을 수행하지 않으며, 1만 7천 개 이상 항목을 가진 비공식 디렉터리는 검증이 전무하다. 배포 뒤 동작을 바꾸는 “rug pull” 공격을 고려하면 사전 검토만으로는 부족하고, 런타임 행위 모니터링도 병행해야 한다.

여러 서드파티 서버를 체이닝하는 프로덕션 환경에서는 한 링크의 악성 코드가 전체를 위협할 수 있다. Censys 조사(2026년 4~5월)에서는 인터넷에 노출된 MCP 서비스가 1만 2천여 개에서 2만 1천 개 이상으로 급증했고, 약 40%는 인증이 없었다. 서버 호스팅, OAuth 인증 인프라, 모니터링, 감사 로그(audit trail) 비용을 함께 산정하고 승인된 서버 화이트리스트를 관리하는 이유다.

커스텀 함수 호출과 달라지는 통합 비용

비교 축	MCP 표준	커스텀 함수 호출 / 벤더 플러그인
상호운용성	클라이언트 비종속, 1회 구축 후 다중 클라이언트 재사용	클라이언트·벤더별 개별 구현 필요
통합 방식	네이티브 지원(Claude Code·Cursor·Windsurf 등)	어댑터·래퍼로 개별 연동
거버넌스	중립 재단(Linux Foundation/AAIF)	단일 벤더 주도
지속성	벤더 중립으로 락인(lock-in) 위험 낮음	벤더 정책 변경 시 단절 위험
전송 표준	JSON-RPC 2.0, stdio / Streamable HTTP 통일	벤더별 상이한 프로토콜
보안 사양	OAuth 2.1+PKCE 표준 규정	벤더별 임의 방식

커스텀 함수 호출은 특정 모델이나 SDK에 묶이기 쉬워 이식성이 낮다. 반면 MCP 서버는 여러 에이전트가 재사용할 수 있으므로 통합 비용을 크게 줄인다.

거버넌스 구조도 다르다. 단일 벤더가 관리하는 표준은 해당 벤더의 사업 방향에 따라 지속성이 흔들릴 수 있다. Linux Foundation의 중립 거버넌스는 8개 Platinum 회원사의 균형 참여를 통해 장기 지속성을 담보한다. 네이티브 지원은 어댑터 계층 없이 표준 사양만으로 연동하게 해 유지보수 부담과 장애 지점을 줄인다.

엔터프라이즈 통합과 보안 거버넌스에 연결하기

MCP는 EAI(Enterprise Application Integration)의 ESB(Enterprise Service Bus)가 다루던 N×M 연동 문제를 AI 에이전트 영역에서 다시 마주하게 한다. M개 클라이언트와 N개 도구를 각각 연결하면 M×N개의 통합이 필요하지만, MCP라는 표준 허브를 두면 M+N으로 수렴한다. 표준 인터페이스를 통한 느슨한 결합(loose coupling)과 관심사 분리가 이 구조의 중심이다.

MCP는 REST나 GraphQL 같은 인터페이스 표준 위에서 작동하는 에이전트-도구 계약(contract) 계층으로도 볼 수 있다. 따라서 조직의 API 거버넌스에서 운영하는 버전 관리, 폐기 정책, 인증 정책과 정합성을 맞춰야 한다. MCP의 공식 폐기 정책은 기존 API 라이프사이클 관리 원칙과 연결된다.

보안 통제에서는 공급망 보안이 출발점이다. SBOM 유사 개념의 서버 목록 관리, OAuth 2.1 인증, 감사 추적성 확보가 도입의 전제 조건이 된다. 검증되지 않은 커뮤니티 서버를 무분별하게 도입하면 정보보호 관리체계(ISMS) 통제 항목 위반으로 이어질 수 있다.

AAIF 체제 이후의 변화

AAIF 체제에서는 워킹그룹이 우선순위를 정한다. 2026 로드맵은 전송 진화, 에이전트 통신 라이프사이클, 거버넌스 성숙, 엔터프라이즈 준비의 4대 축으로 정리된다.

프로토콜 코어의 상태 비저장화는 서버리스와 수평 확장 배포를 쉽게 만들어 엔터프라이즈 프로덕션 도입을 가속할 전망이다. 인증이 없는 서버가 다수인 현실은 레지스트리 검증 체계와 런타임 모니터링 도구 시장의 성장을 촉발할 것이다. AGENTS.md, goose 등이 AAIF 아래에 함께 들어오면서 에이전트 상호운용 표준군이 형성되고, MCP는 그 사이를 잇는 연결 계층으로 자리 잡게 된다.

MCP의 Linux Foundation 기증은 소유권 이전에 그치지 않는다. 단일 벤더 표준이 지닌 지속성 리스크를 낮추고, 산업 전반이 신뢰할 수 있는 중립 표준으로 옮겨간 전환점이다. 이제 운영의 관건은 표준 채택 여부보다 검증되지 않은 커뮤니티 서버와 낮은 인증 채택률이 만드는 공급망 리스크를 얼마나 체계적으로 통제하느냐에 있다.