MCP(Model Context Protocol) 사양을 관리하는 워킹그룹이 7월 28일 최종 발표를 앞두고 5월 21일 릴리스 후보를 공개했다. 리드 메인테이너 데이비드 소리아 파라와 덴 델리마스키가 공식 블로그에 직접 밝힌 이번 개편은 출시 이후 가장 큰 규모의 스펙 변경으로, 핵심은 프로토콜 계층에서 세션 개념 자체를 없앤 것이다. 지금까지 MCP 서버를 여러 대로 늘리려면 특정 요청을 항상 같은 서버로 보내는 고정 라우팅과 인스턴스 간에 공유하는 세션 저장소가 필요했는데, 이 개편 이후에는 평범한 라운드로빈 로드밸런서 뒤에 서버를 몇 대든 세워도 된다.
이번 릴리스 후보는 이런 하위 호환성 깨짐을 포함하고 있어서, 최종 스펙이 나오는 7월 28일까지 10주의 검증 기간을 뒀다. SDK 등급 체계상 1등급 SDK는 이 기간 안에 대응을 마쳐야 한다.
지금까지 서버 한 대에 묶여 있던 이유
2025-11-25 버전에서 Streamable HTTP로 도구를 호출하려면 먼저 세션을 여는 initialize 요청을 보내야 했다. 서버는 응답에 Mcp-Session-Id를 담아 돌려주고, 이후의 모든 요청은 이 값을 붙여야 했다. 문제는 이 세션 ID가 그 값을 발급한 서버 인스턴스 하나에 묶인다는 점이다. 그래서 로드밸런서는 같은 클라이언트의 요청을 항상 같은 인스턴스로 보내는 고정 라우팅을 유지해야 했고, 여러 인스턴스가 세션 상태를 공유하려면 별도의 세션 저장소까지 필요했다.
2026-07-28 버전에서는 이 handshake 자체가 없어졌다. 프로토콜 버전과 클라이언트 정보는 매 요청의 _meta 필드에 담아 보내고, 서버 기능이 필요하면 새로 생긴 server/discover 메서드로 그때그때 조회한다. Mcp-Session-Id 헤더와 그 헤더가 만들던 프로토콜 수준의 세션도 함께 제거됐다. 그 결과 하나의 요청은 그 자체로 완결된 정보를 담게 됐고, 어떤 서버 인스턴스가 받아도 처리할 수 있다.
상태가 필요한 앱은 이제 어떻게 하나
프로토콜이 세션을 관리해 주지 않는다고 해서 애플리케이션까지 상태를 포기해야 하는 것은 아니다. 상태를 유지해야 하는 서버는 HTTP API가 오래전부터 해 온 방식을 그대로 쓰면 된다. 도구 호출 하나가 basket_id 같은 명시적인 식별자를 만들어 돌려주고, 모델이 다음 호출에서 이 값을 평범한 인자로 다시 전달하는 방식이다.
공식 블로그는 이 패턴이 세션의 단순한 대체재가 아니라 오히려 더 강력하다고 설명한다. 모델이 여러 도구에 걸쳐 식별자를 조합하고 추론하며, 단계 사이에 직접 넘겨줄 수 있기 때문이다. 전송 계층 메타데이터에 숨어 있던 세션 상태와 달리, 이 식별자는 모델에게 그대로 보인다.
서버가 호출 도중 클라이언트에 되묻는 흐름(엘리시테이션 등)도 재구성됐다. 서버가 먼저 요청을 보내는 것은 클라이언트 요청을 실제로 처리하는 동안에만 허용되도록 못박았고, 이 요청은 SSE 스트림을 계속 열어 두는 대신 InputRequiredResult를 돌려주는 방식으로 바뀌었다. 클라이언트는 사용자의 답을 모아 원래 호출을 requestState 값과 함께 다시 보내며, 이 재시도 역시 어떤 서버 인스턴스든 받을 수 있다.
헤더 하나로 라우팅·캐싱·추적까지 정리됐다
세션이 사라진 트래픽을 실제로 운영하기 쉽게 만드는 장치도 함께 들어왔다. Streamable HTTP 전송은 이제 Mcp-Method와 Mcp-Name 헤더를 반드시 붙이도록 요구한다. 로드밸런서·게이트웨이·레이트리미터가 요청 본문을 열어 보지 않고도 헤더만으로 어떤 작업인지 알고 라우팅할 수 있다는 뜻이다. 헤더와 본문 내용이 다르면 서버가 요청을 거부한다.
목록 조회나 리소스 읽기 결과에는 HTTP의 Cache-Control을 본뜬 ttlMs와 cacheScope가 붙는다. 클라이언트는 tools/list 응답이 얼마나 오래 유효한지, 사용자 사이에 공유해도 되는지를 정확히 알 수 있고, 목록 변경 여부를 확인하려고 SSE 스트림을 계속 열어 둘 필요도 없어졌다. W3C Trace Context 규격의 traceparent, tracestate, baggage 키 이름도 _meta 안에 문서로 고정됐다. 여러 SDK와 도구가 이미 이렇게 하고 있었는데, 키 이름이 스펙에 못박히면서 호스트 애플리케이션에서 시작한 추적이 클라이언트 SDK와 MCP 서버, 그 뒤의 다운스트림 호출까지 하나의 스팬 트리로 이어져 보이게 된다.
MCP Apps와 Tasks, 확장 기능으로 자리를 옮긴 것들
2025-11-25에 있었지만 정식 절차가 없던 확장(Extensions)도 이번에 격식을 갖췄다. 확장은 역방향 DNS ID로 식별되고, 클라이언트·서버 기능에 있는 extensions 맵으로 협상되며, 별도 관리자가 있는 ext-* 저장소에서 스펙과 독립적으로 버전이 올라간다. 이번 릴리스에는 공식 확장 두 개가 새로 들어왔다. MCP Apps는 서버가 대화형 HTML 인터페이스를 만들어 호스트가 샌드박스 iframe에서 렌더링하게 해 주는 확장으로, 도구가 UI 템플릿을 미리 선언해 두면 호스트가 실행 전에 미리 가져오고 캐시하고 보안 검토를 할 수 있다. Tasks는 2025-11-25에 실험적 핵심 기능으로 나왔다가, 실제 운영에서 드러난 재설계 필요성 때문에 이번에 확장으로 옮겨졌다. 서버가 tools/call 응답으로 작업 핸들을 돌려주면 클라이언트가 tasks/get, tasks/update, tasks/cancel로 진행 상황을 다룬다. 세션 없이는 안전하게 범위를 좁힐 수 없는 tasks/list는 아예 제거됐다.
인증도 OAuth·OpenID Connect 실제 배포 방식에 맞춰졌다
인증 스펙을 강화하는 여섯 건의 변경도 함께 들어왔다. 클라이언트는 이제 인가 서버 응답의 iss 파라미터를 RFC 9207에 따라 검증해야 하며, 이후 버전에서는 iss가 없는 응답 자체를 거부하도록 강제될 예정이다. 동적 클라이언트 등록 시에는 OpenID Connect의 application_type을 함께 선언하게 해, 인가 서버가 데스크톱·CLI 클라이언트를 웹 클라이언트로 오인해 localhost 리다이렉트 URI를 거부하는 흔한 문제를 막는다. 등록한 자격 증명은 발급한 인가 서버의 issuer에 묶어 두고, 리소스가 다른 인가 서버로 옮겨 가면 다시 등록하도록 했다.
없어지는 게 아니라 물러나는 기능들
새로 생긴 기능 수명 주기 정책에 따라 Roots, Sampling, Logging 세 기능은 이번에 사용 중단(deprecated) 표시가 붙었다. 표시만 붙을 뿐 이번 릴리스와 이후 1년 안에 나오는 모든 스펙 버전에서는 그대로 동작하며, 실제로 제거하려면 별도의 절차를 다시 거쳐야 한다. 사용 중단과 제거 가능 시점 사이에는 최소 12개월을 두도록 정책에 못박혀 있다.
같은 릴리스에서 도구의 inputSchema와 outputSchema는 JSON Schema 2020-12 전체 사양으로 올라갔다. 입력 스키마는 최상위 type을 여전히 object로 고정하지만 oneOf, anyOf, allOf 같은 조합과 조건부 스키마, $ref·$defs 참조를 쓸 수 있다. 출력 스키마 제약은 아예 없어져 structuredContent가 객체가 아닌 임의의 JSON 값이어도 된다. 리소스가 없을 때 돌려주는 오류 코드도 MCP 전용이던 -32002에서 JSON-RPC 표준인 -32602(Invalid Params)로 바뀌었다.
최종 스펙까지 남은 일정
이번 릴리스 후보는 5월 21일 자로 고정됐고, 최종 스펙은 7월 28일에 나온다. 이 기간은 SDK 메인테이너와 클라이언트 구현체가 실제 워크로드로 변경 사항을 검증하는 시간이며, 1등급 SDK는 이 안에 지원을 갖춰야 한다.
새로 생긴 기능 수명 주기 정책과 확장 체계, 그리고 표준 트랙 SEP이 정합성 검사 스위트에서 시나리오를 통과해야만 Final 상태에 오를 수 있게 한 규정까지 더해지면서, 이번처럼 큰 폭의 하위 호환성 깨짐은 당분간 다시 없을 것이라는 게 메인테이너들의 설명이다. 2026-07-28을 기준으로 구현한 팀은 앞으로 나올 개정판에서 전송 계층이나 라이프사이클 코드를 다시 쓰지 않아도 될 것으로 기대된다.
출처: Model Context Protocol Blog, The 2026-07-28 MCP Specification Release Candidate (2026-08-16 확인)