d02/07. change-management-workshop.md

2일차 실습 7: 변경 요청 대응 워크숍

현실에서 요구사항은 바뀝니다

코드를 다 만들고 나서 사실 이렇게 바꿔야 할 것 같아요라는 말을 듣는 것은 흔한 일입니다. SDD가 없으면 이 상황에서 어디서부터 다시 시작해야 할지 막막합니다. SDD에서는 변경이 어떤 종류인지 판단하고 올바른 레이어부터 다시 시작합니다.

변경 종류 판단하기

변경 요청이 왔을 때 가장 먼저 할 질문은 이것입니다.

이것이 기존 Spec에 있는 내용인가, 새로운 요구사항인가?

실습 시나리오: 태그 이름에 공백 허용 요구

예를 들어 태그 기능을 만든 뒤 아래 요청이 들어왔다고 가정합니다.

태그 이름에 공백을 포함할 수 있게 해주세요. 예: 중요 업무

Step 1: 버그인가, 요구사항 변경인가?

specs/002-.../spec.md를 열어 태그 이름 규칙을 확인합니다.

이 실습에서는 기존 spec에 공백 허용 여부가 없다고 가정합니다. 따라서 이것은 버그가 아니라 요구사항 변경입니다.

Step 2: 기존 Spec 수정 -> plan, tasks 재생성

요구사항 변경이므로 기존 spec을 수정하고 하위 아티팩트를 재생성합니다. 이것이 SDD의 cascade 재실행입니다.

순서 예시:

1. spec 수정
2. clarify 필요 시 재실행
3. plan 재생성
4. tasks 재생성
5. analyze 재확인
6. implement 수정 진행

왜 바로 코드부터 고치면 안 되는가

• spec과 구현이 다시 어긋납니다.
• tasks 기준이 낡아집니다.
• 리뷰할 때 변경 이유를 추적하기 어려워집니다.

실습 포인트

• 변경이 버그인지 요구사항 변경인지 먼저 분류한다.
• 요구사항 변경이면 문서 계층부터 다시 맞춘다.
• SDD는 문서를 많이 만드는 것이 아니라 변경 시작점을 잃지 않게 해 준다.

다음 단계

마지막으로 08_recap-and-retrospective.md에서 2일간의 전체 흐름을 복기합니다.