아키텍처의 변화: 상태 유지 세션(Stateful Sessions)에서 상태가 없는(Stateless) 핵심으로

Model Context Protocol (MCP)이 처음 도입되었을 때, 이는 매우 중요하고 즉각적인 문제, 즉 대규모 언어 모델 (LLMs)에 데이터를 읽고 도구를 실행할 수 있는 표준화된 방법을 어떻게 제공할 것인가라는 문제를 해결했습니다. 하지만 프로토콜의 초기 버전은 로컬 중심의 개발자 지향적 사용 사례에 크게 영향을 받았습니다. 이들은 표준 입출력 (stdio) 또는 단일 테넌트 (single-tenant) WebSockets를 통한 상태 유지 (stateful) 방식의 장기 연결에 의존했습니다. 이는 데스크톱 기반 AI 어시스턴트와 로컬 IDE 통합에는 매우 효과적이었으나, 이러한 시스템을 엔터프라이즈급 멀티 테넌트 (multi-tenant) 클라우드 환경으로 확장할 때는 거대한 아키텍처 병목 현상을 초래했습니다.

에이전트 아키텍처를 설계하는 과정에서, 저는 상태 유지 (stateful) 프로토콜이 운영 워크로드 하에서 어떻게 성능을 저하시키는지 반복적으로 목격해 왔습니다. 수천 개의 동시 에이전트 세션을 위해 지속적인 연결을 관리하는 것은 심각한 연결 고갈, 복잡한 상태 동기화 (state-synchronization) 문제, 그리고 표준 클라우드 네이티브 부하 분산 (load-balancing) 인프라를 사용할 수 없는 문제로 이어집니다.

Model Context Protocol Spec 2026-07-28의 출시는 엔터프라이즈 AI 엔지니어링의 분수령이 됩니다. 상태가 없는 (stateless) 핵심 구조로 진화함으로써, 프로토콜은 전송 계층 (transport layer)을 실행 컨텍스트 (execution context)로부터 분리합니다. 이를 통해 우리는 MCP 서버를 수평 확장이 가능한 상태가 없는 (stateless) 마이크로서비스 (microservices)로 취급할 수 있습니다. 이 글에서 저는 이러한 전환의 아키텍처적 메커니즘을 분석하고, 새로운 엔터프라이즈 권한 부여 (authorization) 패러다임을 검토하며, 공식 C# SDK v2.0 업데이트를 평가하고, 여러분의 에이전트 인프라를 이 새로운 표준으로 마이그레이션하기 위한 구체적인 구현 청사진을 제공합니다.

2026-07-28 사양(specification)이 왜 이토록 중대한 도약인지 이해하려면, 먼저 이전 버전의 MCP에서 상태(state)가 어떻게 관리되었는지 살펴보아야 합니다. 초기 프로토콜에서 MCP 서버는 특정 클라이언트와 활성 세션(active session)을 유지했습니다. 서버는 종종 세션별 변수, 협상 상태(negotiation states), 그리고 리소스 잠금(resource locks)을 메모리에 유지했습니다. 만약 연결이 끊어지면 전체 세션 상태가 손실되었으며, 이는 비용이 많이 드는 재초기화 핸드셰이크(re-initialization handshake)를 요구했습니다.

이러한 상태 유지(stateful) 모델은 현대적인 클라우드 네이티브 확장 패턴(cloud-native scaling patterns)과 근본적으로 호환되지 않습니다. 만약 전통적인 MCP 서버를 표준 HTTP 로드 밸런서(load balancer) 뒤에 배치한다면, 동일한 에이전트로부터 오는 후속 요청들이 서로 다른 컨테이너 인스턴스(container instances)에 도달할 수 있습니다. 복잡한 스티키 세션(sticky-session) 설정 없이는 시스템이 깨지게 되는데, 이러한 설정은 그 자체로 새로운 장애 모드(failure modes)와 불균형한 리소스 활용을 초래합니다.

2026-07-28 사양은 상태가 없는(stateless) 코어를 의무화함으로써 이 문제를 해결합니다. 이 패러다임에서 MCP 서버는 자신이 연속적이고 전용된 파이프(dedicated pipe)를 통해 단일 클라이언트와 통신하고 있다고 가정하지 않습니다. 대신, 모든 JSON-RPC 요청은 자기 완결적(self-contained)이도록 설계되었습니다. 프로토콜은 다음과 같은 몇 가지 핵심 메커니즘을 통해 이를 달성합니다:

• 분리된 전송 추상화 (Decoupled Transport Abstraction): 프로토콜은 JSON-RPC 메시지 계층을 하부 전송 계층 (underlying transport)으로부터 공식적으로 분리합니다. 요청이 HTTP POST, 서버 전송 이벤트 (SSE), 또는 메시지 브로커 (message broker)를 통해 전달되든 관계없이, 서버는 이를 동일하게 처리합니다.
• 명시적인 요청 범위 컨텍스트 (Explicit Request-Scoped Context): 도구 실행 (tool execution), 리소스 읽기 (resource read), 또는 프롬프트 템플릿 (prompt template)을 처리하는 데 필요한 모든 상태는 반드시 요청 페이로드 (request payload) 내에 명시적으로 전달되어야 합니다. 서버는 순수 함수 (pure function)로 동작합니다. 즉, 입력 컨텍스트를 받아 요청된 작업을 실행하고 출력을 반환합니다.
• 멱등적 핸드셰이크 및 기능 협상 (Idempotent Handshakes and Capabilities Negotiation): MCP 1.0에서는 클라이언트와 서버의 기능 (capabilities)이 연결 시작 시점에 한 번 협상되어 메모리에 저장되었습니다. 2026-07-28 사양에 따르면, 기능은 메타데이터 엔드포인트 (metadata endpoints)를 통해 정적으로 선언되거나 요청 봉투 (request envelope) 내에서 동적으로 전달되므로, 서버가 클라이언트 상태를 추적할 필요가 없습니다.

상태 관리 (state management)의 부담을 클라이언트나 중앙 집중식 상태 저장소 (Redis와 같은)로 다시 넘김으로써, 이제 MCP 서버를 가볍고 일시적인 (ephemeral) 컨테이너로 배포할 수 있습니다. 서버 인스턴스가 종료되더라도 로드 밸런서 (load balancer)는 에이전트의 실행 흐름에 중단 없이 다음 요청을 정상적인 컨테이너로 라우팅하기만 하면 됩니다.

Model Context Protocol (MCP) 2026-07-28 사양에 대한 심층 분석. 상태가 없는 (stateless) 코어로의 전환, 엔터프라이즈급 권한 부여 (authorization), 그리고 새로운 C# SDK v2.0이 어떻게 수평적 확장을 가능하게 하는지 알아보세요.

엔터프라이즈 권한 부여 및 요청 범위 컨텍스트 (Enterprise Authorization and Request-Scoped Context)

로컬 개발 환경에서는 권한 부여 (Authorization)가 문제가 되는 경우가 거의 없습니다. MCP 서버가 사용자의 로컬 머신에서 실행되며 사용자의 사용자 권한을 상속받기 때문입니다. 하지만 엔터프라이즈 환경에서는 이것이 보안상의 악몽이 될 수 있습니다. MCP 서버는 민감한 데이터베이스, 내부 API 또는 독점적인 문서 저장소에 접근할 수 있습니다. 우리는 LLM 에이전트가 엄격하고, 감사 가능하며, 동적인 권한 부여 없이 이러한 리소스에 접근하는 것을 허용할 수 없습니다.

이전 버전의 MCP는 강력하고 표준화된 권한 부여 모델이 부족했기 때문에, 보안 팀은 커스텀 방식의 별도(out-of-band) 인증 메커니즘을 구현해야만 했습니다. 이는 종종 페이로드(Payload)를 검사하는 커스텀 API 게이트웨이로 MCP 서버를 감싸거나, 서버 설정에 정적 API 키를 하드코딩하는 방식을 포함했습니다.

2026-07-28 사양은 네이티브한 요청 범위(Request-scoped) 권한 부여를 도입함으로써 이 문제를 해결합니다. 핵심이 상태가 없는(Stateless) 방식이기 때문에, 권한 부여는 연결 시점에 한 번만 설정될 수 없으며, 모든 개별 상호작용에 대해 검증되어야 합니다.

이제 프로토콜은 JSON-RPC 요청 엔벨로프(Envelope) 내에 권한 부여 메타데이터를 직접 전달하는 것을 공식적으로 지원합니다. 이는 일반적으로 JSON-RPC 페이로드 내의 표준화된 meta 필드를 사용하여 수행되며, 여기에는 암호학적으로 서명된 토큰(JWT 등) 또는 위임 자격 증명(Delegation credentials)이 포함됩니다.

에이전트가 도구 실행(Tool execution)을 요청할 때, 흐름은 다음과 같이 진행됩니다:

• Token Acquisition (토큰 획득): 에이전트 게이트웨이(Agentic gateway) 또는 오케스트레이터(Orchestrator)가 최종 사용자를 대신하여 OAuth2 액세스 토큰(Access token) 또는 범위가 지정된 세션 토큰(Scoped session token)을 획득합니다.
• Payload Enrichment (페이로드 보강): 게이트웨이는 이 토큰을 MCP 요청의 meta.authorization 필드에 주입합니다.
• Upstream Verification (업스트림 검증): 상태가 없는(Stateless) MCP 서버가 요청을 수신하고, 토큰을 추출하여 기업의 ID 제공업체(IdP)를 통해 검증하거나, JWT를 로컬에서 복호화하여 클레임(Claims) 및 스코프(Scopes)를 확인합니다.
• Contextual Execution (문맥적 실행): 도구는 인증된 사용자의 엄격한 보안 문맥(Security context) 내에서 실행됩니다. 서버는 이 토큰을 절대 저장하지 않으며, 요청 라이프사이클(Request lifecycle)이 완료되는 즉시 폐기됩니다.

이러한 접근 방식은 완전한 감사 가능성(Auditability)을 보장합니다. 모든 리소스 접근 또는 도구 실행은 특정 사용자, 에이전트 세션 및 권한 부여(Authorization grant)로 추적될 수 있으며, 이는 엄격한 기업 컴플라이언스 요구 사항(SOC 2 및 ISO 27001 등)을 충족합니다.

프로덕션 환경에서의 부하 분산(Load Balancing) 및 수평 확장(Horizontal Scaling)

상태가 없는(Stateless) 코어로 전환하면 MCP 인프라를 설계하고 배포하는 방식이 완전히 바뀝니다. 취약한 지속적 WebSocket 연결망을 관리하는 대신, 이제 MCP 서버를 다른 REST 또는 gRPC 마이크로서비스(Microservice)와 동일하게 취급할 수 있습니다. 이를 통해 업계 표준인 인그레스 컨트롤러(Ingress controller) 및 서비스 메시(Service mesh)를 활용할 수 있습니다.

프로덕션급 MCP 클러스터를 설계할 때, 저는 MCP 서버 앞에 API 게이트웨이(Envoy, Kong 또는 AWS API Gateway 등)를 배치하는 것을 권장합니다. 게이트웨이는 TLS 터미네이션(Termination), 글로벌 속도 제한(Rate limiting) 및 초기 JWT 검증을 처리합니다. 그런 다음 Kubernetes와 같은 컨테이너 오케스트레이터(Container orchestrator)에서 실행되는 MCP 서버 풀(Pool) 전체로 상태가 없는 JSON-RPC 요청을 라우팅합니다.

서버가 상태가 없기(stateless) 때문에, 표준 라운드 로빈(round-robin) 또는 최소 연결(least-connections) 부하 분산(load-balancing) 알고리즘을 사용할 수 있습니다. 이는 상태가 있는(stateful) 시스템에서 흔히 발생하는 "핫스팟(hotspotting)" 현상을 방지합니다. 핫스팟 현상이란 특정 서버 인스턴스가 매우 활발하고 오래 지속되는 에이전트 세션에 결합되어 과부하가 걸리는 반면, 다른 인스턴스들은 유휴 상태로 남아 있는 현상을 말합니다.

나아가, 이 아키텍처는 원활한 수평적 오토스케일링(horizontal autoscaling)을 가능하게 합니다. CPU 사용률이나 HTTP 요청 동시성(concurrency)과 같은 표준 지표를 기반으로 MCP 서버 배포를 확장하도록 쿠버네티스 수평적 포드 오토스케일러(Kubernetes Horizontal Pod Autoscaler, HPA)를 구성할 수 있습니다. 에이전트 활동이 많은 기간 동안에는 새로운 포드(pod)가 생성되며, 세션 테이블을 동기화하거나 연결을 재설정할 필요 없이 즉시 요청을 처리하기 시작합니다. 반대로 활동이 적은 기간에는 최소한의 점유율(footprint)로 규모를 축소하여 클라우드 인프라 비용을 크게 절감할 수 있습니다.

새로운 패러다임의 구현: C# SDK v2.0 실무 적용

이러한 아키텍처의 진화를 지원하기 위해 공식 SDK들이 대대적인 재작성을 거쳤습니다. 특히 공식 MCP C# SDK v2.0의 출시는 엔터프라이즈 개발자들에게 매우 주목할 만합니다. .NET 10 및 .NET 11을 위해 처음부터 구축된 v2.0 SDK는 상태가 없는(stateless) 패러다임을 완전히 수용하여, 네이티브 의존성 주입(dependency injection), 고성능 메모리 맵 직렬화(memory-mapped serialization), 그리고 ASP.NET Core 통합에 대한 일급 지원(first-class support)을 제공합니다.

이전 버전의 C# SDK에서는 서버를 설정하기 위해 전송 계층(transport layer)과 도구 등록(tool registration)이 밀접하게 결합된 모놀리식(monolithic) McpServer 클래스를 인스턴스화해야 했습니다. v2.0에서는 이러한 관심사들이 깔끔하게 분리되었습니다. 이제 도구를 상태가 없는 서비스로 정의하고, 들어오는 JSON-RPC 요청을 문맥에 맞게(contextually) 처리하는 실행 파이프라인(execution pipeline)에 등록하면 됩니다.

다음은 C# SDK v2.0을 사용하여 상태가 없는(stateless) MCP 서버를 구현한 매우 실용적이고 프로덕션 환경에 즉시 적용 가능한(production-ready) 구현 예시입니다. 이 예제는 ASP.NET Core minimal API 엔드포인트를 구성하여 상태가 없는 JSON-RPC 요청을 수신하고, 요청 범위(request-scoped)의 권한 부여 메타데이터를 추출하며, 도구(tool)를 안전하게 실행하는 방법을 보여줍니다:

using System.Text.Json;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Http;
...

이 구현은 2026-07-28 사양(specification)의 탁월함을 잘 보여줍니다. ASP.NET Core 엔드포인트는 완전히 상태가 없습니다(stateless). 모든 요청은 파싱되고, 들어오는 요청에서 추출된 보안 문맥(security context)으로 보강되며, 처리된 후 반환됩니다. 메모리 내 세션 딕셔너리(in-memory session dictionaries)를 유지하지 않으므로, 이 애플리케이션은 대규모 Kubernetes 클러스터나 AWS Fargate 또는 Azure Container Apps와 같은 서버리스(serverless) 환경에 배포하기에 완벽하게 적합합니다.

마이그레이션 전략 및 운영상의 트레이드오프 (Operational Trade-offs)

기존 MCP 인프라를 2026-07-28 사양으로 마이그레이션하려면 세심한 계획이 필요합니다. 단순히 스위치를 전환하는 것만으로는 불가능하며, 기존 에이전트와 서버의 아키텍처적 가정(architectural assumptions)을 체계적으로 업데이트해야 합니다.

이 전환을 평가하는 데 도움이 되도록, 기존 MCP 1.0 사양과 새로운 2026-07-28 상태가 없는(stateless) 사양 간의 운영 패러다임 비교를 정리했습니다:

단계별 마이그레이션 체크리스트

프로덕션 에이전트 워크로드를 새로운 사양으로 마이그레이션할 계획이라면, 다음과 같은 구조화된 로드맵을 따를 것을 권장합니다: