MCP의 새로운 전송 계층 - Streamable HTTP 프로토콜 상세 설명

Model Context Protocol (MCP)는 AI 모델과 도구 간 통신을 위한 표준 프로토콜입니다. AI 애플리케이션이 점점 더 복잡해지고 광범위하게 배포됨에 따라 기존 통신 메커니즘은 일련의 도전 과제에 직면하고 있습니다. GitHub의 PR #206은 기존 HTTP+SSE 전송 메커니즘을 크게 개선한 새로운 Streamable HTTP 전송 계층을 도입했습니다. 이 글은 이 프로토콜의 설계 철학, 기술적 세부 사항 및 실제 적용에 대해 상세히 분석합니다.

기존 HTTP+SSE 전송 메커니즘과 한계

HTTP+SSE 전송 메커니즘

기존 MCP 구현에서 클라이언트와 서버는 두 가지 주요 채널을 통해 통신했습니다:

HTTP 요청/응답: 클라이언트가 표준 HTTP 요청을 통해 서버에 메시지 전송
서버 전송 이벤트(SSE): 서버가 전용 /sse 엔드포인트를 통해 클라이언트에 메시지 푸시

주요 문제점

이 설계는 단순하고 직관적이지만 몇 가지 중요한 문제가 있었습니다:

연결 끊김 복구/재개 미지원

SSE 연결이 끊어지면 모든 세션 상태가 손실되며, 클라이언트는 연결을 다시 설정하고 전체 세션을 초기화해야 합니다. 예를 들어 대용량 파일 분석 작업이 진행 중일 때 WiFi가 불안정하면 전체 프로세스가 중단되어 사용자가 처음부터 다시 시작해야 합니다.

서버 장시간 연결 유지 필요

서버는 각 클라이언트마다 장시간 SSE 연결을 유지해야 하며, 많은 동시 사용자로 인해 리소스 소비가 급증합니다. 서버를 재시작하거나 확장해야 할 때 모든 연결이 끊어져 사용자 경험과 시스템 안정성이 저하됩니다.

서버 메시지 SSE 전송만 가능

간단한 요청-응답 상호작용도 SSE 채널을 통해 정보를 반환해야 하므로 불필요한 복잡성과 오버헤드가 발생합니다. 일부 환경(예: 클라우드 함수)에서는 장시간 SSE 연결 유지가 적합하지 않습니다.

인프라 호환성 제한

많은 기존 웹 인프라(CDN, 로드 밸런서, API 게이트웨이 등)가 장시간 SSE 연결을 올바르게 처리하지 못할 수 있으며, 기업 방화벽이 시간 초과 연결을 강제로 종료하여 서비스 신뢰성이 떨어질 수 있습니다.

Streamable HTTP: 설계와 원리

Streamable HTTP는 다음과 같은 핵심 개념에 기반하여 설계되었습니다:

최대 호환성: 기존 HTTP 생태계와 원활하게 통합
유연성: 상태 비저장 및 상태 저장 모드 동시 지원
리소스 효율성: 필요에 따라 리소스 할당, 불필요한 장시간 연결 방지
신뢰성: 연결 끊김 복구 및 세션 재개 지원

주요 개선 사항

기존 메커니즘과 비교하여 Streamable HTTP는 몇 가지 중요한 개선 사항을 도입했습니다:

통합 엔드포인트: 전용 /sse 엔드포인트 제거, 모든 통신은 단일 엔드포인트(예: /message)를 통해 수행
주문형 스트리밍 전송: 서버는 일반 HTTP 응답 반환 또는 SSE 스트림으로 업그레이드 유연하게 선택 가능
세션 식별자: 세션 ID 메커니즘 도입, 상태 관리 및 복구 지원
유연한 초기화: 클라이언트가 빈 GET 요청으로 SSE 스트림을 능동적으로 초기화 가능

기술적 세부 사항

Streamable HTTP의 작동 흐름은 다음과 같습니다:

세션 초기화:
- 클라이언트가 /message 엔드포인트에 초기화 요청 전송
- 서버는 세션 ID 생성 후 클라이언트에 반환 가능
- 세션 ID는 이후 요청에서 세션 식별에 사용
클라이언트-서버 통신:
- 모든 메시지는 HTTP POST 요청으로 /message 엔드포인트에 전송
- 세션 ID가 있으면 요청에 포함
서버 응답 방식:
- 일반 응답: 직접 HTTP 응답 반환, 간단한 상호작용에 적합
- 스트림 응답: 연결을 SSE로 업그레이드, 일련의 이벤트 전송 후 종료
- 장시간 연결: SSE 연결 유지, 지속적으로 이벤트 전송
능동적 SSE 스트림 생성:
- 클라이언트가 /message 엔드포인트에 GET 요청 전송하여 SSE 스트림 능동적으로 생성 가능
- 서버는 이 스트림을 통해 알림 또는 요청 푸시 가능
연결 복구:
- 연결이 끊어지면 클라이언트는 이전 세션 ID 사용하여 재연결 가능
- 서버는 세션 상태 복구 후 이전 상호작용 계속 가능

실제 적용 시나리오

상태 비저장 서버 모드

시나리오: 수학 계산, 텍스트 처리 등 간단한 도구 API 서비스.

구현:

클라이언트                                  서버
   |                                    |
   |-- POST /message (계산 요청) -------->|
   |                                    |-- 계산 실행
   |<------- HTTP 200 (계산 결과) -------|
   |                                    |

장점: 최소한의 배포, 상태 관리 불필요, 서버리스 아키텍처 및 마이크로서비스에 적합.

스트리밍 진행 피드백 모드

시나리오: 대용량 파일 처리, 복잡한 AI 생성 등 장시간 실행 작업.

구현:

클라이언트                                  서버
   |                                    |
   |-- POST /message (처리 요청) -------->|
   |                                    |-- 처리 작업 시작
   |<------- HTTP 200 (SSE 시작) --------|
   |                                    |
   |<------- SSE: 진행률 10% ---------------|
   |<------- SSE: 진행률 30% ---------------|
   |<------- SSE: 진행률 70% ---------------|
   |<------- SSE: 완료 + 결과 ------------|
   |                                    |

장점: 실시간 피드백 제공, 영구 연결 상태 유지 불필요.

복잡한 AI 세션 모드

시나리오: 컨텍스트 유지가 필요한 다중 턴 대화형 AI 어시스턴트.

구현:

클라이언트                                  서버
   |                                    |
   |-- POST /message (초기화) ---------->|
   |<-- HTTP 200 (세션ID: abc123) ------|
   |                                    |
   |-- GET /message (세션ID: abc123) --->|
   |<------- SSE 스트림 생성 ------------|
   |                                    |
   |-- POST /message (질문1, abc123) --->|
   |<------- SSE: 생각 중... -------------|
   |<------- SSE: 답변1 ----------------|
   |                                    |
   |-- POST /message (질문2, abc123) --->|
   |<------- SSE: 생각 중... -------------|
   |<------- SSE: 답변2 ----------------|

장점: 세션 컨텍스트 유지, 복잡한 상호작용 지원, 수평 확장 가능.

연결 끊김 복구 모드

시나리오: 불안정한 네트워크 환경에서의 AI 애플리케이션 사용.

구현:

클라이언트                                  서버
   |                                    |
   |-- POST /message (초기화) ---------->|
   |<-- HTTP 200 (세션ID: xyz789) ------|
   |                                    |
   |-- GET /message (세션ID: xyz789) --->|
   |<------- SSE 스트림 생성 ------------|
   |                                    |
   |-- POST /message (장시간 작업, xyz789) -->|
   |<------- SSE: 진행률 30% ---------------|
   |                                    |
   |     [네트워크 중단]                      |
   |                                    |
   |-- GET /message (세션ID: xyz789) --->|
   |<------- SSE 스트림 재생성 -----------|
   |<------- SSE: 진행률 60% ---------------|
   |<------- SSE: 완료 ------------------|

장점: 약한 네트워크 환경에서 신뢰성 향상, 사용자 경험 개선.

Streamable HTTP의 주요 장점

기술적 장점

구현 단순화: 일반 HTTP 서버에서 구현 가능, 특별한 지원 불필요
리소스 효율성: 필요에 따라 리소스 할당, 클라이언트별 장시간 연결 유지 불필요
인프라 호환성: 기존 웹 인프라(CDN, 로드 밸런서, API 게이트웨이)와 잘 호환
수평 확장: 메시지 버스를 통해 요청을 다른 서버 노드로 라우팅 가능
점진적 도입: 서비스 제공자는 필요에 따라 구현 복잡도 선택 가능
연결 끊김 복구: 세션 복구 지원, 신뢰성 향상

비즈니스 장점

운영 비용 절감: 서버 리소스 소비 감소, 배포 아키텍처 단순화
사용자 경험 향상: 실시간 피드백과 신뢰할 수 있는 연결로 경험 개선
광범위한 적용성: 간단한 도구부터 복잡한 AI 상호작용까지 다양한 구현 방식 제공
확장 능력: 더 다양하고 풍부한 AI 애플리케이션 시나리오 지원
개발자 친화적: MCP 구현 기술 진입 장벽 낮춤

구현 참고 사항

서버 측 구현 핵심 사항

엔드포인트 설계:
- 모든 요청을 처리하는 단일 /message 엔드포인트 구현
- POST 및 GET 두 가지 HTTP 메서드 지원
상태 관리:
- 세션 ID 생성 및 검증 메커니즘 설계
- 세션 상태 저장소 구현(메모리, Redis 등)
요청 처리:
- 요청에서 세션 ID 파싱
- 응답 유형 결정(일반 HTTP 또는 SSE)
- 스트림 응답의 콘텐츠 유형 및 형식 처리
연결 관리:
- SSE 스트림 초기화 및 유지 구현
- 연결 끊김 및 재연결 로직 처리

클라이언트 측 구현 핵심 사항

요청 구성:
- 프로토콜 준수 메시지 형식 구성
- 세션 ID(있는 경우) 올바르게 포함
응답 처리:
- 응답이 일반 HTTP인지 SSE인지 감지
- SSE 이벤트 파싱 및 처리
세션 관리:
- 세션 ID 저장 및 관리
- 연결 끊김 복구 로직 구현
오류 처리:
- 네트워크 오류 및 시간 초과 처리
- 지수 백오프 재시도 전략 구현

결론

Streamable HTTP 전송 계층은 MCP 프로토콜의 중요한 진화를 나타내며, HTTP와 SSE의 장점을 결합하고 한계를 극복하여 AI 애플리케이션 통신을 위한 더 유연하고 신뢰할 수 있는 솔루션을 제공합니다. 이는 기존 전송 메커니즘의 문제를 해결할 뿐만 아니라 미래의 더 복잡한 AI 상호작용 패턴을 위한 기반을 마련합니다.

이 프로토콜의 설계는 실용성 원칙을 충분히 반영하며, 기술적 선진성 요구 사항을 충족하는 동시에 기존 웹 인프라와의 호환성을 유지합니다. 그 유연성으로 인해 개발자는 자신의 요구에 가장 적합한 구현 방식을 선택할 수 있으며, 간단한 상태 비저장 API부터 복잡한 대화형 AI 애플리케이션까지 모두 적합한 솔루션을 찾을 수 있습니다.

이 PR이 병합됨에 따라 MCP 커뮤니티의 기술 생태계는 더욱 풍부해질 것이며, 더 많은 개발자가 MCP를 채택하는 데 편의를 제공할 것입니다. 가까운 미래에 Streamable HTTP 기반 MCP 구현이 다양한 AI 애플리케이션에서 광범위하게 적용되는 것을 볼 수 있을 것으로 기대합니다.