7장. 슬래시 커맨드: 나만의 단축어 만들기

혼자 제품을 만들다 보면 이상한 순간이 온다. 코드를 짜는 시간보다, 이미 여러 번 해본 일을 다시 설명하는 시간이 더 길어진다.

'현재 diff를 리뷰해 줘.' '보안 이슈만 봐 줘.' '테스트 돌리고 실패 원인 정리해 줘.' '커밋 메시지 써 줘.'

이런 요청은 처음에는 자연어로 해도 된다. 하지만 세 번째쯤부터는 감이 온다. 아, 이건 작업이 아니라 습관이구나.

슬래시 커맨드는 그 습관을 파일로 굳혀 주는 장치다. Claude Code에는 /compact, /permissions, /agents, /security-review 같은 내장 커맨드가 이미 많지만, 솔로 빌더에게 더 중요한 것은 자기 일하는 방식을 자기 손으로 명령어로 만드는 일이다.¹ 잘하는 사람의 비밀은 매번 번뜩이는 프롬프트를 치는 데 있지 않다. 자주 이기는 패턴을 저장해 두는 데 있다.

슬래시 커맨드를 한 문장으로 정의하면 이렇다. 반복되는 프롬프트를 이름 붙여 재사용 가능한 작업 버튼으로 만든 것이다. 그리고 이 버튼이 쌓일수록, 혼자 일해도 팀처럼 움직이기 시작한다.

7.1 프로젝트 커맨드 vs 글로벌 커맨드

커스텀 슬래시 커맨드는 마크다운 파일이다. 프로젝트 안의 .claude/commands/에 두면 그 저장소 전용 커맨드가 되고, ~/.claude/commands/에 두면 내 컴퓨터 어디서나 쓸 수 있는 개인 커맨드가 된다.² 파일 경로가 곧 명령어 이름이 되기 때문에, 예를 들어 .claude/commands/review.md는 /review, .claude/commands/db/migrate.md는 /db:migrate가 된다.²

이 구분은 생각보다 중요하다. 솔로 빌더는 늘 두 가지 일을 동시에 하기 때문이다. 하나는 제품마다 다른 일, 다른 하나는 내가 늘 같은 방식으로 하는 일이다.

프로젝트 커맨드는 제품의 문맥을 담아야 한다. 예를 들어 SaaS 프로젝트라면 /ship-ready가 빌드, 테스트, 환경 변수 누락, 결제 플로우, 온보딩 화면까지 확인하도록 만들 수 있다. 반면 글로벌 커맨드는 내 개인 습관을 담는 편이 좋다. /commit, /explain, /summarize-bug처럼 어느 저장소에서도 쓸 수 있는 것들이 여기에 들어간다.

정리하면 이렇게 나누는 것이 편하다.

• 프로젝트 커맨드: 제품 규칙, 배포 절차, 도메인 체크리스트를 담는다.

• 글로벌 커맨드: 내가 자주 쓰는 개인 작업 습관을 담는다.

• 네임스페이스 커맨드: /db:migrate, /ops:incident처럼 분야별로 묶어 커맨드가 늘어나도 찾기 쉽게 만든다.

같은 이름이 겹치면 프로젝트 커맨드가 우선한다. 심지어 프로젝트 안에서 /review 같은 이름으로 내장 커맨드를 덮어써, 우리 프로젝트 방식에 맞는 리뷰 명령으로 바꿀 수도 있다.² 이건 꽤 강력하다. 일반적인 도구를 내 제품의 도구로 바꾸는 순간이기 때문이다.

여기서 한 가지 원칙을 기억해 두자. CLAUDE.md는 헌법이고, 슬래시 커맨드는 작전 카드다. 헌법에는 항상 지켜야 할 기준을 적고, 커맨드에는 특정 상황에서 어떻게 행동할지를 적는다. 둘을 섞으면 커맨드가 길어지고, 길어진 커맨드는 잘 안 쓴다.

7.2 자주 쓰는 커맨드 10개 만들기

슬래시 커맨드의 매력은 단순함에 있다. 본질적으로는 '저장된 프롬프트'지만, 여기에 약간의 설정을 더할 수 있다. 보통은 YAML 프런트매터에 설명, 인자 힌트, 허용 도구, 사용할 모델을 적고, 본문에는 실제 작업 지시를 적는다. 커맨드는 $ARGUMENTS, $1, $2 같은 인자를 받을 수 있고, !로 시작하는 줄에서 셸 출력을 프롬프트에 끼워 넣거나, @파일경로로 특정 파일 내용을 불러와 문맥에 포함시킬 수도 있다.²

말로만 들으면 복잡해 보이지만, 예시는 아주 단순하다.

---
description: 현재 변경사항을 리뷰하고 위험도를 정리한다
argument-hint: [집중할 관점]
allowed-tools:
  - Read
  - Grep
  - Bash(git diff:*)
  - Bash(git status:*)
model: claude-sonnet-4-6
---

현재 변경사항을 리뷰하라.
집중 관점: $ARGUMENTS

작업 전 상태:
!`git status --short`

검토 대상 diff:
!`git diff --staged`

다음 형식으로만 답하라.
1. Critical
2. Important
3. Nit
4. Merge 전에 반드시 확인할 것

스타일 취향은 빼고, 실제 버그 가능성과 회귀 위험 중심으로 정리하라.

이제 /review auth라고 치면, 매번 'staged diff 보고 위험도별로 리뷰해 줘'라고 길게 설명하지 않아도 된다. 더 중요한 점은, 매번 같은 기준으로 검토한다는 것이다. 솔로 빌더에게 가장 무서운 것은 실력이 부족한 것이 아니라, 컨디션에 따라 기준이 흔들리는 것이다.

아래 10개는 거의 모든 솔로 빌더가 먼저 만들어 볼 만한 커맨드들이다.

• /review: 현재 diff를 리뷰한다. 로직, 회귀, 누락된 예외 처리 위주로 본다.

• /security-check: 인증, 권한, 입력 검증, 비밀값 노출, SQL/XSS 위험만 집중적으로 본다.

• /test-gen <파일>: 특정 파일이나 기능에 맞는 단위 테스트 초안을 만든다.

• /fix-ts: 타입 오류를 수집하고, 가장 작은 수정부터 순서대로 해결한다.

• /commit: staged diff를 읽고 Conventional Commits 형식의 메시지를 만든다.

• /pr-body: 변경 이유, 테스트 방법, 영향 범위를 정리한 PR 설명문을 만든다.

• /ship-ready: 린트, 테스트, 빌드, 환경 변수, 마이그레이션 위험까지 배포 전 체크리스트를 수행한다.

• /incident: 에러 로그나 장애 상황을 요약하고, 원인 가설과 즉시 조치안을 나눈다.

• /optimize: 느린 쿼리, 불필요한 렌더링, 무거운 번들처럼 성능 병목을 찾는다.

• /customer-bug <설명>: 사용자 제보를 재현 단계, 가설, 수정 계획, 확인 기준으로 바꿔 준다.

이 중에서 가장 먼저 만들 것을 고르라면 나는 세 개를 추천한다. /review, /ship-ready, /incident다. 이유는 간단하다. 이 세 가지는 제품을 만드는 시간, 내보내는 시간, 망가졌을 때 복구하는 시간을 동시에 단축해 주기 때문이다.

실제로는 커맨드를 10개 한 번에 만들 필요가 없다. 오히려 처음엔 역효과가 난다. 이름은 많은데 손이 안 가는 서랍이 되기 쉽다. 다음 규칙이 더 실용적이다.

• 같은 프롬프트를 세 번 이상 쳤다면 커맨드로 올린다.³

• 한 커맨드는 한 가지 결정만 잘하게 만든다.

• 결과 형식을 강제해 다음 행동이 바로 가능하게 만든다.

예를 들어 /security-check는 '보안 전반을 두루 검토' 같은 넓은 말보다, 출력 형식을 못 박는 편이 낫다.

---
description: 변경사항의 보안 위험만 점검한다
allowed-tools:
  - Read
  - Grep
  - Bash(git diff:*)
model: claude-haiku-4-5
---

현재 diff를 보안 관점에서만 검토하라.

반드시 아래 형식으로 답하라.
- 취약점 요약
- 위험도: high | medium | low
- 문제 파일
- 왜 위험한지
- 최소 수정안

중복 지적은 합치고, 근거가 약한 추측은 제외하라.

여기서 모델을 Haiku로 핀 고정한 이유도 중요하다. 루틴한 검토는 가장 비싼 모델이 아니라, 충분히 좋은 모델을 충분히 자주 쓰는 것이 이긴다. 반대로 아키텍처를 갈아엎는 /redesign-auth 같은 커맨드는 Sonnet이나 Opus로 올리는 편이 맞다.

또 하나 유용한 기능이 @ 참조다. 예를 들어 테스트 생성 커맨드가 있다면 프로젝트의 테스트 컨벤션 문서를 매번 읽게 만들 수 있다.

---
description: 파일에 맞는 테스트를 생성한다
argument-hint: <path>
allowed-tools:
  - Read
  - Edit
  - Write
  - Bash(npm test:*)
---

다음 규칙을 따르라: @docs/testing.md

대상 파일:
@$1

기존 스타일 참고:
@tests/examples/basic.test.ts

해피 패스와 최소 두 개의 엣지 케이스를 포함해 테스트를 작성하라.
작성 후 테스트를 실행하고, 네가 만든 실패만 수정하라.

이 방식의 장점은 분명하다. 프롬프트의 기억력에 기대지 않고, 파일과 출력 형식에 기대게 된다. 혼자 일할수록 이 차이가 크게 난다.

7.3 커맨드에서 서브에이전트 호출하기

슬래시 커맨드가 진짜 재미있어지는 순간은, 단순한 단축어를 넘어 오케스트레이터가 될 때다. 즉, 커맨드 하나가 '무엇을 할지'만 말하는 것이 아니라, '누가 어떤 역할로 나눠서 할지'까지 정해 주는 것이다.

여기서 슬래시 커맨드와 서브에이전트의 역할을 분리해 이해하면 편하다. 슬래시 커맨드는 사용자가 직접 누르는 시작 버튼이고, 서브에이전트는 그 버튼을 눌렀을 때 투입되는 전문 인력이다.³ 다시 말해, 커맨드는 워크플로우를 호출하고, 서브에이전트는 그 안에서 역할을 분업한다.

예를 들어 .claude/agents/에 다음 같은 전문가들을 정의해 두었다고 해 보자.

• architect-reviewer: 구조와 경계 조건을 본다.

• security-reviewer: 인증, 권한, 데이터 노출을 본다.

• test-reviewer: 테스트 누락과 회귀 가능성을 본다.

그럼 /full-review 같은 커맨드는 이렇게 설계할 수 있다.

---
description: 변경사항을 병렬 검토하고 하나의 실행 계획으로 합친다
allowed-tools:
  - Read
  - Grep
  - Bash(git diff:*)
  - Bash(git status:*)
model: claude-sonnet-4-6
---

현재 변경사항을 검토하라.

1. 구조 관점은 architect-reviewer 서브에이전트에 맡긴다.
2. 보안 관점은 security-reviewer 서브에이전트에 맡긴다.
3. 테스트/회귀 관점은 test-reviewer 서브에이전트에 맡긴다.
4. 가능하면 병렬로 진행한다.
5. 마지막에는 중복을 제거하고 하나의 합쳐진 결과만 보고한다.

출력 형식:
- 반드시 수정할 것
- 이번 PR에서는 미뤄도 되는 것
- 근거가 약해 제외한 항목

이렇게 하면 매번 '이번에는 구조도 좀 보고, 보안도 좀 보고, 테스트도 좀 봐 줘'라고 인간 PM처럼 조율하지 않아도 된다. 명령어가 그 역할을 대신한다.

이 아이디어가 과장처럼 들릴 수 있지만, Anthropic이 공개한 코드 리뷰용 커맨드 예시도 비슷한 구조를 따른다. PR 상태를 먼저 확인하고, 관련 규칙 파일을 찾고, 여러 리뷰 에이전트를 병렬로 돌리고, 나온 이슈를 다시 검증해 신호가 높은 것만 남기는 식이다.⁴ 즉, 좋은 커맨드는 한 번의 질문이 아니라 작은 파이프라인이다.

다만 주의할 점도 있다. 모든 커맨드를 다중 에이전트 파이프라인으로 만들 필요는 없다. 오히려 대부분은 그러면 안 된다. /commit이나 /explain처럼 짧고 결정적인 작업은 단일 실행이 더 빠르다. 서브에이전트는 다음 조건일 때만 쓰는 편이 좋다.

• 서로 다른 관점을 분리했을 때 품질이 올라갈 때

• 병렬 실행으로 실제 시간이 줄어들 때

• 마지막에 사람이 읽을 최종 결과를 한 장으로 합칠 수 있을 때

솔로 빌더의 목적은 '복잡한 시스템을 만드는 것'이 아니라 '반복 업무를 덜 생각하고도 안정적으로 끝내는 것'이라는 점을 잊지 말자.

7.4 솔로 빌더의 실전 커맨드 모음

이제 중요한 질문이 남는다. 실제로는 어떤 식으로 굴러가야 할까.

나는 슬래시 커맨드를 도구 상자보다 작은 운영 체제에 가깝게 보는 편이 좋다고 생각한다. 하루를 따라가 보자.

아침에 기능 작업을 시작했으면 /plan-feature로 작업 단위를 정리한다. 점심 전에 /review로 현재 diff를 점검한다. 머지 직전에는 /ship-ready로 린트, 테스트, 빌드, 보안 위험을 한 번에 확인한다. 밤에 에러 알림이 오면 /incident에 로그를 넣고 원인 후보와 임시 조치안을 뽑는다. 다음 날에는 /customer-bug로 사용자 제보를 재현 가능한 이슈로 바꾼다.

이 흐름이 자리 잡으면, Claude Code는 그때그때 기분 따라 말 걸어야 하는 채팅 상대가 아니라 내 제품 운영 플레이북을 실행하는 터미널 도구가 된다.

솔로 빌더에게 특히 잘 맞는 실전 커맨드 묶음은 다음과 같다.

• 개발 묶음: /plan-feature, /test-gen, /fix-ts

• 품질 묶음: /review, /security-check, /optimize

• 출시 묶음: /commit, /pr-body, /ship-ready

• 운영 묶음: /incident, /customer-bug, /postmortem-draft

중요한 것은 개수가 아니라 연결 방식이다. 예를 들어 /ship-ready는 단순히 '준비됐나?'를 묻는 커맨드가 아니라, 혼자서도 배포 게이트를 통과하게 만드는 명령이어야 한다. 출력도 애매하면 안 된다. '대체로 괜찮습니다'가 아니라 아래처럼 끝나야 한다.

• 배포 가능 여부: yes / no

• 막는 항목

• 배포 후 10분 내 확인할 항목

• 롤백이 필요한 조건

이렇게 되면 커맨드는 생각을 줄이는 도구가 된다. 좋은 자동화는 손을 대신 움직이는 게 아니라, 판단 피로를 줄여 준다.

마지막으로, 커맨드를 오래 살아남게 만드는 다섯 가지 규칙을 남기고 싶다.

• 짧게 유지하라. 커맨드가 길어질수록 호출하지 않는다.

• 기준은 CLAUDE.md에, 절차는 커맨드에 둬라. 기본 규칙을 중복해서 적지 마라.³

• 허용 도구를 좁혀라. 설명용 커맨드가 파일을 수정할 필요는 없다.²

• 출력 형식을 강제하라. 다음 행동으로 바로 이어지게 만들어라.

• 커맨드도 코드처럼 리뷰하라. 한 번 만든 뒤 끝이 아니라, 쓸수록 다듬어야 한다.

결국 슬래시 커맨드의 핵심은 거창한 자동화가 아니다. 내가 자주 하는 좋은 판단을 저장하는 일이다. 솔로 빌더는 사람이 적다. 그래서 더더욱, 매번 잘하려고 애쓰기보다 한 번 잘 정의해 두고 계속 재사용하는 편이 강하다.

오늘 /review 하나만 제대로 만들어도, 내일부터의 나는 조금 더 덜 지치고 조금 더 흔들리지 않는다. 그리고 그런 작은 명령어 몇 개가 쌓이면, 어느새 혼자 일하는데도 팀의 운영 리듬이 생긴다.

참고

¹Commands - Claude Code Docs

²Claude Code Slash Commands: Build Reusable Workflows

³Claude Code Custom Commands: Build Your Own AI Agents

⁴code-review.md in anthropics/claude-code