16개월의 시차 — 폐기 선언과 제거 시계는 다른 사건이다

MCP가 SSE(Server-Sent Events) 전송을 폐기 대상으로 표시한 것은 2025년 3월 26일 스펙에서 Streamable HTTP가 대체 전송으로 도입되면서였습니다. 하지만 "폐기 표시"와 "제거 시점 확정"은 별개의 사건입니다. 2026년 7월 28일 확정된 최신 스펙이 처음으로 "1년 유예(year-long offramp)"를 공식화하면서, 16개월 만에야 실제 종료 카운트다운이 시작됐습니다.

SDK 간 인지 격차도 그대로 드러납니다. TypeScript SDK는 이미 SSEClientTransport@deprecated로 표시하고 StreamableHTTPClientTransport 사용을 권장하지만, Python SDK는 2026년 3월 11일 등록된 이슈(#2278) 기준으로 아직 경고조차 노출하지 않습니다. 같은 프로토콜을 쓰는 조직 안에서도 언어별로 폐기를 체감하는 시점이 갈립니다.

이중 엔드포인트 vs 단일 엔드포인트 — 전환이 더딘 이유

SSE는 서버→클라이언트 스트림과 클라이언트→서버 POST를 별도 엔드포인트로 나눠 커넥션 관리와 스케일링 부담을 키웠습니다. Streamable HTTP는 이를 단일 /mcp 엔드포인트로 통합해 이 부담을 없앴습니다. 문제는 구형 클라이언트를 계속 받아야 하는 서버입니다. 스펙 문서 자체가 "레거시 클라이언트를 지원하려는 서버는 SSE·POST 엔드포인트를 신규 MCP 엔드포인트와 나란히 계속 호스팅해야 한다"고 명시합니다. 이중 지원 기간이 길어질수록 라우팅·인증·로깅을 두 갈래로 유지하는 비용이 조용히 쌓입니다.

설계에서 운영까지: MCP 레거시 SSE 전송 유예 종료 대응 체크리스트

기획 단계에서는 유예 종료(2026-07-28 확정 기준 1년 뒤)까지 남은 기간을 분기 단위로 쪼개 목표부터 숫자로 걸어 둡니다. 분기마다 SSE 트래픽 비중을 25%p씩 낮춰 유예 종료 3개월 전에는 5% 미만으로 수렴시키고, 신규 클라이언트 온보딩에서는 Streamable HTTP 채택률 100%를 배포 합격선으로 못박습니다.

실패 패턴은 세 갈래로 나타납니다. 첫째, SDK별 경고 노출 시점 차이를 팀이 인지하지 못해 TypeScript 서비스는 전환을 시작했는데 Python 서비스는 여전히 SSE를 기본값으로 새로 붙이는 불일치입니다. 둘째, 이중 엔드포인트를 게이트웨이 라우팅 규칙에 임시로 박아두고 문서화하지 않아, 유예 종료가 임박해도 어떤 클라이언트가 아직 SSE에 의존하는지 아무도 답하지 못하는 경우입니다. 셋째, SSE 제거를 SDK 메이저 버전 업그레이드 한 번에 묶어 처리하려다, 하위호환이 꼭 필요한 구형 파트너 연동까지 함께 끊어버리는 경우입니다.

복구 분기는 로그 설계에서 시작합니다. 요청마다 전송 타입과 클라이언트 식별자를 필수 필드로 남겨 두면, 유예 종료가 임박한 시점에 미전환 클라이언트 목록을 즉시 추출해 개별 통보할 수 있습니다. 추가 유예가 꼭 필요한 파트너가 있다면 게이트웨이 단에서 그 트래픽만 전송별 라우팅으로 남겨 두고, 나머지 트래픽은 먼저 전환을 마치는 부분 롤아웃으로 분리합니다.

운영 체크리스트는 배포 전 검증부터 시작합니다. SSE·Streamable HTTP 두 전송 모두로 스모크 테스트를 통과시키고, 각 SDK의 DeprecationWarning 노출 여부를 사내 의존성 대시보드에 표시해 팀별 인지 격차를 없앱니다. 로그 스키마에는 전송 타입·SDK 버전·클라이언트 식별자를 필수 필드로 추가해 잔존 SSE 트래픽을 실시간으로 집계합니다.

지속 개선 루프는 주간 추적으로 완성됩니다. SSE 트래픽 비중과 미전환 클라이언트 수를 매주 집계하고, 감소 추세가 멈추면 그 주 안에 원인(구형 파트너, 특정 SDK 버전 고정 등)을 특정해 개별 대응 계획을 세웁니다. 유예 종료 3개월 전에는 잔존 트래픽이 남아 있어도 하드 컷오프 여부를 결정하는 의사결정 지점을 미리 캘린더에 고정해 둡니다.

한눈에 보는 적용 포인트

16개월 전 폐기 선언된 SSE 전송이 2026-07-28 스펙에서야 1년 유예 시계를 얻었다는 사실은, 지금이 이중 지원을 계획적으로 끝내야 할 시점이라는 신호입니다. SDK별 경고 노출 격차를 대시보드로 메우고, 전송 타입을 로그 필수 필드로 남겨 미전환 클라이언트를 특정하며, 분기별 SSE 트래픽 감소를 코드가 아니라 숫자로 걸어 두면 유예 종료 시점의 강제 컷오프가 사고 없이 지나갑니다.

참고 링크

The 2026-07-28 Specification — Model Context Protocol Blog

Mark SSE transport as deprecated · Issue #2278 — modelcontextprotocol/python-sdk

세션이 사라진 MCP: 2026-07-28 스펙 리뷰 — sunny34.com 리서치