🍑 심화(LV35)#Claude Code#클로드 코드#슬래시 커맨드#스킬#SKILL.md#업무 자동화#AI 자동화#워크플로우
9분·2026. 4. 24.·조회 7
오늘도 AI 한입 하세요 🍊
새 아티클이 발행되면 이메일로 알려드릴게요.
댓글을 남기려면 로그인이 필요합니다.
아직 댓글이 없습니다. 첫 댓글을 남겨보세요!
클로드 코드(Claude Code)에게 매번 같은 커밋·PR·배포 지시를 반복하고 계신가요? 클로드 코드 스킬(Claude Code Skill)을 직접 만들면 /commit, /pr, /deploy 같은 한 단어 명령으로 반복 업무를 끝낼 수 있습니다. 슬래시 커맨드와의 통합, 5분 핸즈온, 자동 호출 트리거, 인자 처리, 실시간 컨텍스트 주입까지 한 번에 정리합니다.
클로드 코드(Claude Code)에게 매번 '이 프로젝트는 이렇고, 답변은 이렇게...' 반복 설명하고 계신가요? CLAUDE.md 파일 하나면 한 번만 세팅하고 끝입니다. 비개발자도 5분이면 따라할 수 있는 CLAUDE.md 설정법과 실전 템플릿, 웹에서 쓰는 Claude Projects까지 한 번에 정리했습니다.
터미널 뜻, CLI란 무엇인지부터 맥 터미널 여는 법, 첫 명령어 실습까지. Claude Code, Codex 같은 AI 도구를 쓰려면 터미널을 알아야 합니다.
옵시디언(Obsidian) MCP 설정, 사실은 간단합니다. 클로드 코드(Claude Code)를 볼트 폴더에서 실행하면 AI가 내 노트를 직접 읽고 씁니다. 3단계 연결 방법과 실제 활용 예시를 정리했습니다.
클로드 코드 사용량을 /context와 /usage 명령어로 진단하고, 토큰이 빨리 소진되는 원인을 분석해 비용을 아끼는 실전 팁까지 정리합니다. 서브에이전트 남용·긴 세션 등 리밋이 걸리는 패턴별 대응법과 요금제 비교 포함.
엑셀 함수도, 매크로도, 파이썬도 배울 필요가 없습니다. 터미널에서 Claude Code를 열고 엑셀 파일을 넘긴 다음 하고 싶은 일을 말로 설명하면, 파일을 직접 읽고 수정하고 저장까지 해줍니다. 실전 예제 3가지로 보여드립니다.
둘 다 AI인데 어떻게 다를까요? 코딩, 글쓰기, 분석 등 상황별로 어떤 AI를 선택해야 하는지 실전 비교로 정리했습니다.
클로드 코드(Claude Code)를 한 달쯤 써보면 자연스럽게 눈치채는 게 있습니다. 매일 치는 프롬프트가 거의 똑같다는 것.
어제도 "이 변경사항 정리해서 커밋 메시지 써줘. AI 흔적은 빼고. 제목은 50자 이내, 본문은 '왜' 중심으로"라고 쳤고, 오늘도 같은 프롬프트를 복붙하고 있습니다. 내일도 또. PR 올릴 때도, 코드 리뷰 요청할 때도, 매일 똑같은 지시문을 반복해서 보내고 있습니다.
이걸 줄이는 방법이 두 가지 있습니다. 슬래시 커맨드와 스킬입니다. 같은 문제를 해결하지만 쓰는 상황이 다릅니다. 이 글에서는 두 개념이 정확히 무엇이고, 어떻게 만들고, 언제 뭘 써야 하는지, 그리고 이 블로그(1bite.ai)가 실제로 이 두 가지로 어떻게 돌아가는지까지 한 번에 정리합니다.
결론부터 짧게 드리면 이렇습니다.
/commit 같은 짧은 단어로 줄여 부르는 단축키.이 글을 읽기 전에 알고 있으면 좋은 것
클로드 코드가 처음이라면 설치와 기본 실행 방법부터 잡고 오시는 게 좋습니다.
👉 Claude Code, 처음 시작할 때 이것만 따라하세요
그리고 프로젝트별 기본 규칙을 AI에 주입하는 개념(
CLAUDE.md)을 먼저 이해하면 이 글의 전후 맥락이 훨씬 빨리 잡힙니다.
같은 폴더에 있지만 역할이 다릅니다
슬래시 커맨드 얘기를 시작하기 전에, 자주 헷갈리는 지점부터 정리하고 가겠습니다. CLAUDE.md와 슬래시 커맨드는 둘 다 .claude/ 폴더 근처에 살지만, 역할이 다릅니다.
CLAUDE.md는 AI의 배경지식입니다. 클로드 코드가 대화를 시작하는 순간 자동으로 읽히고, 그 뒤의 모든 대화에 조용히 깔려 있습니다. "나는 마케팅팀 기획자야, 답변은 한국어로 해줘" 같은 정보가 여기 들어갑니다.
반면 슬래시 커맨드는 내가 직접 호출하는 명령어입니다. /commit이라고 치는 순간에만 실행됩니다. 자동으로 읽히지는 않습니다.
비유하자면 CLAUDE.md는 입사 첫날 받는 업무 매뉴얼이고, 슬래시 커맨드는 책상 서랍에 붙여둔 단축키 스티커입니다. 매뉴얼은 일하는 동안 내내 참고하고, 단축키는 내가 필요할 때마다 손으로 눌러서 씁니다.
.claude/commands/에.md파일만 넣으면 끝
이론은 이쯤 하고 실제로 만들어보는 게 빠릅니다. 가장 흔한 예시로 "커밋 메시지 자동 생성 커맨드"를 만들어보겠습니다. 파일 하나, 3줄이면 끝납니다.
프로젝트 폴더의 최상위에서 다음 명령으로 폴더를 만듭니다.
mkdir -p .claude/commands이미 있다면 그냥 넘어갑니다. -p 옵션이 "없으면 만들고, 있으면 조용히 넘어가라"는 의미이므로 안전하게 실행해도 됩니다.
commit.md 파일 만들기방금 만든 폴더 안에 commit.md라는 파일을 만들고 아래 내용을 넣습니다.
현재 staged 변경사항을 분석해서 한국어로 커밋 메시지를 작성해줘.
규칙:
- 제목은 50자 이내, 타입 prefix(feat, fix, chore, refactor, docs) 사용
- 본문은 "왜" 중심으로 2~3줄
- AI 흔적 금지 (Claude, Co-Authored-By 등 제외)
- 바로 커밋까지 실행저장하고 나면 끝입니다. 폴더 구조는 이렇게 보입니다.
내-프로젝트/
├── .claude/
│ └── commands/
│ └── commit.md
└── ...(나머지 프로젝트 파일들)
이제 같은 프로젝트 폴더에서 claude를 실행하고 대화창에 입력해봅니다.
/commit
클로드 코드는 commit.md의 내용을 지금 입력한 프롬프트처럼 읽고 실행합니다. git diff --staged를 직접 돌려서 변경사항을 확인하고, 규칙에 맞는 메시지를 작성한 뒤, 바로 커밋까지 찍습니다.
오늘부터 /commit 일곱 글자만 치면, 매일 새로 쓰던 그 긴 프롬프트가 사라집니다.
왜
.md파일이 명령어가 되나요클로드 코드는 대화창에서
/커맨드이름을 받으면.claude/commands/커맨드이름.md파일을 찾아서, 그 내용을 "지금 막 사용자가 친 프롬프트"처럼 읽습니다. 그래서 복잡한 설정 없이 마크다운 파일 하나가 커맨드 한 개가 됩니다. 평범한 글로 쓴 파일이 그대로 명령어가 되는 겁니다.
$ARGUMENTS한 커맨드로 여러 상황 대응
/commit은 인자가 필요 없지만, 같은 커맨드인데 상황마다 다른 값을 넣고 싶은 경우가 많습니다. 예를 들어 "버그 리포트를 받아서 재현-분석-수정 과정을 돌리는" 커맨드를 만들고 싶다면, 버그 내용 자체를 인자로 받아야 합니다.
방법은 간단합니다. Claude Code의 커스텀 커맨드는 파일 안에 $ARGUMENTS라는 특별한 문자열을 받을 수 있고, 커맨드를 호출할 때 뒤에 붙인 말이 그 자리에 자동으로 치환됩니다.
.claude/commands/fix-bug.md를 이렇게 만들어봅니다.
다음 버그를 재현하고 원인을 분석한 뒤 수정해줘.
버그 내용: $ARGUMENTS
순서:
1. 먼저 재현 시나리오를 정리하고 나에게 확인받아줘
2. 재현 후 원인이 된 파일과 라인 번호를 알려줘
3. 수정 전에 어떤 방법으로 고칠지 제안하고 승인 받아줘
4. 승인 후 수정 및 테스트 실행이제 이렇게 부를 수 있습니다.
/fix-bug 로그인 버튼을 눌러도 반응이 없습니다
클로드는 $ARGUMENTS 자리에 "로그인 버튼을 눌러도 반응이 없습니다"를 끼워 넣고, 그 뒤 단계대로 작업을 시작합니다. 같은 커맨드를 인자만 바꿔서 여러 버그에 쓸 수 있게 되는 겁니다.
@경로매번 "이 파일 열어봐"라고 말할 필요 없음
커맨드 안에서 특정 파일을 AI에게 읽히고 싶을 때가 있습니다. 매번 "src/auth/login.ts 열어봐"라고 쓰지 않아도, 파일 경로 앞에 @를 붙이면 클로드가 커맨드 실행 시점에 그 파일을 자동으로 읽어서 맥락에 넣습니다.
예를 들어 "주요 설정 파일 세 개를 항상 같이 확인하는 커맨드"는 이렇게 만들 수 있습니다.
아래 세 파일의 최신 상태를 기준으로 환경 설정을 점검해줘.
@package.json
@.env.local
@prisma/schema.prisma
체크 항목:
- 누락된 환경변수가 있는지
- 패키지 버전 충돌 가능성
- 스키마와 실제 DB가 어긋나는 부분이제 /env-check라고만 치면 세 파일이 자동으로 읽힌 상태로 점검이 시작됩니다. 매번 "이 파일부터 보고 저 파일 보고..."를 타이핑할 필요가 없어집니다.
! 접두사
git log,ls같은 결과를 커맨드가 직접 가져옴
클로드가 판단하기 전에 지금 프로젝트의 실시간 상태가 필요할 때가 있습니다. 예를 들어 최근 커밋 10개를 본 뒤 릴리스 노트를 만들게 하고 싶다면, 매번 "git log 돌려봐"라고 할 필요가 없습니다.
!(느낌표)로 시작하는 줄은 클로드가 실제로 그 셸 명령을 실행한 뒤, 그 결과를 프롬프트에 끼워 넣어 읽습니다.
최근 10개 커밋을 바탕으로 오늘자 릴리스 노트를 한국어로 써줘.
최근 커밋:
!git log --oneline -n 10
형식:
- 제목은 "YYYY-MM-DD 릴리스"
- 주요 변경을 bullet 3~5개로
- 기술 용어는 줄글로 풀어서이제 /release-note만 치면 최신 커밋 로그가 자동으로 끼워져 있는 상태로 글쓰기가 시작됩니다. 커맨드 하나가 "상태 조회 + 해석 + 글쓰기"를 한 번에 끝내주는 셈입니다.
"조건부"와 "여러 단계 재사용"이 한계
슬래시 커맨드는 "매번 똑같이 시작하는 지시문"을 줄이는 데는 완벽합니다. 하지만 쓰다 보면 세 가지 벽에 부딪힙니다.
/commit과 /release-note가 둘 다 "AI 흔적 제거"를 해야 한다면, 그 규칙을 두 파일에 복붙해두게 됩니다. 나중에 규칙이 바뀌면 파일마다 찾아다니며 수정해야 합니다.이 세 가지를 한꺼번에 풀어주는 게 바로 스킬(Skill)이라는 개념입니다.
호출 방식 자체가 다르다
슬래시 커맨드와 스킬의 가장 큰 차이는 누가 호출하느냐입니다.
/commit이라고 쳐야 실행됩니다.이 차이가 중요한 이유는, AI는 내가 언제 /commit을 쳐야 하는지 외우라고 강요하지 않을 수 있기 때문입니다. "커밋해줘", "변경사항 정리해", "commit하자" 어떤 말로 불러도 AI가 자동으로 맞는 스킬을 고릅니다. 더 자연스러운 대화에 가깝습니다.
.claude/skills/이름/SKILL.md
스킬은 파일 하나가 아니라 폴더 하나입니다. 이름 있는 작업 단위라서 "이 스킬은 이 폴더에 산다"는 구조가 필요합니다.
내-프로젝트/
├── .claude/
│ ├── commands/
│ │ └── commit.md ← 슬래시 커맨드 (파일)
│ └── skills/
│ └── commit/ ← 스킬 (폴더)
│ └── SKILL.md ← 이 파일이 필수
└── ...
SKILL.md는 스킬의 심장 같은 파일입니다. 반드시 이 이름이어야 하고, 특정한 양식을 따라야 합니다.
SKILL.md의 구조 — frontmatter가 진짜 핵심description 한 줄이 이 스킬의 수명을 결정합니다
SKILL.md는 두 덩어리로 나뉩니다. 위쪽 frontmatter(YAML)와, 아래쪽 본문(마크다운).
---
name: commit
description: 변경사항을 분석해 한국어 커밋 메시지를 작성하고 커밋까지 실행합니다. 사용자가 "커밋해줘", "commit", "변경사항 정리" 등으로 요청할 때 활성화됩니다.
---
# 커밋 자동화 스킬
## 트리거
- "커밋해줘", "commit", "변경사항 정리"
## 실행 순서
1. `git status`로 staged 여부 확인
2. staged가 없으면 사용자에게 `git add` 필요 여부 질문
3. 메시지 작성 규칙 적용 (제목 50자, 타입 prefix, AI 흔적 제거)
4. 사용자 확인 없이 `git commit` 실행
## 주의사항
- `--no-verify` 금지
- 민감 파일(.env, credentials) 자동 스테이징 금지위쪽 --- 사이의 frontmatter에는 두 가지 필수 필드가 있습니다.
name: 스킬의 이름입니다. 폴더 이름과 같게 두면 실수가 줄어듭니다.description: 이 스킬의 운명을 가르는 한 줄입니다. 클로드는 대화하면서 "지금 이 상황에 어떤 스킬을 써야 할까?"를 결정할 때 각 스킬의 description만 읽고 판단합니다. 본문까지 읽지 않습니다. description이 애매하면 스킬은 영영 호출되지 않습니다.Anthropic 공식 가이드는 description에 두 질문의 답을 모두 담으라고 안내합니다.
그리고 "나(1인칭)"가 아니라 3인칭으로 씁니다. "도와드릴 수 있습니다"가 아니라 "~을 수행합니다".
나쁜 예: description: 커밋을 도와드립니다 — 언제 써야 할지 모호합니다.
좋은 예: description: 변경사항을 분석해 한국어 커밋 메시지를 작성하고 커밋까지 실행합니다. 사용자가 "커밋해줘", "commit", "변경사항 정리" 등으로 요청할 때 활성화됩니다.
더 좋은 예: 여기에 트리거 키워드를 아예 예시로 열거하면 AI가 매칭하기 훨씬 쉬워집니다.
공식 제한: description은 최대 1,024자, XML 태그 금지. 너무 길게 쓸 필요는 없고, 보통 2~3문장 안에서 "무엇 / 언제"를 명확히 적는 게 핵심입니다.
frontmatter로 "호출 트리거", 본문으로 "실제 행동 지침"
description이 "언제 호출되나"를 결정한다면, 본문은 "호출된 뒤 실제로 뭘 하나"를 결정합니다. 본문에는 다음 네 가지 덩어리가 거의 항상 들어갑니다.
이 네 덩어리가 다 들어가야 같은 스킬이 매번 같은 결과를 냅니다. 덕분에 같은 스킬이 여러 상황에서 일관되게 동작합니다. 어제 "커밋해줘"와 오늘 "변경사항 정리"가 완전히 같은 절차로 끝나는 겁니다.
판단 기준 네 줄
여기서 가장 많이 받는 질문이 "그럼 뭘 언제 써요?"입니다. 네 가지 판단 기준으로 정리할 수 있습니다.
| 상황 | 슬래시 커맨드 | 스킬 |
|---|---|---|
| 내가 매번 직접 호출하고 싶다 | ✅ | △ |
| AI가 자연스러운 말로도 알아채게 하고 싶다 | ❌ | ✅ |
| 단계가 3개 이내, 단순 템플릿 | ✅ | △ |
| 여러 단계 + 조건 분기 + 재사용 로직 | ❌ | ✅ |
실전에서 제가 쓰는 기준은 이렇습니다.
처음에는 슬래시 커맨드로 시작하고, 쓰다 보면 "이 커맨드는 스킬로 올리는 게 낫겠는데?" 하는 타이밍이 자연스럽게 옵니다. 그때 옮기면 됩니다.
부작용이 있는 스킬은 자동 호출을 막아두세요
커밋, 배포, 메시지 발송처럼 한 번 실행되면 되돌리기 어려운 스킬은 frontmatter에
disable-model-invocation: true한 줄을 더해두는 편이 안전합니다. 이 옵션이 켜지면 AI가 스스로 판단해서 호출하지 않고, 사용자가 직접/이름을 쳐서 부를 때만 실행됩니다. AI의 편의성보다 "실수로 배포되면 안 된다" 쪽이 더 중요한 스킬에 권장되는 공식 안전 장치입니다.
~/.claude/에 두면 모든 프로젝트에서, 프로젝트 폴더에 두면 그 프로젝트에서만
지금까지 만든 커맨드·스킬은 전부 프로젝트 폴더 안의 .claude/ 폴더에 저장한 것이었습니다. 이 경우 그 프로젝트에서만 불러 쓸 수 있습니다.
그런데 /commit이나 /release-note 같은 커맨드는 모든 프로젝트에서 쓰고 싶은 게 인지상정입니다. 이럴 땐 같은 폴더 구조를 홈 디렉토리 아래에 만들면 됩니다.
./내-프로젝트/.claude/commands/commit.md~/.claude/commands/commit.md맥·리눅스라면 ~는 /Users/내-아이디를 가리킵니다. 이 위치에 둔 커맨드는 어느 폴더에서 클로드를 실행하든 다 불려 나옵니다.
스킬도 마찬가지 규칙입니다. ~/.claude/skills/에 둔 스킬은 모든 프로젝트에서 자동 인식됩니다.
팀 전체에 공유하고 싶으면 프로젝트 .claude/를 git에 커밋하면 됩니다. 팀원이 git pull만 하면 같은 커맨드와 스킬이 자기 환경에도 깔립니다. "우리 팀은 이렇게 커밋 메시지를 씁니다"가 파일 한 장으로 표준화되는 겁니다.
지금 보고 계신 1bite.ai는 이렇게 스킬로 굴러갑니다
이 블로그(1bite.ai)는 실제로 50개 가까운 스킬로 돌아갑니다. 글 한 편 발행까지의 흐름을 그대로 예시로 풀어보겠습니다.
/suggest-article: 옵시디언에 적어둔 주제 백로그와 DB의 발행 기록을 교차해, 다음에 쓸 글을 추천합니다./write-article: 주제를 받으면 키워드 조사 → 본문 작성 → 셀프 체크 → SEO 반영 → 팩트체크 → 시각자료 → 썸네일 → 발행까지 8단계 파이프라인이 순차로 돌아갑니다./commit: 이 글을 쓰는 동안 생긴 파일들을 한국어 커밋 메시지로 정리합니다./publish-article: DB의 draft: true를 false로 바꾸고 Vercel 재배포를 트리거합니다.지금 이 글도 /suggest-article → /write-article 흐름으로 제안되고 쓰이고 있습니다. 제가 매번 "다음 글 뭐 쓸까", "글 써줘"라고 평범하게 말해도, 클로드가 description을 보고 알아서 맞는 스킬을 골라 실행합니다. 기억해야 할 명령어가 없다는 게 핵심입니다.
각 스킬은 대략 200~600줄 사이의 SKILL.md를 가지고 있고, "어떤 순서로 일하는지", "절대 하지 말 것은 뭔지"가 빼곡히 적혀 있습니다. 이 파일을 한 번 잘 써두면, 그 뒤부터는 제가 글쓰기 과정을 몰라도 AI가 대신 절차를 밟아줍니다.
이걸 슬래시 커맨드로 하려고 했다면, 파일 하나에 8단계 파이프라인을 전부 담아야 했을 겁니다. 중간에 멈추거나 단계별로 다시 실행하는 것도 불가능했을 테고요. 스킬이라서 가능한 구조입니다.
실제로 제가 한 번씩 다 겪은 것들
커맨드·스킬을 처음 도입할 때 공통으로 겪는 세 가지 실수가 있습니다.
RULES.md, EXAMPLES.md 등)로 분리해서 SKILL.md에서 참조하는 구조가 좋습니다.~/.claude/)에 너무 많이 쌓는 것 — 스킬이 너무 많아지면 클로드가 description을 다 훑느라 실제 작업에 쓸 주의력이 줄어듭니다. "이건 이 프로젝트에서만 쓰겠다" 싶은 건 그 프로젝트의 .claude/에 따로 두는 게 낫습니다. 전역은 정말 어디서나 쓸 것(커밋, PR, 릴리스 노트 정도)만 남겨두세요.슬래시 커맨드는 단축키, 스킬은 절차
여기까지 오셨다면 다음 행동은 명확합니다.
.claude/commands/이름.md에 저장합니다 — 오늘부터 /이름만 치면 끝입니다..claude/skills/이름/SKILL.md로 옮기고 상단에 description을 달아주세요. 이제 클로드가 "커밋해줘"라는 평범한 말만 들어도 알아서 그 절차를 꺼내 씁니다.슬래시 커맨드와 스킬은 결국 내 반복 업무를 AI에게 문서로 저장하는 것입니다. 손으로 타이핑하던 게 파일로 옮겨가고, 그 파일이 쌓이면 쌓일수록 제가 같은 설명을 반복할 일이 줄어듭니다. 생각해보면 인수인계 문서를 정성껏 써두면 그 자리가 사라져도 후임이 일할 수 있는 것처럼, 스킬도 "미래의 나(와 AI)에게 주는 인수인계 문서"에 가깝습니다.
이제 반복을 자동화하는 틀은 다 잡으셨습니다. 다음으로는 매번 뜨는 "이거 해도 돼요?" 확인 창을 끄는 권한 설정까지 이어서 보시면, 이 자동화가 실제로 멈춤 없이 돌아가기 시작합니다.