📑 이 챕터에서 다룰 내용
9장에서 BUILD.md를 만들고 첫 기능을 TDD로 구현했습니다. 그 과정에서 /tdd, /clear, /model, /effort 같은 슬래시 명령들을 사용했습니다. 이 장은 그 슬래시 명령들의 풍경 전체를 정리합니다.
이 장은 1탄 v2의 마지막 "전면 재작성" 챕터입니다. v1.0 8장은 "GSD 슬래시 명령"으로 명명됐고 자체 명령을 다뤘습니다. v2에서는 세 가지가 달라집니다.
/gsd:... 명령은 TÂCHES의 GSD 도구 슬래시 명령과 충돌합니다. v2에서는 표준 도구의 공식 명령(/gsd-new-project 등)만 "GSD"로 가리킵니다.
GSD / Spec-Kit / OpenSpec / BMAD / Taskmaster 등의 명령을 비교합니다.
Claude Code 내장 명령 + 우리가 직접 만드는 커스텀 명령을 다룹니다.
자유 창작 단계 진입 가이드 (3탄 이후)를 명시합니다.
자동화는 "단순 작업"만 줄이는 게 아닙니다. 자동화가 깊을수록 "무엇을 자동화할지 결정하는 인간 판단"의 중요성이 커집니다. 자동화의 역설 — 잘못된 자동화는 자동화가 없는 것보다 더 큰 비용을 만듭니다.
슬래시 명령은 "반복 작업의 자동화"입니다. 그러나 매일 안 쓰는 명령까지 자동화하면 학습 부담만 늘어납니다. 매일 쓰는 5개를 자연스럽게 쓰는 게 핵심입니다.
먼저 시장의 풍경을 봅니다. 9개 표준 도구가 각자 자체 슬래시 명령을 갖고 있습니다.
| 도구 | 명령 패턴 | 핵심 명령 |
|---|---|---|
| GSD (TÂCHES) | /gsd-{action} | /gsd-new-project · /gsd-discuss-phase · /gsd-plan-phase · /gsd-execute-phase · /gsd-verify-work · /gsd-ship |
| Spec-Kit | /speckit.{action} | /speckit.constitution · /speckit.specify · /speckit.clarify · /speckit.analyze · /speckit.implement |
| OpenSpec | /opsx{action} 또는 /opsx:{action} | /opsx-explore · /opsx:apply · openspec view |
| BMAD-METHOD | YAML 페르소나 ID | (각 페르소나가 자기 영역의 명령. Mary·Preston·Winston 등) |
| Taskmaster | MCP 서버 호출 | task-master parse-prd · task-master next · task-master expand |
| PromptX | 자연어 위주 | (정형 명령 적음) |
| Intent | IDE 통합 | (IDE 안에서 living spec 자동 동기화) |
| Kiro / AI-DLC | AWS 콘솔 | (AWS 환경에서 phase 자동) |
| specs.md / fabriqa | 다중 모델 호출 | (Claude·Codex·Gemini 동시 사용) |
표를 보면 명확합니다. 각 도구가 자체 슬래시 명령 세트를 가집니다. 어느 도구를 골랐느냐에 따라 "매일 입력하는 명령어"가 완전히 달라집니다.
처음 보면 어지러울 수 있습니다. 그러나 9개를 다 외울 필요는 없습니다. 우리는 5파일+ 사이클을 사용하므로, 위 표는 "3탄 이후 자유 창작 단계에서 표준 도구로 옮길 때 어디로 가는지"의 풍경 정도로 알아두시면 됩니다.
5파일+ 사이클은 위 9개 도구 중 어느 것도 그대로 쓰지 않습니다. Claude Code 자체의 내장 슬래시 명령만 사용하고, 그 위에 "우리가 직접 만드는 커스텀 명령"을 더합니다.
Claude Code 내장 슬래시 명령 (매일 쓰는 5개)
/effort low|medium|high 작업 복잡도 신호 (비용·품질 조절)
/model {모델명} 모델 변경 (Opus / Sonnet / Haiku)
/clear 대화 컨텍스트 초기화
/compact 대화 요약 압축
/tdd TDD 모드 활성화
이 5개가 하루 90%의 사용 빈도를 차지합니다. 자연스럽게 외워집니다.
자주 쓰는 추가 5개
/context 현재 컨텍스트·MCP 상태 확인 /memories AutoMemory 확인·수정 /plan Plan Mode 진입 (Shift+Tab으로도 가능) /powerup 환경 최적화 (설치 후 첫 실행) /security-scan 보안 점검 (ECC 플러그인)
v1.0 → v2 변경
v1.0에서는 자체 명령으로 /gsd:plan, /gsd:execute-phase 등을 다뤘습니다. v2에서는 이 명령들을 자체 명명으로 사용하지 않습니다. 이유는 다음과 같습니다.
- TÂCHES의 GSD 도구가
/gsd-new-project같은 슬래시 명령을 사용 (한 글자 차이로 충돌) - 학습자가 "GSD 명령"이라는 단어를 들을 때 두 가지 의미를 혼동할 위험
- v2의 "5파일+ 사이클" 정체성에서 "GSD" 단어는 TÂCHES 도구만 가리키도록 정리
대신 5파일+ 작업은 자연어 + Claude Code 내장 명령으로 처리합니다.
# v1.0 패턴 — 자체 명령 /gsd:plan /gsd:execute-phase 1 # v2 패턴 — 자연어 + 내장 명령 /model claude-opus-4-6 /effort high "SPEC.md를 읽고 PLAN.md를 작성해줘. [기준]" /model claude-sonnet-4-6 /effort high "REVIEW.md READY: YES 확인. PLAN의 Day 1 작업을 시작해줘."
자연어가 더 길지만 "무엇을 하는지"가 본문에 남습니다. BUILD.md의 LogOnTable 트레이스가 자연스럽게 됩니다.
/effort 명령은 작업 복잡도를 Claude Code에 미리 알려주는 신호입니다. 복잡한 작업에 low를 쓰면 품질이 떨어지고, 단순 작업에 high를 쓰면 비용이 낭비됩니다.
| 레벨 | 적합한 작업 | 예시 | 비용 |
|---|---|---|---|
| low | 간단한 질문 · 단순 코드 수정 · 설명 요청 | "이 변수 이름 바꿔줘" | 💰 |
| medium | 일반 기능 구현 · 버그 수정 (기본값) | "로그인 폼 만들어줘" | 💰💰 |
| high | 복잡한 아키텍처 · 보안 설계 · 페이즈 실행 | "SPEC.md → PLAN.md 변환" | 💰💰💰 |
/model 과의 조합
/effort + /model 조합으로 4가지 패턴이 자연스럽게 형성됩니다.
| 작업 영역 | /model | /effort | 비용 절감 |
|---|---|---|---|
| SPEC v1 작성 | claude-opus-4-6 | high | (그대로) |
| Gemini 1차 검토 반영 | claude-sonnet-4-6 | high | -40% |
| BUILD 일반 기능 구현 | claude-sonnet-4-6 | medium | -60% |
| 단순 텍스트 수정 | claude-haiku-4-5 | low | -85% |
자세한 비용 절감 전략은 21장 (토큰 최적화)에서 다룹니다.
.claude/commands/ 폴더에 마크다운 파일을 만들면 나만의 슬래시 명령이 됩니다. 10번 이상 반복하는 작업을 명령어로 만드세요.
예시 — 매일 아침 점검 명령
매일 아침 5파일+ 상태 점검 명령 ## 점검 항목 1. SPEC.md / PLAN.md / REVIEW.md / BUILD.md / CLAUDE.md 모두 읽고 2. BUILD.md 어제 작업 + LogOnTable 트레이스 요약 3. PLAN.md 오늘 Day 작업 추출 4. 누적 시간 점검 (R4 1인 번아웃 트리거 60h/4주 임박 여부) 5. 오늘 만들 기능 1개 선정 후 보고 6. /effort medium 으로 작업 시작 준비
이 파일을 만들면 /daily-review 명령으로 바로 실행됩니다. 파일명이 명령어 이름이 됩니다.
직접 만들기 어려우면 Claude Code에게 이렇게 요청하세요.
"나는 매일 [작업 내용]을 반복합니다. 이것을 /[명령어이름] 슬래시 명령으로 만들어줘. .claude/commands/ 폴더에 저장해줘."
5파일+ 운영용 추천 커스텀 명령 7개
| 명령 | 역할 | 실행 시점 |
|---|---|---|
/daily-review | 매일 아침 5파일 점검 + 오늘 작업 추출 | 매일 작업 시작 시 |
/gate-check | 게이트 통과 조건 점검 (PLAN.md 게이트 N) | 게이트 마감 전 |
/spec-evolve | SPEC v(N) → v(N+1) 진화 (외부 검토 + 사용자 직관) | 새 결정 발생 시 |
/build-update | BUILD.md 일자별 양식 + LogOnTable 트레이스 자동 채움 | 매일 작업 끝 |
/risk-trigger | 리스크 등록부 R1~RN 트리거 점검 | 매주 일요일 |
/persona-test | 페르소나 일관성 테스트 (E5 적용 시) | 콘텐츠 페르소나 변경 시 |
/face-pace | E2 1인 페이스 점검 (누적 시간·휴식 여부) | 매주 일요일 |
이 7개는 줍줍·TSV 두 프로젝트에서 자연 발생하는 반복 작업입니다. 직접 작성하셔도 되고, Claude Code에 "위 표를 보고 .claude/commands/ 폴더에 7개 명령을 모두 만들어줘"라고 요청하셔도 됩니다.
지금까지 다룬 슬래시 명령은 모두 터미널에서 사람이 직접 입력하는 방식입니다. 하지만 Claude Code는 자동화 스크립트나 CI/CD 파이프라인에서도 호출 가능합니다. 이것을 헤드리스 모드라고 합니다.
기본 사용법
# 기본 형식 claude --print '프롬프트 내용' # 예시 1: 코드 리뷰 claude --print 'src/api/auth.ts를 보안 관점에서 리뷰해줘' # 예시 2: 결과를 파일로 저장 claude --print 'BUILD.md를 분석해 진행률을 알려줘' > status.txt # 예시 3: 다른 명령에 파이프 git diff HEAD~1 | claude --print '이 변경사항을 한국어로 요약해줘' # 예시 4: 파일 내용을 입력으로 cat error.log | claude --print '이 에러의 원인과 해결책 알려줘'
실용 자동화 시나리오 5가지
| 시나리오 | 실행 시점 | 얻는 결과 |
|---|---|---|
| 일일 진행률 리포트 | 매일 오전 9시 (cron) | BUILD.md 기반 진행률 + 다음 단계 |
| 커밋 전 자동 리뷰 | git pre-commit hook | 변경사항의 잠재 문제점 |
| 에러 자동 분석 | Sentry 알림 발생 시 | 에러 원인 + 수정 코드 제안 |
| 주간 코드 품질 점검 | 매주 금요일 | CLAUDE.md 규칙 위반 사항 |
| CI/CD 보안 스캔 | Pull Request 생성 시 | 보안 취약점 자동 탐지 |
실전 예시 — git pre-commit hook
#!/bin/bash DIFF=$(git diff --cached) if [ -z "$DIFF" ]; then exit 0; fi REVIEW=$(echo "$DIFF" | claude --print '이 변경사항에서: 1. 보안 취약점 (API 키 노출 등) 2. CLAUDE.md 규칙 위반 3. 명백한 버그 중 하나라도 있으면 BLOCK이라고 시작하고, 없으면 OK로 시작.') if [[ "$REVIEW" == BLOCK* ]]; then echo "⚠️ $REVIEW" exit 1 fi echo "✅ 자동 리뷰 통과"
헤드리스 모드도 일반 Claude Code와 동일하게 토큰 비용이 발생합니다. 매일 자동 실행되는 스크립트는 한 번 실행에 약 500~3,000 토큰, 한 달 비용 약 $1~5입니다.
매 commit마다 실행되는 hook은 commit 빈도가 높으면 비용이 빠르게 쌓입니다. /effort low + Haiku 모델로 비용을 최소화하세요.
claude --print --model haiku-4-5 '간단한 리뷰 요청'
27장 (Observability)과 결합될 때 드러납니다. Sentry 에러가 발생하면 Claude가 자동 분석하고 Slack으로 결과를 보내는 시스템을 구축할 수 있습니다.
다만 처음부터 모든 것을 자동화하지 마세요. 먼저 일일 리포트 하나만 시작하고 점진 확장하는 것이 좋습니다.
"5파일+ 사이클을 충분히 익힌 후 표준 도구로 옮겨가는 트리거"를 명시합니다.
옮기는 시점의 4가지 트리거
| 트리거 | 의미 | 추천 도구 |
|---|---|---|
| 단일 프로젝트가 19리그 이상 확장 | 작업량이 1인 수동 관리 한계 초과 | GSD (TÂCHES) — 자동화 깊이 |
| 팀 5명+ 합류 | 페르소나 협업 + 역할 분리 필요 | BMAD-METHOD — 7~8 페르소나 |
| 기존 코드(brownfield) 대규모 리팩터 | 변경 명세 중심 + 점진 머지 | OpenSpec — delta spec |
| 여러 마이크로서비스 환경 | 서비스 간 living spec 동기화 | Intent — living spec |
5파일+ 자산을 표준 도구로 옮기는 매핑 가이드
SPEC.md → GSD: PROJECT.md + REQUIREMENTS.md 분리
→ Spec-Kit: /speckit.specify + /speckit.constitution
PLAN.md → GSD: ROADMAP.md + phase별 PLAN.md 분리
→ Spec-Kit: phase tasks
→ Taskmaster: PRD 입력으로
REVIEW.md → GSD: VERIFICATION.md + UAT.md 분리
→ Spec-Kit: /speckit.analyze + /speckit.checklist
BUILD.md → GSD: phase별 SUMMARY.md 분리
→ 모든 도구: atomic commits
CLAUDE.md → GSD: STATE.md
→ Spec-Kit: /speckit.constitution (architectural rules)
→ Cursor: .cursorrules
자세한 매핑은 33장 (자유 창작 준비) + 부록 H + 3탄 권7 "표준 + 확장 컴패니언"에서 다룹니다.
5확장 (E1~E5) 은 어떻게 옮길 것인가
표준 도구로 옮긴 후에도 5확장 5개는 자체 보강 영역으로 남습니다. 이게 핵심입니다.
| 확장 | 표준 도구로 옮긴 후의 자리 |
|---|---|
| E1 회색지대 | SPEC + About 페이지 + 약관 + 콘텐츠 정책에 일관 노출 (도구 무관) |
| E2 1인 페이스 | 운영자 자체 의식 (toggle off 안 됨) |
| E3 두 검토자 | Gemini 외부 검토 + Claude 시뮬 검토 (자동화는 가능, 두 검토자 자체는 필수) |
| E4 LogOnTable | BUILD log 또는 결정 트레이스 폴더 (자동 추적 가능) |
| E5 콘텐츠 SSOT | 도구와 무관 — 콘텐츠 시스템에 SSOT 인터페이스 |
표준 도구로 옮긴 후에도 5확장 5개는 본문에 명시된 자기 운영 의식으로 남습니다. 표준 도구가 코드 영역의 자동화를 풀어줘도, 5확장이 다루는 영역은 운영자 책임으로 남습니다.
- 1️⃣ 핵심: 5파일+ = Claude Code 내장 명령 + 커스텀 명령. 9개 표준 도구 명령은 자유 창작 시 옮겨갈 풍경.
- 2️⃣ 매일 5개:
/effort·/model·/clear·/compact·/tdd - 3️⃣ 자주 쓰는 추가 5개:
/context·/memories·/plan·/powerup·/security-scan - 4️⃣ GSD 명명 정정: v1.0의
/gsd:plan자체 명령 → 자연어 + 내장 명령으로 변경. "GSD"는 이제 TÂCHES 도구만 가리킵니다. - 5️⃣ /effort × /model 조합: SPEC(Opus+high) / 단순 BUILD(Sonnet+medium, -60%) / 텍스트 수정(Haiku+low, -85%)
- 6️⃣ 추천 커스텀 명령 7개:
/daily-review·/gate-check·/spec-evolve·/build-update·/risk-trigger·/persona-test·/face-pace - 7️⃣ 자유 창작 트리거: 19리그+ → GSD / 팀 5명+ → BMAD / brownfield 리팩터 → OpenSpec / 마이크로서비스 → Intent
- 8️⃣ 5확장은 도구 무관 — 운영자 자체 의식으로 영구 남습니다.
11장 — CLAUDE.md + E5 콘텐츠 SSOT. 5파일의 마지막이자 5확장 다섯 개 모두의 완성이 11장에서 이루어집니다.