개념
왜 재현이 안 되는가
한 번 목격했는데 다시 시도해도 똑같이 안 생기는 버그는 실무에서 매우 흔하다. 원인은 대체로 다음 중 하나다.
- 레슨 5에서 배운 숨은 변수가 그때만 특정 값이었다 (예: 그 순간만 네트워크가 느렸다)
- 동시성 문제(race condition): 아주 좁은 타이밍에만 발생한다
- 이전 세션에서 남은 상태가 우연히 이번 세션에 영향을 줬다 (캐시, 이전에 열어둔 탭 등)
- 외부 서비스의 일시적 장애
절대 무시하면 안 되는 이유
"어? 이상하네, 다시 해보니 안 되네"라며 넘어가고 싶은 유혹이 크다. 하지만 재현이 안 된다는 것이 결함이 없었다는 뜻은 아니다. 오히려 가장 심각한 실무 버그(동시성 문제, 메모리 누수, 경합 조건)일수록 재현이 어렵다 — 조건이 좁고 우연히 맞아떨어져야 하기 때문이다.
목격한 순간, 무엇을 해야 하는가
- 즉시 멈추고 증거부터 남긴다. 스크린샷, 콘솔 로그(레슨 4), 네트워크 로그, 정확한 시각을 캡처한다. 다음 행동을 하기 전에 먼저 증거부터다.
- 그 순간까지의 전체 맥락을 최대한 복원한다. 방금 한 행동뿐 아니라, 이 세션에서 그 전에 했던 모든 행동, 열려 있던 탭, 걸린 시간을 되짚어본다 — 숨은 변수(레슨 5)를 찾는 것과 같은 작업이다.
- "재현 안 됨"을 숨기지 않고 정직하게 보고한다. 결함 리포트에 "1회 목격, 재현 조건 불명, 증거 첨부"라고 명확히 적는다. 확신에 찬 것처럼 과장하지도, 무시하지도 않는다.
- 비슷한 보고가 또 있는지 찾아본다. 한 번은 우연일 수 있지만, 비슷한 재현 불가 보고가 여러 번 쌓이면 패턴이 보이기 시작한다 — 이건 모듈 6(결함 관리)에서 다룰 결함 이력 관리와 연결된다.
실무에서 왜 필요한가
팀은 재현이 안 되는 버그 리포트를 "사용자 실수"나 "일시적 착오"로 치부하고 덮어버리기 쉽다. 이게 실제로는 조용히 방치된 동시성 버그가 프로덕션에서 계속 사용자에게 영향을 주는 상황으로 이어질 수 있다. 목격 즉시 증거를 남기는 습관이 있는 QA는, 나중에 비슷한 보고가 쌓였을 때 팀이 그 패턴을 실제로 찾아낼 수 있는 기반을 만든다. "어차피 재현 안 되니까 소용없다"는 태도가 가장 위험하다.
실습 과제
과제 1 — 즉시 대응 목록 만들기 (10분)
탐험 중 화면이 갑자기 하얗게 변하며 멈추는 걸 한 번 목격했다고 하자. 다시 시도해도 재현되지 않는다. 이 순간부터 2분 안에 무엇을 하고, 무엇을 기록할지 순서대로 적는다.
과제 2 — 정직한 결함 리포트 쓰기 (10분)
과제 1의 상황에 대해 결함 리포트 제목과 본문을 작성한다. 확신을 과장하지 않으면서도, 팀이 참고할 수 있는 유용한 정보를 담는다.
자가 체크리스트
- 재현 불가능한 버그가 왜 생기는지 최소 세 가지 원인을 설명할 수 있다
- "재현 안 됨"이 "결함 없음"이 아닌 이유를 설명할 수 있다
- 버그를 목격한 순간 무엇을, 어떤 순서로 해야 하는지 안다
- 재현 불가 버그를 정직하고 유용하게 보고하는 법을 안다
흔한 실수
- "다시 해보니 안 되네요"라며 그냥 넘어간다. 증거를 남기지 않으면 그 버그는 영원히 사라진 정보가 된다.
- 재현이 안 됐는데 확신에 찬 어조로 보고한다. 반대로 너무 자신 없어 보고 자체를 포기하는 것도 문제다 — 불확실성을 있는 그대로 전달하는 게 맞다.
- 비슷한 보고가 쌓이고 있는지 확인하지 않는다. 과거 결함 이력을 검색해보는 습관이 있으면, "어, 이거 전에도 누가 비슷한 걸 봤었네"를 발견할 수 있다.
참고 자료
- Elisabeth Hendrickson, Explore It! — 재현 불가능한 버그를 다루는 실무적 조언을 담은 장
- Cem Kaner, "The Ongoing Revolution in Software Testing" — 간헐적 결함(intermittent bugs)의 실무적 중요성을 다룬 자료