KEY POINT

- MCP 2026-07-28 사양은 세션 기반 구조를 제거하고 상태 비저장(Stateless) 프로토콜로 전환하여 일반 HTTP 인프라에서의 수평 확장을 가능하게 했다.

- `Mcp-Method` 및 `Mcp-Name` 헤더와 `_meta` 파라미터를 도입해 핸드셰이크 없이 HTTP 계층에서 라우팅, 캐싱, 분산 추적이 가능하도록 최적화했다.

- 운영자는 `UpdateGateway`로 버전을 활성화하고, HTTP 400 에러 코드(-32022, -32020)를 통해 버전 호환성과 헤더 바인딩 정합성을 검증하여 스티키 세션 없는 확장 여부를 결정해야 한다.

#MCP #AmazonBedrock #상태비저장 #인프라확장성 #AgentCore

MCP 2026-07-28 사양 공개와 상태 비저장 전환

MCP(Model Context Protocol)가 2026-07-28 사양을 공개하며 출시 이후 가장 큰 규모의 프로토콜 개정을 단행했다. MCP는 이번 릴리스를 통해 상태 비저장(Stateless) 프로토콜로 전환되었으며, 이를 통해 일반적인 HTTP 인프라 위에서 시스템 확장이 가능해졌다. 프로토콜 유지 관리 팀은 기업급 배포에서 발생하는 확장성 문제를 해결하기 위해 기존의 세션 기반 구조를 제거하는 근본적인 변경을 수행했다.

유지 관리 팀은 하위 호환성이 파괴되는 변경 사항을 보완하기 위해 새로운 거버넌스 체계를 도입했다. 이들은 기능 생명주기 정책(Feature lifecycle policy), 확장 프레임워크(Extensions framework), 적합성 테스트 세트(Conformance-suite) 요구사항을 설정하여 핵심 기능의 파괴 없이 프로토콜이 진화할 수 있는 경로를 마련했다. 또한 MCP는 권한 부여 체계를 OAuth 2.0 및 OpenID Connect와 밀접하게 정렬하여 기업의 보안 관행에 맞게 강화했다.

이번 업데이트는 옵트인(Opt-in) 방식으로 제공된다. 클라이언트와 서버 양측이 모두 새로운 버전을 채택하기 전까지는 기존 동작이 유지되며, 특정 버전의 요청에 대해서만 새로운 동작이 적용되는 구조를 채택했다.

핸드셰이크 제거와 자립적 요청 구조의 구현

이전 버전의 MCP 서버는 Streamable HTTP 상호작용 시 `initialize`와 `initialized` 핸드셰이크 과정을 거쳐야 했다. 서버는 이 과정에서 `Mcp-Session-Id` 헤더를 발행했으며, 클라이언트는 이후 모든 요청에 이 ID를 포함해 특정 서버 인스턴스에 고정(Pinning)되어야 했다. 이로 인해 운영자는 서버를 수평 확장하기 위해 로드 밸런서에서 스티키 세션(Sticky Session)을 설정하거나 별도의 공유 세션 저장소를 구축해야 하는 제약이 있었다.

2026-07-28 사양은 SEP-2575와 SEP-2567을 통해 핸드셰이크와 프로토콜 수준의 세션 요구사항을 완전히 제거했다. 이제 모든 요청은 `_meta` 파라미터 내에 프로토콜 버전, 클라이언트 정보, 클라이언트 기능(Capabilities)을 직접 포함하여 전송한다. 이를 통해 단일 도구 호출이 모든 컨텍스트를 포함하는 자립적 구조가 되었으며, 요청은 사전 세션 문맥 없이 어떤 서버 인스턴스로든 라우팅될 수 있다.

클라이언트는 서버가 지원하는 기능을 확인하기 위해 기존의 초기화 단계 대신 새로운 `server/discover` 메서드를 언제든지 호출할 수 있다. 상태 유지가 필요한 애플리케이션의 경우, 프로토콜 세션 대신 도구 파라미터에 명시적인 ID를 전달하고 에이전트의 기능을 통해 이 상태 핸들을 후속 요청에 전달하는 패턴을 사용한다.

표준 HTTP 인프라 최적화 및 분산 추적

MCP는 표준 HTTP 인프라와의 호환성을 높이기 위해 세 가지 기술적 개선을 도입했다. 첫째, 모든 Streamable HTTP 요청은 `Mcp-Method`와 `Mcp-Name` 헤더(SEP-2243)를 통해 의도를 외부에 노출한다. 이를 통해 로드 밸런서나 API 게이트웨이는 JSON-RPC 바디를 파싱하지 않고도 HTTP 계층에서 즉시 라우팅, 스로틀링, 미터링을 수행할 수 있다. 서버는 선언된 헤더가 바디 내용과 충돌할 경우 해당 요청을 즉시 거부한다.

둘째, `list` 및 `resource-read` 작업의 응답에 `ttlMs`와 `cacheScope`라는 신선도 메타데이터를 추가했다(SEP-2549). 이는 HTTP Cache-Control의 시맨틱을 차용한 것으로, 클라이언트는 지속적인 SSE 연결을 유지하지 않고도 `tools/list` 응답을 정해진 기간과 범위 내에서 로컬에 캐싱할 수 있다.

셋째, `_meta` 파라미터 내에 W3C Trace Context 키인 `traceparent`, `tracestate`, `baggage`를 예약했다(SEP-414). 이를 통해 에이전트에서 MCP 클라이언트, 게이트웨이를 거쳐 다운스트림 서비스까지 이어지는 전체 호출 체인을 OpenTelemetry 호환 수집기에서 단일 스팬 트리(Unified span tree)로 시각화할 수 있다.

다중 왕복 요청을 통한 서버-클라이언트 상호작용

상태 비저장 프로토콜 환경에서 서버가 클라이언트에게 중간 입력을 요청하는 상호작용은 다중 왕복 요청(Multi Round-Trip Requests) 방식으로 변경되었다(SEP-2322). 이전의 장기 유지 SSE 스트림 방식은 연결 유지 비용이 높았으나, 새 방식은 서버가 처리 중인 상태를 외부에 저장하고 클라이언트에게 토큰을 전달하는 구조를 취한다.

서버는 사용자 입력이 필요한 경우(Elicitation), 파일 시스템 경로 요청(Roots), 모델 응답 생성 요청(Sampling) 시 `InputRequiredResult` 결과값과 함께 불투명 토큰인 `requestState`를 전달한다. 서버는 내부 메모리에 상태를 저장하지 않고 이 토큰에 상태 정보를 담아 전달함으로써 상태 비저장 구조를 유지한다.

클라이언트는 사용자의 답변과 전달받은 `requestState` 토큰을 포함해 원래의 호출을 다시 발행한다. 서버는 이 토큰을 통해 이전 맥락을 복원하여 작업을 이어간다. 이러한 구조는 특정 서버 인스턴스에 장애가 발생하더라도 페이로드에 상태 정보가 포함되어 있어 다른 인스턴스가 즉시 작업을 처리할 수 있게 하는 안전장치 역할을 한다.

AgentCore Gateway 적용 및 버전 검증 기준

사용자는 Amazon Bedrock AgentCore의 `UpdateGateway`를 호출하여 지원할 버전 리스트를 지정함으로써 최신 프로토콜을 활성화할 수 있다.

bash
UpdateGateway --supported-versions "2025-11-25,2026-07-28"

AgentCore Gateway는 `Mcp-Protocol-Version` 헤더를 통해 요청 버전을 식별한다. 게이트웨이는 요청된 버전이 `supportedVersions` 설정에 포함되어 있으면 해당 버전으로 처리하며, 포함되지 않은 경우 HTTP 400 응답과 함께 에러 코드 `-32022` 및 지원 버전 리스트를 반환한다. 헤더가 누락된 요청은 기본값인 2025-03-26 버전으로 처리된다.

또한 2026-07-28 경로에서는 도구 입력 스키마의 특정 필드를 헤더 바인딩(Header-binding)으로 지정할 수 있다. 게이트웨이는 필수 헤더가 누락되었거나 헤더 값이 바디 내용과 충돌하는 경우 HTTP 400 응답과 에러 코드 `-32020`을 반환하며 요청을 거부한다. 게이트웨이는 모든 도구 결과에 구조화된 결과 엔벨로프를 적용하며, 캐시 가능한 결과에는 TTL과 스코프 힌트를 포함해 SDK 수준의 캐싱을 지원한다.

결과적으로 엔지니어는 `UpdateGateway`를 통해 버전 호환성을 확보하고, HTTP 400 에러 코드(-32022, -32020)를 기반으로 버전 및 헤더 정합성을 검증하는 체계를 구축함으로써, 스티키 세션이나 공유 세션 저장소 없이 MCP 서버를 수평 확장할 수 있는 판단 기준을 얻는다.