TL;DR

• Model Context Protocol 2026-07-28 사양은 initialize/initialized 핸드셰이크와 Mcp-Session-Id 기반 프로토콜 세션을 제거했다. 버전·능력은 각 요청의 _meta에 담는다(protocolVersion·capabilities는 필수, clientInfo는 선택).
• 프로토콜 코어는 무상태(stateless)지만 애플리케이션까지 무상태일 필요는 없다. 호출 간 상태가 필요하면 도구가 명시적 핸들을 발급하고 다음 호출의 인자로 받는다.
• 요청이 스스로 필요한 정보를 담으므로 서버리스(serverless)·엣지(edge) 배포와 수평 확장이 쉬워진다. 다만 요청 범위 SSE와 subscriptions/listen 장기 스트림은 여전히 존재한다.
• 인가는 OAuth 2.1 기반 흐름과 OAuth 2.0·OIDC 관련 표준에 맞게 강화됐다. MCP Apps와 Tasks는 코어와 별도로 선택하는 공식 확장이다.
• 새 버전은 이전 버전과 같은 통신 흐름으로 직접 호환되지 않는다. 스펙은 양쪽을 지원하는 dual-era 구현과 탐지·폴백 절차를 함께 정의한다.

Model Context Protocol 2026-07-28 사양은 핸드셰이크와 프로토콜 세션을 없앤다

Model Context Protocol(MCP)은 AI 클라이언트가 서로 다른 외부 API·데이터·로컬 함수를 같은 방식으로 찾고 호출하도록 연결하는 규격이다. 2026-07-28은 프로토콜 사양의 날짜 기반 버전 표기다. 공식 발표는 이를 "the 2026-07-28 Model Context Protocol specification"이라고 부르며 커뮤니티에서는 "Stateless MCP"라고도 부른다. 핵심 변화는 양방향 상태 유지형(stateful) 프로토콜에서 무상태 요청-응답(request/response) 코어로의 전환이다. 여기서 없어진 상태는 전송 계층이 숨겨 관리하던 프로토콜 세션이다. 도구가 발급한 핸들을 인자로 주고받는 애플리케이션 상태는 그대로 사용할 수 있다.

바뀐 점

이전 버전은 initialize 요청과 notifications/initialized 알림으로 논리적 세션을 시작했다. Streamable HTTP 서버는 초기화 응답에서 세션 ID를 선택적으로 발급할 수 있었다. 각 JSON-RPC 메시지는 별도의 HTTP POST로 전송됐고 SSE 사용도 선택 사항이었다. 세션은 여러 요청을 묶는 논리적 범위였으며 실제 연결의 지속 여부는 SSE 사용 방식에 따라 달랐다.

구분	2025-11-25 사양 (Streamable HTTP)	2026-07-28 사양
프로토콜 문맥	필수 initialize/initialized; 서버가 세션 ID를 선택적으로 발급	핸드셰이크와 세션 ID 없음; 요청별 _meta에 문맥 포함
최초 도구 호출	initialize + initialized + tools/call, 최소 3 POST	직접 tools/call하면 1 POST; 선택적 server/discover를 먼저 부르면 2 POST
SSE	요청 범위 SSE와 선택적 독립 GET SSE	요청 범위 SSE와 subscriptions/listen 장기 SSE
라우팅	세션 상태를 인스턴스 메모리에 뒀다면 세션 고정 또는 공유 저장소 필요	프로토콜 요청은 self-contained라 일반 라우팅 가능
애플리케이션 상태	프로토콜 세션 안에 숨길 수 있음	명시적 핸들을 도구 인자로 전달
배포	세션을 사용하면 상태 관리 인프라 필요	서버리스·엣지 배포에 적합 (AWS Lambda, Cloudflare Workers)

위 요청 수는 인증을 마쳤고 도구 이름·입력 스키마를 이미 아는 정상 경로의 비교다. OAuth, tools/list, 추가 입력을 위한 재요청은 포함하지 않는다. 최초 도구 호출 전에 필요한 준비 메시지의 차이를 나타낸다.

흐름 1 · 이전 MCP: 최소 3 POST

sequenceDiagram
    autonumber
    participant C as Client-Agent
    participant LB as LoadBalancer
    participant S as Server
    C->>LB: initialize 세션 생성
    LB->>S: 라우팅
    S-->>C: InitializeResult + 선택적 session ID
    C->>LB: notifications/initialized
    LB->>S: 라우팅
    S-->>C: 202 Accepted
    C->>LB: tools/call + 선택적 session ID
    LB->>S: session 상태에 맞춰 라우팅
    S-->>C: 결과
    Note over C,S: 각 메시지는 별도 POST · 요청 범위/독립 SSE는 선택적

---

흐름 2 · 2026-07-28 사양: 직접 호출 시 1 POST

sequenceDiagram
    autonumber
    participant C as Client-Agent
    participant S as Server
    C->>S: tools/call + _meta + 인증
    S-->>C: 단일 JSON 또는 요청 범위 SSE
    Note over C,S: 장기 알림은 subscriptions/listen SSE 사용

새 버전의 서버는 server/discover를 반드시 구현하지만 클라이언트가 이를 먼저 호출할 의무는 없다. 클라이언트는 바로 tools/call을 보내고 지원하지 않는 버전이라는 응답을 받으면 호환 버전으로 재시도할 수 있다.

이전 구조가 만든 부담

무상태 코어가 줄이는 부담은 물리적 연결 수보다 핸드셰이크와 프로토콜 세션 관리에 있다.

• 초기화 비용: 최초 실제 호출 전에 initialize와 notifications/initialized라는 두 개의 준비 메시지가 필요했다.
• 세션 상태 관리: 세션 ID를 사용하고 상태를 특정 인스턴스의 메모리에 보관한 서버는 세션 고정 라우팅(sticky routing)이나 공유 저장소가 필요했다. 세션 ID 발급은 스펙상 선택 사항이었으므로 모든 서버에 적용되는 제약은 아니다.
• 서버 주도 상호작용: 요청 범위 SSE, 독립 GET SSE, 재연결 규칙은 모두 선택 사항이었지만 풍부한 서버 주도 스트리밍·재개를 지원하려면 이들을 함께 다뤄야 했다. 2026-07-28은 이를 요청 범위 응답, 다중 왕복 요청(Multi Round-Trip Requests), subscriptions/listen으로 분리했다.
• 배포 복잡성: 프로토콜 세션을 사용한 서버는 인스턴스 간 상태 공유나 라우팅 전략을 따로 설계해야 했다. 무상태 코어는 이 요구를 기본 경로에서 제거한다.

무상태 코어의 효과

각 요청이 버전·능력(clientInfo는 선택)을 직접 전달하면서 다음 효과가 생긴다.

• 배포 유연성: 프로토콜 세션과 세션 고정 라우팅 없이 서버리스·엣지 환경에 배포할 수 있다.
• 수평 확장: 요청 자체만으로 처리에 필요한 프로토콜 문맥을 알 수 있어 일반적인 라운드 로빈 라우팅을 적용하기 쉽다.
• 상태의 명시성: 호출 간 상태는 도구가 발급한 핸들로 드러난다. 모델과 개발자가 어떤 상태를 이어받는지 확인할 수 있다.
• 비용 선택지: 서버리스 과금 모델을 선택할 수 있어 유휴 비용을 낮출 수 있다. 프로토콜 자체가 비용 0을 보장하지는 않는다.

인증과 공식 확장

개정 스펙은 무상태 전환과 함께 인가 규칙과 확장 프레임워크도 정리했다.

• 인가 강화: 인가 응답의 발급자 검증과 발급자별 자격증명 분리를 강화했다. 동적 클라이언트 등록(DCR)은 호환성을 위해 남아 있지만 폐기 예정이며 신규 구현은 클라이언트 ID 메타데이터 문서(CIMD)를 우선한다. OAuth/OIDC를 처음 도입한 개정은 아니다.
• MCP Apps: 서버가 대화형 UI 리소스를 반환하면 호스트가 대화 안의 격리된 iframe에 렌더링한다. 서버가 호스트 화면에 직접 그리는 구조는 아니다.
• Tasks: 오래 걸리는 작업에 내구성 있는 핸들을 발급한다. 클라이언트는 진행 상태를 폴링하고 실행 도중 필요한 입력을 제공하며 재연결 후에도 결과 조회를 이어갈 수 있다.

MCP Apps와 Tasks는 코어 프로토콜과 별도로 선택하는 공식 확장이다. 클라이언트와 서버가 모두 명시적으로 지원해야 사용할 수 있다. Tasks만 이전 코어의 실험 기능에서 확장으로 이동했으며 Apps를 코어 기능에서 승격한 것은 아니다.

Sampling·Roots·Logging도 폐기 예정으로 분류됐지만 즉시 제거된 것은 아니다. HTTP SSE의 재개·메시지 재전달은 제거됐다. 스트림이 끊겨 재요청하더라도 이전 작업이 실행되지 않았다고 단정할 수 없으므로 쓰기 도구는 중복 실행 방지나 결과 조회 방식을 설계해야 한다. 2026-07-28 변경 기록.

트레이드오프: 통신 규격 변경과 dual-era 전환 비용

2026-07-28만 구현한 클라이언트와 이전 버전만 구현한 서버는 직접 호환되지 않는다. 반대 조합도 마찬가지다. 핸드셰이크 기반 버전과 요청별 메타데이터 기반 버전의 통신 흐름 자체가 달라졌기 때문이다.

스펙은 이 단절을 다루는 dual-era 구현을 정의한다. dual-era 클라이언트는 현대 방식으로 먼저 요청한 뒤 서버 응답을 보고 이전 initialize 흐름으로 폴백할 수 있다. dual-era 서버는 요청 형태를 보고 현대 방식과 이전 방식을 함께 제공한다. 따라서 전환이 완전히 불가능하지는 않다. 대신 양쪽 통신 규격을 동시에 구현하거나 게이트웨이에서 변환하는 비용이 든다.

공식 MCP 프로젝트는 공개 당일 TypeScript·Python·Go·C# Tier 1 SDK가 새 버전을 지원했고 Rust SDK는 베타로 지원했다고 밝혔다. 제품별 지원은 별도 문제다. 2026-09-03 기준 OpenAI·Cursor 공식 문서에는 2026-07-28 사양 코어 지원이 명시돼 있지 않다.

MCP의 역할은 표준 어댑터다

MCP 아래에서 실제 작업은 기존 API가 처리한다. 예를 들어 GitLab MCP로 이슈를 만들거나 PR을 조회하면 내부에서는 GitLab API를 호출한다. MCP는 여러 AI 클라이언트가 서로 다른 API·데이터·로컬 함수를 같은 방식으로 발견·호출·인증하도록 인터페이스를 통일한다. USB는 장치 연결 방식을 표준화하고 JDBC는 데이터베이스 접근 인터페이스를 통일한다. MCP도 AI 클라이언트와 외부 도구 사이에서 같은 역할을 한다. Stateless 전환은 이 어댑터를 실제 제품에 통합하기 쉬운 구조로 바꾼다.

---

Connections

• 세션 - 여러 요청에 상태를 잇는 논리적 범위 — 세션·상태·연결의 일반적인 구분을 설명한다.
• 동시성 실행 모델의 발전 흐름 — 연결과 프로세스가 상주할 때 생기는 오버헤드를 실행 단위 관점에서 설명한다.
• OAuth 인증 플로우 — 개정 스펙이 채택한 OAuth 2.0·OIDC 인가의 기반을 설명한다.
• OpenAI Apps SDK MCP 구축하기 — MCP 서버 구축과 인증 강화의 실무 맥락을 다룬다.
• Agent Skills - AI 에이전트에게 전문성을 부여하는 방법 — 에이전트에 도구와 절차를 연결하는 인접 메커니즘을 설명한다.

Related MOCs

• MOCs - Harness Engineering
• MOCs - Computer Science(CS)

Open Questions

• Claude 제품군 전체가 2026-07-28 사양 코어와 Apps·Tasks 확장을 각각 지원하는 시점은 언제인가?
• Codex의 mcp_2026_07_28 기능은 언제 안정화돼 기본 활성화되는가?
• Cursor는 2026-07-28 사양 코어를 공식 지원하는가?