지난 몇 주간 갑자기 발생한 에러때문에 디버깅으로 시간을 다 보냈다. 덕분에 가끔 미투데이에 남기는 글들 외 따로 블로그에 글을 올리지도 못했다.
이번 문제는 새롭게 빌드한 바이너리1의 성능을 측정하기 위해 벤치마크 테스트를 준비하던 중 발생했다. 보통의 경우에는 미리 만들어 둔 데이타 이미지를 사용해서 성능 측정을 했었는데, 이번 바이너리의 경우에는 이미지의 포맷이 변경되는 바람에 기존 이미지를 가져다 쓰지 못하고 새롭게 만들어야 했는데, 그 과정에서 발생한 것이다.
원인을 분석하고 해결책을 찾아야 했는데, 도무지 원인을 파악할 수가 없었다. 여러 팀이 나누어 구현하고 관리하는 바이너리라 책임 소재를 찾기도 힘들었다. 게다가 디버깅용으로 같이 만들어지는 슬로우 바이너리2를 이용하여 문제를 파악하려고 했더니 슬로우 바이너리에서는 해당 문제가 발생하지 않았다. 진퇴 양난. 결국 선택한 건 지금까지 릴리즈한 바이너리들을 전부 테스트해 보고 처음 문제가 발생하는 바이너리를 찾아서 해당 릴리즈에 수정된 코드를 추가한 사람에게 책임을 묻는 방법이었다.
먼저 지금까지 테스트를 위해 사용해 왔던 테스트 데이타 이미지를 생성한 릴리즈 바이너리를 찾았다. 그 바이너리에서는 문제가 발생하지 않았으므로, 그 때를 기준으로 현재 바이너리까지 릴리즈 된 녀석들을 대상으로 바이너리 서치를 수행했다. 결론은 캘린더 위크 07~09 사이에 추가된 코드에 문제가 있을 것이라는 것.
해당 기간 동안 수정 된 코드를 Perforce3에 서브밋한 사람들을 불러 모아서 각자 자신의 수정 사항을 제거한 바이너리를 캘린더 위크 09에 릴리즈한 바이너리의 버전에 맞춰 빌드해 달라고 요청하였다. 이렇게 해서 받은 바이너리들을 테스트해서 결국 에러의 원인이 된 수정 사항을 발견할 수 있었다.
가만히 하나하나 따져가며 논리적으로 문제가 발생하는 부분을 찾아낼 수도 있겠지만, 이렇게 수정 사항들을 하나씩 되돌려보는 무식한 방법이 더 빨리 문제를 해결해 주기도 한다.


댓글을 달아 주세요
이런 버그를 하이젠버그 (Heisenbug)라고 부른다. 보통 레이싱 컨디션에서 일어나는 현상으로 디버깅을 위해 트레이싱 코드를 넣는 순간 제대로 돌아가게 된다. 트레이싱 코드로 인한 약간의 딜레이가 문제를 해소시켜버리는 것이다. 하이젠버그라는 이름은 하이젠베르그의 불확정성 이론에서 따 왔다고 한다.