StreamableHTTP 전송 방식은 MCP 클라이언트가 HTTP 연결을 통해 원격으로 호스팅된 서버에 접속할 수 있게 해줍니다. 클라이언트와 서버가 같은 머신에 있어야 하는 표준 I/O 전송 방식과 달리, 이 전송 방식은 누구나 접근할 수 있는 공개 MCP 서버의 가능성을 열어줍니다.

그러나 중요한 주의사항이 있습니다. 일부 구성 설정이 MCP 서버의 기능을 크게 제한할 수 있습니다. 로컬에서 표준 I/O 전송 방식으로는 완벽하게 동작하던 애플리케이션이 HTTP 전송 방식으로 배포하면 작동하지 않는다면, 이것이 원인일 가능성이 높습니다.

중요한 구성 설정

StreamableHTTP 전송 방식의 동작을 제어하는 두 가지 핵심 설정이 있습니다:

• stateless_http - 연결 상태 관리를 제어합니다
• json_response - 응답 형식 처리를 제어합니다

기본적으로 두 설정 모두 false이지만, 특정 배포 시나리오에서는 이를 true로 설정해야 할 수 있습니다. 활성화되면 이 설정들은 진행 알림, 로깅, 서버 시작 요청과 같은 핵심 기능을 손상시킬 수 있습니다.

HTTP 통신의 한계

이러한 제한이 존재하는 이유를 이해하려면 HTTP 통신이 어떻게 작동하는지 살펴볼 필요가 있습니다. 표준 HTTP에서는:

• 클라이언트는 서버에 요청을 쉽게 시작할 수 있습니다 (서버는 알려진 URL을 가지고 있음)
• 서버는 이러한 요청에 쉽게 응답할 수 있습니다
• 서버는 클라이언트에 요청을 쉽게 시작할 수 없습니다 (클라이언트는 알려진 URL이 없음)
• 클라이언트에서 서버로의 역방향 응답 패턴이 문제가 됩니다

영향을 받는 MCP 메시지 유형

이 HTTP 제한은 특정 MCP 통신 패턴에 영향을 미칩니다. 다음 메시지 유형들은 일반 HTTP로는 구현하기 어려워집니다:

• 서버 시작 요청: 메시지 생성 요청, 루트 목록 요청
• 알림: 진행 알림, 로깅 알림, 초기화 알림, 취소 알림

이것이 바로 제한적인 HTTP 설정을 활성화했을 때 손상되는 기능들입니다. 진행 표시줄이 사라지고, 로깅이 작동을 멈추며, 서버 시작 샘플링 요청이 실패합니다.

StreamableHTTP의 해결책

StreamableHTTP 전송 방식은 HTTP의 한계를 우회하는 영리한 해결책을 제공하지만, 트레이드오프가 따릅니다. stateless_http=True 또는 json_response=True를 사용해야 할 경우, 이는 본질적으로 HTTP의 제약을 우회하는 대신 그 안에서 동작하도록 전송 방식에 지시하는 것입니다.

이러한 제한을 이해하면 다음과 같은 사항에 대해 정보에 입각한 결정을 내릴 수 있습니다:

• 다양한 배포 시나리오에서 어떤 전송 방식을 사용할지
• HTTP 제약을 우아하게 처리하도록 MCP 서버를 설계하는 방법
• 원격 호스팅의 이점을 위해 기능 축소를 수용할 시점

핵심은 이러한 제한이 존재한다는 사실을 인지하고 이에 맞게 MCP 서버 아키텍처를 계획하는 것입니다. 애플리케이션이 서버 시작 요청이나 실시간 알림에 크게 의존한다면, 전송 방식 선택을 재고하거나 대안적인 통신 패턴을 구현해야 할 수도 있습니다.