2026-10-06 개발자를 위한 Claude Code 추천 명령어

Claude Code에서 /를 누르면 명령어가 수십 개 나온다. 전부 외우는 대신, 실제로 많이 쓰는 사람들이 반복해서 추천하는 것을 기준으로 골랐다. 공식 베스트 프랙티스 문서, Claude Code를 만든 Boris Cherny의 작업 방식을 다룬 기사, 개발자들의 사용 후기와 팁 모음을 읽고, 명령어 자체는 공식 문서로 다시 확인했다.

기준: 2026-10-06에 확인한 Claude Code 공식 문서다. Claude Code는 업데이트가 잦아서 명령어 이름이나 동작이 바뀔 수 있고, 일부 기능은 버전·요금제·설정에 따라 보이지 않는다. 내 환경에서는 /를 입력해 보거나 /help로 확인하는 게 가장 정확하다.

0. 먼저, 사람들이 공통으로 하는 말

출처가 달라도 반복해서 나오는 조언은 몇 가지로 모인다. 명령어는 결국 이 원칙을 실천하는 도구다.

1. 컨텍스트가 가장 중요한 자원이다. 공식 문서는 대부분의 베스트 프랙티스가 "컨텍스트 창은 빨리 차고, 찰수록 성능이 떨어진다"는 한 가지 제약에서 나온다고 설명한다. 그래서 /clear를 자주 쓰라는 조언이 가장 많다.
2. 바로 코딩시키지 말고 계획부터. 계획 모드에서 계획을 충분히 다듬은 뒤 실행하면 구현을 한 번에 끝내는 경우가 많다는 이야기가 Boris Cherny의 작업 방식에서도, 공식 문서에서도 나온다.
3. Claude가 스스로 확인할 수단을 줘라. Boris Cherny가 가장 중요하다고 꼽은 팁이다. 테스트, 빌드, 브라우저 확인처럼 통과·실패가 나오는 검사가 있어야 Claude가 혼자 반복하며 고칠 수 있다.
4. CLAUDE.md는 짧게, 실수할 때마다 고쳐라. Boris Cherny의 팀은 Claude가 실수할 때마다 CLAUDE.md에 기록해 같은 실수를 반복하지 않게 한다. 반대로 너무 길면 규칙이 묻혀 무시된다.
5. 처음부터 과하게 세팅하지 마라. 플러그인과 스킬을 잔뜩 설치하기보다 기본으로 시작해서, 반복되는 불편이 생길 때 하나씩 추가하라는 조언이 여러 곳에서 나온다.

처음이라면 이 다섯 개부터

1. 세션 시작과 복귀

/init — 프로젝트 안내서 만들기

프로젝트 구조를 읽고 CLAUDE.md를 만든다. CLAUDE.md는 매 세션 시작 때 자동으로 읽히는 프로젝트 메모다.

생성된 내용은 초안이다. 공식 문서는 각 줄마다 "이 줄을 지우면 Claude가 실수할까?"를 묻고, 아니면 지우라고 권한다.

가끔만 필요한 지식은 CLAUDE.md 대신 스킬로 빼면 필요할 때만 불러온다(7장). /context로 CLAUDE.md가 실제로 로드됐는지 확인할 수 있다.

예전 글에는 프롬프트 앞에 #을 붙여 메모를 추가하는 팁이 자주 나오는데, 현재 공식 단축키 목록에는 없다. 지금은 /memory로 CLAUDE.md를 열어 고치거나, Claude에게 "이 규칙을 CLAUDE.md에 추가해 줘"라고 요청하면 된다.

claude -c, claude -r, /resume, /rename — 하던 작업 이어 하기

claude -c                    # 현재 디렉터리의 가장 최근 대화 이어 하기claude -r "oauth-migration"  # 이름(또는 ID)으로 특정 세션 재개

공식 문서는 세션에 oauth-migration처럼 이름을 붙이고 git 브랜치처럼 다루라고 권한다. 작업 줄기마다 자기 컨텍스트를 가지게 하는 것이다. 세션 안에서 /rename을 쓰고, /resume으로 목록을 열어 고른다.

2. 컨텍스트 관리

/clear — 가장 많이 추천되는 명령어

빈 컨텍스트로 새 대화를 시작한다. 이전 대화는 /resume으로 다시 열 수 있다.

공식 문서가 꼽는 대표 실수 두 가지가 여기에 해당한다.

• 잡탕 세션: 한 작업 중에 관계없는 질문을 하고 다시 돌아오면 컨텍스트가 관계없는 정보로 찬다. → 작업 사이에 /clear.
• 같은 걸 계속 고치기: 두 번 고쳤는데도 안 되면 컨텍스트에 실패한 시도가 쌓여 있다는 신호다. → /clear하고, 지금까지 배운 것을 반영해 처음 프롬프트를 더 잘 쓴다.

"긴 세션에서 계속 고치는 것보다 깨끗한 세션에 더 나은 프롬프트가 거의 항상 낫다"는 게 공식 문서의 설명이다.

/compact [지시] — 같은 작업을 이어 갈 때

지금까지의 대화를 요약해서 공간을 확보한다. 뒤에 지시를 붙이면 요약 방향을 정할 수 있다.

/compact API 변경 사항과 남은 TODO 위주로 요약

기준은 간단하다. 같은 작업이면 /compact, 다른 작업이면 /clear.

요약 때 꼭 남겨야 할 것을 CLAUDE.md에 적어 둘 수도 있다. 예: "요약할 때는 수정한 파일 목록과 테스트 명령을 항상 유지할 것."

/context와 상태 줄 — 얼마나 찼는지 보기

/context는 컨텍스트 사용량을 색깔 격자로 보여 주고, 많이 차지하는 도구·메모리 파일과 줄이는 방법을 제안한다.

계속 확인하고 싶다면 /statusline으로 화면 하단 상태 줄에 모델, git 브랜치, 컨텍스트 사용량 등을 띄울 수 있다. 원하는 모양을 말로 설명하면 설정해 준다. 공식 문서도, 팁을 모은 GitHub 저장소 claude-code-tips도 상태 줄을 앞쪽에서 추천한다.

/btw — 대화를 더럽히지 않는 곁가지 질문

/btw 이 프로젝트에서 쓰는 Java 버전이 뭐였지?

답이 대화 기록에 들어가지 않아서 컨텍스트를 늘리지 않고 잠깐 확인할 수 있다.

"서브에이전트로 조사해 줘"

명령어는 아니지만 공식 문서가 강조하는 습관이다. 코드베이스를 조사하면 파일을 많이 읽고, 그게 전부 컨텍스트를 차지한다. 서브에이전트는 별도 컨텍스트에서 조사하고 요약만 돌려준다.

서브에이전트로 인증 시스템이 토큰 갱신을 어떻게 처리하는지,재사용할 만한 OAuth 유틸이 있는지 조사해 줘

3. 실수 되돌리기와 안전장치

Esc — 중간에 멈추기

방향이 틀렸다 싶으면 기다리지 말고 바로 Esc. 지금까지 한 작업은 유지되므로 바로 방향을 다시 잡아 주면 된다. Ctrl+C는 입력을 지우거나 종료하는 키라서 멈출 때는 Esc를 쓴다.

Esc Esc / /rewind — 되감기와 부분 요약

입력창이 비어 있을 때 Esc를 두 번 누르면 되감기 메뉴가 열린다(/rewind와 같다). 프롬프트를 보낼 때마다 체크포인트가 생기고, 다음을 고를 수 있다.

• 대화만 / 코드만 / 둘 다 되돌리기
• 이 지점부터 요약 / 이 지점까지 요약: 대화의 일부만 압축한다. /compact보다 세밀하다.

체크포인트가 있으니 "위험해 보이는 방법도 일단 시켜 보고, 안 되면 되감는" 식으로 쓸 수 있다. 단, Claude의 파일 편집 도구로 바꾼 것만 추적한다. Bash 명령으로 바뀐 파일은 되돌리지 못하므로 git을 대신하지는 않는다.

Shift+Tab, /plan, Ctrl+G — 계획 먼저

Shift+Tab을 누를 때마다 권한 모드가 바뀐다.

• default(Manual): 수정·명령 실행마다 확인
• acceptEdits: 파일 수정은 자동 승인
• plan: 코드를 바꾸지 않고 탐색·계획만
• auto: 별도 분류 모델이 위험해 보이는 행동만 막고 나머지는 진행(사용 가능한 환경에서)

공식 문서가 권하는 흐름은 탐색 → 계획 → 구현 → 커밋이다. Boris Cherny도 계획 모드에서 마음에 들 때까지 계획을 주고받은 뒤, 자동 승인 모드로 바꿔 구현을 맡긴다고 했다.

계획이 나오면 Ctrl+G로 텍스트 편집기에서 계획을 직접 고칠 수 있다. 말로 수정을 요청하는 것보다 빠르다.

/plan 로그인 실패 시 계정 잠금 기능 추가

계획 모드에도 비용이 있다. 공식 문서 기준으로는 diff를 한 문장으로 설명할 수 있으면 계획을 건너뛴다. 오타 수정이나 로그 한 줄 추가는 바로 시키면 된다.

4. 변경 확인과 리뷰

/diff — 바뀐 것 보기

작업 트리의 변경 사항, 즉 Claude가 지금까지 수정한 내용을 보여 준다. 커밋 전에 한 번 훑어보는 용도다.

/code-review (별칭 /review) — 버그 찾기

현재 diff, 또는 PR 번호·브랜치·경로를 지정해 정확성 버그를 찾는다. 새 컨텍스트의 서브에이전트가 리뷰하므로, 방금 코드를 쓴 대화의 편향이 덜 들어간다.

/code-review            # 현재 변경 사항/review 1234            # PR #1234/code-review high --fix # 깊게 보고, 찾은 것을 바로 적용

공식 문서가 덧붙이는 주의점이 있다. 문제를 찾으라고 시키면 리뷰어는 작업이 멀쩡해도 뭔가를 보고하는 경향이 있다. 지적을 전부 반영하다 보면 과잉 설계가 되므로, 정확성이나 요구사항에 영향을 주는 것만 반영하고 나머지는 선택으로 둔다.

/security-review, /simplify

• /security-review: 현재 브랜치와 origin 기본 브랜치 사이 diff에서 인젝션, 인증 문제, 데이터 노출을 찾는다. origin 원격 저장소가 필요하다.
• /simplify: 기존 헬퍼 재사용, 단순화, 효율, 추상화 수준을 보고 정리까지 적용한다. 버그는 찾지 않는다. 버그는 /code-review, 정리는 /simplify로 나눠 쓴다.

Writer / Reviewer 두 세션

공식 문서가 소개하는 패턴이다. 세션 A가 구현하고, 새 세션 B가 리뷰하고, B의 결과를 A에 붙여 넣어 고친다. 새 컨텍스트는 방금 쓴 코드에 치우치지 않아서 리뷰 품질이 좋아진다. 테스트를 한 세션이 쓰고 다른 세션이 그걸 통과하는 코드를 쓰게 하는 변형도 있다.

5. 입력을 빠르게 하는 단축키

응답 중에도 입력할 수 있다. Claude가 작업하는 동안 메시지를 보내면 중단하지 않고 큐에 쌓인다. 메시지는 진행 중인 도구 호출이 끝나는 대로 같은 턴 안에서 전달되고, 슬래시 명령과 ! 명령은 턴이 끝난 뒤 순서대로 실행된다. 바로 보내고 싶으면 Ctrl+Enter. 사용 후기에서도 "다음 지시를 미리 쌓아 두라"는 팁이 자주 나온다.

6. 권한, 훅, 설정

/permissions — 승인 피로 줄이기

수정과 명령마다 승인하다 보면 열 번째쯤엔 검토 없이 누르게 된다고 공식 문서는 지적한다. 자주 쓰는 안전한 명령은 허용 목록에 넣는다. Boris Cherny도 빌드·테스트처럼 자주 쓰는 bash 명령을 /permissions로 미리 허용해 둔다고 했다.

직접 규칙을 쓰기 전에 /fewer-permission-prompts를 돌리면, 지난 대화에서 자주 승인한 읽기 전용 명령을 찾아 프로젝트 설정에 넣어 준다.

--dangerously-skip-permissions에 대해: 여러 사용 후기에서 모든 승인을 건너뛰는 이 옵션을 추천하지만, Boris Cherny는 샌드박스에서 돌리는 오래 걸리는 작업에만 쓴다고 했다. 이름 그대로 위험하므로 평소에는 허용 목록, /sandbox, auto 모드를 먼저 고려하는 편이 낫다.

훅 — "반드시 매번" 해야 하는 일

CLAUDE.md의 지시는 권고라서 가끔 빠질 수 있다. 훅은 정해진 시점에 스크립트를 무조건 실행한다. Boris Cherny의 팀은 코드 수정 뒤 자동으로 포매터를 돌리는 훅을 써서 CI 실패를 막는다.

훅 설정을 직접 쓸 필요는 없다. 공식 문서처럼 Claude에게 시키면 된다.

파일을 수정할 때마다 eslint를 실행하는 훅을 만들어 줘

설정된 훅은 /hooks로 확인한다.

그 밖의 설정

7. 자동화와 나만의 명령어

claude -p — 한 번 묻고 끝내기

claude -p "이 함수가 하는 일을 설명해 줘"cat error.log | claude -p "이 에러의 원인 후보를 정리해 줘"claude -p "API 엔드포인트 목록" --output-format json

대화형 화면 없이 결과만 출력하고 끝난다. 파이프 입력을 받을 수 있어서 셸 스크립트, pre-commit 훅, CI에 끼워 넣기 좋다.

커스텀 스킬 — 반복 요청을 명령어로

Boris Cherny는 직접 만든 /commit-push-pr 명령을 하루에도 수십 번 쓴다고 했다. 반복하는 요청은 이렇게 명령어로 만들어 두는 게 가장 효과가 크다.

.claude/skills/<이름>/SKILL.md 파일이 /<이름> 명령어가 된다. 본문에 !`명령`을 쓰면 스킬을 부를 때 그 명령을 실행해 결과를 프롬프트에 미리 넣는다. Claude가 같은 정보를 확인하려고 따로 명령을 실행할 필요가 없어진다.

---description: 스테이징된 변경으로 커밋 메시지 초안 작성disable-model-invocation: true---아래 변경 사항으로 커밋 메시지 초안을 써 줘.!`git diff --staged`추가 요청: $ARGUMENTS

• /commit-draft 한국어로처럼 쓰면 뒤의 글자가 $ARGUMENTS로 들어간다.
• disable-model-invocation: true는 Claude가 알아서 부르지 않고 내가 직접 호출할 때만 실행되게 한다. 커밋·배포처럼 부수 효과가 있는 작업에 권장된다.
• .claude/skills/는 레포에 커밋해서 팀과 공유하고, ~/.claude/skills/는 모든 프로젝트에서 쓰는 개인용이다.
• 예전 방식인 .claude/commands/<이름>.md도 계속 동작한다.

큰 기능은 인터뷰부터

공식 문서가 소개하는 방법이다. 큰 기능을 만들 때 짧게 설명하고 Claude가 나를 인터뷰하게 한다.

[만들 기능 한 줄 설명]을 만들고 싶어. AskUserQuestion 도구로 나를 자세히 인터뷰해 줘.구현, UI/UX, 엣지 케이스, 트레이드오프를 묻고, 뻔한 질문은 빼 줘.다 끝나면 SPEC.md에 스펙을 정리해 줘.

스펙이 나오면 새 세션에서 구현을 시킨다. 깨끗한 컨텍스트에서 시작하고, 참고할 문서도 남는다.

8. 한 단계 더: 숙련자용과 최근 추가된 명령어

최근 버전에 추가된 기능이 많아서 버전·요금제·설정에 따라 메뉴에 안 보일 수 있다. 업데이트 내역은 /release-notes로 볼 수 있다.

병렬로 일하기: 숙련자들의 공통점

사용 후기에서 가장 크게 차이 나는 부분이다. Boris Cherny는 터미널에서 Claude 5개, 웹에서 5~10개를 동시에 돌리고, 각자 별도 git 체크아웃에서 작업하게 한다고 했다. 한 세션의 응답을 기다리는 대신 여러 작업을 나눠 맡기는 방식이다.

대화를 갈라서 일하기: /branch, /subtask, /fork

셋 다 지금 대화를 복사하지만 복사본이 어디서 돌고 결과가 어디로 오는지가 다르다.

끝날 때까지 맡기기: /goal, /loop

/goal test/auth의 모든 테스트가 통과하고 lint가 깨끗하다. 다른 테스트 파일은 수정하지 않는다. 또는 20턴 후 중단

완료 조건을 정해 두면 Claude가 조건이 충족될 때까지 턴을 이어서 작업한다. 매 턴이 끝날 때마다 별도의 작은 모델이 조건을 판정하므로, 일하는 모델이 스스로 "다 됐다"고 판단하는 것과 다르다. 0장의 "스스로 확인할 수단을 줘라"를 세션 단위로 강제하는 도구다.

좋은 조건은 측정 가능한 끝 상태 하나, 확인 방법(npm test가 0으로 종료), 바꾸면 안 되는 것, 상한(턴 수)을 담는다. 판정 모델은 명령을 직접 실행하지 않고 대화에 드러난 것만 보므로, Claude의 출력으로 증명할 수 있는 조건이어야 한다. /goal만 입력하면 진행 상태, /goal clear로 중단한다.

/loop는 조건 대신 시간 간격이 기준이다.

/loop 5m 배포가 끝났는지 확인해 줘

큰 작업을 병렬로: /batch, ultracode, /deep-research

• /batch <지시>: 작업을 5~30개의 독립 단위로 나눠 계획을 보여 주고, 승인하면 단위마다 격리된 worktree에서 서브에이전트가 구현·테스트한다.

  text

  /batch src/ 아래 JavaScript 파일을 TypeScript로 마이그레이션

• ultracode 키워드: 프롬프트에 ultracode를 넣으면 여러 서브에이전트를 조율하는 workflow 스크립트를 작성해 실행한다. 진행 상황은 /workflows에서 보고, 쓸 만하면 s로 저장해 /<이름>으로 재사용한다. /effort ultracode로 켜면 세션의 큰 작업마다 workflow를 쓰는데, 토큰을 많이 쓰므로 평소엔 /effort ultracode off.

  text

  ultracode: src/routes/ 아래 모든 API 엔드포인트에서 인증 검사 누락을 찾아 줘

• /deep-research <질문>: 여러 각도로 웹을 검색하고 출처끼리 교차 검증해 출처가 달린 보고서를 만든다.

"테스트 통과"를 넘어: /run, /verify

Boris Cherny는 Claude가 변경마다 브라우저를 열어 UI를 직접 확인하게 한다고 했다. 같은 방향의 기본 제공 명령어가 있다.

• /run: 앱을 실제로 띄우고 조작해서 변경이 동작하는지 본다.
• /verify: 테스트나 타입 체크만 믿지 않고, 빌드하고 실행해서 결과를 관찰한다.
• /run-skill-generator: 우리 프로젝트를 빌드·실행하는 방법을 /run과 /verify에 가르치는 프로젝트 스킬을 만든다.

리뷰를 한 단계 더: /code-review ultra, /autofix-pr

• /code-review ultra(별칭 /ultrareview): 클라우드 샌드박스에서 여러 에이전트로 깊게 리뷰한다. Pro·Max는 3회 무료, 이후 사용량 크레딧이 필요하다.
• /code-review --comment: 찾은 문제를 PR 코멘트로 단다.
• /autofix-pr: 현재 브랜치 PR을 지켜보다가 CI가 실패하거나 리뷰 코멘트가 달리면 수정을 푸시하는 클라우드 세션을 띄운다. gh CLI가 필요하다.

내 사용 습관 점검하기

소소하지만 손이 편해지는 것들

사람들의 추천을 따를 때 주의할 점

• 유행하는 기능을 전부 설치하지 않는다. 여러 후기에서 반복되는 경고다. 새 기능이 왜 나왔는지 이해하고, 내 반복 작업에 맞을 때 들인다.
• 오래된 글을 조심한다. # 메모 단축키처럼 예전 글의 팁 중 일부는 지금 동작이 다르다. 명령어는 공식 문서로 한 번 확인한다.
• 권한을 푸는 팁은 환경을 보고 쓴다. 승인 생략은 샌드박스·컨테이너 같은 격리 환경에서 쓰는 게 안전하다.

정리

• 원칙: 컨텍스트는 깨끗하게, 계획 먼저, Claude가 스스로 확인할 수단을 준다.
• 시작: /init으로 만든 CLAUDE.md를 짧게 유지하고, 실수할 때마다 보완한다.
• 컨텍스트: 같은 작업이면 /compact, 다른 작업이면 /clear. 두 번 고쳐도 안 되면 /clear하고 다시.
• 안전장치: Esc로 멈추고, Esc Esc로 되감고, Shift+Tab 계획 모드에서 Ctrl+G로 계획을 다듬는다.
• 리뷰: /diff로 보고, /code-review로 버그를, /simplify로 정리를. 리뷰는 새 컨텍스트에서.
• 반복 줄이기: 승인은 /permissions, 매번 할 일은 훅, 반복 요청은 스킬.
• 한 단계 더: worktree와 /subtask·/fork로 병렬 작업, /goal로 끝까지 맡기기, /verify로 실제 동작 확인.

많은 명령어를 아는 것보다, 사람들이 공통으로 말하는 깨끗한 컨텍스트, 계획, 검증이라는 세 습관이 결과에 더 크게 영향을 준다.

참고

공식 문서

• Best practices — Claude Code Docs
• Commands — Claude Code Docs
• Interactive mode — Claude Code Docs
• CLI reference — Claude Code Docs
• Skills — Claude Code Docs
• Goal — Claude Code Docs
• Dynamic workflows — Claude Code Docs

사용자 경험·팁

• Claude Code 제작자의 워크플로 — InfoQ (2026-01-10)
• How I use Claude Code (+ my best tips) — Builder.io
• ykdojo/claude-code-tips — GitHub
• 클로드 코드 800시간 사용 경험 기반 9가지 꿀팁 — Lilys AI 영상 요약