장 02
핵심 루프
DWP는 계획을 목표에서 완료된, 검토 가능한 작업으로 옮기는 작은 연산 집합을 정의합니다. create → execute → refine → resume → status, 그리고 결과를 확인하는 적합성 검증으로서의 verify입니다. 이들이 함께 에이전트가 계획의 수명 내내 따르는 루프를 이룹니다. 에이전트는 한 번에 하나의 작업을 실행하며, 다음으로 넘어가기 전에 각 단계를 검증합니다.
이 루프는 스펙 주도 개발의 운영적 형태입니다. 계획은 에이전트가 맞춰 실행하는 스펙이고, 각 작업은 명시적인 인수 기준을 담으며, 검증 단계는 완료 주장을 완료의 증거로 바꾸는 게이트입니다. 계획과 그 진행 로그가 리포지토리 안에 존재하므로, 루프는 세션과 에이전트를 넘어 재개 가능합니다.
연산들
- create — 목표로부터 새 계획을 생성합니다. 에이전트는 목표를 분석하고 순차적 작업으로 분해한 뒤 계획 파일을 작성합니다. 목표가 모호할 때는 작성하기 전에 명확히 하는 질문을 해야 합니다.
- execute — 계획을 작업 단위로 실행합니다. 에이전트는 각 작업 후 진행 로그를 갱신하고 작업의 완료 상태를 표시합니다. 이유를 기록하지 않고 작업을 건너뛰어서는 안 됩니다.
- refine — 기존 계획을 수정합니다. 에이전트는 작업을 추가, 제거, 재배열할 수 있지만 완료된 작업은 보존하고 작업 표를 갱신해야 합니다.
- resume — 중단된 계획을 이어 갑니다. 에이전트는 진행 로그와 작업 파일을 읽어 상태를 재구성한 뒤, 완료되지 않은 첫 작업부터 계속합니다.
- status — 실행하지 않고 진행 상황을 보고합니다. 에이전트는 완료, 진행 중, 대기 작업을 요약하며 아무것도 바꾸지 않습니다.
- verify — 아무것도 바꾸지 않고 적합성을 확인합니다. 에이전트는 리포지토리가 표준을 충족하는지, 그리고 계획이 잘 구성되었는지 — 모든 작업이 인수 기준과 검증 게이트를 담고 있는지 — 를 보고합니다. 스펙의 적합성 문서를 참고하세요.
.dwp/ 출력 디렉터리
모든 DWP 산출물은 리포지토리 루트의 gitignore된 .dwp/ 디렉터리 아래에 존재합니다. 작업 공간을 버전 관리 밖에 두면 계획의 작업 상태가 프로젝트 이력을 오염시키는 일이 결코 없습니다.
.dwp/
├── plans/
│ └── PLAN_<slug>/
│ ├── README.md
│ ├── PROGRESS.md
│ └── <n>.task_<slug>.md
└── config.yaml아홉 절로 이루어진 작업 구조
- 01 목표
- 02 맥락
- 03 단계
- 04 수용 기준
- 05 검증
- 06 파일
- 07 의존성
- 08 위험
- 09 완료 및 로그
모든 작업 파일은 이 아홉 절을 순서대로 담습니다. 이 구조는 각 작업 단위가 자기 완결적이고 검토 가능함을 보장합니다.
- 목표(Goal) — 작업이 무엇을 달성하는지 서술하는 한 단락.
- 컨텍스트(Context) — 배경, 링크, 그리고 이 작업이 존재하는 이유.
- 단계(Steps) — 수행할 순서대로 정리된 구체적 행동.
- 인수 기준(Acceptance criteria) — 완료를 정의하는 조건의 체크리스트.
- 검증(Validation) — 작업을 확인하기 위해 실행할 명령이나 테스트.
- 파일(Files) — 생성 또는 수정될 것으로 예상되는 경로.
- 의존성(Dependencies) — 다른 작업이나 외부 선행 조건.
- 리스크(Risks) — 무엇이 잘못될 수 있는지와 완화책.
- 완료 & 로그(Completion & Log) — 상태 표시와 함께 시간순 기록.
검증, 완료, 재개
검증은 사후 고려가 아니라 작업의 일부입니다. 각 작업은 완료를 증명하는 명령이나 테스트를 명시하고, 에이전트는 완료를 표시하기 전에 그것들을 실행합니다. 완료는 완료 & 로그 절에 명시적 상태 표시([ ] 시작 안 함, [~] 진행 중, [x] 완료, [!] 차단됨)로 기록됩니다. 재개는 이 표시와 진행 로그에 의존합니다 — 에이전트는 계획이 정확히 어디서 멈췄는지 재구성하고, 끝난 작업을 다시 하지 않으며 완료되지 않은 첫 작업부터 계속할 수 있습니다.