【파괴적 변경】 MCP에서 '세션'이 사라진다! 7월 28일 신규 사양으로 인해 발생하는 문제와 지금 해야 할 준비 완전 가이드

MCP 역사상 최대의 파괴적 변경(Breaking Change)이 다가온다.

2026년 7월 28일, Model Context Protocol (MCP)의 신규 사양이 확정된다. 이미 출시 후보(RC)는 락(Lock)이 완료된 상태다. 그리고 이번 변경은 지금까지의 마이너 업데이트와는 차원이 다르다.

initialize 핸드셰이크가 사라진다 -
Mcp-Session-Id 헤더가 사라진다 -
Sampling · Roots · Logging이 비권장(Deprecated) 처리된다

즉, 현재 작동 중인 MCP 서버의 '방식'이 근본적으로 바뀐다. 이 기사에서는 무엇이 바뀌는지, 왜 바뀌는지, 그리고 지금 무엇을 해야 하는지 전부 해설한다.

MCP는 '스테이트리스(Stateless)'가 된다. 세션 관리가 프로토콜(Protocol) 레이어에서 소멸하여, 일반적인 HTTP 인프라(로드 밸런서 + 다중 인스턴스)에서 그대로 스케일링(Scale)할 수 있게 된다. 대신 상태가 필요하다면 '핸들(Handle)'을 명시적으로 전달하는 설계로 이행한다.

공식 SDK (Tier 1)는 사양 확정 후 10주 이내에 대응할 예정이다. 비권장 기능은 12개월의 유예 기간 후에 삭제된다. 당장 바로 망가지는 것은 아니지만, 이행 계획은 지금부터 세워야 한다.

Before (현행: 2025-11-25 사양)

Client → Server: initialize (protocolVersion, clientInfo...)
Server → Client: initialize result (capabilities...)
Client → Server: initialized 통지
...

After (2026-07-28 사양)

Client → Server: tools/call (_meta에 버전과 클라이언트 정보를 동봉)

갑자기 본론인 요청(Request)을 던질 수 있다. 프로토콜 버전과 클라이언트 정보는 매 요청의 _meta에 포함된다. 왕복 3회의 의식(Ceremony)이 사라지므로 콜드 스타트(Cold Start)도 빨라진다.

Mcp-Session-Id 헤더와 프로토콜 레벨의 세션이 완전히 삭제된다.

이것이 무엇을 의미할까?

Before: 세션을 가진 서버는 '동일한 인스턴스'로 계속 요청을 보내야 했다 (Sticky Routing). Kubernetes에서 스케일링하려면 세션 어피니티(Session Affinity) 설정이 필수였으며, 인스턴스가 죽으면 세션도 함께 사라졌다.

After: 어떤 인스턴스가 요청을 받아도 상관없다. 라운드 로빈(Round Robin) 방식의 로드 밸런서 뒤에 배치하는 것만으로 스케일링이 가능하다.

"그럼 상태가 필요한 처리는 어떻게 하나요?" → **명시적인 핸들(Handle)**을 사용한다. 예를 들어 모델이 create_basket을 호출하여 ID를 받고, 이후의 툴 호출 시 그 ID를 인수로 전달한다. 상태는 프로토콜이 아니라 애플리케이션의 책임이 된다.

영구적인 SSE 스트림을 통해 서버에서 요청을 보내는 방식을 버리고, InputRequiredResult를 통해 클라이언트에게 "입력이 필요하다"라고 반환하는 방식으로 바뀐다. 스테이트리스화의 핵심이다.

Mcp-Method와 Mcp-Name 헤더가 추가되어, API 게이트웨이가 바디(Body)를 파싱하지 않고도 라우팅할 수 있게 된다. 엔터프라이즈 인프라 팀이 환호할 만한 변경이다.

ttlMs와 cacheScope로 툴 결과의 캐시(Cache)를 제어할 수 있다. 동일한 list_files를 반복해서 실행하며 토큰을 낭비하는 시대가 끝날지도 모른다.

이 부분이 가장 큰 영향을 받는 사람들도 있을 것이다. 다음 3가지는 정식으로 Deprecated(비권장) 처리된다.

기능	대체 수단
Roots	툴 파라미터 또는 리소스 URI로 전달
Sampling	LLM 프로바이더의 API를 직접 호출
Logging	stdio라면 stderr, 구조화하고 싶다면 OpenTelemetry

12개월 동안은 계속 작동하지만, 신규 개발에서 사용하는 것은 지양하는 것이 좋다.

특히 Sampling (서버 측에서 클라이언트의 LLM에 추론을 의뢰하는 기능)을 사용한 '재귀적 에이전트(Recursive Agent)' 패턴을 구축했던 사람들은 아키텍처 재검토가 필요하다.

파괴적인 변화만 있는 것은 아니다. Extensions 프레임워크 (SEP-2133)가 도입되며, 공식 확장 기능이 2개 출시될 예정이다.

서버가 **인터랙티브 HTML UI (Interactive HTML UI)**를 전달하고, 호스트가 샌드박스화된 iframe에서 렌더링한다.

• 도구가 UI 템플릿을 사전 선언 → 호스트가 prefetch(사전 가져오기)·캐시·보안 리뷰 (Security Review) 가능
• UI 상의 조작도 직접적인 도구 호출과 **동일한 감사 경로 (Audit Path)**를 통과

「ChatGPT Apps vs MCP Apps」의 구도가 드디어 선명해졌다. 채팅 UI 안에 앱이 거주하는 시대다.

2025-11-25에 실험적으로 도입된 Tasks는, 실전 투입의 지견을 바탕으로 확장 기능 (Extensions)으로서 재설계되었다.

Client: tools/call → Server: 태스크 핸들(Task Handle)을 즉시 반환
Client: tasks/get으로 폴링 (Polling)
Client: tasks/update / tasks/cancel로 제어

스테이트리스 (Stateless) 모델과 일치하는 형태가 되었으므로, "30분이 걸리는 데이터 처리를 MCP를 통해 던지는" 것과 같은 유스케이스가 정식으로 지원된다. 실험적 API를 사용하던 사람은 새로운 라이프사이클 (Lifecycle)로의 이행이 필수적이다.

보안 관련 변경 사항도 많다. 중요한 것만 정리하면:

• SEP-2468: 클라이언트는 iss 파라미터 검증이 필수가 됨 (RFC 9207 준수). 인가 서버 (Authorization Server)의 사칭 방지
• SEP-2352: 크리덴셜 (Credential)이 발행처 서버에 바인딩됨. 리소스가 이전되면 재등록 필요
• SEP-837: Dynamic Client Registration을 통해 OpenID Connect의 application_type을 선언

작년부터 이어진 「MCP 서버를 통한 인증 정보 유출」 사건들을 고려하면, 이러한 하드닝 (Hardening, 보안 강화)은 필연적인 흐름이다.

2026-05-21 RC 락(Lock) 완료 ← 현재 (검증 기간 중)
2026-07-28 사양 확정
+10주 후 Tier 1 SDK 대응 완료 예상
...

• 세션 의존성 확인: Mcp-Session-Id에 의존한 상태 관리(State Management)를 하고 있는가? → 핸들 기반 설계로의 이행을 계획할 것
• Sampling / Roots / Logging 사용처 파악: 대체 수단으로 전환
• Tasks 실험적 API를 사용 중이라면: 새로운 라이프사이클로의 이행 준비
• 도구 스키마 (Tool Schema) 재검토: JSON Schema 2020-12를 풀 지원 ( oneOf / anyOf / $ref 사용 가능! SEP-2106)하므로, 억지로 평탄화(Flatten)했던 스키마를 자연스러운 형태로 되돌릴 수 있음
• SDK 버전 추적: 사양 확정 후 10주 동안은 SDK의 움직임을 주시

기본적으로는 SDK와 호스트 앱의 업데이트를 기다리면 된다. 단, 자체 제작한 MCP 서버를 사내에 배포하고 있는 경우에는 위의 체크리스트가 본인의 문제가 된다.

답은 간단하다. MCP가 「실험」에서 「인프라」가 되었기 때문이다.

세션 중심의 설계는 로컬의 stdio로 Claude Desktop에 연결하는 수준에서는 문제가 없었다. 하지만 기업이 수천 명 규모로 MCP 게이트웨이를 운영하기 시작하면, 스티키 라우팅 (Sticky Routing)은 운영상의 악몽이 된다.

주목해야 할 문구는 이것이다:

Breaking changes: This release only; future versions designed for backward compatibility

즉, "파괴적 변경은 이번이 마지막이다. 여기서 토대를 바로잡고, 이후부터는 하위 호환성 (Backward Compatibility)을 유지하겠다"라는 선언이다. 신기능은 우선 Extensions로서 출시하고, 안정화된 후에 사양으로 편입시키는 거버넌스 (Governance, SEP-2484)도 갖춰졌다. 이는 성숙한 프로토콜의 전형적인 행보이다.

• 7월 28일, MCP는 스테이트리스 (Stateless)가 된다. initialize와 세션 ID도 사라진다.
• Sampling / Roots / Logging은 권장되지 않음 (Deprecated). 12개월 이내에 이행할 것.
• MCP Apps에서 서버가 UI를 갖고, Tasks를 통해 장시간 처리가 정식 지원됨. 인가는 RFC 9207 준수 등으로 대폭 강화.
• 파괴적 변경은 이번이 마지막이 되는 설계 방침.

"돌아가니까 괜찮아"라며 방치하다가는, 1년 뒤에 갑자기 작동을 멈추는 MCP 서버가 양산될 것이라는 예감이 든다. 반대로 말하면, 지금 이 RC 기간에 따라가고 있다면 에코시스템의 최전선에 설 수 있다는 뜻이다.

이 글이 도움이 되었다면, 좋아요👍와 저장📌를 부탁드립니다!

여러분의 MCP 서버는 세션 (Session)에 의존하고 있나요? 이전 과정에서의 고민이나 지식이 있다면 꼭 댓글로 알려주세요. 다음번에는 MCP Apps 구현 핸즈온 (Hands-on)을 작성할 예정입니다!

2026-07-28 MCP 사양 출시 후보 (Release Candidate) | Model Context Protocol Blog

2026 MCP 로드맵 (Roadmap) | Model Context Protocol Blog

MCP 사양 (초안) (MCP Specification (Draft))

MCP 사양 변경 이력 (MCP Specification Changelog)