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

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

어디가 스테이트풀(Stateful)했는가 🔌

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

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

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

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

순수 HTTP 인프라에 그대로 올라탄다

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

트랜스포트(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) 공격이 통하기 쉬우므로 타당한 보강이다.

이전 버전과의 마이그레이션도 고려되어 있다. 신구 버전이 혼재되어도 망가지지 않는다.

2026-07-28 버전을 사용하는 클라이언트는 2025-11-25 또는 그 이전 버전의 서버를 만났을 때 initialize 핸드셰이크로 폴백(Fall back)하므로, 오래된 서버와 새로운 클라이언트가 계속 상호 운용될 수 있다.

새로운 클라이언트는 오래된 서버를 만나면 기존의 initialize...

핸드셰이크 (Handshake)로 자동으로 폴백 (Fallback)한다. 반대로 v2 서버는 하나의 엔드포인트에서 신구 버전 리비전(Revision) 모두에 응답할 수 있다. 단계적 이행을 위한 퇴로가 마련되어 있다.

직접 사용해보기

베타 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 확장이 추가된다. 본체를 가벼운 스테이트리스 코어로 유지하면서 무거운 기능은 확장으로 분리하는 설계 판단이며, 방향성 측면에서 매우 합리적이다.

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

Discussion