StreamableHTTP는 근본적인 문제에 대한 MCP의 해결책입니다: 일부 MCP 기능은 서버가 클라이언트에 요청을 보내야 하지만, HTTP는 이를 어렵게 만듭니다. StreamableHTTP가 이 제약을 어떻게 우회하는지, 그리고 언제 그 우회 방법을 깨뜨려야 할 수도 있는지 살펴보겠습니다.
핵심 문제
샘플링, 알림, 로깅과 같은 일부 MCP 기능은 서버가 클라이언트에 요청을 시작하는 것에 의존합니다. 그러나 HTTP는 클라이언트가 서버에 요청을 보내도록 설계되어 있으며, 그 반대는 아닙니다. StreamableHTTP는 Server-Sent Events(SSE)를 사용한 기발한 우회 방법으로 이 문제를 해결합니다.
StreamableHTTP의 작동 방식
이 마법은 클라이언트와 서버 간에 지속적인 연결을 수립하는 다단계 프로세스를 통해 이루어집니다.
초기 연결 설정
이 프로세스는 일반적인 MCP 연결과 동일하게 시작됩니다:
- 클라이언트가 서버에
Initialize Request를 전송합니다 - 서버는 특별한
mcp-session-id헤더가 포함된Initialize Result로 응답합니다 - 클라이언트는 세션 ID와 함께
Initialized Notification을 전송합니다
이 세션 ID는 매우 중요합니다 - 클라이언트를 고유하게 식별하며 이후의 모든 요청에 포함되어야 합니다.
SSE 우회 방법
초기화 후, 클라이언트는 Server-Sent Events 연결을 수립하기 위해 GET 요청을 보낼 수 있습니다. 이는 서버가 언제든지 클라이언트로 메시지를 스트리밍할 수 있는 장기 지속 HTTP 응답을 생성합니다.
이 SSE 연결은 서버에서 클라이언트로의 통신을 가능하게 하는 핵심입니다. 서버는 이제 이 지속적인 채널을 통해 요청, 알림 및 기타 메시지를 전송할 수 있습니다.
도구 호출과 이중 SSE 연결
클라이언트가 도구 호출을 수행하면 상황이 더 복잡해집니다. 시스템은 두 개의 별도 SSE 연결을 생성합니다:
- 기본 SSE 연결: 서버가 시작하는 요청에 사용되며 무기한 열려 있습니다
- 도구별 SSE 연결: 각 도구 호출마다 생성되며 도구 결과가 전송되면 자동으로 닫힙니다
메시지 라우팅
서로 다른 유형의 메시지는 서로 다른 연결을 통해 라우팅됩니다:
- 진행 알림: 기본 SSE 연결을 통해 전송됩니다
- 로깅 메시지 및 도구 결과: 도구별 SSE 연결을 통해 전송됩니다
우회 방법을 깨뜨리는 구성 플래그
StreamableHTTP에는 두 가지 중요한 구성 옵션이 포함되어 있습니다:
stateless_httpjson_response
이를 True로 설정하면 SSE 우회 메커니즘이 깨질 수 있습니다. 특정 상황에서는 이러한 플래그를 활성화하고 싶을 수 있지만, 그렇게 하면 서버-클라이언트 통신에 의존하는 전체 MCP 기능이 제한됩니다.
핵심 요약
StreamableHTTP는 HTTP의 제약을 우회해야 하기 때문에 다른 MCP 전송 방식보다 더 복잡합니다. SSE 기반 우회 방법은 HTTP를 통해 전체 MCP 기능을 가능하게 하지만, 이중 연결 모델을 이해하는 것은 디버깅과 최적화에 매우 중요합니다.
StreamableHTTP로 MCP 애플리케이션을 구축할 때, 초기화 이후의 모든 요청에는 세션 ID가 필요하며, 시스템은 서버-클라이언트 통신의 다양한 유형을 처리하기 위해 여러 SSE 연결을 자동으로 관리한다는 점을 기억하세요.