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