d02/08. recap-and-retrospective.md

2일차 정리: 흐름 복기와 현업 적용

2일간의 SDD 흐름 복기

아래 흐름을 보면서 각 단계에서 무엇을 했는지 말로 설명할 수 없는 단계가 있다면 해당 문서를 다시 확인합니다.

1. constitution으로 프로젝트 원칙 고정
2. Greenfield spec 작성
3. clarify로 모호성 제거
4. plan, tasks, analyze로 구현 전 설계 고정
5. implement로 기준선 생성
6. baseline-v1.0 태그 고정
7. Brownfield 기능 추가를 새 spec으로 시작
8. bugfix를 fix 브랜치와 재현 테스트로 처리
9. merge 전 검토 후 main 병합
10. 변경 요청 시 cascade 재실행 여부 판단

스스로에게 물어보기

• spec 없이 태그 기능을 추가했다면 어떤 일이 벌어졌을까?
• 버그 수정 시 테스트를 먼저 작성한 것이 왜 중요한가?
• AI가 생성한 코드를 각 phase마다 확인한 것이 어떤 차이를 만들었는가?
• 기준선을 먼저 확인하지 않았다면 오늘 작업에서 어떤 혼란이 생겼을까?

현업 적용 계획 작성

아래 항목을 직접 작성합니다. SDD를 도입하겠다는 막연한 다짐이 아니라 다음 주에 당장 할 수 있는 첫 번째 행동을 정합니다.

• 내가 유지보수 중인 기존 프로젝트 하나
• 그 프로젝트의 현재 기준선을 어떻게 정의할지
• 다음 변경 요청이 들어오면 spec부터 시작할지 fix 브랜치부터 시작할지 판단 기준
• 다음 주 안에 시도할 가장 작은 SDD 실험 1개

참고 자료

• d01/README.md: 1일차 전체 그림
• d01/09_implement-baseline-workshop.md: 기준선 생성 맥락
• d02/README.md: 2일차 전체 그림

마무리

2일차의 핵심은 새 기능을 추가하는 능력 자체보다 기존 것을 망가뜨리지 않으면서 바꾸는 능력입니다. SDD는 바로 그 지점을 구조적으로 돕는 방식입니다.