MCP 차기 스펙의 Stateless Core와 에이전트 확장 구조

세션을 없애고 확장 가능한 프로토콜로

Model Context Protocol(MCP)의 차기 버전 릴리스 후보는 2026년 5월 21일 공개됐다. 출시 이후 최대 규모의 개편으로 평가되는 스펙이다. 상태 비저장 핵심 프로토콜, Extensions 모듈 프레임워크, Tasks 확장, MCP Apps, 강화된 인증 체계와 공식 폐지 정책이 함께 제안됐다.

최종 스펙 확정 예정일은 2026년 7월 28일이다. SDK 유지보수자와 클라이언트 구현자에게는 10주간의 검증 기간이 주어진다. 단순한 도구 호출 규약이었던 MCP를 에이전트 오케스트레이션의 표준 인프라로 확장하려는 변화다.

영역	변경 내용	영향
Stateless Core	핸드셰이크·세션 ID 제거	수평 확장, 서버리스 배포 가능
Extensions	역방향 DNS 식별 모듈형 확장	점진적 기능 도입
Tasks	장기 실행 작업 생명주기 API	폴링 기반 비동기 작업 추적
MCP Apps	샌드박스 iframe UI 통합	서버 제공 인터랙티브 UI
인증 강화	OAuth 2.1 / OIDC 정렬 (SEP-2596)	엔터프라이즈 보안 표준 준수
폐지 정책	최소 12개월 폐지 전 보장	예측 가능한 마이그레이션

변경 폭 때문에 MCP 2.0으로 불리기도 하지만, Anthropic 팀은 공식 폐지 정책을 통해 하위 호환성을 관리한다는 입장이다.

고정 세션이 만든 운영 제약

기존 MCP는 initialize와 initialized 핸드셰이크로 세션을 만들고 Mcp-Session-Id 헤더로 연결 상태를 유지했다. 클라이언트와 서버 사이의 1:1 고정 연결을 전제로 한 구조라 클라우드 네이티브 환경에서는 운영 부담이 뒤따랐다.

로드 밸런서 뒤에서는 세션 어피니티가 필요했다. 서버리스 함수나 컨테이너를 확장하면 세션 상태를 동기화해야 했고, 서버가 재시작되거나 크래시하면 기존 세션을 복구하기 어려웠다. 여러 에이전트가 병렬로 호출할 때는 세션 경합도 발생할 수 있었다.

Stateless Core는 이 전제를 뒤집는다. RC에서는 initialize 핸드셰이크와 Mcp-Session-Id를 완전히 제거한다. 프로토콜 버전, 클라이언트 정보, 기능 협상 정보는 각 요청의 _meta 필드에 직접 포함된다.

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "search",
    "arguments": { "query": "MCP 2026" },
    "_meta": {
      "protocolVersion": "2026-07-28",
      "clientInfo": { "name": "claude-code", "version": "1.0" },
      "capabilities": { "extensions": ["tasks", "apps"] }
    }
  }
}

요청 하나가 처리에 필요한 정보를 자체적으로 갖기 때문에 특정 서버 인스턴스에 묶일 이유가 줄어든다. 일반 HTTP 인프라의 표준 로드 밸런싱과 오토 스케일링을 적용할 수 있고, 서버리스 배포도 가능해진다.

핵심은 작게, 새 기능은 Extension으로

Extensions 프레임워크는 MCP 핵심 스펙을 최소한으로 유지하면서 새 기능을 점진적으로 도입하기 위한 장치다. 기능을 먼저 Extension으로 제공해 검증하고, 충분히 안정화되면 핵심 스펙에 흡수할 수 있다.

각 Extension은 역방향 DNS 식별자로 구분한다.

io.modelcontextprotocol.tasks
io.modelcontextprotocol.apps
com.company.custom-extension

클라이언트는 _meta.capabilities.extensions 배열에 자신이 지원하는 Extension을 선언한다. 서버는 응답을 통해 실제 활성화된 Extension을 알린다. 양측이 서로 다른 기능 집합을 구현했더라도 공통으로 지원하는 범위에서 동작할 수 있는 협상 방식이다.

도구가 인터랙티브 화면까지 제공하는 MCP Apps

기존 흐름에서는 LLM이 도구 실행 결과를 텍스트로 돌려주는 방식이 중심이었다. MCP Apps는 서버가 인터랙티브 HTML 인터페이스를 제공하고, 호스트가 이를 샌드박스 iframe 안에서 렌더링할 수 있도록 범위를 넓힌다.

여기서 중요한 설계는 선행 선언이다. 서버는 도구가 사용할 UI 템플릿을 실행 전에 선언한다. 호스트는 해당 템플릿을 미리 가져와 캐시하고 보안 심사를 수행할 수 있다. 런타임에 임의 코드가 삽입되는 위협을 사전에 차단하기 위한 구조다.

오래 걸리는 호출을 Tasks로 분리한다

기존 tools/call은 결과가 나올 때까지 기다리는 블로킹 방식이었다. 그러나 복잡한 에이전트 작업은 수 분 이상 이어질 수 있다. Tasks 확장은 이런 실행을 비동기 작업으로 다루기 위해 Stateless Core와 함께 설계됐다.

메서드	역할
`tools/call` → task handle 반환	장기 작업 시작, 즉시 핸들 반환
`tasks/get`	작업 상태 폴링
`tasks/update`	클라이언트가 서버에 추가 입력 제공
`tasks/cancel`	실행 중 작업 취소

클라이언트는 tools/call에서 받은 task handle로 tasks/get을 호출해 상태를 확인한다. 사용자 승인이나 추가 정보가 필요하면 수집한 내용을 tasks/update로 서버에 전달할 수 있다. 이 패턴은 사용자 개입이 필요한 에이전트 작업과 멀티 에이전트 협업에서 핵심 역할을 맡는다.

tasks/list는 RC에서 제거됐다. 서버가 tools/call 응답 없이 자발적으로 task handle을 반환할 수도 있다.

요청부터 UI와 장기 작업까지 이어지는 경로

⤢✕

클라이언트 요청은 _meta 정보를 포함해 Stateless Core로 들어간다. 협상 결과에 따라 기본 도구 실행, Tasks, MCP Apps 중 필요한 경로가 활성화된다. 장기 작업은 task handle과 폴링으로 추적하고, UI에서 받은 사용자 입력은 tasks/update를 거쳐 다시 작업에 반영된다.

OAuth 2.1과 OIDC에 맞춘 인증 처리

RC는 총 6개의 SEP(Specification Enhancement Proposal)을 통해 MCP 인증 체계를 주류 OAuth 2.1 및 OpenID Connect 표준과 정렬한다.

iss 파라미터 검증은 RFC 9207을 준수해 액세스 토큰 혼용 공격을 차단한다. 클라이언트는 인증 응답의 iss를 기대한 발급자와 반드시 비교해야 한다.

Dynamic Client Registration에서는 OIDC의 application_type을 등록할 때 명시적으로 선언한다. 데스크탑이나 CLI 클라이언트가 웹 애플리케이션으로 잘못 분류돼 부적절한 인증 흐름이 적용되는 문제를 다룬다.

클라이언트 자격증명은 인증 서버의 발급자 식별자에 바인딩한다. 리소스가 다른 인증 서버로 마이그레이션되면 클라이언트도 재등록해야 한다. OIDC 스타일 인증 서버에서 리프레시 토큰을 요청하는 방법과 스텝업 인증 과정에서 범위를 누적하는 방법도 명확히 문서화한다.

폐지와 제거 사이에 보장되는 기간

공식 폐지 정책인 SEP-2596은 기능 제거 전에 최소 12개월의 보장 기간을 둔다. 어떤 기능이 폐지 상태로 표시되더라도 최소 12개월이 지나기 전에는 실제로 제거할 수 없다. 서버와 클라이언트 구현자가 예측 가능한 일정에 맞춰 이동할 수 있도록 만든 규칙이다.

이번 RC에서는 Roots, Sampling, Logging이 폐지 예정 기능으로 표시됐다.

Roots가 담당하던 프로토콜 수준의 루트 디렉터리 개념은 제거하고 도구 파라미터나 설정에서 처리한다. Sampling은 MCP 서버가 프로토콜을 통해 LLM 샘플링을 요청하던 방식 대신 LLM 공급자 API를 직접 호출하는 방식으로 대체한다. Logging은 프로토콜 레벨에서 분리해 stderr 또는 OpenTelemetry로 이관한다.

서버와 클라이언트가 바꿔야 할 지점

세션 기반 구조를 Stateless Core로 옮기는 작업은 API 호출 몇 개를 교체하는 수준에 머물지 않는다. 서버 설계에서 세션 상태를 전제로 한 부분부터 찾아내야 한다.

서버에서는 initialize 핸들러와 세션 상태 의존성을 제거하고, 요청마다 _meta를 파싱하도록 바꿔야 한다. 지원할 Extensions를 결정한 뒤 협상 결과를 응답하는 로직도 필요하다.

클라이언트는 Mcp-Session-Id 헤더를 제거하고 모든 요청에 _meta를 인라인으로 넣어야 한다. Tasks Extension을 사용한다면 상태를 확인하는 폴링 루프를 구현해야 하며, OAuth 2.1 인증 응답에서는 iss 파라미터 검증을 추가해야 한다.

인프라에서는 세션 어피니티 설정을 걷어내고 표준 로드 밸런서로 전환할 수 있다. 서버리스 배포 가능 여부도 다시 검토할 수 있다.

검증 기간은 2026년 5월 21일부터 7월 28일까지 10주다. SDK 유지보수자들은 실제 워크로드로 변경 사항을 검증하고, 발견한 문제를 공식 스펙 확정 전에 반영할 수 있다. Stateless Core는 MCP 서버를 일반 HTTP 서비스처럼 운영할 기반을 만들고, Extensions와 Tasks, MCP Apps는 장기 비동기 작업과 인터랙티브 UI를 에이전트 프로토콜 안에서 연결한다.