![[Claude 커맨드] 팀 공용 Slash Command 만드는 법 대표 이미지](https://blog.kakaocdn.net/dna/mYnDY/dJMcabYq4Xr/AAAAAAAAAAAAAAAAAAAAAB33GdasHQUM8f3hREWqbcoSnud6pWmZKK6QtN5popXi/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1780239599&allow_ip=&allow_referer=&signature=mM3aMRWjKHsog0E8g4i1mVXuu6s%3D)
안녕하세요. 재아군의 관찰인생입니다.
오늘은 Claude 커맨드을 현업 개발자 관점에서 정리해보겠습니다. Claude Code를 어느 정도 쓰기 시작하면 단순 질문보다 팀 규칙, 권한, 비용, 메모리처럼 운영에 가까운 문제가 더 중요해집니다.
Claude Code를 매일 쓰다 보면 같은 지시를 반복하게 됩니다. PR 리뷰, 테스트 추가, 릴리스 노트 작성, 성능 점검 같은 프롬프트는 매번 손으로 치기보다 팀 공용 커맨드로 고정하는 편이 훨씬 안정적입니다.
Claude 커맨드는 자주 쓰는 프롬프트를 Markdown 파일로 저장해 `/명령어` 형태로 실행하는 Claude Code의 Slash Command 기능입니다.
![[Claude 커맨드] 팀 공용 Slash Command 만드는 법 개요 다이어그램](https://blog.kakaocdn.net/dna/bi9haV/dJMcahEjlsp/AAAAAAAAAAAAAAAAAAAAACnElb4gPuoTTcN_kZfbsrF0fAur1gtI0e8YHApJgJAA/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1780239599&allow_ip=&allow_referer=&signature=ohf9qxYhiFCUmH6kY%2BAcI78A8%2Bs%3D)
1. Claude 커맨드이 중요한 이유
AI 코딩의 품질은 모델만으로 정해지지 않습니다. 같은 도구를 써도 누가 어떤 프롬프트를 쓰는지에 따라 결과가 달라지고, 팀에서는 이 차이가 곧 리뷰 비용으로 이어집니다.
Claude 커맨드는 반복 프롬프트를 파일로 만들고 저장소에 공유할 수 있게 해줍니다. 프로젝트 커맨드는 `.claude/commands/`에 두고, 개인 커맨드는 `~/.claude/commands/`에 둘 수 있습니다.
- 반복 프롬프트를 팀 표준으로 고정할 수 있습니다.
- 커맨드 파일에 인자, 설명, 허용 도구를 함께 선언할 수 있습니다.
- Bash 실행 결과나 파일 참조를 커맨드 컨텍스트에 포함할 수 있습니다.
- MCP 서버가 노출한 prompts도 slash command처럼 사용할 수 있습니다.
| 구분 | 개인 사용 | 팀 운영 |
|---|---|---|
| 프롬프트 관리 | 개인 노트나 채팅 기록에 의존 | 저장소의 `.claude/commands/`로 공유 |
| 실행 기준 | 사람마다 표현이 다름 | 동일한 명령어와 인자 규칙 사용 |
| 권한 제어 | 대화 권한을 그대로 상속 | frontmatter에서 allowed-tools 지정 |
![[Claude 커맨드] 팀 공용 Slash Command 만드는 법 핵심 포인트](https://blog.kakaocdn.net/dna/bwOKfb/dJMcaf0NjG1/AAAAAAAAAAAAAAAAAAAAANakfIY_Fb_4JrZfSiMiqODrlbyZT6-BNUaGi7nG_Zhl/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1780239599&allow_ip=&allow_referer=&signature=EUgUs0OZTZ47PPVa61YUwb46Qp4%3D)
2. 공식 구조로 이해하기
공식 문서 기준으로 Slash Command는 Markdown 파일 이름이 명령어 이름이 됩니다. 프로젝트 커맨드는 저장소 내부 `.claude/commands/`, 개인 커맨드는 홈 디렉터리 `~/.claude/commands/`에 저장합니다.
| 구성 요소 | 공식 동작 기준 | 실무 적용 포인트 |
|---|---|---|
| 명령어 이름 | 파일명에서 `.md`를 뺀 값 | 짧고 동사 중심으로 작성 |
| 인자 | $ARGUMENTS 또는 $1, $2 사용 | 이슈 번호, PR 번호, 우선순위에 적합 |
| Frontmatter | description, argument-hint, allowed-tools 등 지원 | 자동완성과 권한 제한에 활용 |
팀 공용 커맨드는 “프롬프트 저장소”라기보다 작은 운영 인터페이스에 가깝습니다. 좋은 커맨드는 이름만 봐도 언제 쓰는지 알 수 있고, 실행 결과 형식도 반복 가능합니다.
Developer runs /review-pr 123
-> Claude loads .claude/commands/review-pr.md
-> Arguments are injected
-> Optional Bash or file context is added
-> Claude performs the standardized task
![[Claude 커맨드] 팀 공용 Slash Command 만드는 법 프로세스 흐름](https://blog.kakaocdn.net/dna/brq5lX/dJMcaf0NjG6/AAAAAAAAAAAAAAAAAAAAANuGG5EUzcT_PQ7eIJTRHpUo5-9xTTeS2yBSD_1MghIs/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1780239599&allow_ip=&allow_referer=&signature=lf3WCuuLeJ6xXnOOygqcegOn2Q0%3D)
3. 실무 설정 예시
가장 먼저 만들기 좋은 커맨드는 PR 리뷰입니다. 반복성이 높고, 팀마다 리뷰 기준이 다르며, 결과 형식을 강제했을 때 품질 차이가 크게 줄어듭니다.
---
description: Review a pull request
argument-hint: [pr-number]
allowed-tools: Bash(gh pr diff:*)
---
Review PR #$1. Focus on bugs and missing tests.
커맨드에서 Bash 결과를 컨텍스트로 넣을 수도 있습니다. 이때는 allowed-tools에 실행 가능한 명령을 좁게 지정해야 합니다.
---
allowed-tools: Bash(git status:*), Bash(git diff:*)
description: Summarize current changes
---
Current status: !`git status --short`
Summarize the change and test risk.
추천 적용 순서
- 반복 빈도가 높은 프롬프트 3개를 고릅니다.
- 명령어 이름을 동사형으로 짧게 정합니다.
- 출력 형식을 먼저 고정합니다.
- Bash 권한은 필요한 명령만 허용합니다.
- 팀에서 2주 사용한 뒤 커맨드 설명과 인자를 다듬습니다.
4. 팀 워크플로우에 넣는 방법
팀에서는 `/review-pr`, `/write-tests`, `/release-note`, `/debug-failure` 같은 커맨드가 특히 효과적입니다. 이 커맨드들은 개인 생산성보다 팀의 결과물 형식 표준화에 더 큰 가치가 있습니다.
커맨드가 늘어나면 디렉터리로 분류할 수 있지만, 실제 명령어 이름 충돌에는 주의해야 합니다. 공식 문서 기준으로 하위 디렉터리는 설명에 표시되지만 기본 명령 이름 자체를 완전히 별도 네임스페이스로 만드는 것은 아닙니다.
| 상황 | 추천 방식 | 주의점 |
|---|---|---|
| PR 리뷰 | /review-pr [번호] | 스타일보다 버그와 테스트 누락 우선 |
| 테스트 생성 | /write-tests [파일] | 수정 범위를 테스트 파일로 제한 |
| 릴리스 노트 | /release-note [범위] | git log와 이슈 링크 기준 명확화 |
- 명령어 이름은 2단어 이하로 유지합니다.
- argument-hint를 넣어 사용자가 인자 형식을 기억하지 않게 합니다.
- allowed-tools는 커맨드별 최소 권한으로 둡니다.
- 프로젝트 커맨드와 개인 커맨드 이름 충돌을 피합니다.
![[Claude 커맨드] 팀 공용 Slash Command 만드는 법 비교 테이블](https://blog.kakaocdn.net/dna/MrVzE/dJMcaarG4Fz/AAAAAAAAAAAAAAAAAAAAAG_pO3dsfCEctNmyEgcpPA9H6N04_hzrJ6fWLbfzY_zB/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1780239599&allow_ip=&allow_referer=&signature=aR4cKTddGN%2ForUfjs41lqzpzR8w%3D)
5. 비슷한 기능과 비교하기
Claude 커맨드는 Hooks, subagents, CLAUDE.md와 함께 쓰면 더 강해집니다. 각각은 비슷해 보여도 역할이 다릅니다.
| 대안 | 강점 | 한계 | 추천 사용처 |
|---|---|---|---|
| Slash Command | 반복 프롬프트를 명령어로 실행 | 작업 자체를 자동 감시하지는 않음 | PR 리뷰, 테스트 생성, 요약 |
| Hooks | 도구 실행 전후에 자동 개입 | 설정이 무거우면 흐름을 방해 | 위험 명령 차단, 종료 전 검사 |
| Subagents | 역할별 별도 컨텍스트 사용 | 역할 설계가 필요 | 리뷰어, 탐색자, 테스트 담당 |
비교의 핵심은 기능 이름이 아니라 운영 경계입니다. 같은 자동화라도 개인 로컬 편의인지, 프로젝트 공통 규칙인지, 조직 보안 정책인지에 따라 저장 위치와 승인 흐름이 달라져야 합니다.
6. 도입 전 체크리스트와 실수 방지
가장 흔한 실수는 커맨드를 너무 만능으로 만드는 것입니다. `/do-work`처럼 넓은 명령어는 결국 일반 대화와 다르지 않습니다.
| 체크 항목 | 좋은 기준 | 위험 신호 |
|---|---|---|
| 이름 | 작업이 바로 드러나는 동사형 | 무엇이든 처리하는 모호한 이름 |
| 권한 | 명령별 allowed-tools 최소화 | Bash 전체 허용 |
| 출력 | 리뷰, 요약, 체크리스트 형식 고정 | 매번 다른 장문 답변 |
흔한 실수
- 개인 커맨드를 검증 없이 프로젝트에 올리는 실수
- Bash 권한을 넓게 열어두는 실수
- 인자 사용법을 설명하지 않는 실수
- 커맨드가 늘어나도 정리 기준을 만들지 않는 실수
![[Claude 커맨드] 팀 공용 Slash Command 만드는 법 실전 체크리스트](https://blog.kakaocdn.net/dna/OHOcS/dJMcabc05ZA/AAAAAAAAAAAAAAAAAAAAABSGG7gfIKrc7v80MHDLBOu2v9NcC6wNo2bN6RW4c-vA/img.png?credential=yqXZFxpELC7KVnFOS48ylbz2pIh7yKj8&expires=1780239599&allow_ip=&allow_referer=&signature=RIPpEqn7GBgn270psmL0HCmioN8%3D)
7. 앞으로의 활용 방향
Claude 커맨드는 팀의 AI 작업 표준을 만드는 가장 가벼운 출발점입니다. 나중에는 MCP prompts와 연결되어 사내 이슈, 문서, 배포 도구까지 slash command로 다루는 흐름이 자연스러워질 수 있습니다.
앞으로 개발팀의 경쟁력은 좋은 프롬프트를 개인 노하우로 숨기는 것이 아니라, 반복 가능한 커맨드와 정책으로 공유하는 데서 나올 가능성이 큽니다.
- PR 리뷰 커맨드의 팀 표준화
- MCP prompts 기반 사내 업무 커맨드
- 커맨드별 allowed-tools 정책 강화
- 커맨드 실행 결과를 문서와 릴리스 노트로 연결
마무리
정리하면 Claude 커맨드은 Claude Code를 개인 생산성 도구에서 팀 개발 워크플로우로 끌어올리는 핵심 운영 주제입니다. 처음부터 완벽한 표준을 만들기보다, 반복되는 작은 문제 하나를 규칙으로 고정하는 방식이 가장 현실적입니다.
첫 커맨드는 작게 시작하세요. `/review-pr` 하나만 잘 만들어도 팀 리뷰 품질과 속도가 꽤 달라집니다.
이 글이 도움이 되셨다면 댓글로 현재 Claude Code에서 가장 자주 반복하는 작업을 남겨주세요. 다음 글에서 Claude 커맨드을 더 실전적인 예제로 이어가겠습니다.
'개발&프로그래밍' 카테고리의 다른 글
| [Claude 권한관리] 위험 명령 차단과 승인 플로우 (0) | 2026.05.12 |
|---|---|
| [AI 코딩 워크플로우] Claude·Codex·Copilot 역할 나누기 (0) | 2026.05.11 |
| [Copilot 에이전트] GitHub 이슈에서 PR까지 맡기는 법 (0) | 2026.05.11 |
| [Claude 서브에이전트] 역할별 AI 팀 만드는 실전 가이드 (0) | 2026.05.11 |
| [Codex 리뷰] GitHub PR 코드리뷰 자동화 가이드 (0) | 2026.05.10 |
댓글