버그를 고치기 전에 재현 조건부터 적는다

버그를 발견하면 본능적으로 바로 코드부터 열게 된다. 그런데 그렇게 하면 고친 것 같은데 증상이 그대로거나, 다른 조건에서는 다시 나오는 상황이 반복된다. 이유는 단순하다 — 무엇을 고쳐야 하는지 제대로 정의하지 않은 채로 고치려 했기 때문이다.

그래서 요즘은 버그를 잡기 전에 반드시 재현 조건을 먼저 적는다.

재현 조건이란 무엇인가

재현 조건은 거창한 게 아니다. 이 세 가지면 충분하다.

• 어떤 상태에서 문제가 생기는가 (URL, 사용자, 환경)
• 어떤 동작을 했을 때 나타나는가
• 무엇이 예상과 다른가 (화면, 로그, 응답 코드)

예를 들어 로그인 후 새로고침하면 세션이 끊기는 버그라면 이렇게 쓴다.

재현: 로그인 → 페이지 새로고침
예상: 로그인 상태 유지
실제: 로그인 화면으로 리다이렉트
확인: Network 탭 → /api/me 요청 → 401

한 줄이어도 괜찮다. 중요한 건 "증상"을 눈으로 보이는 값으로 표현하는 것이다.

재현 조건을 먼저 쓰면 달라지는 것

재현 조건이 있으면 디버깅의 시작점이 명확해진다. "왠지 쿠키 문제 같은데"가 아니라 "401이 반환된다, 그러면 서버가 세션을 못 읽고 있다"로 바뀐다.

또 하나. 수정 후에 재현 조건을 다시 돌려보면 고쳐졌는지 확인이 된다. "왠지 되는 것 같다"가 아니라 "같은 조건에서 더 이상 401이 안 난다"로 끝낼 수 있다.

코드 수정 전 체크

빌드 결과나 응답 코드 같은 구체적인 값 하나를 먼저 기록해두자.

npm run build
# 빌드 성공 여부와 에러 메시지 전체를 복사해둔다

수정 전후의 값이 달라야 수정이 유효하다는 걸 증명할 수 있다. 그 값이 없으면 "된 것 같다"는 느낌으로 끝내게 된다.

짧게라도 남겨두면 쌓인다

노션이든 로컬 파일이든 상관없다. 재현 조건, 확인한 값, 수정 내용을 세 줄만 써도 다음에 비슷한 버그가 왔을 때 그 기록이 기준점이 된다. 한 번에 여러 곳을 동시에 수정하지 않는 것과 함께, 이 습관 하나가 디버깅 시간을 가장 많이 줄여줬다.