2026년 7월 28일, Model Context Protocol (MCP)은 출시 이후 가장 중요한 개정안을 발표했습니다. 이제 MCP는 무상태(stateless) 프로토콜입니다. 더 이상의 세션 핸드셰이크(session handshakes)도, 스티키 로드 밸런싱(sticky load balancing)도, 수평적 확장(horizontal scaling)을 위한 공유 세션 저장소(shared session stores)도 필요하지 않습니다. 모든 요청은 그 자체로 완결성을 갖습니다.

저는 현실이 약속과 일치하는지 확인하고 싶었습니다. 그래서 실제 Lambda 도구들이 뒤에 배치된 라이브 AWS AgentCore Gateway를 대상으로 새로운 사양을 테스트하며 하루를 보냈습니다. 이 포스트는 그 과정에서 발견한 내용입니다.

관점에 대한 참고 사항: 저는 AAIF Ambassador이자 AWS Community Builder로서 이 글을 작성합니다. MCP는 Linux Foundation 산하의 Agentic AI Foundation (AAIF)에서 호스팅하는 오픈 표준입니다. AgentCore Gateway는 해당 표준에 대한 AWS의 관리형 구현체입니다. 관리형 클라우드 구현체를 해당 표준을 지원한다고 주장하는 오픈 사양과 대조하여 테스트하는 것은, MCP 7-28이 약속한 바를 실제로 전달하는지 평가하는 정확한 방법이라고 느꼈습니다.

목차

• 7가지 파괴적 변경 사항 (The Seven Breaking Changes)
• 테스트 설정
• 테스트 결과
• 시사점
• 향후 계획
• 링크

7가지 파괴적 변경 사항

MCP 7-28은 단순한 마이너 버전 업데이트가 아닙니다. 개발자에게 미치는 영향력을 기준으로 정리한 중요한 7가지 변경 사항은 다음과 같습니다:

사용 중단(deprecation) 목록도 주목할 만합니다: Roots, Sampling, 그리고 Logging은 12개월의 권고 사용 중단 기간(advisory deprecation window)이 적용됩니다. 만약 귀하의 툴링이 이 중 하나에 의존하고 있다면, 마이그레이션할 수 있는 시간은 2027년 중반까지입니다.

실제로 네트워크 통신(on the wire)에서 무엇이 변하는지는 다음과 같습니다.

요청 형식 (Request Format)

이전 (7-28 이전, 세션 기반 (session-based)):

POST /mcp HTTP/1.1
Content-Type: application/json
Mcp-Session-Id: 1868a90c-3a3f-4f5b-9c2d-abc123def456
...

이후 (2026-07-28, 무상태 (stateless)):

POST /mcp HTTP/1.1
Content-Type: application/json
MCP-Protocol-Version: 2026-07-28
...

세 가지가 변경되었습니다:

• Mcp-Session-Id가 사라졌습니다. 대신 MCP-Protocol-Version 및 Mcp-Method 헤더가 도입되었습니다.
• 기존에 initialize 핸드셰이크 (handshake) 단계에서 존재하던 클라이언트 식별 정보(Client identity)가 이제 모든 요청의 _meta를 통해 인라인(inline)으로 전달됩니다.
• 인증(Auth)이 세션을 통한 암시적(implicit) 방식이 아닌, HTTP 계층(Authorization 헤더)에서 명시적(explicit)으로 이루어집니다.

응답 형식 (Response Format)

이전 (2025-x):

{"jsonrpc":"2.0","id":1,"result":{"tools":[...]}}

이후 (2026-07-28):

{
  "jsonrpc": "2.0",
  "id": "test-1",
...

새로운 resultType, ttlMs, 그리고 cacheScope 필드는 HTTP 네이티브 캐싱 메타데이터 (HTTP-native caching metadata)입니다. 이 필드들은 프록시(proxies)와 CDN이 별도의 커스텀 로직 없이도 MCP 응답을 어떻게 캐싱할지 알려줍니다. 이는 인프라 측면에서 큰 영향을 미치는 작은 추가 사항입니다.

에러 처리 (Error Handling)

"모든 것이 에러를 JSON 내부에 숨긴 채 HTTP 200을 반환한다"에서 "HTTP 상태 코드(status codes)를 적절히 사용한다"로의 전환은 매우 중요합니다. 이제 모니터링 도구, 로드 밸런서(load balancers), 그리고 알림 시스템(alerting systems)이 응답 바디를 파싱(parsing)하지 않고도 MCP 실패를 감지할 수 있습니다.

테스트 설정 (Setting Up the Test)

프로토콜 변경 사항을 격리된 환경에서 테스트하기 위해, 두 개의 Lambda 기반 데모 도구(echo_message 및 get_current_time)를 사용하는 최소한의 AgentCore Gateway를 생성했습니다.

인프라 (Infrastructure):

• Region (리전): us-east-1
• Gateway (게이트웨이): CUSTOM_JWT 인증자(authorizer)를 사용하는 AgentCore Gateway (Amazon Cognito, client_credentials 권한 부여 방식)
• Backend (백엔드): AWS Lambda, Python 3.12, 128MB
• 활성화된 MCP 버전: 2025-03-26, 2025-11-25, 2026-07-28 -- 세 버전 모두 동시에 활성화됨
• 총 비용: 모든 테스트 비용 $0.001 미만 (AgentCore Gateway에 대한 상시 유지 비용 없음)

설정은 IAM 역할(role), Cognito 풀(pool), Lambda 함수, 게이트웨이 생성, 그리고 테스트 실행 순으로 실행되는 5개의 bash 스크립트로 구성되었습니다. 게이트웨이는 --protocol-type MCP, --authorizer-type CUSTOM_JWT, --exception-level DEBUG 옵션과 함께 supportedVersions가 세 가지 활성 버전을 동시에 포함하도록 설정되어 생성되었습니다.

주의해야 할 점 하나는 UpdateGateway가 supportedVersions를 추가(append)하는 것이 아니라 **교체(replaces)**한다는 것입니다. 기존 버전을 포함하지 않고 2026-07-28을 추가하면 기존 버전들이 삭제됩니다. 항상 get-gateway를 통해 현재 설정을 먼저 확인하십시오.

테스트 결과

라이브 게이트웨이를 대상으로 6가지 테스트를 수행했습니다. 결과는 다음과 같습니다.

테스트 1: Stateless tools/list (MCP 2026-07-28)

가장 핵심적인 테스트입니다. initialize도, 세션(session)도 필요 없습니다. 그냥 요청을 보내기만 하면 됩니다.

요청 (Request):

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

응답 (Response):

{
  "jsonrpc": "2.0",
  "id": "test-1",
...

HTTP 200. 전체 캐시 메타데이터(cache metadata)와 함께 도구(tools)가 반환되었습니다. 세션이 필요하지 않았습니다. 사양(spec)이 광고된 대로 작동합니다.

테스트 2: 하위 호환성 (Backward Compatibility) (MCP 2025-11-25)

동일한 게이트웨이, 동일한 Lambda, 하지만 더 오래된 프로토콜 버전입니다. _meta가 필요하지 않으며, 새로운 헤더(header)도 없습니다.

요청 (Request):

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2025-11-25
Authorization: Bearer <cognito-token>
...

응답 (Response): HTTP 200: 동일한 도구가 반환되었으나, resultType, ttlMs, cacheScope는 포함되지 않았습니다. 프로토콜 버전이 와이어 포맷(wire format)을 결정합니다. 오래된 클라이언트는 오래된 응답을 보고, 새로운 클라이언트는 새로운 메타데이터를 봅니다. 동일한 게이트웨이와 동일한 백엔드를 사용하지만, 와이어(wire)는 다릅니다.

테스트 3: 인증 강제 (토큰 없음)

요청 (Request): 테스트 1과 동일하지만 Authorization 헤더를 완전히 제거했습니다.

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

응답 (Response):

{
  "jsonrpc": "2.0",
  "id": 0,
...

HTTP 401. Lambda가 호출되기 전에 게이트웨이(gateway)에서 요청을 거부했습니다. CloudWatch를 통해 이를 확인했습니다. 이 요청에 대한 Lambda 호출 로그가 없습니다. 인증 강제(Auth enforcement)는 도구(tool) 계층이 아닌 게이트웨이 계층에서 발생합니다. 이것이 6가지 SEP가 약속한 바이며, 실제로 작동합니다.

테스트 4: 지원되지 않는 버전 (Unsupported Version)

요청 (Request): 유효한 인증, 유효한 JSON-RPC를 사용하지만, 존재하지 않는 버전을 사용했습니다.

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2099-01-01
Authorization: Bearer <cognito-token>
...

응답 (Response):

{
  "jsonrpc": "2.0",
  "id": "test-4",
...

새로운 에러 코드 -32022와 함께 HTTP 400이 반환됩니다. data 필드에 지원되는 모든 버전이 나열되어 있어, 클라이언트는 에러 자체로부터 유효한 버전을 찾아낼 수 있습니다. 7월 28일 이전 버전에서는 이 시나리오에서 정의되지 않은 동작(undefined behavior)이 발생했습니다.

테스트 5: 이전 세션 패턴 거부 (Old Session Patterns Rejected)

요청 (Request): 새로운 프로토콜 버전 헤더를 사용하여 전송된 7월 28일 이전의 SSE 시대 초기화 호출입니다. 이는 헤더는 업그레이드했지만 요청 패턴은 업그레이드하지 않은 클라이언트를 시뮬레이션합니다.

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

응답 (Response):

{
  "jsonrpc": "2.0",
  "id": "test-5a",
...

HTTP 400. 게이트웨이는 2026-07-28 요청에 대해 _meta를 필수 사항으로 강제합니다. 실수로 지원 중단된(deprecated) 세션 동작으로 되돌아가는(fall back) 일이 발생하지 않습니다. 프로토콜이 스스로를 강제(self-enforcing)합니다.

테스트 6: 잘못된 형식의 요청 (Malformed Requests)

요청 (Request): Content-Type 헤더가 없는 깨진 본문입니다. 설정이 잘못된 클라이언트나 손상된 페이로드(payload)를 시뮬레이션합니다.

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Authorization: Bearer <cognito-token>
...

응답 (Response):

{
  "jsonrpc": "2.0",
  "id": "unknown",
...

HTTP 400. 에러 코드 -32600 (Invalid Request). 게이트웨이는 MCP 로직이 실행되기도 전에 HTTP/파싱(parse) 계층에서 요청을 거부합니다. 깔끔하고, 예측 가능하며, 디버깅이 용이합니다.

Lambda 실행 프로필 (Lambda Execution Profile)

CloudWatch를 통해 게이트웨이 뒤의 Lambda가 예상되는 최소한의 점유율(footprint)로 실행됨을 확인했습니다:

Duration: 2.00 ms | Billed: 2 ms | Memory: 128 MB | Used: 37 MB     (tools/list)
Duration: 7.77 ms | Billed: 8 ms | Memory: 128 MB | Used: 37 MB     (tools/call)
Init Duration: 94.15 ms                                               (cold start)

게이트웨이는 측정 가능한 오버헤드(overhead)를 추가하지 않습니다. tools/list 호출은 2ms 만에 완료되었습니다. 비즈니스 로직을 포함한 get_current_time에 대한 tools/call은 7.77ms가 소요되었습니다. 콜드 스타트(Cold start)는 94ms였으며, 이는 Python 3.12 Lambda의 표준 수준입니다.

요약 (Summary)

핵심 요약 (Takeaways)

하루 동안의 테스트를 통해 얻은 세 가지 핵심 요약입니다:

수평 확장(Horizontal scaling)이 이제 매우 간단해졌습니다. 무상태(Stateless) MCP를 사용하면 MCP 서버를 어떤 로드 밸런서(load balancer), CDN, API 게이트웨이 뒤에든 배치할 수 있습니다. 어피니티(affinity)나 공유 상태(shared state)가 필요 없습니다. 이것이 MCP를 실제 운영 트래픽 규모에서 실행 가능하게 만드는 변화입니다.

인증(Auth)은 더 이상 선택 사항이 아닙니다. 게이트웨이는 Lambda가 요청을 받기도 전에 OAuth를 강제했습니다. 사양(spec)에 내장된 6가지 SEP를 통해, 이제 모든 구현체가 따를 수 있는 MCP 엔드포인트 보안 표준 방식이 마련되었습니다. 운영 팀은 더 이상 자체적인 인증 계층을 발명할 필요가 없습니다.

에러 핸들링(Error handling)이 마침내 디버깅 가능해졌습니다. HTTP 상태 코드, 기계 판독 가능한 에러 페이로드(error payloads), 그리고 에러 응답에서 지원되는 버전 탐색(version discovery) 기능 덕분에, 커스텀 파서(custom parser) 없이도 MCP를 중심으로 모니터링 및 알림 시스템을 구축할 수 있습니다.

향후 계획 (What's Next)

지원 종료(Deprecation) 주의: Roots, Sampling, Logging은 12개월의 권고 지원 종료(advisory deprecation) 일정이 잡혀 있습니다. 만약 사용 중인 MCP 툴링이 이 중 하나라도 사용하고 있다면, 지금 바로 마이그레이션 계획을 세우기 시작하십시오.

AAIF의 agentgateway는 AgentCore와 같은 관리형 게이트웨이(managed gateways)에 대응하는 오픈 소스 솔루션입니다. 다음 포스트에서는 agentgateway v1.3과 AgentCore Gateway가 각각 MCP 7-28을 어떻게 처리하는지 비교하겠습니다. 동일한 프로토콜을 사용하지만, 배포 모델(deployment models)과 트레이드오프(tradeoffs)는 서로 다릅니다.

**AGNTCon + MCPCon Japan**은 9월 10~11일 도쿄에서 개최됩니다. 이번 릴리스 이후 열리는 첫 번째 주요 커뮤니티 이벤트가 될 것입니다. 만약 프로덕션 환경에서 MCP를 사용하여 구축하고 있다면, 바로 그곳에서 관련 논의가 이루어질 것입니다.

링크

• MCP 2026-07-28 Specification
• How AgentCore Gateway Supports MCP 2026-07-28 -- Sean Eichenberger 및 Luca Chang
• Agentic AI Foundation (AAIF)
• AAIF agentgateway Project
• AgentCore Gateway Documentation
• AgentCore Gateway Quickstart

즐거운 학습 되시길 바랍니다 🚀