MCP 2026-07-28 스펙 RC: 상태 없는 프로토콜 코어·확장 프레임워크·인증 강화로 에이전트 연결 경계를 다시 그은 방식

왜 이 변화가 지금인가

MCP의 2025-11-25 안정 버전은 프로토콜의 기초를 놓았다. 세션 기반으로 클라이언트와 서버를 연결하고, 도구·리소스·프롬프트를 표준 방식으로 노출하며, 다양한 SDK와 런타임이 동일한 인터페이스를 쓸 수 있게 했다. 그러나 에이전트를 프로덕션에서 운영하기 시작한 팀들은 예상치 못한 곳에서 벽을 만났다.

세션 sticky routing이 필요하다. 서버 인스턴스를 늘리면 클라이언트가 항상 같은 인스턴스로 돌아와야 한다. SSE(Server-Sent Events) 스트림을 유지해야 사용자 입력을 기다릴 수 있다. Tasks가 실험적이라 프로덕션 배포가 불안하다. Sampling과 Roots는 쓰기 애매한 경계에 있다. 인증은 있지만 OAuth 2.1 자원 서버로서의 역할이 명확하지 않다.

2026-07-28 스펙 릴리스 캔디데이트(RC)는 이 문제들을 한꺼번에 다룬다. RC는 2026년 5월 21일 확정됐고, 최종 스펙은 7월 28일 발행된다. 핵심 메시지는 하나다. MCP 서버가 이제 상태 없는 일반 HTTP 서비스처럼 운영될 수 있다.

핵심 변화 한눈에 보기

1. 상태 없는 프로토콜 코어: 무엇이 사라졌고 무엇이 남았나

세션과 초기화 핸드셰이크가 제거됐다

2025-11-25 스펙에서는 클라이언트가 처음 연결할 때 initialize 메서드를 보내고 서버가 initialized 알림을 받아야 통신이 시작됐다. 그리고 서버마다 Mcp-Session-Id 헤더를 발행해 세션을 유지했다.

2026-07-28 RC는 이 두 가지를 모두 제거한다.

클라이언트는 이제 server/discover를 통해 서버 능력을 확인하고, 프로토콜 버전과 기능 선언은 _meta 필드에서 읽는다. 초기화 라운드트립이 없으니 첫 요청 지연이 줄어든다. 그리고 세션 ID가 없으니 클라이언트 요청이 어느 서버 인스턴스에 도달해도 동일하게 처리된다.

이 변화가 운영에 미치는 가장 큰 영향은 인프라 단순화다. 기존에 sticky session을 강제하던 로드밸런서 설정, 세션 어피니티 룰, 세션 공유 스토어가 모두 불필요해진다.

상태는 핸들로 명시된다

"세션이 없으면 도구 결과를 어떻게 이어가나?"라는 질문이 자연스럽다.

답은 명시적 핸들이다. 서버가 도구 호출에 대해 핸들(식별자)을 반환하면, 클라이언트는 다음 요청에서 그 핸들을 파라미터로 첨부한다. 세션 ID가 프로토콜 레이어에 숨어 있던 것과 달리, 핸들은 모델이 볼 수 있는 도구 응답 안에 있다. 따라서 어느 서버 인스턴스든 핸들만 받으면 작업을 재개할 수 있다.

이것은 단순한 구현 변경이 아니다. 암묵적 상태를 명시적 상태로 바꾸는 설계 철학의 전환이다.

캐싱과 라우팅 헤더

tools/list, resources/list 같은 목록 응답에는 이제 ttlMs와 cacheScope 필드가 붙는다. HTTP의 Cache-Control을 본뜬 구조다. 클라이언트는 이 값을 읽어 도구 목록을 재요청할 시점을 결정할 수 있다. 도구 목록이 바뀌지 않는 서버라면 클라이언트는 매 요청마다 tools/list를 보낼 필요가 없다.

라우팅 헤더인 Mcp-Method와 Mcp-Name은 로드밸런서가 요청 바디를 파싱하지 않고도 라우팅 결정을 내릴 수 있게 한다. 이는 특히 HTTP POST body가 큰 경우에 의미 있다.

2. 사용자 입력 대기: SSE 없이 멀티라운드를 처리하는 방법

기존에 서버가 사용자 입력을 기다려야 할 때는 SSE(Server-Sent Events) 스트림을 유지해야 했다. 스트림이 열려 있는 동안 서버는 "대기 상태"였다. 이 구조는 세션 sticky와 맞물려 서버 자원을 잡아먹는 원인이 됐다.

2026-07-28 RC는 InputRequiredResult 타입으로 이를 해결한다.

서버는 사용자 입력이 필요한 시점에 SSE 스트림을 유지하는 대신, InputRequiredResult를 반환한다. 여기에는 클라이언트에게 보여줄 프롬프트, 작업 재개에 필요한 페이로드, 재시도 가능한 요청 구조가 포함된다. 클라이언트가 사용자 답변을 받으면, 그 페이로드를 그대로 다음 요청에 담아 보낸다. 이 요청은 어느 서버 인스턴스도 처리할 수 있다.

결과적으로 서버는 "대기" 상태를 가질 필요가 없다. 모든 요청은 독립적이고, 상태는 클라이언트가 들고 있다가 다음 요청에 넘긴다. 이것이 바로 상태 없는 멀티라운드다.

3. Extensions 프레임워크: Tasks와 MCP Apps

Tasks가 실험적 core에서 공식 확장으로 이동한 이유

2025-11-25 스펙에서 Tasks는 실험적 core feature였다. 문제는 Tasks의 설계가 세션 기반 구조에 의존했다는 점이다. 세션이 사라지면서 Tasks 전체가 재설계 대상이 됐다.

2026-07-28 RC에서 Tasks는 핸들 기반 확장으로 다시 태어난다.

• 서버는 tools/call에 대해 작업 핸들을 반환한다.
• 클라이언트는 tasks/get으로 진행 상황을 조회한다.
• tasks/update로 중간 상태를 갱신할 수 있다.
• tasks/cancel로 취소 요청을 보낸다.
• tasks/list는 세션 없이 범위를 특정하기 어렵다는 이유로 제거됐다.

핸들이 자기 완결적이므로, 장기 실행 작업을 어떤 서버 인스턴스도 이어받을 수 있다.

MCP Apps: 도구가 UI를 반환한다

MCP Apps는 서버가 도구 호출 결과로 인터랙티브 HTML 템플릿을 반환할 수 있게 하는 확장이다. 호스트는 이 템플릿을 샌드박스 iframe 안에서 렌더링하고, UI 내 사용자 행동(클릭, 입력)은 동일한 JSON-RPC 채널로 라우팅된다.

이로써 도구가 "텍스트 응답"만이 아니라, 폼·버튼·데이터 뷰 같은 가벼운 UI를 포함한 결과를 돌려줄 수 있게 된다. 보안 측면에서 호스트는 템플릿을 prefetch해 실행 전에 검토할 수 있다.

Extensions 거버넌스

확장은 역방향 DNS 식별자(예: io.modelcontextprotocol.tasks)를 사용하고, core 스펙과 독립적으로 버전 관리된다. 각 확장은 전용 ext-* 저장소에서 독립 관리자가 운영한다. 표준 트랙 SEP(Specification Enhancement Proposal)이 실험적 → 공식 단계를 거치려면 conformance suite에 테스트 시나리오가 먼저 포함돼야 한다.

4. 인증 강화: OAuth 2.1 자원 서버로서의 MCP

RFC 9207 iss 파라미터 검증

가장 중요한 인증 변화는 iss 파라미터 검증 요구다. RFC 9207은 OAuth 2.0 믹스업 공격을 방지하기 위해 클라이언트가 응답의 iss 파라미터를 검증해야 한다고 규정한다. 믹스업 공격은 공격자가 정상 인가 서버처럼 행동해 토큰을 가로채는 방식이다.

MCP 클라이언트가 이제 이 검증을 수행해야 한다는 것은, MCP가 단순한 도구 프레임워크를 넘어 보안 경계를 명확히 다루는 프로토콜로 성숙했다는 신호다.

Dynamic Client Registration에서 application_type 필수

클라이언트는 DCR(Dynamic Client Registration) 시 application_type을 선언해야 한다. 이는 클라이언트가 웹 애플리케이션인지, 네이티브 앱인지, 백엔드 서비스인지를 인가 서버가 알 수 있게 한다. 타입에 따라 허용 redirect URI, 토큰 발급 방식이 달라질 수 있다.

자격증명 발급자 바인딩과 스텝업 인증

자격증명이 발급된 인가 서버의 issuer에 바인딩되면, 다른 AS에서 발급된 토큰을 잘못 사용하는 경우를 막을 수 있다. 리프레시 토큰 요청 방식과 스텝업 인증 시 스코프 누적도 명시됐다. 사용자가 더 높은 권한을 요구하는 도구를 호출할 때 추가 인증을 요청하고, 기존 스코프에 더하는 방식이 표준화됐다.

5. Deprecation: 12개월 안에 세 가지를 대체해야 한다

Roots → tool 파라미터 또는 resource URI

Roots는 클라이언트가 허용하는 파일시스템 경로를 서버에 알리는 기능이었다. 상태 없는 세계에서 이 정보는 세션 컨텍스트가 아닌, 도구 파라미터나 리소스 URI로 전달하는 편이 더 명확하다. 서버가 roots/list를 통해 파악하던 것을 이제 도구 입력 스키마에 명시적으로 선언하면 된다.

Sampling → LLM provider API 직접 통합

Sampling은 MCP 서버가 클라이언트를 통해 모델을 호출하는 역방향 흐름이었다. 이 패턴은 설계상 복잡하고, 어떤 모델을 어떤 파라미터로 부르는지가 프로토콜에 묶여 있었다. 대체 방향은 간단하다. 서버가 LLM을 호출해야 한다면, Anthropic API나 OpenAI API를 직접 통합하라.

Logging → stderr 또는 OpenTelemetry

MCP를 통한 로그 전달은 프로토콜의 의무가 돼선 안 된다는 판단이다. stdio transport에서는 stderr로 로그를 내보내면 된다. 구조화 관측이 필요하다면 OpenTelemetry가 더 적합한 표준이다. W3C Trace Context 전파가 이번 스펙에 포함된 이유이기도 하다.

6. W3C Trace Context와 분산 추적

이번 RC에서 의미 있는 조용한 변화가 하나 있다. _meta 필드에 W3C Trace Context 전파를 표준화한 것이다.

표준 키 이름으로 traceparent와 tracestate가 _meta에 포함되면, OpenTelemetry를 이미 쓰는 조직에서는 MCP 호출이 자연스럽게 기존 추적 파이프라인에 이어진다. 호스트 → SDK → MCP 서버 → 다운스트림 서비스까지 단일 트레이스 ID로 연결할 수 있게 된다.

에이전트 루프에서 무슨 도구 호출이 얼마나 걸렸는지, 어떤 서버 인스턴스에서 처리됐는지를 기존 APM 대시보드에서 볼 수 있다는 뜻이다. 이것은 프로덕션 에이전트 시스템 운영에서 매우 실용적인 이득이다.

7. 마이그레이션 체크리스트

서버 개발자

• initialize/initialized 핸드셰이크 코드를 제거하고 server/discover로 대체한다.
• Mcp-Session-Id 헤더 처리 로직을 제거한다.
• 세션에 의존하던 상태를 핸들 기반 명시적 상태로 변환한다.
• tools/list, resources/list 응답에 ttlMs와 cacheScope를 추가한다.
• 사용자 입력 대기가 필요한 흐름을 InputRequiredResult 패턴으로 재구성한다.
• 2025-11-25 실험적 Tasks API를 2026-07-28 핸들 기반 Tasks 확장으로 마이그레이션한다.
• 누락 리소스 에러코드를 -32002에서 -32602로 변경한다.
• Logging에 MCP 채널을 사용 중이면 stderr 또는 OTel 출력으로 전환 계획을 수립한다.
• Roots를 사용 중이면 tool 파라미터나 resource URI로 대체 방안을 설계한다.
• Sampling을 사용 중이면 LLM provider 직접 호출로 전환 방안을 검토한다.

인프라 운영자

• sticky session 설정을 제거하고 라운드로빈 로드밸런서로 전환한다.
• Mcp-Method, Mcp-Name 헤더 기반 라우팅 정책을 검토한다.
• 세션 공유 스토어(Redis 등)가 MCP 세션 전용이었다면 제거 가능 여부를 확인한다.
• IDP에서 application_type 포함 DCR 흐름을 지원하는지 확인한다.
• iss 파라미터 검증이 클라이언트 SDK에서 수행되는지 확인한다.

타임라인

• 2026-05-21: RC 확정
• 2026-07-28: 최종 스펙 발행
• v1 서버는 계속 동작한다. Deprecation 항목은 12개월 grace period가 있다.
• Tier 1 SDK(Python, TypeScript 등)는 이 10주 검증 기간 내 지원 출시가 기대된다.

마무리

MCP 2026-07-28 RC를 한 줄로 요약하면 이렇다. MCP 서버가 드디어 평범한 HTTP 서비스처럼 운영될 수 있게 됐다.

세션 제거는 sticky routing과 세션 스토어를 없애고, 수평 확장 비용을 낮춘다. InputRequiredResult는 서버가 SSE 스트림을 유지하지 않고도 사용자 입력을 기다릴 수 있게 한다. Tasks 확장은 핸들 기반으로 재설계돼 프로덕션에서 안전하게 쓸 수 있게 됐다. 인증 강화는 MCP를 OAuth 2.1 자원 서버 수준의 보안 경계로 끌어올렸다. 그리고 Extensions 프레임워크는 앞으로의 기능 추가가 core 스펙을 흔들지 않고 이뤄질 수 있는 구조를 제공한다.

Roots·Sampling·Logging의 deprecation은 당장 서비스를 멈추는 신호가 아니다. 12개월의 여유가 있고, 대체 경로도 명확하다. 하지만 설계를 다시 생각할 기회이기도 하다. 특히 Sampling이 의존하는 역방향 모델 호출 패턴은, 에이전트 아키텍처에서 클라이언트와 서버의 역할을 재정의할 만한 변화다.

References

• MCP 공식 블로그, "The 2026-07-28 MCP Specification Release Candidate" (2026): https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/
• MCP 공식 블로그, "Beta SDKs for the 2026-07-28 MCP Spec Release Candidate Are Here": https://blog.modelcontextprotocol.io/posts/sdk-betas-2026-07-28/
• AAIF 블로그, "MCP 2026-07-28: From Local Tool to Distributed Protocol": https://aaif.io/blog/mcp-2026-07-28-whats-changing-and-how-to-migrate
• WorkOS 블로그, "The biggest MCP spec update ships July 28: What changes for AI agent authentication": https://workos.com/blog/mcp-2026-spec-agent-authentication
• 4sysops, "2026-07-28 Model Context Protocol (MCP): stateless, multi-round-trip, routable headers, authorization hardening": https://4sysops.com/archives/2026-07-28-model-context-protocol-mcp-stateless-multi-round-trip-routable-headers-authorization-hardening/
• TokenMix Blog, "MCP Protocol Updates 2026: 9 Spec Changes, RC Migration Map": https://tokenmix.ai/blog/mcp-updates-changelog-every-protocol-change-2026
• RFC 9207, "OAuth 2.0 Authorization Server Issuer Identification" (IETF, 2022): https://www.rfc-editor.org/rfc/rfc9207