서론

2026년 7월 28일, Anthropic은 「Bringing MCP 2026-07-28 to Claude」를 공개하며, MCP(Model Context Protocol)의 5번째 대규모 사양 업데이트가 Claude에 도입됨을 발표했습니다. 원격 프로토콜이 등장한 지 약 1년 반 만에 이루어진 가장 큰 변경입니다.

이 기사에서는 공식 블로그와 MCP 공식 사양 블로그를 바탕으로 다음 내용을 알기 쉽게 정리합니다.

• 이번 업데이트로 무엇이 변했는가 (가장 큰 핵심은 「스테이트리스(Stateless)화」)
• 그 결과 개발자가 무엇을 할 수 있게 되었는가
• 기존 MCP 서버를 어떻게 마이그레이션해야 하는가

결론: MCP는 「스테이트리스 HTTP 워크로드(Stateless HTTP Workload)」가 되었다

세부적인 내용에 들어가기에 앞서, 이번 업데이트의 본질을 한마디로 요약합니다.

지금까지 「세션을 계속 유지하는, 상태를 가진 프로토콜」이었던 MCP가,

1개의 요청으로 완결되는 스테이트리스한 요청/응답(Request/Response) 방식으로 탈바꿈했습니다.

이로 인해 MCP 서버는 특별한 장치 없이도 서버리스(Serverless), 에지(Edge), 로드 밸런서(Load Balancer) 하부에서 동작할 수 있게 되었습니다.

규모를 나타내는 수치도 업데이트되었습니다.

• Claude의 커넥터 디렉토리에는 950개 이상의 MCP 서버가 등록되어 있으며, 매일 수백만 명이 이용하고 있습니다.
• MCP의 월간 SDK 다운로드 수는 4억 회 초과 (올해 4배 증가)
• TypeScript / Python SDK는 누적 10억 다운로드를 돌파

Anthropic은 MCP가 사실상 「AI 에이전트와 앱을 연결하는 업계 표준」이 되었다고 규정하고 있습니다.

1. 가장 큰 핵심: 스테이트리스 프로토콜 코어

이번 변경의 중심은 프로토콜 코어의 스테이트리스(Stateless)화입니다.

무엇이 사라졌는가

• initialize / initialized 핸드셰이크 (SEP-2575)
• 세션을 식별하는 Mcp-Session-Id 헤더 (SEP-2567)

지금까지는 「먼저 초기화하고, 세션 ID를 발행하여, 그것을 계속 들고 다녀야」 했습니다. 이번에는 이를 중단하고, **모든 요청이 자기 기술적(Self-describing)**이 됩니다. 프로토콜 버전, 클라이언트 정보, 기능(Capability)을 _meta 필드에 담아 매번 보내는 방식입니다.

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

왜 좋은가

각 요청이 독립적이므로, 어느 서버 인스턴스에 도착하더라도 처리가 가능합니다. 공유 스토리지나 세션 어피니티(Session Affinity, 동일한 서버로 연결하는 메커니즘)도 필요하지 않습니다.

「상태를 가질 수 없게 되는 것」은 아니다

스테이트리스화 = 앱이 상태를 가질 수 없다는 뜻은 아닙니다. **명시적인 핸들(Handle, Identifier)**을 사용합니다.

• 서버는 도구의 응답으로 basket_id와 같은 핸들을 반환합니다.
• 모델은 다음 호출 시 그 핸들을 인자(Argument)로 전달합니다.

숨겨진 세션 상태 대신, 상태를 명시적으로 전달하는 설계입니다. 오히려 모델이 여러 도구를 가로질러 핸들을 조합하거나, 상태를 명시적으로 다룰 수 있다는 이점으로 설명되고 있습니다.

2. Multi Round-Trip Requests (MRTR) — 사용자에게 질문하기를 스테이트리스(Stateless)하게

지금까지 "실행 전 확인"이나 "부족한 파라미터의 추가 입력"은 서버 측에서 elicitation/create 등을 호출하고, SSE 스트림을 계속 열어두어야 했습니다. 스테이트리스(Stateless) 방식에서는 사용할 수 없습니다.

그래서 도입된 것이 MRTR (SEP-2322) 입니다.

• 서버는 처리 도중에 resultType: "input_required"를 반환하며, 필요한 입력(inputRequests)과 상태를 담은 base64 형식의 requestState를 반환합니다. - 클라이언트는 답변을 수집하여, 원래의 호출에 inputResponses와 requestState를 붙여서 재전송합니다. - 상태가 모두 페이로드(Payload)에 들어있기 때문에, 어떤 인스턴스에서도 처리를 재개할 수 있습니다.

이를 통해 "삭제하기 전에 확인하기", "부족한 파라미터를 다시 묻기"와 같은 elicitation (질문/유도) 기능이 스테이트리스 환경에서도 구현 가능해졌습니다. Supabase 등이 "지금까지 불가능했던 기능"이라며 환영하고 있습니다.

3. 헤더 기반 라우팅 (SEP-2243)

Streamable HTTP 요청은 Mcp-Method와 Mcp-Name 헤더를 필수로 포함해야 합니다.

• 게이트웨이, 속도 제한(Rate Limiting), WAF가 JSON 바디를 분석하지 않고 헤더만으로 라우팅이나 미터링(Metering)을 할 수 있습니다. - 헤더와 바디가 일치하지 않는 요청은 서버가 거부합니다.

인프라 측면에서 보면, MCP가 마침내 "일반적인 HTTP 워크로드"로 취급될 수 있게 되었다는 것을 의미합니다.

4. 목록 결과 캐싱 (SEP-2549)

tools/list, prompts/list, resources/list, resources/read 응답에 HTTP의 Cache-Control을 참고한 **ttlMs (유효 기간) 및 cacheScope (공유 범위)**가 추가되었습니다.

• 클라이언트는 영구 스트림 없이도 캐시 전략을 결정할 수 있습니다. - 순서가 결정론적(Deterministic)으로 바뀌면서, 재연결 시에도 프롬프트 캐시가 안정적으로 유지됩니다.

5. 분산 트레이싱 (Distributed Tracing)

W3C Trace Context 전파가 정식으로 문서화되었으며, traceparent, tracestate, baggage를 _meta에 고정된 키 이름으로 실을 수 있습니다. OpenTelemetry 호환 백엔드에서 SDK와 하류(Downstream) 서비스를 가로지르는 트레이스를 상관(Correlation)시킬 수 있습니다.

6. 인증 강화: OAuth 2.0 / OIDC 정식 준수

엔터프라이즈 도입에 효과적인 변경 사항입니다. 6개의 SEP를 통해 인증이 강화되었으며, Entra나 Okta와 같은 기업의 ID 시스템에 우회책 없이 연결할 수 있게 되었습니다.

7. 확장 프레임워크 (Extensions Framework) 정식화

"코어 사양을 변경하지 않고 새로운 기능을 추가하기" 위한 메커니즘이 정식화되었습니다.

• 확장은 역 DNS 형식의 ID로 식별하며, 클라이언트/서버의 extensions 맵을 통해 협상(Negotiate)합니다. - ext-* 리포지토리에서 코어 사양과 독립적으로 버전 관리됩니다. - SEP 프로세스에 Extensions Track이 신설되어, 실험적 단계에서 공식 단계로 단계적으로 승격될 수 있습니다.

대표적인 확장은 다음과 같습니다.

8. 스키마와 에러 코드 업데이트

• 툴의 inputSchema / outputSchema가 JSON Schema 2020-12를 풀 서포트 (oneOf / anyOf / allOf, 조건부 유효성 검사(Conditional Validation), $ref / $defs)
• structuredContent는 객체에 국한되지 않고 임의의 JSON 값을 수용
• 외부 $ref URI의 자동 해결은 금지 (스키마의 깊이나 검증 시간도 제한해야 함)
• 파괴적 변경 (Breaking Change): 리소스 부재 에러가 자체 코드 -32002에서 JSON-RPC 표준인 -32602 (Invalid Params)로 변경. -32002를 리터럴 일치로 확인하는 클라이언트는 수정이 필요함

9. 비권장 (12개월의 이행 기간 포함)

모두 본 릴리스 및 공개 후 12개월 동안은 동작합니다 (SEP-2577). 삭제를 위해서는 별도의 SEP가 필요하다는 **라이프사이클 정책 (Lifecycle Policy)**이 수립되었습니다.

10. 이를 통해 '깨지지 않는' 업그레이드로

미래의 파괴적 변경을 방지하기 위한 거버넌스(Governance)도 3가지 마련되었습니다.

• 기능 라이프사이클 정책 (Feature Lifecycle Policy): Active → Deprecated → Removed. 각 전이에는 최소 12개월의 유예 기간 부여
• 확장 프레임워크 (Extension Framework): 신기능은 옵트인(opt-in) 방식의 확장으로 출시하여 독립적으로 안정화
• 적합성 요구사항 (Compliance Requirements): Standards Track의 SEP는 적합성 테스트 시나리오가 갖춰지지 않으면 Final 단계가 될 수 없음. SDK는 새로운 티어(Tier) 제도로 채점됨

목표는 2026-07-28 버전을 채택한 구현체가 트랜스포트(Transport)나 라이프사이클 코드를 다시 작성하지 않고도 미래 버전으로 올라갈 수 있도록 하는 것입니다.

11. SDK 및 대응 현황

• Tier 1 SDK (TypeScript / Python / Go / C#)는 모두 2026-07-28에 대응 완료
• Rust SDK는 베타 버전으로 대응 - 릴리스 후보는 2026년 5월 21일에 확정, 최종 사양은 7월 28일에 출하 (약 10주간의 검증 기간)

개발자로서 할 수 있게 되는 것 (요약)

이번 업데이트를 '개발자 관점의 가능해진 것'으로 번역하면 다음과 같습니다.

• 서버리스/엣지(Edge)에서 MCP 서버를 구동할 수 있음: 상주 서버나 세션 스토어를 준비하지 않아도 Cloudflare Workers나 서버리스 함수에 그대로 올릴 수 있음
• 일반 로드 밸런서로 스케일링 가능: 스티키 세션(Sticky Session) 설정이 불필요. 순수 라운드 로빈(Round Robin)으로 수평 확장 가능
• 스테이트리스 상태에서도 '확인 대화상자'를 띄울 수 있음: MRTR을 통해 파괴적인 작업 전의 확인이나 추가 입력 요청이 가능함
• 인프라 측에서 라우팅 및 제한을 걸기 쉬움: Mcp-Method 헤더를 통해 바디(Body)를 들여다보지 않고도 게이트웨이 제어 가능
• 기업의 ID와 올바르게 연결됨: OAuth 2.0 / OIDC 준수로 Entra, Okta 등에 그대로 연결
• 풍부한 UI를 안전하게 제공할 수 있음: MCP Apps를 통해 샌드박스 iframe UI를 감사 일관성을 유지하며 제공
• 장시간 작업을 처리할 수 있음: Tasks 확장을 통한 폴링 기반의 진행 관리
• 미래의 업그레이드 시 깨질 위험이 적음: 라이프사이클과 적합성 거버넌스가 정비됨

요약

• MCP 2026-07-28의 본질은
  「스테이트풀 (Stateful) 세션」에서 「스테이트리스 (Stateless) 요청/응답」으로의 전환 -
  initialize 핸드셰이크와 Mcp-Session-Id가 사라지고, 각 요청이 자기 완결적(self-contained)으로 동작합니다. 서버리스(Serverless)/에지(Edge)/라운드 로빈(Round-robin) 환경에서 작동합니다 -
  MRTR을 통해 스테이트리스 상태에서도 재질의(querying back)가 가능해졌습니다. 헤더 라우팅 (Header Routing), 리스트 캐싱 (List Caching), **분산 트레이싱 (Distributed Tracing)**을 통해 인프라 친화적으로 변했습니다 -
  OAuth 2.0 / OIDC 준수로 엔터프라이즈 인증에 대응합니다. 확장 프레임워크 (Extension Framework) (MCP Apps / Tasks / EMA)를 통해 기능 추가를 코어(Core)로부터 분리합니다 - 파괴적 변경(에러 코드 -32002 → -32602, 실험적 Tasks API의 이전)과 12개월의 권장되지 않음(Deprecated) 전환 기간에 주의하십시오 - Tier 1 SDK는 대응을 완료했습니다. 우선 공식 마이그레이션 문서를 확인하는 것부터 시작해 보세요.

수고하셨습니다!

참고 링크

Discussion