MCP 프로토콜 stateless 전환 대응법과 마이그레이션 체크리스트

MCP 프로토콜이 2026년 7월 28일자 스펙에서 stateless 기본값으로 전환되며 세션 핸드셰이크가 사라졌다. SDK별 대응 방식과 마이그레이션 단계, 자주 놓치는 부분을 정리했다.

MCP프로토콜stateless전환 시작 전 확인할 것

MCP(Model Context Protocol)는 2026년 7월 28일자 스펙에서 ·notifications/initialized 핸드셰이크와 Mcp-Session-Id 헤더를 Streamable HTTP 전송에서 제거하고 프로토콜을 stateless 기본값으로 전환했다. 이 변경은 2025년 6월 18일 제안된 SEP-2575(“Make MCP Stateless”)가 최종(Final) 상태로 확정되면서 반영됐으며, 2026년 5월 21일 Release Candidate가 락(lock)된 뒤 10주간의 SDK·클라이언트 검증 기간을 거쳐 최종 공개됐다.

이 글은 자체적으로 MCP 서버·클라이언트를 구현·운영 중인 개발자가 무엇을 점검하고 어떤 순서로 대응해야 하는지를 다룬다. Claude 앱을 단순 사용하는 입장이라면 체감할 변화는 거의 없다 — Anthropic 공식 블로그는 Claude 제품 전반에 “순차 롤아웃 예정”이라고만 밝혔을 뿐 정확한 완전 적용 시점은 확인되지 않는다. 반면 Anthropic의 David Soria Parra는 The Register(2026-07-23) 인터뷰에서 “자체 MCP 엔진을 직접 구축한 경우 이를 올바르게 고치려면 상당한 작업이 필요할 것”이라고 밝혀, 발표의 “단순화” 프레이밍과 별개로 실제 이행 부담이 작지 않음을 시인했다.

준비물·필요 서류

마이그레이션 착수 전에 아래 항목을 먼저 표로 정리해두면 작업 범위를 가늠하기 쉽다.

server/discover는 이번에 신설된 필수 RPC로, 핸드셰이크 없이 프로토콜 버전과 기능을 조회할 수 있게 해준다. 반대로 resources/subscribe/, HTTP GET SSE 엔드포인트는 폐지되고 subscriptions/listen 단일 RPC로 통합됐으며, ·logging/setLevel·notifications/roots/list_changed는 양방향 모두에서 제거됐다. 새로 정의된 에러 코드는 UnsupportedProtocolVersion(-32022), MissingRequiredClientCapability(-32021) 두 가지이며, 이 코드가 뜬다면 클라이언트·서버 중 어느 쪽이 신규 스펙을 따르지 않는지부터 확인하면 된다.

용어 풀이
1. 핸드셰이크(handshake) — 통신 시작 전 양쪽이 서로의 상태·버전을 확인하는 절차. 이번 개편으로 MCP에서는 생략됐다.
2. Streamable HTTP — MCP가 요청·응답을 스트리밍으로 주고받는 전송 방식으로, 이번 개편의 대상이 된 전송 계층이다.

단계별 진행 순서

1단계 — 현재 SDK와 프로토콜 버전 확인 (소요시간 10~20분)
사용 중인 SDK 종류와 버전을 먼저 파악한다. Python·C#은 v2 업그레이드만으로 2025-11-25와 2026-07-28을 동시 지원하므로 부담이 적지만, TypeScript·Go는 명시적 설정을 하지 않으면 구버전 wire format이 그대로 유지된다는 점을 확인해야 한다. 이 단계에서 “지금 당장 손대야 하는지, 유예 기간 안에 있는지”가 갈린다.

2단계 — MCP-Protocol-Version 헤더 대응 점검 (소요시간 30분~1시간)
HTTP 전송을 쓰는 서버라면 이 헤더가 필수이며, 값이 클라이언트·서버 간 불일치하면 400 Bad Request로 요청 자체가 거부된다. 게이트웨이나 프록시를 앞단에 둔 구조라면 헤더가 중간에서 유실되지 않는지 별도로 확인해야 한다.

3단계 — deprecated 기능 사용처 전수 조사 (소요시간 1~2시간)
Roots·Sampling·Logging RPC를 호출하는 코드를 검색해 목록화한다. 최소 12개월 동작이 보장되므로 당장 서비스가 끊기지는 않지만, Roots는 tool parameter로, Sampling은 LLM 제공사 API 직접 연동으로, Logging은 stderr나 OpenTelemetry로 옮기는 대체 설계를 이 시점에 정해두는 편이 나중에 유리하다.

4단계 — 신버전 옵트인 설정 적용 (소요시간 반나절~1일)
TypeScript는 createMcpHandler, Go는 StreamableHTTPOptions.Stateless=true 같은 명시적 옵션을 켜야 stateless 방식으로 전환된다. 이 작업은 배포 파이프라인과 함께 스테이징 환경에서 먼저 검증하는 것이 안전하다.

5단계 — 버전 혼합 환경 테스트 (소요시간 1일 내외)
구버전 클라이언트와 신버전 서버를 함께 운영해야 하는 경우, AWS AgentCore Gateway의 실측 결과처럼 도구 호출은 되지만 엘리시테이션·샘플링 관련 상호작용은 지원되지 않는 조합이 나올 수 있다. 이 단계에서 실제 시나리오를 재현해 어떤 기능이 깨지는지 미리 확인해둔다.

6단계 — 프로덕션 배포와 모니터링
server/discover 응답과 에러 코드(-32022, -32021) 발생률을 배포 후 며칠간 모니터링해 버전 불일치로 인한 요청 실패가 남아있지 않은지 확인한다.

자주 놓치는 부분

공식 발표의 “단순화”라는 표현을 실제 이행 난이도와 동일시하는 태도가 가장 흔한 착오다. SEP-2575 자체 FAQ는 “완전히 stateless는 아니다(hence ‘by default’)”라고 명시하고 있어, SSE 스트림 내부에는 여전히 다중 요청 맥락이 남아 있을 수 있다. “이제 세션 관리를 아예 신경 쓰지 않아도 된다”는 식으로 넘겨짚으면 실제 구현에서 어긋난다.

두 번째로 자주 놓치는 지점은 SDK별 하위호환 방식 차이다. Python·C#만 써본 팀이 TypeScript·Go 서버에도 동일하게 “그냥 업그레이드하면 자동 적용된다”고 가정하는 경우가 있는데, 이 두 언어는 명시적 옵트인 설정 전까지 기존 wire format을 그대로 유지한다. 반대로 이 사실을 모르고 옵트인 설정을 켜지 않은 채 신규 클라이언트와 연결하면 원인 파악이 어려운 호출 실패가 발생할 수 있다.

세 번째는 버전 혼합 환경의 기능 제약이다. “구버전 클라이언트도 신버전 서버의 도구를 호출할 수 있다”는 설명만 보고 완전한 상호운용을 기대하면 곤란하다. 실제로는 엘리시테이션·샘플링처럼 상호작용이 필요한 기능에서 막힌다는 사실이 AWS 실측(2026-07-28 기준)에서 확인됐다. 게이트웨이 단에서 버전별로 지원 기능을 분기하는 설계를 미리 넣어둬야 한다.

마지막으로, Claude 제품 자체의 지원 시점을 스펙 공개일과 동일시하지 않아야 한다. 2026년 7월 28일 발표와 함께 “가능해진 것”처럼 보이지만 실제로는 “순차 롤아웃 예정”이라는 표현뿐이었고, 정확한 전체 제품군 GA 일정은 이 글 작성 시점(2026-09-03 기준)까지 공식 문서로 재확인되지 않는다. 이 부분은 확인 필요 상태로 남겨둔다.

체크리스트 정리

• 사용 중인 SDK가 TypeScript·Go(명시적 옵트인 필요)인지, Python·C#(자동 이중 지원)인지 구분했는가
• MCP-Protocol-Version 헤더가 게이트웨이·프록시를 통과하며 유실되지 않는지 확인했는가
• Roots·Sampling·Logging RPC 사용처를 전수 조사하고 12개월 유예 기간 내 대체 설계를 정했는가
• 구버전 클라이언트-신버전 서버 혼합 환경에서 엘리시테이션·샘플링 기능 제약을 테스트했는가
• server/discover, 에러 코드(-32022, -32021) 응답을 배포 후 모니터링할 준비를 했는가
• SSE Last-Event-ID 재개 로직에 의존하던 코드가 있다면 새 요청 ID 재발급 방식으로 교체했는가
• Claude 제품군의 실제 지원 시점은 아직 공식 확정치가 없다는 점을 감안해 일정을 여유 있게 잡았는가

참고 자료

조사 기준일: 2026년 09월 02일

본문의 수치는 아래 자료에서 확인한 것입니다. 제조사 공식 자료(T1)와 전문 매체 실측(T2)을 구분해 표기했습니다. 가격·공급 상황은 변동이 크므로 기준일 이후의 값은 다시 확인해야 합니다.

Tier 1
– MCP 공식 블로그, “The 2026-07-28 Specification” — https://blog.modelcontextprotocol.io/posts/2026-07-28/ (확인일 2026-09-02)
– MCP 공식 블로그, “The 2026-07-28 MCP Specification Release Candidate” — https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/ (확인일 2026-09-02)
– MCP 공식 블로그, “Beta SDKs for the 2026-07-28 MCP Spec Release Candidate Are Here” — https://blog.modelcontextprotocol.io/posts/sdk-betas-2026-07-28/ (확인일 2026-09-02)
– MCP 공식 사양, SEP-2575 “Make MCP Stateless” — https://modelcontextprotocol.io/seps/2575-stateless-mcp (확인일 2026-09-02)
– MCP 공식 사양, “Key Changes” changelog (2026-07-28) — https://modelcontextprotocol.io/specification/2026-07-28/changelog (확인일 2026-09-02)
– Claude(Anthropic) 공식 블로그, “MCP 2026-07-28 spec: stateless core, coming to Claude” — https://claude.com/blog/bringing-mcp-2026-07-28-to-claude (확인일 2026-09-02, 2026-07-28 게시)
Tier 2
– The Register, “Model Context Protocol prepares to break with its stateful past” (2026-07-23) — https://www.theregister.com/devops/2026/07/23/model-context-protocol-prepares-to-break-with-its-stateful-past/5276722
– InfoQ, “MCP Goes Stateless, and Developers Ask Whether That Just Makes it an API Again” (2026-08-12 확인) — https://www.infoq.com/news/2026/08/mcp-stateless-gateway/
– Simon Willison 블로그, “Stateless MCP has recaptured my interest” (2026-07-31) — https://simonwillison.net/2026/Jul/31/stateless-mcp/
– AWS 머신러닝 블로그, “How AgentCore Gateway supports the MCP 2026-07-28 spec” (2026-07-28) — https://aws.amazon.com/blogs/machine-learning/how-agentcore-gateway-supports-the-mcp-2026-07-28-spec/
– Cloudflare 공식 블로그, “The next generation of MCP” (2026-07-27) — https://blog.cloudflare.com/mcp-v2/