13장. 플러그인과 마켓플레이스

MCP를 붙이고, Hooks를 걸고, Skills를 쌓다 보면 어느 순간 이런 생각이 듭니다.

"이걸 다 내가 직접 만들어야 하나?"

여기서 많은 솔로 빌더가 두 갈래로 갈립니다. 한쪽은 모든 것을 직접 만들다가 지칩니다. 다른 한쪽은 반대로 마켓플레이스에서 눈에 띄는 것을 잔뜩 설치했다가 환경이 금세 어수선해집니다. 둘 다 생산성을 떨어뜨리는 길입니다.

플러그인 생태계의 진짜 가치는 이 둘 사이에 있습니다. 직접 만들 가치가 있는 것은 직접 만들고, 이미 잘 검증된 것은 가져다 쓰되, 설치 기준과 운영 기준은 내 쪽에 남겨 두는 것입니다.

이 장에서는 바로 그 기준을 다룹니다. 플러그인이 정확히 무엇인지, 마켓플레이스는 어떻게 동작하는지, 어떤 플러그인을 믿고 들일지, 그리고 솔로 빌더라면 어떻게 자기만의 플러그인 셋업 템플릿을 만들어야 하는지 차근차근 보겠습니다.

플러그인은 묶음이고, 마켓플레이스는 배포 방식이다

앞 장들에서 우리는 Skills, 서브에이전트, Hooks, MCP를 각각 따로 배웠습니다. 플러그인은 이 조각들을 한데 묶어 설치 가능한 형태로 만든 꾸러미입니다. 예를 들어 Figma 연동 플러그인 하나가 MCP 연결 설정, 디자인 구현용 Skill, 리뷰용 명령어까지 함께 담을 수 있다는 뜻입니다.¹

이때 마켓플레이스는 앱스토어와 비슷한 역할을 합니다. 다만 중요한 차이가 하나 있습니다. 마켓플레이스를 추가한다고 해서 기능이 바로 활성화되는 것은 아닙니다. 먼저 카탈로그를 등록하고, 그다음 그 안에서 원하는 플러그인을 골라 개별 설치합니다.² 이 두 단계 구조는 생각보다 중요합니다. 한 번 등록한 뒤에도 플러그인은 필요한 것만 골라 얇게 유지할 수 있기 때문입니다.

솔로 빌더 관점에서 이 구조가 좋은 이유는 단순합니다. 제품을 운영하다 보면 필요한 기능은 계속 바뀝니다. 이번 달에는 GitHub와 Playwright가 가장 중요하지만, 다음 달에는 배포 자동화나 디자인 핸드오프가 더 중요해질 수 있습니다. 플러그인 시스템은 이런 변화를 "설정 변경" 수준으로 다루게 해 줍니다. 코어 워크플로우를 갈아엎지 않고도 능력을 끼웠다 뺄 수 있는 셈입니다.

13.1 Plugin 시스템 이해

플러그인을 이해하는 가장 쉬운 방법은 구성 요소를 위계로 보는 것입니다.

가장 아래에는 Skill, Hook, Agent, MCP 서버, LSP 서버 같은 개별 부품이 있습니다. 그 위에 이 부품들을 묶어 놓은 것이 플러그인입니다. 그리고 여러 플러그인을 카탈로그 형태로 배포하는 저장소가 마켓플레이스입니다.³

즉, 관계는 이렇게 정리할 수 있습니다.

• Skill은 한 가지 작업 능력입니다.

• Plugin은 여러 능력을 하나의 설치 단위로 묶은 패키지입니다.

• Marketplace는 그런 패키지들을 배포하는 목록입니다.

이 구분이 왜 중요할까요. 솔로 빌더는 문제를 "무엇을 설치할까?"로 시작하면 자주 길을 잃습니다. 대신 "내가 필요한 것은 단일 Skill인가, 통합 워크플로우인가, 배포 채널인가?"로 생각해야 합니다.

예를 들어 코드 리뷰용 체크리스트 하나만 필요하면 Skill이면 충분합니다. 반면 GitHub 연동, PR 리뷰 에이전트, 커밋 명령어, 검증 Hook이 함께 필요하다면 플러그인이 더 맞습니다. 그리고 그 플러그인을 팀이나 여러 프로젝트에 반복 배포하려면 마켓플레이스가 필요합니다.

공식 문서 기준으로 마켓플레이스는 marketplace.json 파일을 중심으로 동작합니다. 이 파일에는 마켓플레이스 이름, 소유자 정보, 그리고 어떤 플러그인을 어디서 가져올지 적습니다. 소스는 같은 저장소 안의 상대 경로일 수도 있고, GitHub 저장소일 수도 있고, git 하위 디렉터리나 npm 패키지일 수도 있습니다.³ 이 설계 덕분에 플러그인 배포는 꽤 유연합니다. 작은 개인 저장소에서도 시작할 수 있고, 모노레포의 일부만 떼어 배포할 수도 있습니다.

여기서 솔로 빌더에게 실용적인 포인트는 세 가지입니다.

첫째, 플러그인은 결국 코드와 설정의 묶음입니다. 그러니 설치 전에는 README만 보지 말고 실제 내용도 확인해야 합니다. 공식 디렉터리도 이 점을 분명히 경고합니다. 플러그인은 MCP 서버, 로컬 스크립트, 기타 소프트웨어를 함께 불러올 수 있으므로, 의도대로 동작할지와 안전한지를 사용자가 직접 확인해야 합니다.⁴⁵

둘째, 플러그인은 범위가 있습니다. 사용자 범위로 설치하면 내 모든 프로젝트에서 쓰고, 프로젝트 범위로 설치하면 저장소에 공유되며, 로컬 범위로 설치하면 내 현재 저장소에서만 씁니다.² 이 범위 개념을 무시하면, 어느 프로젝트에서는 편리했던 플러그인이 다른 프로젝트에서는 소음이 됩니다.

셋째, 플러그인은 설치보다 관리가 더 중요합니다. 설치나 비활성화, 제거는 /plugin 인터페이스와 CLI로 다룰 수 있고, 플러그인을 바꾼 뒤에는 /reload-plugins로 재시작 없이 반영할 수 있습니다.² 즉, 플러그인은 한 번 깔고 잊는 도구가 아니라, 작업 맥락에 맞춰 계속 정리해야 하는 운영 자산입니다.

여기서 많은 사람이 놓치는 사실이 하나 있습니다. 플러그인 생태계의 핵심은 "기능 확장"이 아니라 컨텍스트 절약입니다. 필요한 기능을 묶음으로 가져오되, 지금 안 쓰는 능력은 비활성화하거나 아예 설치하지 않음으로써 작업 공간을 가볍게 유지하는 것이 훨씬 중요합니다.

공식 마켓플레이스와 커뮤니티 마켓플레이스는 어떻게 다를까

Claude Code는 공식 Anthropic 마켓플레이스를 기본으로 제공합니다. 시작하자마자 /plugin의 Discover 탭에서 탐색할 수 있고, github, gitlab, notion, slack, supabase, vercel, sentry 같은 외부 통합이나 언어별 LSP 플러그인, 개발 워크플로우용 플러그인을 설치할 수 있습니다.²

이 공식 채널의 장점은 명확합니다. 시작이 쉽고, 설명이 비교적 표준화되어 있으며, 일정 수준의 검토를 거친 플러그인이 모여 있습니다. 특히 일부 플러그인에는 "Anthropic Verified" 배지가 붙는데, 이는 기본 자동 검토보다 한 단계 더 품질과 안전 관점의 검토를 거쳤다는 뜻입니다.¹

다만 이 말을 "공식이니까 무조건 안전하다"로 이해하면 곤란합니다. Anthropic도 플러그인 내부에 포함된 모든 MCP 서버나 로컬 소프트웨어를 완전히 통제하지는 못한다고 분명히 밝힙니다.⁵ 공식 채널은 신뢰의 출발점이지, 사고를 멈춰도 되는 보증 수표가 아닙니다.

반대로 커뮤니티 마켓플레이스는 훨씬 빠르고 다양합니다. 대형 디렉터리 서비스들은 수천 개 규모의 skills, MCP servers, marketplaces를 모아 카테고리와 인기도 기준으로 정리해 보여 줍니다.⁶⁷ 커뮤니티 저장소 중에는 특정 영역에만 강한 큐레이션도 많습니다. 예를 들어 워크플로우 오케스트레이션, 코드 품질, 문서화, 보안, 그로스, 제품 관리 등으로 분류해 플러그인을 모아 둔 큐레이션 저장소도 있습니다.⁸

이런 다양성은 솔로 빌더에게 큰 기회입니다. 내 분야에 딱 맞는 워크플로우를 훨씬 빨리 가져올 수 있기 때문입니다. 하지만 동시에 함정도 있습니다. 설치 수가 많고 스타가 많다고 해서 내 환경에 맞는다는 뜻은 아닙니다. 특히 플러그인은 단순 텍스트 프롬프트가 아니라 도구 권한과 스크립트 실행을 품을 수 있으므로, "인기 많으니 일단 설치"는 아주 나쁜 습관입니다.

정리하면 이렇습니다.

공식 마켓플레이스는 기본형 공구함입니다. 커뮤니티 마켓플레이스는 전문 장비 상가입니다. 처음엔 공식부터 쓰고, 그다음 빈 구멍이 분명해졌을 때 커뮤니티로 가는 편이 좋습니다.

13.2 검증된 플러그인 큐레이션

이 장의 핵심 문장을 하나만 남긴다면 이것입니다.

플러그인은 기능으로 고르지 말고, 리스크 대비 반복 사용 빈도로 골라야 합니다.

멋져 보이는 플러그인은 많습니다. 하지만 솔로 빌더에게 좋은 플러그인은 대개 화려한 것이 아니라, 자주 쓰는 반복 업무를 줄이고, 실수 확률을 낮추고, 작업 전환 비용을 깎아 주는 것입니다.

제가 권하는 선별 기준은 다섯 단계입니다.

첫 번째 기준: 이 플러그인이 시간을 버는가, 시간을 먹는가

플러그인을 설치하면 새로운 능력이 생기지만, 동시에 새로운 메뉴와 명령, 권한과 업데이트 관리 부담도 생깁니다. 따라서 첫 질문은 늘 이겁니다.

"이걸 한 달에 몇 번 쓸까?"

한 달에 한두 번도 안 쓸 플러그인은 대체로 설치보다 북마크가 낫습니다. 반대로 매주 반복하는 작업이라면 후보가 됩니다. 예를 들어 GitHub PR 워크플로우, 커밋 보조, 코드 인텔리전스, 로컬 품질 점검, 배포 전 점검은 반복 빈도가 높아 플러그인화 가치가 큽니다.²⁴

두 번째 기준: 내부 구성이 보이는가

좋은 플러그인은 무엇이 들어 있는지 감추지 않습니다. 공식 저장소 예시를 보면 플러그인 구조는 비교적 명확합니다. .claude-plugin/plugin.json, commands/, agents/, skills/, README.md 같은 디렉터리 구성이 드러나고, 필요하면 .mcp.json도 포함됩니다.⁴

즉, 설치 전 확인해야 할 것은 설명문보다 구조입니다. 어떤 명령을 추가하는지, 어떤 Hook이 있는지, 어떤 MCP 서버를 띄우는지, 외부 바이너리 의존성이 있는지 봐야 합니다. 구조가 투명하지 않으면 생산성이 아니라 복권을 사는 셈입니다.

세 번째 기준: 업데이트 전략이 있는가

마켓플레이스는 버전 추적과 자동 업데이트를 지원합니다.³ 편리한 기능이지만, 솔로 빌더에게 자동 업데이트는 양날의 검입니다. 어제 잘 되던 워크플로우가 오늘 갑자기 바뀔 수도 있기 때문입니다.

그래서 제 권장은 단순합니다. 공식 마켓플레이스의 저위험 플러그인만 자동 업데이트를 열고, 타사 마켓플레이스는 기본적으로 수동 업데이트로 두세요.² 특히 배포, Git 조작, 파일 쓰기, 외부 서비스 호출이 포함된 플러그인은 더 보수적으로 다루는 편이 좋습니다.

네 번째 기준: 권한이 목적에 비해 과하지 않은가

이 기준이 가장 중요합니다. 예를 들어 단순 리뷰 보조 플러그인인데 광범위한 Bash 실행, 네트워크 호출, 쓰기 권한이 함께 들어 있다면 한 번 더 생각해야 합니다. 좋은 플러그인은 대체로 목적이 선명하고, 필요한 권한도 그 목적에 맞게 좁혀져 있습니다.

마켓플레이스와 플러그인은 사용자 권한으로 실행되는 매우 신뢰도 높은 구성 요소라는 점을 공식 문서도 분명히 강조합니다.² 다시 말해, 플러그인을 설치하는 일은 브라우저 확장 프로그램 하나 까는 것보다 더 무겁게 봐야 합니다.

다섯 번째 기준: 나중에 지울 수 있는가

의외로 중요합니다. 플러그인은 도입보다 퇴출이 쉬워야 합니다. 비활성화, 제거, 범위 축소가 간단하지 않으면 결국 환경에 잔해가 남습니다.² 좋은 셋업은 늘 "이게 별로면 바로 뺄 수 있다"는 전제가 있어야 합니다.

솔로 빌더에게 먼저 추천하는 플러그인 카테고리

플러그인 이름보다 카테고리로 생각하면 선택이 훨씬 쉬워집니다.

첫 번째는 코드 인텔리전스 플러그인입니다. 언어 서버를 연결해 정의로 이동, 참조 찾기, 타입 오류 확인 같은 기능을 Claude에게 제공합니다. 특히 TypeScript, Python, Go, Rust처럼 타입 또는 도구 체인이 잘 갖춰진 언어는 체감 차이가 큽니다.²

두 번째는 외부 통합 플러그인입니다. GitHub, GitLab, Notion, Slack, Supabase, Vercel, Sentry 같은 서비스와의 연결을 미리 묶어 두어 설정 비용을 줄입니다.² 이미 12장에서 MCP 자체를 배웠다면, 이 카테고리는 "내가 매번 수동 설정하던 연동을 플러그인 단위로 가져오는 방식"이라고 이해하면 됩니다.

세 번째는 개발 워크플로우 플러그인입니다. 커밋 생성, PR 리뷰, 플러그인 개발 보조처럼 자주 반복되는 작업을 명령어와 에이전트 단위로 제공합니다.²

네 번째는 출력 스타일 또는 작업 방식 플러그인입니다. 설명을 더 교육적으로 하거나, 학습 모드로 응답하게 만드는 식의 출력 스타일도 플러그인으로 배포될 수 있습니다.² 이런 것은 강력해 보이지만, 솔로 빌더에게는 오히려 신중히 써야 합니다. 출력 스타일은 거의 모든 세션의 톤을 바꾸기 때문입니다.

이 네 카테고리를 보면 감이 옵니다. 처음부터 전부 넣는 것이 아니라, 현재 병목이 있는 축부터 하나씩 채워 넣어야 합니다.

실전 큐레이션: 설치 전 체크리스트

처음 보는 플러그인을 들이기 전에 저는 다음 순서를 권합니다.

1. 누가 만들었는지 본다. 공식인지, 검증 배지가 있는지, 개인 저장소인지 확인합니다.¹⁴

2. 무엇이 들어 있는지 본다. Skill만 있는지, MCP 서버와 Hook까지 들어 있는지 살핍니다.⁴

3. 외부 의존성을 본다. 별도 바이너리, Node 패키지, 인증 토큰, 로컬 스크립트 실행이 필요한지 봅니다.²⁵

4. 설치 범위를 좁힌다. 처음엔 user가 아니라 local 또는 project 범위로 시험하는 편이 안전합니다.²

5. 세션에서 테스트한다. 설치 후 /reload-plugins로 반영하고, 작은 작업 하나만 맡겨 봅니다.²

6. 남길지 뺄지 빨리 결정한다. 세 번 이상 유용하면 남기고, 그렇지 않으면 비활성화하거나 제거합니다.

이 체크리스트를 따르면 마켓플레이스가 놀이터가 아니라 실험실이 됩니다. 아무거나 넣어 보고 환경이 무거워지는 대신, 작은 가설을 검증하며 내 셋업을 진화시키게 됩니다.

13.3 솔로 빌더의 플러그인 셋업 템플릿

이제 가장 실전적인 이야기로 가봅시다. 솔로 빌더는 어떤 구조로 플러그인을 운영해야 할까요.

제 추천은 "3층 구조"입니다.

첫 번째 층은 기본 생존층입니다. 모든 프로젝트에서 거의 공통으로 쓰는 것만 둡니다. 예를 들어 언어별 LSP, GitHub 워크플로우, 아주 가벼운 품질 보조 정도입니다. 이 층은 사용자 범위에 둘 수 있습니다.²

두 번째 층은 프로젝트 전용층입니다. 특정 SaaS나 특정 저장소에서만 필요한 통합입니다. Supabase, Vercel, Sentry, Notion, 특정 프레임워크용 개발 플러그인 같은 것은 이쪽으로 보내는 편이 낫습니다. 이 층은 프로젝트 범위 또는 로컬 범위가 잘 맞습니다.²

세 번째 층은 실험층입니다. 커뮤니티에서 발견한 새 플러그인, 아직 안정성을 검증하지 않은 툴, 생산성은 좋아 보이지만 내 흐름과 충돌할 수 있는 것들을 잠깐 써 보는 층입니다. 이 층은 항상 로컬 범위가 좋습니다.

이 구조를 쓰면 머리가 맑아집니다. 모든 플러그인이 한 바구니에 섞이지 않기 때문입니다.

템플릿 1: 최소 시작 세트

사이드 프로젝트를 막 시작한 솔로 빌더라면 이 정도면 충분합니다.

• 언어 하나에 맞는 LSP 플러그인 1개

• GitHub 연동 또는 커밋 워크플로우 플러그인 1개

• 품질 점검용 플러그인 1개

이 구성의 장점은 단순합니다. 설치했을 때 바로 체감되고, 컨텍스트 오염이 적습니다. 개발 초반에는 기능보다 속도가 중요하니, 도구도 최소한으로 가져가야 합니다.

템플릿 2: 운영 진입 세트

사용자가 붙기 시작하고, 이슈와 배포, 장애 대응이 늘어나는 시점에는 다음이 유용합니다.

• GitHub 또는 GitLab 워크플로우 플러그인

• 배포/인프라 연동 플러그인

• 모니터링 또는 오류 추적 플러그인

• 문서화 또는 changelog 보조 플러그인

이 단계에서는 "더 빨리 만드는 것"보다 "덜 놓치는 것"이 중요해집니다. 플러그인의 역할도 생성보다 검증과 운영 보조 쪽으로 옮겨 갑니다.

템플릿 3: 혼자 일하지만 팀처럼 움직이는 세트

여기서는 조금 더 고급입니다. 서브에이전트와 Skill, 외부 연동이 묶인 플러그인이 빛납니다.

• PR 리뷰용 에이전트 플러그인

• 커밋/브랜치/릴리스 명령 플러그인

• 자체 제품 운영용 내부 플러그인

• 플러그인 개발 보조 플러그인

이 구성이 좋은 이유는 "일의 흐름"을 패키징하기 때문입니다. 단순 명령 하나가 아니라, 검토하고, 수정하고, 정리하고, 배포하는 흐름이 하나의 플러그인 단위로 들어오면 솔로 빌더는 진짜로 작은 팀처럼 움직일 수 있습니다.

자기 마켓플레이스를 만들면 좋은 순간

처음부터 자기 마켓플레이스를 만들 필요는 없습니다. 하지만 다음 셋 중 두 개 이상에 해당하면 진지하게 고려할 만합니다.

첫째, 여러 프로젝트에서 같은 플러그인 조합을 반복해 쓰고 있습니다.

둘째, 개인용 플러그인과 공개 플러그인을 섞어 관리하고 싶습니다.

셋째, 버전과 업데이트 시점을 내가 통제하고 싶습니다.

마켓플레이스는 결국 배포 카탈로그입니다. .claude-plugin/marketplace.json 하나로 시작할 수 있고, 플러그인을 같은 저장소의 상대 경로로 둘 수도 있으며, GitHub 저장소나 npm 패키지를 섞어 등록할 수도 있습니다.³ 중요한 것은 거창한 플랫폼을 만드는 것이 아니라, 내 표준 도구 묶음을 한 번에 재현 가능하게 만드는 것입니다.

예를 들어 이런 구조를 생각할 수 있습니다.

solo-builder-tools/
  .claude-plugin/
    marketplace.json
  plugins/
    review-kit/
    release-kit/
    ops-kit/

review-kit에는 코드 리뷰 Skill과 리뷰 에이전트를, release-kit에는 릴리스 체크 명령과 Hook을, ops-kit에는 운영용 MCP 연결과 복구 체크리스트를 넣는 식입니다. 이 구조의 좋은 점은 미래의 내가 새 노트북을 사더라도 같은 셋업을 빠르게 복원할 수 있다는 것입니다.

또 하나 중요한 기능은 마켓플레이스 간 의존성 통제입니다. 공식 문서는 다른 마켓플레이스의 플러그인에 의존할 수 있는 목록을 허용 목록으로 제한하는 설정도 제공합니다.³ 이건 팀용 기능처럼 보이지만, 솔로 빌더에게도 유용합니다. 내 내부 마켓플레이스가 아무 커뮤니티 플러그인에나 기대지 않게 막아 주기 때문입니다.

남의 것을 가져다 쓸 때와 직접 만들 때의 경계선

이 장의 마지막 질문은 이것입니다.

"언제 가져다 쓰고, 언제 직접 만들까?"

제 기준은 간단합니다.

이미 잘 검증된 외부 서비스 연결, 언어 서버, 범용 Git 워크플로우는 가져다 쓰는 편이 낫습니다. 공식 마켓플레이스와 검증된 디렉터리의 힘을 빌리는 것이 빠르고, 유지 비용도 적습니다.²⁴⁶

반대로 내 제품만의 운영 액션, 내 배포 절차, 내 리뷰 기준, 내 릴리스 체크리스트는 직접 만드는 쪽이 좋습니다. 이런 것은 남의 일반론보다 내 구체성이 더 큰 가치이기 때문입니다.

쉽게 말해 이렇습니다.

세상 공통의 문제는 남이 푼 것을 쓰고, 내 사업 특유의 문제는 내가 묶어서 자산으로 만들면 됩니다.

이 기준만 흔들리지 않으면 플러그인 생태계는 함정이 아니라 지렛대가 됩니다.

좋은 플러그인 셋업은 많음이 아니라 선명함이다

플러그인과 마켓플레이스는 Claude Code를 강하게 만듭니다. 하지만 아무거나 많이 붙인다고 더 강해지는 것은 아닙니다. 오히려 혼란만 늘어날 때가 많습니다.

솔로 빌더에게 필요한 것은 거대한 도구 박물관이 아닙니다. 자주 쓰는 동작을 빠르게 꺼내 쓸 수 있는, 얇고 믿을 수 있는 공구 벨트입니다.

그래서 원칙은 단순해야 합니다.

• 공식부터 시작한다.

• 반복 업무에만 설치한다.

• 처음엔 범위를 좁힌다.

• 자동 업데이트는 보수적으로 연다.

• 세 번 이상 안 쓰면 뺀다.

• 내 비즈니스 고유의 흐름만 직접 패키징한다.

모든 것을 직접 만들 필요는 없습니다. 하지만 아무거나 설치해도 안 됩니다.

그 중간 어딘가에, 솔로 빌더에게 딱 맞는 속도가 있습니다. 그 속도를 찾는 사람이 결국 덜 지치고, 더 오래 만들고, 더 꾸준히 운영합니다.

다음 부부터는 이 확장 도구들을 바탕으로, 실제로 아이디어를 PRD로 바꾸고 프로토타입을 만들고 운영하는 흐름으로 들어가겠습니다. 이제 공구는 어느 정도 갖춰졌습니다. 다음은, 진짜로 제품을 만드는 차례입니다.

참고

¹Plugins for Claude Code and Cowork [Anthropic]

²마켓플레이스를 통해 미리 빌드된 플러그인 발견 및 설치

³플러그인 마켓플레이스 생성 및 배포

⁵Create and distribute a plugin marketplace

⁶Find the best plugins, skills, and MCP servers for Claude Code

⁷Plugin Marketplaces | Claude Code Plugin Directory

⁸ihistand/marketplace - Claude Code Plugins Marketplace