🍑 심화(LV30)#Claude Code Skill#클로드 코드 스킬#Claude Code#클로드 코드#슬래시 커맨드#SKILL.md#반복 업무 자동화#바이브코딩
9분·2026. 4. 24.·조회 8
오늘도 AI 한입 하세요 🍊
새 아티클이 발행되면 이메일로 알려드릴게요.
댓글을 남기려면 로그인이 필요합니다.
아직 댓글이 없습니다. 첫 댓글을 남겨보세요!
클로드 코드에서 매번 같은 프롬프트를 복붙하고 계신가요? 슬래시 커맨드로 단축키처럼 줄이고, 복잡한 작업은 스킬로 묶어 AI가 알아서 호출하게 만드는 법을 한 번에 정리했습니다.
클로드 코드(Claude Code)에게 매번 '이 프로젝트는 이렇고, 답변은 이렇게...' 반복 설명하고 계신가요? CLAUDE.md 파일 하나면 한 번만 세팅하고 끝입니다. 비개발자도 5분이면 따라할 수 있는 CLAUDE.md 설정법과 실전 템플릿, 웹에서 쓰는 Claude Projects까지 한 번에 정리했습니다.
터미널 뜻, CLI란 무엇인지부터 맥 터미널 여는 법, 첫 명령어 실습까지. Claude Code, Codex 같은 AI 도구를 쓰려면 터미널을 알아야 합니다.
클로드 코드(Claude Code)가 파일 수정할 때마다 Yes를 물어봐서 답답하다면, 권한 자동 허용(bypassPermissions)을 켜면 됩니다. 설정법부터 Shift+Tab 전환, 위험성, plan mode 활용, settings.json 영속화까지 한 글로 끝냅니다.
Supabase(수파베이스)는 RLS를 안 켜면 모든 사용자 데이터가 노출됩니다. 아파트 택배함 비유로 RLS 보안 설정을 쉽게 이해하고, 왜 반드시 켜야 하는지 알아봅니다.
옵시디언(Obsidian) MCP 설정, 사실은 간단합니다. 클로드 코드(Claude Code)를 볼트 폴더에서 실행하면 AI가 내 노트를 직접 읽고 씁니다. 3단계 연결 방법과 실제 활용 예시를 정리했습니다.
클로드 코드 사용량을 /context와 /usage 명령어로 진단하고, 토큰이 빨리 소진되는 원인을 분석해 비용을 아끼는 실전 팁까지 정리합니다. 서브에이전트 남용·긴 세션 등 리밋이 걸리는 패턴별 대응법과 요금제 비교 포함.
엑셀 함수도, 매크로도, 파이썬도 배울 필요가 없습니다. 터미널에서 Claude Code를 열고 엑셀 파일을 넘긴 다음 하고 싶은 일을 말로 설명하면, 파일을 직접 읽고 수정하고 저장까지 해줍니다. 실전 예제 3가지로 보여드립니다.
둘 다 AI인데 어떻게 다를까요? 코딩, 글쓰기, 분석 등 상황별로 어떤 AI를 선택해야 하는지 실전 비교로 정리했습니다.
클로드 코드(Claude Code)를 일주일쯤 써보신 분이라면 아마 공감하실 겁니다. 커밋 한 번 하려고 매번 같은 문장을 칩니다.
"지금까지의 변경사항을 한글 커밋 메시지로 작성해줘. 메시지에 'AI', 'Claude', 'Co-Authored-By' 같은 흔적은 빼고. 이모지도 쓰지 말고. 변경 이유를 한 줄 더 추가해줘."
세 번째쯤 반복할 때 피로감이 옵니다. CLAUDE.md에 규칙을 써둬도 클로드가 미묘하게 다르게 실행합니다. 어떤 때는 이모지를 붙이고, 어떤 때는 영어가 섞이고, 어떤 때는 이유 설명을 빼먹습니다.
결론부터 말씀드리면 이 반복을 한 단어로 끝낼 수 있습니다. 내 전용 클로드 코드 스킬(Claude Code Skill)을 하나 만들어서 ~/.claude/skills/commit/SKILL.md에 저장해두면, 그 다음부터는 대화창에 /commit만 치면 됩니다. 한 번 만들어두면 영원히 같은 규칙으로 커밋이 만들어집니다.
이 글에서는 스킬이 정확히 뭐고 왜 생겼는지, 가장 기본적인 /commit 스킬을 5분 안에 만드는 법, /pr, /deploy 같은 실전 업무 스킬 레시피, 그리고 $ARGUMENTS와 쉘 실시간 주입 같은 고급 기능까지 한 번에 정리하겠습니다.
CLAUDE.md와 스킬은 어떻게 다른가요 이 글은 CLAUDE.md를 한 번이라도 써보셨다는 전제로 시작합니다. CLAUDE.md가 뭔지부터 궁금하시다면 아래 글을 먼저 읽고 오셔도 됩니다. 👉 클로드 코드에게 매번 설명하기 귀찮다면 — CLAUDE.md 설정법
2026년 기준, 커스텀 슬래시 커맨드는 스킬로 통합되었습니다
클로드 코드 자료를 검색하다 보면 두 가지 용어가 혼용됩니다. 커스텀 슬래시 커맨드와 스킬(Skill). 예전 글들은 "커스텀 커맨드를 .claude/commands/deploy.md 파일로 만들라"고 안내했고, 최신 글들은 ".claude/skills/deploy/SKILL.md 디렉터리로 만들라"고 안내합니다. 헷갈리실 만합니다.
공식 문서의 결론은 단순합니다.
"Custom commands have been merged into skills." —
.claude/commands/deploy.md파일과.claude/skills/deploy/SKILL.md디렉터리는 둘 다 동일한/deploy슬래시 명령을 만들고, 동작도 같습니다. 기존.claude/commands/파일은 그대로 둬도 계속 작동합니다.
즉 슬래시 커맨드는 스킬의 가장 단순한 형태이고, 스킬은 슬래시 커맨드를 포함해서 추가 기능(보조 파일, 자동 호출 제어, 서브에이전트 실행)을 얹은 상위 개념입니다. 새로 만드실 거라면 스킬 형식이 권장됩니다. 이 글에서도 스킬 형식을 기준으로 설명하겠습니다.
실제로 바뀐 건 두 가지뿐입니다.
.claude/commands/<이름>.md → .claude/skills/<이름>/SKILL.mdSKILL.md + 필요하면 보조 파일)내용 형식(YAML frontmatter + 마크다운 본문)은 동일합니다. 예전 스타일 파일이 있다면 그대로 두셔도 되고, 시간 날 때 하나씩 스킬 디렉터리 구조로 옮기시면 됩니다. 같은 이름이 양쪽에 있으면 스킬 쪽이 우선합니다.
/commit 만들기폴더 하나 + 파일 하나로 끝납니다
말로만 설명하면 감이 안 오니 직접 만들어보겠습니다. 목표는 내 커밋 규칙을 한 단어로 끝내는 /commit 스킬을 만들어서, /commit만 치면 자동으로 한글 커밋 메시지가 생성되도록 하는 겁니다. 총 세 단계면 끝납니다.
개인용 스킬은 홈 폴더 안의 .claude/skills/ 밑에 만듭니다. 터미널에서 아래 한 줄을 실행하면 됩니다.
mkdir -p ~/.claude/skills/commit
mkdir -p가 뭔가요mkdir은 폴더 만들기 명령이고, 뒤에-p를 붙이면 "경로 중간 폴더가 없어도 자동으로 만들어주고, 이미 있으면 그냥 넘어간다"는 뜻입니다. 안전하게 쓸 수 있는 옵션이라 걱정 없이 실행하셔도 됩니다.
SKILL.md 파일을 작성합니다방금 만든 폴더 안에 SKILL.md라는 이름으로 파일을 만듭니다. 아무 편집기(VS Code, nano, 옵시디언)로 열어서 아래 내용을 붙여넣고 저장합니다.
---
name: commit
description: 현재 변경사항을 한글 메시지로 커밋합니다. 커밋해줘, commit, 커밋하자 같은 요청을 받으면 사용하세요.
disable-model-invocation: true
allowed-tools: Bash(git add *) Bash(git commit *) Bash(git status *) Bash(git diff *)
---
현재 스테이징되지 않은 변경사항을 포함해 커밋을 만듭니다.
## 실행 순서
1. `git status`와 `git diff`로 변경사항을 확인합니다.
2. 변경 성격을 파악합니다 (기능 추가, 버그 수정, 리팩토링 등).
3. 한글 커밋 메시지를 작성합니다.
4. `git add .`와 `git commit`을 실행합니다.
## 메시지 규칙
- 제목은 한 줄로 간결하게, 변경 성격 + 대상 순서로 적습니다.
- 본문은 한두 문장으로 변경 이유(왜)를 설명합니다.
- 다음 단어는 절대 포함하지 않습니다: `Claude`, `Anthropic`, `AI`, `Co-Authored-By`, 🤖
- 이모지 사용 금지.---로 둘러싼 윗 부분을 YAML frontmatter라고 부르고, 스킬의 메타데이터를 적는 영역입니다. 일단 세 줄만 기억하시면 됩니다.
name: 스킬 이름입니다. 이 값이 그대로 /commit 슬래시 명령이 됩니다. 영소문자·숫자·하이픈만 허용되고 한글은 안 됩니다.description: 클로드가 "이 스킬을 언제 써야 하는지" 판단할 때 참고하는 설명입니다. 자연어로 쓰시고, 트리거가 될 만한 표현("커밋해줘", "commit")을 같이 넣어두면 자동 호출 확률이 올라갑니다.disable-model-invocation: true: 클로드가 알아서 이 스킬을 실행하지 못하게 막습니다. 즉 내가 /commit을 직접 쳤을 때만 실행됩니다. 배포·커밋·PR처럼 부작용이 있는 작업에는 이 옵션을 켜두는 편이 안전합니다.--- 아래는 평범한 마크다운입니다. 클로드가 스킬 실행 시 이 내용을 그대로 지시사항으로 읽습니다.
allowed-tools로 매번 묻는 권한 창을 끌 수 있나요allowed-tools에 적은 명령은 스킬이 활성화된 동안 별도 확인 창 없이 바로 실행됩니다. 클로드 코드가 매번 띄우는 "이거 해도 될까요?" 창 자체가 거슬리신다면 권한 모드를 먼저 한 번 정리하고 가시는 편이 좋습니다. 👉 클로드 코드 매번 Yes 묻는 거 끄는 법 — 권한 자동 허용 완벽 설정
이 파일을 저장하시고 클로드 코드를 다시 실행(혹은 열려 있던 세션에서 그대로) 시키신 뒤, 대화창에 아래처럼 치시면 됩니다.
/commit
끝입니다. / 슬래시를 치는 순간 자동완성에 /commit이 뜨고, 선택해서 엔터를 누르면 방금 쓴 SKILL.md 지시사항대로 git status를 확인하고 한글 커밋 메시지를 만들어줍니다. 내일 아침 새 터미널을 열어도 똑같이 동작합니다.
스킬 파일은 실시간으로 반영됩니다 클로드 코드는
~/.claude/skills/와 프로젝트의.claude/skills/폴더를 계속 감시합니다. 스킬을 수정하거나 추가하시면 현재 세션에서 즉시 반영되니 세션 재시작은 필요 없습니다. 단, 스킬 디렉터리 자체가 세션 시작 시점에 없었다면 이때만큼은 한 번 재시작해야 감시 대상으로 잡힙니다.
공통 업무는 홈 폴더, 프로젝트 특화는 저장소 안에
스킬을 저장할 수 있는 위치는 크게 두 군데입니다. 어디에 두느냐에 따라 쓸 수 있는 범위가 달라집니다.
| 위치 | 경로 | 쓸 수 있는 범위 |
|---|---|---|
| 개인용 (Personal) | ~/.claude/skills/<이름>/SKILL.md | 내 컴퓨터의 모든 프로젝트 |
| 프로젝트용 (Project) | <프로젝트 폴더>/.claude/skills/<이름>/SKILL.md | 그 프로젝트에서만 |
개인용에는 커밋 규칙, PR 생성, 이슈 정리 같은 모든 프로젝트에 공통으로 쓰는 스킬을 둡니다. 방금 만든 /commit 스킬이 여기 해당합니다.
프로젝트용에는 그 프로젝트에만 맞는 스킬을 둡니다. 예를 들어 Vercel에 배포하는 Next.js 프로젝트라면 /deploy 스킬에 "Vercel CLI로 production 배포", "배포 후 프로덕션 URL 200 응답 확인" 같은 이 프로젝트 전용 절차가 들어갑니다. 이걸 저장소 루트의 .claude/skills/deploy/SKILL.md에 두시면 됩니다.
팀원과 공유하고 싶으시면 프로젝트용이 훨씬 편리합니다. .claude/skills/ 폴더를 git에 커밋만 하면, 저장소를 받아가는 모든 팀원이 동일한 스킬을 쓰게 됩니다. 팀이 커밋 규칙을 맞추거나 배포 체크리스트를 통일할 때 이 방식이 특히 유용합니다.
같은 이름 스킬이 두 위치에 모두 있으면 개인용이 우선합니다. 내 로컬 덮어쓰기가 팀 설정보다 강합니다. 기억하시면 될 단 하나의 규칙입니다.
/pr, /deploy, /refactor가장 자주 만드는 세 가지를 그대로 가져다 쓰세요
첫 스킬을 만들어보셨다면 감이 잡히실 겁니다. 같은 패턴으로 자주 하는 반복 업무를 서너 개 만들어두시면, 하루 작업 시간이 눈에 띄게 줄어듭니다. 실전에서 가장 먼저 만들 만한 세 개를 소개하겠습니다.
/pr — 바로 머지 가능한 PR 만들기커밋 여러 개를 쌓아뒀다가 한 번에 PR을 올릴 때, 매번 제목과 본문을 고르는 게 일입니다. 이 절차를 스킬로 만듭니다.
---
name: pr
description: 현재 브랜치에서 PR을 생성합니다. 제목은 브랜치의 핵심 변경을 요약하고 본문은 변경 내역과 테스트 플랜을 담습니다.
disable-model-invocation: true
allowed-tools: Bash(git *) Bash(gh pr *)
---
현재 브랜치와 기본 브랜치(main 또는 dev)를 비교해 PR을 만듭니다.
## 실행 순서
1. `git log origin/main..HEAD`로 포함될 커밋을 모두 확인합니다.
2. `git diff origin/main...HEAD --stat`으로 변경 파일 범위를 파악합니다.
3. 아래 규칙대로 제목과 본문을 작성합니다.
4. `gh pr create --title "..." --body "..."`로 PR을 올립니다.
## 제목 규칙
- 70자 이내. 브랜치 이름에 있는 핵심 키워드를 포함합니다.
- 변경 성격 접두어(chore, feat 등) 금지.
## 본문 구성
## 요약
1~3개 불릿으로 주요 변경.
## 테스트 플랜
- [ ] 리뷰어가 직접 확인할 체크리스트/deploy — Vercel 프로덕션 배포와 검증까지이 스킬은 프로젝트용으로 만드는 게 좋습니다. Vercel Deploy Hook URL이나 검증용 프로덕션 URL이 프로젝트마다 다르기 때문입니다. 저장소 루트에서 mkdir -p .claude/skills/deploy를 친 뒤 아래 내용을 SKILL.md에 저장합니다.
---
name: deploy
description: main 브랜치의 현재 커밋을 Vercel 프로덕션으로 배포하고 상태를 확인합니다.
disable-model-invocation: true
allowed-tools: Bash(curl *) Bash(git *) Bash(gh run *)
---
## 실행 순서
1. 현재 브랜치가 main인지 확인합니다. 아니면 중단.
2. `git push origin main`으로 최신 커밋을 올립니다.
3. Vercel Deploy Hook을 호출합니다.
4. 3분 대기 후 프로덕션 URL 200 응답을 확인합니다.
5. 응답이 200이 아니면 에러를 보고하고 롤백 절차를 안내합니다./refactor — 리팩토링 요청을 규칙대로 실행이건 결이 조금 다릅니다. 부작용 없는 리팩토링은 클로드가 알아서 호출해도 큰 문제가 없기 때문에 disable-model-invocation을 쓰지 않습니다. description에 트리거 표현만 풍부하게 넣어둡니다.
---
name: refactor
description: 함수 또는 파일 단위로 리팩토링을 수행합니다. "리팩토링 해줘", "이 함수 정리해줘", "중복 제거" 같은 요청 시 사용하세요.
allowed-tools: Read Edit Grep
---
리팩토링 대상을 받으면 다음 순서로 처리합니다.
1. 대상 코드의 호출부를 Grep으로 먼저 찾습니다.
2. 호출부 시그니처를 바꿔야 한다면 범위를 보고하고 확인을 받습니다.
3. 이름 변경은 심볼 단위로 일괄 처리합니다.
4. 수정 후 타입체크와 테스트를 실행합니다.description에 독자가 실제로 칠 만한 표현("리팩토링 해줘", "중복 제거")을 여러 개 넣어두시면, 클로드가 그 표현을 듣는 순간 스킬을 자동으로 호출할 확률이 올라갑니다.
항상 적용되는 규칙은 CLAUDE.md, 필요할 때만 호출되는 절차는 스킬
CLAUDE.md와 클로드 코드 스킬 둘 다 "내 규칙을 클로드에게 주입"하는 수단입니다. 그래서 언제 뭘 써야 할지 헷갈리기 쉽습니다. 판단 기준은 단순합니다.
| 기준 | CLAUDE.md | 스킬 |
|---|---|---|
| 언제 적용되나 | 항상 — 세션 시작 때마다 자동 로드 | 호출할 때만 — /이름 또는 클로드 자동 판단 |
| 컨텍스트 사용 | 매번 소모 | 호출 전까진 description만, 본문은 호출 시 로드 |
| 적합한 내용 | 사람·프로젝트 정체성, 말투, 공통 규칙 | 커밋, PR, 배포 같은 구체적 절차 |
| 수정 주기 | 거의 안 바뀜 | 자주 바뀌어도 OK |
핵심은 컨텍스트 비용입니다. CLAUDE.md는 대화 시작마다 전부 읽히기 때문에 길어질수록 클로드의 주의력이 분산됩니다. 반면 스킬은 description만 상주하고 본문은 호출 시점에만 메모리에 올라갑니다. 매번 지켜야 할 규칙은 CLAUDE.md에, 가끔 돌리는 절차는 스킬로 나누시면 기억 관리가 깔끔해집니다.
실전에서는 이렇게 정리됩니다.
/commit(커밋 절차), /pr(PR 만들기), /deploy(배포 절차) — 가끔 돌릴 것CLAUDE.md가 점점 길어지면서 절차 설명처럼 읽히는 섹션이 생긴다면, 그 섹션은 스킬로 옮길 신호입니다. CLAUDE.md는 짧고 선언적인 규칙만 남기시는 편이 장기적으로 유리합니다.
$ARGUMENTS,!`명령어`, 보조 파일
여기까지 따라오셨다면 스킬의 80%는 다 쓴 겁니다. 남은 20%가 스킬을 정적인 "메모장"에서 살아있는 도구로 바꿉니다.
$ARGUMENTS스킬 이름 뒤에 내가 입력한 값을 본문에서 쓰고 싶을 때가 있습니다. 예를 들어 /fix-issue 123처럼 이슈 번호를 넣어서 호출하는 식입니다.
---
name: fix-issue
description: GitHub 이슈를 수정합니다.
disable-model-invocation: true
allowed-tools: Bash(gh *)
---
GitHub 이슈 #$ARGUMENTS를 수정합니다.
1. `gh issue view $ARGUMENTS`로 이슈를 읽습니다.
2. 요구사항을 파악합니다.
3. 수정 + 테스트 + 커밋까지 진행합니다.$ARGUMENTS는 스킬 뒤에 붙인 문자열 전체로 치환됩니다. /fix-issue 123을 실행하면 본문의 $ARGUMENTS가 모두 123으로 바뀐 채 클로드에게 전달됩니다.
인자가 여러 개라면 $ARGUMENTS[0], $ARGUMENTS[1] 같은 위치 기반으로도 쓸 수 있고, 더 짧게 $0, $1로도 씁니다.
/migrate-component SearchBar React Vue
→ 본문의 $0은 SearchBar, $1은 React, $2는 Vue로 치환됩니다.
!`명령어`스킬이 실행될 때 쉘 명령을 먼저 돌리고 그 결과를 본문에 집어넣을 수 있습니다. 백틱 한 쌍 앞에 느낌표를 붙이는 !`명령어` 문법입니다.
---
name: pr-summary
description: 현재 PR을 요약합니다.
allowed-tools: Bash(gh *)
---
## PR 컨텍스트
- 변경 diff: !`gh pr diff`
- 리뷰 코멘트: !`gh pr view --comments`
- 수정된 파일: !`gh pr diff --name-only`
## 작업
위 컨텍스트를 바탕으로 이 PR을 요약하세요.클로드가 이 스킬을 실행할 때, 첫 단계에서 !`gh pr diff` 같은 명령들이 먼저 실행되고 결과가 본문 해당 자리에 삽입된 상태로 클로드에게 전달됩니다. 클로드는 자기가 명령을 치는 게 아니라, 이미 실행된 결과를 읽고 답만 합니다.
대화창에서 매번 "먼저 이거 실행하고 저거 실행해서 결과를 봐야 해"를 설명할 필요가 없어집니다. 살아있는 컨텍스트를 프리앰블로 미리 주입하는 기능입니다.
여러 줄 명령을 한 번에 넣고 싶으시다면 ```!로 여는 코드 블록을 씁니다.
## 환경
\```!
node --version
git status --short
gh auth status
\```스킬이 길어지면 SKILL.md 하나에 모든 걸 욱여넣기 힘들어집니다. 공식 권장은 SKILL.md는 500줄 이내로 유지하고, 상세 레퍼런스는 별도 파일로 분리하는 것입니다.
~/.claude/skills/api-design/
├── SKILL.md # 핵심 지시, 내비게이션
├── reference.md # 상세 API 레퍼런스
├── examples.md # 여러 사용 예시
└── scripts/
└── validate.sh # 클로드가 필요할 때 실행할 스크립트
SKILL.md에서 보조 파일을 이렇게 참조하시면 됩니다.
상세 스펙은 [reference.md](reference.md)를 참고하세요.
사용 예시는 [examples.md](examples.md)에 있습니다.보조 파일은 필요할 때만 로드됩니다. SKILL.md의 description은 항상 컨텍스트에 상주하지만, reference.md는 클로드가 실제로 열어봐야 판단할 때만 읽습니다. 긴 레퍼런스 문서를 묶어두는 비용이 거의 없어지는 셈입니다.
description이 9할입니다
만들어놓은 스킬인데 클로드가 알아서 쓰지 않는 경우가 있습니다. 슬래시 명령으로 직접 치면 잘 되는데, 자연어로 "커밋해줘"라고 했을 때는 스킬을 무시하고 즉흥적으로 답하는 식입니다. 원인은 거의 세 가지 중 하나입니다.
스킬 자동 호출은 오로지 description 텍스트 매칭에 기반합니다. "커밋 도우미"처럼 짧게 쓰지 마시고, 독자가 실제로 칠 만한 표현을 구체적으로 넣어주세요.
# 나쁨
description: 커밋 도우미
# 좋음
description: 현재 변경사항을 한글 메시지로 커밋합니다. "커밋해줘", "commit", "커밋하자", "변경사항 저장" 요청 시 사용하세요.disable-model-invocation: true가 설정되어 있습니다이 옵션이 켜져 있으면 클로드는 절대 자동으로 호출하지 않습니다. 직접 /commit을 쳐야만 실행됩니다. 부작용이 있는 작업은 이게 안전한 기본값이지만, "리팩토링"이나 "코드 리뷰"처럼 자동 호출해도 문제 없는 스킬은 이 옵션을 빼시는 편이 낫습니다.
클로드 코드 대화창에 /를 쳐보시면 사용 가능한 스킬 목록이 자동완성으로 뜹니다. 거기에 내 스킬이 안 보이면 파일 경로와 이름이 잘못됐을 가능성이 높습니다. 주요 체크 포인트는 세 가지입니다.
~/.claude/skills/커밋/SKILL.md 처럼 한글 이름은 안 됩니다. 영소문자 + 숫자 + 하이픈만 허용됩니다.SKILL.md 파일명이 정확한가: 대소문자 중요. Skill.md나 skill.md는 인식되지 않습니다.---가 양쪽에 모두 있는가: 앞뒤 ---가 빠지면 전체가 일반 마크다운으로 처리됩니다.
여기까지 읽으셨다면 스킬이 어떤 물건이고 어떻게 만드는지 감을 잡으셨을 겁니다. 남은 건 딱 하나, 실제로 내 반복 업무 중 하나를 뽑아서 지금 스킬로 만들어보는 것입니다.
판단 기준은 단순합니다. 같은 지시를 3번 이상 반복해서 클로드에게 보낸 적이 있다면, 그건 스킬로 옮길 신호입니다. 커밋 메시지 규칙, PR 템플릿, 배포 절차, 테스트 실행 방식 — 뭐든 반복된다면 5분 투자로 영원히 한 단어짜리 명령으로 줄일 수 있습니다.
스킬은 결국 "내 업무 방식을 클로드가 영원히 기억하게 만드는 파일"입니다. CLAUDE.md가 "나는 어떤 사람이고 이 프로젝트는 뭔지" 적은 인수인계 문서라면, 스킬은 "이 일은 이런 순서로 한다"고 적은 작업 매뉴얼입니다. 두 개를 잘 조합하면 클로드 코드가 진짜 팀원처럼 움직이기 시작합니다.
오늘 딱 하나만 클로드 코드 스킬을 만드신다면 이 글에서 처음에 다룬 /commit을 권합니다. 매일 여러 번 반복하는 작업이고, 한 번 만들어두면 바로 그날부터 차이가 느껴지기 때문입니다.
다음 단계는 이 스킬들을 팀과 공유하는 것입니다. 프로젝트 .claude/skills/ 폴더를 git에 커밋만 하면 팀원이 전부 같은 규칙으로 일하게 됩니다. 팀 전체의 작업 방식을 맞출 수 있는 가장 싸고 빠른 방법입니다.