Streamable HTTP 전송은 MCP 클라이언트가 HTTP 연결을 통해 원격으로 호스팅되는 서버에 연결할 수 있게 해줍니다. 클라이언트와 서버가 동일한 머신에 있어야 하는 표준 I/O 전송과 달리, 이 전송 방식은 누구나 접근할 수 있는 공개 MCP 서버의 가능성을 열어줍니다.
하지만 중요한 주의사항이 있습니다. 일부 구성 설정은 MCP 서버의 기능을 크게 제한할 수 있습니다. 애플리케이션이 로컬에서 표준 I/O 전송으로는 완벽하게 작동하지만 HTTP 전송으로 배포했을 때 문제가 발생한다면, 이것이 원인일 가능성이 높습니다.
중요한 구성 설정
두 가지 핵심 설정이 streamable HTTP 전송의 동작 방식을 제어합니다:
stateless_http- 연결 상태 관리를 제어합니다json_response- 응답 형식 처리를 제어합니다
기본적으로 두 설정 모두 false이지만, 특정 배포 시나리오에서는 이를 true로 설정해야 할 수도 있습니다. 이 설정을 활성화하면 진행 상황 알림, 로깅, 서버 시작 요청과 같은 핵심 기능이 손상될 수 있습니다.
HTTP 통신의 과제
이러한 제한이 존재하는 이유를 이해하려면 HTTP 통신이 작동하는 방식을 살펴봐야 합니다. 표준 HTTP에서는:
- 클라이언트는 서버에 쉽게 요청을 시작할 수 있습니다 (서버는 알려진 URL을 가지고 있습니다)
- 서버는 이러한 요청에 쉽게 응답할 수 있습니다
- 서버는 클라이언트에 쉽게 요청을 시작할 수 없습니다 (클라이언트는 알려진 URL이 없습니다)
- 클라이언트에서 서버로 돌아가는 응답 패턴은 문제가 됩니다
영향을 받는 MCP 메시지 유형
이러한 HTTP 제한은 특정 MCP 통신 패턴에 영향을 미칩니다. 다음 메시지 유형은 일반 HTTP로 구현하기 어려워집니다:
- 서버 시작 요청: Create Message 요청, List Roots 요청
- 알림: 진행 상황 알림, 로깅 알림, Initialized 알림, Cancelled 알림
이것들이 바로 제한적인 HTTP 설정을 활성화했을 때 손상되는 기능들입니다. 진행 표시줄이 사라지고, 로깅이 작동을 멈추며, 서버가 시작하는 샘플링 요청이 실패합니다.
Streamable HTTP 솔루션
Streamable HTTP 전송은 HTTP의 제한을 우회하는 영리한 해결책을 제공하지만, 여기에는 트레이드오프가 따릅니다. stateless_http=True 또는 json_response=True를 사용해야 하는 경우, 사실상 전송 방식에게 HTTP의 제약을 우회하는 대신 그 제약 안에서 작동하도록 지시하는 것입니다.
이러한 제한을 이해하면 다음과 같은 사항에 대해 정보에 입각한 결정을 내릴 수 있습니다:
- 다양한 배포 시나리오에 어떤 전송 방식을 사용할지
- HTTP 제약을 우아하게 처리하도록 MCP 서버를 설계하는 방법
- 원격 호스팅의 이점을 위해 기능 저하를 언제 받아들일지
핵심은 이러한 제한이 존재한다는 것을 알고 그에 맞춰 MCP 서버 아키텍처를 계획하는 것입니다. 애플리케이션이 서버 시작 요청이나 실시간 알림에 크게 의존한다면, 전송 방식 선택을 재고하거나 대체 통신 패턴을 구현해야 할 수도 있습니다.