MCP 서버를 만들어두고 “이제 사람들이 어떻게 찾아서 쓰게 하지?”에서 멈췄다면 살펴볼 소식이다. Anthropic은 9월 25일 Claude 플러그인을 제출하고 심사 진행 상황과 출시 후 사용 지표를 확인할 수 있는 개발자 포털을 발표했다. 공식 발표
연결 기능을 만드는 것과 사용자에게 배포하는 것은 서로 다른 일이다. 이번 변화는 두 번째 문제에 가깝다. 다만 MCP 서버, Skill, 플러그인이라는 이름이 함께 등장해 무엇을 제출해야 하는지부터 헷갈리기 쉽다.
MCP 서버가 있는데 플러그인도 다시 만들어야 하나?
먼저 역할을 나누면 이해가 쉽다.
| 구성요소 | 하는 일 | 이슈 관리 서비스를 예로 들면 |
|---|---|---|
| MCP 커넥터 | 서비스의 데이터·기능에 접근 | 이슈를 검색하고 상태를 조회 |
| Skill | 작업 순서와 좋은 결과의 기준을 설명 | 중복 이슈를 묶고 담당자별로 요약하는 절차 |
| 플러그인 | 필요한 구성요소를 설치·배포 단위로 묶음 | 연결 기능과 요약 절차를 함께 제공 |
| MCP App | 대화 안에 상호작용 UI를 제공 | 사용자가 후보 이슈를 선택하는 화면 |
표의 서비스 사례는 이해를 위한 가정이다. 공식 문서에서도 플러그인은 필요한 구성요소를 조합하는 패키지로 설명하며, 모든 요소를 다 넣어야 완성되는 것은 아니라고 안내한다. UI도 선택 사항이다. 개발 개요
따라서 단순 조회 도구를 공개하려는데 거대한 플러그인부터 만들 필요는 없다. 반대로 사용자가 매번 긴 지시문을 붙여야 원하는 결과가 나온다면, 연결 기능만으로 부족했던 작업 지식을 Skill로 정리할 이유가 있다.
기존에 디렉터리에 등록된 Skill·커넥터·플러그인이 있다면 이번 발표 때문에 즉시 바꿀 필요는 없다는 것이 Anthropic의 안내다. 새 포털이 열렸다는 사실과 기존 연동이 중단된다는 주장은 구분해야 한다. 기존 등록 항목 안내
제출은 어디로, 무엇을 보내나?
시작점은 Claude 개발자 포털이다. 공식 문서가 구분하는 제출 대상은 플러그인 번들과 MCP 커넥터다.
플러그인 번들은 GitHub 저장소를 통해 제출하며, 목록이 공개되기 전 저장소가 공개 상태여야 한다. MCP 커넥터는 원격 서버 URL을 사용한다. 자신이 운영하는 원격 MCP 서버를 번들에서 참조한다면, 서버도 별도 커넥터로 제출하라는 안내가 있다. 번들에 URL을 적었다고 서버 등록까지 끝나는 것은 아니다. 디렉터리 제출 문서
저장소 공개를 준비한다면 코드보다 먼저 확인할 것이 있다. 테스트용 키, 내부 URL, 고객 데이터가 샘플 파일에 남아 있지 않은지 살펴보자. 이것은 포털 제출을 직접 수행한 경험담이 아니라 공개 배포 전 권장하는 기본 점검이다.
등록 계정과 소유 조직도 나중으로 미루지 않는 편이 좋다. 개인이 시험 삼아 제출한 항목을 회사가 장기간 운영해야 하는 상황이라면 소유권과 업데이트 책임부터 정해야 한다.
공식 문서상 제출 가능한 플랜은 Pro·Max·Team·Enterprise다. Team과 Enterprise에서는 역할 조건도 확인해야 한다. 별도 파트너 프로그램 가입이 먼저 필요한 것은 아니다. 또한 Claude Marketplace를 보고 찾아왔더라도 별도의 Marketplace 제출 경로가 있는 것이 아니라 디렉터리에 제출한다. 플랜·권한·제출 경로
연결 성공보다 먼저 정해야 할 사용 장면
서비스에 API가 열 개 있다고 해서 열 개 모두를 첫 버전에 담을 필요는 없다. 사용자가 실제로 요청할 문장 하나부터 정해보는 편이 낫다.
예를 들어 “이번 주 아직 해결되지 않은 고객 이슈를 담당자별로 정리해줘”라는 요청을 지원한다고 하자. 필요한 것은 이슈 조회와 담당자 정보, 기간 해석, 요약 규칙이다. 이 작업에 이슈 삭제 권한까지 필요하지는 않다.
이렇게 범위를 좁히면 테스트 질문도 구체적이 된다. 검색 결과가 없을 때는 어떻게 답해야 할까? 담당자가 비어 있으면 누구에게 분류할까? 사용자가 볼 수 없는 프로젝트의 제목이 요약에 섞일 수 있을까?
이 질문에 대한 답이 도구 설명과 작업 절차에 반영돼야 한다. 플러그인 이름을 잘 붙이는 것만으로 해결되지는 않는다. 특히 읽기와 쓰기를 함께 제공한다면 ‘현황을 알려달라’는 요청이 상태 변경으로 이어지지 않도록 경계를 분명히 해야 한다.
또한 Claude의 모든 화면이 같은 구성요소를 실행한다고 가정하면 안 된다. 공식 개발 문서는 Chat·Cowork·Claude Code의 지원 범위를 확인하고 대상 환경에서 테스트하도록 안내한다. 터미널에서 동작했다는 사실만으로 웹과 모바일까지 같은 경험을 제공한다고 소개하지 말자. 환경별 확인의 출발점
심사 통과 다음에는 무엇을 봐야 할까?
새 포털에서는 제출 검증과 안전 검사, 심사 피드백을 확인할 수 있고, 승인 뒤 공개 시점을 개발자가 선택할 수 있다. 출시 후에는 설치와 버전별 사용 현황뿐 아니라 목록 조회와 유입 검색어도 확인할 수 있다고 발표됐다. 등록·분석 기능
이 지표를 보면 문제를 조금 더 정확하게 나눌 수 있다.
목록을 보는 사람이 거의 없다면 소개 문구와 사용 목적을 점검할 차례다. 목록은 보지만 설치하지 않는다면 어떤 서비스 계정이 필요한지, 어떤 일을 해결하는지 충분히 설명했는지 살펴볼 수 있다. 설치는 하지만 사용이 이어지지 않는다면 인증, 실패 응답, 실제 결과 품질을 확인해야 한다.
이는 발표가 보장하는 성장 공식이 아니라 운영 지표를 읽는 방법에 대한 제안이다. 등록된다는 것만으로 사용자 확보나 매출이 보장되지는 않는다. 디렉터리 노출과 웹사이트 방문도 같은 성과가 아니다. 사용자가 Claude 안에서 일을 끝내면 서비스의 가치는 전달되면서 웹 방문은 늘지 않을 수도 있다.
첫 배포의 목표를 ‘많은 기능을 가진 플러그인’으로 잡기보다, 한 문장으로 설명할 수 있는 작업이 실제로 끝나는 상태로 잡아보자. 그 작업이 안정적으로 쓰이는 것을 확인한 뒤 다음 기능을 추가해도 늦지 않다.
이 글은 2026년 9월 26일 공식 발표와 개발 문서를 기준으로 작성했다. 실제 제출·심사를 수행한 후기는 아니며, 세부 조건은 제출 시점의 공식 문서에서 다시 확인해야 한다.