git bisect로 배포 뒤 깨진 설정의 커밋을 좁힌 기록

이상한 건 기능이 아니라 환경이었다

배포 다음 날부터 일부 사용자에게만 알림 설정이 저장되지 않았다. 로컬과 스테이징에서는 재현되지 않아 설정 파일을 먼저 의심했지만, 로그를 보니 요청 자체는 정상적으로 들어오고 있었다. 커밋이 40개쯤 쌓인 상태에서 눈으로 비교하는 방식은 금방 한계가 왔다.

재현 명령을 하나로 만들 수 있다는 점이 기준이었다. 같은 입력으로 실패 여부가 분명해야 했다.

이분 탐색을 재현 명령으로 고정하기

테스트 데이터베이스를 초기화한 뒤 문제 요청을 보내는 스크립트를 만들었다.

git checkout main
./scripts/reproduce-notification-save.sh

그다음 git bisect를 시작하고 정상과 문제 커밋을 알려 줬다.

git bisect start
git bisect bad HEAD
git bisect good 3a91c2f
git bisect run ./scripts/reproduce-notification-save.sh

스크립트는 성공하면 0, 실패하면 1을 반환해야 한다. 처음에는 HTTP 200만 보고 0을 반환해서 잘못된 결과가 나왔다. 응답 JSON의 saved: true까지 확인하도록 고친 뒤에야 탐색이 안정적으로 진행됐다.

찾은 뒤에도 바로 revert하지 않은 이유

문제 커밋은 저장 로직이 아니라 알림 옵션의 기본값을 바꾼 커밋이었다. 기존 데이터에는 해당 키가 없어서, 새 코드가 undefined를 거짓으로 해석하고 있었다. 기본값을 명시하고 마이그레이션 없이 읽을 수 있게 수정했다.

다음부터는 회귀를 찾을 때 이 세 가지를 먼저 확인한다.

• 실패를 한 번의 명령으로 재현할 수 있는가
• 정상 기준 커밋을 실제로 확인했는가
• git bisect run의 종료 코드가 성공과 실패를 정확히 구분하는가

커밋 수가 많아도 재현 명령만 믿을 수 있으면 추측보다 훨씬 빨리 범위를 줄일 수 있다.