Part 3 정리

Part 3에서 배운 SDD 6단계 사이클, 단계별 검증 도구, Compound 승격, Git Worktree·Agent Teams 를 정리합니다

SDD: 도구를 하나의 사이클로 묶기

Part 2 에서 익힌 도구가 6단계 사이클의 부품으로 들어옵니다. SDD 는 아이디어부터 배포까지를 6단계로 이어 가는 프레임워크입니다.

각 단계의 출력이 다음의 입력 — Compound가 다음 사이클의 도구를 갱신합니다

6단계 사슬: Ideate → Specify → Sketch → Plan → Build → Compound. 각 단계 산출물 (idea.md → spec.md → wireframe.html → plan.md → 코드·커밋 → learnings.md) 이 다음 단계 입력으로 이어집니다
슬래시 커맨드로 단계 호출: /idea-refine·/write-spec·/sketch-wireframe·/draft-plan·/execute-plan·/compound 가 6단계에 1:1 로 대응합니다. 엔지니어링 템플릿이 Skills·Agents·Hooks·Rules·CLAUDE.md 다섯 layer 를 단계마다 미리 배치합니다
Spec 이 사이클 전체를 결정: 같은 도구라도 Spec 이 모호하면 결과가 흔들립니다. 변경 비용이 큰 결정 (인증, 데이터 모델, 외부 API) 은 Spec 에서 먼저 드러내고, 색상·버튼 문구는 기본값에 맡깁니다
What 과 How 의 분리: spec.md 는 "사용자가 무엇을 보게 되는가" 만, plan.md 가 "어떻게 구현하는가" 를 맡습니다. 한 문서에 섞으면 양쪽 검토가 모두 약해집니다

각 단계마다 자기 산출물을 검증하는 도구가 따로 있습니다.

wireframe.html 로 레이아웃 먼저: spec 다음에 코드를 바로 짜지 않고 한 HTML 파일에 base 화면과 시나리오별 화면을 모아 좌우로 비교합니다. Screen Notes 에는 화면 흐름만 적고 비즈니스 로직은 plan 으로 미룹니다
수용 기준이 자동 테스트로: spec 의 수용 기준을 RED → GREEN 테스트로 변환해 Build 사이클을 이끕니다. 관찰 가능한 동작은 자동 검증이 맡고, 디자인·접근성처럼 사람 판단이 필요한 부분만 Human review 로 남깁니다
plan-reviewer 의 4축 정합성: Coverage (spec 시나리오 → plan Task 매핑) · plan 내부 정합성 · wireframe 일관성 · 불변 규칙 커버리지 네 축으로 plan.md 를 머지 전에 점검합니다
code-reviewer 의 5차원 리뷰: 정확성·가독성·아키텍처·보안·성능 다섯 축으로 코드를 검토합니다. Critical 은 즉시 고친 뒤 영향 테스트를 다시 돌리고, Important 는 사용자가 판단하며, Suggestion 은 다음 사이클로 미룹니다
Vercel + GitHub 으로 push 가 곧 배포: 한 번 Import 하면 이후 push 마다 자동 빌드, PR 마다 Preview URL 이 생성됩니다. 빌드 실패 시 로컬 bun run build 재현 여부로 코드 문제와 환경변수 누락을 가릅니다

강한 신호 — 1 사이클 안에서 처리

언제

applied 상태

예시

약한 신호 — 여러 사이클 누적 후

언제

applied 상태

예시

강한 신호는 한 사이클 안에서 즉시 승격, 약한 신호는 여러 사이클 누적 후 승격됩니다

같은 사이클을 여러 번 돌리면 두 종류의 학습이 쌓입니다.

강한 신호는 즉시 승격: /execute-plan 중 사용자가 손으로 고친 적이 있는 패턴은 끝나는 자리에서 learnings.md 에 applied: rule 로 표시되며 바로 도구로 올라옵니다
약한 신호는 누적 후 Compound: 한 사이클에서는 우연처럼 보이지만 3~5 사이클 쌓이면 패턴이 드러나는 신호입니다. applied: not-yet 으로 모아 두면 /compound 가 회고 단계에서 꺼냅니다
승격 자리는 네 곳: 제약 위반은 Rule, 기계적 검사는 Hook, 잘못된 사용법은 Skill, 아키텍처 결정은 CLAUDE.md. 분기 기준이 정해져 있어 같은 신호가 두 자리에 중복되지 않습니다

한 명의 Claude 로 충분하지 않은 순간이 옵니다. 두 갈래 가설을 동시에 시도하거나 서로 다른 레이어를 동시에 손대야 할 때, 격리와 협업에는 서로 다른 도구가 필요합니다.

브랜치만으로는 부족: 한 폴더에는 브랜치가 하나뿐이어서 같은 작업 공간에서 두 Claude 가 일하면 파일이 충돌합니다. git worktree 는 .git 을 공유하면서 작업 폴더만 분리해, 같은 파일을 동시에 수정해도 서로 영향이 없습니다
claude -w <name> 한 줄로 생명주기 자동화: 워크트리 생성 (.claude/worktrees/<name>/), 브랜치 생성 (worktree-<name>), 진입, 세션 종료 시 Keep / Remove 정리까지 한 명령에 묶입니다. 중단된 작업은 워크트리만 남겨 두면 --continue 로 그대로 이어갑니다

Subagent 는 결과만 반환하고 종료, Agent Teams 는 팀원끼리 직접 메시지를 주고받으며 세션 동안 지속합니다

분기 기준은 한 문장: "팀원끼리 구현 중 직접 대화해야 하는가". 다각도 병렬 리뷰, 경합 가설 디버깅, 크로스레이어 구현이 그 대화가 필요한 대표 상황입니다. 그 외에는 Subagent 로 충분합니다
Agent Teams 구성: 실험 플래그 CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 로 켭니다. 리더 + 팀원 2~4 명이 각자의 worktree 와 독립 Context 에서 일하면서 ~/.claude/tasks/<team>/ 공유 Task 리스트와 peer-to-peer 메시지로 협업합니다

전체 코스 정리에서 Part 1·2·3 을 한 페이지로 압축합니다. 이후 학습 방향으로는 Compound Engineering 과 Conductor·Subagent + Worktree 를 활용한 병렬 작업 확장을 다룹니다.