여러 인스턴스 뒤에서 원격 Model Context Protocol (MCP) 서버를 실행하는 것은 즉각적인 인프라 과제를 안겨줍니다. 기존 사양은 초기화 핸드셰이크 (initialize handshake)를 요구하고 Mcp-Session-Id 헤더를 통해 세션을 특정 인스턴스에 고정하기 때문에, 로드 밸런서 (load balancer) 수준에서 스티키 라우팅 (sticky routing) 또는 공유 세션 저장소를 구성해야만 합니다. 이는 단일 프로세스 이상으로 확장하는 것을 불필요하게 복잡하게 만듭니다.

이러한 제한 사항을 해결하기 위해, MCP 프로젝트는 2026년 중반에 세 가지 업데이트를 출시했습니다: 2026–07–28 사양에 대한 릴리스 후보 (release candidate), 안정적인 엔터프라이즈 관리형 권한 부여 (authorization) 확장 기능, 그리고 Python, TypeScript, Go, C# 전반에 걸친 베타 SDK입니다.

이러한 변화들은 함께 세 가지 핵심 프로덕션 과제인 상태 비저장 확장 (stateless scaling), 중앙 집중식 ID 관리 (centralized identity management), 그리고 프로토콜 버전 안정성 (protocol version stability)을 해결합니다.

상태 비저장 코어: 핸드셰이크 없는 확장

2026–07–28 사양은 상태 유지 핸드셰이크 (stateful handshake) 및 세션 관리를 제거합니다. 초기화/초기화됨 (initialize/initialized) 핸드셰이크가 사라졌으며, 프로토콜 수준의 세션도 사라졌습니다. 이제 클라이언트 정보, 프로토콜 버전, 그리고 기능 (capabilities)은 모든 호출 시 요청의 _meta 필드에 포함되어 전달되므로, 각 요청이 스스로를 설명할 수 있게 됩니다.

이를 통해 원격 서버는 세션 어피니티 (session affinity)나 동기화 없이 표준 라운드 로빈 (round-robin) 로드 밸런서 뒤에서 실행될 수 있습니다. 어떤 인스턴스든 핸드셰이크를 먼저 재현하거나 공유 세션 상태를 조회할 필요 없이 모든 요청에 응답할 수 있습니다.

표준 도구 호출 (tool call)은 이제 사전 초기화가 필요하지 않으며 모든 컨텍스트를 자체적으로 포함합니다:

POST /mcp HTTP/1.1
Mcp-Protocol-Version: 2026–07–28
Mcp-Method: tools/call
...

_meta 블록은 클라이언트 ID와 프로토콜 버전을 전달합니다. Mcp-Method 및 Mcp-Name HTTP 헤더를 통해 로드 밸런서나 게이트웨이는 JSON 페이로드 본문을 파싱하지 않고도 호출을 라우팅할 수 있습니다.

프로토콜이 이제 상태 비저장(stateless) 방식이 되었기 때문에, 서버는 입력을 요청하기 위해 활성 연결(active connection)을 더 이상 중단할 수 없습니다. 대신, 사양(spec)은 다중 왕복 요청(Multi Round-Trip Requests)을 도입합니다. 도구(tool)가 입력이 필요한 경우, 서버는 불투명한(opaque) requestState를 포함하는 InputRequiredResult를 반환합니다. 그러면 클라이언트는 사용자의 입력과 requestState 토큰을 함께 전달하여 도구 호출을 다시 호출(re-invoke)해야 합니다. 이러한 설계는 연결을 계속 유지하지 않고도 사용 가능한 어떤 인스턴스라도 응답을 처리할 수 있게 해줍니다.

이 상태 비저장(stateless) 모델은 클라이언트 기능(capabilities)과 세션 파라미터(session parameters)가 매 호출마다 전송되어야 하므로 요청 페이로드(request payload) 크기를 증가시킵니다. 하지만 이는 다음과 같은 표준 프로덕션 기능들을 가능하게 합니다: 완전한 JSON Schema 2020–12 검증, 캐시 제어 힌트(cache-control hints; ttlMs 및 cacheScope), OpenTelemetry를 위한 W3C Trace Context 전파, 그리고 모듈형 확장 프레임워크(modular extensions framework)입니다. 처음 두 가지 공식 확장 기능은 MCP Apps(샌드박스화된 HTML 기반 사용자 인터페이스)와 Tasks의 상태 비저장(stateless) 버전입니다.

중앙 집중식 ID: 기업 관리형 권한 부여 (enterprise-managed authorization)

수평적 확장(horizontal scaling)을 넘어, 팀 전체에 걸쳐 MCP 서버 액세스를 관리하려면 중앙 집중식 권한 부여(central authorization)가 필요합니다. 표준 사용자별 OAuth 흐름은 모든 직원이 각 MCP 서버를 개별적으로 승인하도록 강제하며, 이는 온보딩(onboarding)을 복잡하게 만들고, 중앙 집중식 감사 로그(audit logs)가 부족하며, 개인용 및 기업용 액세스가 혼재되는 문제를 야기합니다.

이를 해결하기 위해, 기업 관리형 권한 부여 확장 기능(2026년 6월 안정화)은 ID-JAG(Identity Assertion JWT Authorization Grant)를 구현합니다. 단일 로그인(SSO) 중에 클라이언트는 RFC 8693 토큰 교환(token exchange)을 통해 사용자의 ID 토큰을 특정 대상 서버로 범위가 제한된(scoped) ID-JAG로 교환합니다. 그런 다음 클라이언트는 이 권한 부여(grant)를 MCP 서버의 권한 부여 서버(authorization server)에 제시하여 액세스 토큰(access token)을 얻습니다. 이 토큰 교환은 완전히 백그라운드에서 실행되므로, 개별적인 대화형 동의 화면이 필요하지 않습니다:

1. IdP: SSO 신원을 단일 MCP 서버 전용 권한으로 교환

grant_type=urn:ietf:params:oauth:grant-type:token-exchange
requested_token_type=urn:ietf:params:oauth:token-type:id-jag
...

액세스 제어(Access control)는 조직의 기존 ID 제공자 (IdP, Identity Provider) 그룹 및 역할에 의해 관리됩니다. 관리자는 단일 제어 평면(control plane)에서 권한을 구성할 수 있으며, 모든 액세스는 중앙 집중식 감사 추적(audit trails)을 생성합니다.

이 확장 기능은 추가적이며 선택 사항(opt-in)입니다. 소비자용 구성의 경우 기본값은 사용자별 OAuth로 유지됩니다. MCP 서버는 엔터프라이즈 관리형 권한 부여(authorization) 지원 여부를 기능(capability)으로서 광고하며, 클라이언트는 연결 중에 이를 협상합니다. IdP는 정책을 검증하고 권한(grant)을 발행할 뿐이며, 이는 IdP가 원시 MCP 트래픽을 절대 가로채지 않음을 의미합니다. 또한 각 액세스 토큰(access token)은 대상 서버로 엄격하게 수신자 제한(audience-restricted)됩니다.

버전 안정성: 출시 폐기 기간 및 SDK 베타

프로토콜을 장기 로드맵에 적합하게 만들기 위해, MCP는 공식 사양 수명 주기(specification lifecycle)를 도입했습니다. 이제 기능은 최소 12개월의 폐기 기간(deprecation window)을 거쳐 활성(Active) → 폐기(Deprecated) → 제거(Removed) 상태를 통과합니다. 또한, 표준 트랙(Standards Track)에 대한 제안된 변경 사항은 공식 준수 스위트(conformance suite)를 통해 검증되어야 하며, 사양은 달력 날짜별로 버전이 지정됩니다.

2026-07-28 개정판에서는 몇 가지 레거시 기능(Roots, Sampling, Logging)이 폐기됩니다. 이 기능들은 도구 파라미터(tool parameters), 리소스 URI(resource URIs), 직접 제공자 API(direct provider APIs), 그리고 표준 에러 출력 또는 OpenTelemetry 스트림으로 대체될 예정입니다.

7월 28일 최종 사양 출시 전에 팀들이 이러한 변경 사항을 검증할 수 있도록, 프로젝트는 4가지 언어에 대해 베타 SDK를 공개했습니다:

# Python - 선택적 사전 출시 버전 (opt-in pre-release)
pip install "mcp[cli]==2.0.0b1"
# TypeScript v2 - 새로운 분리형 서버/클라이언트 패키지
...

기존 v1 SDK 라인은 최종 릴리스 이후 최소 6개월 동안 버그 및 보안 패치를 제공받게 됩니다. 하위 호환성 (Backward compatibility)은 유지됩니다. 즉, v2 서버는 기존의 2025-11-25 핸드셰이크 (handshake) 요청을 계속 수락하므로, 클라이언트가 독립적으로 업그레이드할 수 있습니다.

프로덕션 환경에서 에이전트 (agents)를 운영하는 팀에게 의미하는 바

MCP는 이제 Linux Foundation 산하의 Agentic AI Foundation에 의해 호스팅됩니다. 이러한 개방형 거버넌스 (open governance) 모델은 활발한 유지 관리자 (maintainers)들이 주도하는 집중적인 사양 (specification) 개선 프로세스를 유지하면서도 중립적인 관리 (stewardship)를 보장합니다. 예측 가능한 릴리스 주기 (release cadence), 공식적인 지원 종료 (deprecation) 일정, 그리고 적합성 테스트 (conformance testing)를 구현함으로써, MCP는 불안정한 라이브러리가 아닌 신뢰할 수 있는 인프라 표준으로 자리 잡게 됩니다.

2026-07-28 사양 확정 (specification locking)이 7월 말로 예정되어 있고 SDK 베타 버전이 사용 가능함에 따라, 배포 시 다음 사항들을 검토해야 합니다:

세션 의존성 (session dependencies) 식별. 만약 귀하의 설정이 스티키 라우팅 (sticky routing) 또는 공유 세션 테이블에 의존하고 있다면, 상태가 없는 (stateless) 코어로 마이그레이션함으로써 표준 라운드 로빈 (round-robin) 로드 밸런싱으로 전환할 수 있으며 인프라를 단순화할 수 있습니다.

온보딩 흐름 (onboarding flow) 평가. 만약 현재 서버가 개별 사용자 동의 리다이렉트 (consent redirects)를 요구한다면, 역할 기반 권한 부여 (role-based authorization)를 활성화하기 위해 귀하의 IdP와 클라이언트가 새로운 엔터프라이즈 토큰 교환 (enterprise token-exchange) 확장을 지원하는지 확인하십시오.

버전 마이그레이션 (version migrations) 계획. 만약 귀하의 시스템이 기존 2025-11-25 사양에 고정되어 있다면, 12개월의 지원 종료 (deprecation) 기간을 활용하여 도구 (tool) 및 리소스 시그니처 (resource signatures) 업데이트 계획을 수립하십시오.