Claude 플러그인 게시 실전 가이드: 디렉터리 등록까지

Claude 플러그인 게시 절차: 핵심만 보기

Claude 플러그인은 다음 순서로 게시합니다.

1. 제출에 사용할 Claude 계정이 Pro, Max, Team 또는 Enterprise 요금제인지 확인합니다.
2. 장기적으로 목록을 소유할 조직을 선택합니다.
3. .claude-plugin/plugin.json, README, 라이선스를 포함해 플러그인을 패키징합니다.
4. 폴더를 로컬에서 테스트한 뒤, 연결된 GitHub 계정으로 푸시할 수 있는 GitHub 저장소에 올립니다.
5. 개발자 포털을 열고 Plugin bundle을 선택합니다. 저장소와 선택 사항인 플러그인 경로, 추적할 브랜치 또는 태그를 입력한 다음 Validate를 실행합니다.
6. 데이터 처리, 컴플라이언스, 연락처, 업데이트 설정을 완료하고 Submit for review를 선택합니다.
7. 플러그인이 직접 운영하는 원격 MCP 서버를 가리킨다면, 해당 서버를 별도의 MCP connector로 제출합니다.

Anthropic의 GitHub 접근 및 소스 업로드 조건을 충족하면 검증과 심사 중에는 저장소를 비공개로 유지할 수 있습니다. 다만 플러그인이 공개되기 전에는 저장소도 공개 상태로 전환해야 합니다.

포털을 열기 전에 제출 유형부터 정해야 합니다

플러그인과 커넥터는 서로 연관되어 있지만 같은 것은 아닙니다. 플러그인을 업무 절차가 담긴 상자라고 본다면, 원격 MCP 서버는 그 뒤에서 실제 업무를 처리하는 서비스 데스크에 가깝습니다. 하나는 Claude에게 워크플로를 알려주고, 다른 하나는 Claude가 제품이나 데이터에 실시간으로 접근하게 합니다.

스킬은 세 번째 제출 유형이 아닙니다. 플러그인 번들 안에 넣어야 합니다. 번들이 직접 호스팅하는 MCP 서버를 참조한다면, 같은 Claude 조직에서 두 제품을 모두 제출하고 동일한 서버 URL을 지정합니다. 그래야 포털이 두 목록을 연결할 수 있고, 사용자에게 중복된 툴 세트가 표시되는 일을 막을 수 있습니다.

목록 소유자는 처음부터 명확히 정합니다

어느 조직을 선택할지는 단순한 관리 설정이 아니라 오래가는 제품 결정입니다. 플러그인 번들의 경우 저장소 폴더를 처음 제출한 조직이 해당 목록을 소유합니다. 다른 조직은 같은 저장소와 폴더를 다시 제출할 수 없습니다.

계정 규칙은 간단합니다.

• Pro 또는 Max에서는 본인 계정으로 제출합니다.
• Team 또는 Enterprise에서는 Owner가 제출할 수 있습니다.
• Enterprise의 Owner는 사용자 지정 역할을 통해 Directory 권한을 부여할 수 있습니다.
• 해당 Claude 조직에 연결된 GitHub 계정에는 저장소 푸시 권한이 있어야 합니다.

에이전시가 플러그인을 제작하더라도 공개 정체성을 고객사가 소유해야 한다면 고객사 조직에서 제출해야 합니다. 나중에 저장소를 넘기는 것과 디렉터리 목록을 넘기는 것은 같은 일이 아닙니다.

Claude 플러그인 게시 비용은 얼마일까요?

Anthropic의 공개 안내에는 별도의 디렉터리 등록 수수료가 명시되어 있지 않지만, Free 계정으로는 제출할 수 없습니다. 따라서 포털을 이용하려면 최소한 유료 계정이 필요합니다.

• 유료 계정이 없는 1인 개발자는 월간 결제 기준 한 달 $20인 Pro를 이용하거나, 1년 치 $200를 선결제하고 월 $17 요금을 적용받을 수 있습니다.
• Team은 2명부터 시작합니다. Standard 좌석 2개는 월간 결제 시 한 달 $50, 연간 결제 시 월 $40입니다.
• Max는 월 $100부터 시작하지만, 제출만을 위해 Max가 필요한 것은 아닙니다.

더 큰 비용은 출시 준비 작업에서 발생합니다. 호스팅 제품이라면 번들과 커넥터를 각각 준비해 2건으로 제출해야 합니다. 플러그인에는 안정적인 매니페스트, 최소 40단어의 README, 라이선스, 데이터 처리 답변, 심사 연락처, 공개 전환이 가능한 저장소도 필요합니다. 새 포털은 검증, 스캔 결과, 심사 상태, 공개, 업데이트, 사용량을 한곳에 모아 조율 부담을 줄여 줍니다. 그렇다고 필요한 작업 자체가 사라지는 것은 아닙니다.

디렉터리 등록에 맞는 플러그인 번들 준비하기

신뢰할 만한 최소 번들 구조는 다음과 같습니다.

your-plugin/
  .claude-plugin/plugin.json
  skills/your-workflow/SKILL.md
  README.md
  LICENSE

매니페스트에는 영구적으로 사용할 소문자 name, 사용자에게 보이는 displayName, version, 용도를 분명히 설명하는 description, 작성자, 라이선스 선언 또는 별도 라이선스 파일이 필요합니다. 영구 이름은 신중하게 정해야 합니다. displayName은 바꿀 수 있지만 매니페스트의 이름은 플러그인의 정체성이 됩니다.

README는 단순한 저장소 정리 문서가 아닙니다. 디렉터리는 이를 목록 콘텐츠로 사용하며, 코드가 아닌 단어가 40개 미만이면 검증 단계에서 차단합니다. 플러그인의 기능, 사용법, 전송하는 데이터를 명확히 적습니다. 실제 자격 증명은 어떤 것도 저장소에 넣지 않아야 합니다.

번들이 원격 서버를 참조한다면 HTTPS 엔드포인트를 .mcp.json에 넣습니다. API 키는 넣지 마세요. 플러그인 파일은 모든 설치자에게 전달됩니다.

로컬 테스트 후 포털에서 다시 검증합니다

로컬 검증을 실행하면 GitHub에 올리기 전에 잘못된 플러그인 파일을 찾아낼 수 있습니다.

claude plugin validate ./your-plugin
claude --plugin-dir ./your-plugin

첫 번째 명령은 파일 구문과 스키마를 검사합니다. 두 번째 명령은 작업 폴더가 로드된 Claude Code 세션 하나를 시작해 스킬과 명령을 직접 확인할 수 있게 합니다. 로컬 검증이 포털의 Validate 버튼을 대신하지는 않습니다. 포털은 디렉터리 요구 사항, 저장소 구조, 이름 충돌, 파일 정책 등 제출과 관련된 다른 규칙도 검사합니다.

이 가이드에서는 스킬 1개와 가상 이슈 파일 3개로 구성된 작은 release-note-builder 플러그인을 만들었습니다. 이슈는 새로운 감사 로그 CSV 내보내기, 페이지네이션 개선, 중복 이메일 수정에 관한 것이었습니다. Claude Code 2.1.283은 오류나 경고 없이 Validation passed, 종료 코드 0을 반환했습니다.

그다음 claude --plugin-dir로 폴더를 불러와 테스트 실행을 시도했습니다. 이 컴퓨터에는 인증된 Claude 세션이 없었으므로 모델 호출 전에 Not logged in · Please run /login 메시지와 함께 요청이 중단됐습니다. 생성된 릴리스 노트는 확인되지 않았습니다. 이 경계는 중요합니다. 폴더 검증은 로컬에서 실행할 수 있지만, 동작 검증에는 인증된 모델 접근이 필요합니다. 더 충실한 동작 테스트 절차는 별도 Claude Code 플러그인 평가 가이드를 참고하세요.

플러그인 제출 양식 작성하기

공개 문서에 나온 포털 절차는 실무적으로 6단계로 나뉩니다.

1. 소스

GitHub 저장소를 URL 또는 owner/repo 형식으로 입력합니다. 플러그인이 저장소 루트 아래에 있다면 플러그인 경로도 추가합니다. 향후 버전을 추적할 브랜치나 태그를 선택하거나, 기본 브랜치를 따르려면 비워 둡니다. 그런 다음 Validate를 선택합니다.

검증은 하나의 커밋을 읽습니다. 수정 사항을 푸시했다면 보고서가 새 커밋을 읽도록 Re-validate를 선택합니다.

2. 목록 세부 정보

포털은 plugin.json과 README를 바탕으로 목록을 만듭니다. 이름, 설명 또는 안내가 잘못되었다면 저장소 파일을 수정한 뒤 다시 검증합니다. 공개 약속과 실제 배포 패키지를 같은 릴리스 안에 유지하게 만드는 유용한 원칙입니다.

3. 데이터 처리

플러그인이 개인 데이터를 읽거나 저장하는지, 명시된 커넥터 이외의 곳으로 데이터를 보내는지, 데이터를 보관하는지, 18세 미만을 대상으로 하는지 답합니다. 이 답변은 형식적인 양식 입력이 아니라 제품 계약의 일부로 다뤄야 합니다.

4. 컴플라이언스와 연락처

Anthropic이 심사 과정에서 연락할 이메일을 입력한 뒤 필수 확인 사항 4개를 완료합니다. 포털에서 검토 결과나 수정 요청과 함께 버전을 돌려보낼 수 있으므로, 실제로 모니터링하는 받은편지함을 사용해야 합니다.

5. 업데이트

기본 GitHub 푸시 웹훅 또는 예약 검사만 사용하는 방식 중 하나를 선택합니다. 두 방식 모두 디렉터리가 추적 중인 브랜치나 태그를 확인하게 합니다. 웹훅을 설정하려면 저장소 관리자 권한이 필요합니다.

6. 검토 및 제출

세부 정보를 확인하고 Submit for review를 선택합니다. 한 조직은 24시간 동안 최대 10건을 제출할 수 있으며, 초안과 철회한 제출도 여기에 포함됩니다. 기존 초안을 이어서 작업하려는 경우 중복 제출을 만들지 마세요.

원격 MCP 서버는 별도로 제출합니다

플러그인이 직접 운영하는 원격 MCP 서버를 호출한다면 Submit new로 돌아가 MCP connector를 선택합니다. 커넥터 경로에서는 폴더가 아닌 실제 서비스를 등록하므로 더 많은 운영 정보를 요구합니다.

서버 URL, 문서 및 개인정보처리방침 URL, 아이콘, 심사용 테스트 자격 증명, MCP App 캐러셀 이미지를 준비합니다. 문서에 설명된 절차에는 연결, 동기화된 툴, 공개 목록, 사용 사례, 회사, 인증, 데이터 처리, 테스트 안내, 컴플라이언스, 최종 검토가 포함됩니다.

공개 목록 필드에는 최대 100자인 서버 이름, 최대 200자인 한 줄 설명, 최대 2,000자인 상세 설명, 1~5개 카테고리, 문서, 개인정보처리방침, 지원 정보, 아이콘, 영구 URL 슬러그가 포함됩니다. 제품에 계정이 필요하다면 심사 담당자에게 데이터가 채워진 테스트 계정도 제공해야 합니다. 상태 엔드포인트가 응답한다는 이유만으로 커넥터가 준비됐다고 판단해서는 안 됩니다. 먼저 MCP Inspector 또는 Claude의 사용자 지정 커넥터로 모든 툴을 실행해 보세요.

심사 상태를 다음 행동 목록으로 읽는 법

심사 기간은 보장되지 않습니다. “심사에 얼마나 걸릴까?”보다 “다음에는 누가 움직여야 할까?”가 더 유용한 질문입니다.

Approved라고 해서 설치할 수 있는 것은 아닙니다. Published 상태여야 합니다. 기본 설정에서는 심사를 통과한 버전도 Anthropic 심사 담당자가 공개해야 할 수 있습니다. 이후 일부 플러그인은 심사를 통과한 업데이트가 자동으로 공개되도록 설정할 수 있지만, 보류된 버전은 여전히 기다려야 합니다.

첫 출시 전에 업데이트 방식까지 설계합니다

공개 후에는 추적 중인 브랜치에 병합하거나 추적 중인 태그를 이동합니다. 디렉터리는 새 커밋을 읽어 검증하고 보안 스캔을 수행한 뒤 다른 버전으로 표시합니다. 릴리스할 때마다 plugin.json의 version을 올려야 합니다.

업데이트가 실패하거나 보류되더라도 정상 작동 중인 목록이 내려가지는 않습니다. 대체 버전이 공개될 때까지 디렉터리는 마지막으로 공개된 버전을 계속 제공합니다. 따라서 브랜치는 단순한 소스 저장소가 아니라 릴리스 피드 역할을 합니다.

Usage 탭은 피드백 순환 구조를 완성합니다. 선택한 기간에 대해 설치 수, 활성 계정, 유지율, 버전 점유율, 구성요소 사용량, 로드 오류, MCP 호출과 지연 시간, 목록 조회 수, 설치 클릭 수, 실제 설치 수를 최대 90일까지 보여줄 수 있습니다. 수치는 UTC 기준 하루에 한 번 업데이트되며 CSV로 내보낼 수 있습니다. 포털에 기록되기 전에는 설치 수를 약속하지 마세요.

이 포털의 효과가 가장 큰 6개 팀

1. 원격 MCP 제품을 운영하는 SaaS 팀

제품 팀은 실제 서버를 커넥터로 제출하고, 서버를 활용하는 워크플로 스킬을 플러그인으로 패키징합니다. 고객은 툴 접근 권한뿐 아니라 툴을 제대로 활용하는 방법까지 얻게 됩니다. 팀은 커넥터에서 서버 상태와 툴 사용량을, 플러그인에서 설치 및 구성요소 사용량을 확인할 수 있습니다.

2. 워크플로 소프트웨어 기업

비용 처리, 채용, 고객 지원, 영업 플랫폼은 가장 효과적인 운영 절차를 스킬로 만들고 제품 커넥터와 연결할 수 있습니다. 사용자는 설명 없는 API 메서드 묶음이 아니라 하나의 워크플로를 추가하게 되므로 도입 품질이 높아집니다.

3. 오픈소스 플러그인 유지관리자

유지관리자는 코드를 공개로 유지하고 릴리스 브랜치를 추적하면서 포털을 안정적인 목록 및 업데이트 채널로 활용할 수 있습니다. 새 커밋을 수정하는 동안에도 마지막으로 검증을 통과한 버전이 계속 제공되므로, 저장소에 푸시할 때마다 즉시 사용자 배포 수준을 맞춰야 한다는 부담이 줄어듭니다.

4. 고객용 플러그인을 납품하는 에이전시

에이전시가 폴더를 만들고 테스트할 수 있지만, 목록을 고객이 소유해야 한다면 고객 조직에서 제출해야 합니다. 저장소 제어권, 디렉터리 소유권, 지원 연락처, 분석 데이터가 외주사보다 구매사에 귀속되어 인계가 한층 깔끔해집니다.

5. Enterprise 플랫폼 팀

Enterprise Owner는 광범위한 Owner 역할을 공유하지 않고도 선택한 구성원에게 Directory 권한을 부여할 수 있습니다. 목록을 회사 조직에 유지하면서 릴리스 업무와 일반 조직 관리를 분리할 수 있습니다.

6. 터미널 밖으로 확장하려는 Claude Code 툴 개발자

명령어나 스킬을 더 넓은 디렉터리에 배포할 수 있지만, 먼저 각 환경의 지원 범위를 확인해야 합니다. 스킬은 Chat, Cowork, Claude Code 모두에서 작동합니다. 에이전트와 훅은 Chat에서 실행되지 않고, 로컬 MCP 서버도 Chat에서 실행되지 않으며, LSP 서버는 Claude Code에서만 사용할 수 있습니다. 패키지가 제공하지 못하는 동일한 경험을 모든 환경에서 약속하는 실수를 피할 수 있습니다.

포털을 기반으로 만들 만한 제품 3가지

1. 가장 유망한 Plugin Release Gate

릴리스 브랜치가 포털에 도달하기 전에 플러그인을 검사하는 GitHub 체크를 만듭니다. 로컬 검증을 실행하고, README와 라이선스를 확인하며, 지원되지 않는 구성요소 조합을 표시하고, 매니페스트 버전을 비교한 뒤 디렉터리 준비 상태 보고서를 생성하는 제품입니다.

수요는 이미 확인됩니다. claude code plugins의 미국 월간 검색량은 약 5,400회이고, 상업적 검색 의도와 $6.22의 CPC를 보입니다. 판매 가능한 최소 버전은 GitHub App, 웹 보고서, 저장소 배지로 구성할 수 있습니다. 다만 Anthropic의 디렉터리 검사와 사람의 심사는 로컬 명령의 범위를 넘어가므로 포털 승인을 보장한다고 약속해서는 안 됩니다. 이 제품의 가치는 승인 보장이 아니라 예방 가능한 실패를 줄이는 데 있습니다.

2. Directory Listing Optimizer

포털의 CSV 내보내기를 가져와 조회 수, 설치 클릭 수, 설치 수, 유입 경로, 버전, 구성요소 사용량을 릴리스 및 목록 개선 권장 사항으로 바꿔 주는 보고 계층을 만듭니다. 일일 데이터가 의미 있을 만큼 트래픽이 있는 플러그인 게시자가 구매자입니다.

claude plugins의 미국 월간 검색량은 약 8,100회이고, 상업적 검색 의도와 $9.05의 CPC를 보입니다. MVP에는 CSV 업로드, 퍼널 계산, 버전 비교, 주간 실행 목록이 필요합니다. 문제는 콜드 스타트입니다. 공개 후 실제 사용 데이터가 쌓이기 전까지는 분석할 독점 데이터가 없습니다. 문서화된 분석 API가 아니라 내보내기 파일에 의존한다는 한계도 있습니다.

3. Cross-Surface Plugin Auditor

하나의 플러그인 폴더에서 Chat, Cowork, Claude Code가 각각 무엇을 로드할지 정확히 알려 주는 정적 스캐너를 만듭니다. 최상위 bin/ 디렉터리, 로컬 MCP 전제, 채팅에서 무시되는 에이전트와 훅, Claude Code 전용 LSP를 표시하고 테스트 매트릭스를 생성해야 합니다.

claude-plugins marketplace의 미국 월간 검색량은 약 1,900회이고 난이도는 16이며 상업적 검색 의도를 보입니다. MVP는 Anthropic의 지원 표를 바탕으로 한 저장소 스캐너입니다. 문제는 유지관리입니다. 플랫폼 지원 범위는 바뀔 것이고, 터미널 전용 개발자라면 더 넓은 호환성에 관심이 없을 수 있습니다.

가장 좋은 선택은 릴리스 게이트입니다. 첫 등록 때만이 아니라 모든 버전에 관여하기 때문입니다. 포털을 대체하려 하지 않고 보완한다는 점도 강점입니다.

이 포털만으로 해결되지 않는 것

포털이 약한 플러그인을 유용하게 만들어 주지는 않습니다. 검증으로 파일 형식과 정책 호환성은 확인할 수 있지만, 스킬이 실제 결과를 개선하는지는 입증할 수 없습니다. 모든 Claude 앱에서 구성요소가 똑같이 작동하도록 보장하지도 않습니다. 정해진 심사 기간, 요청만으로 받는 Verified 라벨, 출시 당일의 설치 사용자를 제공하지도 않습니다.

또한 호스팅 MCP 제품을 하나의 목록으로 합쳐 주지 않습니다. 서버 인증, 상태, 툴, 정책에는 별도의 운영 기록이 필요하므로 커넥터를 따로 제출하도록 설계된 것입니다.

통합 탐색 환경은 9월 25일 출시 후 몇 주에 걸쳐 계속 배포되고 있습니다. 현재 문서화된 환경을 기준으로 게시하고, 더 넓은 탐색 기능은 지금 약속할 수 있는 도달 범위가 아니라 앞으로 추가될 유통 채널로 보세요.

월요일에 바로 할 일

목록을 소유해야 할 Claude 조직부터 고릅니다. 실제 워크플로 하나를 플러그인 번들로 만들고, 안정적인 매니페스트 이름과 유용한 README, 라이선스를 갖춘 뒤 로컬 검증을 실행합니다. 호스팅 MCP 서버를 호출한다면 커넥터 제출도 함께 준비합니다. 소유 조직과 저장소 경로를 확정하기 전에는 포털을 열지 마세요.

플러그인과 프로덕션 커넥터를 하나의 안정적인 릴리스 시스템으로 구축하려면 AI 프로덕션 시스템을 확인하세요.