2026년 5월 21일, Model Context Protocol (MCP)의 차기 사양이 출시 후보(RC)로 확정되었다. 최종판 공개는 2026년 7월 28일. 공식 측은 "launch 이후 최대의 개정"이라고 규정하고 있으며, 트랜스포트(Transport)를 스테이트리스(Stateless)로 재설계하고, UI·장시간 처리(Long-running process)를 확장(Extension)으로 분리하며, 인가를 OAuth 2.0 / OpenID Connect로 통합하고, 정식 비권장(Deprecated) 정책을 도입한다.

RC부터 최종판까지의 약 10주는 SDK 메인테이너와 구현자가 실제 워크로드(Workload)에서 검증하기 위한 기간으로 설정되어 있다. 즉, "7월 28일에 갑자기 바뀌는" 것이 아니라, 지금 가지고 있는 MCP 서버/클라이언트에서 무엇이 망가지는지를 파악할 여유가 있다는 뜻이다. 이 기사에서는 무엇이 바뀌는지와 이 10주 동안 수정해 두어야 할 것을 정리한다.

RC는 세션 확립을 위한 initialize / initialized 핸드셰이크와 Mcp-Session-Id 헤더를 폐지한다. 클라이언트의 정보와 케이퍼빌리티(Capability)는 매 요청의 _meta에 실어서 전달하는 방식이 된다.

원문: "any MCP request can land on any server instance, and the sticky routing and shared session stores that horizontal deployments needed before are no longer required at the protocol layer."

일본어 번역: 「어떤 MCP 요청도 어떤 서버 인스턴스에 도달해도 좋으며, 수평 확장(Horizontal scaling) 시 이전에 필요했던 스티키 라우팅(Sticky routing)이나 공유 세션 스토어는 프로토콜 계층에서 더 이상 필요하지 않다」(MCP 공식 블로그)

배경에는 스케일링(Scaling) 시의 실제 운영 과제가 있다.

원문: "stateful sessions fight with load balancers, horizontal scaling requires workarounds, and there's no standard way for a registry or crawler to learn what a server does without connecting to it."

일본어 번역: 「스테이트풀(Stateful)한 세션은 로드 밸런서와 충돌하고, 수평 확장에는 우회책이 필요하며, 레지스트리나 크롤러가 서버에 접속하지 않고 서버의 기능을 알 수 있는 표준적인 방법도 없었다」(2026 MCP Roadmap)

지금까지 "처음에 한 번만 초기화하고 이후에는 그 세션을 재사용한다"는 전제로 MCP 서버를 작성했다면, 그 전제가 무너진다. 서버를 컨테이너로 여러 개의 레플리카(Replica)를 실행하고, 라운드 로빈(Round Robin) 전단에 배치하는—일반적인 웹 구성이 프로토콜 측의 특별한 취급 없이도 통하게 된다.

반대로, 메모리 상에 세션 상태를 보유하고 있던 구현은 주의가 필요하다. 상태를 외부 스토어(DB·KVS)로 분리하거나, 애초에 매 요청마다 자기 완결적(self-contained)인 방식으로 재설계해야 한다. n8n이나 서버리스(Serverless, Cloudflare Workers / Vercel) 환경에서 MCP 서버를 구동하고 있다면, 이 변경은 오히려 호재가 될 것이다.

MCP Apps는 서버가 인터랙티브(Interactive)한 HTML 인터페이스를 제공하고, 호스트 측이 샌드박스(Sandbox)화된 iframe으로 렌더링하는 메커니즘이다. 툴(Tool)은 UI 템플릿을 사전에 선언하며, 호스트는 이를 프리페치(prefetch)·캐시(cache)·보안 리뷰(security review)한 후 실행할 수 있다.

원문: "every UI-initiated action goes through the same audit and consent path as a direct tool call."

일본어 번역: 「UI 기점의 모든 조작은 직접적인 툴 호출과 동일한 감사·동의 경로를 통한다」(MCP 공식 블로그)

'텍스트의 왕복'이었던 MCP에 서버 측이 UI를 도입할 수 있게 된다. 승인 버튼, 폼(Form), 대시보드(Dashboard)와 같은 상호작용을 호스트 외부에 구축하지 않고 서버에서 제공할 수 있다.

중요한 점은 UI 조작이 툴 호출과 동일한 동의·감사 경로를 통한다는 것이다. 겉모습만 버튼이라고 해서 멋대로 권한 승격(Privilege Escalation)을 일으키는 우회로가 되지 않는다. 도입하는 측은 "iframe이니까 안전하다"며 그냥 지나치지 말고, UI 템플릿을 배포 전에 리뷰하는 운영을 전제로 삼아야 한다.

장시간 처리를 다루는 Tasks는 2025-11-25에 실험적인 코어 기능(Core Function)으로 도입되었으나, 본 프로덕션 운영을 위한 재설계를 거쳐 코어 사양이 아닌 확장(Extension)으로 재정의되었다. 새로운 라이프사이클(Lifecycle)은 스테이트리스(Stateless)를 전제로 재구축되었다.

• 서버는 tools/call에 대해 태스크 핸들(Task Handle)을 반환한다.
• 클라이언트는 tasks/get / tasks/update / tasks/cancel로 진행을 구동한다.
• tasks/list는 폐지된다.
• 태스크화는 서버 주도: 클라이언트가 확장 대응을 표명하고, 그 호출을 태스크로 실행할지는 서버가 결정한다.

수십 초에서 수 분이 걸리는 처리(배치 생성, 외부 API 대기, 긴 툴 실행)를 커넥션을 계속 유지하지 않고 폴링(Polling) 방식으로 다룰 수 있게 된다. 스테이트리스화와 일치하는 설계다.

이미 Tasks를 코어 기능으로 구현하고 있었다면, 이는 파괴적 변경(Breaking Change)이 된다. tasks/list에 의존하던 부분은 다른 수단(태스크 핸들의 자체 관리)으로 옮겨야 한다. 장시간 처리를 가진 서버는 RC(Release Candidate) 기간 중에 확장 기반의 라이프사이클로 옮겨두는 것이 좋다.

인가(Authorization) 관련은 6개의 SEP를 통해 OAuth 2.0 / OpenID Connect와의 정합성이 강화된다. 주요 내용은 다음과 같다.

• 클라이언트는 iss 파라미터를 RFC 9207에 따라 검증한다.
• 동적 클라이언트 등록(DCR)에서 OpenID Connect의 application_type을 선언한다.
• 크리덴셜(Credential)을 인가 서버의 issuer에 연결한다.
• OpenID Connect 서버를 위한 리프레시 토큰(Refresh Token) 절차가 명문화된다.

'일단 돌아가는 OAuth'로 대충 처리하던 MCP 클라이언트는 표준 준수 검증을 구현해야 하는 상황이 된다. 특히 iss 검증의 부재는 토큰 갈아치우기(Token Substitution)로 이어지는 전형적인 취약점인데, 이 부분이 사양으로 요구되는 것은 실무상 다행스러운 일이다. 자체적으로 인가를 구현하고 있다면 기존의 OIDC 라이브러리에 맞추는 것이 지름길이다.

기능의 라이프사이클로서 Active / Deprecated / Removed의 3단계가 신설되었다. 비권장(Deprecated)에서 최단 삭제(Removed)까지 최소 12개월의 간격을 두도록 규정되어 있다. 이번에 Roots, Sampling, Logging의 3가지 기능이 비권장(Deprecated) 상태가 되었으나, 이행 기간 중에는 계속 동작한다.

"어느 날 갑자기 사라지는 것"을 방지하는 공식 규칙이 생김으로써, 상용 이용에서의 예측 가능성이 높아졌다. Roots, Sampling, Logging을 사용하고 있다면 당장 동작이 멈추는 것은 아니다. 다만 신규 구현에서 이들에 의존하는 것은 피하고, 대체 수단 검토를 시작하는 것이 타당하다. 비권장 기능의 정리(Inventory)는 12개월이라는 유예 기간이 있는 동안 계획적으로 진행해야 한다.

사양의 변화가 "실제 프로덕트에서 어떻게 나타나는가"의 한 예로, Anthropic이 2026년 5월 19일(Code with Claude, 런던)에 발표한 Claude Managed Agents의 2가지 기능이 이해하기 쉽다.

• 자기 호스트 Sandbox (Public Beta): 도구 실행을 고객 자신의 인프라, 또는 Cloudflare, Daytona, Modal, Vercel 등의 매니지드 프로바이더(Managed Provider) 위에서 실행할 수 있다. 오케스트레이션(Orchestration), 컨텍스트 처리, 복구(Recovery)는 Anthropic 측에서 담당하며, 도구 실행과 데이터는 고객의 경계 내에 머문다. 고객은 네트워크 정책, 감사 로그(Audit Log), 런타임 설정, 데이터 소재지를 관리할 수 있다.
• MCP Tunnels (Research Preview): 프라이빗한 MCP 서버를 인터넷에 노출하지 않고 에이전트(Agent)에 연결한다. 인바운드(Inbound) 방화벽 포트를 여는 대신, 경량 게이트웨이가 Anthropic을 향해 **아웃바운드 암호화 연결(Outbound Encrypted Connection)**을 하나 생성한다. 사내 DB, API, 티켓 시스템, 지식 베이스(Knowledge Base)를 기존의 보안 경계를 유지한 채 에이전트에 전달할 수 있다.

MCP의 "스테이트리스화 (Statelessness)", "인가(Authorization)의 표준화"가 지향하는 곳은 이러한 엔터프라이즈 경계 내부에서 에이전트를 구동하는 유스케이스다. 데이터를 외부로 내보내지 않고, 공개 엔드포인트(Public Endpoint)도 만들지 않으며, 감사 경로를 단일화한다는 요구사항에 프로토콜과 제품 모두가 맞춰지고 있다.

자사에서 MCP 서버를 운영한다면, "아웃바운드 1개 + 인가 표준 준수 + 스테이트리스" 형태가 당분간의 핵심 모델이 될 것이다. 반대로, 인바운드를 개방하여 공개 엔드포인트를 생성하는 설계는 앞으로 역풍을 맞기 쉽다.

트랜스포트 (Transport) / 스테이트리스 (Stateless)

• 서버가 메모리 상에 세션 상태를 보유하고 있는지 점검한다.
• 상태를 외부 스토어(External Store)로 분리하거나, 매 요청마다 자기 완결적으로 동작하도록 재설계한다.
• 라운드 로빈(Round Robin) 로드 밸런서(Load Balancer)를 통한 동작(복제본 다수)을 확인한다.
• 클라이언트 정보를 _meta로 전달하는 새로운 방식에 대응한다.

Tasks / 장시간 처리 (Long-running Processing)

• 장시간 처리를 확장 기반의 라이프사이클(Task Handle)로 이전한다.
• tasks/list에 대한 의존성을 파악하고, 자체 관리 방식으로 교체한다.

인가 (Authorization)

• 클라이언트에 iss 검증 (RFC 9207)을 구현한다.
• DCR을 통해 application_type을 선언하고, 자격 증명(Credential)을 issuer에 연결한다.
• 자체 인가 방식을 기존의 OIDC 라이브러리에 맞춘다.

MCP Apps / 비권장 (Deprecated)

• UI 템플릿을 배포 전 리뷰 대상으로 포함한다.
• Roots, Sampling, Logging의 사용처를 점검하고 이행 계획을 수립한다.

스케줄 (Schedule)

• 7월 28일 최종판 출시까지의 10주 동안, 위 사항들을 RC(Release Candidate) 구현에 대해 검증한다.

패턴 1: "최종판이 나온 뒤에 대응하겠다"며 미루는 경우

RC부터 최종판까지의 10주는 Tier 1 SDK가 대응책을 내놓기 위한 검증 기간이다. 최종판 공개 후에 착수하면, SDK 및 의존 라이브러리의 대응을 기다리는 것과 자사 수정 작업이 겹쳐 병목 현상이 발생한다. 대책: 현재 사용 중인 SDK의 RC 대응 상황을 확인하고, 검증을 앞당겨 진행한다.

패턴 2: 스테이트리스화를 단순히 "헤더 이름의 변경" 정도로 치부하는 경우

Mcp-Session-Id가 사라지는 것은 표면적인 현상일 뿐, 본질은 "어느 인스턴스에 도달하더라도 처리가 완결되는" 설계로의 전환이다. 메모리 상의 세션에 의존한 상태를 유지하면, 수평 확장(Horizontal Scale)하는 순간 시스템이 무너진다. 대책: 상태를 보유하는 방식 자체를 재검토한다.

패턴 3: Tasks를 핵심 기능으로 구축해 둔 채 방치하는 경우

tasks/list의 폐지나 태스크 핸들(Task Handle) 방식으로의 변경은 파괴적 변경(Breaking Change)이 될 수 있다. 대책: 장시간 처리를 수행하는 서버는 RC 기간 중에 확장 기반의 라이프사이클로 이전한다.

패턴 4: MCP Apps를 단순히 "편리한 UI"로만 보는 경우

UI 기반의 조작도 도구 호출과 동일한 동의 및 감사 경로를 거쳐야 한다는 것이 설계의 핵심이다. 리뷰를 생략하면 UI가 권한의 우회로(Backdoor)가 될 위험이 있다. 대책: UI 템플릿을 일반적인 도구와 동일한 심사 대상으로 포함한다.

• 2026-07-28 MCP 사양 출시 후보 (Model Context Protocol Blog)
• 2026 MCP 로드맵 (Model Context Protocol Blog)
• Model Context Protocol Blog
• Anthropic, 내부 시스템에 대한 프라이빗 에이전트 접근을 위한 MCP Tunnels 도입 (InfoQ)
• Anthropic, AI 에이전트 인프라 보안 강화를 위해 MCP tunnels 및 셀프 호스팅 샌드박스(self-hosted sandboxes) 공개 (The New Stack)