MCP 최종 사양 전환: 무상태 코어와 버전 협상 운영 전략

2026년 5월 21일 확정된 MCP 릴리스 후보는 검증 기간을 거쳐 7월 28일 최종 사양으로 발행된다. 모델과 도구를 연결하는 프로토콜이 공개된 뒤 가장 큰 폭의 개정이며, 단순 기능 추가가 아니라 코어 동작을 바꾼다. 운영 중인 서버와 클라이언트가 별도 대응 없이 그대로 동작할 것이라고 전제하기 어렵다.

핵심 변화는 initialize / initialized 교환을 없애는 SEP-2575와 Mcp-Session-Id 헤더 및 프로토콜 수준 세션 개념을 제거하는 SEP-2567이다. 연결 시점에 한 번 주고받던 프로토콜 버전, 클라이언트 신원, 능력 정보는 요청마다 _meta 필드로 전달한다. 서버의 능력을 미리 확인해야 한다면 server/discover를 사용한다.

Extensions 프레임워크도 도입된다. 서버 렌더링 UI와 장시간 작업 분리를 위한 구조이며, 인가는 OAuth·OIDC 배포 관행과의 정합성을 강화한다. 공식 폐기 정책이 형식화되는 점도 이후 전환 일정을 운영 항목으로 다뤄야 하는 이유다.

요청 단위로 달라지는 호환성 처리

핸드셰이크가 사라지면 버전을 합의하던 연결 시점도 없어진다. 버전은 요청마다 명시되고, 서버는 각 요청에 맞춰 해석 방식을 결정해야 한다.

불일치를 조용히 구 버전 처리로 넘기는 방식은 피해야 한다. 암묵적 다운그레이드는 원인을 추적하기 어려운 오동작을 남긴다. 버전 불일치, 미지원 확장, 스키마 위반, 인가 실패는 구분된 오류 코드로 반환해야 클라이언트가 대응 경로를 선택할 수 있다.

능력 정보도 요청 단위 전달과 사전 조회를 구분해 설계할 필요가 있다. 매 요청에 능력 정보를 모두 담으면 페이로드가 커진다. 필요한 최소 집합은 _meta에 싣고, 사전 확인이 필요한 항목은 server/discover로 조회하는 규약이 실무적이다.

⤢✕

세션 의존성을 걷어내는 전환 순서

무상태 코어는 원격 MCP 서버를 스티키 세션, 공유 세션 저장소, 게이트웨이 심층 패킷 검사 없이 운영할 수 있게 한다. 일반 라운드로빈 로드밸런서 뒤에 두고 표준 HTTP 인프라를 활용할 수 있으며, 게이트웨이는 본문을 파싱하지 않고도 메서드 단위의 레이트리밋과 권한 정책을 적용할 수 있다.

전환을 시작할 때는 서버와 클라이언트의 프로토콜 버전, SDK, 세션 의존 여부를 인벤토리로 정리한다. 특히 세션 ID를 상태 키로 사용하던 코드를 먼저 찾아야 한다. 이 부분이 가장 큰 걸림돌이 된다.

전개 순서는 SDK 업그레이드, 서버 이중 지원 배포, 클라이언트 전환, 구 경로 제거가 적절하다. 이 순서를 뒤집으면 즉시 장애가 발생할 수 있다.

서버는 구 클라이언트가 보내는 세션 ID를 수용하되 무시하고, 핸드셰이크 요청에는 호환 응답을 반환하는 어댑터를 둘 수 있다. 반대로 클라이언트는 신 사양을 지원하지 않는 서버에 대해 핸드셰이크와 세션 헤더를 쓰는 구 방식 폴백 경로가 필요하다. 두 경로가 함께 존재하는 동안 테스트 매트릭스는 배로 늘어난다.

매트릭스와 적합성 테스트를 운영 자산으로 만들기

지원 조합은 서버 버전, 클라이언트 버전, 사용 확장을 축으로 관리한다. 지원하지 않는 조합도 문서화해야 한다. 조합 폭발을 줄이려면 동시에 지원하는 버전을 최신과 직전 1개로 제한하는 정책이 필요하다.

도구 입출력 스키마는 서버와 클라이언트 양쪽에서 검증한다. 전환기에 가장 자주 생기는 문제는 스키마 해석의 차이다. 검증 실패는 전환기에는 경고로 기록하며 처리하고, 안정화한 뒤 오류로 승격하는 단계적 정책을 둘 수 있다.

사양 요구사항은 테스트 케이스로 옮겨 CI에서 버전 매트릭스 전체에 실행한다. 수동 검증은 전환기에 누락이 발생한다. 무상태 검증에서는 동일 클라이언트의 연속 요청이 서로 다른 인스턴스로 분산돼도 정상 동작하는지 확인해야 한다.

이중 지원은 시작할 때 종료일을 정하고 외부 소비자에게 사전 공지해야 한다. 종료일 없는 병행은 구 경로를 영구 부채로 남긴다. 버전별 요청 비중을 계측해 구 경로 트래픽이 임계 이하가 된 시점을 제거 기준으로 삼는다.

공식 폐기 정책이 도입된 뒤에는 폐기 공지 수신과 잔여 기간 추적을 정례 업무에 넣어야 한다. Extensions는 코어와 진화 속도가 분리되므로, 확장 채택은 코어 전환과 별개의 판단으로 다룬다. 외부 공개 서버라면 소비자 공지 절차와 유예 기간도 정책과 계약에 명시한다.

전환 방식별로 달라지는 비용

구분	최종 사양 즉시 채택	이중 지원 병행
초기 공수	집중	분산
인프라 단순화	즉시 실현	지연
구 클라이언트 영향	즉시 단절	무영향
테스트 부담	단일 경로	매트릭스 배증
잔존 부채	없음	이중 경로 유지
적합 상황	클라이언트 통제 가능	외부 소비자 존재

서버와 클라이언트를 모두 조직이 통제한다면 즉시 채택이 총공수와 부채 측면에서 유리하다. 외부 소비자가 있다면 병행이 불가피하며, 종료일을 명시하는 일이 핵심 통제 수단이 된다. 종료일이 없는 병행은 무상태 전환으로 얻는 인프라 단순화의 이점을 계속 미루는 결정이다.

표준 준수 구현은 클라이언트를 교체할 때 도구 자산을 이식할 수 있게 한다. 벤더 전용 연동은 초기 구현이 단순하고 고유 기능을 온전히 활용할 수 있지만, 클라이언트를 바꾸면 전량 재구현이 된다. 다만 이번처럼 최대 규모 개정이 발생할 수 있다는 사실은 표준 준수에도 전환 비용이 있음을 보여준다.

릴리스 후보를 먼저 채택하면 인프라 단순화 이점을 앞당기고 사양 피드백에 참여할 수 있다. 대신 최종본에서 세부 사항이 바뀌면 재작업이 생긴다. 최종본을 기다리면 재작업 위험은 없지만 공수가 한 시점에 몰리고 베타 SDK로 사전 검증할 기회를 잃는다. 내부 전용 서버는 선행 채택, 외부 공개 서버는 최종본 기준 전환이 위험 대비 합리적이다.

표준 개정이 변경관리 업무가 되는 시점

프로토콜 표준의 가치는 안정성에서 나오지만 초기 표준은 개정을 거친다. 채택을 판단할 때 준수 이점뿐 아니라 버전 전환 비용도 함께 계상해야 한다. 공식 폐기 정책의 도입은 표준이 성숙하고 있다는 신호다. 폐기 정책이 있으면 전환 계획을 미리 세울 수 있지만, 없으면 개정은 돌발 상황이 된다.

무상태 코어는 표준 HTTP 인프라와의 상호운용성을 높인다. 특수 게이트웨이 설정이 사라지면 운영 구성은 일반 웹 서비스와 가까워진다. 다만 능력 선언 기반의 축퇴 경로가 정의되지 않으면 상호운용성은 문서에만 머문다.

외부 표준의 개정은 조직이 통제할 수 없는 변경이다. 이를 통제 가능한 범위로 옮기는 수단은 버전 매트릭스 관리와 이중 지원 기간의 명시적 종료다. 적합성 테스트 자동화는 전환 승인에 필요한 객관적 증적이 되며, 매트릭스가 커질수록 수동 검증의 신뢰도는 급격히 떨어진다.

최종 사양 이후의 운영 변화

무상태 코어 채택이 확산되면 원격 MCP 서버 운영은 일반 HTTP 서비스 수준으로 단순화되는 흐름을 보일 전망이다. Extensions 구조는 코어 안정성과 기능 확장 속도를 분리하며, 확장 단위의 채택 판단은 새로운 아키텍처 결정 항목이 된다.

인가가 OAuth·OIDC 배포 관행과 정합해지면 기존 아이덴티티 인프라와 통합할 때의 부담이 감소한다. 공식 폐기 정책이 정착하면 프로토콜 전환도 돌발 대응이 아니라 계획된 변경관리 업무로 옮겨갈 수 있다.