들어가며 — 1편 복습, 그리고 ‘조종석’으로

지난 1편에서 우리는 Claude Code의 엔진룸에 들어가 봤습니다. 모델 라인업, effort 레벨, 권한 모드, 1M 컨텍스트 운용, CLAUDE.md 계층까지 — 내부에서 어떤 톱니바퀴가 맞물려 돌아가는지 해부했죠. 이제 엔진의 작동 원리를 알았으니, 본격적으로 조종석에 앉을 차례입니다.

Claude Code를 쓰다 보면 자연어로 대화하는 것만으로도 꽤 많은 일을 할 수 있습니다. 하지만 진짜 생산성 폭발은 슬래시 커맨드(Slash Commands)를 손에 익힐 때 시작됩니다. 마치 IDE의 단축키를 외우면 마우스 없이도 코딩 속도가 두 배가 되는 것처럼, 슬래시 커맨드는 Claude Code의 숨겨진 가속 페달입니다.

이번 2편에서는 세 가지 핵심을 다룹니다.

• 슬래시 커맨드 30+종을 5개 카테고리로 나눈 실전 치트시트
• 권한 그라데이션 — Plan mode, /ultraplan, Auto mode를 작업 유형에 매핑하는 전략
• 세션 라이프사이클 — /resume부터 /clear까지, 대화를 ‘자산’으로 관리하는 법
• 자동화 커맨드 심층 분석 — /security-review, /autofix-pr, /loop, /schedule의 실무 활용

글이 꽤 길지만, 끝까지 읽으면 Claude Code를 다루는 손놀림이 확연히 달라질 겁니다. 바로 시작하겠습니다.

1. 슬래시 커맨드 전체 조감 — 왜 카테고리가 필요한가

Claude Code의 슬래시 커맨드는 현재 30종 이상입니다. 버전이 올라갈 때마다 신규 커맨드가 추가되고, 플러그인과 스킬 시스템을 통해 사용자 정의 커맨드까지 늘어나고 있습니다. 이 많은 커맨드를 그냥 알파벳순으로 나열하면 머릿속에 정리가 안 됩니다.

그래서 이 글에서는 목적(intent) 기반 5개 카테고리로 분류합니다.

• 모델·성능(Model & Performance) — 어떤 모델로, 얼마나 깊이 생각할지
• 세션·컨텍스트(Session & Context) — 대화를 저장·복원·분기·정리
• 검토·품질(Review & Quality) — 코드 리뷰, 보안 점검, PR 분석
• 자동화·반복(Automation & Scheduling) — 반복 작업, 무인 실행, 예약
• 유틸리티(Utility) — 설정, 도움말, 기타 편의 기능

이 분류를 머릿속에 넣어두면, “지금 내가 하려는 건 어떤 종류지?”라는 질문 하나로 필요한 커맨드를 바로 떠올릴 수 있습니다.

2. 카테고리별 슬래시 커맨드 치트시트

2-1. 모델·성능 (Model & Performance)

1편에서 다룬 effort 레벨과 모델 선택을 실시간으로 전환하는 커맨드들입니다. 작업 난이도에 따라 즉석에서 “기어 변속”을 할 수 있습니다.

• /model — 현재 세션의 모델을 변경합니다. /model opus, /model sonnet, /model haiku처럼 단축 이름도 지원합니다. 대화 중간에도 바꿀 수 있어서, 복잡한 아키텍처 설계는 Opus로 하고 단순 파일 정리는 Haiku로 전환하는 식의 운용이 가능합니다.
• /effort — 추론 깊이를 low / medium / high / xhigh 중에서 조절합니다. 1편에서 설명했듯이 effort가 높을수록 더 많이 “생각”하지만 토큰 소비와 응답 시간이 늘어납니다. 단순 질문에는 /effort low, 복잡한 버그 추적에는 /effort xhigh가 적합합니다.
• /fast — 같은 Opus 4.6 모델을 유지하면서 출력 속도를 높이는 모드입니다. 모델이 바뀌는 것이 아니라 출력 최적화가 적용되는 것이므로, 품질 저하 없이 빠른 응답이 필요할 때 유용합니다.

실전 팁: 하루 작업을 시작할 때 /effort medium으로 세팅해두고, 정말 까다로운 문제를 만날 때만 /effort high나 /effort xhigh로 올리는 것이 비용 대비 효율이 가장 좋습니다. “항상 xhigh”는 마치 시내 주행에서 항상 6단 기어를 넣는 것과 같습니다.

2-2. 세션·컨텍스트 (Session & Context)

세션 관련 커맨드는 이번 편의 핵심이므로 뒤에서 별도 섹션으로 깊이 다룹니다. 여기서는 개요만 정리합니다.

• /resume — 이전 세션을 이어서 작업합니다. 세션 ID를 지정하거나, 최근 세션 목록에서 선택할 수 있습니다.
• /fork — 현재 세션을 복제하여 새로운 분기를 만듭니다. 원본 세션은 그대로 보존됩니다.
• /recap — 현재 세션의 핵심 내용을 요약합니다. 긴 대화 중간에 “지금까지 뭘 했지?”를 빠르게 확인할 때 씁니다.
• /rename — 세션에 의미 있는 이름을 붙입니다. 나중에 /resume으로 되돌아올 때 찾기 쉬워집니다.
• /clear — 현재 대화 내용을 모두 지우고 새로 시작합니다. 세션 자체는 유지되지만 컨텍스트가 초기화됩니다.
• /compact — 1편에서 언급했듯이, 컨텍스트 윈도우가 차올랐을 때 대화를 압축합니다. 자동 압축도 되지만 수동으로 타이밍을 잡을 수도 있습니다. 선택적으로 압축 지시(어떤 내용을 유지할지)를 인자로 전달할 수 있습니다.

실전 팁: 세션 이름 규칙을 만들어두면 관리가 편합니다. 예를 들어 /rename feat/user-auth-api처럼 브랜치 이름과 맞추면, 나중에 어떤 세션이 어떤 작업이었는지 한눈에 들어옵니다.

2-3. 검토·품질 (Review & Quality)

코드 품질을 높이는 데 특화된 커맨드들입니다. 혼자 개발할 때도 “AI 코드 리뷰어”를 옆에 두는 효과를 줍니다.

• /review — 현재 작업 디렉터리의 변경 사항(git diff)을 리뷰합니다. PR을 올리기 전 셀프 리뷰 용도로 매우 유용합니다. 코드 스타일, 잠재적 버그, 성능 이슈를 짚어줍니다.
• /security-review — 보안 관점에서 코드를 정밀 검사합니다. OWASP Top 10 기준으로 SQL 인젝션, XSS, 인증 우회 등의 취약점을 탐지합니다. 뒤에서 자동화 섹션에서 상세히 다룹니다.
• /autofix-pr — PR의 리뷰 코멘트를 읽고 자동으로 수정 사항을 적용합니다. GitHub Actions와 연동하면 리뷰어가 코멘트를 달자마자 수정이 시작되는 워크플로우를 만들 수 있습니다.
• /simplify — 변경된 코드를 검토하여 재사용성, 품질, 효율성을 개선합니다. 리팩터링 단계에서 “이 코드를 더 단순하게 만들 수 있을까?”를 자동으로 점검합니다.

실전 팁: 커밋 전에 /review → /security-review 순서로 돌리는 습관을 들이면, PR 리뷰에서 받는 지적이 확 줄어듭니다. Hook(4편에서 다룰 예정)을 설정하면 이 과정을 완전 자동화할 수도 있습니다.

2-4. 자동화·반복 (Automation & Scheduling)

Claude Code의 진정한 힘이 드러나는 영역입니다. 단발성 대화를 넘어서 지속적·반복적 작업을 처리합니다.

• /loop — 지정된 간격으로 프롬프트나 슬래시 커맨드를 반복 실행합니다. 예: /loop 5m /review는 5분마다 코드 리뷰를 실행합니다. 기본 간격은 10분입니다. 배포 상태 모니터링, 주기적 테스트 실행 등에 활용됩니다.
• /schedule — 크론 스케줄로 원격 에이전트를 예약 실행합니다. /loop이 “세션 안에서의 반복”이라면, /schedule은 “세션 밖에서의 예약”입니다. 매일 새벽 3시에 의존성 업데이트 체크, 매주 월요일 보안 스캔 같은 작업을 걸어둘 수 있습니다.
• /autofix-pr — (검토 카테고리와 겹치지만) 자동화 관점에서 보면, CI/CD 파이프라인의 한 단계로 동작할 수 있습니다. PR이 열릴 때마다 자동으로 리뷰 + 수정을 수행하는 무인 워크플로우의 핵심 요소입니다.

이 카테고리의 커맨드들은 뒤에서 별도 심층 분석 섹션을 마련했습니다.

2-5. 유틸리티 (Utility)

일상적으로 자주 쓰는 편의 커맨드들입니다.

• /help — 사용 가능한 커맨드 목록과 간단한 설명을 보여줍니다. 커맨드가 기억나지 않을 때 첫 번째로 칠 것.
• /config — 테마, 기본 모델, 알림 설정 등 간단한 설정을 변경합니다.
• /commit — 현재 변경 사항으로 git 커밋을 생성합니다. 커밋 메시지를 AI가 자동으로 작성해주며, Conventional Commits 형식을 따릅니다.
• /pr — Pull Request를 생성합니다. 제목, 본문, 라벨까지 자동으로 작성해줍니다.
• /status — 현재 세션의 상태(모델, effort, 권한 모드, 컨텍스트 사용량 등)를 한눈에 보여줍니다.
• /vim — Vim 스타일 키바인딩을 활성화합니다. Vim 사용자에게는 익숙한 조작감을 제공합니다.
• /terminal-setup — 터미널 환경(Shift+Enter 줄바꿈 등)을 최적화합니다.
• /cost — 현재 세션의 토큰 사용량과 비용을 확인합니다. 비용 관리에 필수적입니다.
• /logout — 현재 인증을 해제합니다.
• /bugs — 버그 리포트를 위한 GitHub Issues 페이지를 엽니다.

3. 권한 그라데이션 — Plan · /ultraplan · Auto, 언제 어떻게 쓸 것인가

1편에서 권한 모드의 내부 처리를 살펴봤습니다. 이번에는 실무에서 어떤 작업에 어떤 모드를 매핑할지, 구체적인 의사결정 프레임워크를 제시합니다.

3-1. 세 가지 모드의 스펙트럼

Claude Code의 권한 모드는 연속적인 스펙트럼입니다. 왼쪽 끝이 가장 보수적이고, 오른쪽 끝이 가장 자율적입니다.

Plan mode (가장 보수적)

• Claude가 코드를 직접 수정하지 않습니다.
• “이렇게 하면 어떨까요?”라는 계획만 제시합니다.
• 개발자가 계획을 검토하고 승인해야 실행으로 넘어갑니다.
• 적합한 상황: 프로덕션 코드 변경, 아키텍처 결정, 처음 접하는 코드베이스 탐색

/ultraplan (전략적 계획)

• Plan mode의 강화 버전입니다. 단순 계획을 넘어서 다단계 전략을 수립합니다.
• 복잡한 리팩터링이나 대규모 마이그레이션처럼 여러 파일에 걸친 변경을 체계적으로 설계합니다.
• 각 단계의 리스크, 의존성, 실행 순서까지 포함한 상세 계획을 제시합니다.
• 적합한 상황: 대규모 리팩터링, DB 스키마 마이그레이션, 모놀리스 → 마이크로서비스 전환 계획, 복잡한 버그의 근본 원인 분석

Auto mode (가장 자율적)

• Claude가 필요한 도구를 자율적으로 선택하고 실행합니다.
• 파일 읽기, 편집, 터미널 명령 실행, 테스트 실행까지 승인 없이 진행합니다.
• 단, 권한 설정에서 허용된 범위 내에서만 동작합니다. 설정되지 않은 도구를 쓰려고 하면 여전히 승인을 요청합니다.
• 적합한 상황: 잘 정의된 기능 구현, 테스트 작성, 문서 업데이트, 반복적인 코드 수정

3-2. 작업 유형별 매핑 가이드

아래 표는 실무에서 자주 만나는 작업 유형과 권장 모드를 정리한 것입니다.

탐색·학습 단계

• “이 코드베이스의 구조를 파악하고 싶어” → Plan mode
• “이 버그의 원인이 뭘까?” → Plan mode (원인 파악까지만)
• “이 라이브러리를 교체하려면 어떤 영향이 있을까?” → /ultraplan

설계·의사결정 단계

• “인증 시스템을 JWT에서 세션 기반으로 바꾸고 싶어” → /ultraplan
• “API 엔드포인트 15개를 RESTful 규칙에 맞게 재설계” → /ultraplan
• “이 컴포넌트에 로딩 상태를 추가해줘” → Plan mode (간단하므로)

구현·실행 단계

• “이 함수에 대한 유닛 테스트 작성” → Auto mode
• “TODO 주석이 있는 곳을 전부 구현” → Auto mode (+ 중간 확인)
• “이 PR의 리뷰 코멘트 반영” → Auto mode (명확한 지시가 있으므로)
• “프로덕션 DB 마이그레이션 스크립트 작성” → Plan mode (위험도 높음)

유지보수·운영 단계

• “의존성 업데이트하고 테스트 돌려줘” → Auto mode
• “보안 취약점 스캔” → Auto mode (/security-review)
• “성능 프로파일링 결과 분석” → Plan mode

3-3. 모드 전환의 기술

핵심은 한 세션 안에서도 모드를 유연하게 전환하는 것입니다. 처음부터 끝까지 하나의 모드만 고집할 필요가 없습니다.

전형적인 워크플로우 예시:

1. Plan mode로 시작 — “이 기능을 어떻게 구현하면 좋을지 계획 세워줘”
2. 계획 검토 후, 만족스러우면 Auto mode 전환 — “좋아, 이 계획대로 구현해줘”
3. 구현 중 예상치 못한 문제 발견 → 다시 Plan mode — “잠깐, 이 부분은 다시 생각해보자”
4. 문제 해결 후 Auto mode로 복귀 — “수정된 방향으로 계속 진행”

이 전환이 자연스러워지면, Claude Code는 단순한 “코드 생성기”가 아니라 페어 프로그래밍 파트너로 진화합니다.

4. 세션 라이프사이클 심층 분석

세션(Session)은 Claude Code에서 하나의 대화 단위입니다. 하지만 단순한 채팅 로그가 아닙니다. 세션에는 컨텍스트, 작업 상태, 도구 실행 이력이 모두 담겨 있습니다. 이것을 제대로 관리하면, 작업의 연속성과 재현성이 극적으로 향상됩니다.

4-1. 세션의 탄생 — 새 세션 시작

Claude Code를 실행하면 새 세션이 시작됩니다. 이때 다음이 자동으로 로드됩니다:

• CLAUDE.md 파일 계층 (1편 참고)
• 자동 메모리(auto memory) 파일
• 현재 디렉터리의 git 상태
• 이전 세션의 요약(설정에 따라)

세션 시작 시 부여되는 세션 ID는 나중에 /resume으로 돌아올 때 사용됩니다. 세션 ID는 자동 생성되지만, /rename으로 사람이 읽기 좋은 이름을 붙일 수 있습니다.

4-2. /resume — 중단된 작업 이어가기

/resume은 세션 라이프사이클에서 가장 중요한 커맨드입니다. 노트북을 닫았다가 다시 열 때, 퇴근 후 다음 날 아침에 이어서 작업할 때, /resume 하나로 어제의 컨텍스트가 복원됩니다.

사용법:

• /resume — 최근 세션 목록을 보여주고 선택
• /resume [session-id] — 특정 세션 ID로 직접 복원
• /resume [session-name] — /rename으로 붙인 이름으로 복원

복원되는 것:

• 대화 히스토리 전체 (압축된 경우 요약본)
• 작업 디렉터리 정보
• 마지막으로 사용한 모델과 effort 설정
• 진행 중이던 todo 리스트 상태

복원되지 않는 것:

• 실행 중이던 프로세스 (서버, 와처 등)
• 임시 환경 변수
• 열려 있던 파일 핸들

실전 팁: 길고 복잡한 작업을 할 때는 중간중간 /rename으로 세션 이름을 업데이트하세요. 예를 들어 /rename auth-api-step3-db-schema처럼 진행 단계를 이름에 반영하면, 나중에 어느 시점으로 돌아가야 할지 명확해집니다.

4-3. /fork — 세션 분기, 실험의 자유

/fork는 git branch와 비슷한 개념입니다. 현재 세션의 모든 컨텍스트를 복제하여 새로운 세션을 만듭니다. 원본 세션은 그대로 보존됩니다.

언제 쓸까?

• 실험적 접근을 시도할 때: “이 방향이 맞는지 확신이 없으니, 일단 시도해보고 안 되면 원본으로 돌아가자”
• A/B 비교가 필요할 때: 같은 문제를 두 가지 방법으로 풀어보고 비교
• 위험한 변경 전: 프로덕션 코드를 대폭 수정하기 전에 세션을 포크해두면 안전망이 됩니다

주의할 점: /fork는 세션(대화 컨텍스트)만 복제합니다. 파일 시스템의 변경사항은 복제하지 않습니다. 파일 레벨의 분기가 필요하면 git branch와 함께 사용해야 합니다. 즉, git checkout -b experiment + /fork를 함께 실행하는 것이 안전한 실험 패턴입니다.

4-4. /recap — 맥락 재확인

/recap은 현재 세션에서 지금까지 무슨 일이 있었는지를 요약해줍니다.

특히 유용한 상황:

• 긴 대화 후 현재 상태를 정리하고 싶을 때
• /resume으로 복원한 뒤, “어디까지 했더라?”를 빠르게 확인할 때
• 다른 사람에게 작업 내용을 전달할 때 (요약을 복사해서 공유)

/recap과 /compact의 차이를 혼동하는 분이 많습니다. /recap은 요약을 보여주기만 합니다. 컨텍스트를 건드리지 않습니다. 반면 /compact는 실제로 컨텍스트를 압축합니다. /recap은 읽기 전용, /compact는 쓰기 작업입니다.

4-5. /clear — 깔끔한 재시작

/clear는 현재 세션의 대화 내용을 모두 지웁니다. 하지만 세션 자체를 삭제하는 것은 아닙니다. 같은 작업 디렉터리에서, CLAUDE.md와 메모리는 유지한 채, 대화만 초기화합니다.

언제 쓸까?

• 잘못된 방향으로 한참 진행한 뒤, 처음부터 다시 시작하고 싶을 때
• 민감한 정보가 대화에 포함되어서 지우고 싶을 때
• 컨텍스트가 너무 오염되어서 /compact로도 정리가 안 될 때

/clear vs 새 세션 시작: /clear는 현재 디렉터리와 설정을 유지합니다. 새 세션을 시작하면 모든 것이 초기 상태로 돌아갑니다. 대부분의 경우 /clear가 더 편리합니다.

4-6. 세션 라이프사이클 종합 워크플로우

이 다섯 개 커맨드를 조합하면 다음과 같은 강력한 워크플로우가 만들어집니다:

1. 작업 시작: 새 세션 또는 /resume
2. 작업 명명: /rename feat/payment-gateway
3. 작업 진행: 코드 작성, 리뷰, 테스트
4. 중간 점검: /recap으로 진행 상황 확인
5. 실험 필요: /fork로 분기 → 실험 → 실패하면 원본 /resume
6. 컨텍스트 관리: 대화가 길어지면 /compact로 압축
7. 방향 전환: 근본적으로 잘못됐으면 /clear로 리셋
8. 작업 종료: 세션 자동 저장 → 다음에 /resume으로 복귀

이 순환이 익숙해지면, Claude Code와의 대화가 일회성 질답이 아니라 지속적인 프로젝트 협업이 됩니다.

5. 자동화 커맨드 심층 분석

이제 실무에서 가장 강력한 임팩트를 만들어내는 자동화 커맨드 네 가지를 깊이 파봅니다.

5-1. /security-review — AI 보안 감사관

/security-review는 현재 코드베이스(또는 변경 사항)를 보안 관점에서 정밀 분석합니다.

검사 항목 (주요):

• 인젝션 공격: SQL 인젝션, 커맨드 인젝션, XSS(Cross-Site Scripting)
• 인증·인가: 하드코딩된 비밀번호, 약한 토큰 생성, 권한 검증 누락
• 데이터 노출: 민감 정보 로깅, 에러 메시지를 통한 정보 유출
• 의존성: 알려진 취약점이 있는 라이브러리 사용
• 설정: 디버그 모드 활성화, CORS 와일드카드, 보안 헤더 미설정

사용 패턴:

• /security-review — 전체 변경 사항 검사
• 특정 파일이나 디렉터리를 지정하여 범위를 좁힐 수도 있습니다
• CI/CD 파이프라인에 통합하면 매 PR마다 자동 보안 검사가 됩니다

실전 사례: 한 개발자가 로그인 API를 구현한 뒤 /security-review를 돌렸더니, bcrypt의 salt round가 4로 설정된 것과 로그인 실패 응답에서 “이메일이 존재하지 않습니다” vs “비밀번호가 틀렸습니다”를 구분해서 보여주는 열거 공격(enumeration attack) 취약점을 잡아냈습니다. 이런 실수는 사람 리뷰어도 놓치기 쉽습니다.

5-2. /autofix-pr — 리뷰 코멘트 자동 반영

/autofix-pr은 GitHub PR의 리뷰 코멘트를 읽고, 해당 피드백을 코드에 자동으로 반영합니다.

동작 흐름:

1. PR 번호를 입력하거나, 현재 브랜치의 열린 PR을 자동 감지
2. 리뷰 코멘트를 파싱하여 수정 요청 사항 추출
3. 각 코멘트에 대해 코드 수정을 수행
4. 수정 결과를 새 커밋으로 푸시 (확인 후)

활용 시나리오:

• 개인 프로젝트: 셀프 리뷰 후 코멘트를 달아두고, /autofix-pr로 일괄 처리
• 팀 프로젝트: 시니어 개발자가 리뷰 코멘트를 달면, 주니어가 /autofix-pr로 빠르게 반영
• CI 통합: GitHub Actions에서 자동 실행하면, 리뷰어가 “Approve” 대신 코멘트만 달아도 자동 수정 → 재리뷰의 빠른 순환이 가능

주의사항: /autofix-pr이 항상 완벽한 수정을 보장하지는 않습니다. 특히 아키텍처 수준의 피드백(“이 접근 방식 자체를 바꿔야 합니다”)은 자동화하기 어렵습니다. 구체적이고 로컬한 피드백(“이 변수명을 바꿔주세요”, “null 체크를 추가해주세요”)에서 가장 잘 작동합니다.

5-3. /loop — 세션 내 반복 실행

/loop은 지정된 간격으로 프롬프트나 커맨드를 반복 실행합니다.

문법:

• /loop 5m /review — 5분마다 코드 리뷰 실행
• /loop 10m 테스트를 실행하고 실패하면 수정해줘 — 10분마다 테스트 + 자동 수정
• /loop 30m /security-review — 30분마다 보안 검사
• 간격 미지정 시 기본값은 10분

실전 활용:

• 개발 중 지속적 테스트: /loop 3m 테스트를 돌리고 실패하면 알려줘 — TDD 워크플로우에서 지속적으로 테스트 상태를 모니터링
• 배포 후 모니터링: /loop 5m 헬스체크 엔드포인트를 호출하고 결과를 알려줘 — 배포 직후 안정성 확인
• 코드 품질 감시: 대규모 리팩터링 중 /loop 10m /review를 걸어두면, 변경 사항이 쌓일 때마다 자동으로 리뷰

/loop vs /schedule 의 차이: /loop은 현재 세션 안에서 동작합니다. 세션을 닫으면 반복도 멈춥니다. 세션과 무관하게 예약 실행이 필요하면 /schedule을 써야 합니다.

5-4. /schedule — 크론 기반 예약 실행

/schedule은 원격 에이전트(trigger)를 크론 스케줄로 예약합니다. /loop이 “지금 내가 보고 있는 동안 반복”이라면, /schedule은 “나 없어도 알아서 실행”입니다.

사용 예시:

• 매일 새벽 2시에 의존성 취약점 스캔 실행
• 매주 월요일 오전 9시에 주간 코드 품질 리포트 생성
• 매 6시간마다 외부 API 호환성 테스트

구성 요소:

• 크론 표현식: 표준 cron 형식 (분 시 일 월 요일)
• 실행 프롬프트: 에이전트에게 전달할 지시
• 알림 설정: 실행 결과를 어디로 보낼지 (이메일, Slack, 웹훅 등)

/schedule은 5편 “Remote Control · Cloud · 관측”에서 더 깊이 다룰 예정입니다. 여기서는 “이런 것이 가능하다”는 개념만 잡아두세요.

6. 슬래시 커맨드 조합의 실전 레시피

개별 커맨드를 아는 것보다 중요한 것은 커맨드를 조합하는 감각입니다. 실무에서 자주 쓰는 조합 패턴 몇 가지를 소개합니다.

레시피 1: 안전한 대규모 리팩터링

1. /rename refactor/auth-system-v2 — 세션 명명
2. /effort xhigh — 최고 추론 깊이 설정
3. Plan mode에서 /ultraplan — 전략 수립
4. /fork — 실험 분기 생성 (동시에 git branch도)
5. Auto mode로 전환 — 계획 실행
6. /review — 변경 사항 검토
7. /security-review — 보안 검사
8. 문제없으면 /commit → /pr

레시피 2: 긴 호흡의 버그 추적

1. /rename debug/memory-leak-api-server
2. /effort high
3. Plan mode — 가설 수립: “어디서 메모리 릭이 발생할 수 있는지 분석해줘”
4. 가설 검증을 위한 Auto mode — 로그 분석, 프로파일링 코드 삽입
5. /recap — 중간 정리: “지금까지 어떤 가설을 검증했고 결과가 뭐였지?”
6. 원인 특정 후 수정 → /review → /commit

레시피 3: 일일 코드 품질 루틴

1. /resume daily-quality-check — 매일 같은 세션 이어가기
2. /security-review — 보안 점검
3. /review — 전반적 코드 리뷰
4. /cost — 비용 확인
5. /compact — 컨텍스트 정리 (매일 쌓이므로)

레시피 4: PR 리뷰 자동화 파이프라인

1. 팀원이 PR 생성
2. CI에서 Claude Code 실행: /autofix-pr [PR번호]
3. /loop 10m으로 추가 코멘트 모니터링
4. 모든 코멘트 해결 시 자동으로 “Ready for re-review” 라벨 추가

7. 커맨드 기억법 — 멘탈 모델 만들기

30개가 넘는 커맨드를 외우려고 하지 마세요. 대신 멘탈 모델을 만드세요.

“운전” 메타포

• /model, /effort, /fast = 기어와 가속 페달. 상황에 맞게 변속한다.
• /resume, /fork, /clear = 내비게이션. 경로를 저장하고, 분기하고, 초기화한다.
• /review, /security-review = 계기판 경고등. 문제를 조기에 발견한다.
• /loop, /schedule = 크루즈 컨트롤. 반복 작업을 자동화한다.
• /commit, /pr = 목적지 도착. 결과물을 확정한다.

이 메타포 하나면, “지금 내가 해야 할 건 뭐지?”라는 질문에 바로 해당 커맨드 그룹이 떠오릅니다.

20/80 법칙 — 먼저 익힐 커맨드 7개

전체 커맨드 중 일상적으로 80% 이상 사용하는 것은 다음 7개입니다:

1. /effort — 매 작업 시작 시
2. /resume — 매일 작업 시작 시
3. /compact — 대화가 길어질 때
4. /review — 커밋 전
5. /commit — 작업 완료 시
6. /rename — 세션 생성 직후
7. /help — 나머지가 기억 안 날 때

이 7개를 먼저 손에 익히고, 나머지는 필요할 때 /help에서 찾아 쓰면 됩니다.

8. 고급 활용 — 커스텀 슬래시 커맨드

Claude Code는 사용자 정의 슬래시 커맨드도 지원합니다. 프로젝트의 .claude/commands/ 디렉터리에 마크다운 파일을 만들면, 해당 파일 이름이 슬래시 커맨드가 됩니다.

예시: 프로젝트 전용 배포 체크리스트

.claude/commands/deploy-check.md 파일을 만들고 다음 내용을 넣습니다:

“다음 배포 전 체크리스트를 실행해주세요:
1. 모든 테스트 통과 확인
2. /security-review 실행
3. 환경변수 설정 확인
4. DB 마이그레이션 스크립트 검증
5. CHANGELOG.md 업데이트 확인”

이제 /deploy-check라고 입력하면 이 전체 체크리스트가 실행됩니다.

커스텀 커맨드의 장점:

• 팀 전체가 동일한 워크플로우를 공유할 수 있습니다 (git으로 관리)
• 반복적인 프롬프트를 매번 타이핑할 필요가 없습니다
• 프로젝트별 특화된 작업을 표준화할 수 있습니다

또한 사용자 개인의 글로벌 커맨드도 만들 수 있습니다. ~/.claude/commands/ 디렉터리에 파일을 놓으면 모든 프로젝트에서 사용 가능한 개인 커맨드가 됩니다. 팀 커맨드와 개인 커맨드를 분리할 수 있는 거죠.

인자 전달: 커스텀 커맨드 파일 안에서 $ARGUMENTS 플레이스홀더를 사용하면, 커맨드 실행 시 추가 인자를 받을 수 있습니다. 예를 들어 /deploy-check staging이라고 입력하면, 파일 내의 $ARGUMENTS가 “staging”으로 치환됩니다.

9. 자주 하는 실수와 해결책

실수 1: Auto mode를 켜놓고 방치

문제: Auto mode에서 Claude가 의도하지 않은 파일을 수정하거나, 예상치 못한 커맨드를 실행합니다.

해결: Auto mode를 쓰더라도 권한 설정을 세밀하게 조정하세요. 허용할 도구와 디렉터리를 명시적으로 지정하면, Auto mode의 편리함을 누리면서도 안전성을 확보할 수 있습니다. 4편에서 다룰 Hook을 결합하면 더욱 견고해집니다.

실수 2: /compact 타이밍을 놓침

문제: 컨텍스트 윈도우가 꽉 차서 시스템이 자동 압축을 하는데, 이때 중요한 맥락이 손실됩니다.

해결: 컨텍스트의 70~80% 정도 찼을 때 수동으로 /compact를 실행하세요. 이때 “다음 내용은 꼭 유지해줘: [핵심 사항]”이라고 지시하면, 중요한 맥락이 보존됩니다. /cost로 현재 토큰 사용량을 확인할 수 있습니다.

실수 3: 세션을 이름 없이 방치

문제: 나중에 /resume을 하려고 보니 “session-a1b2c3d4” 같은 ID만 잔뜩 있어서 어떤 세션이 어떤 작업이었는지 알 수 없습니다.

해결: 세션을 시작하자마자 /rename을 습관화하세요. 이름 규칙을 정해두면 더 좋습니다.

실수 4: /fork 없이 위험한 실험

문제: 실험적인 시도를 하다가 세션이 엉망이 되어서 /clear로 다 날려야 합니다.

해결: 조금이라도 불확실한 방향의 작업은 /fork 먼저. 비용은 거의 0인데, 실패 시 복구 비용은 큽니다.

실수 5: /effort를 한 번 설정하고 잊음

문제: /effort xhigh로 설정한 뒤 간단한 질문에도 높은 비용이 계속 발생합니다.

해결: 작업 난이도가 바뀔 때마다 /effort를 조정하는 습관을 들이세요. 복잡한 설계 → xhigh, 간단한 수정 → low, 일반 개발 → medium이 기본 패턴입니다.

10. 슬래시 커맨드 빠른 참조 카드

마지막으로, 이 글에서 다룬 모든 커맨드를 한 곳에 정리합니다. 이 섹션을 북마크해두고 필요할 때 참조하세요.

모델·성능

• /model [name] — 모델 전환
• /effort [level] — 추론 깊이 조절 (low/medium/high/xhigh)
• /fast — 빠른 출력 모드 토글

세션·컨텍스트

• /resume [id|name] — 이전 세션 복원
• /fork — 현재 세션 분기
• /recap — 세션 요약 확인
• /rename [name] — 세션 이름 지정
• /clear — 대화 초기화
• /compact [지시] — 컨텍스트 압축

검토·품질

• /review — 코드 리뷰
• /security-review — 보안 검사
• /autofix-pr [PR] — PR 코멘트 자동 반영
• /simplify — 코드 단순화 검토

자동화·반복

• /loop [간격] [커맨드] — 반복 실행
• /schedule — 크론 예약 실행

유틸리티

• /help — 도움말
• /config — 설정 변경
• /commit — 커밋 생성
• /pr — PR 생성
• /status — 현재 상태 확인
• /cost — 비용 확인
• /vim — Vim 모드
• /terminal-setup — 터미널 최적화
• /logout — 로그아웃
• /bugs — 버그 리포트

마무리 — 다음 편 예고

이번 2편에서는 Claude Code의 슬래시 커맨드 전체를 조감하고, 권한 모드의 실전 매핑 전략, 세션 라이프사이클 관리, 그리고 자동화 커맨드의 활용법까지 다뤘습니다.

핵심을 한 문장으로 요약하면: 슬래시 커맨드는 Claude Code를 ‘대화형 AI’에서 ‘개발 운영 체제’로 격상시키는 인터페이스입니다. 7개 핵심 커맨드부터 손에 익히고, 점차 범위를 넓혀가세요.

하지만 우리가 오늘 다룬 것은 여전히 Claude Code 단독의 이야기입니다. Claude Code의 진정한 잠재력은 외부 시스템과 연결될 때 폭발합니다. 3편에서는 MCP(Model Context Protocol), Plugins, Skills — Claude Code의 확장 생태계를 완전 정복합니다. MCP 프로토콜의 내부 동작(Streamable HTTP, OAuth 2.1)부터, 자체 MCP 서버 만들기, Plugin Marketplace 구조, 그리고 SKILL.md 작성법까지. Claude Code가 혼자서는 못 하는 일들, 예를 들어 Slack 메시지 보내기, Jira 티켓 관리, 데이터베이스 직접 조회 같은 것들을 가능하게 만드는 확장 메커니즘의 전모를 밝힙니다.

Claude Code라는 비행기에 날개를 달아줄 3편, 기대해주세요.

이미지는 Leonardo AI 로 생성되었습니다.

이미지는 Claude AI 로 생성되었습니다.

---