스킬을 키우고 나누기
스킬을 키우는 방법은 새 세션에서 실제 일에 써 보며 헤매는 자리를 고치고, 모델이 바뀔 때마다 모델이 이미 아는 지시를 덜어 내는 것입니다. 나눌 때는 원본을 한 곳에 두고 모두가 같은 버전을 받게 합니다. 처음 만든 스킬은 대개 어딘가 어긋납니다. 불려야 할 때 안 불리거나, 불렸는데 규칙 하나를 빠뜨리거나, 참조 파일을 넣어 두었는데 한 번도 열지 않습니다. 이 절에서는 스킬을 쓰면서 고치는 방법, 모델이 바뀔 때 스킬을 덜어 내는 방법, 팀과 나누는 길을 차례로 보고, 이 모든 과정을 지나서도 사람에게 끝까지 남는 것이 무엇인지로 책을 닫습니다.
1. 쓰면서 고친다
공식 모범 사례가 권하는 방법은 Claude 둘을 번갈아 쓰는 것입니다. 한쪽은 나와 함께 스킬을 고치는 Claude이고, 다른 쪽은 그 스킬을 실제 일에 쓰는 새 세션의 Claude입니다. 문서에서는 이 둘을 Claude A, Claude B라고 부릅니다.
새 세션을 쓰는 이유가 중요합니다. 스킬을 만든 그 대화에는 이미 내가 설명한 맥락이 잔뜩 남아 있어서, 스킬 파일에 빠진 내용이 있어도 그 대화 안에서는 티가 나지 않습니다. 스킬만 들고 시작하는 새 세션이어야 빈자리가 드러납니다.
글쓰기실습/이라면 이렇게 됩니다. 새 세션에서 "Git 브랜치를 처음 설명하는 절을 써 줘"라고 시키고, 결과와 과정을 봅니다. 용어집에 있는 표기를 따르지 않았다면, 그 장면을 들고 원래 대화로 돌아가 "B가 브랜치를 '가지'라고 썼어. 용어집은 읽었는데 본문 단계에서 다시 안 본 것 같아. 어디를 고칠까?"라고 묻습니다. 고칠 자리를 찾는 일까지 Claude에게 맡길 수 있습니다.
1.1 무엇을 관찰하나
공식 모범 사례는 Claude B가 스킬을 어떻게 돌아다니는지 보라고 합니다. 볼 곳은 네 가지입니다.
- 예상 밖의 순서: 내가 생각한 것과 다른 순서로 파일을 읽는다면 폴더 구조가 생각만큼 직관적이지 않다는 신호입니다.
- 놓친 연결: 중요한 참조 파일을 열지 않는다면
SKILL.md의 링크가 더 분명해야 합니다. - 같은 파일만 거듭 읽기: 매번 여는 파일이 있다면 그 내용은
SKILL.md본문으로 올리는 편이 낫습니다. - 한 번도 안 여는 파일: 필요 없는 파일이거나, 본문에서 제대로 안내하지 못한 파일입니다.
1.2 증상별로 고칠 곳
관찰한 증상은 대개 고칠 자리가 정해져 있습니다.
| 증상 | 고칠 곳 |
|---|---|
| 불려야 할 때 안 불림 | description에 사용자가 실제로 쓰는 말과 '언제 쓰는지'를 넣기 |
| 엉뚱한 일에 불림 | description을 좁히기. 다른 스킬과 겹치는 말 빼기 |
| 불렸는데 규칙 하나를 빠뜨림 | 그 규칙을 본문 앞쪽으로 옮기거나 진행 순서의 한 단계로 넣기 |
| 참조 파일을 안 엶 | 본문에서 언제 그 파일을 볼지 링크와 함께 적기 |
| 결과가 매번 흔들림 | 판정할 수 있는 부분을 scripts/의 스크립트로 내리기 |
| 지시를 지키는데 결과가 밋밋함 | 설명을 더하기보다 assets/에 좋은 예시 하나 넣기 |
마지막 두 줄은 공식 모범 사례가 말하는 자유도 이야기와 같습니다. 양옆이 낭떠러지인 좁은 다리에서는 정확한 지시와 정해진 스크립트를 주고, 장애물 없는 넓은 들판에서는 방향만 주고 길은 Claude에게 맡기라는 비유입니다. 글쓰기실습/이라면 분량과 금지 표현은 좁은 다리라 check.sh가 맡고, 비유를 고르고 설명 순서를 정하는 일은 넓은 들판이라 예시 하나와 방향 몇 줄이면 충분합니다.
여러 요청을 정해 두고 스킬이 있을 때와 없을 때를 숫자로 비교하는 일은 07-2에서 본 skill-creator와 claude plugin eval이 맡습니다. 관찰로 고칠 자리를 찾고, 평가로 고친 것이 정말 나아졌는지 확인하는 순서입니다.
2. 모델이 바뀌면 덜어 낸다
이 책의 질문으로 돌아가 보면, 모델이 좋아질 때 스킬에도 일어나는 일이 있습니다. 지시는 줄어들고, 맥락은 그대로 남습니다.
| 모델이 좋아질수록 줄어드는 것 | 모델이 바뀌어도 그대로인 것 |
|---|---|
| 일반적인 글쓰기·코딩 요령 설명 | 회사 정보, 단가표, 용어집 |
| "먼저 계획을 세우고" 같은 단계 주문 | 로고, 서식, 템플릿 같은 에셋 |
| 모델이 이미 아는 도구 사용법 | 검사 스크립트와 판정 기준 |
| 예전 모델의 실수를 막던 문장 | 좋은 결과의 예시, 지난 지적 |
공식 모범 사례도 스킬은 모델에 더해지는 것이라 효과가 모델에 따라 다르다고 설명합니다. Opus에서 잘 되는 스킬이 더 작은 모델에서는 설명이 더 필요할 수 있고, 반대로 큰 모델에게는 지나친 설명이 될 수 있습니다. 그래서 새 모델로 바꾼 뒤에는 스킬을 한 번 다시 봅니다. Claude Code에는 이 일을 돕는 명령이 있습니다.
| 명령 | 하는 일 |
|---|---|
/doctor prompt-audit | CLAUDE.md, 스킬, 서브에이전트 같은 지시 파일에서 예전 모델을 위해 쓴 지시, 없는 파일이나 명령을 가리키는 내용, 서로 어긋나는 내용을 찾아 고칠 안을 보여 줌 |
/skill-doctor | 스킬마다 컨텍스트를 얼마나 차지하고 얼마나 자주 쓰이는지 보여 줌 |
/skills | 쓸 수 있는 스킬 목록. 토큰 크기 순으로 정렬하고, 스킬마다 Claude에게 보일지 정할 수 있음 |
/doctor prompt-audit는 찾은 내용을 보고서로만 보여 주고, 내가 적용하라고 하기 전에는 파일을 바꾸지 않습니다. 버전에 따라 없는 명령도 있으니 / 메뉴에서 먼저 확인합니다.
날짜에 묶인 내용도 이때 정리합니다. 09-2에서 말했듯 "8월 전에는 옛 방식" 같은 문장은 시간이 지나면 틀린 지시가 됩니다. 지금 기준만 본문에 남기고 지난 기준은 접어 둡니다.
3. 팀과 나눈다
스킬을 팀에 나누는 길은 07-1에서 자세히 봤습니다. 짧게 다시 모으면 세 갈래입니다.
- 저장소에 커밋하기: 한 저장소에서 일하는 팀이라면
.claude/skills/에 넣고 커밋하는 것으로 충분합니다. - 플러그인으로 묶기: 여러 저장소에서 같은 스킬 묶음을 쓴다면 플러그인으로 묶고 마켓플레이스로 나눕니다.
- claude.ai에서 공유하기: 터미널을 쓰지 않는 팀원이 섞여 있다면 Team·Enterprise 요금제의 Customize > Skills에서 공유하거나 조직에 게시합니다. 받은 사람은 켜서 쓰고, 고치는 일은 만든 사람이 합니다.
어느 길이든 원칙은 하나입니다. 원본은 한 곳에 두고, 모두가 같은 버전을 받습니다. 그리고 받는 쪽에서는 스킬을 소프트웨어처럼 다룹니다. 공식 문서는 스킬이 지시와 코드를 함께 담기 때문에, 믿을 수 있는 곳에서 온 스킬만 쓰고 남이 만든 스킬은 SKILL.md와 스크립트, 함께 든 파일까지 살펴본 뒤 켜라고 권합니다.
4. 끝까지 사람에게 남는 것
이제 1장의 질문에 이 책의 답을 적을 수 있습니다. 지능이 높아질수록 요령은 모델 안으로, 장치는 제품 안으로 들어갔습니다. 그 뒤에도 남는 것은 세 가지입니다.
원하는 것: 무엇을 왜 만들지는 사람이 정합니다. 스킬로 치면 어떤 일을 스킬로 만들지 고르는 일, 그리고 description에 '언제 쓰는지'를 적는 일입니다. 모델은 그럴듯한 선택지를 많이 보여 줄 수 있지만 그중 하나를 원하는 일은 대신하지 못합니다.
판단: 결과가 원하는 것과 맞는지, 이대로 내보내도 되는지, 그 결과에 누가 책임지는지는 사람의 몫입니다. 판단 기준 가운데 기계가 볼 수 있는 부분은 검사 스크립트로 내려 스킬에 넣을 수 있지만, 기준을 세우는 일과 마지막에 내보내는 결정은 남습니다. 스킬에 담기는 것은 어제까지의 판단이고, 오늘 처음 생긴 상황은 여전히 사람이 봅니다.
맥락: 세상에 없는 정보입니다. 회사 정보, 서식, 로고, 고객 이야기, 팀의 용어, 지난번에 틀렸던 자리. 이 세 가지 가운데 쌓아서 다시 쓸 수 있는 것이 맥락이고, 지금 그 맥락이 쌓이는 자리가 스킬입니다.
이 고리를 한 바퀴 돌 때마다 다음 일은 더 적은 말로 시작됩니다. 같은 설명을 다시 하지 않아도 되고, 같은 실수를 다시 지적하지 않아도 됩니다. 모델이 바뀌면 지시를 덜어 내고, 맥락은 그대로 들고 다음 모델로 갑니다.
4.1 오늘 시작하는 순서
거창하게 시작할 필요는 없습니다. 스킬 하나면 됩니다.
- 이번 주에 세 번 이상 같은 설명을 한 일을 하나 고릅니다.
- 그 일을 스킬 없이 Claude와 한 번 끝까지 해 봅니다.
- 끝나면 "방금 한 일을 스킬로 만들어 줘. 네가 이미 아는 설명은 빼고"라고 부탁합니다.
- 세상에 없는 자료, 곧 서식, 회사 정보, 좋은 예시, 로고를
references/와assets/에 넣습니다. - 새 세션에서 실제 일에 써 보고, 1.2의 표대로 고칩니다.
- 기계로 확인할 수 있는 기준이 보이면
scripts/에 검사 스크립트로 내립니다. - 쓸 만해지면 팀과 나눕니다.
이 책을 따라오며 만든 글쓰기실습/ 폴더가 있다면 거기서 시작해도 됩니다. write-section 스킬에 우리 팀의 용어집 한 장, 잘 쓴 원고 한 편을 넣고 새 세션에서 한 절을 맡겨 보세요. 결과가 흔들리는 자리가 보이면 그 자리가 다음에 스킬에 더할 맥락입니다.
- 스킬 작성 모범 사례: https://platform.claude.com/docs/en/agents-and-tools/agent-skills/best-practices
- Agent Skills 개요와 보안 고려 사항: https://platform.claude.com/docs/en/agents-and-tools/agent-skills/overview
- Claude Code 스킬 문서: https://code.claude.com/docs/en/skills
- Claude Code 명령어 목록: https://code.claude.com/docs/en/commands
- Claude Code 메모리 문서의 지시 파일 점검: https://code.claude.com/docs/en/memory
- Claude Code 플러그인 개요: https://code.claude.com/docs/en/plugins
- Claude에서 스킬 쓰기: https://support.claude.com/en/articles/12512180-use-skills-in-claude