프롤로그 — Skill은 공짜가 아니다
지난 글에서 우리는 Skill을 처음부터 만들었다. SKILL.md, 메타데이터, 예시 입출력, allowed-tools, 폴더 구조까지. 그 글의 메시지는 "필요하면 직접 만들어라"였다.
이번 글은 반대편이다. **이미 잘 만들어진 Skill이 차고 넘친다.** Anthropic 공식 마켓플레이스, 파트너 통합, 커뮤니티 레지스트리에 수백 개의 Skill이 떠 있다. 모두 깔면 좋을까? 절대 아니다.
Skill은 **공짜가 아니다.** 깔린 Skill 하나당:
- 컨텍스트 윈도우의 일부를 차지한다 (적어도 SKILL.md의 메타데이터)
- 에이전트가 매번 "이걸 써야 하나?"를 판단해야 한다 (decision tax)
- 잘못 트리거되면 엉뚱한 일을 한다 (false trigger)
- 업데이트해야 한다 (Skill을 만든 사람이 손을 떼면 stale)
그래서 진짜 어려운 질문은 "**무엇을 깔지**"가 아니라 "**무엇을 깔지 않을지**"다. 200K 컨텍스트는 무한 자원이 아니다. 30개 Skill을 모두 활성화하면 본인의 코드도 못 본다.
이 글은 큐레이션이다. 2026년 5월 현재, **어떤 Skill이 자기 컨텍스트 비용을 정당화하는가**를 카테고리별로 정리한다. 그리고 끝에서 역할별 번들 — Backend·Frontend·SRE·PM·기술 라이터 — 추천을 단다.
1장 · 2026년 Claude Skills 마켓플레이스 지형도
먼저 어디에 무엇이 있는지 정리한다. Skill의 출처는 크게 4가지다.
1-1. Anthropic 공식 마켓플레이스
`anthropic-skills` 플러그인으로 묶인 공식 Skill 묶음. Anthropic이 직접 만들고 유지한다. 2026년 현재 핵심은:
- **docx / pptx / xlsx / pdf** — 오피스 문서 생성·편집·읽기. Word/PowerPoint/Excel/PDF를 직접 다루는 가장 검증된 길.
- **skill-creator** — Skill을 만들거나 고치는 메타 Skill. 첫 Skill 만들 때 거의 필수.
- **consolidate-memory** — 메모리 파일들을 정리하는 Skill. CLAUDE.md가 부풀면 호출.
- **setup-cowork** — Cowork(팀 공유 컨텍스트) 설정 도우미.
이 묶음은 **"의심 가면 켜라"**다. 신뢰도가 높고, 다른 Skill의 기반이 되는 경우가 많다.
1-2. 파트너 통합 Skills
기업 SaaS 벤더가 Anthropic과 협업해서 만든 공식 Skill. OAuth 흐름이 빌트인이고, MCP 서버를 동반한다.
- **Atlassian** (Jira·Confluence): 티켓 생성·검색, 위키 페이지 작성
- **Figma**: 디자인 파일 읽기, 컴포넌트 추출, 디자인 핸드오프 사양 생성
- **Canva**: 디자인 자산 생성·편집
- **Stripe**: (제한된) 결제/구독 데이터 조회 — 트랜잭션 실행은 막혀 있다
- **Notion**: 페이지/데이터베이스 읽기·쓰기
- **Zapier**: Zap 트리거 호출 (수천 개의 통합을 Zapier 한 다리로)
- **Slack**: 채널 메시지 조회, DM, 스레드 작업
- **Linear / Asana / ClickUp / Monday**: 프로젝트 매니지먼트 통합
- **HubSpot / Salesforce-style CRM**: 리드·딜·컨택트 조회
- **GitHub / GitLab**: PR·이슈·코드 워크플로우
파트너 Skill은 **사내 SaaS 스택과 1:1로 맞춰서 깔아야** 한다. 안 쓰는 SaaS의 Skill을 켜두면 false trigger의 온상이다.
1-3. 커뮤니티 마켓플레이스 (GitHub 기반)
`awesome-claude-skills` 같은 큐레이션 레포, 개별 메인테이너의 Skill 레포, 그리고 점점 늘어나는 "스킬 컬렉션" 형태의 plugin. 2026년 현재 잘 알려진 출처:
- **anthropic-cookbook**의 Skills 섹션 — 공식 예제 모음
- **awesome-claude-skills** — 커뮤니티 큐레이션 인덱스
- 개별 메인테이너의 dotfiles 식 Skill — 깃허브 스타가 모이면 신뢰도 신호
핵심 주의: 커뮤니티 Skill은 **출처 검증**이 필수. SKILL.md만 보면 그럴듯하지만 실제로는 `bash` 권한을 광범위하게 요청하는 경우가 있다. 깔기 전에 `allowed-tools` 섹션과 셸 스크립트를 직접 읽자.
1-4. 사내 자체 Skill
가장 가치 있는 카테고리. 회사 안의 워크플로우, 컨벤션, 도메인 지식을 Skill로 만든 것. 외부 Skill로 대체 불가능한 영역(예: "우리 회사 PR 템플릿", "우리 팀 인시던트 응답 절차")이다. 보통 사내 Git 레포로 관리하고 `.claude/skills/`에 심볼릭 링크한다.
이 글은 **외부 Skill의 큐레이션**에 집중한다. 사내 Skill 만드는 법은 지난 글로.
2장 · 코드 리뷰 & PR 워크플로우
엔지니어가 가장 많이 Skill을 켜는 영역. 효과가 가시적이라 ROI도 명확하다.
2-1. PR 요약기 (PR Summarizer)
**무엇:** PR diff를 읽고 "이게 뭐 하는 PR인지" 사람이 읽을 수 있는 요약을 만든다. 보통 PR 본문의 첫 단락으로 넣는다.
**왜 자기 비용을 정당화하나:**
- 코드 리뷰어가 처음 30초에 PR을 이해할 수 있게 도와줌
- "왜?"에 집중한 요약은 diff만 봐서는 안 보임
- 다국어 팀에서 요약이 자동 영문화되면 글로벌 리뷰 활성화
**잘 어울리는 조합:** Conventional commit drafter(아래), security review Skill. 한 PR 안에서 셋이 같이 돌면 "요약 + 커밋 정리 + 보안 체크" 셋업 완성.
**언제 깔지:** PR 본문이 자주 한 줄짜리(`fix bug`)인 팀, PR이 하루 5개 이상 도는 팀.
**언제 안 깔지:** 1인 프로젝트, PR 본문을 어차피 사람이 직접 쓰는 문화의 팀(중복).
2-2. 보안 리뷰 Skill (Security Review)
**무엇:** 일반적인 보안 이슈(SQL injection, XSS, secret leak, IDOR 패턴, 약한 암호화)를 패턴 매칭으로 잡고, 위험 등급과 함께 코멘트 초안을 만든다.
**왜:** 사람 리뷰어는 항상 보안에 집중하지 못한다. "성능 좋네"에 한 번, "테스트 추가하자"에 한 번, 그리고 보안은 흘러간다. Skill은 매번 안 흘린다.
**잘 어울리는 조합:** PR 요약기, Aikido / Snyk 같은 SCA 도구의 MCP. Skill은 1차 그물, SCA는 2차 그물.
**언제 깔지:** 금융·의료·B2B SaaS 등 보안이 비즈니스 리스크인 도메인.
**언제 안 깔지:** 내부용 데모/프로토타입. False positive 피로도가 가치를 상회.
2-3. Conventional Commit 드래프터
**무엇:** 스테이지된 변경(`git diff --staged`)을 보고 Conventional Commits 규약에 맞는 커밋 메시지 후보 2-3개를 제시한다. `feat:`, `fix:`, `refactor:` 같은 타입과 스코프, 변경의 "왜"가 들어간 본문.
**왜:** 좋은 커밋 메시지는 미래의 디버깅·릴리스 노트·체인지로그·`git bisect`의 자원이다. "왜"를 적는 건 사람이 가장 게을러지는 일이고, Skill이 가장 잘 도와주는 일이다.
**잘 어울리는 조합:** Release notes 생성 Skill(아래) — 커밋 메시지가 정돈되면 릴리스 노트 품질도 자동으로 올라간다.
**언제 깔지:** Conventional Commits 규약을 채택했거나 채택하려는 팀.
**언제 안 깔지:** 1인 프로젝트에서 본인이 이미 잘 쓰고 있을 때.
2-4. PR 체크리스트 인포서
**무엇:** 사내 PR 템플릿(테스트 추가됨? 마이그레이션 있음? 롤백 절차? 모니터링 알림?)을 자동으로 채우거나 비어있는 항목을 표시한다.
**잘 어울리는 조합:** 사내 deploy-checklist Skill, 사내 ADR Skill.
**언제 깔지:** PR 템플릿이 길고 자주 비어 있는 팀. 가장 가성비 좋은 Skill 중 하나.
3장 · 릴리스 & 체인지로그
3-1. release-notes-from-git-log
**무엇:** 지난 태그부터 HEAD까지의 커밋을 읽고, 사용자 향 릴리스 노트(`### Added` / `### Fixed` / `### Breaking`)를 만든다. Conventional Commits를 쓰면 정확도가 급격히 오른다.
**잘 어울리는 조합:** Conventional commit drafter(상류), 사내 changelog 포맷 Skill, 그리고 social copy Skill(아래) — 릴리스 노트가 트윗/링크드인 글로 자동 변환.
**언제 깔지:** 격주 이상 릴리스를 도는 팀. 매번 릴리스 노트를 사람이 쥐어짜는 시간이 통계적으로 가장 큰 낭비 중 하나.
**언제 안 깔지:** "Continuous deploy, 노트 없음" 문화.
3-2. semver 판정자 (SemVer Decider)
**무엇:** 변경 목록과 공개 API 스냅샷을 비교해서 다음 릴리스가 `patch`인지 `minor`인지 `major`인지 추천. Breaking change 후보를 별도로 표시.
**왜:** SemVer는 라이브러리 메인테이너의 영원한 골칫거리. 외부 의존자가 있는 라이브러리에서 잘못된 minor 릴리스는 다운스트림 빌드를 다 깬다.
**잘 어울리는 조합:** Public API 추출 Skill, breaking-change detector.
**언제 깔지:** 라이브러리·SDK·공개 API 메인테이너.
3-3. Changelog 마이그레이션 헬퍼
**무엇:** Keep a Changelog 포맷, GitHub Releases 마크다운, 사내 위키 — 같은 변경 정보를 채널별로 다르게 포매팅. 한 번 쓴 릴리스 노트를 세 군데에 자동 복제.
**잘 어울리는 조합:** Notion 통합 Skill, Slack 채널 자동 포스트 Skill.
4장 · 콘텐츠 드래프팅
엔지니어가 글을 안 쓰는 건 못 써서가 아니라 빈 페이지 공포 때문이다. Skill은 그 빈 페이지를 채워준다.
4-1. 블로그 포스트 드래프터
**무엇:** 변경된 코드, 릴리스 노트, 회의록 — 입력 소스를 받아 블로그 포스트 초안을 만든다. 사내 톤·구조 가이드를 따른다.
**잘 어울리는 조합:** Brand voice Skill (아래), Notion 통합(드래프트를 자동 저장).
**언제 깔지:** 개발자 마케팅·DevRel 팀, 또는 회사 블로그를 운영하는 모든 엔지니어링 조직.
**언제 안 깔지:** 글의 진정성이 핵심 자산인 1인 블로거(과의존 위험).
4-2. 체인지로그-소셜 카피 변환기
**무엇:** 릴리스 노트 한 덩이를 트윗 스레드, 링크드인 포스트, 사내 슬랙 공지로 변환. 채널별 톤·길이·해시태그.
**잘 어울리는 조합:** release-notes-from-git-log(상류). 한 파이프라인: git log → 릴리스 노트 → 소셜 카피.
4-3. Brand Voice 인포서
**무엇:** 회사의 톤·문체 가이드(예: "능동태 사용", "느낌표 절제", "불필요한 마케팅 형용사 금지")를 인지하고, 드래프트를 그 톤으로 다듬는다.
**왜:** 여러 사람이 콘텐츠를 만들면 톤이 갈린다. 사람이 항상 톤 가이드를 외울 수 없다. Skill은 외운다.
**잘 어울리는 조합:** 블로그 포스트 드래프터, 마케팅 이메일 드래프터.
4-4. 회의록-블로그 변환기
**무엇:** Granola·Fireflies 같은 회의록 도구의 raw transcript를 받아서, 외부 공개 가능한 블로그 포스트 초안으로 변환. 민감 정보 마스킹 + 톤 다듬기.
**잘 어울리는 조합:** Granola Skill, Brand Voice 인포서.
5장 · 런북 실행 (Runbooks)
SRE·플랫폼·온콜 영역. 실수 한 번이 비싼 영역이라 Skill의 가성비가 가장 높다.
5-1. 인시던트 트리아지 Skill
**무엇:** 들어온 알람의 페이로드를 분석해서 (a) 심각도 분류, (b) 영향 범위 추정, (c) 가까운 과거 유사 인시던트 찾기, (d) 첫 대응 단계 제시. PagerDuty/Datadog/Sentry payload 포맷에 맞춰 동작.
**왜:** 인시던트 초기 5분이 가장 중요하고, 가장 사고가 많이 난다. 잠 깨운 온콜에게 "1) 사용자 N명 영향, 2) 비슷한 인시던트 PD-1234, 3) 첫 단계: A/B 확인"을 자동으로 띄워주는 게 Skill의 진짜 가치.
**잘 어울리는 조합:** PagerDuty Skill, Sentry Skill, 사내 runbook 인덱스 Skill.
**언제 깔지:** 24/7 운영 책임이 있는 팀.
5-2. 온콜 응답 템플릿
**무엇:** "사용자 보고 처음 응대 - 정보 수집 + 침착 응답" / "스테이터스 페이지 첫 업데이트" / "사내 인시던트 채널 첫 메시지" — 각 채널별로 잘 다듬어진 응답 템플릿을 상황에 맞춰 채워준다.
**잘 어울리는 조합:** Slack Skill, Statuspage MCP.
5-3. Runbook 실행 가이드
**무엇:** 사내 runbook(보통 마크다운)을 인지하고, 사람이 "X를 해야 한다"고 하면 해당 runbook을 찾아 단계별로 실행 가이드를 제공. 위험한 단계 전에는 확인 요청.
**잘 어울리는 조합:** AWS / GCP / Azure CLI MCP(아래), Kubernetes Skill.
**언제 깔지:** Runbook이 위키에 잘 정리된 팀. Runbook이 부실하면 Skill이 거짓말함.
5-4. 포스트모템 드래프터
**무엇:** 인시던트 타임라인 raw(Slack 스레드, PagerDuty 이벤트, 배포 로그)를 받아 비난 없는(blameless) 포스트모템 초안을 작성. "5 Whys", "Action Items" 섹션 포함.
**잘 어울리는 조합:** Slack Skill, PagerDuty Skill, Notion Skill.
6장 · 리서치 헬퍼
기술 결정을 내릴 때 자료를 모으는 영역. 잘못 쓰면 시간 도둑, 잘 쓰면 시간 절약기.
6-1. 논문 요약기 (Paper Summarizer)
**무엇:** arXiv PDF나 학회 논문 PDF를 받아서 "1) 문제, 2) 핵심 아이디어, 3) 평가 결과, 4) 한계, 5) 한 줄 요약"의 5섹션 요약을 만든다. 수식은 자연어로 풀어 설명.
**왜:** AI 분야 논문이 일주일에 수백 편 쏟아진다. 사람이 다 못 읽는다. 90초 만에 "이거 깊게 읽을 가치 있는지"를 판단해주는 도구가 필요.
**잘 어울리는 조합:** PDF Skill(공식), Notion 노트 통합.
**언제 깔지:** 리서치 엔지니어, 적용 ML 팀, 기술 의사결정자.
6-2. URL 3개 비교표 생성기
**무엇:** 3개의 경쟁 제품 페이지(예: Drizzle / Prisma / Kysely)를 받아서 feature 비교표를 만든다. 마케팅 광고는 깎고, 객관적 비교 항목으로 정렬.
**잘 어울리는 조합:** Web fetch 도구, 사내 ADR Skill.
**언제 깔지:** 기술 선택을 자주 하는 팀, 벤더 평가가 잦은 팀.
6-3. RFC 비교 Skill
**무엇:** 2-3개 RFC 또는 ADR 문서를 받아서 "공통점·차이점·결정에 필요한 추가 정보" 표를 만든다.
**잘 어울리는 조합:** Notion / Confluence Skill.
7장 · 코드베이스 탐색
새 코드베이스에 합류하거나, 큰 리팩토링을 시작할 때 가장 비싼 비용은 "여기 뭐가 어디 있는지 모름"이다.
7-1. 아키텍처 매퍼 (Architecture Mapper)
**무엇:** 코드베이스를 훑어서 모듈 간 의존 그래프, 데이터 흐름, 외부 시스템 통합 지점, 그리고 "이 시스템의 hot spot 5개"를 마크다운으로 정리.
**왜:** 새 엔지니어 온보딩 첫 주에 가장 필요한 자료. 그런데 손으로 그리면 항상 stale.
**잘 어울리는 조합:** Mermaid 다이어그램 생성기, 사내 ADR Skill.
**언제 깔지:** 큰 모놀리스, 수십 개 마이크로서비스, 또는 레거시 코드 인수받는 상황.
7-2. Dead Code 파인더
**무엇:** import 그래프와 호출 그래프를 분석해서 "다른 어디서도 안 부르는 함수·파일·엔드포인트" 후보를 표시. 동적 import / reflection 케이스는 false positive 가능성도 같이 표시.
**왜:** Dead code는 매번 리뷰어의 인지 자원을 갉아먹는다. 정기적으로 청소하는 팀과 안 하는 팀의 코드베이스 건강도 차이는 1년 뒤에 극명.
**잘 어울리는 조합:** Test coverage 분석 Skill, 사내 refactor 가이드 Skill.
**언제 깔지:** 코드베이스가 2년 이상 살아남은 시점부터.
7-3. 의존성 감사기
**무엇:** `package.json`, `pyproject.toml`, `go.mod` 등을 읽고 (a) 안 쓰는 의존성, (b) 보안 권고, (c) major 버전 업그레이드 후보를 정리.
**잘 어울리는 조합:** Aikido / Snyk MCP.
7-4. 테스트 갭 분석기
**무엇:** 어떤 코드 경로가 테스트로 안 덮였는지, 그리고 "이 경로가 비즈니스적으로 얼마나 중요한지"를 같이 평가해서 테스트 추가 우선순위를 매긴다.
**잘 어울리는 조합:** Coverage 도구(`vitest --coverage`, `pytest-cov`), 사내 critical path 정의 Skill.
8장 · 개인 생산성
내 시간을 가장 직접적으로 돌려주는 카테고리.
8-1. 일일 스탠드업 라이터
**무엇:** 어제의 PR·커밋·완료한 티켓·내일의 캘린더 이벤트를 모아서 "어제·오늘·블로커" 3단 스탠드업 노트를 생성. Slack에 자동 포스트.
**잘 어울리는 조합:** GitHub Skill, Linear / Jira Skill, Slack Skill, Calendar Skill.
**언제 깔지:** 매일 비동기 스탠드업 노트를 적는 팀.
8-2. 회의록-액션아이템 추출기
**무엇:** Granola·Fireflies 등의 회의록 raw를 받아서 액션 아이템만 추출, 담당자·기한 별로 정리. 사용자 확인 후 Linear/Jira로 자동 티켓 생성.
**잘 어울리는 조합:** Granola Skill, Linear Skill.
8-3. 이메일 트리아지 헬퍼
**무엇:** 받은 메일함을 훑어서 "오늘 답해야 함 / 이번 주 / FYI / 무시 가능" 4분류. 답해야 할 것 중 단순한 것은 응답 초안까지.
**잘 어울리는 조합:** Gmail / Outlook 통합.
**언제 안 깔지:** 이메일을 거의 안 보는 직무. 컨텍스트 윈도우 낭비.
8-4. 주간 회고 라이터
**무엇:** 한 주의 PR/커밋/회의록/일정을 모아서 "이번 주 한 것 / 못 한 것 / 다음 주 우선순위" 3섹션 회고를 생성.
**잘 어울리는 조합:** GitHub Skill, Calendar Skill, Notion Skill.
9장 · 파트너 통합 Skills
SaaS 통합은 보통 MCP 서버 + Skill 페어로 온다. MCP는 도구를, Skill은 워크플로우 지식을 제공한다.
9-1. Atlassian (Jira·Confluence)
**무엇:** 티켓 검색·생성·이동, 위키 페이지 읽기·쓰기. Skill은 "버그 티켓 잘 쓰는 법", "릴리스 노트 페이지 만드는 법" 같은 워크플로우 패턴을 안다.
**언제 깔지:** Jira / Confluence를 회사 SoR(Source of Record)로 쓰는 모든 팀.
9-2. Figma
**무엇:** 디자인 파일에서 컴포넌트·스타일·assets 추출, 디자인-개발 핸드오프 사양 자동 생성, 디자인 토큰을 코드 토큰으로 변환.
**잘 어울리는 조합:** Storybook 통합, design system Skill.
**언제 깔지:** 프론트엔드·풀스택 팀, 디자인 시스템 운영팀.
9-3. Canva
**무엇:** 디자인 자산 생성 — 소셜 카드, 발표 슬라이드, 한 페이지 사양서. 텍스트 입력으로 디자인.
**언제 깔지:** 마케팅 팀, DevRel.
9-4. Stripe
**무엇:** 결제·구독·인보이스 데이터 조회. **트랜잭션 실행은 막혀 있다** (의도적 안전장치). "고객 X의 마지막 결제 실패 이유" 같은 조회 워크플로우.
**언제 깔지:** Stripe 데이터를 자주 읽어야 하는 CS·Finance·Eng on-call.
9-5. Notion
**무엇:** 페이지·데이터베이스 읽기·쓰기. Skill은 "회의록 자동 정리", "프로젝트 문서 자동 인덱싱" 같은 워크플로우.
**잘 어울리는 조합:** Granola, Calendar.
**언제 깔지:** 회사 위키가 Notion인 팀.
9-6. Zapier
**무엇:** Zapier의 수천 개 통합을 Zap 트리거로 호출. "Salesforce에 새 lead 생성", "메일침프에 구독자 추가" 같은 동작을 Skill로 노출.
**왜 가치 있나:** 개별 SaaS Skill을 매번 깔지 않아도 Zapier 한 다리로 커버. 단, 응답 시간이 느림.
**언제 깔지:** 다양한 lightweight SaaS 통합이 필요한 마케팅·세일즈 팀.
9-7. Slack / Linear / GitHub
생산성 트라이어드. 거의 모든 엔지니어링 팀의 기본 묶음. 각각의 Skill은 잘 검증되어 있고 안정적.
10장 · 큐레이션 철학 — 컨텍스트 비용 회계
여기서 진짜 어려운 이야기. **Skill을 깔 때마다 우리는 컨텍스트의 일부를 지불한다.** 이건 추상적인 이야기가 아니다.
10-1. Skill의 진짜 비용 3가지
1. **메타데이터 비용** — SKILL.md의 description이 항상 시스템 프롬프트에 들어간다. 200자짜리 description × 30개 Skill = 6,000자.
2. **결정 비용 (decision tax)** — Skill이 많을수록 에이전트가 "어떤 Skill을 쓸까?"를 판단하는 데 토큰을 쓴다. 응답 지연 증가.
3. **False trigger 비용** — 의도 안 한 Skill이 발동되면 잘못된 답을 만든다. 사용자가 디버깅에 시간 씀.
10-2. ROI 매트릭스 — 어떤 Skill이 정당화되는가
| 카테고리 | 사용 빈도 | 작업 가치 | 비용 정당화? |
| --- | --- | --- | --- |
| 인시던트 트리아지 | 낮음(주 1-2회) | 매우 높음(분당 수만 원 손실) | 항상 켜둠 |
| PR 요약기 | 매우 높음(매일) | 중간 | 켜둠 |
| 논문 요약기 | 중간(주 5-10회) | 높음 | 켜둠 |
| 회의록 변환기 | 중간 | 중간 | 조건부 |
| 이메일 트리아지 | 직무별 차이 큼 | 낮음~높음 | 직무 의존 |
| Stripe Skill | 낮음 | 높음(돈) | CS/Finance만 |
규칙은 단순하다: **"이번 주에 한 번이라도 쓸까?"라는 질문에 "아마 아닐 듯"이면 끄자.** 켜두는 Skill은 매주 평균 1회 이상 트리거되어야 한다.
10-3. 켜는 vs 끄는 결정 워크플로우
1. **분기 회고에 Skill 감사 30분을 넣는다.** 분기마다 어떤 Skill이 실제로 발동됐는지 본다.
2. **사용 0회 Skill은 끈다.** "혹시 모르니까"는 안 좋은 이유.
3. **False trigger 빈도가 높으면 description을 다듬거나 끈다.**
4. **사내 Skill > 커뮤니티 Skill > 파트너 Skill > 공식 일반 Skill** 순으로 우선순위 매긴다 (회사 특수성이 높을수록 우선).
10-4. 안티패턴 5가지
1. **"마켓플레이스 다 깔아"** — Skill 30개 짜리 환경은 항상 1개짜리 환경보다 못 한다.
2. **"트렌드 따라 깔기"** — 새 Skill 베타가 떴다고 무작정 추가하지 말 것. 1주 시도 후 정량으로 평가.
3. **"검증 없이 커뮤니티 Skill 신뢰"** — `allowed-tools`와 셸 스크립트 직접 읽지 않으면 깔지 말 것.
4. **"description 충돌 무시"** — 두 Skill의 description이 비슷하면 false trigger 발생. 하나만 남기거나, description을 명확히 구분.
5. **"파트너 Skill을 사내 Skill 대체로 사용"** — 우리 회사 PR 템플릿은 외부 파트너 Skill이 모른다. 회사 특수 워크플로우는 사내 Skill로.
11장 · 역할별 Skill 번들 추천
이상의 정리를 바탕으로, 역할별 추천 묶음. **이게 최종 정답이 아니라 출발점**이다. 자기 팀에 맞춰 조정하라.
11-1. 백엔드 엔지니어 (15개 이하)
핵심: 코드 리뷰 + 릴리스 + 일일 워크플로우.
- 공식: `skill-creator`, `consolidate-memory`
- 코드: PR 요약기, conventional commit drafter, security review
- 릴리스: release-notes-from-git-log, semver decider
- 탐색: 아키텍처 매퍼, dead code 파인더
- 통합: GitHub, Linear/Jira, Slack
- 개인: 일일 스탠드업 라이터
11-2. 프론트엔드 엔지니어 (15개 이하)
핵심: 디자인 핸드오프 + 컴포넌트 검수.
- 공식: `skill-creator`
- 코드: PR 요약기, conventional commit drafter
- 디자인: Figma Skill, design system Skill(사내), brand voice
- 콘텐츠: 체인지로그-소셜 카피
- 통합: GitHub, Linear, Slack, Figma
- 개인: 일일 스탠드업 라이터
11-3. SRE / 플랫폼 엔지니어 (12개 이하)
핵심: 인시던트 + 런북 + 자동화.
- 공식: `skill-creator`, `docx`(포스트모템 자동 생성용)
- 런북: 인시던트 트리아지, 온콜 응답, runbook 가이드, 포스트모템 드래프터
- 통합: PagerDuty, Sentry, Slack, GitHub, AWS/GCP CLI MCP
- 코드: PR 요약기
11-4. PM (10개 이하)
핵심: 회의 + 리서치 + 글쓰기.
- 공식: `pptx`, `docx`
- 리서치: 논문 요약기, URL 3개 비교표
- 콘텐츠: 블로그 드래프터, 브랜드 보이스
- 회의: 회의록-액션아이템 추출기
- 통합: Linear/Jira, Notion, Slack, Figma(공유 읽기)
- 개인: 주간 회고 라이터
11-5. 기술 라이터 / DevRel (10개 이하)
핵심: 콘텐츠 파이프라인.
- 공식: `docx`, `pptx`, `pdf`
- 콘텐츠: 블로그 드래프터, 체인지로그-소셜 카피, 브랜드 보이스, 회의록-블로그 변환기
- 리서치: 논문 요약기, URL 3개 비교표
- 통합: Notion, Canva, Slack, GitHub(release notes)
11-6. 신입 / 온보딩 (5-8개)
핵심: 학습 + 탐색. 처음엔 작게 시작하자.
- 공식: `skill-creator`(언젠가 만들기 시작할 것), `docx`
- 탐색: 아키텍처 매퍼, 의존성 감사기
- 코드: PR 요약기
- 통합: GitHub, Slack
- 개인: 일일 스탠드업 라이터
12장 · 마켓플레이스 미래 — 2026 하반기 전망
마지막으로 짧게, 2026년 5월 시점에서 보이는 흐름.
1. **Skill의 컴포저빌리티가 핵심 가치로 부각.** 단일 거대 Skill보다, 작은 Skill들이 서로를 호출하는 그래프 모델.
2. **파트너 Skill의 SLA화.** 무료 Skill은 자기 컨텍스트 비용을 보장하지 못하면 사용자가 끈다. 유료 파트너 Skill은 "1% false trigger 이하"를 보장하는 형태로 진화.
3. **사내 Skill 호스팅 서비스.** 깃허브 dotfiles 식으로 관리하던 사내 Skill을 사내 plugin 레지스트리로 호스팅하는 서비스 시작.
4. **Skill의 audit log.** Compliance 영역에서 "어떤 Skill이 언제 어떻게 발동했는지" 감사 로그 의무화 시작. SOC2 영향 영역.
5. **Skill 큐레이션의 직무화.** "AI Skill Curator"라는 직무가 큰 조직에서 등장 — 사내 Skill 카탈로그 관리, 외부 Skill 검증, 분기 Skill 감사.
에필로그 — 체크리스트와 다음 글 예고
큐레이션의 본질은 "더하기"가 아니라 "빼기"다. **Skill을 켜는 결정보다 끄는 결정이 더 어렵고 더 가치 있다.** 분기마다 30분 감사를 잡자.
출발 체크리스트
- [ ] 본인의 직무에 맞는 11장의 번들 중 하나를 1주일간 시범 운영
- [ ] 매번 어떤 Skill이 트리거됐는지 메모 (Claude Code에는 자동 로그도 있다)
- [ ] 1주일 후 트리거 0회 Skill은 끄기
- [ ] False trigger가 잦은 Skill은 description 다듬기 또는 끄기
- [ ] 분기마다 Skill 감사 30분을 캘린더에 잡기
- [ ] 회사 특수 워크플로우는 사내 Skill로 만들 것 (외부 대체 불가)
안티패턴 빠르게 다시
1. "마켓플레이스 다 깔아" — 30개 환경은 1개 환경보다 못함
2. "트렌드 따라 깔기" — 1주일 정량 평가 없이 추가 금지
3. "검증 없이 커뮤니티 Skill 신뢰" — allowed-tools와 셸 직접 읽기
4. "description 충돌 무시" — 비슷한 description은 false trigger의 온상
5. "파트너 Skill로 사내 Skill 대체" — 회사 특수성은 외부가 모른다
다음 글 예고
- **사내 Skill 카탈로그 만들기 — Git 레포 구조와 권한 모델**
- **Skill을 위한 평가 시스템 — false trigger 회귀 알림**
- **MCP 서버와 Skill의 역할 분리 — 무엇이 도구이고 무엇이 워크플로우인가**
- **AI Skill Curator라는 새 직무 — 사내 카탈로그 관리자의 하루**
> "Skill은 공짜가 아니다. 컨텍스트 윈도우라는 한정 자원의 일부를 지불해야 한다. 무엇을 깔지 정하는 것보다, 무엇을 깔지 않을지 정하는 것이 더 어렵고 더 가치 있다."
— Claude Skills 마켓플레이스 2026, 끝.
참고 / References
- [Anthropic — Claude Code Skills overview](https://docs.claude.com/en/docs/claude-code/skills)
- [Anthropic — Skill plugins and marketplaces](https://docs.claude.com/en/docs/claude-code/plugins)
- [Anthropic — anthropic-skills plugin (docx/pptx/xlsx/pdf)](https://github.com/anthropics/skills)
- [anthropic-cookbook — examples and skills](https://github.com/anthropics/anthropic-cookbook)
- [awesome-claude-skills — community curation](https://github.com/topics/claude-skills)
- [Atlassian — Jira/Confluence integration](https://www.atlassian.com/blog/announcements/atlassian-ai)
- [Figma — developer plugins and integrations](https://www.figma.com/developers/)
- [Canva — developer docs](https://www.canva.com/developers/)
- [Stripe — MCP integration](https://stripe.com/blog/model-context-protocol)
- [Notion — API and connectors](https://developers.notion.com/)
- [Zapier — MCP and connectors](https://zapier.com/blog/mcp-with-zapier/)
- [Slack — API for AI assistants](https://api.slack.com/ai)
- [Linear — API and integrations](https://linear.app/developers)
- [GitHub — Copilot and AI agent integrations](https://github.com/features/copilot)
- [Conventional Commits specification](https://www.conventionalcommits.org/)
- [Keep a Changelog](https://keepachangelog.com/)
- [Semantic Versioning](https://semver.org/)
- [Granola — meeting notes](https://www.granola.ai/)
- [Fireflies — meeting AI](https://fireflies.ai/)
- [PagerDuty — incident response](https://www.pagerduty.com/)
- [Sentry — error monitoring](https://sentry.io/)
- [Aikido — security scanning](https://www.aikido.dev/)
- [Snyk — dependency security](https://snyk.io/)
- [Model Context Protocol — specification](https://modelcontextprotocol.io/)
현재 단락 (1/249)
지난 글에서 우리는 Skill을 처음부터 만들었다. SKILL.md, 메타데이터, 예시 입출력, allowed-tools, 폴더 구조까지. 그 글의 메시지는 "필요하면 직접 만들어...