에이전트 연동 코드를 최신 MCP 문서대로 바꿨더니 기존 서버가 실패합니다. 빠르게 바뀌는 프로토콜의 버전과 실험 기능을 어떻게 관리하나요?

최신 링크가 가리키는 규약과 현재 배포된 구현이 지원하는 규약을 구분해야 합니다. 프로토콜 리비전·SDK 버전·확장 기능 버전을 각각 기록하고, 실제 지원 기능을 확인한 뒤 호환 가능한 경로를 선택하겠습니다. 새 명세가 나왔다는 사실이 모든 서버의 자동 업그레이드를 뜻하지는 않습니다.

구체적인 변경을 계약으로 고정합니다

2026년 9월 11일 확인한 MCP 변경 이력에서 2026-07-28 리비전은 2025-11-25 대비 protocol-level session과 initialize handshake를 제거하고 요청마다 버전과 client capability를 전달하는 구조를 설명합니다. server/discover, subscriptions/listen, resultType과 추가 입력을 위한 multi round-trip 패턴도 명시합니다. 과거 코드의 세션 ID나 초기화 순서를 최신 구현에 그대로 보내거나 그 반대를 하면 맞지 않을 수 있습니다.

같은 변경 이력은 장기 tasks를 코어에서 공식 확장으로 옮기고, Streamable HTTP의 SSE 재개·재전달 계약도 바꿉니다. 따라서 'MCP는 항상 연결을 복원해 중단 요청을 이어 준다'거나 'tasks는 모든 서버의 기본 기능이다'라고 일반화하지 않습니다. 재요청에 새 프로토콜 ID를 쓰더라도 실제 변경의 논리 요청 ID는 유지해야 중복 효과를 통제할 수 있습니다. 전송 식별자와 업무 멱등 키는 별개입니다.

지원과 검증을 단계적으로 합니다

지원 리비전과 기능을 명시한 호환 표를 만들고 구·신 client와 server 조합을 테스트합니다. 모르는 기능을 조용히 무시해서 성공처럼 처리하지 않고, 명확한 unsupported 결과와 대체 경로를 둡니다. 실험·선택 확장은 양쪽의 지원과 현재 계약을 확인하며, 폐기 예정 기능은 지원 종료 계획을 세우되 존재와 제거를 혼동하지 않습니다. 문서 내부 설명이 충돌하면 상세 규범과 스키마·구현을 대조하고 불확실한 부분은 확인 전 적용하지 않습니다.

명세 고정 링크와 확인 날짜를 변경 근거로 남기고, 정상 호출뿐 아니라 오류·연결 중단·추가 입력·권한 변경을 회귀 시험에 넣습니다. 버전 전환은 형식 수정만이 아니라 상태 수명·재시도·캐시 의미를 바꿀 수 있습니다. 모델이 최신 설명을 잘 이해해도 런타임이 실제 계약을 구현하지 않으면 해결되지 않으므로, 문서 갱신과 코드 호환 검증을 같은 작업에서 수행하겠습니다.

실행 사례로 확인합니다

문서의 변경 상태도 구분합니다. deprecated는 당장 제거됐다는 뜻이 아니며 최소 지원 기간이나 마이그레이션 정책이 있을 수 있습니다. 반대로 removed는 예전 호출을 새 구현이 계속 받아 줄 것이라고 기대할 수 없는 상태입니다. 2026-07-28 변경 이력의 Roots·Sampling·Logging 등의 상태를 다룰 때도 이 구분을 유지합니다. 테스트 결과에는 성공한 기능만 아니라 지원하지 않는 선택 기능과 fallback 범위를 남깁니다. 클라이언트가 모르는 resultType을 성공 결과로 해석하는 식의 관대한 처리가 오히려 미완료 작업을 완료로 바꿀 수 있으므로 프로토콜의 호환 규칙을 정확히 적용해야 합니다.