Claude Code 슬래시 명령어 총정리, 9개월 실사용 후기

 

클로드 코드를 쓰기 시작한 지 9개월쯤 됐습니다. 처음 몇 달은 그냥 프롬프트만 주구장창 쳤습니다. 터미널에 요구사항 쓰고, 코드 나오면 확인하고, 또 쓰고. 그것만으로도 충분히 빨라서 만족했으니까요.

문제는 세션이 길어질 때 생겼습니다. 대화가 쌓이면 답변이 점점 이상해지고, 엉뚱한 파일을 건드리기 시작하고, 어제 디버깅하던 컨텍스트가 오늘 기능 개발에 섞여 들어옵니다. 그때부터 슬래시 명령어를 하나씩 익혔는데, 결론부터 말하면 명령어를 아는 것과 모르는 것의 차이가 프롬프트를 잘 쓰는 것보다 큽니다.

이 글은 클로드 코드 명령어를 사전식으로 나열하지 않습니다. 실제 작업 흐름 순서대로 프로젝트 세팅 -> 작업 중 -> 배포 전 -> 세션 사이 필요한 시점에 쓰는 명령어만 정리했습니다.

명령어는 버전에 따라 달라집니다. 세션에서 / 만 쳐보면 지금 내 환경에서 실제로 쓸 수 있는 목록이 나옵니다. 이 글보다 그게 정확합니다.

 

들어가기 전 명령어의 세 가지 종류부터

이걸 먼저 구분해야 동작이 예측됩니다.

빌트인 명령어	CLI에 코딩된 고정 로직. 결정적으로 동작	/clear, /compact, /model
번들 스킬	클로드에게 건네지는 프롬프트. 클로드가 알아서 호출하기도 함	/code-review, /batch, /debug, /doctor
커스텀 스킬	내가 만든 것. .claude/skills/<이름>/SKILL.md	/deploy, /commit

빌트인은 딱 그 일만 합니다. 스킬은 클로드의 판단이 개입하므로 유연하지만 항상 똑같이 동작하진 않습니다. 이 차이를 알면 "왜 어제랑 다르지?"가 줄어듭니다.

 

 

---

1. 프로젝트 첫 세션 - 초기 셋팅

/init

프로젝트 루트에 CLAUDE.md를 생성합니다. 새 레포에서 제일 먼저 하는 일입니다.

여기서 나오는 초안은 대체로 장황합니다. 그대로 두면 매 요청마다 토큰만 먹으니, 생성 후 반드시 손봅니다. 저는 이 정도로 줄입니다.

많이 쓴다고 무조건 좋은건 아닙니다.

# 프로젝트명
한 줄 설명

## 스택
- Java 21 / Spring Boot 3.x / JPA / MySQL 8
- React 18 + TypeScript / Vite

## 명령어
- `./gradlew bootRun` - 개발 서버
- `./gradlew test` - 테스트
- `npm run dev` - 프론트 개발 서버

## 컨벤션
- Service 계층에서만 트랜잭션 시작
- DTO는 record, 엔티티 직접 노출 금지

## 하지 말 것
- 엔티티에 @Data 붙이지 말 것 (양방향 연관관계에서 터짐)
- application.yml 직접 수정 금지 (환경별 프로파일 사용)

"하지 말 것" 섹션이 핵심입니다. 해야 할 일은 클로드가 알아서 잘 찾습니다. 하지 말아야 하는것을 잘 못 찾습니다.

 

/memory

CLAUDE.md 파일들을 편집하고, 자동 메모리를 켜고 끕니다. /init 이후 다듬을 때 씁니다.

 

/permissions

허용/질문/거부 규칙을 관리합니다. 매번 "이 명령 실행해도 될까요?" 질문 폭탄을 받기 전에 한 번 정리해두는 게 낫습니다.

읽기 전용 명령(git status, ls, npm test)은 미리 허용해두면 흐름이 안 끊깁니다. 반대로 rm -rf, 배포 스크립트, 마이그레이션은 반드시 물어보게 두세요.

 

/mcp

MCP 서버 연결과 OAuth 인증을 관리합니다. 저는 프로젝트에 따라 Figma, GitHub, DB 계열 MCP를 붙여 씁니다(너무 좋아요.) 연결하면 각 서버의 프롬프트가 /mcp <서버> <프롬프트> 형태의 명령어로 노출됩니다.

 

---

2. 작업 중 - 컨텍스트가 전부입니다

여기가 제일 중요합니다. 클로드 코드를 잘 쓴다는 건 사실상 컨텍스트를 잘 관리한다는 뜻입니다.

컨텍스트 관리를 잘 못하면 토큰도 바사삭 녹아버리고 답변도 상태가 좋지 않아집니다.

/context - 지금 뭐가 컨텍스트를 먹고 있나

현재 컨텍스트 사용량을 색깔 그리드로 보여줍니다. 어떤 도구가, 어떤 메모리가, 어떤 스킬이 자리를 차지하는지 항목별로 나옵니다.

답변이 이상해지기 시작하면 프롬프트를 고치기 전에 이걸 먼저 쳐보세요. 대부분 컨텍스트 문제입니다. MCP 서버 하나가 도구 정의만으로 컨텍스트의 15%를 먹고 있는 걸 발견한 적도 있습니다.

 

/compact - 대화를 요약해서 자리 확보

지금까지의 대화를 요약 압축합니다. 같은 작업을 계속 이어가면서 컨텍스트만 비우고 싶을 때 씁니다.

포커스 지시를 같이 줄 수 있는 게 포인트입니다. 저는 이 명령어를 자주 씁니다. 

/compact 인증 리팩터링 관련 결정사항만 남기고 요약해줘

이렇게 하면 곁가지 디버깅 로그는 날리고 핵심 결정만 살립니다.

 

/clear - 새 작업 시작

대화를 완전히 비우고 새 컨텍스트로 시작합니다. 프로젝트 메모리(CLAUDE.md)는 유지됩니다. 이전 대화는 /resume에서 다시 찾을 수 있습니다.

(중요) 작업이 바뀌면 무조건 /clear.  이게 가장 큰 토큰 절약이자 품질 유지 방법입니다. 어제의 버그 헌팅 컨텍스트가 오늘의 기능 개발에 섞일 이유가 없습니다.

/compact와 /clear 구분:

• 같은 작업 계속 → /compact
• 다른 작업 시작 → /clear

 

/plan - 큰 변경 전엔 반드시

플랜 모드로 진입합니다. 설명을 같이 넘기면 바로 그 작업으로 시작합니다.

/plan 주문 도메인에 부분 취소 기능 추가

저는 큰 작업은 Research → Plan → 주석 → 구현 순서로 갑니다. /plan이 그 두 번째 단계를 강제해줍니다. 계획 없이 바로 코드를 짜게 두면, 잘못된 방향으로 20개 파일을 고쳐놓고 나서야 알게 됩니다.

또 다른 방법으로는 Shift + Tab을 이용해서 Plan Mode로 변경해서 사용하는 방법도 있어요.

 

/effort - 사고 깊이 조절

모델의 사고 수준을 조절합니다. low, medium, high, xhigh, max 등이 있고 모델에 따라 가능한 레벨이 다릅니다. 인자 없이 치면 슬라이더가 나옵니다.

보일러플레이트에 최고 수준을 쓸 이유가 없습니다. 반대로 아키텍처 결정이나 까다로운 동시성 버그엔 올려서 씁니다.

 

/model - 모델 전환

세션 중에 모델을 바꿉니다. 단순 반복 작업은 가벼운 모델, 설계·리뷰는 무거운 모델. 이 스위칭만 습관화해도 비용이 눈에 띄게 줄어듭니다.

 

/btw - 곁가지 질문

작업 중 문득 궁금한 걸 물어보되, 메인 대화 컨텍스트를 오염시키지 않습니다.

/btw 이 프로젝트 Node 버전이 뭐였지?

이거 알기 전엔 이런 질문 하나 때문에 대화 흐름이 지저분해지는 걸 그냥 참았습니다. 그리고 끝날 때 까지 기다리기도 했죠.

 

---

3. 병렬로 굴리기

/batch <지시>

대규모 변경을 병렬로 처리합니다. 코드베이스를 조사해서 작업을 5~30개의 독립 단위로 분해하고 계획을 제시합니다. 승인하면 각 단위마다 백그라운드 서브에이전트를 격리된 git worktree에 띄웁니다. 각 에이전트가 자기 몫을 구현하고, 테스트를 돌리고, PR을 엽니다.

/batch src/ 전체 클래스 컴포넌트를 함수형 + 훅으로 마이그레이션

git 저장소여야 동작합니다. 대규모 마이그레이션에서 이거 하나로 며칠 걸릴 일이 반나절이 됩니다.

 

/fork <지시> vs /branch [이름]

헷갈리기 쉬운 한 쌍입니다.

• /branch — 지금 대화를 분기해서 내가 다른 방향으로 가봅니다. 원본은 보존되고 /resume으로 돌아올 수 있습니다. 위험한 실험 전에 씁니다.
• /fork — 전체 대화를 물려받은 백그라운드 서브에이전트가 그 지시를 처리하는 동안 나는 하던 일을 계속합니다. 결과는 끝나면 대화로 돌아옵니다.

 

/background (별칭 /bg)

현재 세션을 백그라운드 에이전트로 떼어내고 터미널을 반환합니다. 긴 작업 던져놓고 다른 일 할 때 씁니다.

 

/tasks

백그라운드에서 돌고 있는 것들을 확인하고 관리합니다.

 

---

4. 커밋 전 - 품질 게이트

/diff

변경사항을 인터랙티브 뷰어로 봅니다. 좌우 방향키로 현재 git diff와 클로드의 개별 턴 diff를 오갈 수 있는 게 유용합니다. "클로드가 어느 턴에서 이 파일을 건드렸지?"를 추적할 수 있습니다.

 

/code-review [레벨] [--fix] [--comment]

현재 diff를 리뷰합니다. 정확성 버그와 함께 재사용, 단순화, 효율 관점의 정리 포인트를 찾아줍니다.

/code-review high          # 높은 수준으로 리뷰
/code-review --fix         # 발견 사항을 작업 트리에 바로 적용
/code-review --comment     # GitHub PR 인라인 코멘트로 게시
/code-review ultra         # 클라우드에서 멀티 에이전트 심층 리뷰

 

/simplify [대상]

정리 전용 리뷰입니다. 4개의 리뷰 에이전트가 병렬로 돌면서 재사용, 단순화, 효율, 추상화 레벨을 보고 수정을 적용합니다. 버그는 찾지 않습니다 (그건 /code-review 몫입니다.)

역할 분담이 명확해서 좋습니다. 버그는 /code-review, 코드 정리는 /simplify.

저는 이 두개 명령어를 작업 후 왠만하면 한번씩 실행하기도 하고 지침에 넣어버리기도 합니다.

작업이 끝나면 /simplify 실행해줘. 라고요. 하지만 지침에 넣어놓으면 무시되는 경우도 많아요.ㅠ

 

/security-review

현재 브랜치의 변경사항을 보안 취약점 관점에서 분석합니다. 인젝션, 인증 문제, 데이터 노출 같은 위험을 잡습니다.

작년에 Next.js SSRF 취약점으로 서버가 크립토 마이닝 악성코드에 뚫린 적이 있습니다. 그 이후로 외부 입력을 다루는 코드는 무조건 이걸 한 번 돌립니다.

 

/review [PR번호]

GitHub PR을 빠르게 단일 패스로 읽기 전용 리뷰합니다. 인자 없이 치면 열린 PR 목록에서 고를 수 있습니다.

 

---

5. 세션 사이 - 이어서 하기

명령어 용도

/resume [세션]	이전 대화를 ID나 이름으로 재개. 인자 없으면 피커
/rewind	코드와 대화를 체크포인트로 되돌림 (별칭 /undo)
/clear [이름]	새 대화 시작. 이름을 주면 이전 대화에 라벨이 붙어 /resume에서 찾기 쉬움
/usage	세션 비용, 플랜 사용량, 활동 통계 (별칭 /cost, /stats)

/rewind는 안전망입니다. 클로드가 파일 10개를 잘못 고쳐놨을 때 git stash 뒤지지 말고 이걸 쓰세요.

 

---

6. 정리와 진단

/doctor (별칭 /checkup) - 이건 좀 놀랐습니다

예전엔 그냥 설치 상태 진단이었는데, 지금은 셋업 전반을 점검하고 고쳐주는 명령어가 됐습니다.

• 중복 설치, PATH 문제, 파싱 안 되는 설정 파일 탐지
• 안 쓰는 스킬·MCP 서버·플러그인을 컨텍스트 비용 대비로 찾아냄
• 로컬 CLAUDE.md와 체크인된 버전 간 중복 제거
• 비대해진 CLAUDE.md를 스킬과 중첩 CLAUDE.md로 분리
• 느린 훅 플래그
• 최신 버전 확인

변경 전에 반드시 확인을 받습니다. 프로젝트 몇 개 굴리다 보면 스킬이랑 MCP가 계속 쌓이는데, 한 달에 한 번 돌려서 정리하기 좋습니다.

 

/skills

사용 가능한 스킬 목록. t를 누르면 토큰 수 기준 정렬됩니다. 컨텍스트 도둑을 잡는 데 유용합니다.

 

/debug [설명]

현재 세션의 디버그 로깅을 켜고 로그를 읽어서 문제를 분석합니다.

 

---

7. 커스텀 명령어 - 이제 "스킬"입니다

여기가 이번 정리에서 가장 크게 바뀐 부분입니다.

커스텀 명령어는 스킬로 통합됐습니다. .claude/commands/deploy.md와 .claude/skills/deploy/SKILL.md 둘 다 /deploy를 만들고 똑같이 동작합니다. 기존 .claude/commands/ 파일은 계속 잘 돌아갑니다. 다만 스킬 쪽이 기능이 더 많습니다.

• 보조 파일(스크립트, 템플릿, 레퍼런스)을 같은 디렉터리에 번들
• 클로드가 필요할 때 알아서 호출하게 만들 수 있음
• 프론트매터로 호출 주체 제어

 

만드는 법

mkdir -p ~/.claude/skills/summarize-changes

~/.claude/skills/summarize-changes/SKILL.md:

---
description: 커밋되지 않은 변경사항을 요약하고 위험 요소를 짚어준다.
  사용자가 뭐가 바뀌었는지 묻거나, 커밋 메시지를 원하거나, diff 리뷰를 요청할 때 사용.
---

## 현재 변경사항

!`git diff HEAD`

## 지시

위 변경사항을 2~3개 불릿으로 요약하고, 에러 핸들링 누락·하드코딩된 값·
업데이트가 필요한 테스트 같은 위험 요소를 나열하라.
diff가 비어 있으면 커밋되지 않은 변경사항이 없다고 답하라.

 

핵심 기능 세 가지

 

1. 동적 컨텍스트 주입 - !`명령어` 문법 백틱 앞에 !를 붙이면 클로드가 스킬 내용을 보기 전에 셸 명령이 실행되고, 그 출력이 자리를 대체합니다. 클로드는 실제 데이터가 이미 박힌 프롬프트를 받습니다.

이게 진짜 강력합니다. "git diff 좀 봐줘"가 아니라, diff가 이미 프롬프트에 들어있는 상태로 시작합니다.

 

2. 인자 전달

---
name: fix-issue
description: GitHub 이슈를 수정한다
disable-model-invocation: true
---

우리 코딩 표준에 따라 GitHub 이슈 $ARGUMENTS 를 수정하라.

/fix-issue 123 → $ARGUMENTS가 123으로 치환됩니다. 위치별로 $0, $1도 됩니다.

 

3. 호출 주체 제어

프론트매터 내가 호출 클로드가 호출

(기본)	O	O
disable-model-invocation: true	O	X
user-invocable: false	X	O

/deploy 같은 부작용 있는 스킬엔 반드시 disable-model-invocation: true를 거세요. 코드가 준비돼 보인다는 이유로 클로드가 배포를 결정하게 두면 안 됩니다.

 

스킬이 사는 곳

위치 경로 적용 범위

개인	~/.claude/skills/<이름>/SKILL.md	내 모든 프로젝트
프로젝트	.claude/skills/<이름>/SKILL.md	이 프로젝트만
플러그인	<플러그인>/skills/<이름>/SKILL.md	플러그인 활성화된 곳

프로젝트 스킬은 git에 커밋하면 팀 전체가 씁니다. 팀의 코드 리뷰 체크리스트, 배포 검증 절차, 커밋 컨벤션 이런 걸 한 줄 명령어로 만들어서 레포에 넣어두는 것이 팀 단위에서 가장 레버리지가 큽니다.

 

주의: 스킬 본문은 짧게

스킬이 한번 로드되면 그 내용이 세션 내내 컨텍스트에 남습니다. 모든 줄이 반복 비용입니다. 왜 그런지 서술하지 말고 뭘 할지만 쓰세요. SKILL.md는 500줄 안쪽으로. 긴 레퍼런스는 별도 파일로 빼서 필요할 때만 읽게 하는 게 맞습니다.

---

실전 워크플로우 - 제 하루

정리하면 이런 흐름입니다.

# 아침, 새 기능 시작
/clear                              # 어제 컨텍스트 버림
/resume								# 어제 작업 이어서 하고 싶을 때
/plan 상품 옵션에 재고 연동 추가       # 계획부터

# 작업 중
/context                            # 답변 이상하면 여기부터
/compact 재고 로직 결정사항만 남겨줘   # 대화 길어지면
/btw 이 프로젝트 JPA 버전 뭐지        # 곁가지는 곁가지로

# 커밋 전
/diff                               # 뭘 바꿨는지 확인
/code-review high                   # 버그 찾기
/simplify                           # 코드 정리
/security-review                    # 외부 입력 다뤘으면 필수

# 정리
/usage                              # 오늘 얼마 썼나

한 달에 한 번쯤 /doctor 돌려서 안 쓰는 스킬과 MCP 정리합니다.

 

---

마무리

클로드 코드를 잘 쓰는 사람은 프롬프트를 잘 쓰는 사람이 아닙니다. 컨텍스트를 관리할 줄 알고, 적절한 순간에 맞는 명령어를 꺼내는 사람입니다. 제 주위에도 생각보다 컨텍스트 관리 안하는 분들이 많았어요.

당장 세 개만 몸에 붙이라면 이걸 고르겠습니다.

1. /clear — 작업 바뀌면 무조건. 가장 큰 품질 개선.
2. /plan — 큰 변경 전엔 항상. 잘못된 방향으로 20개 파일 고치는 걸 막아줍니다.
3. /code-review — 커밋 전에. 사람 리뷰어에게 갈 노이즈를 줄여줍니다.

나머지는 필요할 때 /help나 /로 찾으면 됩니다.

명령어는 버전·플랜·플랫폼에 따라 달라집니다. 최신 공식 레퍼런스는 여기입니다:

• 명령어 레퍼런스: https://code.claude.com/docs/en/commands
• 스킬 만들기: https://code.claude.com/docs/en/skills

 

---

 

여러분은 클로드 코드에서 어떤 커스텀 스킬을 만들어 쓰시나요? 댓글로 공유해주시면 저도 배워보겠습니다.

 

---

 

이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.