MCP 서버의 stateless_http 및 json_response 플래그는 서버가 작동하는 방식의 근본적인 측면을 제어합니다. 특히 서버를 확장하거나 프로덕션 환경에 배포할 계획이라면, 이 플래그를 언제 왜 사용해야 하는지 이해하는 것이 중요합니다.
Stateless HTTP가 필요한 경우
인기를 얻게 된 MCP 서버를 만든다고 상상해 보세요. 처음에는 단일 서버 인스턴스에 연결하는 클라이언트가 몇 개뿐일 수 있습니다:
서버가 성장함에 따라 수천 개의 클라이언트가 연결을 시도할 수 있습니다. 단일 서버 인스턴스를 운영하는 것으로는 그 모든 트래픽을 처리할 만큼 확장할 수 없습니다:
일반적인 해결책은 수평 확장(horizontal scaling)입니다 - 로드 밸런서 뒤에서 여러 서버 인스턴스를 운영하는 것입니다:
하지만 여기서부터 복잡해집니다. MCP 클라이언트는 두 개의 별도 연결이 필요하다는 점을 기억하세요:
- 서버에서 클라이언트로의 요청을 수신하기 위한 GET SSE 연결
- 도구를 호출하고 응답을 받기 위한 POST 요청
로드 밸런서를 사용하면 이러한 요청이 서로 다른 서버 인스턴스로 라우팅될 수 있습니다. 도구가 (샘플링을 통해) Claude를 사용해야 하는 경우, POST 요청을 처리하는 서버는 GET SSE 연결을 처리하는 서버와 조율해야 합니다. 이는 서버 간의 복잡한 조율 문제를 만들어냅니다.
Stateless HTTP가 이 문제를 해결하는 방법
stateless_http=True를 설정하면 이 조율 문제가 해결되지만, 상당한 트레이드오프가 따릅니다:
stateless HTTP가 활성화되면:
- 클라이언트가 세션 ID를 받지 못합니다 - 서버가 개별 클라이언트를 추적할 수 없습니다
- 서버에서 클라이언트로의 요청이 불가능합니다 - GET SSE 경로를 사용할 수 없게 됩니다
- 샘플링이 불가능합니다 - Claude나 다른 AI 모델을 사용할 수 없습니다
- 진행 상황 보고가 불가능합니다 - 장시간 작업 중 진행 상황 업데이트를 보낼 수 없습니다
- 구독이 불가능합니다 - 리소스 업데이트에 대해 클라이언트에 알릴 수 없습니다
하지만 한 가지 이점이 있습니다: 클라이언트 초기화가 더 이상 필요하지 않습니다. 클라이언트는 초기 핸드셰이크 과정 없이 직접 요청을 보낼 수 있습니다.
JSON Response 이해하기
json_response=True 플래그는 더 단순합니다 - POST 요청 응답에 대한 스트리밍을 비활성화할 뿐입니다. 도구가 실행되는 동안 여러 개의 SSE 메시지를 받는 대신, 일반 JSON 형태의 최종 결과만 받게 됩니다.
스트리밍이 비활성화되면:
- 중간 진행 상황 메시지가 없습니다
- 실행 중 로그 문이 없습니다
- 최종 도구 결과만 있습니다
이 플래그를 사용해야 할 때
다음과 같은 경우 stateless HTTP를 사용하세요:
- 로드 밸런서를 사용한 수평 확장이 필요한 경우
- 서버에서 클라이언트로의 통신이 필요하지 않은 경우
- 도구가 AI 모델 샘플링을 필요로 하지 않는 경우
- 연결 오버헤드를 최소화하고 싶은 경우
다음과 같은 경우 JSON response를 사용하세요:
- 스트리밍 응답이 필요하지 않은 경우
- 더 단순한, 스트리밍이 아닌 HTTP 응답을 선호하는 경우
- 일반 JSON을 기대하는 시스템과 통합하는 경우
개발 환경 대 프로덕션 환경
표준 I/O 전송을 사용하여 로컬에서 개발하고 있지만 HTTP 전송으로 배포할 계획이라면, 프로덕션에서 사용할 것과 동일한 전송 방식으로 테스트하세요. stateful 모드와 stateless 모드 간의 동작 차이는 상당할 수 있으며, 배포 후가 아니라 개발 중에 문제를 발견하는 것이 더 낫습니다.
이러한 플래그는 MCP 서버가 작동하는 방식을 근본적으로 바꾸므로, 특정 확장성 및 기능 요구 사항에 따라 선택하세요.