LOTS-OResearch Notes

TL;DR

  • MCP는 JSON-RPC 메시지를 실어 나르는 전송으로 stdio와 Streamable HTTP 두 가지를 쓴다.
  • stdio는 로컬 통합에 맞는다. 클라이언트가 서버를 subprocess로 띄워 해당 프로세스와 1:1로 쓰며(해당 프로세스를 다른 클라이언트가 공유하진 못한다), stdout에 로그를 남기면 안 된다.
  • Streamable HTTP는 원격 다중 클라이언트에 맞는다. POST 응답은 단일 JSON이거나 요청 범위 SSE이며(항상 SSE가 아님), 구 HTTP+SSE 전송과 다른 현행 방식이다.
  • 고를 때는 대체로 배포 위치·동시 클라이언트 수를 보지만, HTTP는 localhost에도 쓰며 프로세스 수명·인증·네트워크 경계도 함께 고려한다.

MCP 전송은 stdio와 Streamable HTTP 중에 고른다

전송(transport)은 클라이언트와 서버 사이에서 메시지를 실어 나르는 통신 방법이다. 메시지 형식JSON-RPC가 정한다. MCP에는 두 표준 전송이 있고 고르는 기준은 서버를 어디에 두고 몇 명이 붙느냐다.

두 전송

stdio는 클라이언트가 서버를 자식 프로세스로 띄우고 표준 입력·출력 스트림으로 JSON-RPC를 주고받는다.

  • 네트워크가 필요 없어 설정이 간단하다.
  • 클라이언트가 서버를 직접 spawn하므로 그 프로세스는 띄운 클라이언트 하나와 1:1로 묶인다. 한 stdio 서버 프로세스를 여러 클라이언트가 공유하지는 못한다. 대신 각 앱은 같은 서버 프로그램을 자기 프로세스로 따로 띄운다(Claude Desktop·VS Code·Codex가 각자 인스턴스). 여러 앱이 동시에 쓰는 것 자체는 가능하다.
  • stdout은 프로토콜 채널이므로 로그를 찍으면 메시지가 깨진다. 로그는 stderr로 보낸다.
  • 로컬 개발 도구, 데스크톱 앱, IDE 확장에 적합하다.

Streamable HTTP는 클라이언트가 네트워크로 서버에 접속해 POST를 보낸다. 서버는 응답을 단일 JSON으로 주거나 스트리밍이 필요하면 요청 범위 SSE로 준다. 2025-03-26부터의 현행 정식 명칭이다. 구 HTTP+SSE 전송은 상시 SSE 스트림(서버→클라이언트)과 별도 POST(클라이언트→서버)를 함께 써서 연결을 계속 유지해야 했던 옛 원격 전송이다. Streamable HTTP는 이를 단일 엔드포인트로 합쳤다.

  • 원격 접속과 다중 클라이언트를 지원한다.
  • 웹 서비스로 배포할 수 있다.
  • 클라우드·다중 사용자 환경에 적합하다.

선택 기준

기준stdioStreamable HTTP
배포 위치로컬원격
서버 프로세스클라이언트가 spawn, 1:1(공유 불가·앱마다 자기 인스턴스)상주 프로세스에 다중 연결
네트워크불필요필요
설정 복잡도낮음중간
대표 용도데스크톱·IDE 통합클라우드 API 서비스

이 표는 설계 휴리스틱이다. 스펙이 강제하는 규칙은 아니다. Streamable HTTP는 localhost에서도 쓸 수 있고, 실제 선택에는 프로세스 수명·인증·네트워크 경계·배포 모델이 함께 든다.

stdio subprocess·Streamable HTTP 실행 코드는 2025-11-30-[MCP-Study]-MCP 서버·클라이언트 구현 코드 레퍼런스 참조.

버전 주의

Streamable HTTP의 세부는 버전에 따라 다르다. 2025-11-25는 POST 응답 SSE 외에 독립 GET SSE도 허용한다. 2026-07-28은 요청 범위 SSE와 subscriptions/listen 장기 POST 응답 스트림으로 정리했다. SSE는 HTTP 응답 스트림이며 WebSocket Upgrade를 요구하지 않는다. 2025-11-25 Transports, 2026-07-28 Streamable HTTP. 서버리스·엣지 배포와 무상태 코어의 세부는 Model Context Protocol 2026-07-28 사양은 핸드셰이크와 프로토콜 세션을 없앤다를 참조한다.


Connections