비교 - 검증 우선 워크플로 vs 속도 우선 워크플로¶
비교 대상¶
- 검증 우선 워크플로:
/tdd,/code-review,/handoff-verify,/verify-loop처럼 검증 근거를 먼저 확보하고 완료를 선언하는 경로 - 속도 우선 워크플로:
/explore,/quick-commit처럼 작은 변경을 빠르게 마무리하는 경로
핵심 차이¶
| 항목 | 검증 우선 워크플로 | 속도 우선 워크플로 |
|---|---|---|
| 목표 | 증거 기반 완료, 품질 편차 최소화 | 짧은 작업의 마찰 비용 최소화 |
| 강점 | 완료 기준이 명확함, 팀 작업에서 신뢰도 높음 | 빠른 반복, 작은 수정에 적합, 절차 부담이 낮음 |
| 약점 | 작은 작업에는 과할 수 있음, 시간 비용이 큼 | 근거 부족 위험, 습관화되면 품질 편차가 커질 수 있음 |
| 적합한 역할 | 기능 구현, 리스크가 있는 변경, 팀 핸드오프 | 사소한 수정, 문맥이 명확한 작은 정리, 이미 충분히 검증된 변경 |
| 실패 시 위험 | 과도한 절차로 속도가 불필요하게 느려짐 | 완료 선언이 검증보다 앞서서 회귀나 누락이 생김 |
이 저장소 맥락에서의 결론¶
claude-forge는 속도를 부정하지 않지만, 기본 철학은 검증 우선 쪽에 더 가깝습니다. /quick-commit 같은 빠른 경로도 존재하지만, README 전반의 메시지는 verification.md, /handoff-verify, verify-agent처럼 "검증 없는 완료를 막는 환경"을 기본값으로 두는 쪽에 있습니다. 따라서 속도 우선 경로는 예외적 최적화이고, 검증 우선 경로가 표준 작업 체인으로 읽는 편이 맞습니다.
언제 균형이 깨지는가¶
- 작은 작업까지 무조건 무거운 검증 체인을 적용할 때
- 빠른 커밋 경로가 점점 기본값이 되어 검증 기준이 무너질 때
- 팀이 작업 크기 기준 없이 서로 다른 완료 경로를 섞어 쓸 때