Claude Code 슬래시 커맨드 직접 만들기: 반복 프롬프트를 작업 버튼처럼 쓰는 법

왜 슬래시 커맨드를 만들어야 할까

Claude Code를 쓰다 보면 같은 말을 계속 반복하게 됩니다. “변경사항을 보고 커밋 메시지를 써줘”, “이 함수의 책임을 나눠줘”, “PR 설명을 한국어로 정리해줘” 같은 요청입니다. 처음에는 자연어로 매번 입력해도 괜찮지만, 프로젝트가 길어질수록 프롬프트의 품질이 흔들립니다.

슬래시 커맨드는 이 반복 프롬프트를 파일로 저장해 /명령어처럼 호출하는 방식입니다. 핵심은 자동화 자체보다 “작업 기준을 고정한다”는 데 있습니다. 혼자 개발할 때도 커밋 스타일, 리뷰 관점, 리팩토링 범위를 일정하게 유지할 수 있습니다.

커맨드화할 작업을 고르는 기준

모든 프롬프트를 커맨드로 만들 필요는 없습니다. 커맨드로 만들기 좋은 작업은 대체로 세 가지 조건을 만족합니다.

기준	설명	예시
반복성	일주일에 여러 번 요청한다	커밋 메시지, PR 요약
형식성	결과물의 구조가 정해져 있다	체크리스트, 릴리즈 노트
위험 관리	매번 같은 제약을 지켜야 한다	마이그레이션 리뷰, 보안 점검

반대로 한 번만 하는 탐색성 질문이나 맥락이 매번 크게 달라지는 기획 토론은 커맨드보다 일반 대화가 낫습니다. 커맨드는 “정답을 찾는 도구”라기보다 “반복되는 작업 방식을 저장하는 도구”에 가깝습니다.

기본 구조: 명령어는 작은 작업 단위로

보통 커스텀 커맨드는 명령어 이름에 대응하는 마크다운 파일로 관리합니다. 예를 들어 프로젝트 안에 커맨드 파일을 두고, 그 안에 Claude에게 맡길 역할·입력·출력 형식을 적는 식입니다. 팀이나 도구 버전에 따라 경로와 동작 방식은 조금씩 확인이 필요하지만, 원칙은 단순합니다.

좋은 커맨드는 한 번에 하나의 결과물을 만듭니다.

변경사항을 검토하고 커밋 메시지 후보를 작성해줘.

조건:
- Conventional Commits 형식을 우선 사용
- 변경 범위가 섞여 있으면 커밋을 나눌지 제안
- 메시지는 한국어로 작성
- 불확실한 변경은 단정하지 말고 질문으로 남김

이 정도면 /commit-msg 같은 이름으로 호출하기 좋습니다. 중요한 점은 “좋은 커밋 메시지를 써줘”에서 끝내지 않고, 판단 기준과 출력 형식을 함께 넣는 것입니다.

인자 전달은 느슨하게, 출력은 엄격하게

커맨드가 유용해지는 순간은 인자를 받을 때입니다. 예를 들어 /refactor auth-flow처럼 범위를 넘기면, 커맨드는 해당 범위만 분석하도록 설계할 수 있습니다. 여기서 인자는 보통 사용자가 덧붙이는 자유 텍스트라고 생각하면 됩니다.

설계 패턴은 간단합니다.

인자 없음: 현재 변경사항이나 현재 파일을 기준으로 작업
짧은 인자: 대상 파일, 기능명, 브랜치 목적처럼 범위 지정
긴 인자: 추가 제약, 제외할 파일, 원하는 톤 전달

예시는 이렇게 만들 수 있습니다.

다음 인자를 작업 범위로 해석해 리팩토링 계획을 세워줘: $ARGUMENTS

출력:
1. 현재 문제
2. 바꿀 파일
3. 작은 단계의 수정 순서
4. 테스트해야 할 항목

제약:
- 코드 변경은 아직 하지 말고 계획만 작성
- 공개 API 변경이 필요하면 먼저 표시

입력은 유연하게 받되, 출력은 늘 같은 구조로 고정하는 편이 좋습니다. 그래야 나중에 결과를 빠르게 훑고 실행 여부를 결정할 수 있습니다.

1인 빌더에게 유용한 커맨드 예시

처음부터 많은 커맨드를 만들기보다, 병목이 자주 생기는 지점부터 시작하세요.

커밋 메시지 작성

/commit-msg는 가장 먼저 만들 만합니다. 변경사항을 읽고 커밋 후보를 2~3개 제안하게 하되, 관련 없는 변경이 섞였는지 확인하도록 넣어두면 좋습니다. 혼자 작업할수록 커밋이 커지기 쉬우므로 “나눌 수 있는 커밋 단위”를 묻는 조건이 도움이 됩니다.

PR 설명 생성

혼자 만든 프로젝트라도 배포 전 정리용 PR이나 변경 기록은 유용합니다. /pr-summary는 변경 목적, 주요 수정, 테스트 결과, 남은 리스크를 같은 형식으로 뽑게 만들 수 있습니다. 나중에 릴리즈 노트나 블로그 회고를 쓸 때도 재료가 됩니다.

리팩토링 계획

/refactor-plan 결제 흐름처럼 호출하면 바로 코드를 바꾸기보다 먼저 영향 범위를 정리하게 하세요. 1인 개발자는 속도가 장점이지만, 리팩토링에서는 멈춤이 더 중요할 때가 많습니다. “수정 전 계획만 작성”이라는 제약을 넣으면 과한 변경을 줄이는 데 도움이 됩니다.

커맨드가 늘어날 때 관리 규칙

커맨드가 10개를 넘으면 이름이 더 중요해집니다. 동사보다 결과물 중심으로 짓는 편이 찾기 쉽습니다. /write-pr보다 /pr-summary, /check-code보다 /review-risk처럼 결과가 드러나는 이름이 좋습니다.

또한 커맨드 안에는 프로젝트 고유 규칙을 너무 많이 복붙하지 않는 편이 좋습니다. 공통 규칙은 별도 프로젝트 지침 파일에 두고, 커맨드에는 해당 작업의 목적과 출력 형식만 남기면 유지보수가 쉽습니다.

마지막으로 커맨드는 주기적으로 삭제해야 합니다. 더 이상 쓰지 않는 명령이 쌓이면 오히려 선택 비용이 생깁니다. 한 달에 한 번 정도 “최근에 실제로 호출한 커맨드만 남긴다”는 기준으로 정리하면 충분합니다.

오늘 바로 만들 3개

처음 시작한다면 아래 세 개면 충분합니다.

/commit-msg: 변경사항 기반 커밋 메시지 후보 작성
/pr-summary: 배포 전 변경 요약과 테스트 항목 정리
/refactor-plan: 코드 수정 전 리팩토링 범위와 순서 설계

슬래시 커맨드의 목적은 멋진 자동화가 아니라, 반복되는 판단을 덜 흔들리게 만드는 것입니다. 1인 빌더에게 가장 부족한 것은 시간이기도 하지만, 같은 품질로 반복할 수 있는 작업 루틴이기도 합니다. 자주 쓰는 프롬프트 하나를 파일로 옮기는 것부터 시작해보세요.