같은 작업도 어떤 슬래시 명령어로 시작하느냐에 따라 걸리는 시간이 갈린다. “버그 고쳐줘”라고 던지는 것과, 조사는 /deep-research로 모으고 큰 수정은 /batch로 쪼개고 합치기 전 /code-review로 거르는 것은 결과물의 안정성부터 다르다. 코드팩토리 영상이 정리한 16개 명령어를 Anthropic 공식 문서로 하나씩 대조하면서, 실제로 작업을 빠르게 만드는 쓰임새만 추렸다.
핵심은 명령어를 다 외우는 게 아니다. 조사·실행·검토라는 작업 흐름의 어느 칸에 어떤 명령을 끼우느냐가 속도를 만든다.
조사는 검색 대신 /deep-research 한 번으로
새 라이브러리나 에러를 조사할 때 탭을 수십 개 여는 대신 /deep-research를 쓴다. 이 명령은 웹 검색을 여러 갈래로 펼쳐 출처를 교차 검증한 뒤, 인용을 단 보고서로 정리해준다. 단순 검색 한 번이 아니라 여러 조사를 동시에 돌리는 번들 워크플로다.
조사 범위가 코드베이스 안쪽이면 서브에이전트를 쓰는 게 낫다. “이 함수 어디서 쓰는지 조사해줘”처럼 시키면, 별도 컨텍스트에서 돌며 결과를 1,000~2,000 토큰짜리 요약으로만 돌려준다. 조사를 분리하면 메인 대화창이 깨끗하게 유지된다 — 이게 Claude Code 속도의 핵심이다. 컨텍스트가 차면 성능이 떨어지기 때문이다.
큰 작업은 /batch로 쪼개 동시에 돌린다
여러 파일을 한꺼번에 바꾸는 대규모 작업에는 /batch가 강력하다. 이 명령은 작업을 5~30개의 독립 단위로 쪼개고, 단위마다 격리된 작업 공간(git worktree)에서 백그라운드 일꾼을 띄운다. 각 일꾼이 자기 몫을 구현하고 테스트한 뒤 따로 결과를 올린다. 혼자서 여러 명을 동시에 부리는 셈이다.
길게 걸리는 작업은 /background(또는 /bg)로 떼어내면 터미널이 자유로워진다. 진행 상황은 claude agents로 확인한다. 그리고 끝까지 시키고 싶을 땐 /goal을 건다. “테스트 폴더가 다 통과할 때까지”처럼 완료 조건을 정하면, 빠른 평가 모델이 매 턴마다 조건을 확인하고 달성되면 알아서 멈춘다.
합치기 전엔 /code-review로 한 번 거른다
코드를 병합하기 전 /code-review로 직접 만든 변경분을 점검한다. 버그뿐 아니라 중복·단순화 여지까지 잡아주고, --fix를 붙이면 고치고 --comment를 붙이면 PR에 코멘트로 단다. 더 깊은 검증이 필요하면 ultra를 붙인다. 로컬과 클라우드 검토는 이렇게 갈린다.
| 명령 | 어디서 | 비용 | 언제 |
|---|---|---|---|
/code-review |
내 컴퓨터 | 구독 내 | 평소 변경분 빠른 점검 |
/code-review ultra |
클라우드(여러 검토 AI) | 건당 약 15~25달러 | 합치기 전 중요한 최종 리뷰 |
ultra는 격리된 클라우드에서 여러 검토 AI가 버그를 찾고 서로 검증까지 한다. 다만 건당 비용이 붙으니 매번이 아니라 중요한 머지 앞에서만 쓰는 게 합리적이다. 비슷하게 /ultraplan은 계획을 브라우저에서 검토하는 클라우드 기능인데, 이 둘은 외부 클라우드를 막아둔 환경(Bedrock·Vertex 등)에서는 아예 안 된다는 점을 기억해야 한다.
흐름을 안 끊으려면 어떤 명령을 쓰나
작업 흐름을 매끄럽게 만드는 작은 명령들이 생각보다 큰 차이를 만든다.
/rewind— 잘못된 방향으로 갔을 때 이전 지점으로 되돌린다. 매 입력마다 자동 저장되며 30일간 남는다. 단 임시 되돌리기일 뿐이라, 터미널 명령으로 지운 파일은 복구 못 한다. 진짜 기록은 git이 한다./btw— 본 작업과 상관없는 곁가지 질문을 대화 기록과 컨텍스트를 늘리지 않고 물어본다. “이 함수 다른 데서도 쓰나?” 같은 걸 흐름 안 끊고 확인할 때 좋다./copy— 마지막 답변을 클립보드로 복사한다. 숫자를 붙이면 N번째 이전 답변도 가져온다.
이름값에 속기 쉬운 명령도 하나 있다. /powerup은 성능을 끌어올리는 부스터처럼 들리지만, 실제로는 Claude Code 기능을 짧은 애니메이션으로 배우는 학습 도구다. 효과를 키우는 게 아니라 사용법을 알려준다.
권한과 노력은 어떻게 조절하나
명령어만큼 중요한 게 두 가지 다이얼이다. 하나는 권한, 하나는 노력 수준이다.
권한은 AI가 파일을 고치거나 명령을 실행하기 전에 물어볼지를 정하는 설정으로, Shift+Tab으로 단계를 바꾼다. 탐색만 할 땐 읽기 전용인 plan 모드, 마음 놓고 맡길 땐 auto 모드를 쓴다. auto는 알아서 일하되 위험한 명령은 감시 AI가 막고, 연속 3번이나 누적 20번 막히면 멈추고 사람에게 넘긴다.
노력 수준은 /effort로 조절한다. 가벼운 일은 낮게, 어려운 일은 높게 올린다. 여기서 흔한 오해 하나. 울트라코드는 별도 모드가 아니라 노력 수준 설정이다. /effort ultracode로 켜며, 가장 깊은 추론에 자동 작업 조율을 묶은 것이고 세션이 끝나면 풀린다. 이 ‘어디까지 맡기고 얼마나 깊게 파느냐’의 감각은 Opus 4.8의 fast와 ultracode 이야기에서도 똑같이 등장한다.
정리
Claude Code를 빠르게 쓰는 비결은 명령어 암기가 아니라 작업 흐름에 끼우는 감각이다. 조사는 /deep-research와 서브에이전트로 분리하고, 대규모 변경은 /batch로 쪼개 동시에 돌리고, 합치기 전엔 /code-review로 거른다. 거기에 권한(Shift+Tab)과 노력(/effort) 두 다이얼을 작업 난도에 맞춰 돌린다.
새 명령어가 나와도 “이건 조사냐 실행이냐 검토냐”만 물어보면 자리를 찾는다. 도구는 계속 늘지만, 작업 흐름이라는 뼈대는 잘 안 바뀐다. 그래서 명령어를 좇기보다 내 흐름을 먼저 정리하는 쪽이 오래 간다.
참고 자료
- Claude Code Commands (공식 문서)
- Best practices for Claude Code (공식)
- Permission modes (공식)
- Code review (공식)
- Checkpointing (공식)
- 분석 대상 영상 — Claude Code 필수 지식 20가지 (코드팩토리)
함께 읽으면 좋은 글
