내가 지금 쓰는 Claude Code 스킬·플러그인 세트 — 개발 태스크별로 묶었다

2026년 4월 · 귀찮은개발자 EP.20

배포 5분 전에 타입 에러가 터졌다. Claude가 직전에 "완료됐습니다"라고 한 상태였다. 그 말만 믿고 vercel --prod를 쳤다. Preview는 초록불이었지만 Production 빌드가 실패했다. 핫픽스 커밋 4개가 이어졌고 그날 저녁이 날아갔다.

이 일이 없었으면 Skill을 정리할 생각을 안 했을 거다. 그날 바로 /verification-before-completion을 상시 호출 대상으로 올렸다. "완료" 선언을 Claude가 마음대로 하지 못하게 게이트를 박아둔 거다. 그 뒤로 개발 태스크마다 비슷한 가드레일을 하나씩 붙였다. Skill이 7~8개로 늘어났다.

이 글은 내가 지금 주력으로 쓰는 Claude Code Skill·플러그인 세트 정리다. 태스크별로 묶었다 — UI / 백엔드 · API / 데이터 · DB / 배포 · 인프라 / 기획 · 리서치 / 리뷰 · 디버깅. 각 태스크에서 어떤 Skill을 언제 호출하는지, 어떤 플러그인에서 오는지, 그리고 안 쓰는 Skill까지 같이 적는다. EP.19에서 만든 5인 팀에 그대로 얹을 수 있는 세트다.

Skill과 플러그인 — 뭐가 다른가

먼저 용어부터 정리하자. Skill은 마크다운 파일 하나다. "이 작업은 이런 순서로 해라"를 적은 SOP다. Claude가 세션 중에 읽고 따른다. 파일 한 개 단위다.

플러그인은 Skill 묶음이다. 관련된 Skill 여러 개를 한 번에 설치할 수 있게 패키지화한 것이다. Anthropic이 2026년 1월에 공식 마켓플레이스를 열었고, 그 뒤로 /plugin install <name> 한 줄로 Skill 세트를 받아올 수 있다. 업데이트도 같은 명령어로 따라온다.

Skill 3~4개면 수동 복사가 편하다. 그 이상이면 플러그인이 합리적이다. 업데이트가 자주 나오는 Skill은 더더욱 플러그인 경로가 낫다. 나는 3개 플러그인 + 직접 만든 Skill 2~3개 조합으로 쓴다.

내가 깐 플러그인 4개

내 개발 루틴 대부분이 이 네 개 안에서 돈다. 나머지 공백은 프로젝트별로 직접 쓴 Skill 두세 개가 메운다.

superpowers는 개발 방법론 Skill 묶음이다. obra(Jesse Vincent)가 만든 오픈소스가 2026년 1월에 Anthropic 공식 마켓플레이스에 들어왔다. brainstorming, TDD, systematic-debugging, verification-before-completion 같은 "어떻게 일할 것인가"를 담은 Skill 20여 개가 한 번에 들어온다. GitHub 스타 9만 개 넘는다 — 가장 검증된 세트다.

vercel은 인프라·프레임워크 Skill이다. Next.js App Router·Server Component·Cache Components, Vercel Functions·Edge, AI SDK, 배포 CLI까지 폭이 넓다. Next.js 풀스택을 Vercel에 올리는 흐름에선 거의 필수다. 직접 메타데이터 기억 안 해도 Skill이 최신 문법을 끌어온다.

frontend-design은 UI 초안 + React 코드 품질 Skill이다. 제네릭 AI 디자인을 피하고 프로덕션급 UI를 만들게 유도한다. TSX 여러 개 수정한 뒤엔 react-best-practices 체크리스트가 자동으로 호출된다. shadcn 쓸 때도 여기서 초안이 깔끔하게 나온다.

bkit은 PDCA 사이클과 문서화 Skill이다. superpowers가 "어떻게 일할 것인가"라면 bkit은 "무엇을 어떤 단계로 남길 것인가"다. 1인 프로젝트엔 과하지만 클라이언트·팀 문서가 필요해지는 순간 이 플러그인이 제값을 한다. Plan → Design → Do → Check → Act 각 단계에 Skill이 붙어 있어서 의사결정 기록이 저절로 쌓인다. 설계-구현 갭 감지(gap-detector), 코드 품질 분석(code-analyzer), 자동 개선 루프(pdca-iterator)까지 한 세트다.

태스크별 Skill 지도 (7태스크 × 주력 Skill)

실제 개발에서 태스크 유형은 대략 7가지로 나뉜다. 각 태스크에서 어떤 Skill을 호출하는지가 이 글의 본편이다. 표로 먼저 한 번 훑고 섹션별로 자세히 들어간다.

중복되는 Skill도 있다. verification-before-completion은 배포·리뷰·테스트 태스크 어디서나 호출된다. 그래서 전역 Skill로 켜두고 나머지는 태스크별로 불러온다.

UI / 프론트엔드 — 초안부터 리뷰까지

UI 작업은 세 단계로 쪼갠다. 초안 → 구현 → 리뷰. 각 단계마다 Skill이 다르다.

초안 단계엔 frontend-design을 호출한다. "대시보드 카드 섹션 만들어줘" 같은 넓은 요청에 AI 스타일 티 안 나는 프로덕션급 초안을 뽑아준다. 제네릭 테일윈드 템플릿은 이 Skill로 피한다.

shadcn을 쓰고 있으면 vercel:shadcn이 붙는다. 컴포넌트 설치, 테마 구성, 커스텀 레지스트리를 물어볼 때 이 Skill이 자동 발동한다. shadcn 쓰는 프로젝트에선 거의 상주 상태다.

구현 끝나면 vercel:react-best-practices가 TSX 여러 개 수정된 걸 감지하고 리뷰 체크리스트를 돌린다. 훅 사용·접근성·성능·TypeScript 패턴을 일괄 확인한다. 내가 시키지 않아도 붙는 Skill 중 하나다.

백엔드 · API — Next.js 풀스택 기준

Next.js App Router로 풀스택을 짠다. Server Component, Server Actions, Route Handlers가 혼재한다. 이 구간에선 vercel:nextjs가 상주한다.

Server Component에서 fetch 하는 패턴, Server Actions로 폼 처리하는 패턴, Middleware에서 요청 가로채는 패턴 — 전부 이 Skill이 가장 최신 버전을 알고 있다. 내가 Next.js 16 기준으로 짜도 Skill이 15 시절 문법으로 되돌리지 않는다.

서버리스 함수가 필요한 시점엔 vercel:vercel-functions가 붙는다. Edge vs Node 런타임 선택, Fluid Compute 스트리밍, Cron Jobs 설정까지 안내한다. 직접 메모리 할당량이나 타임아웃 설정 기억 안 해도 된다.

AI 기능이 섞이면 vercel:ai-sdk가 추가된다. Chat UI, 구조화 출력, 툴 콜, 에이전트, MCP 통합 패턴까지 AI SDK 쪽 문법을 이 Skill이 잡아준다. Anthropic SDK를 직접 쓰는 경우엔 claude-api Skill이 우선한다.

REST API를 설계하는 초기 단계엔 bkit:phase-4-api가 유용하다. 엔드포인트 설계 규약, 에러 응답 포맷, Zero Script QA(테스트 스크립트 없이 구조화 JSON 로그로 검증) 체크리스트를 꺼내준다. 혼자 설계할 땐 skip해도 되지만 외부 공개 API나 팀 프로젝트에선 이 Skill이 잡아주는 규약 덕에 일관성이 유지된다.

데이터 · DB — 스토리지·캐시·쿼리

Vercel 스택에서 데이터 레이어는 Marketplace 스토리지(Neon·Upstash 등) + Vercel Blob + Edge Config가 기본이다. vercel:vercel-storage가 이 결정을 돕는다. "세션은 어디에, 로그는 어디에, 파일은 어디에"를 구분해준다.

캐싱은 두 축이다. 프레임워크 캐시는 vercel:next-cache-components로 간다 — use cache 지시자, cacheLife, cacheTag 쓰임새를 정리한다. 함수·미들웨어·빌드 간 공유 캐시가 필요하면 vercel:runtime-cache 쪽이다.

ORM 질문이 들어오면 EP.19에서 얘기한 Drizzle 패턴을 쓰되, 캐시 전략은 여기 Skill들이 알려준다. 직접 쿼리 튜닝은 Skill보단 인덱스·EXPLAIN으로 해야 한다. Skill이 SQL 최적화까지 해주진 않는다.

배포 · 인프라 — Vercel 위에서

배포는 가장 보수적으로 간다. Skill 두 개가 항상 붙는다.

vercel:deployments-cicd는 배포·롤백·프로모션·prebuilt 빌드를 다룬다. GitHub Actions에서 Vercel을 트리거하는 워크플로우 파일까지 짜준다. 직접 vercel --prod를 치기 전에 이 Skill이 한 번 체크한다.

환경변수는 vercel:env-vars다. .env 파일과 Vercel 환경변수 동기화, OIDC 토큰, 환경별 분리까지. 로컬에선 vercel env pull 한 줄로 끝나지만 어느 환경 어느 키를 공유할지 결정 단계에 이 Skill이 붙는다.

마지막 관문은 항상 superpowers:verification-before-completion이다. 배포 전에 빌드·타입·테스트가 실제로 통과하는지 확인한다. 이 Skill 하나가 프로덕션 사고 대부분을 막았다. 도입부에서 얘기한 그 "5분 전 타입 에러" 이후로 상시 켜둔다.

기획 · 리서치 — 코드 전 단계

코드 치기 전에 기획이 있다. 이 단계에 Skill을 붙이는 게 처음엔 어색했는데, 실제로 쓰니 결과물이 확 달라진다.

superpowers:brainstorming은 "만들까 말까"를 정리하는 Skill이다. 요구사항 구조화, 엣지케이스 사전 발견, 의사결정 트리 작성. 코딩 시작 전에 이 Skill로 한 번 대화하고 들어가면 중간에 설계 뒤집는 횟수가 준다.

superpowers:writing-plans는 한 단계 더 들어간다. brainstorming 결과를 실행 플랜으로 바꾼다. 파일 단위 · 단계 단위로 할 일을 쪼개놓는다. 플랜 파일이 나오면 /execute-plan이 받아서 돌린다. EP.19 Planner 역할 Skill이 바로 이 조합이다.

기획 문서를 팀 레포에 남겨야 하는 경우엔 bkit:pdca의 plan·design 단계를 같이 돌린다. brainstorming이 아이디어를 굳히는 대화라면, bkit은 그 대화 결과를 docs/plans/{feature}.md 포맷에 맞춰 저장해준다. bkit:bkit-templates가 계획서·설계서 템플릿을 끌어와서 "뭘 적어야 하지"를 대신 정해준다. 나는 혼자 작업엔 안 켜고, 클라이언트 프로젝트에서만 켠다.

리뷰 · 디버깅 — 마지막 게이트

구현이 끝나도 끝난 게 아니다. 리뷰·디버깅 Skill 세 개가 마지막 관문을 지킨다.

superpowers:systematic-debugging은 버그나 테스트 실패가 터졌을 때 발동한다. 재현 → 가설 3개 → 증거로 2개 탈락 → 최소 수정 순서를 강제한다. 무턱대고 고치는 충동을 막는 Skill이다. EP.19 Debugger 역할의 기본 Skill이기도 하다.

superpowers:verification-before-completion은 "됐다"라고 말하기 전에 돌린다. 타입 체크, 빌드, 테스트 실행 결과를 확인한 뒤에야 완료 처리를 허용한다. 이 Skill 없이 "완료됐습니다"를 믿으면 안 된다.

superpowers:requesting-code-review는 직접 만든 기능을 다른 세션에서 리뷰받을 때 쓴다. 변경 이유·엣지케이스·테스트 증거를 포맷에 맞춰 정리한다. 리뷰 받는 쪽이 친절한 세션일수록 답변이 뾰족해진다.

bkit 쪽에서 추가로 붙는 두 Skill이 있다. bkit:code-analyzer는 커밋 전 코드 품질·보안·성능 이슈를 구조화된 리포트로 정리한다. systematic-debugging이 "왜 안 되지"라면 code-analyzer는 "이거 괜찮지만 이 세 가지는 손보면 좋다"에 가깝다. bkit:gap-detector는 설계 문서와 실제 구현 사이 갭을 잡아낸다. PDCA의 Check 단계에 해당하고, Match Rate가 90% 미만이면 pdca-iterator가 자동 개선 루프를 돌린다. 설계 문서를 남기는 프로젝트에서만 유용한 Skill이다.

프로세스 · 문서화 — 문서가 필요해지는 순간

혼자 개발할 땐 프로세스·문서화 Skill을 거의 안 켠다. 그런데 상황이 바뀌는 순간이 있다. 팀원이 합류할 때, 클라이언트에게 진행 상황 보고가 필요할 때, 몇 달 뒤의 내가 "이거 왜 이렇게 짰지?"를 확인해야 할 때다. 그때 bkit이 제값을 한다.

bkit:pdca는 Plan → Design → Do → Check → Act 다섯 단계를 슬래시 커맨드로 쪼갠다. /pdca plan {feature}는 기획서를, /pdca design은 설계서를, /pdca analyze는 구현 후 분석 리포트를 각 단계별 경로에 저장한다. 이 Skill 하나로 docs/ 아래 기록이 자동 축적된다.

bkit:report-generator는 PDCA 사이클이 한 번 돌고 나면 완료 리포트를 만들어준다. Plan/Design/Do/Check 문서와 실제 구현을 모아 "이번 스프린트에 뭐 했는지 · 무엇을 배웠는지"를 한 장짜리 문서로 정리한다. 스테이크홀더 공유용으로 그대로 보낸다.

bkit:pdca-iterator는 Evaluator-Optimizer 패턴이다. gap-detector가 Match Rate 90% 미만을 내면 자동으로 반복 개선 루프를 돈다. 최대 5회 이터레이션을 제한해두고, 90% 넘으면 report-generator로 넘어간다. 혼자 작업엔 오버킬이고, 팀이 합류한 시점부터 의미가 생긴다.

EP.19 5인 팀에 매핑하면

EP.19에서 만든 5인 팀(Planner·Coder·Reviewer·Tester·Debugger)에 Skill이 자연스럽게 매핑된다. 각 Agent의 tools와 Skill을 연결하면 팀이 바로 돈다.

코드 베이스가 Next.js가 아니면 nextjs 대신 해당 프레임워크 Skill로 갈아끼우면 된다. Skill이 플러그인 단위로 묶여 있어서 프로젝트 스택만 바뀌어도 팀 구조 자체는 유지된다.

쓰다 버린 Skill (솔직하게)

모든 Skill이 쓸 만한 건 아니다. 안 쓰게 된 것도 정직하게 적는다.

using-git-worktrees — 이론적으로 유용한데 내 워크플로우엔 안 맞았다. 나는 브랜치 전환이 빠르고 멀티 워크트리를 유지할 만큼 병렬 작업이 많지 않다. 큰 리팩토링할 때 한 번씩 꺼냈다가 다시 브랜치로 돌아온다.

dispatching-parallel-agents — EP.19 구축 초반에 썼는데 5인 팀을 직접 돌리기 시작하면서 손 놓았다. 외부 DB로 상태를 공유하는 구조가 더 안정적이다. 일회성 병렬 태스크엔 여전히 쓸 수 있다.

bkit:enterprise·bkit:infra-architect — 같은 bkit 플러그인 안에 있지만 이 두 Skill은 안 켠다. 마이크로서비스·k8s·Terraform 조합 프로젝트용인데 내 스택(Vercel + Supabase)엔 맞지 않았다. 엔터프라이즈급 인프라 설계가 필요한 시점에만 꺼낸다.

Skill 직접 만드는 시점

처음엔 플러그인이 준 Skill로 충분하다. "이건 매번 같은 말 타이핑하네"가 3번 이상 반복되면 그때 직접 만든다.

내가 직접 만든 Skill은 세 개다. publish-post(블로그 발행 파이프라인), screenshot-ppt(Puppeteer 캡처 템플릿), wp-media-upload(WordPress 미디어 API 호출). 전부 블로그 운영에서만 쓰는 것들이다. 다른 프로젝트엔 안 붙인다.

직접 만들 땐 superpowers:writing-skills가 도와준다. Skill 작성 규약·예시·메타데이터 포맷을 이 Skill이 쥐고 있다. 내 Skill을 쓴 뒤에 같은 Skill을 재호출해 검증하게 하면 포맷 실수가 없다.

FAQ

Q. 플러그인 없이 Skill만 따로 받아 써도 되나?

가능하다. 마크다운 파일을 ~/.claude/skills/에 복사만 하면 된다. 다만 업데이트가 끊긴다. 플러그인으로 설치하면 새 버전이 자동으로 따라온다. Skill 3개 이하면 수동, 그 이상은 플러그인이 편하다.

Q. superpowers와 bkit은 겹치지 않나?

겹치는 영역은 있지만 포지션이 다르다. superpowers는 "어떻게 일할 것인가"(방법론), bkit은 "무엇을 어떤 단계로 남길 것인가"(프로세스·문서). 1인 개발엔 superpowers만 주력으로 쓰고 bkit은 기획·리뷰 태스크에서 보조로 호출한다. 클라이언트·팀 프로젝트에선 bkit을 주력으로 올려 문서를 자동 축적한다.

Q. Skill 몇 개부터 관리가 어려워지나?

7~8개 넘어가면 Claude가 "어느 Skill을 써야 할까요?"를 묻기 시작한다. 내 경험상 주력은 6~7개가 한계다. 그 이상은 태스크별로 프로필을 나눠 쓰는 게 낫다.

Q. 플러그인 설치 명령어는?

/plugin install superpowers@claude-plugins-official — 2026년 1월부터 Anthropic 공식 마켓플레이스에 올라왔다. 이 한 줄로 설치 끝. 업데이트도 같은 명령어로 따라온다.

Q. 직접 만든 Skill이랑 같이 쓸 수 있나?

된다. ~/.claude/skills/에 내 Skill을 넣어두면 플러그인 Skill과 같은 레벨에서 호출된다. 이름만 겹치지 않게 쓰면 충돌 없다.

마무리

Skill은 Claude를 더 똑똑하게 만드는 게 아니라 내 작업 방식을 Claude한테 반복해서 보여주는 장치다. 플러그인 3개로 80%는 덮이고, 나머지 20%는 직접 만든 Skill이 채운다. 처음 세팅은 10분이면 끝난다.

80%는 먼저 빠르게, 나머지 20%는 실제 문제 생길 때 고친다. Skill도 같은 원칙으로 늘린다. 기본 3개 플러그인으로 시작하고, "이건 매번 반복된다"는 순간이 3번 반복되면 그때 새 Skill을 만든다. 그 전엔 굳이 손대지 않는다.

마지막 관문은 언제나 사람이다. verification-before-completion이 통과했다고 실제 기능이 보장되는 게 아니다. 빌드·타입·테스트는 자동이 잡고, 비즈니스 로직은 사람이 확인한다. 이 전제만 지키면 Skill 세트는 개발 속도를 실제로 올려준다.

이 글은 실제 운영 중인 개발 루틴과 공식 문서를 바탕으로 작성됐다. 플러그인 목록과 버전은 변경될 수 있으므로 최신 정보는 공식 마켓플레이스에서 확인한다.

최초 작성: 2026년 4월 · GoCodeLab