아키텍처

Model Context Protocol (MCP)은 각 호스트(host)가 여러 클라이언트 인스턴스를 실행할 수 있는 클라이언트-호스트-서버 아키텍처를 따릅니다. 이 아키텍처는 명확한 보안 경계를 유지하고 관심사를 분리하면서 애플리케이션 전반에 AI 기능을 통합할 수 있게 합니다. JSON-RPC 위에 구축된 MCP는 클라이언트와 서버 간의 컨텍스트 교환 및 샘플링(sampling) 조율에 초점을 맞춘 상태 유지(stateful) 세션 프로토콜을 제공합니다.

핵심 구성 요소

graph LR
    subgraph "Application Host Process"
        H[Host]
        C1[Client 1]
        C2[Client 2]
        C3[Client 3]
        H --> C1
        H --> C2
        H --> C3
    end

    subgraph "Local machine"
        S1[Server 1<br>Files & Git]
        S2[Server 2<br>Database]
        R1[("Local<br>Resource A")]
        R2[("Local<br>Resource B")]

        C1 --> S1
        C2 --> S2
        S1 <--> R1
        S2 <--> R2
    end

    subgraph "Internet"
        S3[Server 3<br>External APIs]
        R3[("Remote<br>Resource C")]

        C3 --> S3
        S3 <--> R3
    end

호스트(Host)

호스트 프로세스는 컨테이너이자 조율자 역할을 합니다:

• 여러 클라이언트 인스턴스를 생성하고 관리합니다
• 클라이언트 연결 권한과 수명 주기를 제어합니다
• 보안 정책과 동의 요구사항을 적용합니다
• 사용자 인증 결정을 처리합니다
• AI/LLM 통합 및 샘플링을 조율합니다
• 클라이언트 전반의 컨텍스트 집계를 관리합니다

클라이언트(Clients)

각 클라이언트는 호스트에 의해 생성되며 격리된 서버 연결을 유지합니다:

• 서버당 하나의 상태 유지 세션을 수립합니다
• 프로토콜 협상 및 기능 교환을 처리합니다
• 프로토콜 메시지를 양방향으로 라우팅합니다
• 구독(subscriptions)과 알림(notifications)을 관리합니다
• 서버 간 보안 경계를 유지합니다

호스트 애플리케이션은 여러 클라이언트를 생성하고 관리하며, 각 클라이언트는 특정 서버와 1:1 관계를 가집니다.

서버(Servers)

서버는 특화된 컨텍스트와 기능을 제공합니다:

• MCP 프리미티브(primitives)를 통해 리소스(resources), 도구(tools), 프롬프트(prompts)를 노출합니다
• 집중된 책임을 가지고 독립적으로 동작합니다
• 클라이언트 인터페이스를 통해 샘플링을 요청합니다
• 보안 제약을 준수해야 합니다
• 로컬 프로세스 또는 원격 서비스로 운영될 수 있습니다

설계 원칙

MCP는 아키텍처와 구현에 영향을 미치는 몇 가지 핵심 설계 원칙을 기반으로 합니다:

1. 서버는 극도로 쉽게 구축할 수 있어야 합니다 * 호스트 애플리케이션이 복잡한 오케스트레이션 책임을 처리합니다 * 서버는 특정하고 잘 정의된 기능에 집중합니다 * 단순한 인터페이스로 구현 부담을 최소화합니다 * 명확한 분리로 유지 보수 가능한 코드를 가능하게 합니다

2. 서버는 고도로 조합 가능해야 합니다 * 각 서버는 격리된 상태에서 집중된 기능을 제공합니다 * 여러 서버를 원활하게 결합할 수 있습니다 * 공유 프로토콜이 상호 운용성을 가능하게 합니다 * 모듈형 설계가 확장성을 지원합니다

3. 서버는 전체 대화를 읽거나 다른 서버를 "들여다볼" 수 없어야 합니다 * 서버는 필요한 컨텍스트 정보만 수신합니다 * 전체 대화 이력은 호스트에 남아 있습니다 * 각 서버 연결은 격리를 유지합니다 * 서버 간 상호작용은 호스트가 제어합니다 * 호스트 프로세스가 보안 경계를 적용합니다

4. 기능은 서버와 클라이언트에 점진적으로 추가될 수 있어야 합니다 * 핵심 프로토콜은 최소한의 필수 기능을 제공합니다 * 추가 기능은 필요에 따라 협상할 수 있습니다 * 서버와 클라이언트는 독립적으로 발전합니다 * 프로토콜은 향후 확장성을 위해 설계되었습니다 * 하위 호환성이 유지됩니다

기능 협상(Capability Negotiation)

Model Context Protocol은 클라이언트와 서버가 초기화 중에 지원하는 기능을 명시적으로 선언하는 기능 기반 협상 시스템을 사용합니다. 기능(capabilities)은 세션 중에 사용 가능한 프로토콜 기능과 프리미티브를 결정합니다.

• 서버는 리소스 구독, 도구 지원, 프롬프트 템플릿과 같은 기능을 선언합니다
• 클라이언트는 샘플링 지원 및 알림 처리와 같은 기능을 선언합니다
• 양측은 세션 전반에 걸쳐 선언된 기능을 준수해야 합니다
• 추가 기능은 프로토콜 확장을 통해 협상할 수 있습니다

sequenceDiagram
    participant Host
    participant Client
    participant Server

    Host->>+Client: Initialize client
    Client->>+Server: Initialize session with capabilities
    Server-->>Client: Respond with supported capabilities

    Note over Host,Server: Active Session with Negotiated Features

    loop Client Requests
        Host->>Client: User- or model-initiated action
        Client->>Server: Request (tools/resources)
        Server-->>Client: Response
        Client-->>Host: Update UI or respond to model
    end

    loop Server Requests
        Server->>Client: Request (sampling)
        Client->>Host: Forward to AI
        Host-->>Client: AI response
        Client-->>Server: Response
    end

    loop Notifications
        Server--)Client: Resource updates
        Client--)Server: Status changes
    end

    Host->>Client: Terminate
    Client->>-Server: End session
    deactivate Server

각 기능은 세션 중에 사용할 특정 프로토콜 기능을 잠금 해제합니다. 예를 들어:

• 구현된 서버 기능은 서버의 기능(capabilities)에 명시되어야 합니다
• 리소스 구독 알림을 발행하려면 서버가 구독 지원을 선언해야 합니다
• 도구 호출에는 서버가 도구 기능을 선언해야 합니다
• 샘플링에는 클라이언트가 기능에서 지원을 선언해야 합니다

이러한 기능 협상은 클라이언트와 서버가 프로토콜 확장성을 유지하면서 지원되는 기능을 명확히 이해할 수 있도록 합니다.

원문(영어): https://modelcontextprotocol.io/specification/2025-11-25/architecture/index · 본 문서는 학습용 한국어 번역이며 원본의 권리는 원저작자(Model Context Protocol)에게 있습니다.

원문(영어): https://modelcontextprotocol.io/specification/2025-11-25/architecture/index