Claude Code 사용법: 슬래시 명령어와 팀 스킬 실전 가이드

팀에서 쓸 만한 명령어에는 입력값, 확인할 근거, 결과물의 형식이 담겨 있습니다. 코드 옆에 보관하는 작업 지시서라고 생각하면 됩니다. 명령어 이름을 입력하면 현재 작업에 맞게 그 지시서가 채워집니다.

먼저 /plan, /diff, /context, /compact를 익히고, 아래 템플릿의 /team-pr-check를 추가합니다. 리뷰는 첫 적용 대상으로 좋습니다. 변경할 때마다 권한, 데이터, 테스트에 관해 같은 질문을 확인하기 때문입니다.

Claude Code 사용법의 기본: 먼저 익힐 내장 명령어

Claude Code에서 메시지를 입력할 때 맨 앞에 아래 명령어를 적습니다. 대괄호는 선택 인수, 꺾쇠괄호는 필수 인수를 뜻합니다. 아래 목록은 2026년 10월 13일에 확인한 Anthropic의 현행 명령어 레퍼런스에 나온 명령어 구문을 그대로 따릅니다. 사용 가능 여부는 플랫폼, 요금제, 환경에 따라 다릅니다.

같은 작업을 이어갈 때는 /compact, 다른 작업으로 넘어갈 때는 /clear를 사용합니다. 기능 개발을 계속하는 중이라면 /compact keep the acceptance criteria, unresolved risks, and exact test commands처럼 지시하면 유용합니다.

/release-notes는 Claude Code 자체의 변경 이력을 엽니다. 개발 중인 애플리케이션의 릴리스 노트를 작성해 주는 명령어는 아닙니다. 아래의 커스텀 명령어는 이와 구분되도록 이름을 다르게 지었습니다.

이 명령어를 일상적인 작업에 활용하는 방법은 Claude Code 모범 사례에서 확인할 수 있습니다.

기본 제공 스킬도 명령어 메뉴에 표시됩니다

슬래시 메뉴의 일부 항목은 Claude에 수행할 절차를 전달합니다. CLI의 고정 제어 기능과는 구별되는 기본 제공 스킬입니다.

• /code-review는 diff나 그 밖의 지원 대상을 리뷰합니다. /review는 같은 기능을 호출하는 별칭입니다. --fix를 붙이면 수정을, --comment를 붙이면 리뷰 댓글 게시를 요청합니다.
• /simplify는 변경된 코드에서 정리할 부분을 검토하고 수정합니다.
• /verify는 애플리케이션을 빌드하고 실행해 동작을 확인합니다.
• /doctor는 설정 문제를 진단하고 해결책을 제안합니다.

코드를 바꾸기 전에 검토 결과부터 보고 싶다면 수정 옵션 없이 리뷰를 실행합니다. 전체 호출 형식과 사전 요건, 사용 가능 여부는 명령어 레퍼런스의 기본 제공 항목에 정리되어 있습니다.

커스텀 명령어는 이제 스킬로 만듭니다

새 절차를 만들 때는 저장소의 .claude/skills/<name>/SKILL.md에 Markdown 지침 파일을 저장합니다. 파일을 커밋하면 팀원도 같은 절차를 받게 됩니다. 개인용 절차는 ~/.claude/skills/<name>/SKILL.md에 둡니다.

기존의 .claude/commands/<name>.md 형식도 계속 사용할 수 있습니다. 두 형식 모두 /<name> 명령어를 만듭니다. 스킬 디렉터리에는 템플릿, 참고 문서, 스크립트도 함께 보관할 수 있으므로 절차가 복잡해질수록 스킬 형식을 권장합니다. Anthropic 스킬 가이드

플러그인 명령어와 MCP 명령어는 어디서 오나요?

플러그인은 재사용할 기능을 패키지로 묶습니다. 플러그인의 skills/<name>/SKILL.md 폴더는 /plugin-name:skill-name처럼 네임스페이스가 붙은 명령어를 만듭니다. 이전 형식의 플러그인 명령어는 commands/에 들어갑니다. 이 폴더들은 매니페스트가 있는 .claude-plugin/ 디렉터리 안이 아니라, 그 디렉터리와 나란히 플러그인 루트에 있어야 합니다. 플러그인 관리에는 /plugin을, 변경 후 적용에는 /reload-plugins를 사용합니다. 플러그인 구성 요소

절차가 하나의 코드베이스에만 해당한다면 프로젝트 스킬로 시작합니다. 여러 저장소에 같은 절차를 배포하고 유지해야 할 때 플러그인을 검토합니다. 직접 새로 만들기 전에 평가해 볼 만한 기존 패키지는 Claude Code 추천 플러그인 가이드에서 살펴볼 수 있습니다.

MCP 프롬프트는 연결된 서버가 제공합니다. MCP는 Model Context Protocol의 약자로, Claude Code를 외부 툴과 데이터에 연결합니다. 서버는 재사용 가능한 프롬프트도 제공할 수 있습니다. 메뉴에는 /servername:promptname (MCP) 형식으로 표시되며, /mcp__servername__promptname으로도 호출할 수 있습니다. 연결된 서버가 해당 프롬프트를 노출할 때만 나타납니다. 툴을 제공하는 연동이라고 해서 원하는 프롬프트까지 모두 제공하는 것은 아닙니다. MCP 프롬프트 문서

MCP 프롬프트의 인수는 공백으로 나뉘며, 서버에 선언된 매개변수를 따릅니다. 프롬프트의 결과는 대화에 추가됩니다. 서버 프롬프트가 로컬 스킬과 같은 방식으로 인수를 처리한다고 가정해서는 안 됩니다.

지침 파일을 만들고 작업에 필요한 값을 전달합니다

프런트매터는 Markdown 지침 앞에 놓이는 짧은 YAML 설정 블록입니다. 블록을 여는 ---는 반드시 파일의 첫 줄에 있어야 합니다. 아래 템플릿에서 알아둘 필드는 다음과 같습니다.

allowed-tools는 권한을 부여하는 설정이며, 사용할 수 있는 툴을 해당 목록으로 제한하는 설정은 아닙니다. 모든 프런트매터 필드는 선택 사항이지만 description은 작성을 권장합니다. 기존 명령어 파일도 name과 paths를 제외한 같은 필드를 지원합니다. 프런트매터 레퍼런스

인수 전달: $ARGUMENTS는 입력 문자열 전체를 삽입합니다. $0 또는 $ARGUMENTS[0]은 첫 번째 인수, $1은 두 번째 인수입니다. 이름이 있는 인수는 지정한 순서대로 위치에 대응합니다. 여러 단어로 된 값을 하나의 위치 인수로 전달하려면 따옴표로 감쌉니다. argument-hint는 입력값을 안내할 뿐이므로, 실제 값이 올바른지는 절차 안에서 확인해야 합니다. 인수 치환

아래 템플릿은 name을 생략하므로 폴더 이름이 명령어 이름이 됩니다. 프런트매터는 기존 명령어 파일 형식에서도 사용할 수 있습니다. 저장소에 관해 오래 유지할 정보는 CLAUDE.md 팀 메모리에, 특정 작업의 수행 단계는 해당 스킬에 둡니다.

복사해서 바로 쓸 수 있는 팀 커스텀 명령어 5가지

아래에 표시된 폴더를 각각 만들고 코드 블록을 SKILL.md에 붙여 넣습니다. /reload-skills를 실행하면 새 파일을 다시 검색합니다. 아래는 팀에 맞게 수정해 쓰도록 직접 작성한 템플릿입니다. Anthropic이 기본 제공하는 명령어가 아니며, 테스트 결과를 제시하는 것도 아닙니다.

반복 가능한 엔지니어링 점검을 먼저, 커뮤니케이션 작업을 나중에 배치했습니다. 템플릿은 가능한 한 로컬 저장소의 근거를 활용합니다. 이슈 트래커나 PR 서비스에 연결하지 않아도 유용한 결과를 만들 수 있습니다.

고객 데이터를 다루는 변경을 위한 PR 리뷰 체크리스트

소규모 SaaS 팀이 사람에게 리뷰를 요청하기 전에 활용할 수 있습니다. 작성자가 급하게 작업하더라도 테넌트 격리, 인가, 테스트 커버리지에 관한 질문을 빠짐없이 확인하도록 합니다. 각 지적 사항에 코드 위치와 실패 상황을 연결해, 리뷰를 넘기는 품질을 일정하게 유지하는 데 도움이 됩니다.

.claude/skills/team-pr-check/SKILL.md로 저장합니다. /team-pr-check main으로 호출하면 현재 브랜치를 main과의 공통 조상인 머지 베이스를 기준으로 리뷰합니다.

---
description: Review a branch against the team's business-risk checklist
argument-hint: "[base-ref]"
disable-model-invocation: true
---

Review the current branch against this base ref: $ARGUMENTS
If no base is supplied, ask for it. Confirm it exists locally.
Read CLAUDE.md and any repository review guidance first.
Inspect the diff from the merge base to HEAD. Report uncommitted
changes separately; do not silently mix them into the branch review.

Check:
- Authorization and tenant boundaries on every changed data path.
- Validation, failure handling, retries and duplicate side effects.
- Schema compatibility, rollout assumptions and rollback options.
- Regression coverage for the changed behavior.
- Secrets, sensitive logs and changes to public contracts.

For each finding: severity, file and line, triggering scenario,
user impact and a concrete repair or test. Separate verified findings
from questions. Mark checks you could not assess as unknown.
Return findings first, then the checklist with pass/fail/unknown
and supporting evidence. If none are found, say so and name gaps.
Review only. Do not edit files, post comments, approve or merge.

체크리스트는 실제로 겪는 실패 유형을 반영할 때 가치가 있습니다. 일반적인 점검 항목을 계정 소유권, 과금 상태, 팀을 통해 상속되는 권한처럼 제품에서 중요한 경계를 확인하는 항목으로 바꿉니다.

재현 가능한 버그를 테스트부터 작성해 수정하기

운영 중인 제품을 직접 관리하는 창업자가 재현 방법이 분명한 버그 제보를 받았을 때 활용할 수 있습니다. 잘못된 동작을 확인하는 과정과 회귀 테스트를 작업 지시서에 포함하므로, 그럴듯한 패치만 내놓고 작업을 끝내지 않도록 합니다.

.claude/skills/team-test-first-fix/SKILL.md로 저장합니다. /team-test-first-fix duplicate webhook events create duplicate invoices로 호출합니다.

---
description: Reproduce a bug with a failing test before fixing it
argument-hint: "[bug description or local issue file]"
disable-model-invocation: true
---

Bug: $ARGUMENTS
If the expected behavior is unclear, ask before changing code.
Read CLAUDE.md, inspect the working tree and preserve unrelated edits.
Find the relevant code and the repository's existing test runner.
Use local fixtures or mocks; do not call production services.

Add the smallest regression test that demonstrates the reported bug.
Run it before changing implementation. Confirm that it fails for
this bug, not because the environment or test setup is broken.
If you cannot demonstrate that failure, explain the blocker and stop.

Make the smallest implementation change that fixes the behavior.
Rerun the regression test and relevant nearby tests. Do not weaken
assertions to obtain a pass or expand into unrelated refactoring.

Report the cause, changed files, failing-before evidence,
passing-after evidence and any tests you could not run.
Do not commit, push or deploy.

이 절차는 재현 가능한 결함에 적합합니다. 근거가 부족한 간헐적 운영 장애라면, 명령어에 실패하는 테스트를 억지로 만들게 하기보다 원인 조사부터 시작합니다.

공유 시스템을 변경하기 전에 마이그레이션 계획 세우기

데이터베이스 스키마를 바꾸거나 API를 교체하는 팀이 구현에 앞서 작업 순서와 호환성 문제를 검토할 때 활용할 수 있습니다. 특히 구버전과 신버전이 함께 실행되는 상황을 두고, 팀원이 타당성을 따져 볼 수 있는 계획을 만드는 데 의미가 있습니다.

.claude/skills/team-migration-plan/SKILL.md로 저장합니다. /team-migration-plan "billing storage" "new invoice schema"로 호출합니다.

---
description: Plan a migration with compatibility checks and rollback gates
argument-hint: "[scope] [target-state]"
arguments: [scope, target]
disable-model-invocation: true
---

Plan a migration of $scope to $target.
If either input is missing or ambiguous, ask for clarification.
Read CLAUDE.md and inspect the current implementation and consumers.
Do not edit files, execute migrations or connect to production.

Describe the current state with file references. List affected data,
APIs, background jobs, integrations and deployment dependencies.
Separate verified facts from assumptions that need an owner.

Propose small phases with dependencies, acceptance checks and a
stop/go decision for each. Include compatibility between old and new
versions, backfill validation, retries and observability.
For each phase, describe rollback or recovery. Flag irreversible
steps and data that a code rollback cannot restore.

Return a reviewable plan, open questions and the smallest safe pilot.
Do not invent a duration, data volume or owner.

계획을 세우라는 지침만으로 Claude Code의 권한 모드가 바뀌지는 않습니다. 세션도 Plan Mode로 전환하려면 이 스킬을 호출하기 전에 /plan을 입력합니다. 문서로 작성한 절차와 세션의 툴 권한은 별개의 제어 수단으로 다뤄야 합니다. Plan Mode

제품의 릴리스 노트 작성하기

릴리스를 담당하는 개발자가 정해진 변경 범위를 고객용 초안으로 정리할 때 활용할 수 있습니다. 커밋을 사용자에게 어떤 영향을 주는지 설명하는 문장으로 바꾸는 수고를 줄이면서, 모든 설명에 근거를 요구합니다.

.claude/skills/team-release-notes/SKILL.md로 저장합니다. /team-release-notes previous-release HEAD로 호출하되, previous-release를 실제로 존재하는 태그나 커밋으로 바꿉니다.

---
description: Draft product release notes from a verified Git range
argument-hint: "[base-ref] [head-ref]"
arguments: [base, head]
disable-model-invocation: true
---

Draft release notes for $base..$head.
If either ref is missing, ask. Confirm both resolve locally.
Read CLAUDE.md and the project's existing release-note format.
Inspect commits in the range and compare the endpoint trees.
Use the changed code and tests to verify what each change does.

Group the draft into Added, Changed, Fixed and Breaking Changes.
Omit empty sections. Describe user impact without exposing internal
secrets or vulnerability details that need coordinated disclosure.
Attach a commit or file reference to each item for the reviewer.
Do not claim a change is deployed, enabled for every customer or
faster by a measured amount without evidence of that fact.

Finish with upgrade actions, unresolved questions and any changes
excluded because their impact could not be established.
Return a draft in chat. Do not edit the changelog, tag a release,
publish, send messages or deploy.

코드 범위로 확인할 수 있는 것은 저장소에서 무엇이 바뀌었는지입니다. 어떤 고객에게 변경 사항이 적용되었는지까지 증명하지는 못합니다. 초안을 게시하기 전에 실제 적용 현황을 확인합니다.

팀을 위한 주간 변경 이력 작성하기

엔지니어링 리드가 제품팀과 고객 지원팀에 주간 소식을 전할 때 활용할 수 있습니다. 머지된 작업과 실제 릴리스가 확인된 작업을 구분하므로, 아직 기능 플래그 뒤에 있는 변경을 이미 제공 중인 것처럼 알리지 않도록 합니다.

.claude/skills/team-weekly-changelog/SKILL.md로 저장합니다. /team-weekly-changelog START_DATE END_DATE main으로 호출하되, 날짜를 시간대가 포함된 ISO 타임스탬프로 바꿉니다. 집계 범위에는 시작 시점이 포함되고 종료 시점은 포함되지 않습니다.

---
description: Draft a weekly engineering changelog from branch history
argument-hint: "[since] [until] [branch]"
arguments: [since, until, branch]
disable-model-invocation: true
---

Prepare a weekly changelog for $branch from $since inclusive to
$until exclusive. If an input is missing, ask. Confirm the timezone
and that the branch exists locally. State whether its checkout may
be stale; do not fetch or assume it matches the remote.

Read CLAUDE.md and the team's update format. Inspect commits reachable
from the branch, filtering by committer timestamp in this window.
Explain that commit timestamps do not prove merge or release dates.
Read diffs for claimed outcomes. Group related changes into themes
and avoid counting a merge and its constituent commits as separate
outcomes. Separate product changes, fixes and maintenance.

For each item, give its impact and a commit or file reference.
Label release status unknown unless deployment evidence is available.
Do not infer blockers, revenue, adoption or completion percentages
from commit messages. List evidence gaps at the end.
Return a concise draft in chat. Do not write files or send the update.

릴리스 노트와 주간 소식은 별도로 관리합니다. 릴리스는 코드의 경계가 명확하고 독자는 고객입니다. 주간 소식은 보고 기간을 기준으로 하며, 아직 출시되지 않은 유용한 작업도 포함할 수 있습니다.

계속 쓸 만한 명령어인지 어떻게 판단하나요?

첫 답변이 얼마나 인상적인지보다, 모델을 사용하는 과정에서 반복되는 작업을 측정합니다.

주간 가치는 다음과 같이 계산합니다. 실행 횟수 × (기존 준비·보정 시간 − 도입 후 준비·보정 시간) × 팀의 시간당 비용 − 추가 모델 비용 − 유지보수 시간을 같은 시간당 비용으로 환산한 금액. 각 항목에는 직접 측정한 값을 넣습니다. 더 긴 프롬프트가 검토할 일을 늘린다면, 자동화가 더 많이 된 것처럼 느껴져도 비용 면에서는 손해일 수 있습니다.

비용 항목 중 달라질 가능성이 가장 높은 것은 시니어 개발자가 같은 절차를 설명하고, 불완전하게 넘겨받은 작업을 보완하는 데 쓰는 시간입니다. 아키텍처나 릴리스 절차가 바뀌면 명령어의 지침도 계속 관리해야 합니다.

저장해 둔 명령어라도 Claude가 지침을 수행할 때는 모델 사용량이 발생합니다. /usage는 토큰 비용 추정치와 요금제 사용량 정보를 보여 줍니다. 화면에 표시되는 API 비용 추정치는 구독 요금 청구서가 아닙니다. Anthropic 비용 문서

이 명령어를 바탕으로 만들어 볼 만한 제품 2가지

이 템플릿은 내부 툴로 유용합니다. 제품으로 만들려면 프롬프트를 저장해 주는 것 이상의, 쉽게 따라 하기 어려운 강점이 필요합니다.

가장 유망한 기회: 저장소에 맞춘 리뷰 점검 패키지

소규모 소프트웨어 팀은 자사의 위험도가 높은 경계를 이해하고 꾸준히 관리되는 리뷰 패키지에 비용을 지불할 수 있습니다. 어느 테이블이 특정 계정에 속하는지, 어떤 작업이 과금에 영향을 주는지, 변경 시 어떤 테스트가 함께 있어야 하는지를 파악하는 패키지입니다.

2026년 10월 13일 DataForSEO의 미국 Google 영어 키워드 개요에서 “ai code review”의 추정 월간 검색량은 1,300회였습니다. 이는 해당 작업에 대한 관심을 보여 주는 지표이며, 특정 Claude Code 플러그인에 대한 수요를 뜻하지는 않습니다. DataForSEO 키워드 개요

판매 가능한 최소 구성은 프로젝트 체크리스트, 이를 뒷받침하는 아키텍처 문서, 과거 버그로 만든 평가 세트가 될 수 있습니다. 플러그인으로 배포하기 전에, 그 사례들에서 근거를 갖춘 지적 사항을 만들어 내는지 확인합니다.

문제는 경쟁이 치열하다는 점입니다. Claude Code에는 이미 리뷰 기능이 있고, CodeRabbit도 코드 리뷰 툴을 판매합니다. 일반적인 리뷰 프롬프트만으로는 차별화가 어렵습니다. 저는 특정 팀의 장애·실패 이력에 접근할 수 있고, 점검 항목의 정확성을 유지할 담당자가 있을 때만 이 기회를 선택하겠습니다.

작은 규모로 시작할 기회: 근거를 갖춘 릴리스 커뮤니케이션

제품팀은 저장소의 변경 사항을 고객용 릴리스 노트와 내부 고객 지원 브리핑으로 연결하는 워크플로를 활용할 수 있습니다. 근거 자료의 참조와 명시적인 적용 현황 점검을 포함하고, 지속해서 관리하는 방식입니다.

같은 키워드 개요에서 “release notes generator”의 추정 월간 검색량은 70회였습니다. 검색 수요 신호가 크지 않으므로, 저는 독립형 소프트웨어를 만들기 전에 서비스나 내부 워크플로부터 시작하겠습니다. DataForSEO 키워드 개요

최소 구성으로는 선택한 Git 범위에서 팀의 기존 형식에 맞는 초안을 만들 수 있습니다. 어려운 부분은 코드 변경을 기능 플래그, 배포, 고객의 실제 사용 가능 여부와 연결하는 일입니다. 명령어는 근거를 정리할 수 있지만, 팀이 기록하지 않은 근거를 만들어 낼 수는 없습니다.

실제 제품 코드베이스에서 알아둘 한계

명령어는 지침을 표준화합니다. 결과를 받아들일 수 있는지는 여전히 테스트, 리뷰, 릴리스 통제 절차로 판단해야 합니다. 다섯 템플릿을 출발점으로 삼고, 템플릿 변경 사항도 애플리케이션 코드와 함께 리뷰합니다.

스킬의 전체 내용은 사용할 때 로드됩니다. 따라서 절차는 간결하게 작성하고 자세한 참고 자료는 보조 파일에 둡니다. 이름이 같으면 개인 스킬이 프로젝트 스킬보다 우선할 수 있으며, 로컬 터미널 세션에서는 스킬이 내장 명령어보다 우선해 호출될 수도 있습니다. 구별하기 쉬운 이름을 사용하고, 팀원마다 동작이 다르면 어떤 소스에서 로드되었는지 확인합니다. 스킬 로딩과 우선순위

권한은 실제 툴 규칙으로 별도 설정합니다. “리뷰만 수행”이라는 문장은 Claude에 의도를 전달하는 지침이지, 운영체제 수준의 제한이 아닙니다. Claude Code 권한

다음 업무일에 먼저 해 볼 일

먼저 /team-pr-check를 커밋합니다. 일반적인 항목을 최근 문제가 되었던 변경에서 통과했어야 할 점검 항목으로 바꿉니다. 결과를 알고 있는 완료된 변경에 실행해 실제 문제와 지적 사항을 비교하고, 팀의 일상 절차로 정착시키기 전에 지침을 다듬습니다. 릴리스 노트와 주간 소식 명령어는 결과물의 형식에 합의한 뒤 추가합니다.

이 워크플로를 업무 시스템과 연결하고 싶다면, 팀에 실제로 필요한 점검 절차를 중심으로 AI 자동화를 구축해 드립니다.