Claude Plugins Directory가 열리며 확장 기능이 Anthropic의 배포 계층으로 전환

Anthropic은 2026년 9월 25일 Claude plugins directory를 서드파티 제출에 개방하며, 개발자에게 자사 확장 기능 마켓플레이스에 진입할 수 있는 검토 경로를 제공했다. 이 변화가 중요한 이유는 플러그인이 더 이상 Claude 기능을 둘러싼 선택적 래퍼가 아니기 때문이다. Anthropic은 이제 플러그인을 개발자가 Claude용 외부 기능을 패키징해야 하는 주요 방식으로 설명한다.

플러그인에는 Model Context Protocol 커넥터, 하나 이상의 Agent Skills 또는 둘 다를 포함할 수 있다. MCP는 Claude에 외부 도구와 데이터에 대한 접근 권한을 제공하고, Skill은 재사용 가능한 지침, 스크립트, 보조 리소스를 제공한다. 이를 결합하면 개발자는 접근 권한과 운영 지식을 하나의 설치 가능한 제품으로 배포할 수 있다.

이 패키징 결정으로 Anthropic은 ChatGPT가 사용하는 앱 모델과 직접 경쟁하게 됐다. 이제 두 회사 모두 서드파티 개발자가 MCP를 기반으로 구축하고, 플랫폼 검토를 거쳐 검색 가능한 디렉터리를 통해 사용자에게 도달하기를 원한다. 따라서 중요한 경쟁은 Claude와 개별 통합 하나의 대결이 아니다. Claude의 번들형 플러그인 모델과 기존 대화형 앱 스토어 간의 경쟁이다.

Anthropic의 플러그인 발표는 개발자에게 제출, 검토 추적, 출시 제어, 사용량 분석을 위한 포털을 제공한다. 또한 이전에는 별개의 구성 요소로 제공되던 여러 확장 형식을 통합하기 시작한다.

Claude plugins directory는 정교한 에이전트 워크플로를 더 쉽게 설치하고 발견할 수 있게 만들 수 있다. 동시에 승인 이후에도 변경될 수 있는 소프트웨어의 처리뿐 아니라 Anthropic의 검토 절차, 순위 시스템, 권한 제어에 더 큰 책임을 집중시킨다.

Claude Plugins Directory에 이제 제출 파이프라인이 생겼다

즉각적인 변화는 운영 측면에 있다. 이제 외부 개발자는 플러그인을 제출하고, 검토 과정을 추적하며, 승인 후 게시할 수 있다.

제출 포털은 유료 Claude 플랜의 개발자에게 제공된다. Anthropic은 개발자들이 이미 Claude를 확장해 온 서로 다른 방식을 반영해 두 가지 제출 경로를 제공한다.

첫 번째 경로는 단일 원격 MCP 커넥터를 다룬다. 개발자는 MCP 서버의 주소를 제공하며, 이 서버는 프로토콜을 통해 도구 또는 데이터를 노출한다. 이 경로는 Claude가 주로 레코드를 검색하고, API를 호출하거나, 정의된 작업을 수행해야 하는 서비스에 적합하다.

두 번째 경로는 GitHub 리포지토리에 호스팅된 플러그인 번들을 다룬다. 이 번들은 MCP 서버와 Agent Skills를 결합할 수 있다. Claude Code에서는 언어 서버 통합, 명령어, 훅, 전문 에이전트도 포함할 수 있다.

이 구분은 중요하다. 커넥터는 Claude가 어떤 외부 시스템에 접근할 수 있는지 알려 준다. Skill은 Claude가 특정 작업에 어떻게 접근해야 하는지 알려 준다. 플러그인은 두 요소를 함께 패키징할 수 있으므로 사용자는 별도 구성 요소를 조합해 워크플로를 만들 필요가 없다.

프로덕션 장애 해결을 위한 개발자 도구를 생각해 보자. 해당 커넥터는 알림, 로그, 이슈 레코드를 가져올 수 있다. Skills는 조사 순서, 필요한 증거, 최종 장애 보고서 형식을 정의할 수 있다. 그러면 플러그인은 연결과 절차를 함께 배포한다.

Anthropic은 모든 제출 항목이 자동 검증과 안전성 검사를 받는다고 말한다. 개발자는 검토 상태를 확인하고, 검사 결과를 검토하며, 권장 변경 사항에 응답할 수 있다. 개발자가 게시 날짜에 대한 통제권을 유지하므로, 승인되었다고 해서 즉시 출시해야 하는 것은 아니다.

이 최종 통제권은 검토와 출시를 분리한다. 팀은 승인된 플러그인을 공개하기 전에 백엔드, 지원 자료 또는 발표가 준비될 때까지 기다릴 수 있다. 기존 제품 배포와 디렉터리 출시 시점을 조율할 수도 있다.

게시 후 포털은 Claude 표면과 플러그인 버전별 설치 수를 보고한다. 또한 목록 조회 수와 사용자가 플러그인에 도달한 검색어도 보여 준다. 이 지표는 개발자가 발견 문제와 활성화 문제를 구분하는 데 도움이 될 것이다.

조회는 많지만 설치가 적은 목록은 포지셔닝이 약하거나, 권한이 불명확하거나, 인지된 가치가 제한적일 수 있다. Claude Code에서는 도입률이 높지만 다른 곳에서는 사용이 적은 플러그인은 일반 Claude 사용자를 위한 다른 Skills나 문서가 필요할 수 있다.

디렉터리 자체는 여전히 Skills, 커넥터, 플러그인을 알아볼 수 있는 범주로 제시한다. 기존 항목은 즉각적인 변경이 필요하지 않다. Anthropic은 개발자가 궁극적으로 커넥터 목록을 플러그인으로 전환할 수 있게 될 것이며, 전환 기간 동안 현재 디렉터리 항목은 그대로 유지될 수 있다고 말한다.

이는 급격한 마이그레이션 기한 없는 통합이다. Anthropic은 기존 통합과 그 기반의 설치 사용자층을 유지하면서도 플러그인을 선호 형식으로 만들 수 있다.

이 전략은 2,000개가 넘는 플러그인과 커넥터를 나열하는 더 광범위한 Claude Marketplace와 함께 등장한다. 제출 포털은 해당 카탈로그를 큐레이션된 목적지에서 보다 구조화된 개발자 채널로 바꾼다.

Anthropic이 지금 도구와 지침을 번들링하는 이유

플러그인은 MCP 커넥터나 프롬프트 패키지만으로는 각각 해결하기 어려운 배포 문제를 해결한다.

MCP는 AI 애플리케이션과 외부 서비스 간의 교환을 표준화했다. 서버는 MCP 호환 클라이언트가 이해할 수 있는 형태로 도구, 리소스 및 관련 기능을 알릴 수 있다. 이는 개발자가 AI 제품마다 서로 다른 통합 프로토콜을 설계해야 할 필요를 줄인다.

이 프로토콜은 대규모 운영도 더 쉬워졌다. 2026년 7월 MCP 사양은 상태 비저장 코어, 캐시 가능한 목록, 헤더 기반 라우팅, 인증 변경 사항, 공식 확장 프레임워크를 도입했다. 상태 비저장 코어는 요청이 지속적인 전송 세션에 의존하지 않고 일반 서버 인스턴스에 도달할 수 있게 한다.

이러한 변화는 MCP를 호스팅형 상용 통합을 위한 더 강력한 기반으로 만든다. 하지만 조직이 작업을 수행하기를 원하는 방식을 Claude에 알려 주지는 않는다. 사용 가능한 도구 목록은 운영 절차와 다르다.

Agent Skills는 두 번째 계층을 담당한다. Anthropic은 Skill을 Claude가 관련 상황에서 로드하는 지침, 스크립트, 리소스가 담긴 폴더로 정의한다. Agent Skills 모델은 개발자가 모든 대화에 모든 지침을 넣지 않고도 전문화된 워크플로를 인코딩할 수 있게 한다.

이로써 자연스러운 역할 분담이 만들어진다. MCP는 접근과 작업을 담당한다. Skills는 절차와 작업별 맥락을 담당한다. 플러그인은 설치와 배포를 위해 이러한 계층을 패키징한다.

이 시점은 에이전트 제품이 단순한 질의응답을 넘어서는 방식도 반영한다. 어시스턴트가 비공개 레코드를 가져오고, 코드를 실행하고, 파일을 생성하거나, 외부 시스템을 변경할 수 있게 되면 성공적인 사용은 모델 품질 이상의 요소에 달려 있다. 주변 워크플로가 모델이 볼 수 있는 것, 수행할 수 있는 것, 그리고 얼마나 일관되게 작동하는지를 결정한다.

개발자들은 이전에 이 요소들을 별도의 채널을 통해 배포해야 했다. 한 리포지토리에는 MCP 서버가, 다른 리포지토리에는 프롬프트, 스크립트 또는 Claude Code 명령어가 있을 수 있었다. 설치 지침은 종종 사용자가 구성 파일을 편집하고 구성 요소가 어떻게 함께 작동하는지 이해하도록 요구했다.

플러그인은 이러한 조각들을 알아볼 수 있는 제품 단위로 바꾼다. 이는 개발자에게 하나의 목록, 하나의 버전 관리 패키지, 하나의 도입 퍼널을 제공한다. 사용자에게는 특정 작업을 위해 설계된 패키지를 설치할지 여부라는 더 단순한 결정을 제공한다.

엔터프라이즈 구매자에게 번들링은 거버넌스도 더 명확하게 만든다. 관리자는 이름이 지정된 패키지를 평가하고, 소스와 기능을 검토하며, 이를 제공받아야 할 사용자를 결정할 수 있다. Anthropic의 조직 제어 기능은 플러그인을 사용 가능하게 하거나, 기본으로 설치하거나, 지정된 사용자에게 요구할 수 있다.

이 패키지는 Claude의 여러 표면으로도 이동할 수 있다. Anthropic의 디렉터리 안내에 따르면 같은 계정을 사용할 경우 설치된 Skills는 Claude chat, Cowork, Claude Code에서 사용 가능해질 수 있다. 이러한 도달 범위는 플러그인을 하나의 인터페이스에 묶인 좁은 통합보다 더 유용하게 만든다.

이러한 표면 간 약속에는 여전히 조건이 따른다. 로컬 훅이나 개발 명령어 중심으로 설계된 플러그인은 브라우저 대화에서 같은 경험을 제공하지 못한다. 개발자는 각 표면에서 어떤 기능이 작동하는지 식별하고 적절한 대체 수단을 설계해야 한다.

그럼에도 Anthropic은 발견, 검토, 분석, 조직 배포가 작동하는 단위로 플러그인을 정립하고 있다. MCP와 Skills는 기반 구성 요소로 남지만, 디렉터리는 번들에 상업적·운영적 가시성을 부여한다.

Claude Plugins와 커넥터의 대결은 잘못된 구도다

핵심 경쟁은 Claude plugins와 커넥터 간의 경쟁이 아니다. Anthropic은 커넥터가 플러그인 내부의 구성 요소가 되기를 원하기 때문이다.

접근 권한 자체가 제품의 전부일 때는 커넥터가 여전히 유용하다. 데이터베이스 검색 서비스, 문서 검색 엔드포인트, 또는 좁게 정의된 API에는 추가 지침이 필요하지 않을 수 있다. 따라서 Anthropic은 새 포털을 통해 단일 원격 MCP 서버도 계속 수용한다.

통합에 순서, 정책 또는 전문화된 결과물이 필요할 때 플러그인은 더 큰 가치를 갖는다. 개발자는 도구를, 언제 이를 사용하고 그 결과를 완성된 작업으로 전환하는 방식을 설명하는 Skills와 결합할 수 있다.

이는 Claude plugins와 커넥터의 구분이 주로 패키징의 깊이에 관한 것임을 뜻한다. 커넥터는 기능을 노출한다. 플러그인은 하나 이상의 기능을 자체 지침과 보조 자산을 갖춘 워크플로로 바꿀 수 있다.

더 중요한 비교 대상은 ChatGPT의 앱 배포 모델이다. OpenAI는 2025년 12월부터 서드파티 앱 제출을 받기 시작했고, 승인된 제품을 검색 가능한 디렉터리에 배치했다. 제출 절차에서는 개발자에게 MCP 연결 세부 정보, 테스트 지침, 디렉터리 메타데이터, 시장 제공 가능 여부도 요구한다.

OpenAI의 앱 제출 모델은 맥락을 가져오고, 작업을 수행하며, 대화형 인터페이스를 렌더링할 수 있는 대화 경험을 강조한다. 앱은 이름으로 호출하거나, 도구 메뉴에서 선택하거나, 추천을 통해 표시될 수 있다.

Anthropic은 다른 출발점에서 같은 기회에 접근하고 있다. Anthropic의 번들은 원격 도구와 절차적 지식을 결합할 수 있으며, Claude Code 플러그인은 명령어, 훅, 에이전트, 개발 인프라까지 더 확장할 수 있다.

그럼에도 두 모델은 명칭이 시사하는 것보다 더 많은 기술적 기반을 공유한다. 두 회사 모두 MCP를 중요한 연결 계층으로 취급한다. 두 회사 모두 공개 제출물을 검토한다. 두 회사 모두 배포가 부분적으로 검색, 순위, 플랫폼 추천에 좌우되는 디렉터리를 제공한다.

이러한 공통 기반은 일부 개발 비용을 낮춘다. 기업은 MCP를 통해 핵심 기능을 노출한 뒤, 그 위에 플랫폼별 패키징을 구축할 수 있다. 하지만 각 호스트는 서로 다른 인터페이스, 정책, 검토 기준, 지원 확장 기능을 갖기 때문에 적응 작업이 사라지는 것은 아니다.

전략적 질문은 어떤 플랫폼이 개발자에게 작동하는 통합을 반복 사용으로 전환하는 최선의 경로를 제공하는가이다. 순수한 사용자 규모도 중요하지만, 발견 품질, 분석, 표면 간 가용성, 엔터프라이즈 배포, 필요한 플랫폼별 작업량도 마찬가지로 중요하다.

Anthropic의 포털은 이러한 요인 가운데 여러 가지를 직접적으로 다룹니다. 검색어 분석은 사용자가 문제를 어떻게 표현하는지 개발자에게 보여줄 수 있습니다. 버전별 설치 데이터는 업데이트가 도입률을 개선했는지 파악하게 해줍니다. 리뷰 피드백은 출시 전에 컴플라이언스 문제를 드러낼 수 있습니다.

하지만 분석만으로 수요를 만들 수는 없습니다. 수천 개의 항목을 보유한 디렉터리는 탐색하기 어려워질 수 있으며, 특히 여러 플러그인이 동일한 워크플로를 해결한다고 주장할 때 그렇습니다. 이때 검색 순위와 편집 추천은 공식 결제 시스템이 없더라도 제품 경제의 일부가 됩니다.

개발자는 플랫폼별 Skill에 어느 정도의 가치를 둘지도 결정해야 합니다. 상세한 Claude 지침은 Anthropic 제품 내 경험을 개선할 수 있지만, 다른 호스트가 워크플로 가이드를 다르게 해석할 경우 유지보수 부담을 키울 수 있습니다.

사용자에게 가장 좋은 모델은 중요한 선택을 숨기지 않으면서 설정 부담을 줄이는 모델일 것입니다. 원클릭 패키지는 사용자가 권한, 데이터 흐름, 유지보수 상태, 지원 환경을 이해할 수 있을 때에만 유용합니다.

지식 근로자는 디렉터리 브랜딩보다 일상 업무를 통해 이러한 경쟁을 체감할 수 있습니다. 리서치 플러그인은 소스 자료를 수집하고, 검증 절차를 적용한 뒤, 구조화된 브리프를 생성할 수 있습니다. 이러한 AI 워크플로는 도구와 운영 지침이 함께 제공될 때 더 큰 가치를 발휘합니다.

Anthropic은 이 묶음이 에이전트 소프트웨어의 올바른 단위라고 보고 있습니다. OpenAI는 앱 중심 경험이 대화에 자연스럽게 녹아들 수 있다고 보고 있습니다. 두 접근법 모두 배포와 신뢰를 GitHub 리포지토리와 수동 설정에만 맡기지 않고 플랫폼 기능으로 전환합니다.

Claude Plugins의 작동 방식이 더 어려운 신뢰 문제를 만드는 이유

검토된 디렉터리는 불확실성을 줄이지만, 모든 플러그인을 영구적으로 안전하게 만들 수는 없습니다.

Anthropic의 자동 검증과 안전성 검사는 유용한 첫 번째 방어선입니다. 디렉터리 정책은 개인정보 보호, 적절한 데이터 수집, 사용 규칙 준수, 다른 등록 서버와의 호환성도 요구합니다. 항목이 게시된 후에도 검토는 계속될 수 있습니다.

하지만 플러그인은 정적인 문서가 아닙니다. 실시간 서비스에 Claude를 연결하거나, 실행 가능한 구성 요소를 포함하거나, 이후 업데이트되는 코드에 의존할 수 있습니다. 따라서 제출 시점에 관찰된 안전 특성은 바뀔 수 있습니다.

원격 MCP 서버는 특히 어려운 과제를 제시합니다. 운영자는 사용자에게 재설치를 요구하지 않고도 서버 동작을 변경할 수 있습니다. 검토 중 무해했던 도구 응답이 미래에도 무해하리라는 보장은 없습니다.

Anthropic은 자체 에이전트 격리 분석에서 이러한 차이를 인정했습니다. 로컬 도구는 검사하고 알려진 버전에 고정할 수 있습니다. 원격 도구는 사용자의 최초 신뢰 결정 이후에도 변경될 수 있으므로, Anthropic은 검토된 디렉터리 밖의 리소스를 신뢰할 수 없는 것으로 취급할 것을 권고합니다.

디렉터리 등록은 초기 및 지속적 검토를 통해 상황을 개선합니다. 하지만 원격 서비스를 변경 불가능한 소프트웨어로 바꾸지는 않습니다. Anthropic의 약관은 보안 우려, 신고, 정책 위반 또는 기타 이유로 MCP 서버를 제거할 권리를 보유합니다.

두 번째 위험은 프롬프트 인젝션입니다. 이는 신뢰할 수 없는 콘텐츠에 에이전트를 다른 방향으로 유도하려는 지침이 포함될 때 발생합니다. 웹페이지, 메시지, 티켓 또는 문서를 가져오는 플러그인은 적대적인 텍스트를 Claude의 작업 컨텍스트로 들여올 수 있습니다.

기존의 의존성 검사는 이 문제를 완전히 해결하지 못합니다. 서버가 진품의 서명된 코드를 실행하더라도 에이전트를 조작하도록 설계된 콘텐츠를 반환할 수 있습니다. 유해한 지침은 실행 파일 자체가 아니라 문서를 통해 들어올 수 있습니다.

Skill을 커넥터와 묶으면 또 다른 검토 영역이 추가됩니다. 지침은 Claude가 언제 도구를 사용해야 하는지, 어떤 근거를 신뢰해야 하는지, 충돌에 어떻게 대응해야 하는지를 결정합니다. 부실하게 설계된 가이드는 명백히 악성인 코드를 포함하지 않아도 안전하지 않은 행동을 유발할 수 있습니다.

Claude Code 플러그인은 훨씬 더 광범위한 결과를 초래할 수 있습니다. 훅, 명령어, 에이전트, 로컬 MCP 서버는 소스 파일, 셸 명령어, 자격 증명 또는 배포 시스템과 상호작용할 수 있습니다. 실제 위험은 권한과 플러그인이 실행되는 환경에 따라 달라집니다.

따라서 기업에는 승인 배지 이상의 것이 필요합니다. 관리자는 요청된 기능, 인증 경로, 데이터 보존 정책, 업데이트 동작, 로컬 및 원격 구성 요소의 차이를 검토해야 합니다. 또한 프로덕션 시스템 접근 권한을 부여하기 전에 민감하지 않은 데이터로 새 플러그인을 테스트해야 합니다.

개발자도 관련된 공개 문제에 직면합니다. 명확한 등록 정보는 어떤 정보가 Claude 밖으로 나가는지, 플러그인이 어떤 작업을 수행할 수 있는지, 원격 서비스가 설치된 패키지와 별개로 변경될 수 있는지를 설명해야 합니다. 권한이나 의존성이 바뀔 때는 버전 노트가 중요합니다.

포털의 버전 분석은 정기 업데이트를 장려할 수 있지만, 빈번한 릴리스는 검토 부담을 만듭니다. Anthropic은 재검토의 모든 기준, 모든 순위 신호, 변경된 원격 서비스를 얼마나 빨리 재평가할 수 있는지에 대해 공개적으로 세부 사항을 밝히지 않았습니다.

플러그인을 기본적인 서드파티 형식으로 삼기로 한 Anthropic의 결정에는 거버넌스 측면의 긴장도 존재합니다. 통합 패키지는 배포를 단순화하지만, 플랫폼이 노출도와 지속적 접근에 더 큰 영향력을 갖게 합니다. 개발자는 변화할 수 있는 정책을 준수해야 하며, Anthropic은 디렉터리 배치와 제거를 통제합니다.

이러한 구조는 소프트웨어 마켓플레이스에서 흔합니다. 에이전트 플러그인은 외부 데이터, 절차적 지침, 중요한 행동을 하나의 패키지 안에 결합할 수 있기 때문에 위험 수준을 높입니다. 검토는 소프트웨어가 실행되는지뿐 아니라 불확실한 입력 아래에서 모델을 어떻게 유도하는지도 평가해야 합니다.

사용자는 승인을 영구 보증이 아니라 위험을 줄이는 조치로 해석해야 합니다. 가장 강력한 신호는 Anthropic이 자동 검사를 지속적인 모니터링, 투명한 공개, 신속한 사고 대응, 각 플러그인의 권한을 제한적으로 유지하는 통제 수단과 결합할 수 있는지 여부가 될 것입니다.

디렉터리가 개발자와 엔터프라이즈 구매자에게 가하는 압력

Anthropic의 결정은 플러그인 개발자에게 발견 가능성, 거버넌스, 유지보수를 제품 요구사항으로 다루도록 요구합니다.

독립 개발자에게 포털은 리포지토리를 수동으로 설치하지 않을 사용자에게 도달할 수 있는 신뢰할 만한 경로를 만듭니다. 이러한 배포는 적은 설정으로 완결된 작업을 해결하는, 범위가 명확한 플러그인에 보상할 수 있습니다.

동시에 진입 기준도 높아집니다. 이제 공개 플러그인에는 작동하는 코드만으로는 부족합니다. 일관된 등록 정보, 명확한 권한 경계, 안정적인 호스팅, 검토 가능한 리포지토리, 버전 관리 규율, 실제 환경의 사용을 견딜 만큼의 지원이 필요합니다.

포털의 검색 분석은 이름과 포지셔닝을 측정 가능하게 만들 것입니다. 개발자는 어떤 검색어가 등록 페이지 방문을 생성하는지 확인한 뒤 설명을 조정하거나 빠진 기능의 우선순위를 정할 수 있습니다. 제품 표면별 설치 데이터는 플랫폼별 개발 방향을 안내할 수 있습니다.

이러한 신호는 더 나은 제품을 만들 수 있지만, 디렉터리 성과를 최적화할 시간이 있는 팀에 유리하게 작용할 수도 있습니다. 소규모 개발자는 이미 잘 알려진 브랜드, 성숙한 인증 시스템, 전담 컴플라이언스 인력을 보유한 기존 소프트웨어 벤더와 경쟁하게 될 수 있습니다.

엔터프라이즈 구매자는 다른 결정을 내려야 합니다. 공개 디렉터리 플러그인을 사용하거나, 내부 패키지를 배포하거나, 두 접근법을 결합할 수 있습니다. 공개 등록은 소싱 노력을 줄이는 반면, 내부 플러그인은 회사별 절차를 담고 비공개 시스템에 연결할 수 있습니다.

Anthropic의 조직 제어 기능은 관리자가 게시와 설치를 관리할 수 있게 합니다. 기업은 플러그인을 선택 사항으로 두거나, 기본 설치하거나, 필수로 지정할 수 있습니다. 이는 특히 Skill에 승인된 운영 지침이 포함된 경우 워크플로 표준화에 도움이 됩니다.

필수 배포는 신중히 다뤄야 합니다. Anthropic은 일부 Claude Code 구성 요소가 사용자의 컴퓨터에서 실행된다고 설명합니다. 로컬 훅이나 도구 접근 권한이 있는 필수 플러그인은 직원이 독립적으로 비활성화할 수 없는 방식으로 개발 환경에 영향을 줄 수 있습니다.

보안팀은 출처, 버전, 기능, 대상 사용자, 최근 사용 현황을 포괄하는 인벤토리를 원할 것입니다. 또한 공개 디렉터리에서 제거된 플러그인, 동작이 바뀌는 서버, 유지관리자가 더 이상 업데이트를 내놓지 않는 패키지에 대응하는 절차도 필요합니다.

소프트웨어 벤더는 이제 Claude가 자체 패키지형 워크플로를 가질 가치가 있는지 결정해야 합니다. 기본 MCP 엔드포인트는 여러 호환 클라이언트에 도달할 수 있지만, Claude 전용 Skill은 작업 품질과 디렉터리 내 위치를 개선할 수 있습니다. 그 대가는 유지해야 할 또 하나의 제품 표면입니다.

가장 성공적인 개발자는 핵심 서비스를 이식 가능하게 유지하면서 각 호스트에 맞춰 경험을 조정할 가능성이 높습니다. MCP는 도구에 대한 공통 접근을 제공할 수 있습니다. 플랫폼별 지침, 인터페이스, 거버넌스 메타데이터는 이 공통 계층 위에 놓일 수 있습니다.

이 접근법은 이식성을 동일성으로 취급하지 않게 합니다. 하나의 서버가 Claude와 ChatGPT에 동일한 기반 기능을 제공하더라도, 각 플랫폼은 발견, 추천, 권한, 사용자 상호작용을 서로 다르게 처리할 수 있습니다.

Anthropic은 이 추가 작업이 가치 있음을 입증해야 합니다. 디렉터리는 수동적 조회 수가 아니라 적합한 설치를 제공해야 합니다. 검토 기간은 예측 가능하게 유지되어야 합니다. 분석은 의사결정을 이끌 만큼 정확해야 합니다. 제품 표면 간 동작은 이해 가능해야 합니다.

또한 회사는 낮은 품질의 제출물이 발견 경험을 압도하지 않도록 막아야 합니다. 자동 검증은 형식 문제와 알려진 보안 이슈를 포착할 수 있지만, 거의 동일한 열 개의 플러그인이 각각 뚜렷한 가치를 제공하는지는 판단할 수 없습니다.

제출이 늘어날수록 큐레이션은 더 어려워질 것입니다. 검색이 기존 업체에 유리하면 신규 개발자는 주목을 얻기 어려울 수 있습니다. 추천이 새로움에 치우치면 사용자는 불안정한 제품을 접할 수 있습니다. Anthropic은 디렉터리를 초기 등록 항목 중심으로 고착시키지 않으면서 품질에 보상하는 균형을 찾아야 합니다.

구매자에게 중요한 지표는 이용 가능한 플러그인의 수가 아닙니다. 설치 후에도 안정적이고 투명하며 유용하게 유지되는 플러그인의 수입니다. 대규모 카탈로그는 선택지를 만들지만, 실제 사용과 유지율은 패키징이 실질적인 업무를 개선했는지 보여줍니다.

Claude Plugins Directory의 다음 단계

플러그인이 단순한 통합 카탈로그가 아니라 Claude의 실질적인 확장 계층이 될지를 결정할 세 가지 신호가 있습니다.

첫 번째 신호는 기존 커넥터가 더 풍부한 플러그인 묶음으로 전환되는 정도입니다. Anthropic은 개발자가 궁극적으로 커넥터 등록 정보를 플러그인으로 전환할 수 있게 될 것이라고 말합니다. 지속적인 전환 물결은 개발자가 MCP 접근에 Skill과 워크플로 자산을 연결하는 데 가치를 느낀다는 것을 보여줄 것입니다.

이러한 전환의 품질은 단순한 수보다 중요합니다. 기존 커넥터를 새 매니페스트로 감싸기만 한다면 추가되는 가치는 거의 없습니다. 플러그인은 설정 부담을 줄이거나, 유용한 절차를 내장하거나, 커넥터만으로는 제공할 수 없는 일관된 결과를 만들어야 합니다.

기존 커넥터 제공업체가 이러한 더 풍부한 패키지에 투자한다면 Anthropic의 번들링 전략은 뒷받침을 얻습니다. 대부분의 등록 정보가 커넥터 전용으로 남는다면, 플러그인은 주로 새로운 디렉터리 라벨로 기능할 수 있습니다.

두 번째 신호는 하나의 발견 경험이 Claude와 Claude Code를 실제로 아우르는지 여부입니다. Anthropic은 향후 몇 주에 걸쳐 두 제품 전반에 통합된 경험을 출시할 것이라고 말합니다. 사용자는 설치 전에 플러그인이 어디에서 작동하는지 이해할 수 있어야 합니다.

설득력 있는 출시는 제품 표면 전반에 걸쳐 일관된 정체성, 버전 정보, 권한, 상태를 제공할 것입니다. 또한 표면별 기능도 명확히 보여줘야 합니다. 개발자 중심 훅이 브라우저 호환 Skill과 동등한 것처럼 표시되어서는 안 됩니다.

크로스 서피스 유지율은 특히 많은 것을 보여줄 것이다. 사용자가 한 Claude 제품을 통해 패키지를 설치한 뒤 다른 곳에서도 계속 사용한다면, 플러그인은 독립형 커넥터가 쉽게 제공하기 어려운 가치를 구현한 셈이다.

세 번째 신호는 Anthropic이 처음으로 눈에 띄는 보안 또는 품질 사고를 어떻게 처리하는가다. 대규모 서드파티 생태계에서는 결국 취약한 패키지, 침해된 서버, 오해를 부르는 메타데이터, 또는 검토된 버전과 다르게 작동하는 업데이트가 발생하게 마련이다.

그 대응은 지속적인 모니터링, 개발자 커뮤니케이션, 사용자 알림, 제거 절차를 시험하게 될 것이다. 신속한 차단 조치는 디렉터리의 신뢰 모델을 강화할 수 있다. 반대로 대응이 느리거나 불투명하다면 승인 절차의 가치는 약화될 것이다.

경쟁사의 반응도 주목할 만하지만, 핵심 검증 항목이라기보다 보조 증거에 가깝다. OpenAI는 이미 MCP 기반 디렉터리와 제출 절차를 갖추고 있다. 두 회사 모두 퍼블리싱 도구, 인터페이스, 분석 기능, 엔터프라이즈 제어 기능을 계속 추가할 것이다.

Anthropic의 차별화된 제안은 플러그인 번들 자체다. 서드파티가 접근 권한, 전문성, 워크플로 동작을 하나의 설치 가능한 단위로 패키징해 여러 Claude 제품에서 작동하도록 하려는 것이다.

이는 에이전트에 도구와 지침이 모두 필요하다는 점에서 설득력 있는 방향이다. 그러나 자동으로 지속 가능한 우위가 되는 것은 아니다. 개방형 표준은 핵심 연결을 이식 가능하게 만드는 반면, 검토 품질과 제품 배포는 각 플랫폼의 통제 아래 남는다.

개발자는 범위가 명확한 하나의 작업부터 시작해 필요한 최소한의 도구만 노출하고, 의미 있는 모든 권한을 문서화해야 한다. 가져온 콘텐츠에 오해를 부르는 지침이 포함되어 있거나 원격 의존성이 실패할 때 패키지가 어떻게 동작하는지도 테스트해야 한다.

엔터프라이즈 팀은 플러그인을 장식적인 프롬프트 팩이 아니라 활성 소프트웨어 의존성으로 평가해야 한다. 이는 업데이트 검토, 권한 제한, 사용 모니터링, 제거 계획 유지를 의미한다.

개별 사용자에게 실질적인 질문은 더 간단하다. 설치한 패키지가 더 적은 설정과 더 명확한 제어로 실제 워크플로를 안정적으로 완료하는가? 향후 몇 달간 커넥터 전환, 진정한 크로스 제품 사용, 투명한 사고 대응을 지켜봐야 한다. 이러한 결과는 Claude 플러그인 디렉터리가 Anthropic의 지속 가능한 서드파티 플랫폼으로 자리 잡았는지 보여줄 것이다.