전송

Transports · 원문: modelcontextprotocol.io/specification/2025-11-25/basic/transports

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

MCP는 메시지를 인코딩하기 위해 JSON-RPC를 사용합니다. JSON-RPC 메시지는 반드시 UTF-8로 인코딩되어야 합니다(MUST).

프로토콜은 현재 클라이언트-서버 통신을 위한 두 가지 표준 전송 메커니즘을 정의합니다:

stdio — 표준 입력 및 표준 출력을 통한 통신
Streamable HTTP

클라이언트는 가능한 경우 항상 stdio를 지원해야 합니다(SHOULD).

클라이언트와 서버는 플러그인 방식으로 사용자 정의 전송(custom transports)을 구현할 수도 있습니다.

stdio

stdio 전송에서:

클라이언트는 MCP 서버를 서브프로세스로 실행합니다.
서버는 표준 입력(stdin)에서 JSON-RPC 메시지를 읽고 표준 출력(stdout)으로 메시지를 전송합니다.
메시지는 개별 JSON-RPC 요청, 알림 또는 응답입니다.
메시지는 개행 문자로 구분되며, 내장 개행 문자를 포함해서는 안 됩니다(MUST NOT).
서버는 정보, 디버그, 오류 메시지 등 로깅 목적으로 표준 오류(stderr)에 UTF-8 문자열을 작성할 수 있습니다(MAY).
클라이언트는 서버의 stderr 출력을 캡처, 전달하거나 무시할 수 있으며, stderr 출력이 오류 조건을 나타낸다고 가정해서는 안 됩니다(SHOULD NOT).
서버는 유효한 MCP 메시지가 아닌 것은 stdout에 작성해서는 안 됩니다(MUST NOT).
클라이언트는 유효한 MCP 메시지가 아닌 것은 서버의 stdin에 작성해서는 안 됩니다(MUST NOT).

코드 · 명령

sequenceDiagram
    participant Client
    participant Server Process

    Client->>+Server Process: Launch subprocess
    loop Message Exchange
        Client->>Server Process: Write to stdin
        Server Process->>Client: Write to stdout
        Server Process--)Client: Optional logs on stderr
    end
    Client->>Server Process: Close stdin, terminate subprocess
    deactivate Server Process

Streamable HTTP

참고: 이는 프로토콜 버전 2024-11-05의 HTTP+SSE 전송을 대체합니다. 아래 하위 호환성 가이드를 참조하세요.

Streamable HTTP 전송에서 서버는 여러 클라이언트 연결을 처리할 수 있는 독립 프로세스로 운영됩니다. 이 전송은 HTTP POST와 GET 요청을 사용합니다. 서버는 선택적으로 Server-Sent Events (SSE)를 사용하여 여러 서버 메시지를 스트리밍할 수 있습니다. 이를 통해 기본 MCP 서버뿐만 아니라 스트리밍과 서버-클라이언트 알림 및 요청을 지원하는 더 풍부한 서버도 가능합니다.

서버는 POST와 GET 메서드를 모두 지원하는 단일 HTTP 엔드포인트 경로(MCP 엔드포인트라고 함)를 제공해야 합니다(MUST). 예를 들어 https://example.com/mcp와 같은 URL일 수 있습니다.

보안 경고

Streamable HTTP 전송을 구현할 때:

서버는 DNS 재바인딩 공격을 방지하기 위해 모든 수신 연결의 Origin 헤더를 검증해야 합니다(MUST) * Origin 헤더가 있고 유효하지 않으면 서버는 HTTP 403 Forbidden으로 응답해야 합니다(MUST)
로컬에서 실행할 때 서버는 모든 네트워크 인터페이스(0.0.0.0) 대신 localhost(127.0.0.1)에만 바인딩해야 합니다(SHOULD)
서버는 모든 연결에 적절한 인증을 구현해야 합니다(SHOULD)

이러한 보호 없이는 공격자가 DNS 재바인딩을 사용하여 원격 웹사이트에서 로컬 MCP 서버와 상호작용할 수 있습니다.

서버로 메시지 전송

클라이언트가 전송하는 모든 JSON-RPC 메시지는 MCP 엔드포인트에 대한 새로운 HTTP POST 요청이어야 합니다(MUST).

클라이언트는 MCP 엔드포인트로 JSON-RPC 메시지를 전송하기 위해 HTTP POST를 사용해야 합니다(MUST).
클라이언트는 application/json과 text/event-stream 모두를 지원 콘텐츠 타입으로 나열하는 Accept 헤더를 포함해야 합니다(MUST).
POST 요청 본문은 단일 JSON-RPC 요청, 알림, 또는 응답이어야 합니다(MUST).
입력이 JSON-RPC 응답 또는 알림인 경우: * 서버가 입력을 수락하면 본문 없이 HTTP 상태 코드 202 Accepted를 반환해야 합니다(MUST). * 서버가 입력을 수락할 수 없으면 HTTP 오류 상태 코드를 반환해야 합니다(MUST).
입력이 JSON-RPC 요청인 경우, 서버는 SSE 스트림을 시작하기 위해 Content-Type: text/event-stream을 반환하거나, 하나의 JSON 객체를 반환하기 위해 Content-Type: application/json을 반환해야 합니다(MUST).
서버가 SSE 스트림을 시작하는 경우: * 서버는 즉시 이벤트 ID와 빈 data 필드로 구성된 SSE 이벤트를 전송해야 합니다(SHOULD). * 연결 해제는 클라이언트가 요청을 취소한 것으로 해석해서는 안 됩니다(SHOULD NOT). * 취소하려면 클라이언트는 MCP CancelledNotification을 명시적으로 전송해야 합니다(SHOULD).

서버에서 메시지 수신

클라이언트는 MCP 엔드포인트에 HTTP GET을 발행하여 SSE 스트림을 열 수 있습니다(MAY).
클라이언트는 text/event-stream을 지원 콘텐츠 타입으로 나열하는 Accept 헤더를 포함해야 합니다(MUST).
서버는 Content-Type: text/event-stream을 반환하거나 HTTP 405 Method Not Allowed를 반환해야 합니다(MUST).
서버가 SSE 스트림을 시작하는 경우: * 서버는 스트림에서 JSON-RPC 요청과 알림을 전송할 수 있습니다(MAY). * 서버는 이전 스트림을 재개하는 경우를 제외하고 스트림에서 JSON-RPC 응답을 전송해서는 안 됩니다(MUST NOT).

다중 연결

클라이언트는 여러 SSE 스트림에 동시에 연결된 상태를 유지할 수 있습니다(MAY).
서버는 각 JSON-RPC 메시지를 연결된 스트림 중 하나에만 전송해야 합니다(MUST).

재개 가능성 및 재전달

서버는 SSE 이벤트에 id 필드를 첨부할 수 있습니다(MAY). * ID는 세션 내 모든 스트림에서 전역적으로 고유해야 합니다(MUST).
연결 해제 후 재개하려는 클라이언트는 Last-Event-ID 헤더와 함께 HTTP GET을 발행해야 합니다(SHOULD). * 서버는 마지막 이벤트 ID 이후 메시지를 재전달할 수 있습니다(MAY).

세션 관리

서버는 InitializeResult 응답의 MCP-Session-Id 헤더에 세션 ID를 할당할 수 있습니다(MAY). * 세션 ID는 전역적으로 고유하고 암호학적으로 안전해야 합니다(SHOULD). * 세션 ID는 가시적 ASCII 문자(0x21~0x7E)만 포함해야 합니다(MUST).
MCP-Session-Id가 반환된 경우, 클라이언트는 이후 모든 HTTP 요청에 이를 포함해야 합니다(MUST).
서버는 세션을 종료할 수 있으며, 이후 해당 세션 ID가 포함된 요청에 HTTP 404 Not Found로 응답해야 합니다(MUST).
클라이언트가 HTTP 404를 수신하면 새 세션을 시작해야 합니다(MUST).
더 이상 세션이 필요 없는 클라이언트는 MCP 엔드포인트에 HTTP DELETE를 전송해야 합니다(SHOULD).

시퀀스 다이어그램

코드 · 명령

sequenceDiagram
    participant Client
    participant Server

    note over Client, Server: initialization

    Client->>+Server: POST InitializeRequest
    Server->>-Client: InitializeResponse<br>MCP-Session-Id: 1868a90c...

    Client->>+Server: POST InitializedNotification<br>MCP-Session-Id: 1868a90c...
    Server->>-Client: 202 Accepted

    note over Client, Server: client requests
    Client->>+Server: POST ... request ...<br>MCP-Session-Id: 1868a90c...

    alt single HTTP response
      Server->>Client: ... response ...
    else server opens SSE stream
      loop while connection remains open
          Server-)Client: ... SSE messages from server ...
      end
      Server-)Client: SSE event: ... response ...
    end
    deactivate Server

    note over Client, Server: client notifications/responses
    Client->>+Server: POST ... notification/response ...<br>MCP-Session-Id: 1868a90c...
    Server->>-Client: 202 Accepted

    note over Client, Server: server requests
    Client->>+Server: GET<br>MCP-Session-Id: 1868a90c...
    loop while connection remains open
        Server-)Client: ... SSE messages from server ...
    end
    deactivate Server

프로토콜 버전 헤더

HTTP를 사용하는 경우 클라이언트는 모든 후속 요청에 MCP-Protocol-Version: <protocol-version> HTTP 헤더를 포함해야 합니다(MUST).

예: MCP-Protocol-Version: 2025-11-25

클라이언트가 전송하는 프로토콜 버전은 초기화 중에 협상된 버전이어야 합니다(SHOULD).

하위 호환성을 위해 서버가 MCP-Protocol-Version 헤더를 수신하지 못한 경우 프로토콜 버전 2025-03-26을 가정해야 합니다(SHOULD).

서버가 유효하지 않거나 지원하지 않는 MCP-Protocol-Version을 수신하면 400 Bad Request로 응답해야 합니다(MUST).

하위 호환성

이전 클라이언트를 지원하려는 서버는 이전 전송의 SSE 및 POST 엔드포인트를 새 MCP 엔드포인트와 함께 계속 호스팅해야 합니다.

이전 서버를 지원하려는 클라이언트는 다음을 수행해야 합니다:

사용자로부터 MCP 서버 URL을 수락합니다.
서버 URL에 InitializeRequest를 POST 시도합니다. * 성공하면 Streamable HTTP 전송을 가정합니다. * 400, 404, 또는 405로 실패하면: SSE 스트림을 기대하며 GET 요청을 발행합니다.

사용자 정의 전송(Custom Transports)

클라이언트와 서버는 특정 요구에 맞는 추가 사용자 정의 전송 메커니즘을 구현할 수 있습니다(MAY). 사용자 정의 전송은 JSON-RPC 메시지 형식과 수명 주기 요구사항을 보존해야 합니다(MUST). 사용자 정의 전송은 상호 운용성을 위해 연결 수립 및 메시지 교환 패턴을 문서화해야 합니다(SHOULD).

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

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

문서 이동

‹ 수명 주기 인가 › · 전체 목차