MCP 2026-07-28 사양 업데이트, Stateless Protocol Core와 주요 변화 정리

MCP(Model Context Protocol)가 2026년 7월 28일 새로운 사양을 공개했습니다. 이번 업데이트에서 가장 눈에 띄는 변화는 MCP의 핵심 프로토콜 구조가 기존의 상태 기반 통신 방식에서 Stateless Request/Response 방식으로 전환됐다는 점입니다.

이와 함께 서버와 클라이언트 사이의 요청 처리 방식도 달라졌습니다. Multi Round-Trip Requests(MRTR)가 도입됐고, HTTP 헤더 기반 라우팅, List 결과 캐싱, 인증 보안 강화, Extensions 프레임워크 정식화 등이 함께 이뤄졌습니다.

기존 MCP 구현을 사용하고 있다면 단순히 새로운 기능이 추가된 버전으로 보기 어렵습니다. initialize/initialized 교환과 Mcp-Session-Id가 제거됐으며, 일부 기존 기능은 Deprecated로 전환됐기 때문입니다.

이번 글에서는 MCP 2026-07-28 사양에서 달라진 핵심 내용을 중심으로 Stateless 구조부터 MRTR, 라우팅, 캐싱, 인증, Tasks, SDK 업데이트까지 주요 변화를 정리합니다.

반응형

MCP 2026-07-28 사양에서 가장 크게 달라진 점

이번 사양의 핵심은 MCP가 상태를 유지하는 양방향 프로토콜에서 Stateless Request/Response 프로토콜로 전환됐다는 것입니다.

기존 MCP는 초기화 과정과 세션 식별자를 기반으로 통신하는 구조를 사용했습니다. 하지만 새로운 사양에서는 프로토콜 수준의 세션을 제거했습니다.

이에 따라 다음과 같은 변화가 발생했습니다.

• initialize/initialized 교환 제거
• Mcp-Session-Id 헤더 제거
• 각 요청에 프로토콜 버전, 클라이언트 정보, capabilities 포함
• 필요한 경우 server/discover RPC를 통해 서버 capabilities 확인
• 별도의 공유 저장소 없이 여러 서버 인스턴스에 요청 분산 가능

결과적으로 MCP 서버는 특정 세션에 요청이 묶이지 않아도 됩니다.

예를 들어 여러 MCP 서버 인스턴스가 로드 밸런서 뒤에 있다면 요청마다 특정 서버 인스턴스에 연결된 세션을 찾을 필요 없이 일반적인 Round-Robin 방식으로 요청을 전달할 수 있습니다.

이는 MCP 서버를 확장하는 과정에서 중요한 변화입니다.

Handshake와 Session이 사라진 Stateless MCP

새로운 사양에서는 기존의 initialize/initialized 교환이 공식적으로 제거됐습니다.

또한 MCP 세션을 식별하기 위해 사용하던 Mcp-Session-Id 헤더도 없어졌습니다.

이제 요청은 독립적으로 처리될 수 있으며, 각각의 요청에는 프로토콜 버전과 클라이언트 정보, capabilities 등이 포함됩니다.

서버의 기능을 먼저 확인하고 싶은 클라이언트라면 선택적으로 server/discover RPC를 사용할 수 있습니다. 다만 이 과정 자체가 필수는 아닙니다.

핵심은 모든 요청이 자체적으로 필요한 정보를 갖고 이동할 수 있다는 점입니다.

따라서 특정 요청이 반드시 동일한 서버 인스턴스로 전달되어야 하는 구조적 제약이 줄어듭니다.

애플리케이션 상태까지 없어진 것은 아니다

여기서 주의할 부분이 있습니다.

Stateless Protocol Core가 적용됐다고 해서 애플리케이션에서 상태를 사용할 수 없다는 의미는 아닙니다.

서버가 여러 호출에 걸쳐 상태를 유지해야 한다면 도구 호출을 통해 명시적인 핸들을 발급하고, 이후 모델이 해당 핸들을 다음 호출의 인자로 전달하도록 구성할 수 있습니다.

즉, 상태를 프로토콜 내부의 숨겨진 세션에 저장하는 방식에서 벗어나 모델이 확인하고 전달할 수 있는 명시적인 상태 핸들을 활용하는 방식으로 전환할 수 있습니다.

이 차이는 상당히 중요합니다.

프로토콜이 상태를 몰래 관리하는 것이 아니라, 필요한 상태를 애플리케이션 수준에서 명시적으로 관리할 수 있기 때문입니다.

Multi Round-Trip Requests, MRTR 도입

Stateless 구조로 변경되면서 또 하나의 중요한 변화가 등장했습니다. 바로 Multi Round-Trip Requests(MRTR)입니다.

기존에는 서버가 작업 중 사용자에게 추가 정보를 요청하거나 클라이언트에 특정 작업을 요청하기 위해 연결을 계속 유지해야 하는 경우가 있었습니다.

예를 들어 도구를 실행하는 과정에서 사용자 확인이 필요하거나, 누락된 파라미터를 다시 받아야 하는 상황을 생각할 수 있습니다.

새로운 MRTR 방식에서는 이런 과정을 열린 양방향 스트림에 의존하지 않고 여러 번의 요청과 응답으로 처리합니다.

흐름을 단순화하면 다음과 같습니다.

도구 호출 → 추가 입력 필요 → input_required 반환 → 클라이언트가 응답 → 원래 요청 재시도

서버는 필요한 요청과 함께 resultType: "input_required"를 반환할 수 있습니다.

클라이언트가 필요한 답변을 전달하면 원래 호출을 다시 요청하고, 답변은 inputResponses에 포함합니다.

이 방식은 Stateless 프로토콜에서도 서버와 클라이언트 사이에 추가적인 상호작용을 구현할 수 있도록 합니다.

기존처럼 연결을 계속 열어둬야 하는 방식에서 벗어난다는 점이 핵심입니다.

HTTP 헤더 기반 라우팅으로 인프라 활용성 강화

새로운 MCP 사양에서는 Streamable HTTP 요청에 Mcp-Method와 Mcp-Name 헤더가 포함돼야 합니다.

예를 들어 도구 호출 요청이라면 다음과 같이 요청 정보를 HTTP 헤더에서 확인할 수 있습니다.

Mcp-Method: tools/call
Mcp-Name: search

이 변화는 MCP 서버 자체뿐만 아니라 MCP 앞단에 위치한 인프라에도 영향을 줍니다.

기존에는 Gateway나 WAF 등이 요청의 실제 내용을 확인하기 위해 JSON Body를 파싱해야 할 수 있었습니다.

하지만 메서드와 도구 이름이 HTTP 헤더에 포함되면 Gateway, Rate Limiter, WAF 등이 해당 정보를 기준으로 요청을 처리할 수 있습니다.

예를 들어 다음과 같은 작업이 가능해집니다.

• 특정 MCP 도구별 라우팅
• 도구별 요청량 측정
• 도구별 Rate Limit 적용
• WAF 정책 구성
• Gateway에서 요청 유형에 따른 처리

결국 MCP 요청을 기존 HTTP 인프라에서 보다 직접적으로 다룰 수 있는 구조가 됩니다.

List 결과에 캐싱 적용

이번 사양에서는 MCP의 여러 List 및 Read 응답에 캐싱을 위한 정보도 추가됐습니다.

대상에는 다음 요청이 포함됩니다.

• tools/list
• prompts/list
• resources/list
• resources/read

이 응답에는 ttlMs와 cacheScope가 포함될 수 있습니다.

이를 통해 클라이언트는 해당 결과를 얼마나 오래 캐시할 수 있는지, 어떤 범위에서 캐시해야 하는지 판단할 수 있습니다.

MCP 클라이언트가 서버에 연결할 때마다 동일한 도구 목록이나 리소스 정보를 반복해서 가져와야 한다면 불필요한 요청이 발생할 수 있습니다.

캐시 정보를 활용하면 이런 반복적인 조회를 줄이고, MCP 서버와 상위 시스템 사이의 요청 부담도 줄일 수 있습니다.

특히 새로운 사양의 Stateless 구조에서는 재연결이나 서버 인스턴스 변경이 보다 자연스러워지기 때문에 캐시 가능한 List 결과는 전체 구조와도 잘 맞는 변화라고 볼 수 있습니다.

MCP 인증과 보안도 강화

이번 사양에서는 인증 관련 변경도 상당한 비중을 차지합니다.

MCP 구현에서 인증은 실제 통합 과정에서 많은 시간이 필요한 영역으로 언급됐으며, 이번 업데이트에서는 OAuth 기반 인증과 관련된 보안 구조가 강화됐습니다.

RFC 9207 기반 Issuer 검증

Authorization Server는 RFC 9207에 따라 iss 파라미터를 반환해야 하며, 클라이언트는 코드를 교환하기 전에 해당 값을 검증해야 합니다.

이를 통해 잘못된 Authorization Server가 사용되는 문제를 방지하는 방향으로 인증 구조가 강화됐습니다.

DCR에서 CIMD로 이동

이번 사양에서는 Dynamic Client Registration(DCR)에서 Client ID Metadata Documents(CIMD)로 이동하는 방향도 공식화됐습니다.

DCR은 기존 호환성을 위해 계속 동작하지만, 새로운 표준에서는 Deprecated됐으며 향후 MCP 사양에서 제거될 예정입니다.

따라서 새로운 MCP 구현을 설계하는 경우에는 기존 DCR에만 의존하기보다 CIMD 방향을 함께 고려해야 합니다.

Credential의 Issuer 종속성 강화

클라이언트 자격 증명은 이를 발급한 Issuer에 연결됩니다.

따라서 하나의 Authorization Server에서 발급된 credential을 다른 Authorization Server에서 재사용할 수 없도록 하는 방향으로 보안이 강화됐습니다.

이번 인증 변경의 핵심은 단순히 새로운 인증 방식을 추가하는 것이 아니라 Authorization Server의 신뢰 관계와 credential 사용 범위를 보다 명확하게 만드는 것입니다.

Tasks는 Extension으로 이동

Tasks도 이번 사양에서 구조적인 변화가 있습니다.

기존에는 실험적인 Core 기능에 포함돼 있었지만, 이제는 io.modelcontextprotocol/tasks Extension으로 이동합니다.

새로운 Tasks Extension에서는 다음과 같은 기능이 제공됩니다.

• tasks/get
• tasks/update

또한 변경 알림을 전달하는 방식도 변경됩니다.

기존 HTTP GET Endpoint 방식에서 벗어나 클라이언트가 알림 유형별로 선택적으로 참여할 수 있는 subscriptions/listen 스트림을 사용하도록 변경됩니다.

이번 변화는 MCP가 핵심 프로토콜과 확장 기능을 보다 명확하게 구분하는 방향으로 발전하고 있다는 점에서도 의미가 있습니다.

Extensions 프레임워크가 정식화

MCP 2026-07-28에서는 Extensions를 위한 공식적인 프레임워크도 정리됐습니다.

Tasks가 Extension으로 이동했고, MCP Apps와 Enterprise Managed Authorization(EMA) 같은 다른 확장 기능들과 함께 관리되는 구조가 마련됐습니다.

이러한 변화는 MCP Core에 모든 기능을 계속 추가하는 대신, 특정 사용 사례나 고급 기능을 Extension으로 분리할 수 있는 기반을 마련한다는 데 의미가 있습니다.

즉, MCP의 기본 프로토콜은 보다 명확하게 유지하면서 필요한 기능을 확장 구조로 제공할 수 있는 방향입니다.

Deprecated 기능은 무엇인가

기존 MCP 구현을 운영하고 있다면 이번 업데이트에서 Deprecated된 기능도 확인해야 합니다.

이번 사양에서는 다음 기능이 Deprecated됐습니다.

• Roots
• Sampling
• Logging
• Legacy HTTP+SSE transport

중요한 점은 Deprecated가 곧바로 제거를 의미하지 않는다는 것입니다.

해당 기능은 계속 동작하며 최소 12개월의 유예 기간이 제공됩니다.

특히 MCP는 이번 사양에서 공식적인 deprecation policy를 마련했으며, 최소 12개월의 기간을 보장하는 방향으로 변경됐습니다.

따라서 기존 구현을 사용하고 있다면 당장 모든 기능을 제거하기보다 현재 사용하는 기능을 확인하고 새로운 방식으로 점진적으로 전환하는 전략을 세울 수 있습니다.

반대로 새로운 MCP 구현을 시작한다면 Deprecated된 기능을 새롭게 채택하지 않는 것이 중요합니다.

MCP SDK도 2026-07-28 사양 지원

새로운 사양에 맞춰 Tier 1 SDK도 업데이트됐습니다.

현재 새로운 MCP 사양을 지원하는 Tier 1 SDK는 다음과 같습니다.

• TypeScript
• Python
• Go
• C#

이 SDK들은 새로운 사양을 기준으로 MCP 클라이언트와 서버를 구축할 수 있도록 업데이트됐습니다.

Rust SDK도 새로운 사양을 Beta 단계에서 지원합니다.

특히 기존 구현에서 세션 식별자에 의존하고 있었다면 마이그레이션 과정에서 변경이 발생할 수 있습니다.

새로운 사양에서는 Mcp-Session-Id 자체가 제거됐기 때문입니다.

따라서 SDK 버전을 올리는 것만으로 모든 변경이 끝난다고 보기보다는, 현재 구현이 세션 상태를 어떤 방식으로 사용하고 있는지 함께 확인해야 합니다.

기존 MCP 구현에서 확인해야 할 마이그레이션 포인트

MCP 2026-07-28로 전환하려는 개발자라면 먼저 현재 구현에서 어떤 기능을 사용하고 있는지 확인하는 것이 중요합니다.

특히 다음 항목을 우선적으로 살펴볼 필요가 있습니다.

1. 세션 의존성 확인

initialize/initialized 교환과 Mcp-Session-Id에 의존하고 있는지 확인해야 합니다.

세션에 상태를 저장하고 있다면 해당 상태를 애플리케이션 수준의 명시적인 핸들 등으로 어떻게 전달할지 검토해야 합니다.

2. 서버 간 요청 분산 구조 확인

새로운 Stateless 구조에서는 하나의 요청이 특정 서버 인스턴스에 고정될 필요가 줄어듭니다.

따라서 로드 밸런서 뒤에 여러 MCP 서버를 배치하는 환경이라면 공유 세션 저장소 없이 요청을 분산하는 구조를 검토할 수 있습니다.

3. HTTP 인프라 설정 확인

Mcp-Method와 Mcp-Name 헤더를 활용할 수 있도록 Gateway, WAF, Rate Limiter 등의 설정을 확인해야 합니다.

특히 MCP 도구별 라우팅이나 사용량 제어가 필요한 환경이라면 이번 변경을 활용할 수 있습니다.

4. 캐시 정책 검토

ttlMs와 cacheScope를 활용할 수 있는 클라이언트라면 List 및 Read 응답에 대한 캐싱 전략을 검토할 수 있습니다.

5. 인증 방식 점검

현재 DCR을 사용하는지 확인하고, CIMD로의 전환을 고려해야 합니다.

또한 Authorization Server의 iss 검증과 credential의 issuer 종속성 등 새로운 인증 요구사항도 함께 살펴봐야 합니다.

6. Deprecated 기능 확인

Roots, Sampling, Logging, HTTP+SSE transport를 사용하고 있다면 향후 전환 계획을 세워야 합니다.

새로운 구현에서는 Deprecated 기능을 새롭게 도입하지 않는 것이 중요합니다.

MCP 2026-07-28이 가져오는 의미

이번 MCP 사양 업데이트를 하나의 기능 추가로만 이해하기는 어렵습니다.

핵심은 MCP의 프로토콜 설계 방향 자체가 변화했다는 점입니다.

Stateless Protocol Core를 중심으로 요청을 독립적으로 처리할 수 있게 됐고, MRTR을 통해 연결을 계속 유지하지 않고도 서버와 클라이언트 사이의 추가 상호작용을 처리할 수 있게 됐습니다.

여기에 헤더 기반 라우팅이 더해지면서 기존 HTTP 인프라와 MCP의 결합도 높아졌습니다.

캐시 가능한 List 결과는 반복 요청을 줄이는 데 활용할 수 있고, 인증 구조 강화는 MCP를 실제 환경에 적용하는 과정에서 중요한 보안 기반이 될 수 있습니다.

또한 Extensions 프레임워크와 Tasks의 분리는 MCP Core와 확장 기능의 역할을 보다 명확하게 구분하는 방향을 보여줍니다.

728x90

MCP 2026-07-28 사양의 가장 중요한 변화는 Stateless Protocol Core입니다.

기존의 initialize/initialized 교환과 Mcp-Session-Id가 제거되면서 MCP 요청은 보다 독립적으로 처리될 수 있게 됐습니다.

여기에 Multi Round-Trip Requests(MRTR)가 도입되면서 Stateless 환경에서도 추가 입력이나 서버와 클라이언트 사이의 상호작용을 처리할 수 있게 됐습니다.

또한 Mcp-Method, Mcp-Name을 이용한 헤더 기반 라우팅, ttlMs와 cacheScope를 활용한 캐싱, RFC 9207 기반 Issuer 검증과 CIMD 전환 등 인프라와 보안 측면의 변화도 함께 이뤄졌습니다.

기존 MCP 개발자에게 이번 업데이트는 단순한 SDK 버전 업그레이드 이상의 의미를 가집니다. 특히 세션 기반 구현을 사용하고 있다면 새로운 Stateless 구조에 맞춰 마이그레이션을 검토해야 합니다.

반면 새로운 MCP 시스템을 구축하는 입장에서는 Stateless 구조를 기반으로 서버 확장과 요청 분산을 보다 유연하게 설계할 수 있는 기반이 마련됐습니다.

결국 MCP 2026-07-28은 AI 에이전트와 MCP 기반 워크플로우가 커지는 환경에서 확장성, 안정성, 보안, 상호운용성을 강화하기 위한 방향으로 프로토콜의 기반을 다시 정비한 업데이트라고 정리할 수 있습니다.

앞으로 MCP를 도입하거나 기존 MCP 환경을 운영할 계획이라면 새로운 기능만 확인하기보다 Stateless 전환, Deprecated 기능, 인증 변경사항, SDK 마이그레이션 요소까지 함께 살펴보는 것이 중요합니다.

300x250

https://blog.modelcontextprotocol.io/posts/2026-07-28/

The 2026-07-28 Specification