d02/05. bugfix-workshop.md

2일차 실습 5: 버그 수정 워크숍

버그 수정은 기능 추가와 다릅니다

예시 이슈 #3은 버그입니다. 마감일 없는 항목을 마감일 순으로 정렬할 때 오류가 발생한다는 문제라고 가정합니다. 이것은 새로운 기능이 아닙니다. 기존 spec에 이미 정렬 관련 약속이 있었는데 코드가 그것을 지키지 못한 것입니다.

핵심 판단 기준:

• 기존 spec에 약속이 있으면 버그
• 기존 spec에 없는 새 요구면 기능 추가

왜 /speckit.specify를 쓰지 않는가

버그 수정은 새 기능 spec을 만드는 일이 아닙니다. 따라서 /speckit.specify 없이 fix/ 브랜치에서 직접 수정합니다.

Step 1: 버그용 fix/ 브랜치 생성

버그 수정은 브랜치를 직접 만듭니다. 변경 범위를 좁게 유지해야 합니다.

작업 전 확인 명령:

git branch
git status
git checkout main
git branch
git checkout -b fix/issue-3-sort
git branch
git status

브랜치 확인을 여러 번 넣는 이유는 단순합니다. bugfix는 기존 feature 브랜치 위에서 이어서 만들면 안 되고, main에서 새 fix/ 브랜치를 분기해야 하기 때문입니다.

Step 2: 버그를 재현하는 테스트 먼저 작성

constitution의 TDD 원칙에 따라 버그를 재현하는 테스트를 먼저 작성합니다. 테스트가 실패하면 버그가 재현된 것입니다. 그 후 코드를 수정하여 테스트가 통과하게 만듭니다.

중요한 이유:

• 수정 전 실제 문제를 잡아둘 수 있습니다.
• 수정 후 같은 문제가 다시 생겼을 때 회귀 테스트가 됩니다.
• AI가 엉뚱한 범위를 고치는 것을 막을 수 있습니다.

Step 3: AI에게 버그 수정 요청

테스트와 실패 결과를 기준으로 최대한 좁은 범위의 수정을 요청합니다.

Step 4: 수정 후 테스트 확인

• 재현 테스트가 통과하는지 확인합니다.
• 관련 회귀 테스트도 함께 확인합니다.

Step 5: 버그 수정 커밋

버그 수정은 기능 추가와 분리해서 별도 커밋으로 남깁니다.

실습 포인트

• 버그와 기능 추가를 섞지 않는다.
• fix 브랜치는 좁고 짧게 유지한다.
• 수정 전, 분기 직후, 커밋 전마다 현재 브랜치를 확인한다.
• 재현 테스트 없이 바로 수정하지 않는다.

다음 단계

기능 브랜치와 버그 수정 브랜치가 모두 준비되면 06_merge-review-workshop.md에서 merge 전 검토를 진행합니다.