2026년 7월 28일, Model Context Protocol(MCP) 공식 블로그에 차세대 스펙 방향을 알리는 글이 올라왔습니다. 새 스펙 버전은 2026-07-28이며, 이번 릴리스 후보는 MCP가 출시된 이후 가장 큰 폭의 개정입니다.
핵심은 하나로 요약됩니다. “MCP를 무상태(stateless) 프로토콜로 만든다.“
이 글에서는 MCP 블로그가 밝힌 정책 변화들을 중심으로 정리합니다.
1. 프로토콜 자체가 무상태로 바뀐다
기존 2025-11-25 버전에서는 도구를 호출하려면 먼저 initialize/initialized 핸드셰이크로 세션을 맺어야 했습니다. 서버가 발급한 Mcp-Session-Id를 이후 모든 요청에 붙여야 했고, 이 때문에 클라이언트는 세션을 발급한 특정 서버 인스턴스에 고정(sticky routing)될 수밖에 없었습니다.
새 스펙에서는 이 핸드셰이크와 세션 헤더가 완전히 제거됩니다. 클라이언트 정보, 프로토콜 버전 같은 메타데이터는 매 요청의 _meta 필드에 실려 전달되고, 서버 역량이 필요하면 server/discover라는 새 메서드로 그때그때 조회합니다.
결과적으로 어떤 요청이든 어떤 서버 인스턴스에 도착해도 처리할 수 있게 되어, 별도의 세션 스토어나 스티키 로드밸런싱 없이 평범한 라운드로빈 로드밸런서로도 MCP 서버를 운영할 수 있게 됩니다.
물론 애플리케이션 차원의 상태 관리가 사라지는 것은 아닙니다. 여러 호출에 걸쳐 상태를 유지해야 하는 서버는 basket_id, browser_id 같은 명시적 핸들을 도구 호출 결과로 발급하고, 모델이 이 값을 다음 호출의 인자로 다시 전달하는 방식을 씁니다. 오히려 이 패턴이 상태를 모델에게 “보이게” 만들어 여러 도구에 걸쳐 핸들을 조합·추론하는 데 더 유연하다는 것이 팀의 설명입니다.
서버가 클라이언트에게 중간에 무언가를 요청하는 흐름(elicitation 등)도 재설계됩니다. SSE 연결을 계속 열어두는 대신, 서버는 InputRequiredResult를 반환하고 클라이언트가 답변과 requestState를 담아 같은 호출을 재요청하는 방식으로 바뀝니다. 이 재요청은 어떤 서버 인스턴스가 받아도 처리할 수 있습니다.
또한 트래픽 운영 편의를 위해 Mcp-Method, Mcp-Name 헤더가 필수화되어 로드밸런서·게이트웨이가 바디를 열어보지 않아도 라우팅할 수 있게 되고, 목록/리소스 응답에는 HTTP Cache-Control을 본뜬 ttlMs, cacheScope가 추가되며, W3C Trace Context 전파 방식이 _meta 안에 공식 문서화됩니다.
2. 확장(Extensions)이 정식 트랙으로 승격된다
기존에도 확장 개념은 있었지만 공식적인 프로세스가 없었습니다. 이번에 역DNS 방식의 ID 체계, extensions 맵을 통한 협상, 별도 저장소(ext-*)에서의 독립적인 유지보수·버전 관리, 그리고 실험 단계에서 공식 단계로 승격되는 SEP 프로세스(Extensions Track)가 도입됩니다.
이번 릴리스에는 두 개의 공식 확장이 포함됩니다.
- MCP Apps: 서버가 대화형 HTML 인터페이스를 제공하고, 호스트는 이를 샌드박스 iframe에서 렌더링합니다. UI가 호스트와 주고받는 통신도 동일한 JSON-RPC 기반 프로토콜을 타기 때문에, UI에서 시작된 동작도 일반 도구 호출과 같은 감사·동의 절차를 거칩니다.
- Tasks:
2025-11-25에서 실험적 핵심 기능이었던 Tasks가 확장으로 자리를 옮깁니다. 무상태 모델에 맞춰 생명주기가 재설계되어, 서버는tools/call응답으로 태스크 핸들을 돌려주고 클라이언트는tasks/get,tasks/update,tasks/cancel로 이를 제어합니다. 세션 없이는 안전하게 범위를 제한할 수 없다는 이유로tasks/list는 제거됩니다. 기존 실험적 Tasks API를 쓰던 구현체는 마이그레이션이 필요합니다.
3. 인가(Authorization) 정책이 OAuth/OIDC 관행에 맞춰 강화된다
여섯 건의 SEP를 통해 인가 스펙이 실제 OAuth 2.0·OpenID Connect 배포 관행에 더 가깝게 정비됩니다. 주요 내용은 다음과 같습니다.
- 클라이언트는 인가 응답의
iss파라미터를 RFC 9207에 따라 검증해야 합니다. 향후 버전에서는iss가 없는 응답을 아예 거부하게 될 예정이므로, 인가 서버 운영자는 미리iss값을 제공해두는 것이 좋습니다. - 동적 클라이언트 등록(Dynamic Client Registration) 시 클라이언트가 OpenID Connect의
application_type을 명시하도록 하여, 데스크톱·CLI 클라이언트가 “web”으로 잘못 분류되어 로컬호스트 리다이렉트가 거부되는 문제를 방지합니다. - 등록된 자격 증명을 발급 인가 서버의
issuer에 바인딩하고, 리소스가 다른 인가 서버로 이전되면 재등록하도록 규정합니다. - OpenID Connect 방식 인가 서버로부터 리프레시 토큰을 요청하는 방법, 단계적 권한 상승(step-up) 시 스코프 누적 방식,
.well-known디스커버리 접미사 등도 함께 명확해집니다.
4. Roots, Sampling, Logging은 공식적으로 폐기(Deprecated) 수순
새로 도입된 기능 생명주기 정책에 따라 세 가지 핵심 기능이 폐기 예정으로 지정됩니다.
| 기능 | 대체 방안 |
|---|---|
| Roots | 도구 파라미터, 리소스 URI, 서버 설정 |
| Sampling | LLM 제공자 API 직접 연동 |
| Logging | stdio 전송의 경우 stderr, 구조화된 관측을 위해서는 OpenTelemetry |
다만 이는 “주석(annotation)상의 폐기”일 뿐, 해당 메서드·타입·역량 플래그는 이번 릴리스와 이후 1년 이내 발행되는 모든 스펙 버전에서 계속 동작합니다. 실제 제거는 별도의 SEP를 거쳐야 합니다.
5. 도구 스키마가 JSON Schema 2020-12 전체를 지원
도구의 inputSchema, outputSchema가 JSON Schema 2020-12 전체 사양으로 확장됩니다. 입력 스키마는 여전히 최상위가 type: "object"여야 하지만 oneOf, anyOf, allOf, 조건부 구성, $ref/$defs 참조가 허용됩니다. 출력 스키마는 제약이 사라지고 structuredContent도 객체뿐 아니라 임의의 JSON 값을 가질 수 있게 됩니다. 다만 구현체는 외부 $ref URI를 자동으로 역참조해서는 안 되며, 스키마 깊이와 검증 시간에 제한을 두어야 합니다.
부수적으로, 존재하지 않는 리소스에 대한 오류 코드가 MCP 자체 코드인 -32002에서 JSON-RPC 표준 코드인 -32602(Invalid Params)로 바뀝니다.
6. “다시는 이런 파괴적인 변경이 표준이 되지 않도록” — 거버넌스 정책
이번 릴리스에는 파괴적 변경(breaking change)이 포함되어 있지만, 팀은 이것이 관행이 되지 않도록 세 가지 거버넌스 장치를 함께 도입했습니다.
- 기능 생명주기 정책: 모든 기능은 Active → Deprecated → Removed 단계를 거치며, 폐기와 제거 사이에 최소 12개월의 유예 기간을 둡니다.
- 확장 프레임워크: 새 기능은 우선 옵트인 확장으로 출시되어 안정화를 거친 뒤, 필요하다면 그때 스펙 본문으로 편입됩니다.
- 적합성 스위트(conformance suite) 연동: 표준 트랙 SEP는 적합성 스위트에 대응하는 시나리오가 반영되기 전까지는 Final 상태에 도달할 수 없습니다. 이 스위트는 공식 SDK 등급을 매기는 SDK 티어 시스템과도 동일하게 사용됩니다.
일정
- 릴리스 후보 확정: 2026년 5월 21일
- 최종 스펙 발행: 2026년 7월 28일
- 그 사이 10주는 SDK 유지관리자와 클라이언트 구현체가 실제 워크로드로 변경 사항을 검증하는 기간이며, Tier 1 SDK는 이 기간 안에 지원을 출시할 것으로 예상됩니다.
정리
이번 개정의 방향성을 한 문장으로 요약하면, “MCP를 평범한 HTTP 인프라 위에서 수평 확장 가능한 무상태 프로토콜로 만들고, 그 위에 확장·인가·생명주기라는 안정적인 진화 장치를 얹는다” 입니다. 세션 고정, SSE 장기 연결 같은 운영 부담을 걷어내는 대신, 상태 관리는 애플리케이션(핸들 패턴)에 맡기고, 새로운 기능은 스펙 본문이 아닌 확장으로 실험하도록 유도하는 것이 이번 정책 변화의 핵심입니다.
답글 남기기