Claude Code 확장 기능을 47개 시도해보고 5개로 압축한 이야기 ── 남긴 이유와 버린 기준

지난주에는 용어 정리로서 Skills / MCP / Hooks / Plugins의 4가지 확장에 대해 작성했습니다. 이번 주는 실전 경험 편입니다.

저는 처음에 Skill을 47개나 넣고 '47명의 어시스턴트를 고용했다'는 기분이었습니다. 실상은 'hooks가 47번 폭주했다'였습니다. 참 좋네요.

3개월 동안 운용해 보니 살아남은 것은 단 5개뿐이었습니다. 본 기사는 그 압축 과정과 판정 기준을 남겨두는 실전 기록입니다.

47개 → 12개 → 5개로. 각 단계에서 무엇을 쳐냈는가

왜 47개나 넣었는가

첫 동기는 단순했습니다. "어려울 때 쓸 수 있을 법한 것은 전부 넣어두고 싶다"였습니다. Claude Code Skills는 SKILL.md라는 단일 포맷이기에 추가 비용이 거의 제로에 가깝게 보입니다.

게다가 2026년 3월 시점에서 Anthropic 공식 frontend-design Skill은 277,000건 이상의 설치를 기록하고 있으며, 커뮤니티 집약 사이트인 LobeHub의 Agent Skills Marketplace에는 수만 건 규모의 스킬이 나열되어 있습니다. GitHub에 공개된 marketplace 리포지토리만 해도 netresearch/claude-code-marketplace, alirezarezvani/claude-skills(263+), ComposioHQ/awesome-claude-skills 등 수십 개의 리포지토리가 활발하게 업데이트되고 있습니다.

선택지가 너무 많다 보니, 발견하면 닥치는 대로 넣었습니다. 이것이 실수의 시작이었습니다.

47개의 내역: 카테고리별 대표 예시

재고 조사를 해보니 다음과 같은 구성이었습니다.

카테고리	넣은 Skill 예시
코드 리뷰 계열	code-review, security-review, refactor-helper, lint-fixer
Git/PR 조작	gh-cli, pr-summary, branch-protector, conventional-commit
문서화	slide-design, readme-generator, diagram-renderer, blog-writer
검색/RAG	web-search, kg-builder, context-loader, semantic-search
OCR/이미지	screenshot-ocr, figure-extractor, ui-mockup
업무 계열	meeting-notes-summarizer, calendar-glue, gmail-triage
배포/CI	aws-deployer, vercel-pusher, docker-scan
기타 테스트용	tarot, joke-generator, daily-fortune 등

마지막 카테고리를 보면 제가 얼마나 들떠 있었는지 알 수 있습니다.

"tarot이라니, 너 업무에서 뭘 할 생각이었던 거야"라고 과거의 저에게 따지고 싶지만, 당시의 변명은 "재밌게 가보자고"였을 것입니다. 재미로 업무가 진행되지 않는다는 것을 그 후 3개월 동안 뼈저리게 느꼈습니다.

폭주의 이야기: hooks가 hooks를 호출한 밤

전환점은 어느 날 밤 디버깅 중에 찾아왔습니다.

PostToolUse의 hook에서 lint를 수행하는 Skill과, PreCommit에서 test를 실행하는 Skill, 그리고 SaveFile에서 format을 적용하는 Skill. 이 세 가지가 동시에 발화하여, 파일을 저장할 때마다 8초를 기다려야 하는 지옥이 되었습니다.

게다가 format이 코드를 다시 쓰면, lint가 재발화하고, test가 다시 돌아가고, format이 또 돌아갑니다. 여기에 screenshot-ocr이 "이미지가 업데이트되었으니 OCR을 하겠습니다"라며 난입했습니다.

그 당시 저의 Claude Code는 자신의 출력을 스스로 계속해서 다시 쓰는 루프에 빠져 있었고, TPM(Tokens Per Minute)이 평소의 4배로 치솟았습니다.

"47명의 어시스턴트를 고용했다"는 것은 과장이 아닙니다. 47명이 동시에 "제가 하겠습니다"라며 손을 들고 의자를 밀치며 싸우는, 바로 그 광경 자체였습니다.

1차 압축: 30일간 0회 실행되는 것 쳐내기

가장 먼저 한 것은 기계적인 탈락 작업이었습니다. Claude Code의 세션 로그로부터 각 Skill의 실행 횟수를 30일간 집계합니다.

# 세션 로그에서 skill의 호출 횟수를 추출하는 예시
jq -r '.events[] | select(.type=="skill_invoke") | .skill_name' \
~/.claude/sessions/*.json \
...

결과는 잔혹했습니다.

월 20회 이상 호출: 6개
월 5-19회: 6개
월 1-4회: 14개
0회: 21개

즉, 절반 가까이는 설치만 해두고 한 번도 호출되지 않았습니다. tarot가 작동하지 않는 것은 타당하다고 치더라도, aws-deployer조차 0회였습니다. 이유는 단순했습니다. 배포(deploy)는 이미 GitHub Actions에 구현되어 있어, Claude Code에서 호출할 이유가 없었기 때문입니다.

여기서 21개를 한꺼번에 삭제하고, 남은 것은 26개입니다.

2차 선별: 충돌 및 도메인 중복

다음으로 결정적인 문제는 "같은 용도에 여러 개의 Skill이 존재한다"는 점이었습니다.

예를 들어 코드 리뷰(code-review) 계열은 7개를 넣어두었지만, 실제로 호출되었던 것은 code-review와 security-review 2개뿐이었습니다. 나머지 5개는 "비슷한 일을 하지만 미묘하게 다른" 상태였고, 이는 Claude Code가 선택 과정에서 망설이게 만드는 원인이 되었습니다.

선택지가 너무 많으면 Claude가 최적의 Skill을 선택할 수 없습니다. 이는 컨텍스트 엔지니어링 (context engineering)의 기본으로, 도구가 많아질수록 판단 노이즈 (judgment noise)가 증가합니다.

통합 전	통합 후	삭제 이유
code-review, refactor-helper, lint-fixer, formatter, polish-skill	code-review 1개	기능이 80% 중복됨
gh-cli, pr-summary, branch-protector, conventional-commit	gh-cli + pre-push-guard	gh-cli가 PR 계열을 커버함
web-search, semantic-search, context-loader	kg-builder 1개	자신의 KG(Knowledge Graph) 우선

여기서 14개로 압축할 수 있었습니다. 남은 것은 12개. 여기서 한 달을 더 운용해 본 결과, 호출은 되지만 "없어도 큰 지장이 없는" 것들을 7개 더 삭제하여, 최종적으로 5개로 줄였습니다.

남긴 5개와 그 판정 기준

이제부터가 본론입니다. 제가 남긴 5개를 판정 기준 순서대로 나열하겠습니다.

code-review

매일 사용: 판정 기준은 사용 빈도입니다. 주 5회 이상 호출된다면 남기고, 그렇지 않으면 삭제합니다. 이것뿐입니다.

code-review는 커밋(commit) 전에 diff를 던지면 3분 만에 답변이 돌아오는 가벼운 파트너입니다. 무거운 security-review와 분리한 것이 정답이었으며, 매일 사용하는 도구는 가볍지 않으면 지속하기 어렵습니다.

체감상 리뷰를 Skill화한 이후, PR의 지적 사항이 40% 감소했습니다. 리뷰어가 "LGTM"을 누르기까지 걸리는 시간도 체감상 절반으로 줄었습니다. 구체적인 수치는 측정하지 못했으므로, 후회되는 포인트로 남겨둡니다.

secrets-scan

치명적 사고 방지: 판정 기준은 실패 시의 치명도입니다. 한 달에 단 한 번 작동하더라도, 그 한 번으로 회사가 흔들릴 수 있다면 남깁니다.

secrets-scan은 파일 저장 시의 훅 (hook)으로서 작동하며, .env, API 키로 의심되는 문자열, AWS의 access key 패턴을 탐지합니다. 저는 과거에 GitHub에 Stripe 테스트 키를 push했다가 1시간 만에 revoke(권한 취소)당했던 사건을 겪은 적이 있으며, 그 이후로 "순식간에 알아차리는 메커니즘"을 최우선 순위에 두고 있습니다.

피해 규모로 판정하는 카테고리는 절대로 삭제해서는 안 됩니다. 빈도가 낮더라도 피해가 치명적이라면 남깁니다.

pre-push-guard

불가역 작업의 안전장치: 판정 기준은 불가역성입니다. 되돌릴 수 없는 작업에는 반드시 Skill이나 hook을 통해 확인 단계를 거칩니다.

pre-push-guard는 git push --force나 git push origin main을 감지하여, Claude Code에게 "정말로 푸시하시겠습니까?"라고 확인을 요청합니다. Claude Code 자체가 main에 직접 push(direct push)하려고 했던 케이스를 이 도구로 3번이나 막았습니다.

"Claude가 멈추는 것이 아니라, Claude를 멈춘다"는 발상입니다. AI를 신뢰하기 때문에, 오히려 AI가 폭주할 수 있는 경로에 차단막을 설치하는 것입니다.

meeting-notes-summarizer

인지 비용 (Cognitive Cost) 절감: 판단 기준은 자신의 뇌 리소스입니다. 매주 반복하는 작업 중, 머리를 쓰는 데 비해 가치가 낮은 것은 Skill로 만듭니다.

저는 주 4회 정도 온라인 미팅이 있는데, 매번 전사(transcript) 내용을 수동으로 정리하는 것이 번거로웠습니다. 이 Skill은 Zoom/Meet의 전사 데이터를 던지면, 결정 사항과 TODO만 추출하여 Markdown 형식으로 반환합니다.

1회당 8분 절약 × 주 4회 = 월 128분. 이것만으로도 Claude Code Max 플랜의 본전을 뽑을 수 있습니다.

kaori-knowledge

경쟁 부재: 독자적인 도메인(Domain)의 판단 기준은 세상에 대체재가 존재하는가입니다.

저는 향료 회사의 임원도 맡고 있어서, 향료 지식(IFRA 규제, 희석률, 노트 피라미드 구조)을 다루는 도메인 Skill을 직접 제작하고 있습니다. 이는 공식 마켓플레이스(Marketplace)에도 GitHub에도 존재하지 않으며, 오직 제 업무에서만 수요가 있는 지식입니다.

세상에 있는 범용 Skill은 언제 누군가가 상위 호환을 만들지 모릅니다. 반면, 자신만의 도메인 Skill에는 경쟁자가 없으므로 유지보수만 한다면 평생 사용할 수 있습니다. 이것이 가장 '자산화(Assetization)'하기 쉬운 카테고리였습니다.

버린 42개의 전형적인 사례와 그 이유

반대로, 버린 42개의 전형적인 사례를 남겨둡니다.

버린 Skill	버린 주요 원인
slide-design	월 2회 정도만 발표함. CLI로 만들 가치가 낮음
screenshot-ocr	macOS의 표준 OCR로 충분함
kg-builder	context-forge를 직접 호출하는 것이 더 빠름
tarot	(말할 필요도 없음)
aws-deployer	GitHub Actions가 이미 존재함
diagram-renderer	Mermaid를 직접 작성하는 것이 더 빠름
joke-generator	Wit는 내가 직접 말하는 게 더 재밌음

"Skill로 만들 가치가 있는가"는 "자신의 워크플로우에서 매일 사용하는 도구인가"로 판단하는 것이 결론입니다. SNS에서 화제가 된 Skill에 달려들어도, 자신의 업무에 맞지 않는 것은 한 달 안에 사장됩니다.

5개 주의 장점

5개로 압축한 후 관찰된 3가지 변화입니다.

1. 컨텍스트 윈도우 (Context Window)가 가벼워졌다

Claude Code는 실행 시 유효한 Skill의 SKILL.md를 읽어옵니다. 47개였을 때는 실행에만 15,000 토큰 가까이 소모했습니다. 5개가 되면서 2,000 토큰대로 떨어졌고, 매 세션의 비용 체감이 확실히 낮아졌습니다.

2. "어떤 Skill이 작동하고 있는지"를 항상 파악할 수 있다

47개였을 때는 Claude가 무엇을 생각하고 무엇을 호출했는지 추적할 수 없었습니다. 5개라면 로그를 볼 필요도 없이 전부 머릿속에 들어옵니다. 디버깅이 압도적으로 쉬워집니다.

3. 유지보수가 가능해졌다

5개라면 한 달에 한 번 SKILL.md를 리뷰하고 개선할 수 있습니다. 47개일 때는 개선 대상이 너무 많아서 결국 아무도 손대지 않는 방치된 Skill이 대부분이었습니다. 유지보수할 수 없는 자산은 자산이 아니라 부채입니다.

5개 선정을 위한 체크리스트

내일부터 직접 해보실 분들을 위해 판단 플로우를 남깁니다.

[단계 1] 세션 로그에서 30일간의 실행 횟수를 집계
[단계 2] 실행 횟수가 0인 Skill을 모두 삭제
[단계 3] 남은 Skill을 다음 5가지 축으로 평가
...

단계 5가 은근히 중요합니다. 남겨둔 5개도 반년 후에는 다른 5개로 바뀌어 있을 가능성이 있습니다. Skill은 유동 자산으로 취급하여, 반년 단위로 교체해 나갑니다.

Q2 2026의 플러그인(Plugin) 동향과 압축 전략의 보강

2026년 5월 시점에서, Claude Code 본체의 플러그인 메커니즘에도 몇 가지 소소한 개선이 도입되었습니다.

claude plugin disable이 의존 관계를 감지하여, 의존 대상 플러그인의 연쇄 무효화를 제안함
/plugin marketplace browse에 컨텍스트 소비 예측 토큰 수가 표시됨
/skills에 type-to-filter 검색 박스가 추가되어, 긴 리스트에서도 스크롤이 불필요함
플러그인의 zip 배포가 --plugin-dir로 지원됨

특히 주목해야 할 점은 두 번째입니다. Anthropic 공식 측에서 "이 Skill을 추가하면 컨텍스트 (Context)를 이만큼 사용합니다"라고 표시하기 시작했습니다. 이는 "47개를 설치하여 사용"하는 운영 방식에 대한 운영 측의 견제이기도 합니다.

공식 측이 "비용을 보여주는" 방향으로 움직인 이상, 우리 사용자들도 비용에 걸맞은 Skill만 남기는 방향으로 나아가는 것이 도리입니다.

요약: 선별은 기술이 아니라 태도의 문제

47개에서 5개로라는 구체적인 숫자를 제시했지만, 본질은 숫자가 아닙니다.

많으면 많을수록 좋다는 발상을 버린다
자신의 업무에 맞지 않는 Skill은 1개월 안에 삭제한다
경쟁이 적은 자체 제작 Skill을 자산화한다
hooks의 폭주 리스크를 설계 단계에서 고려한다
공식 plugin의 비용 표시를 판단 기준으로 활용한다

도구는 사람을 돕기 위해 존재하는 것이지, 사람이 도구를 돌보기 위해 존재하는 것이 아닙니다. 이는 Claude Code에 국한되지 않고, 모든 도구에 공통적으로 적용되는 이야기라고 생각합니다.

그럼, 즐겁게 시작해 봅시다.