AI 모델을 외부 도구 및 기업 데이터와 연결하기 위한 발전 중인 표준인 Model Context Protocol (MCP)이 상당한 아키텍처 변화를 겪고 있습니다. 곧 출시될 버전은 상태 비저장 아키텍처 (Stateless Architecture)를 구현하여 프로토콜 수준의 세션 (Session)을 제거함으로써, AI 이니셔티브가 프로덕션 (Production) 단계로 전환됨에 따라 표준 클라우드 인프라 전반에 걸친 배포를 단순화합니다.

이 근본적인 변화는 MCP 역사상 가장 큰 아키텍처 개편을 의미합니다. 업계 전문가들은 이번 변경이 MCP를 현대적인 클라우드 환경에 더 적합하게 만들고 확장(Scale)을 용이하게 하는 것을 목표로 한다고 지적합니다. 세션 기반 모델 (Session-based model)은 로컬 개발에는 적합했지만, 프로덕션 환경에서는 상당한 운영상의 장애물을 초래했습니다.

클라우드 네이티브 확장성을 위한 재구성

Model Context Protocol의 이전 반복 버전들은 각 클라이언트 연결에 대한 지속적인 정보를 유지했습니다. 이는 서버가 상호작용 전반에 걸쳐 개별 세션을 추적해야 함을 의미했습니다. 로컬 개발에는 효과적이었지만, 이 방식은 여러 서버에 걸친 배포를 복잡하게 만들었습니다. 요청이 세션을 시작한 특정 머신으로 다시 라우팅되어야 하는 경우가 빈번하여 전체적인 확장성 (Scalability)을 제한했습니다. 이러한 설계는 MCP를 현대적인 클라우드 아키텍처에 덜 자연스러운 적합성을 갖게 만들었습니다.

ZopDev의 클라우드 어소시에이트(Cloud Associate)인 Muskan Bandta는 이전의 세션 기반 모델이 프로덕션에서 운영 부담이 되었다고 언급합니다. 인프라 팀이 MCP가 다른 클라우드 애플리케이션처럼 확장할 수 있는 능력에 대해 문의했을 때, 답변은 종종 모호했습니다. 상태 비저장 아키텍처 (Stateless architecture)로의 전환과 함께, 그 답변은 결정적으로 긍정적으로 바뀝니다.

새로운 상태 비저장 (Stateless) 설계는 모든 요청이 사용 가능한 어떤 서버라도 독립적으로 처리할 수 있도록 필요한 모든 정보를 포함하도록 보장합니다. 여러 요청에 걸쳐 컨텍스트 (Context)를 유지해야 하는 애플리케이션도 여전히 이를 달성할 수 있지만, 이제 개발자가 해당 상태를 명시적으로 관리해야 합니다. 이는 프로토콜 자체가 상태 관리 (State management)를 담당했던 이전 버전들과 대조됩니다. 이러한 변화는 프로토콜이 세션 데이터 (Session data)를 유지해야 하는 부담에서 벗어나게 하여, 분산 시스템 (Distributed systems)에서 더욱 유연하고 효율적인 리소스 할당을 가능하게 합니다.

IT 컨설팅 기업 Kanerika의 AI 개발 매니저인 Amit Jena는 이러한 전환이 단순한 인프라 단순화를 넘어선다고 설명합니다. 이는 AI 애플리케이션이 다양한 도구 간에 컨텍스트를 관리하고 공유하는 방식을 근본적으로 재편합니다. 새로운 설계는 애플리케이션 상태를 외부화하여 투명하게 만듭니다. 이를 통해 AI 모델이 도구 간에 이 정보를 직접 액세스하고, 해석하며, 전달할 수 있게 됩니다. 개발자는 자신의 툴체인 (Toolchains) 내에서 컨텍스트 보존 및 공유에 대해 더 큰 제어권을 갖게 됩니다. 이러한 움직임은 또한 AI 워크플로 (Workflows)를 더욱 이식성 있고, 탄력적이며, 분산 환경에서 오케스트레이션 (Orchestrate)하기 더 단순하게 만들 것입니다.

MCP의 혁신 및 기능 향상

업데이트된 Model Context Protocol은 기능과 통합을 개선하기 위해 설계된 몇 가지 새로운 기능을 도입합니다. 중요한 추가 사항 중 하나는 다중 왕복 요청 (Multi Round-Trip Requests, MRTR) 메커니즘입니다. 이는 AI 에이전트가 주어진 작업을 완료하는 데 필요한 추가 정보를 요청하는 방식을 변경합니다. 상호작용 내내 클라이언트와 서버 간의 지속적인 연결에 의존하는 대신, MRTR 메커니즘은 서버가 작업을 진행하기 전에 표준 요청-응답 (Request-response) 교환을 통해 추가 입력을 요청할 수 있도록 합니다. 이는 유연성을 높이고 지속적인 연결에 대한 의존도를 줄여 상호작용을 더욱 효율적으로 만듭니다.

또 다른 핵심 기능은 라우팅 가능한 전송 헤더(routable transport headers)의 도입입니다. 이러한 헤더를 통해 API 게이트웨이 및 기타 네트워킹 인프라는 MCP 요청의 내용을 검사할 필요 없이 요청을 식별하고 라우팅할 수 있습니다. Jena에 따르면, 이는 처리 오버헤드(processing overhead)를 줄이고 지연 시간(latency)을 낮춥니다. 또한 기업 팀이 기존의 API 관리 인프라를 사용하여 라우팅, 속도 제한(rate-limiting) 및 보안 정책을 더욱 효과적으로 강제할 수 있도록 지원합니다. 이는 심층 패킷 검사(deep packet inspection)를 요구하지 않고도 네트워크 운영을 간소화하고 보안을 강화합니다.

새로운 MCP 릴리스에는 업데이트된 권한 부여(authorization) 프레임워크도 포함되어 있습니다. 이 프레임워크는 업계 표준인 OAuth 2.1 및 OpenID Connect를 기반으로 구축되어 강력하고 안전한 인증(authentication) 기능을 제공합니다. 또한, 이제 프로토콜은 더욱 역동적이고 몰입감 있는 사용자 경험을 촉진할 수 있는 대화형 MCP 앱(interactive MCP Apps)을 지원합니다. 도구(tool) 및 리소스 목록의 결정론적 캐싱(Deterministic caching)도 추가되어 대규모 언어 모델(LLM)의 프롬프트 캐시 적중률(prompt-cache hit rates)을 개선했습니다. 이러한 개선은 LLM에 대한 중복 요청을 줄임으로써 토큰 비용을 크게 절감할 수 있는 잠재력을 가지고 있습니다. 이러한 새로운 기능들은 집합적으로 프로토콜의 역량을 강화하여, 광범위한 AI 애플리케이션에 대해 더욱 안전하고 효율적이며 다재다능하게 만듭니다.

아키텍처의 변화 및 지원 중단되는 기능 (Deprecated Capabilities)

MCP 릴리스 운영 위원회는 이번 업데이트에서 여러 레거시(legacy) 기능을 지원 중단(deprecate)하기로 의도적인 결정을 내렸습니다. 여기에는 Roots, Sampling, Logging, 이전의 HTTP+SSE 전송 방식, 그리고 동적 클라이언트 등록(Dynamic Client Registration)이 포함됩니다. 이러한 기능들은 현재 버전과 향후 1년 동안 출시될 버전에서는 계속 작동하겠지만, 궁극적인 제거는 프로토콜의 미래를 향한 명확한 방향을 나타냅니다. 개발자들은 향후 MCP 반복 버전과의 호환성을 유지하기 위해 이러한 구성 요소들로부터 전환할 계획을 세워야 합니다.

폐기 예정인 기능 중 Sampling은 파운데이션 모델 (Foundation Model)과의 상호작용을 위한 신뢰 경계 (Trust Boundary)를 근본적으로 변경하기 때문에 가장 큰 영향을 미칠 것으로 예상됩니다. Jena는 기존의 Sampling 방식이 MCP 서버가 클라이언트를 통해 LLM을 호출할 수 있게 하여, 서버가 해당 연결을 직접 소유하지 않고도 모델로 이어지는 콜백 경로 (Callback Path)를 생성했었다고 설명합니다. 이 기능을 폐기함에 따라 해당 신뢰 경계를 재구축해야 합니다. 새로운 패러다임 하에서는 서버가 모델 제공자 (Model Provider)를 직접 호출합니다. 이러한 변화는 AI 애플리케이션의 다양한 측면에 영향을 미치며, 비용 귀속 (Cost Attribution) 구조에 따라 네트워크 아키텍처, 인증 모델 (Authentication Models), 그리고 잠재적으로 결제 흐름 (Billing Flows)에 영향을 줄 수 있습니다.

1년의 전환 기간은 팀들이 기존의 Sampling 의존성을 감사 (Audit)할 수 있는 충분한 시간을 제공합니다. 그러나 Jena는 특히 제3자 (Third-party) MCP 서버를 사용하는 경우, 이러한 의존성을 식별하는 것이 항상 간단하지 않을 수 있다고 경고합니다. Sampling을 직접 구현하지 않은 팀은 의존 중인 MCP 서버가 이를 활용하고 있는지 인지하지 못할 수도 있습니다. 이러한 숨겨진 의존성은 전환 과정에서 문제를 일으킬 수 있으며, 원활한 마이그레이션 (Migration)을 보장하기 위해 세심한 조사가 필요합니다.

업데이트된 SDK를 통한 전환 지원

이 프로토콜 업데이트를 지원하기 위해 Python, Typescript, Go, C#용 새로운 Model Context Protocol SDK가 제공됩니다. 이 업데이트된 SDK들은 이전 버전과 새로운 프로토콜 버전을 모두 지원하도록 설계되었습니다. 이러한 이중 버전 호환성 (Dual-version Compatibility) 덕분에 최신 SDK로 개발된 새로운 클라이언트는 기존 서버와 계속해서 효과적으로 통신할 수 있습니다. 반대로, 업데이트된 서버는 여전히 이전 클라이언트를 지원하므로 전환 기간 동안 발생할 수 있는 즉각적인 중단 위험을 크게 줄여줍니다.

이러한 하위 호환성(backward compatibility)은 출시 전략의 핵심 요소이며, 대부분의 사용자에게 전환 과정을 점진적인 단계로 만들어 줍니다. 하지만 MCP의 초기 세션 기반 아키텍처(session-based architecture)에 맞춰 맞춤형 인프라를 구축해 온 기업들은 더 큰 어려움에 직면할 수 있습니다. 이러한 복잡한 세션 의존성(session dependencies)을 식별하고 감사(auditing)하는 것은 매우 복잡한 작업이 될 수 있습니다.

Jena는 세션 관리의 복잡성이 IT 환경의 여러 계층에 걸쳐 숨겨져 있는 경우가 많다고 경고합니다. 여기에는 게이트웨이 설정(gateway configurations), 배포 스크립트(deployment scripts), 그리고 모니터링 대시보드(monitoring dashboards)가 포함됩니다. 세션 의존성을 제거하기 위한 실제 코드 변경은 미미할 수 있지만, 세션 가정이 존재하는 모든 지점을 찾아내는 과정은 상당한 시간과 자원을 소모할 수 있습니다. 따라서 성공적인 마이그레이션(migration)을 위해서는 철저한 계획과 세밀한 감사가 필수적이며, 특히 맞춤형 시스템이 깊게 통합된 조직일수록 더욱 그러합니다.