MCP가 세션 ID를 버리고 스테이트리스(Stateless)로 변경되는 2026-07-28 사양

원격 MCP 서버를 2대 이상 배치하는 순간 함정에 빠지기 쉽다. 첫 번째 서버가 발행한 세션 ID를 로드 밸런서의 변덕에 따라 분산된 두 번째 서버가 알지 못한다는 문제이다. 이를 피하기 위해 모두들 Sticky Session을 적용하거나, 공유 세션 스토어를 연결하거나, 게이트웨이에서 요청 본문(request body)을 들여다보고 분배해 왔다. 원래 HTTP 세계를 이미 졸업했어야 할 고생을 AI 에이전트 분야가 2년 동안 다시 한번 반복하고 있었다.

오늘 공개된 Model Context Protocol의 2026-07-28 사양이 이 전제를 통째로 버렸다. MCP(LLM에 외부 도구나 데이터를 연결하기 위한 표준 프로토콜. Anthropic이 주도함)에게 있어, 출시 이후 가장 큰 개정이며 파괴적인 변경을 포함한다. 핵심은 한마디로 말할 수 있다. 프로토콜에서 '세션'이라는 개념을 제거했다.

무엇이 사라졌는가

기존 MCP는 클라이언트가 먼저 initialize를 보내고, 서버가 Mcp-Session-Id 헤더를 반환하는 핸드셰이크로 시작했다. 이후의 요청들은 이 세션 ID를 가지고 돌아다니며 사실상 '이 서버 인스턴스에 고정'되었다. TechCrunch 취재에서 에이전트 기반 스타트업 Arcade의 Nate Barbettini 씨는 이 구조의 문제점을 정확히 지적했다.

서버 팜(Server Farm)의 각 머신들이, 다른 머신이 배정한 세션 ID를 전부 알고 있어야 하게 된다.

2026-07-28 버전은 이 initialize/initialized 핸드셰이크와 Mcp-Session-Id 헤더를 모두 삭제했다(SEP-2567). 모든 요청이 자립적으로 완성된다. 대신 Streamable HTTP 요청에는 새로운 헤더가 필수화되었다.

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
...

Mcp-Method와 Mcp-Name이 있기 때문에, 게이트웨이나 레이트 리미터는 내용(JSON 본문)을 열어보지 않고 헤더만으로 '어떤 도구의 어떤 작업인지'를 판단하여 분배할 수 있다. 디프 패킷 인스펙션(Deep Packet Inspection)이 필요 없다. 사양 제정을 주도한 David Soria Parra 씨는 독립 미디어 The Register에 설계 철학을

를 있는 그대로 가져와서, 클라이언트는 '이 도구 목록이 몇 밀리초까지 최신인지', '사용자 간에 공유해도 되는지'를 명시적으로 알 수 있다. 결과적으로 스티키 라우팅(Sticky Routing)도 공유 세션 저장소도 필요 없어지고, 그저 라운드 로빈 로드 밸런서 뒤에서 MCP 서버를 돌릴 수 있게 된다. 운영 비용 측면에서 은근히 효과적이다.

사라지는 것, 격하되는 것

파괴적이라고는 해도, 갑자기 작동하지 않는 것은 아니다. SEP-2577에서 3가지 기능이 사용 중단(deprecated)되었지만, 적어도 앞으로 1년 동안은 작동한다.

(장시간 비동기 처리)는 코어에서 Extension으로 옮겨졌고, tools/call이 태스크 핸들(task handle)을 반환하여 tasks/get, tasks/update, tasks/cancel로 구동되는 형태로 바뀌었다. tasks/list는 삭제되었다. 세션이 없으면 안전하게 스코프를 끊을 수 없다는 이유가 명확히 적혀 있다. 이 '세션을 제거했으니, 세션 전제 API도 정리한다'라는 일관성은 호감이 간다.

새로 도입된 Extensions 프레임워크는 역방향 DNS 형식의 ID를 가지며, extensions 맵에서 능력을 협상(negotiate)한다. 첫 번째 공식 Extension은 서버 측에서 UI를 그리는 MCP Apps(SEP-1865)이다. 게다가 도구 스키마가 JSON Schema 2020-12에 대응하게 되었고, 리소스 부재 오류가 자체적인 -32002에서 JSON-RPC 표준의 -32602로 바뀌었다. 사소하지만 기존 클라이언트의 에러 핸들링을 망가뜨릴 수 있으니 주의해야 한다.

마이그레이션은 쉽지 않다

열광적인 부분만 전달해서는 성실하지 못하다. Parra 씨 자신도 독자 구현 세력에게 '제대로 고치는 것은 상당한 노력이 될 것'이라고 인정했다. Stacklok은 하위 호환성이 보장되지 않는다고 경고하고 있으며, 2026-07-28 버전의 서버가 오래된 클라이언트와 작동하지 않을 가능성이 있어 폴백(fallback)이나 변환 계층을 자체적으로 준비할 필요가 생긴다. 사양 일정을 보면, 출시 후보는 5월 21일에 확정되고, 10주간의 검증 기간을 거쳐 오늘 7월 28일이 최종판이라는 흐름이다.

반대로 생각하면, 이번 고통은 한 번으로 끝내는 설계가 되어 있다. 사용 중단은 최소 12개월, 그 사이에는 계속 작동한다는 공식 정책이 들어갔고, 표준화 트랙의 SEP는 적합성 스위트(conformance suite)에 대응 시나리오가 포함될 때까지 Final이 될 수 없게 되었다. 사양 측에서는 '2026-07-28을 구현해 놓으면, 향후 개정은 전송 계층이나 라이프사이클 코드를 다시 쓸 필요 없이 따라갈 수 있을 것'이라고 말하고 있다.

REST API가 십여 년 전에 배운 '스테이트리스(Stateless)하게 하면 수평 확장 가능하다'는 교훈을 에이전트의 도구 계층이 지금 재경험하고 있다. 그 정도 이야기라고 할 수 있지만, 악수와 세션 ID라는 두 개의 작은 메커니즘만 제거하는 것만으로도 MCP 서버의 운영이 Kubernetes 사용자가 기대하는 일반적인 클라우드 네이티브한 형태로 가까워진다. 만약 당신이 원격 MCP 서버를 운영하고 있다면, 먼저 자신의 도구가 암묵적으로 세션 상태에 의존하고 있지 않은지 파악하고, 의존하고 있다면 핸들(handle)을 반환하는 설계로 다시 작성하는 것이 첫걸음이 될 것이다.

Discussion