다음 MCP 스펙 릴리즈(2026-07-28)의 주요 내용: Stateless 전환 및 공식 확장 도입 예정

9bow · 5월 27, 2026, 6:30오전

MCP 스펙 릴리즈 후보(The 2026-07-28 MCP Specification Release Candidate) 소개

Model Context Protocol(MCP)은 AI 모델과 외부 도구·데이터 소스를 연결하는 개방형 프로토콜(Open Protocol) 로, Anthropic이 2024년 11월 처음 공개한 이후 1년 만에 Claude뿐 아니라 OpenAI ChatGPT, Google Gemini, GitHub Copilot 등 주요 LLM 호스트가 모두 채택하면서 AI 에이전트 시대의 사실상 표준(de facto standard) 으로 자리잡았습니다. 그러나 빠르게 확산되는 과정에서, 초기 설계가 단일 클라이언트와 단일 서버를 가정한 세션 기반 트랜스포트 였다는 한계가 점차 명확해졌습니다. 원격 MCP 서버를 운영하려면 sticky session 라우팅과 공유 세션 저장소가 필요했고, 게이트웨이는 본문(body)을 깊이 들여다봐야 트래픽을 라우팅할 수 있었습니다.

2026년 5월 21일, Model Context Protocol 블로그는 이러한 한계를 정면으로 다룬 2026-07-28 릴리즈 후보(Release Candidate) 를 공개했습니다. 이번 개정은 프로토콜 출시 이래 가장 큰 폭의 변화로, 2026 MCP 로드맵에서 약속한 네 가지 축을 모두 담아냈습니다. 첫째, 일반 HTTP 인프라에서 수평 확장이 가능한 스테이트리스 코어(Stateless Core). 둘째, MCP Apps와 Tasks 같은 기능을 별도 레포에서 진화시키는 공식 확장 프레임워크(Extensions Framework). 셋째, OAuth 2.0과 OpenID Connect의 실제 배포 패턴에 더 가깝게 맞춰진 인증 강화(Authorization Hardening). 그리고 넷째, 빌드한 자산이 깨지지 않으면서도 프로토콜이 진화할 수 있도록 하는 명시적 폐기 정책(Feature Lifecycle Policy) 입니다.

실무적 임팩트는 즉각적입니다. 이전에는 sticky 세션, 공유 세션 저장소, 게이트웨이의 deep packet inspection이 필요했던 원격 MCP 서버를 이제는 평범한 라운드 로빈 로드밸런서(round-robin load balancer) 뒤에 그대로 배치할 수 있고, Mcp-Method 헤더만 보고 트래픽을 라우팅하며, 클라이언트가 tools/list 응답을 서버가 명시한 ttlMs 만큼 캐싱할 수 있습니다. 다만 이번 릴리즈에는 breaking change 가 포함되어 있으며, 릴리즈 후보가 잠긴(locked) 시점은 2026년 5월 21일, 최종 사양 발표 예정일은 2026년 7월 28일 입니다. 그 사이 10주는 공식 SDK와 클라이언트 구현체가 실제 워크로드로 변경 사항을 검증하는 기간입니다.

스테이트리스 프로토콜로의 전환: 세션이 사라진 MCP

이번 릴리즈의 헤드라인은 MCP가 프로토콜 계층에서 스테이트리스(stateless)가 되었다 는 점입니다. 여섯 개의 Specification Enhancement Proposals(SEPs)가 함께 맞물려 이 변화를 완성하는데, 이는 2025년 12월에 공개된 The Future of MCP Transports 에서 예고된 계획을 마무리하는 작업이기도 합니다.

Before와 After: 동일한 도구 호출의 변화

2025-11-25 사양에서 Streamable HTTP를 통해 도구를 호출하려면 먼저 세션을 수립해야 했습니다. 클라이언트는 initialize 메서드로 protocolVersion, capabilities, clientInfo 를 한꺼번에 보내고, 서버는 Mcp-Session-Id 를 발급합니다. 이후 모든 요청은 이 세션 ID를 헤더에 실어야 하며, 그 결과 해당 클라이언트는 세션 ID를 발급한 인스턴스에 고정(pinning)됩니다.

POST /mcp HTTP/1.1
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"initialize",
 "params":{"protocolVersion":"2025-11-25","capabilities":{},
           "clientInfo":{"name":"my-app","version":"1.0"}}}

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

{"jsonrpc":"2.0","id":2,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"}}}

2026-07-28 에서는 같은 호출이 단 한 번의 자기 완결적인(self-contained) 요청 으로 단순해집니다. 프로토콜 버전과 메서드 이름은 헤더로 올라가고, 클라이언트 정보는 _meta 필드로 본문에 함께 실립니다. 어떤 서버 인스턴스로 라우팅되든 동일하게 처리할 수 있는 형태입니다.

POST /mcp HTTP/1.1
MCP-Protocol-Version: 2026-07-28
Mcp-Method: tools/call
Mcp-Name: search
Content-Type: application/json

{"jsonrpc":"2.0","id":1,"method":"tools/call",
 "params":{"name":"search","arguments":{"q":"otters"},
           "_meta":{"io.modelcontextprotocol/clientInfo":{"name":"my-app","version":"1.0"}}}}

핸드셰이크와 세션, 둘 다 사라졌습니다

initialize/initialized 핸드셰이크가 SEP-2575 로 제거되었습니다. 연결 시점에 한 번 교환되던 프로토콜 버전, 클라이언트 정보, 클라이언트 능력(capabilities) 은 이제 모든 요청의 _meta 에 함께 실려서 전송 됩니다. 클라이언트가 서버의 능력을 미리 알아야 할 때를 위해 새로운 server/discover 메서드도 추가되었습니다.

Mcp-Session-Id 헤더와 그에 딸려 있던 프로토콜 수준 세션은 SEP-2567 로 함께 제거되었습니다. 두 가지가 모두 사라지면서, 어떤 MCP 요청이든 어떤 서버 인스턴스에든 떨어질 수 있게 되었고, 수평 배포에 필수였던 sticky 라우팅과 공유 세션 저장소가 더 이상 프로토콜 계층에서 요구되지 않습니다.

스테이트리스 프로토콜, 스테이트풀 애플리케이션

프로토콜 수준 세션이 사라졌다는 것이 애플리케이션도 스테이트리스여야 한다 는 의미는 아닙니다. 호출 간에 상태를 이어가야 하는 서버는, HTTP API가 늘 해 왔던 방식 즉, 도구가 명시적인 핸들(basket_id, browser_id 등)을 발급하고 모델이 이후 호출에 인자로 다시 전달 하는 패턴을 사용하면 됩니다.

흥미로운 점은 이 모델이 도구 호출 사이에 식별자를 직접 엮는 패턴이 단순한 대체재가 아니라 오히려 더 강력한 모델 이라는 사실입니다. 모델은 여러 도구가 발급한 핸들을 조합하고, 이들을 이용해 추론하며, 단계 사이에서 자유롭게 주고받을 수 있습니다. 트랜스포트 메타데이터에 숨어 있던 외부 관리 세션 상태로는 결코 허용되지 않았던 표현력입니다. 프로토콜은 더 이상 상태를 관리해 주지 않지만, 동시에 사용자가 상태를 관리하는 것을 막지도 않습니다. 명시적 핸들 패턴은 단지 그 상태를 모델에게 보이게 만들어 줄 뿐입니다.

Server-to-Client 요청의 재설계

스테이트리스 프로토콜에서도, 서버가 호출 도중 클라이언트에게 무언가를 요청해야 하는 흐름(예: elicitation 프롬프트) 은 여전히 필요합니다. 두 개의 SEP가 이 흐름을 지속적 연결 없이도 동작하도록 재설계했습니다.

먼저, SEP-2260 은 서버 주도(server-initiated) 요청을 서버가 클라이언트 요청을 능동적으로 처리하고 있는 동안에만 발행 가능 하도록 강제 합니다. 이전 사양에서는 권고였던 내용이 이제 필수가 된 셈인데, 사용자가 난데없이 프롬프트를 받는 일이 없어지고, 모든 elicitation 이 사용자(또는 그의 에이전트)가 시작한 어떤 행동으로 거슬러 추적 가능해집니다.

다음으로 SEP-2322 가 도입한 다중 라운드트립 요청(Multi Round-Trip Requests) 은 이러한 프롬프트가 전달되는 방식을 바꿉니다. 서버가 Server-Sent Events(SSE) 스트림을 열어 두는 대신, InputRequiredResult 를 반환합니다.

{
  "resultType": "inputRequired",
  "inputRequests": {
    "confirm": {
      "type": "elicitation",
      "message": "Delete 3 files?",
      "schema": { "type": "boolean" }
    }
  },
  "requestState": "eyJzdGVwIjoxLCJmaWxlcyI6WyJhIiwiYiIsImMiXX0="
}

클라이언트는 사용자에게서 답변을 모은 뒤, 원래 호출을 inputResponses 와 서버가 돌려준 requestState 와 함께 다시 요청합니다. 필요한 정보가 모두 페이로드에 들어 있기 때문에, 어떤 서버 인스턴스가 재시도 요청을 받든 동일하게 이어서 처리 할 수 있습니다.

라우팅·캐싱·트레이싱이 쉬워졌습니다

세 가지 작은 변화가 결과적으로 트래픽을 운영하기 쉽게 만듭니다. Streamable HTTP 트랜스포트는 이제 Mcp-Method 와 Mcp-Name 헤더를 필수 로 요구하므로, 로드밸런서·게이트웨이·레이트 리미터가 본문을 들여다보지 않고도 어떤 연산인지 알 수 있습니다. 헤더와 본문이 불일치하면 서버가 요청을 거부합니다.

목록(list)이나 리소스 읽기 결과는 이제 SEP-2549 에 따라 ttlMs 와 cacheScope 를 함께 실어 보냅니다. HTTP의 Cache-Control 을 모델로 한 설계로, 클라이언트는 tools/list 응답이 얼마나 신선한지, 사용자 간 공유해도 안전한지를 정확히 알 수 있습니다. 더 이상 목록이 바뀌었음을 알기 위해 장기 SSE 스트림을 열어둘 필요가 없습니다.

_meta 를 통한 W3C Trace Context 전파도 SEP-414 로 사양에 명문화되었습니다. traceparent, tracestate, baggage 키 이름이 못박혔으므로, 호스트 애플리케이션에서 시작된 트레이스가 클라이언트 SDK → MCP 서버 → 그 너머의 다운스트림까지 따라가며 OpenTelemetry 호환 백엔드에서 하나의 span tree 로 보이게 됩니다.

확장(Extensions)이 1급 시민이 되다

2025-11-25 릴리즈에도 확장이라는 개념은 있었지만, 이를 운영할 공식 프로세스 가 없었습니다. SEP-2133 이 그 빈자리를 채웁니다. 확장은 이제 reverse-DNS ID 로 식별되고, 클라이언트와 서버 capabilities 안의 extensions 맵을 통해 협상되며, 각자 ext-* 별도 레포지토리에 위임된 메인테이너 그룹이 관리하고, 사양 본체와는 독립적으로 버전이 매겨집니다. 또한 SEP 프로세스에는 새롭게 Extensions Track 이 추가되어, 실험적 단계에서 시작한 확장이 공식 단계까지 단계적으로 승격될 수 있는 경로가 마련되었습니다.

이번 릴리즈에는 두 개의 공식 확장이 포함됩니다.

MCP Apps: 서버가 렌더링하는 사용자 인터페이스

MCP Apps (SEP-1865) 는 서버가 호스트의 샌드박싱된 iframe 안에서 렌더링할 인터랙티브 HTML 인터페이스를 함께 배포할 수 있게 합니다. 도구는 자신의 UI 템플릿을 사전에 선언하므로, 호스트는 실행 전에 미리 받아 캐시하고 보안 검토를 수행할 수 있습니다. 렌더링된 UI는 MCP 의 다른 영역과 동일한 JSON-RPC 베이스 프로토콜로 호스트와 통신하므로, UI 가 시작하는 모든 액션 역시 직접적인 도구 호출과 동일한 감사(audit) 및 동의(consent) 경로를 거치게 됩니다.

이 디자인의 핵심은 "UI 가 신뢰 경계의 바깥에 있다" 는 점입니다. 호스트는 MCP 서버가 보낸 HTML 을 무비판적으로 띄우지 않고, 도구가 사전에 선언한 템플릿만 허용합니다. 새로운 LLM 호스트가 등장하더라도, 같은 MCP 서버의 UI 를 동일한 보안 모델로 사용할 수 있는 길이 열린 셈입니다. 자세한 배경은 OpenAI 가 발표한 ChatGPT Apps 기능 의 흐름과 함께 읽으면 더 이해가 쉽습니다.

Tasks가 코어에서 확장으로 졸업

Tasks 는 2025-11-25 사양에서 실험적 코어 기능 으로 처음 출시되었습니다. 그러나 실제 프로덕션 사용 사례가 누적되면서, 단순히 사양을 다듬는 정도가 아니라 재설계가 필요한 수준의 변경이 요구되었고, 따라서 이 기능을 코어가 아닌 확장으로 옮기는 결정 이 내려졌습니다.

새로운 Tasks 확장 은 라이프사이클을 스테이트리스 모델에 맞게 재구성합니다. 서버는 tools/call 응답으로 태스크 핸들(task handle) 을 돌려줄 수 있고, 클라이언트는 tasks/get, tasks/update, tasks/cancel 로 그 태스크를 운전합니다. 태스크 생성은 서버 주도(server-directed) 입니다. 클라이언트가 단지 Tasks 확장을 지원함 을 광고하면, 어떤 호출을 태스크로 실행할지는 서버가 결정합니다. 또한 세션이 사라진 환경에서 안전하게 범위를 잡기 어렵다는 이유로 tasks/list 는 제거되었습니다.

2025-11-25 의 실험적 Tasks API 를 이미 채택한 구현체라면 새 라이프사이클로의 마이그레이션이 필요 합니다.

인증(Authorization)이 더 단단해졌습니다

여섯 개의 SEP 가 authorization 사양 을 강화하여, 실제 OAuth 2.0 과 OpenID Connect 배포 패턴에 더 가깝게 정렬합니다.

가장 먼저, 클라이언트는 인가 응답(authorization response) 의 iss 파라미터를 RFC 9207 에 따라 반드시 검증 해야 합니다(SEP-2468). MCP 의 단일 클라이언트, 다중 서버 배포 패턴에서는 mix-up 공격(mix-up attack)의 가능성이 더 흔하기 때문에, 낮은 비용으로 큰 효과를 보는 완화책입니다. 향후 버전에서는 iss 가 누락된 응답은 거부하도록 클라이언트가 기대될 것이므로, 인가 서버는 지금부터라도 이를 함께 내려보내는 것이 좋습니다.

클라이언트는 또한 동적 클라이언트 등록(Dynamic Client Registration) 시점에 OpenID Connect 의 application_type 을 명시적으로 선언(SEP-837) 해야 합니다. 그렇게 하지 않으면 인가 서버가 데스크톱·CLI 클라이언트를 기본값인 "web" 으로 간주하고, 그 결과 localhost 리다이렉트 URI 를 거절하는 흔한 사고가 발생합니다. 등록된 자격 증명(credential)은 발급한 인가 서버의 issuer 에 바인딩되고, 리소스가 다른 인가 서버로 이동하면 클라이언트는 재등록을 수행합니다(SEP-2352).

이외에도 사양은 OpenID Connect 스타일 인가 서버에서 refresh token 을 요청하는 방법(SEP-2207), step-up 인증 시 scope 누적 규칙, 그리고 .well-known 디스커버리 접미사 규칙 을 명확히 정의했습니다.

Roots, Sampling, Logging 의 폐기

세 가지 코어 기능이 새로운 기능 라이프사이클 정책(SEP-2577) 아래에서 폐기(deprecated) 표시되었습니다.

기능	대체 수단
Roots	도구 파라미터, 리소스 URI, 또는 서버 설정
Sampling	LLM 제공자 API 와의 직접 통합
Logging	stdio 트랜스포트는 `stderr`, 구조화된 관측 가능성에는 OpenTelemetry

이번 폐기는 애너테이션(annotation) 수준 의 표시입니다. 메서드·타입·capability 플래그는 이번 릴리즈와 이후 1년 이내 발행되는 모든 사양 버전에서 계속 동작 하며, 실제 제거하려면 라이프사이클 정책에 따라 별도 SEP 가 필요합니다. 즉, 지금부터 새 구현체를 만들 때는 대체 수단으로 향하되, 기존 구현체가 당장 깨지지는 않는다는 의미입니다.

도구 스키마, JSON Schema 2020-12 전면 지원

도구의 inputSchema 와 outputSchema 가 JSON Schema 2020-12 전체 사양으로 확장되었습니다(SEP-2106). Input schema 는 여전히 루트가 type: "object" 라는 제약을 유지하지만, 이제 oneOf, anyOf, allOf 같은 조합(composition), 조건절(if/then/else), 그리고 $ref, $defs 를 통한 참조 가 모두 허용됩니다. Output schema 에는 그러한 루트 제약이 없으며, structuredContent 도 더 이상 객체로만 한정되지 않고 임의의 JSON 값을 담을 수 있습니다.

다만, 보안과 성능을 위해 구현체는 외부 $ref URI 를 자동으로 역참조(dereference)해서는 안 되며, 스키마 깊이와 검증 시간에 상한을 두어야 합니다. 또한 누락된 리소스에 대한 에러 코드가 MCP 고유 값이었던 -32002 에서 JSON-RPC 표준 값인 -32602 (Invalid Params) 로 변경되었으므로(SEP-2164), 만약 클라이언트가 -32002 라는 문자 그대로의 값 으로 분기하고 있다면 코드 수정이 필요합니다.

프로토콜은 앞으로 어떻게 진화하나

이번 릴리즈에는 breaking change 가 포함되어 있습니다. 그러나 MCP 팀은 이런 큰 변화를 상시적인 운영 모델 로 만들 의도가 없습니다. 이번 릴리즈에는 향후 개정에서 코어 기능을 깨뜨리지 않으면서도 프로토콜이 진화할 수 있도록, 세 가지 거버넌스 SEP 가 함께 도입되었습니다.

첫째, 기능 라이프사이클 정책 은 모든 기능에 Active → Deprecated → Removed 의 단계를 부여하고, 폐기 표시 이후 최소 12개월 이 지나야 제거가 가능하다는 시간 보장(time guarantee) 을 둡니다. 둘째, 새로 등장하는 능력은 일단 확장(opt-in extension) 으로 출시되어 그 안에서 안정화될 수 있으며, 충분히 검증된 뒤에야 비로소 사양 본체로 편입될지 결정합니다(혹은 아예 편입되지 않을 수도 있습니다). 셋째, SEP-2484 에 따라 Standards Track SEP 는 conformance suite 에 대응하는 시나리오가 추가되기 전까지는 Final 상태에 도달할 수 없습니다. 이 conformance suite 는 새로운 SDK 티어 시스템 이 공식 SDK 의 등급을 매기는 기준이기도 합니다.

스테이트리스 재설계는 한 번쯤 깔끔하게 끊고 가야 할 종류의 기초 변경입니다. 이번 릴리즈로 그 작업이 마무리되고, 앞으로는 폐기 윈도우와 확장 메커니즘이 표준 도구가 되므로, 2026-07-28 을 타깃으로 구현한 코드는 향후 개정에서도 트랜스포트나 라이프사이클을 다시 쓰지 않고 적응할 수 있을 것 으로 기대됩니다.

릴리즈 일정과 검증

릴리즈 후보는 2026년 5월 21일에 잠겼고(locked), 최종 사양은 2026년 7월 28일 에 공개됩니다. 그 사이 10주의 윈도우는 SDK 메인테이너와 클라이언트 구현자가 실제 워크로드로 변경 사항을 검증하기 위한 시간입니다. SDK 티어 시스템 상 Tier 1 SDK 는 이 윈도우 안에 새 사양 지원을 출시할 것으로 기대됩니다.

전체 릴리즈 후보는 draft 사양 문서 에 반영되어 있으며, 2025-11-25 대비 모든 변경은 changelog 에 정리되어 있습니다. 문제를 발견했다면 사양 저장소 issue 에 보고하고, 구현 관련 질문은 Working Group 채널이나 컨트리뷰터 Discord 가 가장 빠른 답을 얻을 수 있는 경로입니다.

정리: MCP 가 오래 가는 표준이 되기 위한 토대

이번 2026-07-28 릴리즈 후보는 MCP 가 오래 갈 표준이 되기 위해 갖춰야 했던 세 가지 토대를 한 번에 마련합니다. 첫째, 평범한 HTTP 인프라 위에서 스테이트리스로 동작하는 프로토콜이 되었고, 둘째, MCP Apps 나 Tasks 같은 능력이 자기 자신의 일정으로 진화할 수 있는 확장 프레임워크가 마련되었으며, 셋째, 구현자가 자신이 만든 자산이 어떤 시점에 어떻게 깨질 수 있는지 를 사전에 알 수 있는 라이프사이클 정책이 도입되었습니다.

AI 에이전트가 외부 세계와 상호작용하는 방식이 일종의 공통 인터페이스(common interface) 위에 수렴하고 있는 시점에서, MCP 의 이번 릴리즈는 그 인터페이스를 운영 가능한(operable) 수준의 인프라 표준으로 끌어올리려는 시도로 읽힙니다. Streamable HTTP, OAuth 정렬, JSON Schema 2020-12, 그리고 12개월 폐기 윈도우는 모두 대형 시스템 에서 익숙한 운영 원칙이며, MCP 가 이 원칙들을 흡수했다는 사실 자체가 프로토타입에서 인프라로 의 전환 신호일 수 있습니다.

Model Context Protocol 홈페이지

The 2026-07-28 MCP Specification Release Candidate 발표 블로그

Model Context Protocol GitHub 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 글을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 덧글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임이 정리한 이 글이 유용하셨나요? 회원으로 가입하시면 주요 글들을 이메일로 보내드립니다! (기본은 Weekly지만 Daily로 변경도 가능합니다.)

아래쪽에 좋아요를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~