서론

Claude Code의 슬래시 명령(Slash Commands) 치트 시트가 X(구 Twitter)에서 주기적으로 올라오고 있습니다.

자주 사용하는 명령 20선 (용도별 치트 시트) — "먼저 사용한다면 /context → /diff → /code-review"
신기능 — 미사용 스킬 정리나 CLAUDE.md 정리를 위저드 형식으로 수행해 주는 /checkup 소개
실무 명령 5선 — /goal, /batch, /loop, /code-review --fix, /background

Claude는 명령어가 자주 바뀌기 때문에 **"이 명령어들, 전부 정말 존재하는가?"**를 검증하기로 했습니다.

직접 만든 근력 트레이닝 기록 앱을 검증 환경으로 사용하여 검증했습니다.

실무 5개 명령은 전부 실재했다
치트 시트의 한 줄 설명과 실제 동작 사이에는 뉘앙스의 차이가 있었다
/code-review는 "상수를 하나 바꿨을 뿐인 간단한 PR"에서도 버그를 찾아냈다
/checkup의 제안은 유능하지만, "권장(推奨)"을 맹신하면 위험한 상황이 2가지 존재했다

검증 방법

다음 체제로 검증

지휘자: Fable5 님께서 대응해 주셨습니다.
시나리오 설계 에이전트 × 3 + 팩트 체커 × 1: 서브 에이전트로 병렬 기동하여, 치트 시트의 명령어보다 시나리오를 설계하고 각 명령어의 사실 여부(공식 문서 기준)를 분담하여 확인

권장 동선을 체험하기: /context → /diff → /code-review

/context — 컨텍스트(Context) 건강 진단

세션 시작 직후의 /context는 다음과 같습니다.

헤드리스 모드(claude -p "/context")라면 Markdown 표로 출력할 수 있습니다.

합계 47.5k / 1M 토큰. 내역을 보면 Memory files (CLAUDE.md + rules)가 28.5k로 최대 소비원입니다.

특히 hono-rules.md 단독으로 9.6k. "세션을 열 때마다 매번 28.5k를 지불하고 있다"는 것을 한눈에 알 수 있습니다.

이것이 나중에 나올 /checkup의 복선이 됩니다.

/diff — "차이 없음"일 터인데

검증 당시, 작업 트리(Working Tree)는 클린(미커밋 변경 사항 제로) 상태였습니다. 따라서 /diff는 "차이 없음"이라고 답할 것이라 생각했는데, 13개 파일 · +24/-24의 파일 리스트가 피커(Picker) UI로 표시되었습니다.

헤더에 "Branch changes (vs main)"라고 명시됨. 작업 트리가 클린해도 13개 파일의 차이점이 나열됨

현재 브랜치(PR#19 "AI 코치의 재생성 간격을 7일에서 3일로 변경")의 베이스 브랜치와의 차이점이었습니다.

PR 브랜치 상에서, /diff는 미커밋 변경 사항이나 세션 내의 턴(Turn) 차이점이 없다면 브랜치 차이점을 보여주었습니다.

공식 레퍼런스의 설명은 "미커밋 변경 사항과 턴별 차이점"이므로, 이 폴백(Fallback) 동작은 사양(Specification)으로서 보장된 것은 아니라는 점에 주의해야 합니다.

보충: 로컬에 수정 사항이 있을 때의 본래 동작

며칠 후, 미커밋 변경 사항이 남아 있는 상태(이 글을 작성 중인 리포지토리)에서 /diff를 실행하자 공식 문서와 동일한 본래 화면이 나왔습니다.

미커밋 변경 사항이 있으면 Current와 T<n> 탭이 나란히 나타남. 헤더에는 해당 턴의 지시 메시지가 표시됨

Open an interactive diff viewer showing uncommitted changes and per-turn diffs. Use left/right arrows to switch between the current git diff and individual Claude turns, and up/down to browse files.

탭은 두 종류가 있습니다.

• Current— 작업 트리(Working tree)의 커밋되지 않은 전체 차이점(git diff에 해당)
• T〈n〉— 세션의 n번째 턴에서 Claude가 파일을 편집한 부분만 추출한 차이점. 편집이 있었던 턴만 탭으로 생성됨

스크린샷의 T5는 "이 세션의 5번째 턴에서 Claude가 추가한 변경 사항"을 의미합니다. 파일을 건드리지 않은 턴에는 탭이 나타나지 않습니다.

용도 구분은, Current가 "커밋 전에 전체를 재검토"하는 용도라면, T〈n〉은 "방금 전 지시로 Claude가 무엇을 건드렸는지"를 턴 단위로 감사(Audit)하는 용도입니다.

여러 지시를 겹쳐서 내린 후 "그 수정 사항이 어디였지"라며 거슬러 올라갈 때 편리합니다.

사용자가 에디터에서 직접 편집한 부분은 Current에만 포함되며 탭에는 연결되지 않습니다. T 탭은 어디까지나 "Claude의 턴" 기록만을 출력합니다.

즉, 첫 번째 검증에서 보였던 브랜치 차이점은 Current에도 T 탭에도 보여줄 내용이 없을 때 나타나는 폴백(Fallback) 표시입니다.

두 모드 모두 "지금 무엇을 바꿨더라"를 확인하는 데 유용합니다.

/code-review — 7개의 에이전트가 상수 변경 PR에서 버그를 찾아내기까지

/code-review를 입력하자 확인 화면이 표시되었습니다.

• 리뷰는 Find → Verify → Sweep → Synthesize의 다단계 워크플로우(관점별 finder 여러 개 + 지적 사항 1건마다 독립적인 verifier)로 진행되며, effort(노력 수준)는 xhigh로 설정됩니다.
• "Dynamic workflows can use a lot of tokens quickly"라는 토큰 소비 경고가 포함되어 있습니다.

7개의 에이전트가 차례로 실행되어, 21분 42초 만에 완료되었습니다.

결과: finder 6개가 16개의 후보를 찾아냈고, 독립 검증을 통과한 6개만이 CONFIRMED로서 보고되었습니다.

대상 PR은 "REGENERATE_INTERVAL_DAYS: 7 → 3의 상수 변경을 13개 파일에 적용했을 뿐"인 매우 간단한 PR입니다.

그럼에도 불구하고, 여러 개의 피드백(FB)이 나왔습니다.

• 【최우선 사항】 캐시 만료 판정의 이중 구현으로 인한 경계 불일치— UI는 "createdAt + 정확히 72시간"으로 판정하는 반면, 서버 측은 독자적으로 구현된 역법(Calendar day) 기반 판정을 사용합니다. 양측의 차이가 최대 약 15시간 발생합니다. 7일에서 3일로 단축되면서 이 차이의 비율이 확대되었습니다.
• 이번 유일한 동작 변경에 대한 테스트가 존재하지 않음— 코드가 망가져도 테스트는 여전히 Green(통과) 상태를 유지합니다.
• 문서가 여전히 "7일 캐시"로 되어 있음— API 사용자가 구버전 사양을 전제로 설계할 위험이 있습니다.
• ## 今週の総評 이 헤딩을 파싱하는 구현이 조용히 빈 화면으로 표시됨 → ## 総評으로의 이름 변경이 문서 샘플에 반영되지 않았습니다.
• AI용 지식 그래프(Ontology memory)에 구버전 사양인 7일이 남아 있음— 향후 에이전트 세션이 "7일"을 정답으로 간주하고 작업할 위험이 있습니다.
• 테스트의 퇴화(Degradation)— 명시적 값인 3이 새로운 기본값과 동일해지면서, 파라미터를 무시하는 회귀(Regression)를 감지할 수 없게 되었습니다.

비용 이야기

Max*5 플랜으로 검증하고 있습니다.

이 xhigh 리뷰로 인해 세션 비용은 Session: 50m / Cost: 약 $35, 소비량 약 50만 토큰까지 불어났습니다.

다음 단계의 검증 세션은 계정의 세션 상한에 도달해 버렸습니다.

일상적인 사용에는 /code-review medium과 같이 낮은 effort로 운영하면서, 머지(Merge) 전 등 특정 타이밍에만 높은 effort로 대응하는 것이 좋을 것 같습니다.

/checkup 실행하기

정체는 "새로워진 /doctor"

공식 문서에 따르면:

v2.1.205: /doctor는 이제 문제를 진단하고 수정할 수 있는 완전한 설정 점검(Setup checkup) 기능을 수행하며, /checkup은 그 별칭(Alias)입니다.

즉, /checkup은 독립된 새 명령어가 아니라, 대폭 강화된 /doctor의 별칭이라는 뜻입니다.

실제로 검증 세션에서 /checkup을 입력하자 트랜스크립트(Transcript)에는 /doctor로 기록되어 있었습니다.

감사(Audit) 단계가 상상 이상

"모든 체크를 읽기 전용으로 실행하고, 리포트를 제시한 후 확인을 받겠습니다"라고 선언하며 환경 감사가 시작되었습니다.

— MCP 서버별 사용 횟수(playwright 286회, claude-peers 27회…), 슬래시 명령어 사용 기록(/exit 19회, /model 9회…), 스킬 호출 횟수까지 집계하는 Python 스크립트 실행
hooks의 지연 시간 측정— '느린 hook 비활성화'를 제안하기 위해 평균 4ms, 타임아웃 0회라는 실제 데이터를 확보한 후 판단함 - CLAUDE.md・rules・스킬・사용자 명령어 크기 전체 측정(총 74,683 chars)

• 본체 버전 최신 확인

'미사용' 여부는 본인의 사용 실적 데이터를 기반으로 했습니다.

위자드: 제안은 3그룹 + 권한 설정

감사가 끝나면 Cleanup → 권한 설정 → Submit의 3단계 위자드가 나타납니다.

제안 요약과 '전부 실행(권장) / 선택하여 / 아무것도 안 함' 중 선택

제안은 이 세 가지였습니다.

'권장'을 무조건 믿지 않은 두 가지 경우

여기서 이번에 가장 전하고 싶은 내용입니다.

첫째: '전부 실행(권장)'을 선택하지 않음. ②와 ③은 git 관리 하의 파일(CLAUDE.md・rules) 편집이었기 때문에 '선택하여(Let me pick)'로 개별 선택했습니다.

실제 개발 리포지토리에서 무심사 일괄 적용은 조금 위험하다고 생각했습니다.

스킬이나 MCP 이용이 적었던 시기였다면, 원래는 남겨두고 다음 단계에서 사용할 것이지만, 사라져 버릴 수도 있기 때문입니다.

둘째: 권한 설정의 auto 모드 제안을 거절함. 클린업과는 별개로 '기본 권한 모드를 auto로 하지 않겠습니까'라는 제안이 나왔습니다.

변경 대상은 ~/.claude/settings.json이며 모든 프로젝트에 적용되는 글로벌 설정이었습니다.

이 리포지토리의 청소를 부탁하자 모든 프로젝트의 권한 모드가 변경될 상황이었습니다.

① 역시 '사용자 명령어 3건 비활성화'는 글로벌 성격의 변경이라, 자유 기술로 '프로젝트 스킬 backend/frontend 2건만 비활성화해'라고 부분 적용을 요청했습니다.

효과 측정 (솔직한 수치)

적용 후 새 세션에서 /context를 재측정한 결과:

0입니다. 비활성화한 2개 스킬의 메타데이터는 총 60 토큰 정도여서, 반올림 오차로 사라졌습니다.

감사 과정의 부산물로 'CLAUDE.md 끝부분 94행(전체의 22%)이 실체가 없는 스킬을 설명하는 깨진 참조'라는 발견이 있었고, 트림 제안의 타당성이 뒷받침되었습니다.

이어지는 '실무 명령어 5가지'는 실제로 존재하는가

/goal
/batch
/loop
/code-review --fix
/background

검증 방법: 대조 실험이 있는 헤드리스 프로브

인터랙티브 화면의 스크린샷만으로는 증거가 약하기 때문에, 헤드리스 모드로 동작을 비교했습니다. 먼저 대조 실험:

$ claude -p "/zzz-not-a-command"
Unknown command: /zzz-not-a-command

존재하지 않는 명령어는 Unknown command가 반환됩니다. 이것이 기준입니다.

결과: 전부 실재했다

/batch의 답변에는 놀라운 점이 있었습니다. 인자(argument) 없이 검증했음에도 불구하고, 검증 리포지토리(repository)의 문맥을 읽은 사용 예시 제안이 있었습니다:

`/batch` 명령어에는 실행하고 싶은 일괄 변경 내용을 지정해야 합니다.
이 프로젝트(MuscleLog)의 문맥이라면, 예를 들어 다음과 같은 사용법을 생각할 수 있습니다:
- /batch src/presentation/api 하위의 모든 파일에 JSDoc 추가
...

다만 설명의 뉘앙스가 어긋나 있다

실재하기는 했으나, 치트시트(cheat sheet)의 한 줄 설명과 공식 사양 사이에는 차이가 있었습니다. 이 부분이 실무에서는 중요하게 작용합니다.

/loop는 '클라우드의 스케줄 실행'이 아닙니다. 정확하게는 '열려 있는 세션 내에서 일정 시간 간격으로 프롬프트를 반복하는' 기능입니다. 세션을 닫아도 계속 실행되는 cron 방식의 스케줄은 별도의 명령어인 /schedule (Claude Routine)의 담당입니다. 이름의 인상 때문에 혼동하기 쉬운 전형적인 사례입니다. /goal의 실체는 'Stop hook의 래퍼(wrapper)'입니다. 조건을 전달하면, 턴(turn)이 끝날 때마다 소형 모델(기본값 Haiku)이 조건 달성 여부를 yes/no로 판정하고, 미달 시 자동으로 다음 턴을 시작하는 구조입니다.

조건은 최대 4,000자이며, "npm test가 exit 0이다"와 같이 대화 로그로부터 판정 가능한 형태로 작성하는 것이 요령입니다. 폭주 방지를 위해 "or stop after 20 turns"와 같은 상한 구문을 조건에 포함할 수 있습니다. auto mode가 '도구 승인의 자동화'라면, /goal은 '턴 지속의 자동화'이며, 두 기능은 상호 보완 관계라고 공식적으로 기재되어 있었습니다. /batch는 단순히 '여러 파일에 대한 변경을 병렬 적용'하는 것만이 아닙니다. 태스크를 5~30개의 유닛으로 분해한 뒤, 각 유닛을 별도의 워크트리(worktree)에 있는 서브 에이전트(sub-agent)가 구현, 테스트, PR(Pull Request) 생성까지 자동으로 실행하는 대규모 오케스트레이션(orchestration) 기능입니다.

/background는 '지속'이 아니라 '디태치(detach)'입니다. 터미널을 닫아도 이어진다는 느낌보다는, 세션을 전용 supervisor 프로세스에 넘겨 background agent화하는 명확한 상태 전이이며, claude agents라는 관리 화면이 이를 받아줍니다.

20선 치트시트 정답 맞히기

20개 중 이번에 실제로 체험한 것:

참고로 "먼저 사용할 것이라면 /context → /diff → /code-review"라는 권장 동선은 실제로 그 순서대로 사용해 보았을 때 납득이 갔습니다. 현상 파악 → 변경 확인 → 품질 체크라는 자연스러운 흐름으로 구성되어 있습니다.

검증을 통해 알게 된 점

1. AI의 검증도 유도 질문에 휘둘린다. 팩트 체크 (Fact Check) 담당 서브 에이전트(Sub-agent)는 처음에 "/goal이 실재하는가"라는 방식으로 웹 검색을 수행했고, 진위가 불분명한 SEO 블로그의 요약 내용에 끌려 "기재되어 있음"이라고 즉시 답변할 뻔했습니다. "페이지의 내용을 한 글자도 빠짐없이 그대로 발췌해줘"라는 중립적인 지시를 통해 1차 자료를 직접 읽게 한 후부터가 진정한 검증이었습니다. 치트 시트 (Cheat sheet)를 의심한다면, 검증 프로세스 또한 동일한 강도로 의심할 필요가 있습니다.

2. "권장(recommended)"은 스코프 (Scope)를 직접 눈으로 확인한 뒤에. /checkup의 "전체 실행(권장)"에는 git 관리 파일의 편집이 포함되어 있었고, 권한 설정의 "적용하기(권장)"에는 모든 프로젝트에 영향을 미치는 글로벌 (Global) 변경 사항이 포함되어 있었습니다. 제안 자체는 올바르더라도, 영향 범위가 리포지토리 (Repository, 스코프)를 벗어나지 않는지는 인간이 직접 확인하는 것이 좋습니다.

3. 명령어를 암기하기보다 활용할 것. claude -p "/명령어명" 방식의 일회성 실행 모드 (Print 모드/Headless 모드)를 통해 실재 여부와 대략적인 동작을 확인할 수 있습니다. 모든 명령어를 외우기보다는, 궁금한 것부터 실제로 시도하며 도입해 나가는 것이 좋아 보입니다.

원문 출처에 기재된 명령어는 모두 "실재하는 기능"이었습니다.

항상 똑같은 명령어(model, rename, clear, exit 등)만 사용해 왔지만, 조금씩 업무 흐름에 도입하여 AI 라이프를 즐기고 싶습니다.

참고 링크

Discussion