byteforce

CPN 한국어 자습서 · 외부 문서 한국어 미러

MCP 문서 · Specification

수명 주기

Lifecycle · 원문: modelcontextprotocol.io/specification/2025-11-25/basic/lifecycle

아래는 원문을 한국어로 옮긴 미러입니다. 코드·명령은 원문 그대로이며, 가장 최신 정보는 하단 원문 링크에서 확인하세요.

Model Context Protocol (MCP)은 적절한 기능 협상 및 상태 관리를 보장하는 클라이언트-서버 연결에 대한 엄격한 수명 주기를 정의합니다.

  1. 초기화(Initialization): 기능 협상 및 프로토콜 버전 합의
  2. 동작(Operation): 일반적인 프로토콜 통신
  3. 종료(Shutdown): 연결의 정상적인 종료
코드 · 명령
sequenceDiagram
    participant Client
    participant Server

    Note over Client,Server: Initialization Phase
    activate Client
    Client->>+Server: initialize request
    Server-->>Client: initialize response
    Client--)Server: initialized notification

    Note over Client,Server: Operation Phase
    rect rgb(200, 220, 250)
        note over Client,Server: Normal protocol operations
    end

    Note over Client,Server: Shutdown
    Client--)-Server: Disconnect
    deactivate Server
    Note over Client,Server: Connection closed

수명 주기 단계

초기화(Initialization)

초기화 단계는 클라이언트와 서버 간의 첫 번째 상호작용이어야 합니다(MUST). 이 단계에서 클라이언트와 서버는:

클라이언트는 다음을 포함하는 initialize 요청을 전송하여 이 단계를 시작해야 합니다(MUST):

코드 · 명령
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "initialize",
  "params": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "roots": {
        "listChanged": true
      },
      "sampling": {},
      "elicitation": {
        "form": {},
        "url": {}
      },
      "tasks": {
        "requests": {
          "elicitation": {
            "create": {}
          },
          "sampling": {
            "createMessage": {}
          }
        }
      }
    },
    "clientInfo": {
      "name": "ExampleClient",
      "title": "Example Client Display Name",
      "version": "1.0.0",
      "description": "An example MCP client application",
      "icons": [
        {
          "src": "https://example.com/icon.png",
          "mimeType": "image/png",
          "sizes": ["48x48"]
        }
      ],
      "websiteUrl": "https://example.com"
    }
  }
}

서버는 자체 기능과 정보를 응답해야 합니다(MUST):

코드 · 명령
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "protocolVersion": "2025-11-25",
    "capabilities": {
      "logging": {},
      "prompts": {
        "listChanged": true
      },
      "resources": {
        "subscribe": true,
        "listChanged": true
      },
      "tools": {
        "listChanged": true
      },
      "tasks": {
        "list": {},
        "cancel": {},
        "requests": {
          "tools": {
            "call": {}
          }
        }
      }
    },
    "serverInfo": {
      "name": "ExampleServer",
      "title": "Example Server Display Name",
      "version": "1.0.0",
      "description": "An example MCP server providing tools and resources",
      "icons": [
        {
          "src": "https://example.com/server-icon.svg",
          "mimeType": "image/svg+xml",
          "sizes": ["any"]
        }
      ],
      "websiteUrl": "https://example.com/server"
    },
    "instructions": "Optional instructions for the client"
  }
}

초기화가 성공적으로 완료된 후, 클라이언트는 일반 운영을 시작할 준비가 되었음을 나타내기 위해 initialized 알림을 보내야 합니다(MUST):

코드 · 명령
{
  "jsonrpc": "2.0",
  "method": "notifications/initialized"
}

버전 협상(Version Negotiation)

initialize 요청에서 클라이언트는 지원하는 프로토콜 버전을 전송해야 합니다(MUST). 이는 클라이언트가 지원하는 최신 버전이어야 합니다(SHOULD).

서버가 요청된 프로토콜 버전을 지원하는 경우 동일한 버전으로 응답해야 합니다(MUST). 그렇지 않으면 서버는 지원하는 다른 프로토콜 버전으로 응답해야 합니다(MUST). 이는 서버가 지원하는 최신 버전이어야 합니다(SHOULD).

클라이언트가 서버 응답의 버전을 지원하지 않는 경우 연결을 끊어야 합니다(SHOULD).

참고: HTTP를 사용하는 경우 클라이언트는 MCP 서버에 대한 모든 후속 요청에 MCP-Protocol-Version: <protocol-version> HTTP 헤더를 반드시 포함해야 합니다. 자세한 내용은 전송의 프로토콜 버전 헤더 섹션을 참조하세요.

기능 협상(Capability Negotiation)

클라이언트와 서버 기능은 세션 중에 사용 가능한 선택적 프로토콜 기능을 결정합니다.

주요 기능은 다음과 같습니다:

카테고리 기능 설명
Client roots 파일시스템 루트(roots) 제공 능력
Client sampling LLM 샘플링(sampling) 요청 지원
Client elicitation 서버 생성 요청(elicitation) 지원
Client tasks 태스크 보강(task-augmented) 클라이언트 요청 지원
Client experimental 비표준 실험적 기능 지원 여부
Server prompts 프롬프트 템플릿(prompt templates) 제공
Server resources 읽기 가능한 리소스(resources) 제공
Server tools 호출 가능한 도구(tools) 노출
Server logging 구조화된 로그 메시지(log messages) 발행
Server completions 인수 자동 완성(autocompletion) 지원
Server tasks 태스크 보강(task-augmented) 서버 요청 지원
Server experimental 비표준 실험적 기능 지원 여부

기능 객체는 다음과 같은 하위 기능을 설명할 수 있습니다:

동작(Operation)

동작 단계에서 클라이언트와 서버는 협상된 기능에 따라 메시지를 교환합니다.

양측은 다음을 반드시 해야 합니다:

종료(Shutdown)

종료 단계에서 한쪽(보통 클라이언트)이 프로토콜 연결을 깔끔하게 종료합니다. 특정 종료 메시지는 정의되지 않으며, 대신 기반 전송 메커니즘을 사용하여 연결 종료를 신호해야 합니다:

stdio

stdio 전송(transport)의 경우 클라이언트는 다음과 같이 종료를 시작해야 합니다(SHOULD):

  1. 먼저 자식 프로세스(서버)에 대한 입력 스트림을 닫습니다
  2. 서버가 종료될 때까지 기다리거나, 합리적인 시간 내에 서버가 종료되지 않으면 SIGTERM을 보냅니다
  3. SIGTERM 후 합리적인 시간 내에 서버가 종료되지 않으면 SIGKILL을 보냅니다

서버는 클라이언트에 대한 출력 스트림을 닫고 종료하여 종료를 시작할 수 있습니다(MAY).

HTTP

HTTP 전송(transports)의 경우 종료는 관련 HTTP 연결을 닫음으로써 표시됩니다.

타임아웃(Timeouts)

구현체는 연결 중단과 리소스 고갈을 방지하기 위해 모든 전송 요청에 타임아웃을 설정해야 합니다(SHOULD). 요청이 타임아웃 기간 내에 성공 또는 오류 응답을 받지 못한 경우, 발신자는 해당 요청에 대한 취소 알림(cancellation notification)을 발행하고 응답 기다리기를 중단해야 합니다(SHOULD).

SDK 및 기타 미들웨어는 이러한 타임아웃을 요청별로 구성할 수 있어야 합니다(SHOULD).

구현체는 요청에 해당하는 진행 알림(progress notification)을 수신할 때 타임아웃 클럭을 리셋하도록 선택할 수 있습니다(MAY). 이는 실제로 작업이 진행 중임을 의미하기 때문입니다. 그러나 구현체는 오작동하는 클라이언트나 서버의 영향을 제한하기 위해 진행 알림에 관계없이 항상 최대 타임아웃을 적용해야 합니다(SHOULD).

오류 처리(Error Handling)

구현체는 다음 오류 케이스를 처리할 준비가 되어 있어야 합니다(SHOULD):

초기화 오류 예시:

코드 · 명령
{
  "jsonrpc": "2.0",
  "id": 1,
  "error": {
    "code": -32602,
    "message": "Unsupported protocol version",
    "data": {
      "supported": ["2024-11-05"],
      "requested": "1.0.0"
    }
  }
}

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

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