Claude Code 슬래시 명령어 7가지 — 반복 작업 줄이는 실전 활용

슬래시 명령어를 쓰면 뭐가 달라지나요

Claude Code 슬래시 명령어, 처음엔 그냥 단축어처럼 보였어요. 그런데 한 달 써보니 매일 반복하던 작업이 한 줄로 줄어들더라고요. PR 리뷰, 테스트 실행, 커밋 메시지 다듬기 — 이런 사이클이 손에 붙으면 진짜로 칼퇴가 가능해요.

저도 처음엔 /help 정도만 알고 있었거든요. 그런데 .claude/commands/ 디렉토리 존재를 알게 된 뒤로 직접 명령어를 만들기 시작했고, 지금은 7개를 매일 돌려요. 이 글에서 그 7개를 공개할게요.

이 글에서 얻어갈 3가지

• 기본 제공 슬래시 명령어 중 꼭 써야 할 4개
• 직접 만들어 쓰는 커스텀 명령어 3개 (복붙 가능)
• 각 명령어가 어떤 작업의 부담을 덜어주는지 용도별 정리

1. /init — 새 레포에 들어갔을 때 가장 먼저

낯선 코드베이스를 받았을 때 가장 먼저 치는 명령어예요. /init 한 번이면 전체 구조를 훑어서 CLAUDE.md 파일을 만들어줘요. 빌드 명령어, 테스트 명령어, 폴더 구조, 코딩 컨벤션을 자동으로 정리해줘요.

외주 코드를 받을 때마다 이걸 먼저 돌리면 좋아요. README와 package.json을 하나씩 뜯어보며 파악하던 과정을 한 번에 정리해주거든요.

# 프로젝트 루트에서
$ claude
> /init

생성된 CLAUDE.md는 그대로 git에 커밋하면 팀원 전체가 동일한 컨텍스트로 작업할 수 있어요.

2. /review — PR 리뷰 1차 패스 자동화

GitHub PR 리뷰 전에 무조건 한 번 돌려요. /review 는 변경된 코드를 읽고 잠재적 버그, 컨벤션 위반, 누락된 에러 핸들링을 짚어줘요. 사람 리뷰어가 보기 전 1차 필터 역할이에요.

놓치기 쉬운 null 체크나 race condition 후보를 잘 짚어주는 편이에요. 변경 규모가 작은 PR일수록 1차 검토가 금방 끝나서, 사람 리뷰어는 설계나 의도 같은 판단 영역에만 집중할 수 있어요.

3. /security-review — 보안 점검 가벼운 버전

/security-review 는 변경 코드에서 OWASP Top 10 패턴을 점검해요. SQL 인젝션, XSS, 시크릿 노출, 부적절한 인증 체크 같은 거요.

제가 자주 쓰는 시나리오는 이런 식이에요.

• 외부 API 호출 코드 추가했을 때 — 시크릿 노출 점검
• 사용자 입력 받는 폼 추가했을 때 — 검증 누락 점검
• 파일 업로드 기능 만들었을 때 — path traversal 점검

매번 직접 점검표 돌리는 것보다 훨씬 빠르고, 빠진 것도 잘 찾아주거든요. 다만 프로덕션 배포 전엔 엔터프라이즈 LLM 보안 체크리스트 같은 별도 감사를 추가하는 걸 권해요.

4. /compact — 긴 대화 메모리 절약

세션이 길어지면 응답이 느려져요. 토큰을 다 써가는 거죠. /compact 는 지금까지 대화를 요약해서 컨텍스트를 압축해줘요.

저는 이렇게 써요.

• 한 작업 완료할 때마다 /compact 한 번
• 다음 세션으로 이어갈 작업이 있으면 끝나기 전에 /compact
• 응답 속도가 느려졌다 싶으면 /compact

요약 후에도 핵심 결정사항과 진행 상태는 그대로 유지돼요. 손해 없는 정리예요.

5. /run-tests — 내가 매일 쓰는 커스텀 명령어

이제 직접 만든 명령어 차례예요. .claude/commands/run-tests.md 파일을 이렇게 만들어두면 끝이에요.

변경된 파일과 관련된 테스트만 골라서 실행해줘.
1. git diff --name-only HEAD~1 로 변경 파일 확인
2. 각 파일에 대응하는 *.test.ts 또는 *.spec.ts 찾기
3. vitest run <file1> <file2> ... 형식으로 실행
4. 실패한 테스트 있으면 원인 분석해서 보고

이러면 /run-tests 한 번에 변경된 파일만 골라서 테스트가 돌아요. 전체 스위트를 처음부터 끝까지 기다리는 것보다 훨씬 빨리 결과를 볼 수 있어서, 커밋 직전 확인용으로 쓰기 좋아요.

6. /commit-msg — 커밋 메시지 자동 생성

.claude/commands/commit-msg.md 안에 이렇게 적어두면 돼요.

git diff --staged 의 내용을 보고 컨벤셔널 커밋 메시지 작성해줘.
- type(scope): subject 형식
- type: feat, fix, refactor, docs, test, chore 중 선택
- subject: 50자 이내, 명령형, 마침표 없음
- 본문은 비워두고 제목만 출력

저는 git stage 한 다음 /commit-msg 호출하고, 출력된 메시지를 그대로 git commit -m "..." 에 붙여요. 의미 없는 "update files" 같은 커밋이 사라졌어요. 블로그 자동화 시스템에서도 이 패턴을 쓰고 있어요.

7. /todo-from-pr — PR 설명을 작업 목록으로

큰 PR 받았을 때 어디서부터 봐야 할지 막막하잖아요. 이 명령어는 PR 본문과 변경 파일 목록을 읽고 체크리스트 형식의 리뷰 작업 목록을 만들어줘요.

gh pr view 명령으로 현재 PR 정보 가져온 다음
변경 파일 카테고리별로 묶어서
"먼저 봐야 할 파일 → 영향받는 테스트 → 수동 검증할 시나리오"
순서로 markdown 체크리스트 만들어줘.

이걸 돌리면 1000줄짜리 PR도 어느 순서로 봐야 할지 명확해져요. 리뷰 시간 절반은 그냥 "어디서부터 봐야 하지?" 였거든요.

7개를 용도별로 정리하면

절감 폭은 프로젝트 규모와 테스트 구성에 따라 크게 달라져요. 표는 "어느 작업에 먼저 붙이면 효과를 체감하기 쉬운지"를 보는 용도로 참고하시고, 실제 효과는 도입 전후로 직접 재보는 게 가장 정확해요.

주의할 점 3가지

• 1차 필터일 뿐이에요 — /review와 /security-review는 사람 리뷰를 대체하지 않아요. 놓치는 항목이 있다는 전제로 쓰세요
• 커스텀 명령어는 짧게 — 프롬프트가 길어질수록 의도가 흐려져요. 단계를 4~5개 이내로 유지하는 편이 결과가 안정적이에요
• 팀 공유 전 검토 — .claude/commands/를 git에 올리면 팀 전체가 같은 명령어를 쓰게 되니, 내부 규칙과 충돌하지 않는지 먼저 확인하세요

커스텀 명령어를 잘 만드는 법

직접 만든 명령어가 기대만큼 안 돌아가는 경우, 원인은 대부분 프롬프트 쪽에 있어요. 몇 가지 요령을 정리했어요.

출력 형식을 못박으세요. "커밋 메시지 만들어줘"보다 "제목 한 줄만 출력, 본문 없음, 마침표 없음"처럼 결과물의 모양을 지정해야 매번 같은 형태로 나와요. 붙여넣어 바로 쓸 수 있는지가 기준이에요.

단계에 번호를 매기세요. 여러 작업을 시키려면 문장을 이어 쓰는 대신 1, 2, 3으로 나누세요. 순서가 명확해지고 중간에 빠뜨리는 단계가 줄어요.

실행할 명령을 그대로 적어두세요. "테스트 돌려줘" 대신 실제로 칠 명령어를 프롬프트 안에 써두면 프로젝트마다 다른 테스트 러너 때문에 헤매는 일이 없어요.

하지 말아야 할 것도 적으세요. "파일을 수정하지 말고 보고만 해줘" 같은 제약을 넣어두면 검토용 명령어가 의도치 않게 코드를 건드리는 사고를 막을 수 있어요.

이름은 동사로 시작하세요. /run-tests, /commit-msg처럼 무엇을 하는지가 이름에 드러나야 나중에 목록에서 찾기 쉬워요. 명령어가 열 개를 넘어가면 이게 꽤 중요해집니다.

팀에서 쓸 때 정해두면 좋은 규칙

명령어를 혼자 쓰다가 팀으로 넓히면 새로운 문제가 생겨요. 미리 합의해두면 좋은 것들이에요.

어디에 둘지 정하기. 프로젝트 공통으로 쓸 명령어는 레포의 .claude/commands/에, 개인 취향이 반영된 것은 ~/.claude/commands/에 두세요. 개인용을 레포에 올리면 다른 사람 작업 흐름과 충돌해요.

리뷰 대상에 포함하기. 명령어 파일도 결국 팀 전체의 작업 방식을 바꾸는 코드예요. 새로 추가하거나 크게 고칠 때는 PR에 포함해서 한 번 훑고 넘어가는 게 좋아요.

결과를 그대로 믿지 않기로 합의하기. 자동 리뷰가 통과했다는 이유로 사람 리뷰를 건너뛰기 시작하면, 도입 전보다 오히려 품질이 떨어질 수 있어요. "1차 필터일 뿐"이라는 전제를 팀 안에서 명시적으로 공유해두세요.

이런 분께 특히 유용해요

혼자 여러 레포를 오가는 개발자, 외주나 인수인계로 낯선 코드베이스를 자주 받는 분, PR 리뷰가 밀려서 병목이 되는 소규모 팀에 효과가 큰 편이에요. 반대로 코드베이스가 하나뿐이고 이미 손에 익었다면 /init 같은 파악용 명령어의 체감은 크지 않아요. 그런 경우엔 커밋 메시지나 테스트 선별처럼 매일 반복되는 잔손질부터 붙여보는 게 좋습니다.

지금 당장 해볼 액션 아이템

1. 터미널에서 claude 실행 후 /help 쳐서 기본 명령어 목록 확인
2. 작업 중인 프로젝트에 /init 한 번 돌리고 CLAUDE.md 검토
3. .claude/commands/ 디렉토리 만들고 위 5번 run-tests.md 부터 복붙

3개만 시작해도 다음 PR부터 체감이 와요. 슬래시 명령어는 "한 번 만들어두면 평생 써먹는" 자산이거든요. Claude Code 개발자 생산성 가이드이 궁금하면 별도 가이드도 같이 봐주세요.