MCP 차기 스펙과 AAIF 이관이 바꾸는 에이전트 표준

프로토콜 변화와 거버넌스 이관이 함께 온다

Model Context Protocol(MCP)의 차기 공식 스펙은 2026년 7월 28일 확정·발표될 예정이다. 프로토콜을 관리하는 주체도 달라진다. Anthropic이 단독으로 이끌던 MCP가 Linux Foundation 산하 Agentic AI Foundation(AAIF)으로 이관되면서 다자 거버넌스에 기반한 커뮤니티 중립 표준으로 이동하고 있다.

이 변화는 소유권만 옮기는 일이 아니다. 단일 기업의 로드맵에 의존하던 프로토콜이 공개적인 표준 운영 구조를 갖추는 과정이며, 기업의 표준 채택 속도에도 영향을 줄 것으로 전망된다.

97M 인스톨 이후 드러난 거버넌스 과제

MCP는 Anthropic이 2024년 공개한 뒤 AI 에이전트와 외부 시스템·도구·데이터 소스를 연결하는 사실상의 표준으로 자리 잡았다. 2026년 초 누적 인스톨 수는 97M을 돌파했고 공개 서버는 10,000개를 넘어섰다. ChatGPT, Cursor, Gemini, Microsoft Copilot 등 주요 플랫폼도 MCP를 지원한다.

기술적 확산과 별개로, 기업 도입에서는 단일 기업이 프로토콜을 관리한다는 점이 계속 부담으로 남았다. 표준의 방향이 Anthropic의 로드맵에 종속될 가능성과 장기적인 지속 가능성에 대한 의문이 엔터프라이즈 아키텍트 사이에서 제기됐다. AAIF 이관은 이 구조적 한계에 대한 직접적인 대응이다.

AAIF 아래 모인 에이전트 프로젝트

Linux Foundation은 2025년 말 AAIF를 설립하면서 다음 프로젝트를 창설 기여물로 받았다.

Model Context Protocol(MCP) — Anthropic 기증
goose — Block(Square 모회사) 기여
AGENTS.md — OpenAI 기여

Anthropic, Block, OpenAI가 공동 창설 주체로 참여했고 Google, Microsoft, AWS, Cloudflare, Bloomberg 등이 지원사로 합류했다. 주요 AI 기업이 같은 재단 안에서 프로토콜 거버넌스를 맡는 구조는 MCP가 공통 표준으로 정착하는 데 힘을 싣는다.

⤢✕

SEP 병목을 줄이는 기여자 래더

AAIF 이관 이후 MCP에는 기여자가 권한을 넓혀 가는 공식 경로가 마련된다. 기존에는 모든 SEP(Spec Enhancement Proposal)를 핵심 메인테이너 전원이 검토해야 했기 때문에 의사결정 병목이 컸다.

단계	역할	권한
1단계	Community Participant	이슈 제기, PR 제출
2단계	Working Group Contributor	WG 내 SEP 공동 작성
3단계	WG Facilitator	WG 의사결정 주도
4단계	Lead Maintainer	도메인 SEP 수락 권한
5단계	Core Maintainer	전략적 감독, 주요 변경 승인

활동 실적이 검증된 Working Group은 핵심 메인테이너 전체의 리뷰를 거치지 않고도 담당 도메인의 SEP를 수락하고 확장 업데이트를 발행할 수 있다. 중앙에 몰렸던 검토 권한을 작업 그룹에 위임해 개발 속도를 높이는 모델이다.

프로토콜 계층에서 세션을 걷어낸다

차기 스펙에서 가장 큰 구조 변화는 프로토콜 계층의 완전한 스테이트리스화다. 기존 Streamable HTTP에서는 클라이언트가 세션을 수립하고 서버가 반환한 Mcp-Session-Id를 후속 요청에 계속 실어야 했다. 서버 운영 측에서는 스티키 세션이나 공유 세션 스토어, MCP를 이해하는 게이트웨이 라우팅이 필요했다.

새 구조에서는 서버가 요청을 처리하는 데 필요한 정보를 각 요청이 직접 포함한다. 특정 인스턴스에 세션이 묶이지 않으므로 어느 서버든 요청을 받을 수 있고, 표준 HTTP 수평 확장 방식을 그대로 사용할 수 있다.

⤢✕

상태는 핸들로 드러낸다

애플리케이션 상태는 프로토콜 세션 안에 감추지 않고 가시적인 핸들(handle)로 관리한다. 도구가 "basket_id": "bkt_123"을 반환하는 식이다. 모델은 이 값을 상태로 인식해 로깅하고 다음 단계로 전달할 수 있다. 상태의 위치와 전달 과정이 밖으로 드러나므로 디버깅과 감사 추적도 쉬워진다.

확장은 코어와 독립적으로 움직인다

Extensions Framework에는 역방향 DNS 식별자(reverse-DNS identifier), 독립적인 버전 관리, 협상된 기능 맵이 들어간다. 처음 구조화된 확장 사례로 제시된 대상은 다음과 같다.

MCP Apps: 에이전트의 결과를 리치 UI로 렌더링하는 샌드박스 HTML 인터페이스
Tasks: 비동기 에이전트 작업의 생명주기를 관리하는 장기 실행 워크플로

반대로 코어 MCP의 범위에서는 일부 기능이 빠진다.

디프리케이션 대상	대체 방향
Roots	도구 파라미터로 처리
Sampling	직접 LLM API 호출
Logging	OpenTelemetry 표준

코어 프로토콜은 집중된 범위를 유지하고, 새로운 실험은 확장 생태계에서 진행하도록 분리하는 방향이다.

인증과 구현 적합성의 기준도 높아진다

OAuth/OIDC 요구사항은 실제 배포 환경을 반영해 강화된다. 이슈어 검증(issuer validation), 자격증명 바인딩(credential binding), 토큰 갱신 보안이 선택적 고려사항에서 필수 요구사항으로 바뀐다.

새로운 기능 생명주기 정책과 필수 적합성 시나리오도 도입된다. 구현체 사이의 상호운용성을 보장하고 소규모 구현체가 특정 벤더에 종속될 위험을 낮추려는 장치다.

날짜 기반 버전과 협상 방식

MCP 버전 식별자는 YYYY-MM-DD 형식을 사용한다. 현행 버전은 2025-11-25, 차기 스펙은 2026-07-28이다. 하위 호환성을 깨지 않는 변경에는 버전을 올리지 않는다는 철학이 이 체계의 전제다.

클라이언트와 서버는 초기화 과정에서 지원할 프로토콜 버전을 합의한다.

⤢✕

게이트웨이에서 버전 차이를 흡수한다

기업 환경에서는 모든 MCP 서버를 한 번에 교체하기 어렵다. 게이트웨이가 클라이언트 버전과 서버 버전을 따로 관리하도록 설계하면 내부 서버를 순차적으로 마이그레이션할 수 있다.

Client (2026-07-28)
    → MCP Gateway (버전 번역 레이어)
        → Legacy Server (2025-11-25)  [마이그레이션 대기]
        → Upgraded Server (2026-07-28) [마이그레이션 완료]

이 계층은 버전 차이를 번역하는 경계가 된다. 내부에는 기존 서버와 업그레이드된 서버를 함께 두면서 외부 클라이언트에는 일관된 인터페이스를 제공할 수 있다.

서버 내부 상태를 외부화한다

세션 기반 서버를 스테이트리스 구조로 바꿀 때는 서버 메모리에 있던 상태부터 외부 스토어로 옮긴 뒤 핸들 패턴을 적용한다.

[기존] 서버 메모리 내 세션 상태
    ↓ (마이그레이션)
[신규] Redis / DynamoDB 등 외부 상태 스토어
    + 클라이언트에 핸들(basket_id, task_id 등) 반환

SEP에는 도구별 시맨틱 버전과 디프리케이션 메커니즘도 추가된다. 도구를 제거하기 전에 클라이언트가 옮겨 갈 수 있는 마이그레이션 윈도우를 제공하기 위해서다. 기업 환경에서는 최소 두 버전 뒤까지 하위 호환성을 유지하는 정책이 권장된다.

기업 채택을 뒷받침하는 지표

Gartner는 2026년 말까지 기업 애플리케이션의 40%가 작업 특화 AI 에이전트를 포함하고, API 게이트웨이 벤더의 75%가 MCP 기능을 탑재할 것으로 전망한다. 2026년 1분기에 출시된 엔터프라이즈 애플리케이션 가운데 80%는 최소 하나 이상의 AI 에이전트를 내장하고 있다. 2024년의 33%에서 크게 늘어난 수치다.

Uber, Nordstrom, Bloomberg, Duolingo, PwC 등 대형 기업의 프로덕션 배포 사례도 MCP가 실험 단계를 넘어 운영 환경에서 쓰이고 있음을 보여준다.

AAIF 이관은 이런 채택 흐름을 더 빠르게 만들 구조적 요인이다. 벤더 중립 표준은 조달 정책과 보안 심사, 장기 지원 약정을 다룰 때 단일 기업이 주도하는 프로토콜보다 유리하다.

전환 전에 점검할 운영 항목

2026년 3분기 이전에는 릴리스 후보와 현재 구현체의 호환성을 먼저 확인해야 한다. 2026-07-28 최종 스펙이 확정되기 전 10주 RC 기간이 검증 구간이다. 서버 코드베이스에서는 Mcp-Session-Id에 의존하는 부분을 찾아 스테이트리스 전환 범위를 산정해야 한다.

사내 도구를 확장 체계에 연결하려면 역방향 DNS 식별자를 사용하는 내부 네임스페이스와 레지스트리도 준비할 필요가 있다.

2026년 4분기부터는 운영 아키텍처 차원의 작업이 이어진다. AAIF Working Group은 기업 요구사항을 SEP로 표준에 반영할 수 있는 공식 채널이다. MCP 게이트웨이에는 버전 추상화, SSO 연동 인증, 감사 로그를 모을 수 있다. Logging 디프리케이션에 대응하려면 MCP 에이전트 트레이싱을 OpenTelemetry 파이프라인으로 통합해야 한다.

MCP 차기 스펙과 AAIF 이관은 서로 분리된 사건이 아니다. 스테이트리스 프로토콜과 명시적 상태 핸들, 독립 확장 프레임워크는 기업 규모의 수평 확장과 운영 투명성을 겨냥한다. 다자 커뮤니티 거버넌스는 조달·보안·장기 지원 과정에서 남아 있던 채택 장벽을 낮춘다. RC 검토와 마이그레이션 설계를 시작한 팀은 이 전환을 먼저 운영 구조에 반영할 수 있다.