MCP Stateless 코어 전환과 Extensions 기반 에이전트 연동

세션 없는 요청이 MCP 서버 운영을 바꾼다

차기 Model Context Protocol(MCP) 사양의 릴리스 후보가 공개됐다. 2026-07-28 개정판은 Stateless 프로토콜 코어, Extensions 프레임워크, Tasks, MCP Apps, 인증 강화, 공식 폐기 정책을 담는다. 10주 검증 기간을 거쳐 2026년 7월 28일 최종본으로 확정될 예정이다.

핵심 변화는 LLM 애플리케이션과 외부 도구·데이터·리소스를 연결하는 MCP의 코어를 무상태로 바꾸는 데 있다. 기존 initialize/initialized 핸드셰이크와 Mcp-Session-Id 세션 헤더가 사라지고, 프로토콜 버전·클라이언트 정보·capabilities는 각 요청의 _meta 필드에 인라인으로 실린다.

이 방식에서는 특정 서버 인스턴스가 특정 세션을 붙잡고 있을 필요가 없다. 원격 MCP 서버를 라운드로빈 로드밸런서 뒤에 두고, 어느 인스턴스든 어느 요청이든 처리할 수 있다.

코어는 작게 유지하고 기능은 확장으로 분리한다

무상태 전환은 서버가 세션 상태를 보관하지 않아도 된다는 뜻이다. 스티키 세션과 공유 세션 스토어 의존성을 줄일 수 있고, 게이트웨이의 심층 패킷 검사(DPI)도 제거할 수 있다. 요청 분기는 Mcp-Method 헤더를 기준으로 이뤄진다.

tools/list 응답은 서버가 지정한 ttlMs 범위에서 클라이언트 캐싱이 가능하다. 요청마다 컨텍스트를 전달하는 부담은 생기지만, 수평 확장과 장애 격리 측면에서는 무상태 코어가 유리하다.

새 기능은 Extensions 프레임워크를 통해 옵트인으로 먼저 제공된다. 안정화된 기능은 코어로 승격될 수 있고, 확장으로 남을 수도 있다. 코어의 안정성을 유지하면서 기능 실험을 병행하기 위한 구조다.

Tasks는 tools/call에서 태스크 핸들을 반환하고, tasks/get·tasks/update·tasks/cancel로 장시간 작업을 다룬다. 기존 실험적 API에 있던 tasks/list는 제거된다.

MCP Apps는 서버가 대화형 HTML 인터페이스를 제공하는 확장이다. 호스트는 이를 샌드박스 iframe으로 렌더링하며, UI 템플릿을 미리 선언해 프리페치·캐시·보안검토에 활용할 수 있다.

⤢✕

상태 기반 원격 서버는 이관 범위를 먼저 확인해야 한다

STDIO 전용 서버나 이미 무상태로 동작하는 원격 서버는 마이그레이션 부담이 작다. 반면 대규모 상태 기반 세션 원격 서버를 운영하는 조직은 영향을 크게 받는다.

클라이언트와 서버는 핸드셰이크를 제거하고, 매 요청 _meta에 필요한 정보를 담도록 로직을 다시 설계해야 한다. 세션 스토어와 스티키 라우팅을 걷어내는 대신 라운드로빈 LB 구조로 인프라를 단순화할 수 있다.

장시간 작업을 처리하는 코드도 점검 대상이다. tasks/list에 의존하는 구현은 제거하고, 태스크 핸들을 폴링하거나 취소하는 패턴으로 다시 구성해야 한다. tools/list 캐시 TTL은 관련 트래픽을 줄이는 데 사용할 수 있다.

인증 계층은 OAuth 2.1 Resource Server 모델에 맞춰 정비한다. RFC 9207의 iss 검증과 토큰 audience 바인딩도 적용 범위에 포함된다. 세션 스토어와 DPI 게이트웨이를 제거해 인프라 비용을 줄일 수 있지만, 이를 확장 채택 기준·인증 정책·버전 폐기 일정과 함께 API 표준 관리 체계에 넣어야 한다.

Stateful 구조와 달라지는 운영 지점

항목	기존 Stateful(2025-11-25)	신규 Stateless(2026-07-28)	트레이드오프
연결 방식	initialize 핸드셰이크	자기완결 요청, `_meta` 인라인	요청당 오버헤드 소폭 증가
세션 관리	`Mcp-Session-Id` 헤더	세션 제거, 무상태	서버 상태 로직 재설계 필요
확장성	스티키 세션·공유 스토어	라운드로빈 LB 수평 확장	인프라 단순화, 이관 비용 발생
장시간 작업	실험적 Tasks(`tasks/list` 포함)	Tasks 확장(핸들 기반)	폴링 패턴 재구현
UI 연동	미지원	MCP Apps 샌드박스 iframe	보안검토·프리페치 이점
인증	초기 OAuth 수준	OAuth 2.1·OIDC·RFC 9207	표준 정합, 검증 로직 추가
버전 정책	비공식	Active/Deprecated/Removed 12개월	예측 가능성 향상

무상태 코어는 장애 격리와 수평 확장에 적합하지만, 모든 요청이 필요한 컨텍스트를 다시 전송해야 한다. Extensions는 기능을 옵트인으로 격리해 코어 안정성을 지키고, Tasks와 MCP Apps가 상호운용되는 기반이 된다.

하위 호환 문제는 Active → Deprecated → Removed 수명주기로 관리한다. 폐기된 기능은 최소 12개월 동안 제거가 유예되므로, 구·신 버전을 병행할 운영 창구를 확보할 수 있다.

엔터프라이즈 API 거버넌스에 반영할 항목

MCP는 엔터프라이즈 AI 에이전트 계층에서 표준 통합 버스(integration bus)로 다룰 수 있다. 확장 채택 기준과 폐기 정책은 사내 API 라이프사이클 관리 규정에 맞춰야 한다.

프로토콜 버전과 확장 버전은 형상 항목으로 등록하고, 변경 이력과 베이스라인을 관리한다. OAuth 2.1 Resource Server와 issuer 검증은 ISMS-P·제로트러스트 통제 항목에 매핑할 수 있다.

Python·TypeScript·Go·C# 베타 SDK의 RC 사양 지원은 이기종 시스템 연계의 기반이 된다. 다만 세션 제거 이후 재현성과 감사(audit) 요구사항은 로깅과 추적 체계로 보완해야 한다. 세션 스토어·DPI 제거에 따른 TCO 절감 효과도 투자 타당성의 근거로 정량 산정할 필요가 있다.

사양 확정 뒤 예상되는 변화

2026년 7월 28일 정식 사양이 발효되면 Tier 1 SDK 지원도 함께 이뤄질 전망이다. 무상태 구조는 서버리스·멀티리전 배포를 넓히고, 원격 MCP 서버 상용화를 가속할 수 있다.

MCP Apps는 도구가 대화형 UI를 배포하는 앱 마켓 형태로 진화할 가능성이 있다. OAuth 2.1 정합은 기업 IdP와 API 게이트웨이 통합 사례 증가로 이어질 수 있으며, Extensions 프레임워크 위에서는 서드파티 확장 간 사실상 표준(de-facto) 경쟁도 예상된다.

대규모 상태 기반 서버 운영 조직은 10주 검증 기간과 12개월 폐기 유예를 활용해 단계적 이관을 준비할 수 있다. 이 과정에서 인증, 형상관리, API 거버넌스를 별도 과제가 아니라 MCP 운영 구조의 일부로 묶는 일이 필요하다.