Deprecation Window

예고 없이 뭔가를 걷어내는 protocol 은 protocol 이 아니라 움직이는 표적이야. MCP 의 절제는 이래. 없앨 기능은 먼저 deprecated 로 표시된 revision 에 한 번 등장하고, 대체재를 나란히 내보내고, 다다음 revision 이 될 때까지는 걷어내지 않아. 구현하는 쪽에 최소한 revision 한 바퀴만큼의 이사 시간을 준다는 뜻이야.

HTTP+SSE 가 2025-11-25 에 deprecated 된 게 살아 있는 예시야. 2024 년 spec 은 endpoint 를 둘 정의했어 (POST 요청용 하나, GET SSE 용 하나). 2025-03-26 revision 이 Streamable HTTP 를 들여왔고, 2025-11-25 revision 이 HTTP+SSE 를 deprecated 로 표시하면서 Streamable HTTP 를 앞으로 갈 길이라고 못박았지. 아직 안 옮긴 server 는 HTTP+SSE 가 실제로 빠지는 revision 이 지나가는 순간부터 새 client 와 handshake 를 못 하게 돼.

Deprecation 은 capability 를 통해서도 흘러. 물러나는 중인 capability 도 당분간은 계속 광고돼 — 옛 client 가 그걸 찾아 쓸 수 있게. 다만 spec 에는 언제 사라지는지가 적히고 SDK 에서도 deprecated 로 표시돼. 지금 당장 잘 돌아간다고 해도, 새로 쓰는 코드는 이미 나가는 중인 capability 를 새로 붙잡지 마.

Code

Spec 에서 deprecation 읽기 — 진짜 fragment·markdown

> The legacy HTTP+SSE transport (defined in revisions before 2025-03-26) is
> **DEPRECATED** as of revision 2025-11-25. New servers SHOULD implement
> Streamable HTTP. Existing HTTP+SSE servers SHOULD plan migration; clients
> SHOULD prefer Streamable HTTP when both are available.

Deprecation 의 마이그레이션 playbook·text

1. 새 revision 의 deprecation note 읽기.
2. Deprecated feature 옆에 교체 stand up (flag flip 은 아직 안 함).
3. Client 마이그레이션해서 새 feature 광고/선호.
4. 한 revision cycle 기다림. Log 에서 stragglers 보기.
5. 광고된 capability 에서 deprecated feature 제거.
6. Spec section URL 을 changelog 에 — 미래의 너 audit 가능.

Code

External links

Exercise

Progress

댓글 0