MCP Servers v2.0.0, 레거시 클라이언트를 유지하면서 현대 프로토콜 지원 추가

MCP Servers v2.0.0은 레거시 클라이언트 지원을 유지하면서 프로젝트의 참조 서버를 현대 프로토콜에 맞게 리팩터링한다. 10월 19일 출시된 이번 업데이트는 AI 애플리케이션을 도구 및 데이터와 연결하는 Model Context Protocol인 MCP의 서로 다른 세대를 잇는다. 호환성 약속에는 분명한 경계가 있다. 이전 클라이언트는 계속 지원되지만, TypeScript 서버는 이제 Node.js 24를 요구한다.

이 구분은 기존 통합을 유지하는 개발자에게 부담을 준다. 클라이언트는 이전 프로토콜로 계속 통신할 수 있지만, 해당 도구를 뒷받침하는 소프트웨어는 더 새로운 런타임을 요구할 수 있다. 따라서 애플리케이션 팀은 서버 패키지, 실행 환경, 프로토콜 동작에 관해 별도의 결정을 내려야 한다.

핵심 긴장은 현대화와 연속성 사이에 있다. 유지보수자는 연결된 모든 애플리케이션이 동시에 전환하도록 요구하지 않으면서 예제를 새로운 아키텍처로 옮기고 있다. Claude Desktop, VS Code 또는 맞춤형 AI 애플리케이션을 사용하는 개발자에게 당장의 질문은 이 전환 과정에서 어떤 전제가 유지되는지다. 연결 설정, 파일 권한, 애플리케이션 상태의 수명은 버전 번호 자체보다 더 면밀한 검토가 필요하다.

MCP Servers v2.0.0이 실제로 바꾸는 것

이번 릴리스는 더 넓은 MCP 커뮤니티의 모든 서버가 아니라, 정해진 참조 구현 모음을 업데이트한다.

릴리스 패키지 목록에는 버전 2.0.0으로 게시된 네 개의 TypeScript 패키지가 명시되어 있다. Everything, Filesystem, Memory, Sequential Thinking을 다룬다. TypeScript는 JavaScript에 타입 검사를 추가하는 프로그래밍 언어다.

동일한 릴리스에는 Fetch, Git, Time의 세 가지 Python 패키지도 나열되어 있다. 이들은 날짜 기반 버전인 2026.10.19를 사용한다. 저장소의 릴리스 태그가 모든 패키지의 버전이 되는 것은 아니므로, 팀이 의존성을 목록화할 때 이 구분은 중요하다.

유지보수자는 이 업데이트를 레거시 클라이언트에 계속 응답하면서 현대 사양을 지원하는 리팩터링이라고 설명한다. 이는 포함된 서버에 관한 구현상의 주장이다. 관련 없는 커뮤니티 통합이나 MCP를 통해 연결되는 모든 애플리케이션의 호환성을 보장하는 것은 아니다.

서로 다른 버전 체계도 작동한다. 저장소 릴리스는 v2.0.0을 사용하며 프로토콜은 날짜 기반 식별자를 사용한다. 패키지 버전은 배포된 소프트웨어를 식별하고, 프로토콜 식별자는 해당 소프트웨어가 지원하는 통신 규칙을 설명한다.

이러한 식별자를 혼동하면 오해를 부르는 업그레이드 기대가 생길 수 있다. 2.0.0으로 표시된 패키지를 설치한다고 해서 애플리케이션이 모든 최신 프로토콜 기능을 자동으로 채택하는 것은 아니다. 클라이언트는 지원되는 통신 동작 중 무엇을 사용할지 계속 결정한다.

이 때문에 MCP 서버 호환성은 구성 요소 간의 관계다. 서버 패키지는 여러 프로토콜 개정판을 지원할 수 있고, 연결된 애플리케이션은 이전 개정판을 계속 사용할 수 있다. 반대로, 더 새 서버 소프트웨어를 설치해도 클라이언트에 없는 기능이 제공되지는 않는다.

엔지니어링 관리자에게 이번 릴리스는 가용성과 준비 상태를 구분하는 데 유용하다. 게시된 패키지는 구현을 사용할 수 있음을 보여준다. 준비 상태는 주변 애플리케이션, 실행 환경, 권한 및 예상 동작이 함께 작동하는지에 달려 있다.

실질적인 의미는 이 패키지를 직접 실행하는 사람에만 국한되지 않는다. 참조 구현은 다른 개발자가 연구하고 적용하는 예시를 제공한다. 참조 패키지가 프로덕션 의존성 목록에 전혀 들어가지 않더라도, 그 아키텍처 선택은 맞춤형 통합에 영향을 줄 수 있다.

그 영향은 신중히 표현할 필요가 있다. 예시는 패턴을 제시할 수 있지만, 그 패턴이 모든 배포 환경에 적합함을 입증하지는 않는다. 이번 릴리스는 구체적인 구현 자료를 제공하지만, 애플리케이션 소유자는 어떤 부분이 자신의 시스템에 맞는지 결정할 책임을 계속 진다.

따라서 이 소식은 MCP가 전반적으로 바뀌었다는 광범위한 발표보다 더 구체적이다. 유지보수자는 최신 프로토콜 동작을 이전 클라이언트의 설치 기반과 연결하는 업데이트된 예제를 배포했다. 다음 질문은 이러한 예제를 실행하는 데 필요한 인프라에 관한 것이다.

이전 클라이언트는 계속 지원되지만, 이전 런타임은 아니다

프로토콜 호환성이 이전 실행 환경을 보존하는 것은 아니다.

릴리스의 Node.js 요구 사항은 TypeScript 서버의 최소 Node.js 버전을 24로 올린다. Node.js는 브라우저 밖에서 JavaScript를 실행하는 런타임이다. 이 변경은 Everything, Filesystem, Memory, Sequential Thinking에 적용된다.

관련 유지보수 기록은 이 요구 사항이 주목할 만한 이유를 설명한다. 이전에는 패키지 선언, 문서, 자동화된 검사가 서로 다른 지원 기대치를 설명했다. 이번 수정은 선언된 최소 버전, 문서, 검증 구성을 더 새로운 런타임에 맞춰 정렬한다.

이는 로컬 AI 애플리케이션에 구체적인 마이그레이션 문제를 만든다. 사용자는 애플리케이션의 실행 환경은 그대로 둔 채 서버 패키지만 업데이트할 수 있다. 클라이언트의 프로토콜은 여전히 허용되지만, 서버는 그 프로세스에서 사용할 수 있는 런타임에 계속 의존한다.

개발 환경과 데스크톱 애플리케이션 환경이 분리된 예시 엔지니어링 워크스테이션을 생각해 볼 수 있다. 터미널은 예상한 런타임을 보고할 수 있지만, 다른 위치에서 실행된 애플리케이션은 다른 구성을 상속할 수 있다. 터미널에서의 성공적인 실행만으로는 데스크톱 애플리케이션이 동일한 서버를 실행할 수 있는지 판단할 수 없다.

이 사례는 릴리스에서 보고된 결함이 아니라 배포 추론을 보여준다. 더 넓은 시사점은 새 최소 요구 사항에서 직접 따른다. 팀은 실제로 패키지를 시작하는 환경에 관한 근거를 확보해야 한다.

부담은 구성 배포 개발자, 관리형 워크스테이션을 유지하는 관리자, 내부 지원 도구를 패키징하는 팀에 가장 직접적으로 돌아간다. 이들의 책임에는 도구의 선언된 인터페이스뿐 아니라 도구를 실행하는 소프트웨어도 포함된다.

이들 팀에게 하위 호환성은 조율 작업을 줄일 수는 있어도 없애지는 못한다. 이전 클라이언트를 즉시 다시 작성할 필요는 없을 수 있다. 그러나 더 새 서버의 요구 사항은 여전히 고려해야 한다.

이 구분은 실패를 해석하는 방식도 바꾼다. 시작할 수 없는 프로세스는 실행 중인 서버가 요청을 거부하는 경우와 다른 문제다. 둘 다 프로토콜 비호환성으로 취급하면 조사가 잘못된 구성 요소를 향하게 된다.

같은 추론은 지원 문서에도 적용된다. 레거시 클라이언트가 계속 지원된다는 안내에는 런타임 요구 사항에 대한 맥락이 인접해 있어야 한다. 그렇지 않으면 독자는 유지보수자가 실제로 약속한 것보다 더 넓은 범위의 약속을 합리적으로 추론할 수 있다.

의존성을 선택한 버전으로 고정하는 패키지 피닝은 눈에 보이는 결과를 수반하는 운영상의 선택이 된다. 팀은 예기치 않은 패키지 변경과 환경 변경을 함께 겪는 대신, 새 릴리스를 의도적으로 평가할 수 있다.

이는 업데이트를 미뤄야 한다는 보편적 주장을 뜻하지는 않는다. 업데이트 이유를 구분할 필요가 있음을 뜻한다. 현대 프로토콜 동작을 원하는 팀은 기존 워크플로를 유지하려는 팀과 당면한 목표가 다르다.

이번 릴리스는 두 팀 모두에 앞으로 나아갈 경로를 제공하지만, 검증은 서로 다른 목표를 반영해야 한다. 이전 클라이언트를 유지한다는 것은 동작의 지속성을 확인하는 일이다. 더 새 클라이언트를 채택한다면 요청을 처리하는 아키텍처도 검토해야 한다.

호환성 브리지는 요청이 컨텍스트를 전달하는 방식을 바꾼다

눈에 보이는 도구가 익숙하게 유지되더라도, 더 새로운 아키텍처는 통신 컨텍스트가 위치하는 곳을 바꾼다.

현재 프로토콜 버전 관리 규칙에 따르면 프로토콜 개정판은 2026-07-28이다. 요청은 요청에 수반되는 설명 정보인 메타데이터를 통해 프로토콜 버전을 선언한다. 서버는 지원되는 버전에 따라 요청을 개별적으로 수락하거나 거부한다.

클라이언트는 서버 식별 정보, 지원 버전, 기능을 반환하는 탐색 요청인 server/discover를 사용할 수 있다. 이전 프로토콜 개정판은 대신 연결의 운영 컨텍스트를 설정하는 초기 교환인 초기화 핸드셰이크를 사용한다.

현대 프로토콜 구현은 두 접근 방식을 TypeScript 참조 서버에 도입한다. 로컬 연결에서는 첫 번째 메시지가 프로토콜 세대를 선택한다. 이전 클라이언트는 initialize로 시작하고, 현대 클라이언트는 탐색 또는 새로운 요청 메타데이터를 사용한다.

구현은 또한 세션 식별자로 색인된 서버 상태에서 벗어난다. 연결별 상태는 서버 인스턴스에 존재한다. 현대 요청 이후에도 유지되어야 하는 정보는 해당 정보를 참조하도록 서버가 발급하는 식별자인 핸들을 사용한다.

이 세부 사항은 “무상태”가 오해될 수 있기 때문에 중요하다. 프로토콜 세션에 대한 의존성을 없앤다고 해서 애플리케이션이 각 요청 이후 모든 것을 잊는다는 뜻은 아니다. 개발자가 정보가 어디에 존재하고 이후 작업이 그것을 어떻게 참조하는지 명시적으로 식별해야 한다는 뜻이다.

맞춤형 통합에서는 이 구분이 아키텍처 검토에 영향을 준다. 개발자는 요청에 속한 정보와 연결 또는 저장된 애플리케이션 데이터에 속한 정보를 분리해야 한다. 이들의 수명은 반드시 일치할 필요가 없다.

프로젝트 관련 사실을 보존하는 지원 도구는 도구가 임시 진행 상황을 보존하는 경우와 다른 요구 사항을 제시한다. 영구 정보는 제품의 저장 규칙에 따라 유지되어야 한다. 임시 정보는 의도한 작업 또는 상호작용에 필요한 기간에만 이용 가능해야 한다.

Memory 서버는 이 차이를 보여준다. 엔터티를 관계로 연결하는 구조인 지식 그래프는 영구 정보를 제공한다. 문서는 동일한 기본 도구와 리소스를 유지하면서 현대 및 레거시 클라이언트에 서로 다른 구독 메커니즘을 설명한다.

구독은 정보가 변경될 때 업데이트를 받기 위한 요청이다. 중요한 제품 질문은 애플리케이션이 해당 업데이트를 계속 받는지에 관한 것이다. 초기 읽기에 성공했다고 해서 이후 변경 사항이 예상대로 나타난다는 사실이 입증되지는 않는다.

Sequential Thinking은 또 다른 수명 구분을 제시한다. 문서는 어느 프로토콜 세대에서든 사고 이력이 연결 기간 동안 지속된다고 설명한다. 이 동작은 영구 메모리에 대한 일반적 약속이 아니라 도구의 작업 컨텍스트에 관한 것이다.

Everything은 다시 다른 목적을 수행한다. 현대 요청 및 알림 동작을 포함해 클라이언트 제작자를 위한 프로토콜 기능을 시험한다. 단순히 성공한 도구 호출로는 검토되지 않을 통합 동작을 드러내는 데 그 가치가 있다.

이 예들을 종합하면 MCP 서버 마이그레이션이 import나 패키지 이름을 바꾸는 일 이상인 이유를 알 수 있다. 눈에 보이는 기능은 알아볼 수 있는 상태로 남을 수 있지만, 주변 통신 모델은 달라진다. 참조 코드를 적용하는 개발자는 두 계층을 모두 이해해야 한다.

호환성 접근 방식의 의미가 드러나는 지점도 바로 여기다. 이전 클라이언트 지원은 애플리케이션 팀에 시간을 벌어 준다. 그렇다고 해당 동작을 채택하기 전에 새 아키텍처를 이해할 필요가 사라지는 것은 아니다.

파일 시스템 접근은 동작상의 차이를 구체화한다

동일한 서버 패키지라도 클라이언트의 프로토콜 시대에 따라 서로 다른 권한 설정이 필요할 수 있습니다.

Filesystem 서버는 도구가 액세스할 수 있는 로컬 디렉터리에 영향을 미치므로 가장 명확한 사례를 제공합니다. 허용 목록은 명시적으로 허가된 위치들의 집합입니다. 서버의 현대적 연결 방식은 프로세스 시작 시 제공되는 디렉터리를 사용합니다.

태그가 지정된 디렉터리 액세스 제어 문서는 프로토콜 버전 전반에서 이러한 시작 인수를 권장합니다. 이전 클라이언트는 파일 시스템 위치를 설명하는 클라이언트 제공 메커니즘인 Roots도 사용할 수 있습니다. 현대적 연결 방식은 이 레거시 정보를 요청하지 않습니다.

따라서 허용된 디렉터리 없이 시작된 서버는 연결 경로에 따라 다르게 동작합니다. 현대적 도구 호출의 경우, 문서는 누락된 디렉터리 구성 정보를 설명하는 오류를 안내합니다. 단순히 프로세스가 연결되었다고 해서 사용할 수 있는 파일 액세스가 설정되는 것은 아닙니다.

레거시 클라이언트의 경우 문서는 액세스 업데이트와 철회도 설명합니다. Roots 새로고침이 대기 중인 동안 도구 호출은 기다립니다. 클라이언트가 제공한 루트가 적용된 뒤 유효한 루트가 없는 업데이트가 전달되면, 유효한 루트가 다시 제공될 때까지 액세스가 제거됩니다.

제품 측면의 의미는 명확합니다. 연결 성공과 권한 성공은 별개의 결과입니다. 클라이언트는 서버를 찾고 해당 도구를 인식할 수 있지만, 의도한 파일로 이어지는 유효한 경로가 없을 수 있습니다.

로컬 디자인 문서를 비교하도록 엔지니어를 돕는 가상의 어시스턴트를 생각해 보겠습니다. 클라이언트 업그레이드 전후로 사용자의 요청은 똑같이 들립니다. 하지만 애플리케이션은 다른 프로토콜 경로로 진입해 서로 다른 구성 요구 사항에 맞닥뜨릴 수 있습니다.

이전 구성이 클라이언트 제공 Roots에 의존했다면, 현대적 경로를 채택할 때는 시작 디렉터리에 주의해야 합니다. 사용자의 표현만으로는 이러한 의존성을 알 수 없습니다. 파일 작업이 존재한다는 도구 목록도 마찬가지입니다.

이 때문에 권한은 각주가 아니라 마이그레이션 분석에 포함되어야 합니다. 파일 액세스는 프로토콜 동작을 사용자 기대와 직접 연결합니다. 구성 불일치는 사용자에게 지식이 누락된 것처럼, 또는 어시스턴트가 요청을 이해하지 못한 것처럼 보일 수 있습니다.

문제 해결도 복잡해질 수 있습니다. 기본 도구가 의도한 위치에 액세스하지 못하는데도, 팀은 소프트웨어가 관련 정보를 얼마나 효과적으로 찾는지를 의미하는 검색 품질을 조사할 수 있습니다. 릴리스 문서는 이러한 가능성을 구분하는 데 도움이 됩니다.

지식 워크플로에서는 팀이 커넥터의 액세스 경계와 그 결과로 생성되는 정보 시스템의 품질을 구분해야 합니다. 검색 가능한 지식 기반은 관련 문서가 이용 가능하고, 정리되어 있으며, 검색 가능해야 합니다. 프로토콜 지원은 그 연결 고리의 일부만 해결합니다.

이 사례는 개발자가 하위 호환성에서 무엇을 추론해야 하는지도 제한합니다. 레거시 동작이 계속 지원된다고 해서 현대적 클라이언트에서도 동일한 권한 구성이 적용된다는 뜻은 아닙니다. 두 경로는 서로 다른 메커니즘에 의존하면서도 모두 지원될 수 있습니다.

어시스턴트를 평가하는 조직에는 이 차이가 구체적인 구매 검토 질문을 만듭니다. 액세스 가능한 위치를 정의하는 구성 요소는 무엇이며, 애플리케이션은 누락되거나 철회된 액세스를 어떻게 알리는가? 답변은 지원되는 표준을 나열하는 데 그치지 않고 실제 동작을 설명해야 합니다.

참조 구현이 자신의 경계를 문서화하므로, 이번 릴리스는 이 질문을 더 쉽게 조사할 수 있게 합니다. 다른 통합은 여전히 각자의 근거가 필요합니다. 프로토콜 레이블을 복사한다고 해서 동등한 액세스 규칙을 적용한다는 사실이 입증되지는 않습니다.