MCP 세션 고정 제거, 에이전트 서버가 round-robin 위로 이동

에이전트 인프라의 병목이 프로토콜 쪽에서 크게 줄어든다. Google Developers Blog가 2026년 8월 5일 설명한 2026-07-28 Model Context Protocol specification release candidate는 transport-level session management를 제거한다. 로컬 도구 연결에는 괜찮았던 MCP의 세션 방식이, Kubernetes와 serverless 환경에서는 확장성 문제를 만들었기 때문이다.

이전 HTTP 기반 MCP에서는 초기화 과정 뒤 서버가 Mcp-Session-Id를 반환했고, 이후 요청은 그 세션을 기억하는 특정 컨테이너나 pod로 계속 가야 했다. 세 pod 뒤에 round-robin load balancer를 두면 두 번째 요청이 다른 pod로 가면서 400 Session Not Found가 날 수 있었다. 그래서 sticky session, Redis session store, gateway-level packet inspection 같은 우회가 필요했다.

새 규격의 핵심은 매 요청이 독립적으로 읽힌다는 점이다. 프로토콜 버전, 클라이언트 정보, capability가 한 번만 교환되는 대신, 각 요청의 _meta에 들어간다. initialize / initialized handshake와 논리적 Mcp-Session-Id header는 사라진다. Google은 이를 통해 일반 HTTP load-balanced infrastructure 위에서 MCP 서버를 수평 확장할 수 있다고 설명했다.

운영 관점의 변화도 구체적이다. 새 HTTP header는 Mcp-Protocol-Version, Mcp-Method, Mcp-Name을 담아 proxy와 gateway가 request body를 들여다보지 않고 routing, rate limit, audit을 처리하게 한다. Multi Round-Trip Requests는 도구 호출 중 사용자 확인이 필요한 상황을 오래 열린 SSE connection 없이 처리한다. 보안 쪽에서는 issuer verification, resource indicators, JSON Schema 2020-12 tool schema가 포함됐다.

개발자가 바로 확인할 지점은 SDK와 deprecation 일정이다. Google은 TypeScript, Python, Go, C#의 네 Tier-1 SDK가 2026-07-28 규격을 지원하는 beta release를 갖췄다고 밝혔다. GitHub MCP Server 같은 production server도 이미 새 규격으로 이동해 Redis session storage를 제거했다. 동시에 Roots, Sampling, Logging은 처음으로 공식 deprecation policy 아래 들어가며, 최소 12개월 전환 기간을 갖는다. MCP가 로컬 보조 연결에서 기업용 에이전트 인프라로 넘어가려면, 이번 stateless 전환이 실제 배포 기준이 될 가능성이 크다.