클로드코드 명령어 정리: 처음에 익힐 슬래시 커맨드

클로드코드(Claude Code)를 켜고 몇 번 쓰다 보면 /로 시작하는 명령어를 보게 됩니다. 검색해보면 명령어 목록을 정리한 글이 많은데, 대부분 수십 개를 한 줄씩 나열해둡니다.

그 목록을 다 외울 필요는 없습니다.

클로드코드 입력창에 / 를 입력하면
사용할 수 있는 명령어 목록이 바로 뜹니다.

글자를 이어 입력하면 목록이 좁혀집니다.

그래서 필요한 건 "전체 목록"이 아니라 어떤 상황에서 어떤 명령어를 떠올려야 하는지입니다. 뚝딱 수업에서 실제로 반복해서 쓰는 순서대로 정리했습니다.

명령어는 메시지 맨 앞에서만 인식돼요

먼저 입력 규칙 하나만 짚고 갑니다.

/clear
/compact 결제 로직 중심으로 남겨줘

→ 명령어로 인식

이 부분은 /clear 하는 게 나을까요?

→ 그냥 문장으로 전달

명령어는 메시지의 맨 앞에 있을 때만 명령으로 처리됩니다. 명령어 뒤에 붙인 텍스트는 그 명령어의 인자가 돼요. /compact 결제 로직 중심으로 남겨줘처럼 뒤에 조건을 붙이는 방식이 여기서 나옵니다.

클로드가 답변하는 중에 명령어를 보내면 대기열에 들어가 현재 턴이 끝난 뒤 실행됩니다. 다만 /status, /usage, /tasks처럼 확인만 하는 명령어는 답변을 끊지 않고 바로 실행돼요.

1. 대화를 정리하는 명령어

가장 자주 쓰고, 가장 먼저 익혀야 할 묶음입니다. 클로드코드를 오래 쓰면서 답변이 흐려지거나 사용량이 빨리 차는 문제는 대부분 여기서 해결됩니다.

판단 기준은 한 문장이면 됩니다.

앞의 대화가 없어도 다음 작업을 설명할 수 있나요?

예 → /clear
아니요 → /compact

/compact 뒤에는 남길 내용을 지정할 수 있어요.

/compact 결제 흐름의 결정 사항, 수정한 파일,
아직 실패하는 테스트를 중심으로 남겨줘

두 명령어의 차이와 각각의 비용은 클로드코드 /clear와 /compact 차이에서 자세히 다뤘습니다.

2. 상태를 확인하는 명령어

무언가 이상하다고 느껴질 때 추측하지 말고 먼저 확인하는 용도입니다.

사용량이 평소보다 빨리 준다고 느껴지면 요금제를 올리기 전에 /usage와 /context를 먼저 보세요. 오래된 긴 대화를 계속 이어가고 있어서 생기는 경우가 많습니다. 이 상황은 오래된 대화와 프롬프트 캐싱에서 따로 설명했어요.

설치 직후 클로드코드가 아예 실행되지 않거나 로그인이 풀린다면 /doctor부터 실행합니다. 진단 결과에서 f를 누르면 클로드가 고칠 수 있는 문제의 수정을 요청할 수 있어요.

3. 되돌리는 명령어

바이브코딩 입문자에게 실제로 가장 필요한 명령어입니다. AI가 코드를 여러 파일에 걸쳐 바꾼 뒤 "이전 상태가 나았는데"라고 느끼는 순간이 반드시 옵니다.

/rewind를 실행하면 이전 요청을 고른 뒤 대화만, 코드만, 둘 다 되돌릴지 선택합니다. 다만 클로드의 파일 편집 도구가 만든 변경만 추적해요. Bash 명령으로 바꾼 파일, 데이터베이스·배포·외부 API에서 이미 실행된 작업은 되돌리지 못합니다.

체크포인트가 있다고 해서 Git이 필요 없어지는 것은 아니에요. 세션을 벗어난 기록과 협업, 추적하지 못한 변경은 여전히 Git의 일입니다. 두 가지의 역할 차이는 Git과 GitHub를 꼭 써야 하는 이유에서 정리했습니다.

4. 프로젝트를 설정하는 명령어

프로젝트를 새로 시작할 때 한 번씩 쓰는 묶음입니다.

프로젝트를 만들고 처음 클로드코드를 켰다면 /init 한 번이 좋은 출발점입니다. 프로젝트의 구조와 명령어를 훑어 CLAUDE.md 초안을 만들어주고, 이후 모든 대화의 시작 지점에서 그 파일을 읽어요. CLAUDE.md가 무엇이고 무엇을 적어야 하는지는 CLAUDE.md란?에서 다뤘습니다.

/permissions는 "매번 승인 버튼을 누르기 귀찮다"는 이유로 서둘러 열어두기 쉬운 설정입니다. 무엇을 허용했는지 모르는 채로 넓히지 말고, 반복해서 승인하게 되는 명령이 확실해졌을 때 하나씩 추가하세요.

5. 모델과 생각의 깊이를 고르는 명령어

같은 요청이라도 어떤 모델이 답하느냐, 얼마나 깊게 생각하느냐에 따라 결과와 사용량이 달라집니다. 두 가지를 각각 조절하는 명령어가 있어요.

/model — 누가 답할지 고르기

/model만 입력하면 고를 수 있는 모델 목록이 열립니다. 이름 대신 별칭으로 불러도 돼요.

/model haiku     빠르고 가벼운 작업
/model sonnet    일상적인 코딩 작업
/model opus      복잡한 추론이 필요한 작업
/model default   추천 설정으로 되돌리기

목록에서 Enter로 고르면 앞으로 새로 시작하는 대화의 기본값으로도 저장됩니다. 이번 대화에서만 바꾸고 싶다면 s를 누르세요.

주의할 점이 하나 있습니다. 긴 대화 도중에 모델을 바꾸면 다음 답변이 지금까지의 대화를 캐시 없이 처음부터 다시 읽습니다. 그래서 목록에서 확인을 한 번 더 물어봐요. 사용량을 아끼려고 대화 중간에 가벼운 모델로 바꿨다가 오히려 한 번에 크게 쓰는 경우가 여기서 나옵니다. 이유는 오래된 대화와 프롬프트 캐싱에서 설명한 것과 같아요.

바꾸려면 대화가 짧을 때, 또는 /clear 직후에 바꾸세요.

/effort — 얼마나 깊게 생각할지 고르기

/effort는 모델을 바꾸지 않고 생각의 깊이만 조절합니다. 지원하는 단계와 기본값은 모델에 따라 달라요. 보통 low, medium, high, xhigh, max 중에서 고르고, auto를 입력하면 현재 모델의 기본값으로 돌아갑니다.

/effort          슬라이더로 조절
/effort low      빠르고 가볍게
/effort auto     기본값으로 되돌리기

낮추면 빠르고 토큰을 적게 쓰고, 높이면 더 오래 생각하는 대신 사용량이 늘어납니다. 현재 단계는 화면 위쪽 모델 이름 옆에 함께 표시돼요.

max가 항상 좋은 선택은 아닙니다. 공식 문서도 max는 어려운 작업에서 도움이 될 수 있지만 효과가 줄고 과하게 생각하는 경향이 있다고 안내합니다. 늘 켜두기보다 정말 안 풀리는 문제에서만 시험해보세요.

한 번만 깊게 생각하게 하고 싶다면 설정을 바꿀 필요 없이 요청에 ultrathink라는 단어를 넣으면 됩니다.

ultrathink 이 결제 오류가 왜 특정 카드에서만
나는지 원인을 처음부터 다시 짚어줘

언제 바꾸면 되나요

두 설정을 실제로 손대게 되는 순간은 대체로 이렇습니다.

사용량이 너무 빨리 찬다
→ /model 을 가벼운 모델로
→ 또는 /effort medium

단순 반복 작업만 남았다
→ /effort low 로 빠르게

어려운 버그가 계속 안 풀린다
→ /model opus + /effort xhigh
→ 또는 요청에 ultrathink 한 번

무엇을 바꿨는지 헷갈린다
→ /model default, /effort auto 로 복귀

다만 올릴 만큼 올렸는데도 같은 자리에서 막힌다면 원인이 모델이나 깊이가 아닐 수 있습니다. 요청을 한 번에 너무 크게 잡고 있는 경우가 많아요. 이 부분은 바이브코딩 프로젝트가 중간에 꼬이는 이유에서 다뤘습니다.

6. 만들기 전에 계획하는 명령어

/plan은 바로 만들지 말고 무엇을 어떻게 만들지 먼저 정리하게 하는 모드입니다.

/plan 예약 페이지에 취소 기능을 붙이고 싶어.
어떻게 만들지 먼저 정리해줘.

계획 모드에서 클로드는 파일을 읽고 프로젝트를 탐색하면서 계획을 씁니다. 하지만 소스 코드는 고치지 않아요. 내가 계획을 승인하기 전까지 편집이 막혀 있습니다.

계획이 나오면 어떻게 진행할지 고를 수 있어요.

승인하고 알아서 진행
승인하되 수정마다 확인
계속 계획 다듬기

Ctrl+G를 누르면 계획을 편집기에서 직접 고칠 수도 있습니다. 승인하지 않고 그냥 빠져나오려면 Shift+Tab을 누르면 돼요. 매번 /plan을 입력하는 대신 Shift+Tab으로 모드를 순환해 켤 수도 있습니다.

언제 쓰면 좋은가요

계획 모드가 특히 잘 맞는 순간은 세 가지입니다.

• 여러 파일을 건드릴 것 같은 기능을 시작할 때
• 기존 코드를 어디까지 고쳐야 하는지 감이 안 올 때
• 같은 요청을 몇 번 시켰는데 매번 엉뚱한 방향으로 갈 때

세 번째가 특히 유용합니다. 결과를 보고 다시 고쳐달라고 반복하는 것보다, 만들기 전에 방향을 맞추는 편이 훨씬 빠르게 끝나요.

반대로 버튼 문구를 바꾸는 정도의 작은 수정에는 오히려 번거롭습니다. 계획을 읽고 승인하는 단계가 작업보다 길어지니까요.

계획 모드는 PRD를 개발 계획으로 바꾸는 과정의 작은 버전이라고 봐도 됩니다. 기능 하나 단위에서 같은 일을 하는 셈이에요.

7. 검토하는 명령어

클로드코드에는 기본으로 들어 있는 검토용 기능도 있습니다.

배포를 앞두고 있다면 /security-review를 한 번 돌려보세요. 특히 로그인, 결제, 파일 업로드처럼 비밀값이 오가는 기능을 붙인 뒤에 유용합니다. 이 명령이 확인하는 범위와 실제 배포 환경에서 함께 볼 항목은 바이브코딩 웹앱 보안 체크리스트에 정리했습니다.

/code-review는 만든 코드를 다시 읽어줘요

바이브코딩에서 가장 불안한 순간은 "다 만들었습니다"라는 답을 받았을 때입니다. 화면은 잘 돌아가는데, 정말 괜찮은 건지 판단할 방법이 없어요.

/code-review는 그 자리에서 쓰는 명령어입니다.

/code-review

인자 없이 실행하면 지금 브랜치에서 새로 만든 커밋과 아직 커밋하지 않은 변경을 읽습니다. 그래서 기능 하나를 끝낸 직후에 실행하는 것이 가장 잘 맞아요. 논리가 틀린 부분과 함께 중복이나 불필요하게 복잡해진 부분도 같이 짚어줍니다.

특정 대상만 보게 할 수도 있습니다.

/code-review src/lib/payment.ts
/code-review main...my-feature

찾은 문제를 바로 고치게 하려면 --fix를 붙입니다.

/code-review --fix

여기서 주의할 점이 하나 있습니다. /code-review는 서브에이전트로 백그라운드에서 실행돼서 내 대화 컨텍스트를 채우지 않는데, 대신 --fix로 적용된 수정은 /rewind로 되돌아가지 않습니다. 되돌리려면 Git을 써야 해요. 그래서 --fix는 커밋을 한 번 해둔 뒤에 쓰는 편이 안전합니다.

검토 강도도 조절할 수 있습니다.

/code-review low     확실한 것만 짧게
/code-review high    넓게 보되 애매한 지적도 포함

처음에는 기본값이나 low로 시작하세요. 강도를 높이면 지적이 늘어나는데, 초보자에게는 "고쳐야 할 것"과 "고쳐도 되는 것"을 구분하는 일 자체가 또 하나의 부담이 됩니다.

정리하면 이 순서입니다.

/plan 으로 방향 맞추기
→ 구현
→ /code-review 로 문제가 없는지 확인
→ 커밋
→ /clear 후 다음 기능

AI가 만든 코드를 검토하는 일까지 AI에게 맡기는 게 이상하게 느껴질 수 있어요. 다만 처음 만들 때와 다시 읽을 때는 보는 방식이 다릅니다. 사람도 자기가 쓴 글의 오타는 잘 못 찾는 것과 비슷해요. 완벽한 검사는 아니지만, 아무도 다시 안 읽는 것보다는 훨씬 낫습니다.

명령어를 직접 만들 수도 있어요

반복해서 붙여넣는 지시가 생기면 그것을 명령어로 만들 수 있습니다. 클로드코드에서 커스텀 명령어는 스킬로 합쳐졌습니다. .claude/commands/deploy.md 파일과 .claude/skills/deploy/SKILL.md 파일은 둘 다 /deploy 명령을 만들고 똑같이 동작해요.

~/.claude/skills/<이름>/SKILL.md
→ 내 모든 프로젝트에서 사용

.claude/skills/<이름>/SKILL.md
→ 이 프로젝트에서만 사용

폴더 이름이 그대로 명령어 이름이 됩니다. deploy 폴더를 만들면 /deploy가 돼요.

다만 처음부터 만들 필요는 없습니다. 같은 지시를 세 번 이상 반복해서 붙여넣고 있다는 걸 깨달았을 때가 만들 시점입니다. 스킬을 언제 만들고 서브에이전트·훅과 무엇이 다른지는 클로드코드 서브에이전트·스킬·훅에서 이어서 설명했습니다.

정리: 열한 개면 충분해요

처음 한 달은 다음 열한 개만 손에 익히면 됩니다.

/clear        작업이 바뀔 때
/compact      같은 작업을 이어갈 때
/context      무엇이 쌓였는지 확인
/usage        사용량 확인
/model        답할 모델을 바꿀 때
/effort       생각의 깊이를 바꿀 때
/plan         큰 기능을 시작할 때
/rewind       잘못 만들어졌을 때 되돌리기
/code-review  기능 하나를 끝냈을 때
/init         프로젝트 시작할 때 한 번
/doctor       설치와 환경이 이상할 때

나머지는 필요해진 순간에 /를 입력해 찾으면 됩니다. 전체 명령어 목록은 클로드코드 명령어 공식 문서 (새 탭에서 열림)에서 확인할 수 있어요.

명령어를 많이 아는 것이 실력이 되지는 않습니다. 작업이 바뀔 때 대화를 정리하고, 만들어진 결과를 눈으로 확인하고, 아니다 싶으면 되돌리는 습관이 훨씬 크게 작용합니다.