MCP v2 – 세션 없는 HTTP 서버로 바뀐 Model Context Protocol

왜 큰 변화인가
주요 변경점
서버 구현이 어떻게 단순해지나
마이그레이션할 때 볼 점
누가 관심 가져야 하나
관련 문서
참고 자료

MCP v2는 2026-07-28 Model Context Protocol 스펙을 가리키는 실무적 표현이다. 핵심 변화는 MCP 서버가 더 이상 프로토콜 세션과 열린 스트림에 의존하지 않아도 된다는 점이다. 서버는 ordinary HTTP 요청처럼 도구 호출을 받고 결과를 반환할 수 있고, Cloudflare Workers 같은 request-scoped 서버리스 환경에서도 단순하게 배포할 수 있다.

왜 큰 변화인가

초기 리모트 MCP는 로컬 stdio 전송의 세션 모델을 웹으로 옮긴 형태에 가까웠다. 서버는 initialize 요청 뒤 Mcp-Session-Id를 발급하고, 이후 요청을 같은 세션 상태와 연결해야 했다. 운영자는 sticky session, 열린 stream, message replay, 배포 중 세션 drain 같은 문제를 처리해야 했다.

2026-07-28 스펙은 이 부담을 core request path에서 제거한다. 각 요청이 필요한 프로토콜 버전, 클라이언트 정체성, capability 정보를 직접 담는다. 서버 기능을 미리 살펴보고 싶으면 server/discover를 호출할 수 있지만 필수 handshake는 아니다.

주요 변경점

변경	의미
세션 없는 호출	`Mcp-Session-Id`와 필수 initialize 흐름 제거
MRTR	elicitation을 열린 stream 대신 `input_required` 반환과 재시도로 처리
HTTP 헤더 표준화	`Mcp-Method`, `Mcp-Name`으로 gateway·WAF·rate limit이 JSON body 파싱 없이 판단
캐시 힌트	`ttlMs`, `cacheScope`로 tools/prompts/resources 목록 캐시 가능
인증 정리	CIMD 우선, DCR은 deprecated, RFC 9207 issuer 확인과 RFC 8707 resource audience 적용
기능 수명주기	Active, Deprecated, Removed 상태와 최소 12개월 deprecation window 도입

서버 구현이 어떻게 단순해지나

기존에는 MCP 자체 때문에 Durable Objects 같은 상태 저장 primitive가 필요했다. 이제 앱 도메인 상태가 필요한 경우에만 Durable Objects를 쓰고, 단순 도구 서버는 Workers handler 하나로 충분할 수 있다.

import { McpServer } from "@modelcontextprotocol/server";
import { createMcpHandler } from "agents/mcp/server";

function createServer() {
  const server = new McpServer({ name: "hello-server", version: "1.0.0" });
  server.registerTool("hello", { description: "Return a greeting" }, async () => ({
    content: [{ type: "text", text: "Hello, World!" }],
  }));
  return server;
}

export default {
  fetch(request, env, ctx) {
    return createMcpHandler(createServer)(request, env, ctx);
  },
};

실제 구현에서는 도구 입력 스키마, OAuth provider, logging, tool-level rate limit을 붙여야 한다. 다만 프로토콜 세션 저장소가 기본 요구사항에서 빠졌다는 점이 핵심이다.

마이그레이션할 때 볼 점

tools, prompts, resources 중심 서버는 SDK 업그레이드와 stateless handler 전환만으로 대부분 옮길 수 있다.
legacy protocol session, server-to-client request, standalone stream에 의존한 서버는 stateless route를 병행 운영하면서 기능을 단계적으로 옮겨야 한다.
elicitation은 열린 stream 기반 구현에서 input_required 결과와 사용자 입력 재시도 흐름으로 다시 설계해야 한다.
gateway·보안팀은 Mcp-Method, Mcp-Name 헤더 기준으로 method별 정책과 관측성을 붙일 수 있다.

누가 관심 가져야 하나

SaaS API 팀: MCP 서버를 일반 HTTP workload처럼 운영하고 싶은 팀
서버리스 플랫폼 사용자: Worker, Function, edge runtime에 MCP를 올리고 싶은 개발자
보안·플랫폼 팀: MCP tool 호출을 gateway, WAF, OAuth audience, rate limit 정책과 연결해야 하는 조직
기존 MCP 서버 운영자: sessionful 구현을 유지할지 stateless 스펙으로 전환할지 판단해야 하는 팀

참고 자료

The next generation of MCP — Cloudflare Blog (2026-08-04)

Like?

AI Sparkup