리모트 MCP 서버를 레플리카 3대로 늘리자마자 요청이 가끔 실패하기 시작한다. 짐작 가는 사람이 많을 것이다. 원인은 대개 같다. 처음 initialize로 맺은 상태가 특정 인스턴스에만 남아있고, 로드 밸런서(Load Balancer)가 다른 인스턴스로 요청을 보내면 "그런 세션은 모른다"며 거부되는 것이다. 그래서 결국 스티키 세션(Sticky Session)을 설정하거나, Redis 같은 곳에 공유 세션 저장소를 구축해 해결하곤 한다. 이 번거로움이 MCP의 차기 사양에서 완전히 사라진다.

Model Context Protocol(LLM에 외부 도구나 데이터를 연결하기 위한 표준 프로토콜)은 2026년 7월 28일에 공개 예정인 신규 리비전 2026-07-28에서 프로토콜의 코어를 스테이트리스(Stateless)하게 다시 설계한다. 릴리스 후보(RC)는 5월 21일에 확정되었으며, 6월 29일에는 주요 4개 언어의 베타 SDK도 출시되었다. 방침을 한마디로 말하자면, 연결에 종속된 상태(State)를 전부 없애는 것이다.

지금까지의 MCP는 클라이언트가 먼저 initialize를 던지면 서버가 Mcp-Session-Id 헤더를 발행하고, 이후의 요청은 해당 세션 ID를 들고 다니는 연결 지향적 설계였다. HTTP 위에서 동작하지만, 실질적으로는 스테이트풀(Stateful)한 커넥션이며 수평 확장(Horizontal Scale)과 상성이 좋지 않다. 어떤 인스턴스가 어떤 세션을 가지고 있는지 신경 써야 한다는 시점에서, 순수 HTTP의 장점이 절반은 죽어 있는 셈이다.

신규 사양은 이 핸드셰이크(Handshake)를 통째로 삭제한다. Mcp-Session-Id도 없어진다. 대신 프로토콜 버전, 클라이언트 정보, 기능(Capability)을 매 요청의 _meta에 실어서 보낸다. 개념을 나타내면 다음과 같은 형태다.

{
"method": "tools/call",
"params": { "name": "search", "arguments": { "q": "mcp" } },
...

서버 측의 능력은 신설된 server/discover 메서드를 통해 필요할 때 가져온다. 결과적으로 모든 요청은 단독으로 자기 완결적이며, 어떤 인스턴스에 도달하더라도 처리가 가능하다. "세션을 어디에 둘 것인가"라는 질문 자체가 사라지는 것이 이번 변경의 본질이다.

변경 사항을 현행 사양과 비교하면 이해하기 쉽다.

2025-11-25 (현행)	2026-07-28 (신규)
세션	Mcp-Session-Id를 발행	폐지
초기화	initialize / initialized	폐지. _meta로 매번 전송
능력 취득	initialize의 응답	server/discover
수평 확장	스티키(Sticky) 필수	라운드 로빈(Round Robin) 가능

트랜스포트(Transport) 계층도 수정되었다. Streamable HTTP의 POST에는 Mcp-Method와 Mcp-Name 헤더가 필수(SEP-2243)가 되어, 게이트웨이는 요청 본문(Request Body)을 들여다보지 않고도 이 헤더만으로 라우팅이나 속도 제한(Rate Limit)을 걸 수 있다. 목록·읽기 계열(tools/list 등)의 응답에는 신선도 힌트인 ttlMs와 cacheScope (public / private)가 붙어, 클라이언트 측에서 캐싱하여 폴링(Polling)을 줄일 수 있다. 인가(Authorization) 관련 부분도 OAuth 2.0 / OpenID Connect의 실제 운영 방식에 맞춰 강화되었으며, 인가 응답의 iss 검증(RFC 9207 준수)이 필수화되었다. 단일 클라이언트가 다수의 서버에 연결하는 MCP 구조에서는 이러한 종류의 믹스업(Mix-up) 공격이 먹히기 쉬우므로 타당한 보강이다.

이전 단계로의 전환(Migration)도 고려되어 있다. 신구 버전이 혼재되어도 망가지지 않는다.

Clients that speak 2026-07-28 fall back to the initialize handshake when they reach a server on 2025-11-25 or earlier, so old servers and new clients keep interoperating.

새로운 클라이언트는 오래된 서버를 만나면 기존의 initialize 핸드셰이크로 자동 폴백(Fallback)한다. 반대로 v2 서버는 하나의 엔드포인트에서 신구 버전 리비전 모두에 응답할 수 있다. 단계적 전환을 위한 퇴로가 마련되어 있다.

베타 SDK는 Python, TypeScript, Go, C#의 4종이다. Python의 경우 현재의 안정 버전을 깨뜨리지 않고 테스트할 수 있다.

uv add "mcp[cli]==2.0.0b1"
# 또는
pip install "mcp[cli]==2.0.0b1"

TypeScript는 패키지가 분할되어 @modelcontextprotocol/server@beta와 @modelcontextprotocol/client@beta를 설치하는 방식이 되었다. Go는 go get github.com/modelcontextprotocol/go-sdk@v1.7.0-pre.1, C#은 dotnet add package ModelContextProtocol --prerelease를 사용한다. SDK의 상세 내용과 피드백 방법은 공식 공지에 정리되어 있다.

스테이트리스(Stateless)화와 동시에 Roots, Sampling, Logging 및 기존의 HTTP+SSE 트랜스포트(Transport)가 비권장(Deprecated) 상태로 전환된다. 여기서 새롭게 도입된 기능 라이프사이클(Active → Deprecated → Removed, 비권장에서 삭제까지 최소 12개월)이 적용된다. 즉시 작동이 중단되는 것은 아니지만, Sampling을 통해 서버에서 클라이언트 측의 LLM을 다시 호출하는 구현 등은 조만간 재작성이 필요하다. 참고로 참조하는 SEP 번호는 해설 기사마다 차이가 있으므로(세션 삭제와 핸드셰이크 폐지를 별도의 SEP로 할당하는 기술도 있음), 번호는 최종 사양에서 확인하는 것이 좋다.

동일한 리비전에서는 확장 메커니즘도 도입되어, 대화 UI를 샌드박스화된 iframe으로 반환하는 MCP Apps나, tools/call이 태스크 핸들(Task Handle)을 반환하고 tasks/get 등으로 장시간 처리를 수행하는 Tasks 확장이 추가된다. 본체를 가벼운 스테이트리스 코어로 유지하면서 무거운 기능은 확장(Extension)으로 분리하는 설계 결정이며, 방향성은 매우 합리적이다.

흥미로운 점은, 서버에 상태를 유지하며 대화를 지속시키는 흐름이 LLM API 측에서 두드러지는 가운데, MCP는 오히려 그 반대로 방향을 틀었다는 것이다. 도구 연결 계층은 인프라에 가깝다. 그렇다면 '상태를 외부에 둔 스테이트리스 프로세스'에 가깝게 만드는 것이 CDN, 로드 밸런서(Load Balancer), 속도 제한(Rate Limiting)과 같은 기존의 HTTP 스택에 그대로 올라탈 수 있는 방법이다. 7월 28일의 확정을 기다리지 않더라도, 원격 서버를 운영 중인 사람이라면 베타 버전을 통해 자신의 배포 구성을 한 번 적용해 볼 가치가 있다. 스티키 세션(Sticky Session)을 제거할 수 있을지는 직접 만져보면 바로 알 수 있을 것이다.