다음 MCP 사양은 단순한 정기 버전 업데이트가 아닙니다. 2026-07-28 출시 후보(release candidate) 버전은 프로토콜 레벨의 세션(session)을 제거하고, 일급 객체로서의 확장(extensions) 및 작업(tasks)을 추가하며, 캐싱(caching)과 추적 컨텍스트(trace context)를 공식화하고, 지원 중단(deprecated) 예정 기능의 라이프사이클(lifecycle)을 강화합니다.

최종 사양은 2026년 7월 28일로 예정되어 있습니다. 만약 귀하가 MCP 클라이언트, 서버, 게이트웨이 또는 코딩 에이전트(coding-agent) 통합을 유지 관리하고 있다면, 유용한 질문은 "언제 업그레이드해야 하는가?"가 아니라 "내 스택의 어떤 가정들이 곧 유효하지 않게 될 것인가?"입니다.

이것은 공식 출시 후보 버전을 기반으로 한 실질적인 마이그레이션 체크리스트이며, 모든 SDK가 이미 이를 채택했다는 주장이 아닙니다.

출시 후보에서 변경되는 사항

이 후보 버전은 여전히 출시 후보(release candidate)입니다. 최종 사양과 귀하의 SDK 지원 매트릭스를 호환성 권위로 간주하십시오.

1. 의도치 않은 세션 상태 제거

가장 큰 운영상의 변화는 프로토콜 레벨의 세션과 Mcp-Session-Id 헤더의 제거입니다. 원격 서버는 이전 MCP 핸드셰이크가 발생했다는 이유로 요청이 동일한 프로세스로 돌아올 것에 더 이상 의존해서는 안 됩니다.

이것이 귀하의 애플리케이션이 상태(state)를 가질 수 없다는 것을 의미하는 것은 아닙니다. 이는 애플리케이션 상태가 프로토콜 연결 내부에 숨겨지는 대신 명시적이어야 함을 의미합니다.

다음 사항들을 감사(Audit)하십시오:

• 세션 ID로만 키가 지정된 인메모리 맵(in-memory maps);
• 로드 밸런서(load balancer)의 스티키 세션(sticky-session) 요구 사항;
• 프로세스 로컬 기능(process-local capabilities)을 채우는 초기화 코드;
• 비즈니스 상태(business-state) 정리를 수행하는 연결 정리(connection cleanup) 작업;
• 핸드셰이크를 한 번만 보내고 암시적인 서버 세션을 재사용하는 테스트.

더 안전한 형태는 요청이 애플리케이션에 실제로 필요한 식별 정보를 전달하도록 만드는 것입니다:

from dataclasses import dataclass

@dataclass
...

이 컨텍스트를 인증 계층(auth layer), 작업 저장소(task store) 또는 트레이스 시스템(trace system)에 유지하세요. 새로운 이름으로 프로토콜 세션 어피니티(protocol session affinity)를 다시 생성하지 마십시오.

2. 게이트웨이를 단순하게(boring) 만드세요

상태가 없는(Stateless) MCP는 에지(edge)가 요청을 일반적인 라우팅 가능한 트래픽(routable traffic)으로 취급할 수 있을 때만 가치가 있습니다. 로드 밸런서(load balancer)를 변경하기 전에, 모든 인스턴스가 다음 사항들을 처리할 수 있는지 테스트하십시오:

1. 새로운 요청;
2. 다른 인스턴스가 이전 요청을 처리한 후의 요청;
3. 타임아웃(timeout) 후의 재시도(retry);
4. 프로세스 로컬 워밍업(process-local warm-up)이 없는 요청;
5. 백엔드 작업이 여전히 비동기적으로 실행 중인 요청.

프로토콜 메서드(protocol method), MCP 이름, 요청 ID(request ID), 서버 인스턴스, 테넌트(tenant), 트레이스 ID(trace ID)를 로그로 남기십시오. API 키, 토큰 또는 사용자 콘텐츠를 라우팅 헤더(routing headers)에 절대 포함하지 마십시오. 헤더는 프록시(proxies), 액세스 로그(access logs) 및 텔레메트리 시스템(telemetry systems)에 노출됩니다.

3. 단순한 캐시가 아닌 캐시 정책을 추가하세요

후보자의 ttlMs 및 cacheScope 필드는 캐싱을 검사 가능하게 만들지만, 데이터의 재사용이 안전한지 여부를 결정하지는 않습니다.

모든 목록(list) 또는 리소스 읽기 작업에 대해 다음 질문에 답하십시오:

• 결과가 공개(public), 테넌트 범위(tenant-scoped), 사용자 범위(user-scoped) 또는 실행 범위(run-scoped) 중 무엇입니까?
• 어떤 이벤트가 이를 무효화(invalidate)합니까?
• 이 도구에 오래된 데이터(stale data)가 허용됩니까?
• 캐시 키(cache key)에 전체 권한 범위(authorization scope)를 포함할 수 있습니까?
• 에이전트가 캐시된 결과를 실시간 확인(live check)으로 오해하지 않겠습니까?

유용한 기본 설정은 수명이 짧고 범위가 제한된(short-lived and scope-bound) 방식입니다. 이슈 상태, 권한 또는 배포 상태보다 캐시 문서 및 불변 메타데이터(immutable metadata)를 더 공격적으로 캐싱하십시오.

4. 엔드 투 엔드(end to end)로 트레이스 컨텍스트를 연결하세요

_meta에서 traceparent, tracestate 및 baggage를 전파(propagating)하는 것은 시스템이 전체 작업에 걸쳐 하나의 트레이스(trace)를 유지할 때만 유용합니다:

에이전트 실행(agent run) -> 모델 호출(model call) -> MCP 게이트웨이(MCP gateway) -> MCP 서버(MCP server) -> 데이터베이스/API(database/API) -> 도구 결과(tool result)

최소한 지연 시간(latency), 재시도 횟수(retry count), 권한 결정(authorization decision), 도구 이름, 결과 크기 및 실패 클래스(failure class)를 기록하십시오. 메타데이터를 내보내기 전에 비밀 정보(secrets)를 삭제(redact)하십시오. 이는 코딩 에이전트(coding agents)에게 특히 중요한데,

Zira의 코딩 에이전트를 위한 관측성 (observability for coding agents)에 관한 이전 가이드는 더 광범위한 계측 (instrumentation) 트레이드오프를 다룹니다. MCP 트레이스 컨텍스트 (trace context)는 이러한 계측이 프로토콜 레벨에서 이동할 수 있는 위치를 제공합니다.

5. 작업을 제한이 있는 리소스로 취급하십시오

작업 (Tasks)은 HTTP 요청을 계속 열어두는 것보다 장기 실행 작업 (long-running work)에 더 적합하지만, 생명주기 (lifecycle) 및 용량 (capacity) 문제를 야기합니다. 다음 사항을 정의하십시오:

• 누가 작업을 생성할 수 있는가;
• 최대 실행 시간 및 큐 깊이 (queue depth);
• 폴링 (polling) 또는 알림 (notification) 정책;
• 취소 의미론 (cancellation semantics);
• 보존 및 삭제 규칙;
• 클라이언트 재시도 후의 멱등성 (idempotency) 동작;
• 작업이 대기 중인 동안 에이전트가 수행할 수 있는 권한.

"비동기 (async)"가 "무제한 (unbounded)"이 되게 하지 마십시오. 도구를 호출하거나, 빌드를 시작하거나, 리포지토리에 접근하는 작업은 동기식 호출 (synchronous call)과 동일한 승인 및 샌드박스 (sandbox) 정책이 필요합니다.

6. 확장 기능과 지원 중단(deprecation)을 명시적으로 검증하십시오

릴리스 후보 (release candidate)는 확장 기능 (extensions)을 일급 객체 (first-class)로 만들고 공식적인 지원 중단 (deprecation) 정책을 도입합니다. 이는 문서화되지 않은 동작에 암묵적으로 의존하는 것보다 더 건강한 방식이지만, 이는 기능 협상 (capability negotiation)이 테스트에 포함되어야 함을 의미합니다.

각 클라이언트/서버 쌍에 대해 호환성 매트릭스 (compatibility matrix)를 작성하십시오:

• 협상된 프로토콜 버전;
• 지원되는 확장 기능 ID 및 버전;
• 작업 (Tasks) 지원 여부;
• 해당되는 경우 앱 (Apps) 지원 여부;
• 전송 (transport) 지원 여부;
• 지원 중단된 기능 (deprecated feature) 사용 여부;
• 기능이 누락되었을 때의 폴백 (fallback) 동작.

배포하는 정확한 SDK 버전을 대상으로 CI에서 실행하십시오. SDK가 후보 버전을 채택하는 속도가 다르기 때문에, 이전의 확정된 사양 (finalized specification)이 계속 사용될 수 있습니다.

72시간 마이그레이션 계획

오늘: 세션 인벤토리, 라우팅 (routing), 캐시 (cache), 트레이스 (trace), 작업 (task), 그리고 지원 중단된 기능 (deprecated-feature)에 대한 가정을 정리하십시오. 현재 SDK 버전을 고정하고 대표적인 요청 픽스처 (request fixtures)를 저장하십시오.

다음 단계: 비-스티키(non-sticky) 로드 밸런서(load balancer) 뒤에서 두 개의 인스턴스로 구성된 서버를 실행하십시오. 기능 누락(missing capabilities), 만료된 작업(expired tasks), 권한이 없는 스코프(unauthorized scopes), 중복 재시도(duplicate retries), 그리고 오래된 캐시 엔트리(stale cache entries)에 대한 부정 테스트(negative tests)를 추가하십시오.

7월 28일 이전: 최종 사양(specification)을 읽고, 사용 중인 SDK의 릴리스 노트(release notes)를 확인하며, 위험도가 낮은 서버 하나를 카나리(canary) 테스트하십시오. 클라이언트들이 전환될 때까지 이전의 확정된 버전에 대한 롤백(rollback) 지원을 유지하십시오.

실질적인 시사점 (The practical takeaway)

MCP 2026-07-28은 모든 상태 저장소(state store)를 삭제해야 하는 이유가 아니라, 확장(scaling)을 위한 기회입니다. 숨겨진 프로토콜 결합(protocol coupling)을 제거하고, 애플리케이션 상태(application state)를 명시적으로 만들며, 캐시를 권한 스코프(authorization scope)에 바인딩하고, 트레이스(traces)를 전파하며, 비동기 작업(asynchronous work)에 대해 엄격한 제한(hard limits)을 설정하십시오.

안전하게 마이그레이션하는 팀은 단순히 해피 패스(happy-path) 도구 호출만을 테스트하는 것이 아니라, 프로토콜의 경계(boundaries)를 테스트하는 팀이 될 것입니다.

만약 당신이 오늘 MCP 서버를 유지 관리하고 있다면, 다음 중 제거하기 가장 어려운 가정은 무엇입니까: 스티키 세션(sticky sessions), 캐시 스코프(cache scope), 트레이스 전파(trace propagation), 또는 장기 실행 작업 제어(long-running task control)?

출처 (Sources)

• MCP 2026-07-28 Specification Release Candidate
• MCP 2026-07-28 RC on GitHub
• MCP draft specification
• MCP changelog