MCP 날짜 기반 버전 협상과 호환성 운영 설계

날짜가 다른 MCP 스펙은 기능 차이로 이어진다

Codex CLI가 MCP 2026-07-28 프로토콜을 채택하면서 페이지네이션 기반 탐색, 다중 라운드 요청, 논블로킹 서버 기동이 포함됐다. 이제 MCP 연동에서는 클라이언트와 서버가 서로 다른 스펙 날짜를 참조하는 일이 자연스러운 운영 조건이 됐다.

서버를 바꾸지 않은 상태에서 클라이언트만 갱신해도 기능이 빠질 수 있다. 협상 결과가 낮은 버전으로 내려가면 오류 없이 기능이 축소되고, 협상 결과가 로그에 남지 않으면 클라이언트와 서버 중 어느 쪽에서 문제가 시작됐는지 가리기 어렵다.

MCP에서 스펙 날짜는 단순한 릴리스 표기가 아니라 호환성 기준이다. 따라서 연동은 한 번 구성한 뒤 끝나는 통합 작업이 아니라, 협상 범위와 실제 사용 버전을 계속 관리하는 운영 대상이 된다.

호환성 체계가 다뤄야 할 항목

클라이언트와 서버는 각자가 지원하는 스펙 날짜 목록과 최소 요구 버전을 명시적으로 선언해야 한다. 최신 버전 하나만 선언하면 협상할 선택지가 사라진다.

교집합이 없을 때의 처리도 서버 유형별로 정해 둘 필요가 있다. 오류로 연결을 끊을지, 최소 기능만 제공할지 결정하지 않은 채 연결을 성립시키면 기능이 빠진 상태의 연동이 가장 진단하기 어려운 문제가 된다.

페이지네이션을 지원하지 않을 때 전량 조회로 바꾸거나, 다중 라운드 요청을 지원하지 않을 때 단일 요청으로 처리하는 식의 폴백은 명시해야 한다. 대체 동작이 성능이나 정확도를 바꾼다면 그 사실도 기록 대상이다.

능력 매트릭스에는 스펙 날짜별 기능과 필수 여부를 정리하고, 조직이 의존하는 기능을 표시한다. 스펙 문서를 매번 다시 읽는 방식으로는 변경 영향 판단을 반복해서 처음부터 시작하게 된다.

예외만 수집해서는 비호환을 충분히 포착할 수 없다. 협상 결과의 버전 하락, 특정 메서드 미지원 응답, 필드 누락, 응답 형식 변화처럼 결과 차이로 드러나는 신호를 함께 수집해야 한다.

각 서버의 현재 협상 버전과 지원 범위도 주기적으로 확인해 인벤토리에 반영한다. 등록 당시의 정보만 보관하면 서버가 갱신된 뒤에도 인벤토리는 변하지 않는다.

⤢✕

연동 환경을 운영 대상으로 만드는 방법

먼저 사용 중인 MCP 서버, 제공 주체, 담당자, 의존 기능을 인벤토리로 정리한다. 설정 파일에 있는 서버만 조사하면 개인 환경에서 업무에 사용되는 연동을 놓칠 수 있다.

그다음 각 연동에서 실제로 협상된 버전을 수집해 목표 버전과의 격차를 확인한다. 서버가 선언한 최대 지원 버전과 실제 사용 버전은 다를 수 있으므로, 선언값만으로 현황을 판단해서는 안 된다.

업그레이드는 의존 구조를 기준으로 순서를 세운다. 의존 서버가 많은 클라이언트는 나중에 올리고, 사용처가 적은 서버부터 갱신하면 문제 범위를 좁힌 채 검증할 수 있다. 모든 구성 요소를 동시에 바꾸면 장애가 발생했을 때 원인 구간을 분리하기 어렵다.

기능별로 허용 가능한 대체 동작과 허용할 수 없는 기능을 사전에 구분해야 한다. 폴백 여부를 개발자 개인 판단에 맡기면 사용자 체감에 큰 영향을 주는 기능도 일관성 없이 처리될 수 있다.

호환성 시험은 대표 도구 호출과 리소스 조회 시나리오를 지원 버전 조합별로 실행하도록 구성한다. 최신 조합만 확인해서는 실제 운영에 남아 있는 구버전 조합을 검증할 수 없다. 조합 수가 늘어날수록 수동 확인도 유지하기 어려워진다.

스펙 저장소와 릴리스 노트를 확인할 담당과 주기를 정하고, 변경 요약을 공유하는 절차도 필요하다. 클라이언트 업데이트 공지만으로는 충분하지 않다. 스펙 변경이 먼저 발생하고 도구 반영은 그 뒤에 따라올 수 있다.

지원 버전 선언 규칙, 폴백 정의, 업그레이드 순서 정책, 시험 통과 기준은 조직 표준으로 등록할 수 있다. 서버별 협상 버전 분포, 폴백 발생률, 호환 시험 통과율, 스펙 격차 일수는 정기 보고 항목으로 관리한다.

폴백과 최소 버전 강제의 선택

구분	버전 협상 자동 폴백	최소 버전 강제
가용성	높음	낮음
기능 완결성	낮음	높음
진단 난이도	높음	낮음
업그레이드 압박	약함	강함
사용자 체감	조용한 저하	명시적 실패
구현 부담	큼	작음

자동 폴백은 구버전 서버를 계속 사용할 수 있어 가용성을 유지하고, 클라이언트 업그레이드가 서버 일정에 묶이지 않도록 한다. 점진적 이행도 가능하다. 반면 기능이 빠진 상태로 동작하면 사용자는 원인을 알 수 없는 성능 저하를 경험할 수 있고, 폴백 상태가 장기간 남을 수 있다. 문제를 분석할 때도 어느 경로가 폴백인지 추적해야 한다.

최소 버전 강제는 필요한 기능이 없으면 명확히 실패시킨다. 동작 경로가 하나이므로 진단은 단순해지고 서버 업그레이드 압박도 실제로 작동한다. 다만 구버전 서버 하나가 전체 연동을 막을 수 있으며, 사내 서버의 갱신 일정이 밀리면 업무가 중단될 수 있다. 외부 제공 서버는 통제할 수 없다는 제약도 있다.

핵심 기능에는 최소 버전을 강제하고 보조 기능에만 폴백을 허용하는 방식은 가용성과 기능 완결성 사이의 절충안이 된다.

클라이언트를 먼저 갱신하면 신규 기능을 선행 확보할 수 있고, 사용자 수가 많은 쪽을 한 번에 관리할 수 있다. 그러나 구버전 서버와의 호환 부담이 클라이언트에 쌓이며, 폴백 경로가 늘어난다. 문제가 생기면 여러 서버에 동시에 영향이 갈 수 있고 되돌림 범위도 넓다.

서버를 먼저 갱신하면 각 서버를 개별적으로 다뤄 장애 범위를 하나의 연동으로 제한할 수 있다. 문제가 생겨도 해당 연동만 되돌리면 되고, 클라이언트는 이후 더 안전하게 갱신할 수 있다. 대신 서버마다 작업이 반복되고 조율 부담이 커지며, 그동안 신규 기능을 쓸 수 없다. 사용처가 적은 서버부터 순차 검증한 뒤 마지막에 클라이언트를 올리는 순서는 위험과 조율 부담을 함께 관리한다.

능력 매트릭스는 버전별 기능 유무를 문서로 확정해 영향 판단과 업그레이드 계획 수립을 빠르게 하고, 신규 인력의 참조 근거가 된다. 스펙 갱신마다 유지 공수가 들며 실제 서버 구현이 스펙과 다르면 매트릭스가 틀릴 수 있다는 점은 한계다.

실행 시점 탐지는 서버가 실제로 응답한 능력을 근거로 삼는다. 별도 유지 없이 실제 구현을 확인할 수 있지만, 문제가 실행 중에야 드러나 사전 계획이 어렵고 탐지 결과를 축적하지 않으면 매번 다시 확인해야 한다. 매트릭스를 계획 근거로 사용하고, 실행 시점 탐지 결과로 자동 검증해 불일치를 경보하는 결합이 두 방식의 장점을 연결한다.

구성·변경 관리로 연결되는 지점

버전 협상과 폴백 정의는 이기종 시스템 사이에서 인터페이스 호환성을 확보하기 위한 설계에 해당한다. 능력 매트릭스는 연계 기능 명세를 관리하는 형태로 볼 수 있다.

서버 목록과 협상 버전을 추적하는 일은 구성 항목을 현행화하는 활동이다. 지원 버전 선언 규격은 구성 항목의 속성을 정의하는 역할을 한다.

업그레이드 순서 정책은 변경 실행 계획에서 순서와 영향 범위를 통제하는 장치다. 버전 조합별 호환성 시험 자동화는 변경 승인 전에 충족해야 할 검증 요건이 된다.

스펙 변화가 운영에 남기는 과제

스펙 날짜 기반 버전 표기가 정착하면 연동 문서에 지원 날짜를 적는 방식이 관행이 되는 방향이다. 폴백 발생도 관측 지표로 수집되면서, 오류 없이 발생하던 기능 축소가 운영 화면에 드러날 수 있다.

버전 조합 호환성 시험은 연동 계약의 검수 항목으로 요구되는 흐름에 가깝다. 논블로킹 기동과 페이지네이션 탐색 역시 대규모 서버 구성에서 기본 전제가 되는 방향이다.

서버가 그대로인 상태에서 클라이언트만 올라가면 기능은 조용히 사라질 수 있다. 지원 버전 선언, 협상 실패 처리, 폴백 정의, 능력 매트릭스, 버전 추적, 조합별 호환성 시험을 함께 운영해야 하는 이유다. 협상 결과와 폴백 발생을 남기지 않으면 기능 축소는 사용자 불만으로만 나타나며, 어느 업그레이드가 원인이었는지 되짚을 근거도 남지 않는다.