MCP 최종 사양 전환과 버전 호환 아키텍처 설계

모델과 도구를 연결하는 MCP(Model Context Protocol)는 2026년 5월 21일 릴리스 후보를 확정한 뒤 10주 검증을 거쳐 7월 28일 최종 사양을 발행한다. 출시 이후 프로토콜 최대 개정으로 규정된 이번 변화는, 이미 운영 중인 서버와 클라이언트가 버전 협상 및 하위 호환 방식을 다시 설계하게 만든다.

핵심은 새 기능을 익히는 일보다 세션에 기대던 경로를 걷어내고, 전환 기간의 조합을 통제하는 데 있다.

무상태 코어가 바꾸는 서버 운영 방식

최종 사양은 initialize 핸드셰이크와 Mcp-Session-Id 헤더를 제거하는 무상태 코어를 채택한다. 세션을 만들 때 한 번 버전을 합의하던 구조에서 벗어나, 요청마다 버전 정보를 전달하는 방식으로 옮겨가는 변화다.

이제 임의의 요청은 임의의 서버 인스턴스에 도달할 수 있다. 원격 서버는 스티키 세션, 공유 세션 저장소, 게이트웨이의 심층 패킷 검사 없이도 단순 라운드로빈 로드밸런서 뒤에서 동작할 수 있다. Mcp-Method 헤더를 기준으로 라우팅하고, 서버가 지정한 ttlMs 범위에서 클라이언트가 tools/list를 캐싱하는 구성도 가능해진다.

무상태 전환은 전송 계층의 선택지를 넓힌다. 세션 고정 요구가 사라지므로 로드밸런서, CDN, API 게이트웨이를 포함한 표준 HTTP 인프라 위에 그대로 배치할 수 있다. 게이트웨이가 본문을 파싱하지 않아도 메서드별 레이트리밋과 권한 정책을 적용할 수 있다는 점도 운영 구조를 단순하게 만든다.

요청마다 드러나는 버전과 능력

서버는 지원하는 버전 집합을 공개하고, 클라이언트는 요청에 사용할 버전을 명시해야 한다. 지원하지 않는 버전이라면 오류 규약에 따라 분명하게 실패를 반환해야 한다. 암묵적 다운그레이드는 원인을 추적하기 어려운 오동작으로 이어진다.

Extensions가 도입되면서 프로토콜은 코어와 선택 확장의 조합으로 확장된다. 서버는 지원 기능을 선언하고, 클라이언트는 선언된 범위 안에서만 호출해야 한다. 미지원 확장을 만났을 때도 클라이언트에는 우아한 축퇴(graceful degradation) 경로가 필요하다.

도구 입출력 스키마 역시 서버와 클라이언트 양쪽에서 검증해야 한다. 전환기에는 같은 스키마를 다르게 해석하는 일이 가장 흔한 실패 원인이 될 수 있다. 검증 실패를 오류로 볼지 경고로 볼지 정책을 명시하고, 전환기에는 경고와 로깅을 거친 뒤 안정화 후 오류 처리로 바꾸는 방식이 실무적이다.

⤢✕

호환 경로를 분리해 관리하기

서버에서는 구 버전 요청을 신 버전의 내부 표현으로 바꾸는 어댑터가 필요하다. 세션 기반 구 클라이언트를 위해 세션 ID를 받아들이되, 무시하는 처리도 포함된다.

클라이언트에는 신 버전을 지원하지 않는 서버를 위한 폴백이 필요하다. 이 경우 기존 핸드셰이크와 세션 헤더를 사용하는 경로로 돌아간다. 이중 지원 기간에는 두 경로의 테스트를 계속 유지해야 하므로 테스트 매트릭스가 배로 늘어난다.

전환에 앞서 보유한 MCP 서버와 클라이언트의 인벤토리를 만들고, 각각의 프로토콜 버전, 사용 SDK, 세션 의존 여부를 기록한다. 특히 세션 ID를 상태 키로 사용하는 로직은 무상태 전환에서 가장 큰 걸림돌이다.

배포 순서는 SDK 업그레이드, 이중 지원 배포, 클라이언트 전환, 구 경로 제거로 이어진다. 클라이언트를 먼저 바꾸면 서버 미지원으로 즉시 장애가 발생할 수 있다.

지원 매트릭스는 서버 버전, 클라이언트 버전, 사용 확장을 축으로 삼는다. 지원 조합과 비지원 조합을 모두 문서화하고, 조합 폭발을 피하려면 최신 버전과 직전 1개처럼 지원 버전 수를 제한하는 정책이 필요하다.

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

이중 지원의 종료 조건을 먼저 정한다

외부 소비자가 있는 서버라면 하위 호환 병행이 사실상 불가피하다. 이중 지원 기간은 명시적으로 정의하고 종료일을 사전에 공지해야 한다. 기간을 무기한으로 두면 구 경로가 영구 부채가 되고, 무상태 전환으로 얻는 인프라 단순화 효과도 계속 미뤄진다.

병행 기간에는 버전별 요청 비중을 계측해 구 경로 트래픽이 임계 이하로 떨어졌을 때 제거한다. 공식 폐기 정책이 도입되는 만큼 폐기 공지를 수신하고 잔여 기간을 추적하는 일도 정례 업무에 넣어야 한다.

Extensions는 코어의 안정성과 확장 기능의 진화 속도를 분리한다. 따라서 확장 채택 여부는 코어 전환과 별도로 판단할 수 있다. 프로토콜 버전 전환 자체는 변경관리 대상으로 두고, 적합성 테스트 리포트를 승인 증적으로 규정하는 편이 낫다. 외부에 공개한 MCP 서버가 있다면 소비자 공지 절차와 유예 기간도 계약 또는 정책으로 정의해야 한다.

통제 범위에 따라 달라지는 선택

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

서버와 클라이언트를 모두 조직이 통제한다면, 즉시 채택이 총공수와 부채 측면에서 유리하다. 외부 소비자가 있는 서버는 병행이 필요하며, 종료일을 정하는 일이 전제 조건이 된다.

표준 프로토콜 준수는 클라이언트 교체 시 재작업을 줄이고 도구 자산을 이식 가능하게 만든다. 반면 벤더 전용 연동은 초기 구현이 단순하고 벤더 고유 기능을 온전히 쓸 수 있지만, 클라이언트를 바꾸는 순간 전량 재구현이 필요하다. 최대 규모 개정이 발생했다는 사실은 표준도 계속 움직인다는 뜻이므로, 표준 준수에도 버전 전환 비용이 존재한다.

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

계획된 변경으로 전환을 흡수하려면

프로토콜 표준의 가치는 안정성에서 나오지만, 초기 표준은 개정을 겪는다. 표준 채택을 결정할 때는 준수의 이점뿐 아니라 버전 전환 비용도 명시적으로 계상해야 한다. 공식 폐기 정책의 도입은 표준 성숙의 신호이며, 폐기 정책이 있으면 전환 계획을 미리 세울 수 있다.

무상태 코어는 표준 HTTP 인프라와의 상호운용성을 높인다. 스티키 세션, 공유 세션 저장소, 심층 패킷 검사가 사라지면 운영 구성은 일반 웹 서비스에 가까워진다. 다만 능력 선언을 바탕으로 한 축퇴 경로가 없다면 상호운용성은 문서상의 약속에 그친다. 미지원 조합에서 어떻게 동작하는지까지 정의돼야 한다.

외부 표준의 개정은 조직이 통제할 수 없는 변경이다. 이를 통제 가능한 변경으로 바꾸는 수단은 버전 매트릭스와 이중 지원 기간의 명시적 종료다. 적합성 테스트 자동화는 전환 승인에 객관적 증적을 제공한다. 수동 검증 결과만을 승인 근거로 삼으면 매트릭스가 커질수록 신뢰도는 무너진다.

무상태 코어 채택이 확산되면 원격 MCP 서버 운영은 일반 HTTP 서비스 운영 수준으로 단순화되는 흐름을 보일 수 있다. Extensions는 코어 안정성과 기능 확장 속도를 분리하고, 확장 단위의 채택 판단은 새로운 아키텍처 결정 항목으로 편입된다. 인가가 OAuth·OIDC 배포 관행에 정합해지면서 기존 아이덴티티 인프라와의 통합 부담도 감소하는 방향이다. 공식 폐기 정책이 정착하면 프로토콜 전환은 돌발 대응이 아니라 계획된 변경관리 업무로 이동한다.