6만 스타짜리 Claude Code 스킬 모음, 진짜 쓸 만한지 보기

mattpocock/skills라는 레포가 GitHub에서 트렌딩 타고 있어요. 62,000스타, 5,400백 포크. Claude Code 사용자 사이에서 화제고요. 본인 .claude/ 디렉토리를 그대로 공개한 형식인데, 슬래시 커맨드로 호출하는 워크플로우 스킬 모음입니다.

스타 수가 워낙 큰 도구라 "이거 진짜 좋은 거" 인지, 아니면 "인플루언서 영향력으로 부풀려진 거" 인지 한 번 분리해서 봐야겠다 싶어서 며칠 써봤습니다. 결론부터 말하면 둘 다 맞습니다. 진짜로 잘 만든 도구이고, 동시에 6만 스타 중 상당 부분은 Matt의 영향력이 만들어낸 거예요. 둘은 분리되는 사실이고, 둘 다 받아들이고 봐야 정확히 평가됩니다.

Matt Pocock이 누구

먼저 사람부터. TypeScript 커뮤니티에서 꽤 유명한 교육자예요. "Total TypeScript" 유료 강의 사이트 운영자, 트위터 팔로워 수십만, 최근에는 "AI Hero" 라는 AI 코딩 강의 사이트도 운영합니다. 즉 레포 공개 시점에 이미 큰 청중을 가진 사람이에요.

이게 중요한 이유: 6만 스타 중 어느 정도가 진짜 도구 가치이고 어느 정도가 인플루언서 효과인지 분리할 줄 알아야 객관적 평가가 됩니다. 트위터에서 본인 청중에게 "내 .claude 디렉토리 공개했다" 라고 한 번 던지면 그 자체로 수만 스타가 보장되는 자리거든요. 도구 자체의 객관적 품질과는 별개의 메커니즘입니다.

다만 그렇다고 "마케팅으로 부풀린 도구" 라고 단정하는 것도 정확하지 않아요. Matt이 영업력만 가진 사람이면 6만 스타까지 안 가요. 인플루언서 영향력이 시작이고, 거기서 한 단계 더 가게 만든 건 도구의 실제 품질입니다. 이 둘이 결합돼서 6만 스타가 된 거고, 진짜 수치로 따지면 "Matt이 아닌 사람이 이걸 만들었으면 5천~1만 스타 정도였을 것" 같습니다. 그 정도면 객관적으로 좋은 OSS 도구인 거고요.

진짜 잘 짚은 부분 - 4가지 실패 모드

이게 사실 글의 핵심이에요. Matt이 README에서 짚은 "Claude Code 쓰면서 만나는 4가지 실패 모드" 가 정말 정확합니다.

#1 Agent가 내가 원하는 거 안 함 - "misalignment" 라고 표현했는데, AI 에이전트 처음 쓰는 사람이 가장 자주 부딪히는 자리. 본인 머릿속의 모호한 요구사항을 그대로 던지고는 "왜 못 알아들어?" 가 되는 패턴.

#2 Agent가 너무 verbose - 도메인 용어를 모르니까 한 마디면 될 걸 20마디로 풀어 씀. 이게 누적되면 토큰도 낭비하고 가독성도 망가짐.

#3 코드가 작동 안 함 - 정렬은 됐는데 실제 코드가 깨지는 케이스. 피드백 루프 부재가 원인.

#4 Ball of Mud - 에이전트가 코딩 속도를 빠르게 하니까 "코드베이스 엔트로피" 도 같이 빨라짐. 일주일 후 본인 코드를 본인이 못 알아보는 자리.

이 진단 자체가 진짜 가치 있어요. AI 코딩 에이전트를 초창기부터 진지하게 굴려본 사람만이 정리할 수 있는 패턴이라고 봅니다. 그 감각이 README에 잘 담겨 있어요.

추천할 만한 스킬 - 4개

40개 넘는 스킬이 있는데, 그중 진지하게 검토할 만한 것을 4개 정도로 추려봤습니다.

1. /grill-with-docs - 작업 시작 전 정렬 도구

이게 가장 좋은 스킬이에요. 사용자가 "X 기능 만들어줘" 하면 바로 코드 짜는 게 아니라, 에이전트가 거꾸로 사용자를 인터뷰합니다. 어떤 모듈에 붙을 건지, 기존 패턴이랑 어떻게 연결될 건지, 엣지 케이스는 뭔지. 답하면서 사용자 본인도 "내가 뭘 원하는지" 더 명확해지는 효과가 있습니다. (최근 오퍼스 4.7에도 비슷한 기능이 붙었어요)

여기에 한 단계 더: 그릴 세션 결과로 CONTEXT.md(도메인 언어 사전)와 docs/adr/(아키텍처 결정 문서) 를 같이 갱신합니다. 다음 세션에서 에이전트가 이 두 파일 읽고 들어오면 정렬 비용이 훨씬 낮아져요. 작은 자동화인데 누적 효과가 진짜 큽니다.

2. /diagnose - 디버깅 루프

재현 → 최소화 → 가설 → 계측 → 수정 → 회귀 테스트. 이 6단계를 강제하는 스킬. "버그가 났다" 라고 던지면 에이전트가 임의로 수정 시도하지 않고 위 순서대로 진행합니다.

이건 사실상 시니어 개발자가 평소 하는 디버깅 패턴 그 자체입니다. 다만 에이전트는 이걸 자동으로 안 하고 "이거 같은데?" 식의 추측 수정을 던지기 쉬운데, 스킬로 강제하면 결과 품질이 다른 차원이 됩니다.

3. /improve-codebase-architecture - 진흙 코드베이스 구조 개선

위 #4 (Ball of Mud) 풀이 도구. 에이전트가 "이 코드베이스 어디가 잘못됐는지" 를 도메인 언어 + ADR 결정 맥락에서 봅니다. 텍스트 매칭이 아니라 "왜 이렇게 짜였는지" 를 이해한 후의 구조 개선 제안이라 품질이 다릅니다.

Matt이 "며칠에 한 번씩 돌리세요" 라고 권장하는데, 이건 진지하게 필요하다가 봅니다. 코드베이스 엔트로피가 알게 모르게 증가하는 걸 주기적으로 측정/개선하는 메커니즘이 거의 없거든요.(짜파게티 코드가 되는 이유!)

4. /caveman - 토큰 75% 절약 모드

울트라 압축 통신 모드예요. 필러 단어 다 빼고 핵심만. "please", "could you", 부드러운 표현 다 제거. 메시지 두 단어로 압축됩니다.

이걸 "무례한 톤" 으로 받아들이실 수도 있는데, 사실 에이전트한테는 톤이 큰 의미가 없어요. "공손함" 토큰들이 결과 품질을 올리지도 않고요. 자주 쓰시는 쿼리에는 의미 있는 절약입니다.

다만 한 가지 - "75% 절약" 이라는 수치는 입력 prompt 한 정거장이고, 전체 세션 비용 기준으로는 더 작은 비율이에요. 그래도 누적 효과는 의미 있습니다.

검토할 만한데 신중해야 할 스킬 - 2개

/tdd - Red-Green-Refactor 루프

테스트 먼저 짜고 → 통과시키고 → 리팩토링. 본인 코드 베이스에 테스트 인프라 잘 깔려 있고 TDD 익숙하신 분께는 좋은 스킬.

다만 - TDD가 모든 작업에 맞는 건 아니에요. 프로토타이핑 단계나, 시각적 UI 개발이나, 명확한 검증 기준 없는 작업에는 오히려 방해. 이 스킬은 "이 작업이 TDD에 맞는가" 부터 본인이 판단하고 호출해야 합니다. 무조건 호출하면 워크플로우가 느려져요.

/grill-me - 비코드 작업용 그릴

위 /grill-with-docs 의 가벼운 버전. CONTEXT.md/ADR 갱신 없이 그릴 세션만. 글쓰기, 문서 작업, 기획 같은 비코드 작업용.

이게 사용자 인내심 테스트가 될 수 있어요. 에이전트가 진짜 끈질기게 물어봐서 "그냥 답이나 줘" 가 되는 순간이 있거든요. 빠른 답이 필요한 자리에는 안 쓰시는 게 좋아요. 결정 트리가 복잡하고 본인도 정렬이 필요한 자리에서만 호출하시면 됩니다.

별로인 부분 - 정직하게

1. 셋업 부담이 적지 않음

/setup-matt-pocock-skills 한 번 돌려야 본격 사용 가능한데, 이슈 트래커(GitHub/Linear/local) 결정, 라벨 vocabulary 결정, 도메인 문서 위치 결정 등 사전 결정이 꽤 있어요. "가볍게 시도해보자" 가 안 되고 "이 도구를 본격 쓰기로 결심" 해야 시작 가능한 구조입니다.

2. Newsletter 광고가 곳곳에 있음

README 상단에 "6만 명 개발자가 구독 중인 내 뉴스레터 가입하세요" 가 박혀 있고, 일부 스킬 문서에도 등장합니다. 도구 자체와 별개로, 이게 Matt의 마케팅 깔때기의 한 부분이라는 점은 의식하고 보시는 게 좋아요. 도구를 쓰는 비용이 "본인의 이메일 주소를 Matt의 마케팅 채널에 노출하는 것" 인 자리도 있습니다.

3. TypeScript 편향

Matt이 TypeScript 교육자라서 일부 스킬(/migrate-to-shoehorn, /scaffold-exercises 등)은 본인 TypeScript 강의 생태계 전용입니다. 다른 언어 사용자한테는 무의미. README에 카테고리("misc")로 분리는 했는데, 그래도 전체 모음의 일관성이 살짝 깨져요.

4. 단일 모델 패턴 전제

이게 가장 큰 한계인데 - 모든 스킬이 Claude Code 한 마리에 좋은 워크플로우 주입하는 것을 전제합니다. 멀티 모델 환경(예: 분해는 Claude, 코드 생성은 로컬 LLM, 검토는 GPT 같은 오케스트레이션)에는 그대로 안 맞아요. "Claude Code만 쓴다" 가 전제라면 정확한 도구이고, 그 전제가 깨지는 환경에서는 부분적으로만 유용합니다. (이건 https://damoang.net/ai/2904 칼쓰뎅님이 gpt에 맞게 튜닝해서 사용중이라고 하셨으니 공개해주시면 좋을 듯 합니다 ㅎㅎ)

결론 - 어떤 분께 추천하나

적합한 자리:

• Claude Code (또는 비슷한 단일 모델 에이전트) 를 메인으로 쓰시는 분
• 코드베이스 1개를 깊이 다루시는 분 (CONTEXT.md / ADR 가치 살아남)
• "에이전트한테 일 시키는데 결과가 일관되지 않아 답답" 한 자리

부적합한 자리:

• 멀티 모델/멀티 에이전트 오케스트레이션이 메인 워크플로우인 분
• 가벼운 일회성 작업 위주이신 분 (셋업 비용 회수 안 됨)
• TypeScript 가 아니거나 도메인이 너무 좁은 작업 (일부 스킬 무의미)

핵심 4개 (/grill-with-docs, /diagnose, /improve-codebase-architecture, /caveman)는 진지하게 검토할 만합니다. 이 4개만 골라서 본인 워크플로우에 시도해보시고, 셋업 다 거치고 나서 다른 스킬은 필요할 때 추가하시는 게 합리적이에요. "40개 다 깔자" 보다 "4개 핵심부터 시작" 이 부담도 덜하고 회수율도 높습니다.

정리

6만 스타짜리 도구를 "좋다는데 일단 깔자" 하는 건 위험합니다. 동시에 "인플루언서 효과니까 무시하자" 하는 것도 손해예요. 둘은 분리되는 사실이고, 분리해서 본 후에 "이 도구의 어느 부분이 내 자리에 맞나" 를 본인이 판단해야 합니다.

Matt이 짚은 4가지 실패 모드는 진짜 정확하고, 그 풀이로 제시한 핵심 4개 스킬도 객관적으로 좋아요. 다만 셋업 비용, 단일 모델 전제, 마케팅 깔때기 같은 한계도 명확하니 - 본인 워크플로우랑 매칭되는 자리에서만 들이시는 게 맞습니다. 무조건 깔지도 말고, 무조건 무시도 하지 마시고요.

기술 OSS의 별 수는 그 자체로 도구 품질의 정확한 지표가 아닙니다. 누가 만든 도구인지가 별 수에 절반 이상 작용합니다. 그걸 의식하고 도구를 평가하는 습관이 AI 시대에는 더 중요해질 것 같아요.