Anthropic Simon 테스트가 드러낸 맞춤형 MCP 연결의 마찰

Anthropic 관찰자 Simon Willison은 하나의 맞춤형 MCP 서버를 Claude와 ChatGPT에 연결했지만, 이 실험은 매우 다른 두 가지 설정 경로를 드러냈다. 7월 29일 진행된 그의 테스트는 제품별 제약, 원격 호스팅 요건, 인증 작업에도 불구하고 표준 채팅 인터페이스가 개발자가 만든 도구를 사용할 수 있음을 보여줬다.

anthropic simon 실험이 중요한 이유는 Model Context Protocol이 코딩 에이전트와 데스크톱 구성 파일을 넘어 확장되고 있기 때문이다. AI 애플리케이션을 외부 도구 및 데이터에 연결하는 개방형 프로토콜인 MCP는 일상적인 채팅 창으로 진입하고 있다. 이는 사용층을 넓히는 동시에 제품 수준의 제약을 더 이상 무시하기 어렵게 만든다.

Claude는 이 연결을 맞춤형 커넥터로 제시한다. ChatGPT는 유사한 기능을 앱 시스템과 개발자 제어 기능 뒤에 배치한다. 두 서비스 모두 원격 서버에 연결할 수 있지만, 어느 쪽도 해당 서버를 보편적으로 이식 가능한 플러그인으로 만들지는 않는다. 프로토콜은 통신을 표준화하지만, 각 호스트는 여전히 검색, 권한, 승인, 가용성을 통제한다.

Simon Willison의 MCP 테스트가 실제로 바꾼 것

맞춤형 MCP 서버는 이제 사용자가 일반적인 웹 대화를 벗어나지 않고도 Claude와 ChatGPT 모두에 기능을 제공할 수 있다.

Willison은 2026년 7월 29일 공개한 맞춤형 MCP 테스트에서 이 과정을 문서화했다. 핵심 결과는 단순했다. 개발자는 MCP 서버를 호스팅하고, 이를 두 서비스에 등록한 뒤, 일반 채팅 인터페이스 안에서 도구를 노출할 수 있다.

이 결과는 Claude Code, 데스크톱 구성 파일, 개발자 중심 클라이언트에 초점을 맞췄던 기존 MCP 시연과 이 실험을 구분한다. 이런 환경에서는 이미 도구 연결이 비교적 자연스러웠다. 표준 소비자용 채팅 제품에는 계정 규칙과 인터페이스 제어라는 추가 계층이 적용된다.

서버는 원격에서 접근 가능해야 한다. 표준 입출력 전송 방식을 사용하는 로컬 프로세스는 브라우저 세션 안에 단순히 나타날 수 없다. 호스트는 각 클라이언트가 기대하는 MCP 구성 요소를 구현한 인터넷 접근 가능한 HTTP 엔드포인트를 제공해야 한다.

원격 액세스는 배포 모델을 바꾼다. 개발자는 더 이상 개인 컴퓨터에서 신뢰하는 하나의 프로세스를 실행하도록 한 애플리케이션만 구성하는 것이 아니다. 대신 전송 보안, 신원, 인증, 가용성, 그리고 잠재적으로 여러 사용자를 처리해야 하는 네트워크 서비스를 운영하게 된다.

Claude는 이러한 통합을 맞춤형 커넥터라고 부른다. Anthropic은 원격 MCP 서버를 통해 Claude를 호스팅된 도구 및 데이터 소스와 연결할 수 있다고 설명한다. 현재 커넥터 안내는 자격을 갖춘 개인 및 업무용 계정에서 Claude와 Claude Desktop을 지원한다고 명시한다.

ChatGPT는 동일한 광범위한 기능을 맞춤형 앱과 MCP 커넥터를 통해 설명한다. OpenAI의 인터페이스 역시 앱 생성, 테스트, 승인, 워크스페이스 내 제공을 구분한다.

이 명명 차이는 단순한 외형상의 문제가 아니다. “커넥터”는 기존 서비스로 연결하는 다리를 시사한다. “앱”은 호스트가 통제하는 제품 표면을 통해 패키징, 검토, 배포되는 무언가를 시사한다. MCP는 두 모델 모두를 지원할 수 있지만, 이러한 명칭은 사용자 기대를 형성한다.

서버에는 유용한 도구 정의도 필요하다. 이런 설명은 각 도구가 무엇을 하는지, 언제 호출해야 하는지, 어떤 입력을 받는지를 모델에 알려준다. 기술적으로 유효한 엔드포인트라도 도구가 겹치거나 설명이 모호하면 성능이 떨어질 수 있다.

따라서 Willison의 테스트는 제품 간 동일한 동작이 아니라 프로토콜 계층에서의 상호운용성을 보여줬다. Claude와 ChatGPT는 동일한 기본 기능을 발견할 수 있다. 그러나 여전히 도구를 다르게 선택하고, 서로 다른 승인을 요청하며, 다른 인터페이스로 결과를 제시할 수 있다.

개발자에게 기억할 만한 사실은 두 회사가 어떤 형태로든 MCP를 지원한다는 점이 아니다. 더 중요한 변화는 하나의 호스팅된 구현이 이제 두 주요 채팅 제품 안의 사용자에게 도달할 수 있다는 것이다. 덕분에 완전히 별개의 두 통합 프로토콜을 유지하지 않고도 제품 간 테스트가 실용적인 선택지가 된다.

Anthropic Simon 결과가 두 AI 플랫폼에 압박을 가하는 이유

MCP는 경쟁의 일부를 모델 지능에서 도구, 권한, 배포에 대한 통제로 옮긴다.

anthropic simon 결과는 Anthropic에 압박을 가한다. Anthropic은 MCP를 만들었고 이 프로토콜을 개방형 표준으로 홍보해 왔기 때문이다. Claude는 설득력 있는 레퍼런스 클라이언트로 남아야 한다. 외부 서버가 다른 곳에서 더 예측 가능하게 작동한다면, 프로토콜의 창시자라는 사실만으로 플랫폼 선호를 보장할 수는 없다.

OpenAI는 반대 방향의 압박에 직면한다. MCP의 기원은 아니지만, ChatGPT는 애플리케이션 플랫폼으로서 막대한 역할을 한다. 개발자들은 이미 Claude 및 다른 MCP 클라이언트에서 작동하는 통합이 ChatGPT에서도 지원되기를 기대할 것이다.

이는 프로토콜 이식성과 플랫폼 통제 사이의 분명한 경쟁을 만든다. 개발자는 도구를 한 번 설명하고 호환되는 여러 제품에 연결하기를 원한다. 플랫폼 운영자는 어떤 계정이 서버에 연결할 수 있는지, 어떤 작업이 허용되는지, 위험한 호출은 어떻게 검토되는지를 결정하려 한다.

Claude는 현재 여러 계정 유형에서 직접적인 맞춤형 커넥터 개념을 제공한다. 커넥터가 회사 데이터를 노출하거나 작업을 실행할 수 있으므로 업무용 사용에는 관리자 제어가 도입된다. 소유자는 가용성을 구성할 수 있으며, 개별 사용자는 여전히 자신의 권한으로 인증한다.

ChatGPT는 보다 명시적인 배포 구조를 적용한다. OpenAI의 현재 개발자 모드 안내는 웹에서 Business 및 Enterprise 또는 Edu 고객에게 전체 MCP 지원이 제공된다고 설명한다. 또한 Pro 사용자에게는 더 제한적인 읽기 및 가져오기 액세스를 설명한다.

서버가 쓰기 작업을 노출할 때 이 차이는 중요해진다. 문서 컬렉션을 검색하는 일에는 하나의 위험 프로필이 따른다. 고객 기록을 업데이트하거나, 콘텐츠를 게시하거나, 프로젝트를 삭제하는 일에는 또 다른 위험이 따른다.

OpenAI는 권한, 맥락, 잠재적 영향에 따라 쓰기 및 수정 작업에서 확인을 요청할 수 있다고 설명한다. 특히 위험한 일부 작업은 차단될 수 있다. 워크스페이스 관리자 역시 앱이 비공개 테스트에서 승인된 가용성 단계로 넘어갈 수 있는지를 통제한다.

Anthropic도 마찬가지로 사용자가 도구 요청을 검토하고 대화와 관련된 도구만 활성화할 것을 권고한다. 이 경고는 에이전트형 인터페이스의 기본적 한계를 반영한다. 자연어 요청이 모델이 필요하다고 판단할 수 있는 모든 외부 작업을 항상 드러내지는 않는다.

이러한 제어 기능은 가장 단순한 이식성 약속을 약화시킨다. 개발자는 서버, 스키마, 인증 기반을 재사용할 수 있다. 그러나 일치하는 액세스, 사용자 흐름, 확인 동작, 모델 결정을 기대할 수는 없다.

이러한 분절이 반드시 프로토콜 실패를 뜻하는 것은 아니다. MCP는 클라이언트와 서버 사이의 공통 언어를 정의한다. 모든 호스트가 동일한 제품 정책을 채택하도록 요구하지는 않는다.

그럼에도 실제 환경에서는 제품상의 마찰이 프로토콜 호환성의 중요성을 좌우할 수 있다. 관리자 설정 뒤에 숨겨진 연결은 개인 설정 화면에서 사용할 수 있는 연결보다 더 적은 사용자에게 도달한다. 읽기 전용 구현은 신중하게 승인된 쓰기를 허용하는 경쟁자를 대체할 수 없다.

도구 호출 품질도 또 다른 압박 요인이다. 모델은 올바른 도구를 선택하고, 유효한 인수를 생성하고, 오류를 해석하고, 결과를 전달해야 한다. MCP 전송을 지원한다고 해서 사용자의 작업을 안정적으로 완료할 수 있는 것은 아니다.

따라서 개발자는 두 플랫폼에서 동일한 프롬프트를 테스트해야 한다. 서버가 동일한 도구를 노출하더라도 서로 다른 호출 패턴을 만들 수 있다. 이런 차이는 설명이 모호한지, 혹은 한 호스트가 더 엄격한 제어를 적용하는지를 드러낼 수 있다.

더 넓은 경쟁의 질문은 더 이상 Claude나 ChatGPT가 API를 호출할 수 있는지가 아니다. 두 플랫폼 모두 가능하다. 핵심은 어느 쪽이 일반 사용자에게 외부 기능을 이해하기 쉽고, 관리 가능하며, 신뢰할 수 있게 만드는가이다.

하나의 프로토콜이 여전히 두 가지 설정 경험을 만드는 이유

MCP는 중복 통합 코드를 줄이지만, 안전한 연결을 둘러싼 운영 단계를 없애지는 않는다.

Claude에서는 기본 경로가 Settings와 Connectors를 거친다. 사용자는 맞춤형 커넥터를 추가하고, 원격 서버 주소를 입력하며, 서버가 요구할 경우 인증을 완료한다. 업무용 소유자는 먼저 커넥터를 활성화하거나 구성해야 할 수 있다.

Anthropic의 서버 문서는 개발자를 프로토콜의 인증 사양과 공식 SDK 예제로 안내한다. 또한 최신 원격 인증 패턴을 지원한다고 언급한다.

ChatGPT에서는 Apps와 고급 설정을 통해 진행한다. 사용자 또는 관리자는 개발자 액세스를 활성화하고, 앱을 생성하며, 원격 MCP URL을 입력하고, 인증 방식을 선택한 뒤, 맞춤형 서버와 관련된 경고를 수락한다.

Business 워크스페이스 관리자는 워크스페이스용 앱을 생성하고 배포할 수 있다. Enterprise 및 Edu 환경에서는 개발자와 사용자에 대한 역할 기반 제어가 추가된다. 이러한 규칙은 연결을 단순한 개인 설정이 아니라 조직 거버넌스의 일부로 만든다.

공통된 기술적 중심은 원격 MCP 엔드포인트다. 현대적인 원격 서버는 일반적으로 HTTP 요청과 스트리밍 응답을 통해 MCP 메시지를 전달하는 전송 방식인 Streamable HTTP를 사용한다. 이 엔드포인트는 호환 클라이언트가 기대하는 초기화 및 도구 검색 교환을 지원해야 한다.

MCP 메시지는 요청, 결과, 알림, 오류를 위한 구조화된 형식인 JSON-RPC 2.0을 사용한다. 프로토콜은 클라이언트가 도구를 발견하고 호출하는 방법을 정의한다. 각 도구의 기반이 되는 비즈니스 로직은 정의하지 않는다.

비공개 리서치 서버를 생각해 보자. 이 서버는 저장된 문서를 검색하는 도구 하나와 전체 레코드를 가져오는 또 다른 도구를 제공할 수 있다. Claude와 ChatGPT는 동일한 엔드포인트에서 이러한 정의를 발견할 수 있다.

그럼에도 개발자는 누가 어떤 레코드를 검색할 수 있는지 결정해야 한다. 이 결정은 서버와 그 인증 계층에 속한다. 한 클라이언트 인터페이스에서 도구를 숨기는 것은 데이터 소스에서 액세스를 강제하는 일을 대체하지 못한다.

서버가 사용자별 데이터를 처리할 때 OAuth는 핵심이 된다. 클라이언트는 사용자를 인증 흐름으로 보내고, 액세스 토큰을 받은 뒤, 보호된 MCP 서버를 호출할 때 해당 토큰을 제시한다. 그러면 서버는 데이터를 반환하기 전에 토큰을 검증한다.

MCP 인증 사양은 호환되는 HTTP 인증 배포를 위해 보호 리소스 메타데이터를 요구한다. 이 메타데이터는 클라이언트에 인증 서비스의 위치를 알려준다. 모든 클라이언트-서버 조합을 하드코딩하지 않고도 검색을 지원한다.

이 지점에서 간단한 검증은 실제 엔지니어링 프로젝트가 된다. 서버에는 안정적인 HTTPS 주소, 올바른 메타데이터, 리디렉션 처리, 토큰 검증, 적절한 범위가 필요하다. 또한 인증 실패 시 클라이언트가 해석할 수 있는 오류 메시지도 필요하다.

클라이언트 등록은 또 다른 호환성 문제가 될 수 있다. 일부 시스템은 동적 등록 또는 클라이언트 메타데이터 문서를 지원한다. 다른 시스템은 사전에 생성된 클라이언트 식별자를 기대한다. 한 가지 가정을 중심으로 설계된 서버는 두 채팅 제품에서 인증이 원활히 작동하기 전에 조정이 필요할 수 있다.

실용적인 구현은 범위가 좁은 읽기 전용 도구에서 시작해야 합니다. 예를 들어, 팀은 승인된 프로젝트 노트를 하나의 검색 기능을 통해 노출할 수 있습니다. 사용자는 업데이트나 삭제 권한을 부여하지 않고도 어느 어시스턴트에게든 이전 결정을 찾아 달라고 요청할 수 있습니다.

이 활용 사례는 개인 또는 팀 지식 베이스로 이어지는 자연스러운 연결고리도 만듭니다. MCP는 액세스 계층을 제공할 수 있으며, 기본 시스템은 인덱싱, 권한, 보존, 소스 품질을 계속 담당합니다.

읽기 경로가 작동한 뒤에는 개발자가 더 정밀한 작업을 추가할 수 있습니다. 각 쓰기 도구는 목적이 분명하고 범위가 제한되어야 합니다. “하나의 작업 상태 업데이트”는 “임의의 프로젝트 작업 실행”보다 검토하기 쉽습니다.

도구 설명은 API 계약만큼 신중하게 작성할 가치가 있습니다. 모델은 함수를 호출할지 결정할 때 이러한 설명을 봅니다. 모호한 이름은 잘못된 선택, 반복 호출 또는 불필요한 데이터 액세스 가능성을 높입니다.

입력 스키마 역시 모호성을 거부해야 합니다. 계정을 변경하는 도구는 안정적인 계정 식별자를 요구해야 합니다. 여러 레코드와 일치할 수 있는 고객 이름에만 의존해서는 안 됩니다.

응답은 모델이 무슨 일이 일어났는지 설명할 수 있도록 충분한 구조화 정보를 반환해야 합니다. 쓰기 도구는 변경된 객체, 이전 상태, 새 상태를 포함할 수 있습니다. 이는 호스트가 의미 있는 확인 메시지를 제시하는 데 도움이 됩니다.

테스트는 성공적인 호출만 다뤄서는 안 됩니다. 개발자는 만료된 토큰, 취소된 권한, 사용할 수 없는 종속성, 잘못된 입력, 다른 사용자의 레코드에 액세스하려는 시도를 테스트해야 합니다. 두 호스트는 이러한 실패를 서로 다르게 표시할 수 있습니다.

이 때문에 개방형 프로토콜임에도 커스텀 서버를 추가하는 일이 오래 걸릴 수 있습니다. MCP는 통합 중복의 한 범주를 제거합니다. 하지만 배포, 신원 관리, 보안 검토, 제품 구성 또는 품질 보증까지 없애지는 않습니다.

진짜 트레이드오프는 이식성과 신뢰 사이에 있다

하나의 서버가 여러 어시스턴트에 연결될 수 있게 하는 바로 그 개방성은, 해당 서버에 사용자·모델·민감한 시스템 사이에서 특권적 위치를 부여하기도 합니다.

커스텀 MCP 서버는 도구를 통해 전송된 입력을 볼 수 있습니다. 또한 모델이 컨텍스트로 취급하는 콘텐츠를 반환할 수 있습니다. 작업을 노출한다면 사용자의 신원으로 외부 데이터를 변경할 수도 있습니다.

이 조합은 여러 신뢰 경계를 만듭니다. 사용자는 채팅 제공업체, MCP 서버 운영자, 연결된 서비스, 인증 구현을 신뢰해야 합니다. 조직은 모델 행동을 안내하는 설명도 신뢰해야 합니다.

프롬프트 인젝션은 주요 우려 사항입니다. 악의적인 지침은 문서, 지원 티켓 또는 웹 페이지처럼 도구가 가져오는 데이터 안에 삽입될 수 있습니다. 모델은 해당 콘텐츠를 신뢰할 수 없는 자료가 아니라 지시로 해석할 수 있습니다.

여러 도구를 사용할 수 있을 때 위험은 커집니다. 검색된 콘텐츠가 모델을 설득해 민감한 인수와 함께 다른 도구를 호출하게 만들 수 있습니다. 따라서 읽기 작업이 의도하지 않은 쓰기 시퀀스의 시작 단계가 될 수 있습니다.

Anthropic과 OpenAI 모두 사용자에게 신뢰할 수 있는 서버만 연결하라고 경고합니다. 이 조언은 필요하지만, 신뢰가 완전한 보안 통제 수단은 아닙니다. 선의의 서버라도 인증 오류나 지나치게 광범위한 작업을 포함할 수 있습니다.

서버는 모든 요청을 독립적으로 검증해야 합니다. Claude나 ChatGPT가 생성한 호출이라는 이유만으로 안전하다고 가정해서는 안 됩니다. 호스트 확인은 사용자에게 도움이 될 수 있지만, 서버 측 액세스 검사를 대체하지는 않습니다.

토큰 처리는 특히 신중해야 합니다. MCP 사양은 서버가 한 서비스용 토큰을 다른 서비스로 전달하는 토큰 패스스루를 금지합니다. 토큰에는 정의된 대상이 있어야 하며, 수신 서버는 그 대상을 검증해야 합니다.

최소 권한 원칙은 가장 명확한 출발점을 제공합니다. 리서치 커넥터는 쓰기 액세스를 요청하기 전에 읽기 액세스를 요청해야 합니다. 캘린더 도구는 단순히 가능 시간을 나열하는 데만 필요하다면 삭제 권한을 요청해서는 안 됩니다.

쓰기 작업도 좁은 의미 체계의 이점을 얻습니다. delete_everything이라는 도구는 명백히 위험하지만, 광범위한 관리 기능도 더 친숙한 이름 뒤에 비슷한 노출을 숨길 수 있습니다. 각 작업은 검토 가능한 사용자 의도에 대응해야 합니다.

영향이 큰 작업은 멱등성을 지원해야 하며, 이는 실수로 반복되어도 여러 변경이 발생하는 것을 방지합니다. 모델은 응답이 불분명한 뒤 재시도할 수 있습니다. 보호 장치가 없다면 하나의 요청 작업이 중복 레코드나 메시지를 만들 수 있습니다.

감사 로그도 똑같이 중요합니다. 운영자는 어떤 사용자가 호출을 승인했는지, 어떤 도구가 실행됐는지, 어떤 객체가 변경됐는지, 호스트가 확인을 보고했는지를 알아야 합니다. 로그는 불필요한 프롬프트 콘텐츠나 비밀 정보를 보관하지 않도록 해야 합니다.

서버 운영자는 사용자 대면 데이터와 제어 지침을 분리해야 합니다. 도구 결과는 신뢰할 수 없는 텍스트를 명확히 표시하고, 가능하면 구조화된 필드를 반환할 수 있습니다. 모델은 여전히 조작에 취약하지만, 신중한 출력 설계는 모호성을 줄입니다.

호스트 플랫폼도 미해결 과제에 직면해 있습니다. 승인 프롬프트는 사용자가 작업을 이해할 수 있을 만큼 충분한 정보를 제공해야 합니다. 도구가 여러 작업을 수행할 수 있을 때 “도구 액세스 허용”이라는 일반적인 요청은 보호 효과가 거의 없습니다.

도구 행동은 연결 후에도 바뀔 수 있습니다. Anthropic은 서버 개발자가 경고 없이 도구를 변경할 수 있다고 명시적으로 언급합니다. 무해한 검색 커넥터를 승인한 사용자는 나중에 같은 엔드포인트에서 더 광범위한 기능을 마주할 수 있습니다.

버전 관리와 검토는 이 위험을 줄일 수 있습니다. 조직은 배포를 고정하고, 스키마 변경을 모니터링하며, 도구가 쓰기 액세스를 얻을 때 추가 검토를 요구할 수 있습니다. 공개 서버 운영자는 변경 로그를 게시하고 범위를 안정적으로 유지할 수 있습니다.

데이터 이동과 관련된 개인정보 보호 문제도 있습니다. 한 회사는 어시스턴트가 내부 레코드를 검색하는 것은 허용하면서도, 그 레코드가 다른 처리자에게 전달되는 것은 금지할 수 있습니다. MCP 서버의 호스팅 위치와 보존 정책은 결정의 일부가 됩니다.

따라서 안전한 배포에는 유효한 연결 이상의 것이 필요합니다. 팀은 데이터 범주, 허용 작업, 인증 범위, 보존 규칙, 사고 대응 담당자, 권한 철회 절차를 문서화해야 합니다. 또한 각 호스트가 도구 사용을 어떻게 보고하는지 테스트해야 합니다.

anthropic simon 데모는 크로스 플랫폼 연결이 가능함을 보여 줍니다. 모든 접근 가능한 서버가 프로덕션에 적합하다는 사실까지 증명하지는 않습니다. 호환성은 평가의 시작이지 끝이 아닙니다.

이 구분은 선호하는 어시스턴트가 비공개 노트나 프로젝트 이력에 접근하기를 바라는 지식 근로자에게 중요합니다. 커넥터는 도구 간 복사를 줄일 수 있습니다. 동시에 민감한 컨텍스트가 이동하는 경로를 넓힐 수도 있습니다.

이 트레이드오프를 평가하는 팀은 통제된 액세스 아래 공개해도 되는 정보부터 시작해야 합니다. 승인된 엔지니어링 문서의 검색 가능한 모음은 모든 내부 시스템으로 연결되는 무제한 게이트웨이보다 안전합니다.

그런 다음 어시스턴트가 올바른 소스를 찾는지, 권한을 준수하는지, 도구 사용을 명확히 설명하는지를 측정할 수 있습니다. 확장은 MCP 엔드포인트가 있다는 사실만이 아니라 증거를 따라야 합니다.

Anthropic Simon 실험이 다음으로 주목해야 할 점

MCP의 다음 시험대는 크로스 플랫폼 서버가 고급 설정을 통해 조립하는 전문가용 통합이 아니라 일상적인 제품이 되는지 여부입니다.

첫 번째 신호는 원격 인증을 둘러싼 수렴입니다. Claude와 ChatGPT는 각 조합마다 별도의 커스텀 등록 작업 없이도 사용자를 안전하게 연결해야 합니다. 하나의 표준 준수 OAuth 배포가 두 환경에서 안정적으로 작동한다면 더 폭넓은 채택이 강화될 것입니다.

인증이 계속 클라이언트별 예외로 가득하다면 이식성 주장은 약해집니다. 개발자는 여전히 서버의 일부를 재사용하겠지만, 별도의 설정 지침, 메타데이터, 문제 해결 경로를 유지해야 합니다.

가장 강력한 증거는 일반 서비스가 여러 어시스턴트를 위한 검증된 지침과 함께 하나의 원격 엔드포인트를 게시할 때 나올 것입니다. 이 서비스들은 사용자가 장기 유효 API 키를 채팅 설정에 붙여넣도록 요구해서는 안 됩니다. 브라우저 기반 동의는 좁고 철회 가능한 범위를 부여해야 합니다.

두 번째 신호는 OpenAI가 완전한 MCP 액세스를 어떻게 확대하는지입니다. 현재 문서는 관리형 업무 계정의 완전한 지원과 더 제한적인 Pro 기능을 구분합니다. 더 폭넓은 개인용 경로는 Claude의 커스텀 커넥터 경험에 직접적인 압력을 가할 것입니다.

관리자 배포를 계속 강조한다면 이는 다른 전략을 가리킵니다. ChatGPT 앱은 주로 거버넌스가 적용된 업무용 소프트웨어로 기능하고, Claude는 개인 실험을 위한 더 직접적인 경로를 유지할 수 있습니다.

어느 쪽이 자동으로 더 나은 것은 아닙니다. 기업에는 흔히 승인, 감사 가능성, 역할 통제가 필요합니다. 독립 개발자는 배포된 서버에서 작동하는 대화까지 가는 짧은 경로를 중요하게 여깁니다.

세 번째 신호는 두 플랫폼이 쓰기 작업을 어떻게 처리하는지입니다. 검색과 검색 결과 제공은 유용한 데모를 만들지만, 작업은 MCP가 진정한 애플리케이션 계층이 되는지를 결정합니다. 동시에 가장 어려운 보안 및 인터페이스 문제를 만듭니다.

더 명확한 권한 요약, 작업 미리보기, 확인 정책, 감사 기록을 주시해야 합니다. 외부 영향을 잘 설명하는 호스트는 쓰기 도구가 위험이 없다고 가장하지 않으면서도 더 유용하게 만들 수 있습니다.

개발자는 호스트가 더 나은 진단 정보를 제공하는지도 살펴봐야 합니다. 연결 실패는 여러 가능한 원인을 하나의 오류로 축소하는 경우가 많습니다. 문제는 전송 계층 협상, 인증 메타데이터, 리디렉션 구성, 토큰 대상 또는 도구 스키마 검증과 관련될 수 있습니다.

더 나은 진단 정보는 작동하는 로컬 서버에서 신뢰할 수 있는 원격 통합으로 가는 경로를 단축할 것입니다. 또한 서버 운영자가 서로 다른 호스트의 기대치를 역공학해야 하는 부담도 줄일 것입니다.

레지스트리와 검색 시스템은 또 다른 중요한 계층입니다. 개방형 프로토콜은 어떤 서버가 신뢰할 수 있는지 사용자에게 알려주지 않습니다. 큐레이션된 디렉터리가 도움이 될 수 있지만, 플랫폼 소유자에게 또 다른 통제 지점을 제공하기도 합니다.

한 호스트에 등록된 서버가 다른 호스트에서는 수동 커스텀 연결로만 남을 수 있습니다. 이 경우 개발자는 구현이 이식 가능하더라도 배포 문제에 직면합니다. 검토 일정과 등록 규칙은 경쟁 차별화 요소가 될 수 있습니다.

따라서 사용자는 서버 호환성과 서버 가용성을 구분해야 합니다. 서비스는 기술적으로 Claude와 ChatGPT에서 작동할 수 있지만, 찾기 어렵거나 워크스페이스 정책에 의해 제한될 수 있습니다.

같은 구분은 인터페이스 지원에도 적용됩니다. MCP Apps는 호환되는 호스트에서 대화형 인터페이스를 반환할 수 있는 반면, 기본 도구 서버는 주로 구조화된 데이터와 텍스트를 교환합니다. 동일한 기본 프로토콜을 사용하더라도 지원 수준 차이로 한 통합이 더 풍부하게 느껴질 수 있습니다.

빌더를 위한 즉각적인 전략은 보수적입니다. 표준 준수 원격 서버를 호스팅하고, 범위가 좁은 읽기 도구 하나로 시작하며, 두 제품에서 동일한 프롬프트를 테스트하세요. 인증, 검색, 호출, 오류 처리의 모든 차이를 기록하세요.

다음으로, 명시적 인증 뒤에 제한적인 쓰기 작업을 도입하세요. 재시도가 변경을 중복하지 않는지, 권한 철회가 작동하는지 확인하세요. 작업이 실행되기 전에 각 플랫폼이 정확히 무엇을 보여 주는지도 검토하세요.

조직의 경우, 결정은 MCP에 대한 열정보다 워크플로에서 시작해야 합니다. 채팅 기반 액세스가 실제 전환이나 검색 노력을 줄이는 반복 작업 하나를 식별하세요. 그런 다음 이를 완료하는 데 필요한 최소 데이터 및 작업 범위를 정의하세요.

좋은 후보는 승인된 기술 문서를 검색하고 소스 링크를 반환하는 기능일 수 있습니다. 또 다른 후보는 프로젝트 업데이트를 게시하지 않고 초안으로 작성하는 기능일 수 있습니다. 둘 다 최종 변경을 사람이 통제하는 상태에서 가치를 만듭니다.

anthropic simon 검색 문구는 아마도 Simon Willison의 특정 실험을 찾는 독자를 끌어들일 것이다. 그러나 그 지속적인 가치는 설정 순서보다 더 넓은 데 있다. 이 테스트는 프로토콜 표준화가 끝나는 지점과 플랫폼 정책이 시작되는 지점을 드러낸다.

MCP는 Claude와 ChatGPT의 표준 인터페이스 안으로 중요한 경계를 넘어섰다. 다음 질문은 신뢰할 수 있는 서버 연결이 일반 사용자에게도 지루할 만큼 평범하고, 예측 가능하며, 눈에 보이는 일이 될 수 있느냐는 것이다.

개발자들은 지금 이 질문에 답하는 데 도움을 줄 수 있다. 위험이 낮은 워크플로 하나를 선택하고, 권한을 좁게 제한한 원격 엔드포인트를 구축한 뒤, 동일한 테스트 프롬프트로 두 호스트를 비교해 보라. 그 차이는 MCP가 실질적인 이식성을 제공하고 있는지, 아니면 단지 공통의 기술적 기반에 그치고 있는지를 보여줄 것이다.