로컬 장난감에서 클라우드 웹 표준으로: MCP v2 아키텍처 대개편과 무상태(Stateless) 전환

Anthropic이 주도하고 리눅스 재단(Agentic AI Foundation)에 기부된 Model Context Protocol (MCP)은 AI 에이전트와 외부 도구·데이터를 연결하는 사실상 업계 표준으로 자리 잡았다.

초기 MCP(v1)는 데스크톱 단일 머신에서 실행되는 도구 연결기에 가까웠다. Claude Desktop이나 Cursor 같은 로컬 클라이언트가 PC 내부의 스크립트를 stdio 파이프로 엮는 데 집중했기 때문이다. 이 설계는 엔터프라이즈 클라우드 환경으로 넘어가는 순간 심각한 아키텍처 한계에 부딪혔다.

공식 공개된 MCP v2 스펙과 신규 SDK는 단순한 라이브러리 리팩토링이 아니다. 로컬 프로세스 연결 규격을 클라우드 분산 환경과 멀티 에이전트 인프라를 지탱하는 웹 표준 에이전트 프로토콜로 전면 전환한 구조 개편이다.

---

1. 로컬 세션의 한계: 왜 MCP v1은 클라우드에서 무너졌는가?

MCP v1의 통신 모델은 연결 세션(Stateful Session)을 기반으로 설계되었다. 클라이언트가 서버에 접속하면 initialize 핸드셰이크를 거쳐 상호 지원 기능을 교환하고, 프로세스가 살아있는 동안 서버 메모리에 세션 상태를 유지하는 방식이었다.

[ 기존 MCP v1: Stateful 세션 모델의 병목 ]

Client  ──(1. initialize 세션 협상)──>  Load Balancer  ──>  MCP Server Pod A (세션 메모리 보존)
Client  ──(2. tools/call 실행 요청)───>  Load Balancer  ──>  MCP Server Pod B (세션 유실! 에러 발생)

이 구조는 단일 로컬 환경에서는 문제없이 작동한다. 클라우드 인프라에 배포되는 순간 세 가지 병목을 유발했다:

1. 세션 불일치(Session Mismatch): L4/L7 로드 밸런서 뒤에 다중 컨테이너를 배치하면, 1차 초기화 요청을 처리한 서버와 2차 도구 호출을 수신한 서버가 달라진다. 후속 서버는 이전 세션 메모리를 알지 못하므로 요청을 거부한다.
2. 스티키 세션(Sticky Session)의 비효율: 세션 일치를 위해 특정 컨테이너로 클라이언트 트래픽을 고정하면 트래픽 분산 효율이 무너진다. 특정 인스턴스 장애 시 세션 페일오버 처리가 까다로워진다.
3. 리소스 낭비: 수천 개의 에이전트가 접속할 때마다 서버 메모리에 세션 다리(State Bridge)를 유지해야 하므로 유휴 상태에서도 메모리 점유율이 선형 증가한다.

---

2. 핵심 변화 1: Stateful 세션에서 무상태(Stateless) Request-Response로 전환

MCP v2 스펙의 핵심은 세션의 영구 유지 개념을 폐기하고 무상태(Stateless) 아키텍처를 전면 도입한 데 있다.

🔍 클릭하여 확대

flowchart TD
    Client["AI 에이전트 (Client)"] --> LB["L7 로드 밸런서 (Reverse Proxy)"]

    subgraph Cluster["무상태 MCP 서버 클러스터"]
        LB -->|Request 1: 자급자족 컨텍스트| PodA["MCP Server Pod A<br>(독립 처리 후 소켓 해제)"]
        LB -->|Request 2: 토큰 기반 후속 호출| PodB["MCP Server Pod B<br>(공유 Redis/DB 참조)"]
        LB -->|Request N: 수평 확장 부하 분산| PodC["MCP Server Pod C"]
    end

    PodA -.-> Storage[("공유 세션 스토리지<br>(PostgreSQL / Redis)")]
    PodB -.-> Storage
    PodC -.-> Storage
  

자급자족 요청(Self-Contained Request) 모델

모든 도구 호출 요청은 실행에 필요한 인증 토큰, 파라미터, 실행 컨텍스트를 자체 페이로드에 포함해 전송한다. 서버는 클라이언트와의 이전 대화 이력을 로컬 메모리에 기억할 필요가 없다.

탄력적 수평 확장(Scale-out)

트래픽이 폭증하면 무상태 MCP 컨테이너를 수십 대에서 수백 대로 즉시 복제해 증설한다. 클라이언트의 1차 요청이 Pod A로 향하고 2차 요청이 Pod B로 라우팅되어도, Pod B는 공유 캐시나 요청 본문만으로 작업을 완결한다. 인프라 복원력과 클라우드 배포 효율이 전통적 RESTful 마이크로서비스 수준으로 격상된다.

---

3. 핵심 변화 2: 서버 역호출을 종식시킨 MRTR (Multi-Round-Trip Requests)

초기 MCP에서 가장 이질적이었던 요소는 서버에서 클라이언트로의 역방향 요청(Server-to-Client Request)이었다. 도구 실행 중 사용자 확인(Human-In-The-Loop)이나 추가 입력이 필요할 때, 서버가 클라이언트를 콜백 호출하는 비대칭 구조였다.

[ 기존 역호출 방식 ]
Client ──(tools/call: DB 삭제)──> Server
Client <──(역호출: "정말 삭제합니까?")── Server  <-- 웹 방화벽·프록시 차단 위험!

이 방식은 웹 게이트웨이, Nginx 리버스 프록시, 기업 방화벽 환경에서 치명적인 문제를 일으킨다. 대부분의 웹 인프라는 단방향 요청-응답을 전제하기 때문이다. 전이중(Full-duplex) 파이프를 유지하지 못하면 연결이 끊기며, 서버와 클라이언트가 서로의 역할을 뒤바꾸며 복잡한 상태 머신 교착 상태를 만든다.

MCP v2는 이 역호출을 전면 폐지하고 MRTR(Multi-Round-Trip Requests) 패턴을 확립했다.

🔍 클릭하여 확대

sequenceDiagram
    autonumber
    actor User as 사용자
    participant Client as AI 에이전트 클라이언트
    participant Server as 무상태 MCP 서버

    Client->>Server: tools/call (delete_database)
    Note over Server: 추가 승인(HITL) 필요 감지
    Server-->>Client: 200 OK { status: "need_info", continuation_token: "tok_xyz987" }
    Note over Server: 연결 즉시 종결 (서버 상태 보관 안 함)

    Client->>User: "운영 DB 삭제 승인이 필요합니다. 진행할까요?"
    User-->>Client: "승인 완료"

    Client->>Server: tools/resume { token: "tok_xyz987", approved: true }
    Note over Server: 토큰 검증 후 나머지 로직 수행
    Server-->>Client: 200 OK { status: "success", result: "Deleted" }
  

MRTR 처리 메커니즘

1. 1차 요청 종결: 서버는 실행 도중 사용자 개입이 필요하면 응답 소켓을 쥐고 대기하지 않는다. 필요한 상태를 암호화된 continuation_token에 담아 클라이언트에 정상 응답(Finish)을 반환하고 트랜잭션을 끝낸다.
2. 클라이언트 주도권 확보: 에이전트 클라이언트는 사용자 UI 모달을 띄우거나 자체 판단을 거친 뒤 추가 데이터를 수집한다. 서버의 타임아웃 압박을 받지 않는다.
3. 2차 후속 요청: 클라이언트는 수집한 데이터와 토큰을 실어 새로운 요청(tools/resume)을 전송한다. 이 요청은 완전히 다른 서버 인스턴스가 받아도 토큰 복호화를 통해 즉시 후속 작업을 이어간다.

---

4. 핵심 변화 3: 프로토콜 정화(Sanitization) — 강결합의 제거

엔터프라이즈 환경에서 보안과 책임 분리는 타협 대상이 아니다. v2 스펙은 경계를 흐리던 v1의 유산 기능을 과감히 정리했다.

구분	v1 레거시 사양	v2 표준 사양	개편 사유 및 보안적 이점
LLM 추론 위임	Sampling (서버가 클라이언트 LLM 호출)	완전 폐지 (Deprecated)	악의적 도구가 클라이언트 토큰 비용을 탕진하거나 탈옥 프롬프트 주입 방지
파일 경로 노출	Roots (클라이언트 파일 경로 목록 전송)	완전 폐지 (Deprecated)	클라우드 환경에서 무의미한 로컬 경로 노출 차단, resources URI로 대체
전송 계층 (Transport)	stdio, WebSocket, SSE 파편화	stdio 및 Streamable HTTP 단일화	상태 유지형 웹소켓 제거, L7 로드밸런서 친화적 HTTP 스트리밍 통일
상태 변경 알림	도구별 개별 이벤트	subscriptions/listen 단일화	이벤트 구독 버스 인터페이스 표준화

Sampling 폐지의 의의

Sampling은 도구 서버가 "내가 처리하기 복잡하니 클라이언트 너의 LLM을 돌려 결과를 달라"고 요구하는 기능이었다. 이는 오케스트레이터와 도구의 책임 역전을 초래했다. 서드파티 MCP 서버가 사용자의 유료 API 크레딧을 무단 소진하거나 시스템 프롬프트를 탈취할 보안 구멍으로 작동할 위험이 컸다. v2에서는 이 기능을 완전히 걷어내고, 필요한 모든 추론 지휘권을 클라이언트 하네스에 귀속시켰다.

---

5. 개발자 경험 혁신: Python SDK v2와 MCPServer

프로토콜 스펙 정비에 발맞춰 개발자 인터페이스도 대폭 간소화되었다.

FastMCP의 정식화: MCPServer

실험적 기능에 붙던 FastMCP 명칭을 버리고 공식 MCPServer 클래스를 정식 지원한다. 기존 직관적인 데코레이터 구문은 그대로 유지된다.

from mcp.server import MCPServer

app = MCPServer(name="production-analytics")

@app.tool(
    name="query_metrics",
    description="지정된 기간의 시스템 지표를 조회합니다.",
    cache_ttl=60  # v2 신규: 캐싱 수명 힌트 제공
)
async def query_metrics(metric_name: str, duration_minutes: int = 5) -> dict:
    return {"metric": metric_name, "value": 98.4, "status": "healthy"}

인프로세스(In-process) 단위 테스트

v1에서는 MCP 서버를 검증하려면 실제 서브프로세스를 띄우거나 소켓을 열어야 했다. v2 SDK의 Client는 메모리 상의 MCPServer 인스턴스에 직접 바인딩된다.

import pytest
from mcp.client import Client
from my_service import app

@pytest.mark.asyncio
async def test_metrics_tool():
    # 서브프로세스 기동 없이 인메모리 직접 바인딩
    async with Client(app) as client:
        result = await client.call_tool(
            "query_metrics",
            {"metric_name": "cpu_usage"}
        )
        assert result.content["value"] == 98.4
        assert not result.is_error  # camelCase 대신 pythonic snake_case 사용

CI 파이프라인에서 네트워크 포트 충돌이나 프로세스 좀비화 없이 밀리초 단위로 수백 개의 도구 단위 테스트를 통과시킨다. 속성명 역시 JavaScript식 isError, inputSchema에서 파이썬 관례인 is_error, input_schema로 정비되었다.

---

6. 시스템 아키텍처 관점의 시사점

이번 MCP v2 전환은 에이전트 엔지니어링 생태계에 명확한 기준을 제시한다:

• 소프트웨어 공학 원칙의 회귀: AI 에이전트 기술도 결국 분산 시스템의 기본 법칙인 무상태성, 단방향 요청-응답, 격리된 실패 도메인을 따라야 생존한다.
• 예측 가능한 하네스 구축: 서버의 기습적인 양방향 콜백에 기대지 않고, 다단계 트랜잭션(MRTR)을 클라이언트 오케스트레이터가 명시적으로 통제할 때 프로덕션 신뢰성이 완성된다.
• 엔터프라이즈 통합 표준의 확립: stdio는 로컬 개발과 서브프로세스 CLI에 집중하고, Streamable HTTP는 클라우드 게이트웨이 표준으로 자리잡았다.

MCP는 로컬 데스크톱의 실험 도구를 넘어 분산 멀티 에이전트 인프라의 표준 전송 계층으로 체질을 바꿨다.