Anthropic, Simon Willison, 그리고 Stateless MCP의 반전

Anthropic은 2024년에 MCP를 도입했지만, Simon Willison은 이후 터미널 도구가 더 유연하다고 판단했다. 그러나 2026년 7월 28일 명세는 이제 그 평가의 일부를 뒤집었다. 프로토콜 세션을 없애고 원격 MCP 호출을 독립적인 요청으로 전환한 것이다.

이 변화는 Willison의 관심을 다시 불러일으켰고 mcp-explorer와 datasette-mcp라는 두 프로젝트에 영감을 주었다. 더 중요한 점은 원격 MCP 서버를 일반 HTTP 서비스보다 배포하기 어렵게 만들었던 아키텍처적 약점을 겨냥한다는 것이다.

따라서 Anthropic과 Simon Willison을 둘러싼 이야기는 단순한 프로토콜 업데이트가 아니다. MCP가 명령줄 도구와의 경쟁을 멈추고 더 설득력 있는 역할에 안착할 수 있는지를 가늠하는 시험대다. Skills는 에이전트에게 기존 소프트웨어 사용법을 가르치는 방식으로 여전히 매력적이며, Stateless MCP는 구조화된 원격 도구, 검색, 권한 부여, 공유 인프라를 제공한다.

Stateless MCP는 모든 요청 경로에서 세션을 제거한다

새 명세는 MCP를 연결 중심 프로토콜에서 요청 중심 프로토콜로 바꾼다.

Model Context Protocol은 AI 에이전트가 외부 도구를 검색하고 호출할 수 있도록 하는 표준 인터페이스를 정의한다. Anthropic은 2024년 11월 이를 도입했고, 개발자들은 빠르게 데이터베이스, 브라우저, 커뮤니케이션 플랫폼, 비즈니스 애플리케이션용 서버를 만들었다.

이전 버전에서는 일반 도구 호출에 앞서 초기화 과정이 필요했다. 클라이언트와 서버는 프로토콜 버전, 기능, 식별 정보를 교환했다. 이 협상으로 이후 메시지가 유지해야 할 컨텍스트가 설정됐다.

HTTP 서버는 Mcp-Session-Id도 발급할 수 있었다. 이후 클라이언트는 해당 식별자를 요청과 함께 다시 보냈다. 이 방식은 일련의 호출을 특정 클라이언트와 서버 인스턴스 간에 이어지는 하나의 대화처럼 동작하게 만들었다.

이 설계는 인프라 측면의 결과를 낳았다. 로드 밸런서는 관련 호출을 올바른 인스턴스로 라우팅하거나 세션 데이터를 공유 저장소에 둬야 했다. 운영자는 만료, 재연결, 복구, 정리를 위한 정책도 마련해야 했다.

최종 2026-07-28 개정안은 필수 initialize 핸드셰이크를 제거한다. 프로토콜 수준의 세션과 관련 헤더도 없앤다. 이제 각 요청에는 독립적으로 해석하는 데 필요한 정보가 포함된다.

공식 MCP release는 이 개정을 프로토콜 출시 이후 가장 큰 변화라고 설명한다. Stateless 코어에는 확장 기능, 개정된 Tasks 지원, 권한 부여 변경, 정식 기능 수명 주기가 더해졌다.

이제 클라이언트는 도구 호출을 직접 보낼 수 있다. 요청에는 프로토콜 버전, 메서드, 도구 이름, 클라이언트 정보, 관련 기능이 담긴다. 호환되는 모든 서버 인스턴스는 이전 교환에 의존하지 않고 이를 처리할 수 있다.

이 변경은 필요할 때 클라이언트가 서버 기능을 요청할 수 있는 server/discover도 추가한다. 검색을 위해 더는 모든 호출자가 프로토콜 세션을 생성하고 유지할 필요가 없다.

이는 모든 애플리케이션이 상태를 버려야 한다는 뜻과는 다르다. 브라우저 자동화 서비스, 장바구니, 데이터베이스 트랜잭션, 리서치 워크플로는 여전히 호출 간 정보를 유지할 수 있다.

차이는 그 정보가 어디에 존재하고 어떻게 참조되는지에 있다. 서버는 이를 세션 뒤에 숨기는 대신 명시적인 식별자를 반환할 수 있다. 모델은 이후 호출에서 해당 식별자를 제공한다.

브라우저 서버는 인스턴스를 시작한 뒤 browser_id를 반환할 수 있다. 이후 도구는 페이지 이동, 캡처, 브라우저 종료 시 이 값을 받을 수 있다. 데이터베이스 도구도 트랜잭션 식별자에 같은 패턴을 적용할 수 있다.

채택된 sessionless proposal은 이 값을 명시적 상태 핸들로 설명한다. 이는 새로운 MCP 데이터 타입이 아니다. 애플리케이션 상태를 드러내는 일반적인 도구 입력과 출력이다.

이러한 가시성은 에이전트에게 중요하다. 오케스트레이터는 한 서브에이전트와 하나의 핸들을 공유하면서 다른 핸들은 분리된 상태로 유지할 수 있다. 식별자를 기록해 이후 작업에 쓰거나, 권한을 가진 다른 프로세스에 전달할 수도 있다.

목록 작업에는 별도의 이점도 있다. 도구와 리소스가 더는 모호한 세션에 따라 바뀔 수 없으므로, 클라이언트는 검색 결과를 더 안전하게 캐시할 수 있다. 이는 수명이 짧은 에이전트 전반에서 반복 호출을 줄인다.

Stateless MCP는 익숙한 HTTP 작업에도 더 자연스럽게 매핑된다. 원격 서버는 표준 라운드로빈 밸런싱, 일반 게이트웨이 라우팅, 요청별 인증, 검증된 관측성 시스템을 사용할 수 있다.

이 조합이 Willison의 관심을 되살린 요인이다. 이 업데이트는 단지 핸드셰이크를 짧게 만드는 데 그치지 않는다. 이전에는 모든 배포와 클라이언트 구현에 스며들었던 아키텍처적 전제를 제거한다.

Anthropic과 Simon Willison의 반전이 중요한 이유

Willison의 새 관심이 중요한 이유는, 그의 이전 비판이 코딩 에이전트 사용자들 사이에서 MCP를 떠나는 실제 흐름을 포착했기 때문이다.

MCP는 2025년 대부분의 기간 동안 큰 관심을 끌었다. 그 가치 제안은 이해하기 쉬웠다. 하나의 서버 인터페이스를 구현하면 여러 호환 AI 클라이언트에 동일한 도구를 노출할 수 있다는 것이었다.

하지만 그와 동시에 코딩 에이전트도 발전하고 있었다. 이들은 신뢰할 수 있는 터미널 접근, 더 나은 셸 활용 능력, 문서를 살피는 능력을 갖추게 됐다. 상당수는 라이브러리를 설치하거나 curl로 일반적인 API를 호출할 수 있었다.

이는 직접적인 도전 과제를 만들었다. 문서화가 잘 된 명령줄 프로그램은 이미 조합 가능한 도구 인터페이스를 제공한다. 에이전트는 프로토콜 어댑터 없이도 명령을 조합하고, 출력을 리디렉션하며, 작은 스크립트를 작성하고, 오류를 확인할 수 있다.

Skills는 이 경로를 강화했다. 스킬은 에이전트에게 작업 수행 방법을 가르치는 지침, 스크립트, 참고 자료의 패키지다. 소유자가 MCP 서버를 운영할 필요 없이 기존 API를 설명할 수 있다.

Willison은 2025년을 돌아본 글에서 자신의 회의론을 요약했다. 코딩 에이전트에는 MCP보다 명령줄 유틸리티와 라이브러리를 선호했다. 이 선택지는 또 하나의 서비스 계층을 피하면서 모델에 더 큰 자유를 줬다.

그 비판은 구조화된 도구 호출에 가치가 없다는 주장이 아니었다. 더 어려운 질문은 MCP가 세션, 전송 관리, 클라이언트 호환성 작업, 컨텍스트 오버헤드를 정당화할 만큼 충분한 추가 가치를 제공하는지였다.

Stateless MCP는 그 격차를 좁힌다. 이제 작은 원격 도구도 에이전트 클라이언트를 위한 기계 판독형 계약을 유지하면서 일반적인 웹 엔드포인트처럼 동작할 수 있다.

Willison의 stateless MCP analysis는 이 변화를 두 가지 실험과 연결한다. 첫 번째는 MCP 서버를 더 쉽게 살피고 이해하도록 설계된 mcp-explorer다. 두 번째는 새로운 접근 방식을 Datasette에 적용하는 datasette-mcp다.

Datasette는 구조화된 데이터를 탐색하고 게시하기 위한 Willison의 오픈소스 시스템이다. 이미 웹 인터페이스와 API를 통해 데이터베이스를 노출한다. MCP는 도구를 사용하는 언어 모델을 위해 특별히 설계된 또 다른 접점을 제공한다.

이 조합은 시사하는 바가 크다. Datasette 배포는 본질적으로 원격이고, 구조화되어 있으며, 사용자 간에 공유된다. 에이전트 옆에 설치되는 개발자 유틸리티만큼 깔끔하게 로컬 명령줄 모델에 들어맞지는 않는다.

MCP 서버는 클라이언트가 이해하는 스키마를 사용해 데이터베이스 도구를 알릴 수 있다. 에이전트는 쿼리를 제출하기 전에 사용할 수 있는 작업을 살필 수 있다. 서버 운영자는 인증, 권한, 한도, 구현 세부 사항에 대한 통제권을 유지한다.

이는 Anthropic과 Simon Willison의 비교를 MCP 대 Skills라는 구도보다 더 미묘하게 만든다. 스킬은 에이전트에게 API 질의 방법을 가르칠 수 있다. MCP는 여러 클라이언트에 그 API를 검색하고 호출하기 위한 공유 계약을 제공할 수 있다.

두 접근 방식은 함께 작동할 수도 있다. 스킬은 MCP 서버를 언제 사용해야 하는지 설명하고, 도메인 개념을 풀어주거나, 여러 도구에 걸친 워크플로를 제공할 수 있다. MCP는 원격 실행 경계를 처리할 수 있다.

이 구분은 MCP가 모든 에이전트 행동을 위한 만능 답이 되어야 한다는 부담을 줄인다. 로컬 명령은 로컬에 남을 수 있다. 라이브러리는 유연한 코딩 작업에 쓰일 수 있다. Skills는 운영 지식을 패키지화할 수 있다.

MCP는 서버가 실행을 통제하고 여러 클라이언트에 동일한 검색 가능한 인터페이스가 필요한 영역에서 더 명확한 역할을 얻는다. 엔터프라이즈 데이터, 호스팅 검색, 공유 서비스, 인증된 비즈니스 시스템이 이 패턴에 들어맞는다.

따라서 프로토콜의 단순성은 경쟁 구도를 바꾼다. 개발자는 더는 모든 도구가 MCP 래퍼를 가질 가치가 있는지 물을 필요가 없다. 대신 원격 기능이 표준화된 검색과 호출의 이점을 얻는지 물을 수 있다.

이는 MCP에 대한 초기의 가장 광범위한 해석보다 작은 약속이다. 하지만 더 신뢰할 만하다. 표준은 경계가 명확해진 뒤에야 유용해지는 경우가 많다.

Stateless 요청은 MCP를 일반적인 클라우드 인프라에 맞춘다

MCP 2.0이 중요한 이유는 일반적인 배포 경로에서 특수한 조정을 제거하기 때문이다.

채택된 stateless proposal은 기존 초기화 모델의 세 가지 문제를 지적한다. 세션은 확장을 복잡하게 하고, 장애 복구를 약화하며, 양측의 구현 작업을 늘렸다.

세 개의 서버 인스턴스에서 실행되는 원격 검색 도구를 생각해 보자. 세션 지향 설계에서는 이후 호출이 초기화를 처리한 동일한 인스턴스를 필요로 할 수 있다. 기본 라운드로빈 로드 밸런서는 그 결과를 보장할 수 없다.

운영자는 고정 라우팅으로 이 문제를 해결할 수 있다. 세션 데이터를 공유 서비스에 저장할 수도 있다. 두 방식 모두 운영 상태, 추가 장애 모드, 새로운 모니터링 요구 사항을 도입한다.

고정 세션은 작업을 불균등하게 분배할 수 있다. 공유 저장소는 또 다른 의존성을 만든다. 서버 재시작은 로컬 상태를 무효화할 수 있고, 클라이언트는 장애를 감지해 초기화를 다시 수행해야 한다.

새 요청 모델에서는 호환되는 도구 호출을 정상 인스턴스 어느 곳에서나 처리할 수 있다. 게이트웨이는 연결 이력이 아니라 메서드와 도구 메타데이터를 기준으로 라우팅할 수 있다.

이 변화는 서버리스 배포도 더 현실적으로 만든다. 수요에 따라 인스턴스를 시작하고 중지하는 플랫폼은 요청이 이전 요청이 남긴 메모리에 의존하지 않을 때 가장 잘 작동한다.

서버는 실제로 지속되어야 하는 애플리케이션 상태를 위해 여전히 영속 스토리지가 필요하다. Stateless MCP가 데이터베이스, 객체 저장소, 브라우저 워커, 작업 큐를 없애는 것은 아니다. 프로토콜 상태가 이들과 함께 따라야 한다는 가정을 제거할 뿐이다.

장기 실행 작업은 이제 확장 기반 모델 안에 놓인다. 서버는 작업 핸들을 반환할 수 있고, 클라이언트는 이후 명시적인 작업을 통해 해당 작업을 확인, 갱신 또는 취소할 수 있다.

이 구분은 중요하다. 숨겨진 세션 상태는 워크플로를 전송 관계에 결합한다. 작업 핸들은 워크플로를 권한을 가진 다른 구성 요소가 관리할 수 있는 주소 지정 가능한 리소스로 바꾼다.

Multi Round-Trip Requests는 또 다른 어려운 사례를 다룬다. 일부 도구는 완료 전에 사용자나 클라이언트로부터 더 많은 정보를 받아야 한다. 이전 구현에서는 이러한 교환이 이미 설정된 세션과 연결됐다.

새 설계에서는 서버가 클라이언트 요청을 처리하는 동안에만 서버 주도 요청을 허용한다. 상관관계 데이터는 요청 및 응답 주기를 따라 이동하므로 영구적인 프로토콜 세션을 피한다.

이는 특정 동작을 제한한다. 서버는 시작 호출이 끝난 한참 뒤에 예고 없이 클라이언트에 연락할 수 없다. 이 제한은 유연성을 줄이지만, 사용자 프롬프트에 더 명확한 출처와 수명 주기를 부여한다.

도구 검색도 라우팅과 캐싱이 한층 쉬워진다. 이 사양은 HTTP 헤더에 메서드와 도구 메타데이터를 추가한다. 게이트웨이는 모든 요청 본문을 파싱하지 않고도 해당 메타데이터를 검사할 수 있다.

서버는 목록 응답에 time-to-live 값을 첨부할 수 있다. 그러면 클라이언트는 허용된 기간 내에 도구 정보를 재사용할 수 있으므로, 수명이 짧은 하위 에이전트마다 같은 목록을 다시 요청할 필요가 없다.

세션리스 제안서는 이전 동작이 하위 에이전트 수와 서버 수를 곱한 수준의 반복적인 검색 트래픽을 유발할 수 있었다고 경고한다. 상태 비저장 목록은 오케스트레이터가 이러한 비용을 피할 수 있는 더 나은 기반을 제공한다.

이는 에이전트 시스템이 더 분산되면서 중요해진다. 한 건의 사용자 요청이 플래너, 여러 전문 작업자, 검증기를 실행할 수 있다. 모든 분기에서 초기화와 검색을 반복하면 지연 시간과 트래픽이 늘어난다.

개정된 프로토콜은 도구 정의에 완전한 JSON Schema 2020-12도 도입한다. JSON Schema는 필수 필드, 타입, 검증 규칙 등을 포함해 구조화된 데이터를 설명하기 위한 표준 어휘다.

더 풍부한 스키마는 더 정밀한 입력과 출력을 설명할 수 있다. 이는 클라이언트가 호출을 검증하고 인터페이스를 구성하는 데 더 나은 정보를 제공한다. 또한 느슨하게 작성된 도구 설명에 대한 의존도를 낮춘다.

확장은 또 다른 형태의 아키텍처 분리를 제공한다. MCP Apps는 서버 렌더링 인터페이스를 제공할 수 있고, Tasks는 더 긴 작업을 처리한다. 이러한 기능은 모든 역량을 프로토콜 코어에 강제로 넣지 않고도 발전할 수 있다.

공식 수명 주기는 기능 지원 중단과 가장 이른 제거 시점 사이에 최소 12개월을 둔다. 이것이 마이그레이션 작업을 없애지는 않지만, 이번 큰 전환 이후 구현자에게 더 명확한 계획 수립 기간을 제공한다.

공식 TypeScript 가이드는 마이그레이션에 여전히 의도적인 작업이 필요하다는 점을 보여준다. SDK migration guide는 새 와이어 형식을 모든 기존 애플리케이션에 조용히 적용하는 대신 명시적으로 채택해야 한다고 설명한다.

그런 신중함은 적절하다. 새 사양이 공개되었다고 해서 상호운용성이 저절로 생기지는 않는다. 클라이언트, 서버, 게이트웨이, SDK는 같은 세부 사항을 구현하고 실제 워크로드로 검증해야 한다.

그럼에도 이 메커니즘은 구체적인 약점을 해결한다. MCP 고유의 세션 메커니즘을 클라우드 팀이 일반 HTTP 서비스에서 이미 사용하는 패턴으로 대체한다.

명시적 상태는 새로운 보안 및 신뢰성 문제를 만든다

상태 비저장 MCP는 인프라 마찰을 줄이지만, 도구 설계, 권한 부여, 에이전트 메모리에 더 많은 책임을 이전한다.

명시적 핸들은 상태를 가시적이고 이식 가능하게 만든다. 이러한 이점은 민감한 식별자가 노출될 수 있는 위치도 넓힌다. 핸들은 채팅 기록, 프롬프트, 로그, 트레이스, 클립보드 내용, 하위 에이전트 메시지에 들어갈 수 있다.

서버는 식별자를 안다는 사실만으로 충분한 권한 부여로 간주해서는 안 된다. 모든 호출에서 핸들과 인증된 신원을 모두 검증해야 한다.

이는 많은 문서 및 프로젝트 서비스가 사용하는 설계와 유사하다. 리소스 ID는 객체를 식별하고, 현재 권한 부여 컨텍스트는 호출자가 이를 읽거나 변경할 수 있는지를 결정한다.

인증되지 않은 서비스는 더 어려운 문제에 직면한다. 이 환경에서 예측하기 어려운 핸들은 bearer token처럼 작동할 수 있다. 이를 획득한 사람은 핸들이 만료될 때까지 기반 상태에 접근할 수 있다.

세션리스 사양은 이런 경우 높은 엔트로피의 식별자와 제한된 수명을 권장한다. MCP는 와이어 수준의 핸들 타입을 정의하지 않으므로, 이 권고는 구현 지침으로 남는다.

이는 집행 공백을 만든다. 클라이언트는 반환된 문자열 중 어떤 것이 활성 상태를 나타내는지 자동으로 인식할 수 없다. 도구 이름과 설명이 역할을 전달하지 않는 한 browser_id는 다른 값과 똑같이 보인다.

따라서 오케스트레이터는 어떤 식별자가 컨텍스트 압축 이후에도 유지되어야 하는지 항상 알 수 있는 것은 아니다. 어떤 값에 정리가 필요한지, 또는 다른 하위 에이전트에 절대 전달해서는 안 되는지도 판단하기 어려울 수 있다.

모델은 일상적으로 파일 경로, 커밋 해시, URL, 거래 식별자를 다룬다. 그럼에도 핸들을 잘못 복사하거나 누락하거나, 긴 대화가 요약될 때 잃어버릴 수 있다.

세션 상태에도 관련된 약점이 있었다. 클라이언트는 일관되지 않은 수명을 사용했고, 많은 클라이언트가 연결이 끊긴 뒤 세션을 복원하지 못했다. 세션을 제거하면 이러한 문제는 명시적으로 드러나지만, 상태 관리가 자동화되지는 않는다.

정리는 또 하나의 미해결 세부 사항이다. 한때 세션 종료는 리소스를 해제하기 위한 이론적 신호를 제공했다. 실제 클라이언트는 세션을 지나치게 자주 종료하거나, 너무 드물게 종료하거나, 관련 없는 페이지 새로고침 뒤에 종료하곤 했다.

명시적 워크플로에는 자체적인 만료 및 폐기 정책이 필요하다. 브라우저 서비스는 close_browser를 제공하는 동시에 유휴 시간 제한을 적용할 수 있다. 작업 서비스는 완료된 결과를 정해진 기간 동안 보관할 수 있다.

도입 과정에서 하위 호환성은 운영 복잡성을 더한다. 세션 ID에 의존하는 기존 서버는 상태 모델을 바꾸지 않고 새 프로토콜 개정을 그대로 수용할 수 없다.

클라이언트와 SDK는 필요할 때 이전 개정을 협상할 수 있다. 이는 점진적 마이그레이션을 가능하게 하지만, 개발자가 테스트해야 할 두 가지 동작 경로도 만든다.

상태 비저장 HTTP에서는 일부 역량이 덜 직접적이 된다. 비요청 알림과 장기적인 서버 주도 상호작용은 독립적인 요청에 자연스럽게 맞지 않는다. 확장과 리스닝 메커니즘이 이 작업을 맡아야 한다.

세션이 사라진다고 해서 모든 MCP 통합이 효율적으로 변한다는 보장도 없다. 설계가 나쁜 스키마는 컨텍스트를 소모할 수 있다. 큰 도구 카탈로그는 모델을 혼란스럽게 할 수 있다. 불명확한 설명은 여전히 잘못된 호출을 유발할 수 있다.

Skills와 명령줄 도구는 여기서도 장점을 유지한다. 코딩 에이전트는 대규모 원격 도구 카탈로그를 불러오지 않고도 프로그램의 도움말 출력을 검사하고 짧은 스크립트를 작성할 수 있는 경우가 많다.

로컬 도구는 민감한 데이터를 사용자의 머신에 유지할 수도 있다. 원격 MCP 배포는 로컬 실행이 피하는 인증, 네트워크 노출, 로깅, 서비스 가용성 문제를 도입한다.

MCP는 프롬프트 인젝션도 해결하지 않는다. 도구를 사용할 수 있는 에이전트는 전송 방식의 상태 유지 여부와 무관하게 비공개 정보, 신뢰할 수 없는 입력, 외부 통신을 결합할 수 있다.

서버 운영자는 권한과 출력을 제한해야 한다. 에이전트 제작자는 어떤 도구가 함께 나타나는지를 통제해야 한다. 사용자는 중대한 결과를 초래하는 작업에 대해 명확한 승인 경계가 필요하다.

이러한 제약은 Anthropic의 Simon Willison 입장 변화에 대한 가장 강한 해석에 의문을 제기한다. Willison의 renewed interest는 아키텍처 변경을 뒷받침하지만, 모든 MCP 구현이나 제안된 모든 서버를 보증하는 것은 아니다.

mcp-explorer와 datasette-mcp는 실질적인 질문을 드러내기 때문에 유용한 초기 실험이다. 클라이언트가 도구를 일관되게 발견할 수 있는가? 스키마는 이해하기 쉬운가? 인증과 상태 핸들은 실제 워크플로를 견뎌내는가?

상태 비저장 MCP의 가장 강력한 근거는 상호운용성 증거에서 나올 것이다. 독립적인 클라이언트는 맞춤형 패치 없이 독립적인 서버에 연결할 수 있어야 하며, 운영자는 일반적인 인프라를 사용해 이를 배포할 수 있어야 한다.

그 증거가 축적되기 전까지 MCP 2.0은 완성된 승리라기보다 더 나은 토대에 머문다. 프로토콜은 큰 마찰 요인 하나를 제거했다. 그 결과물인 시스템이 안전하고 이해하기 쉬운 상태를 유지할지는 여전히 구현자가 결정한다.

개발자가 MCP 2.0 이후 주목해야 할 점

다음 시험대는 또 다른 저장소 수 급증이 아니라 SDK, 실제 서버, 클라이언트 전반의 도입이다.

첫 번째 신호는 2026-07-28 개정판의 구현 범위다. 공식 SDK는 검색, 요청별 메타데이터, 명시적 역량, Tasks, 권한 부여 동작을 일관되게 지원해야 한다.

버전 라벨만으로는 충분하지 않다. 개발자는 적합성 결과와 언어 간 테스트를 지켜봐야 한다. Python 서버, TypeScript 클라이언트, 관리형 게이트웨이는 동일한 요청과 오류에 대해 일치해야 한다.

강력한 SDK 간 호환성은 MCP가 이제 안정적인 원격 도구 경계를 제공한다는 주장을 강화할 것이다. 지속적인 불일치는 개발자를 다시 클라이언트별 어댑터로 되돌려 보내며 그 주장을 약화시킬 것이다.

두 번째 신호는 프로덕션 서버가 상태 유지 워크플로를 어떻게 마이그레이션하는가다. 브라우저 자동화, 거래, 장바구니, 장기 연구 작업은 명시적 핸들에 까다로운 시험을 제공한다.

성공적인 마이그레이션은 신뢰할 수 있는 정리, 요청별 권한 부여, 핸들 전달, 컨텍스트 압축을 보여줘야 한다. 또한 에이전트가 식별자를 잃거나 반복할 때 어떤 일이 일어나는지도 문서화해야 한다.

이러한 패턴이 재사용 가능해진다면, 명시적 상태는 모호한 세션보다 더 나은 추상화로 보일 것이다. 모든 서버가 호환되지 않는 수명 주기 규칙을 발명한다면, 프로토콜은 복잡성을 줄이는 대신 옮겨 놓았을 뿐이다.

세 번째 신호는 MCP와 Skills의 관계다. 에이전트 플랫폼은 로컬 명령, Skill이 안내하는 API 호출, 원격 MCP 서버를 언제 선택하는지 보여줘야 한다.

명확한 선택 규칙은 더 좁은 논지를 강화할 것이다. MCP는 공유되는 원격 역량을 담당하고, Skills는 지침과 로컬 워크플로를 패키징하게 된다.

계속되는 중복은 유지보수 중복을 만들 수 있다. 도구 소유자는 동일한 역량을 위해 API, CLI, skill 패키지, MCP 서버, 클라이언트별 통합을 모두 유지해야 할 수 있다.

개발자는 이러한 중복을 불가피한 것으로 여겨서는 안 된다. skill은 MCP 서버를 참조할 수 있고, MCP 서버는 기존 API를 감쌀 수 있다. 유용한 질문은 어떤 인터페이스가 지속적인 계약을 소유하는가다.

데이터 도구의 경우 Willison의 실험은 지켜볼 구체적인 대상을 제공한다. Datasette는 이미 웹 API를 통해 구조화된 정보를 제공한다. datasette-mcp는 에이전트 중심 계약이 검색과 안전한 쿼리를 개선하는지 시험할 수 있다.

지식 워크플로를 구축하는 팀도 비슷한 선택에 직면한다. 로컬 문서와 노트는 종종 비공개이며 검색 가능한 engineering knowledge base에 적합하다. 공유 비즈니스 시스템은 인증된 원격 도구에 더 적합할 수 있다.

핵심은 공통 프로토콜이 연결을 쉽게 만든다는 이유만으로 하나의 에이전트에 제한 없는 도구 모음을 부여하지 않는 것이다. 표준화는 통합 작업을 줄이지만, 권한 설계를 대체하지는 않는다.

Anthropic의 Simon Willison 입장 변화가 가치 있는 이유는 실제 회의론의 기간을 거친 결과이기 때문이다. MCP는 브랜딩을 통해 다시 주목받은 것이 아니다. 관리자는 비평가들이 배포된 시스템에서 지적할 수 있던 구조적 부담을 제거했다.

프로토콜은 이런 방식으로 발전해야 한다. 실패한 가정에서 얻은 증거를 흡수하고, 책임 범위를 좁히며, 일반적인 작업을 더 쉽게 추론할 수 있게 해야 한다.

향후 3개월 동안 실제로 사용하는 클라이언트와 서버를 살펴보라. 최종 개정을 지원하는지, 애플리케이션 상태를 어떻게 표현하는지, 권한 부여가 각 핸들을 따라가는지 확인하라.

그런 다음 가장 단순한 대안과 비교하라. 로컬 명령이 더 명확하다면 유지하라. 많은 에이전트가 하나의 관리되는 원격 역량을 필요로 한다면, 상태 비저장 MCP를 시험하고 상호운용성이 여전히 실패하는 지점을 기록하라.