본문 바로가기
개발&프로그래밍

[Claude 커맨드] 팀 공용 Slash Command 만드는 법

by 재아군 2026. 5. 12.
반응형

[Claude 커맨드] 팀 공용 Slash Command 만드는 법 대표 이미지

안녕하세요. 재아군의 관찰인생입니다.

오늘은 Claude 커맨드을 현업 개발자 관점에서 정리해보겠습니다. Claude Code를 어느 정도 쓰기 시작하면 단순 질문보다 팀 규칙, 권한, 비용, 메모리처럼 운영에 가까운 문제가 더 중요해집니다.

Claude Code를 매일 쓰다 보면 같은 지시를 반복하게 됩니다. PR 리뷰, 테스트 추가, 릴리스 노트 작성, 성능 점검 같은 프롬프트는 매번 손으로 치기보다 팀 공용 커맨드로 고정하는 편이 훨씬 안정적입니다.

Claude 커맨드는 자주 쓰는 프롬프트를 Markdown 파일로 저장해 `/명령어` 형태로 실행하는 Claude Code의 Slash Command 기능입니다.

[Claude 커맨드] 팀 공용 Slash Command 만드는 법 개요 다이어그램


1. Claude 커맨드이 중요한 이유

AI 코딩의 품질은 모델만으로 정해지지 않습니다. 같은 도구를 써도 누가 어떤 프롬프트를 쓰는지에 따라 결과가 달라지고, 팀에서는 이 차이가 곧 리뷰 비용으로 이어집니다.

Claude 커맨드는 반복 프롬프트를 파일로 만들고 저장소에 공유할 수 있게 해줍니다. 프로젝트 커맨드는 `.claude/commands/`에 두고, 개인 커맨드는 `~/.claude/commands/`에 둘 수 있습니다.

  • 반복 프롬프트를 팀 표준으로 고정할 수 있습니다.
  • 커맨드 파일에 인자, 설명, 허용 도구를 함께 선언할 수 있습니다.
  • Bash 실행 결과나 파일 참조를 커맨드 컨텍스트에 포함할 수 있습니다.
  • MCP 서버가 노출한 prompts도 slash command처럼 사용할 수 있습니다.
구분 개인 사용 팀 운영
프롬프트 관리 개인 노트나 채팅 기록에 의존 저장소의 `.claude/commands/`로 공유
실행 기준 사람마다 표현이 다름 동일한 명령어와 인자 규칙 사용
권한 제어 대화 권한을 그대로 상속 frontmatter에서 allowed-tools 지정

[Claude 커맨드] 팀 공용 Slash Command 만드는 법 핵심 포인트


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 만드는 법 프로세스 흐름


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.

추천 적용 순서

  1. 반복 빈도가 높은 프롬프트 3개를 고릅니다.
  2. 명령어 이름을 동사형으로 짧게 정합니다.
  3. 출력 형식을 먼저 고정합니다.
  4. Bash 권한은 필요한 명령만 허용합니다.
  5. 팀에서 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 만드는 법 비교 테이블


5. 비슷한 기능과 비교하기

Claude 커맨드는 Hooks, subagents, CLAUDE.md와 함께 쓰면 더 강해집니다. 각각은 비슷해 보여도 역할이 다릅니다.

대안 강점 한계 추천 사용처
Slash Command 반복 프롬프트를 명령어로 실행 작업 자체를 자동 감시하지는 않음 PR 리뷰, 테스트 생성, 요약
Hooks 도구 실행 전후에 자동 개입 설정이 무거우면 흐름을 방해 위험 명령 차단, 종료 전 검사
Subagents 역할별 별도 컨텍스트 사용 역할 설계가 필요 리뷰어, 탐색자, 테스트 담당

비교의 핵심은 기능 이름이 아니라 운영 경계입니다. 같은 자동화라도 개인 로컬 편의인지, 프로젝트 공통 규칙인지, 조직 보안 정책인지에 따라 저장 위치와 승인 흐름이 달라져야 합니다.


6. 도입 전 체크리스트와 실수 방지

가장 흔한 실수는 커맨드를 너무 만능으로 만드는 것입니다. `/do-work`처럼 넓은 명령어는 결국 일반 대화와 다르지 않습니다.

체크 항목 좋은 기준 위험 신호
이름 작업이 바로 드러나는 동사형 무엇이든 처리하는 모호한 이름
권한 명령별 allowed-tools 최소화 Bash 전체 허용
출력 리뷰, 요약, 체크리스트 형식 고정 매번 다른 장문 답변

흔한 실수

  • 개인 커맨드를 검증 없이 프로젝트에 올리는 실수
  • Bash 권한을 넓게 열어두는 실수
  • 인자 사용법을 설명하지 않는 실수
  • 커맨드가 늘어나도 정리 기준을 만들지 않는 실수

[Claude 커맨드] 팀 공용 Slash Command 만드는 법 실전 체크리스트


7. 앞으로의 활용 방향

Claude 커맨드는 팀의 AI 작업 표준을 만드는 가장 가벼운 출발점입니다. 나중에는 MCP prompts와 연결되어 사내 이슈, 문서, 배포 도구까지 slash command로 다루는 흐름이 자연스러워질 수 있습니다.

앞으로 개발팀의 경쟁력은 좋은 프롬프트를 개인 노하우로 숨기는 것이 아니라, 반복 가능한 커맨드와 정책으로 공유하는 데서 나올 가능성이 큽니다.

  • PR 리뷰 커맨드의 팀 표준화
  • MCP prompts 기반 사내 업무 커맨드
  • 커맨드별 allowed-tools 정책 강화
  • 커맨드 실행 결과를 문서와 릴리스 노트로 연결

마무리

정리하면 Claude 커맨드은 Claude Code를 개인 생산성 도구에서 팀 개발 워크플로우로 끌어올리는 핵심 운영 주제입니다. 처음부터 완벽한 표준을 만들기보다, 반복되는 작은 문제 하나를 규칙으로 고정하는 방식이 가장 현실적입니다.

첫 커맨드는 작게 시작하세요. `/review-pr` 하나만 잘 만들어도 팀 리뷰 품질과 속도가 꽤 달라집니다.

이 글이 도움이 되셨다면 댓글로 현재 Claude Code에서 가장 자주 반복하는 작업을 남겨주세요. 다음 글에서 Claude 커맨드을 더 실전적인 예제로 이어가겠습니다.
반응형

댓글