MCP 무상태 프로토콜로 바뀌면서 MCP는 더 이상 세션 유지와 핸드셰이크에 기대지 않아도 됩니다.
그 결과 MCP 서버를 더 단순한 구조로 배포할 수 있고, Cloudflare Workers 같은 요청 단위 인프라에서도 운영 부담이 크게 줄어듭니다.
목차
이번 변화는 단순한 구현 편의 개선이 아니라, MCP의 기본 동작 방식이 바뀌는 일입니다. 세션 관리, sticky session, 스트림 유지 같은 복잡한 운영 요소가 핵심 경로에서 빠지면서, 개발자는 실제 도구 호출과 응답에 더 집중할 수 있게 됩니다.
MCP 무상태 프로토콜로 바뀐 핵심
기존 MCP는 초기화와 확인 절차를 거쳐 세션을 시작하고, 이후 요청마다 그 세션 상태를 찾아야 했습니다.
원격으로 MCP를 운영할 때는 이 구조가 그대로 웹 인프라 위로 옮겨지면서 여러 문제가 생겼습니다.
요청 라우팅을 세션에 맞춰 고정해야 했고, 연결이 끊기지 않도록 스트림을 오래 유지해야 했으며, 상태 복구와 메시지 재전송도 신경 써야 했습니다.
MCP 무상태 프로토콜은 이런 부담을 핵심 경로에서 제거합니다.
이제 각 요청은 필요한 프로토콜 버전, 클라이언트 식별 정보, 클라이언트 기능만 담아 처리할 수 있습니다.
서버가 별도의 프로토콜 세션을 저장하지 않아도 되므로, 요청은 들어온 뒤 도구나 프롬프트, 리소스를 실행하고 바로 결과를 돌려주는 형태로 단순해집니다.
이 변화가 중요한 이유는 배포 방식이 달라지기 때문입니다.
MCP 서버를 운영할 때 상태를 보존하는 전용 계층이 항상 필요한 것은 아니며, 요청 단위로 처리하는 인프라에 더 잘 맞게 됩니다.
운영자는 더 적은 구성 요소로 서비스를 유지할 수 있고, 고객은 복잡성이 줄어든 만큼 비용과 장애 가능성도 낮아지는 효과를 기대할 수 있습니다.
MCP 서버 운영이 단순해지는 이유
원문에서 강조하는 핵심은 MCP 무상태 프로토콜이 단순히 “세션을 없앴다”는 수준이 아니라는 점입니다.
프로토콜 세션이 사라지면, 서버 배포와 확장에 따라붙던 많은 보조 작업도 함께 줄어듭니다.
예를 들어 기존에는 활성 세션을 안전하게 드레인하거나 마이그레이션해야 했고, 인스턴스가 사라질 때 클라이언트 재연결 문제가 생길 수 있었습니다.
무상태 구조에서는 이런 운영 과제가 크게 줄어듭니다.
서버는 각 요청을 독립적으로 처리할 수 있으므로, 더 쉽게 확장하고 유지할 수 있습니다.
특히 서버리스 환경이나 요청 스코프 기반 실행 모델에서 MCP 서버를 다루기 쉬워집니다.
상태를 위한 별도 조정 로직이 핵심이 아니게 되기 때문입니다.
이때 중요한 점은 MCP의 기능이 줄어드는 것이 아니라는 사실입니다.
도구 호출, 프롬프트, 리소스 같은 주요 기능은 그대로 유지됩니다.
바뀌는 것은 그 기능을 전달하는 방식이며, MCP 무상태 프로토콜은 그 전달 과정을 더 단순하고 예측 가능하게 만듭니다.
Workers에서의 배포 관점
Cloudflare는 이 변화에 맞춰 MCP를 Workers에서 더 쉽게 운영할 수 있는 방향을 제시하고 있습니다.
원문에 따르면 이제 MCP 자체가 요청 단위 인프라에 더 잘 맞기 때문에, 특별한 상태 계층 없이 Cloudflare Worker에서 실행하는 구성이 가능해집니다.
이는 MCP 서버를 “항상 연결을 유지해야 하는 서비스”가 아니라 “일반적인 HTTP 워크로드”처럼 다루게 만든다는 의미와 가깝습니다.
또한 기존에는 상태ful 구성에 맞춰 설계된 primitive가 필요했지만, 이제는 MCP 자체가 그 요구를 덜어냈습니다.
다만 애플리케이션 자체가 상태를 필요로 한다면 Durable Objects 같은 다른 도구가 여전히 적합할 수 있습니다.
즉, 상태가 필요한 부분과 MCP 프로토콜 자체를 분리해서 생각할 수 있게 된 것입니다.
엘리시테이션은 스트림 대신 여러 차례 요청으로
MCP는 때때로 서버가 작업을 완료하기 전에 사용자로부터 추가 정보를 받아야 합니다.
승인, 선택, 확인 같은 상호작용이 여기에 해당합니다.
기존에는 이런 엘리시테이션이 열린 스트림에 의존했기 때문에, 운영 복잡도와 타임아웃, 비용을 함께 고려해야 했습니다.
새로운 방식은 Multi Round-Trip Requests, 즉 MRTR을 사용합니다.
서버는 input_required 결과를 돌려주고, 클라이언트가 필요한 입력을 수집한 뒤 같은 작업을 다시 요청합니다.
이 과정은 프로토콜 세션을 유지하지 않고도 진행됩니다.
결과적으로 상호작용은 유지되지만, 연결 상태에 대한 의존성은 줄어듭니다.
이 변경은 기존 방식과 호환되지 않는 부분이 있는 브레이킹 체인지입니다.
그러나 운영 관점에서는 훨씬 단순합니다. 스트림을 붙잡고 있어야 하는 부담이 사라지고, 요청이 끊겼을 때의 복구 방식도 더 명확해집니다.
MCP 무상태 프로토콜이 실제로 체감되는 지점이 바로 이 부분입니다.
HTTP 인프라가 MCP를 더 잘 이해하게 된 배경
MCP 요청은 JSON-RPC 메시지를 HTTP로 보내는 구조지만, 이전에는 요청의 의미가 JSON 본문 안에만 있었습니다.
그러다 보니 게이트웨이, 레이트 리미터, WAF 같은 중간 인프라가 요청 종류를 판단하려면 본문을 직접 파싱해야 했습니다.
이는 단순한 관찰만으로도 비용이 드는 구조였습니다.
새로운 사양은 Streamable HTTP 요청에 Mcp-Method 와 Mcp-Name 헤더를 요구합니다.
이로써 인프라는 본문을 해석하지 않아도 요청이 어떤 메서드인지, 어떤 이름의 작업인지 파악할 수 있습니다.
운영자는 기존 HTTP 도구로 메서드별 정책을 적용하거나, 도구 단위 메트릭을 수집하기가 훨씬 쉬워집니다.
또한 응답에는 ttlMs 와 cacheScope 같은 힌트가 추가되어 목록과 리소스 읽기 결과의 재사용 가능성을 더 잘 표현합니다.
도구 목록은 결정적으로 정렬되며, 클라이언트는 이를 재사용할 수 있습니다.
이런 변화는 겉으로는 작아 보여도, 실제 운영에서는 캐시 안정성과 재연결 효율에 직접 영향을 줍니다.
인증과 Workers OAuth Provider의 역할
MCP 무상태 프로토콜은 인증도 함께 정리합니다.
새 사양은 이미 관계가 있는 서버와 클라이언트 사이에서는 사전 등록된 클라이언트를 우선하고, 동적 등록이 필요할 때는 Client ID Metadata Documents를 사용하도록 권장합니다.
Dynamic Client Registration은 새 구현에서 비권장 상태이며, 이후 제거 일정도 제시되어 있습니다.
또 하나의 중요한 변화는 issuer 식별입니다.
인증 서버는 성공 응답에 iss 를 포함하고, 클라이언트는 사전에 발견한 issuer와 이를 비교합니다.
이 절차는 서로 다른 issuer의 응답이 혼동되는 문제를 줄입니다.
또한 토큰 요청과 인증 요청에는 표준 resource 개념이 적용되어, 토큰이 특정 대상에만 유효하도록 더 명확하게 다뤄집니다.
원문은 Workers OAuth Provider가 이러한 요구사항을 MCP 서버에 맞게 구현한다고 설명합니다.
즉, Cloudflare Workers에서 MCP 서버를 운영할 때 인증 계층을 별도로 복잡하게 꾸밀 필요를 줄여주는 도구입니다.
MCP 서버가 무상태로 동작하더라도 인증은 여전히 중요하며, 이 패키지는 그 부분을 표준에 맞춰 정리하는 역할을 합니다.
SDK와 마이그레이션에서 확인할 점
이번 사양 변경은 서버 구현뿐 아니라 SDK에도 반영되었습니다.
TypeScript, Python, Go, C# SDK가 함께 업데이트되었고, createMcpHandler 도 공식 TypeScript SDK로 들어왔습니다.
Cloudflare의 Agents SDK는 이미 새 사양을 지원해 왔고, 기존 McpAgent 에서 새 핸들러로 옮기는 경로도 안내됩니다.
마이그레이션에서 주의할 점은 모든 서버가 같은 속도로 바뀌는 것은 아니라는 사실입니다.
원문은 기존 세션형 기능이나 서버-클라이언트 간 독립 스트림에 의존하는 경우 더 신중한 전환이 필요하다고 말합니다.
이런 경우에는 기존 경로와 무상태 경로를 나란히 두고, 활성 세션을 점진적으로 정리한 뒤 레거시 경로를 제거하는 방식이 적절합니다.
반대로 클라이언트 측은 훨씬 단순합니다.
에이전트 버전을 올리면 대부분 그대로 동작할 수 있다고 설명합니다.
또한 /mcp 엔드포인트는 새 프로토콜과 2025 Streamable HTTP 클라이언트의 무상태 요청을 함께 받아들이므로, 많은 환경에서 재설정 없이 전환이 가능합니다.
즉, 서버는 설계를 바꿔야 하지만, 클라이언트는 상대적으로 부담이 적습니다.
실제 운영에 주는 의미
원문에서 제시하는 사례는 MCP 무상태 프로토콜이 이미 실제 환경에 적용될 수 있음을 보여줍니다.
Sentry와 Linear 같은 팀은 새 사양이 초기에 제기된 복잡성을 상당 부분 정리해 준다고 평가했습니다.
특히 인증과 도구 호출 주변의 불필요한 복잡성이 줄어든 점이 반복해서 언급됩니다.
Cloudflare 쪽에서도 이 전환은 추상적인 계획이 아니라 이미 적용 가능한 운영 모델로 제시됩니다.
새 사양은 Workers에서 실행되는 일반적인 HTTP 워크로드처럼 MCP를 다루게 만들고, 필요한 경우 Durable Objects를 상태가 필요한 애플리케이션에만 사용하도록 분리합니다.
그만큼 배포 판단이 명확해집니다.
정리하면, MCP 무상태 프로토콜은 개발 경험만 바꾸는 것이 아니라 운영 모델 자체를 바꿉니다.
세션 보존과 연결 유지에 맞춰진 설계에서 벗어나, 요청 중심의 더 단순한 구조로 이동하는 것이 핵심입니다.
핵심 정리
MCP 무상태 프로토콜은 세션 유지, 핸드셰이크, 열린 스트림 의존성을 핵심 경로에서 제거해 MCP 서버를 더 쉽게 배포하고 운영할 수 있게 만듭니다.
특히 Workers 같은 요청 단위 인프라에서는 복잡한 상태 조정 없이도 MCP를 다룰 수 있다는 점이 가장 큰 변화입니다.
인증, 헤더 기반 라우팅, MRTR 기반 상호작용까지 함께 정리되면서, MCP는 더 표준적인 HTTP 운영 방식에 가까워졌습니다.
기존 세션형 서버는 전환 전략이 필요하지만, 새 사양은 전반적으로 구현과 유지보수를 단순하게 만듭니다.
MCP 무상태 프로토콜를 이해할 때는 개별 요소보다 전체 맥락과 연결 구조를 함께 보는 것이 중요합니다.
MCP 무상태 프로토콜의 효과는 실제 사례와 적용 조건을 함께 비교할 때 더 분명하게 확인할 수 있습니다.