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 요청
- 알림: 진행 알림, 로깅 알림, 초기화 알림, 취소 알림
이것들이 바로 제한적인 HTTP 설정을 활성화할 때 중단되는 기능들입니다. 진행 표시줄이 사라지고, 로깅이 작동을 멈추며, 서버 시작 샘플링 요청이 실패합니다.
Streamable HTTP 솔루션
Streamable HTTP 전송은 HTTP의 제한을 우회하는 영리한 솔루션을 제공하지만, 이는 트레이드오프를 수반합니다. stateless_http=True 또는 json_response=True를 사용해야 하는 경우, 이는 본질적으로 전송 방식이 HTTP의 제약을 우회하는 대신 그 제약 내에서 작동하도록 지시하는 것입니다.
이러한 제한을 이해하면 다음과 같은 사항에 대해 정보에 기반한 결정을 내릴 수 있습니다:
- 다양한 배포 시나리오에 어떤 전송 방식을 사용할지
- HTTP 제약을 우아하게 처리하도록 MCP 서버를 설계하는 방법
- 원격 호스팅의 이점을 위해 기능 저하를 받아들여야 할 때
핵심은 이러한 제한이 존재한다는 것을 알고 그에 맞게 MCP 서버 아키텍처를 계획하는 것입니다. 애플리케이션이 서버 시작 요청이나 실시간 알림에 크게 의존한다면, 전송 방식 선택을 재고하거나 대체 통신 패턴을 구현해야 할 수도 있습니다.