프로그래밍을 하다 보면 다양한 버그를 접하게 됩니다. 문제가 발생한 시점에 문제가 바로 터져서 디버깅이 가능한 버그는 해결이 그다지 어렵지 않습니다. 무엇 때문에 문제가 발생하는지 쉽게 알기 어려운 버그가 정말 까다로운 버그입니다.
예를 들어, 버그가 발생한 곳에서 프로그램이 뻗지 않고 문제 지점을 한참 지나쳐서 엉뚱한 곳에서 터지는 버그는 상당히 당황스럽습니다. 이럴 때엔 콜 스택이나 메모리 조사 기능 등 현 시점의 상태를 조사하는 디버거의 각종 기능이 거의 무의미합니다. 왜냐하면 그 상태에서는 문제를 이미 지나친 후이기 때문입니다. 이럴 때엔 시야를 넓혀서 프로그램의 전체적인 흐름을 파악하고 원인이 될 만한 곳을 추측해야 문제를 빨리 해결할 수 있습니다. 즉, 어떤 함수를 호출하고 나면 버그가 발생하는지 조사해야 합니다.
원인을 알 수 없는 버그를 빨리 찾는 유용한 방법으로 이분법이 있습니다. 만약 몇몇 최근 리비전에서만 버그가 발생한다면, 버그가 없다고 보고된 가장 최근 리비전과 버그가 있다고 보고된 가장 오래된 리비전 사이에서 버그가 발생한 리비전을 이분 탐색하면 어느 리비전부터 버그가 생겼는지 제일 빠르게 찾을 수 있습니다. 리비전 이분 탐색은 자주 사용되므로, 가능하면 하나의 리비전은 최소 단위로 갱신해야 문제를 나중에 쉽게 찾을 수 있습니다. 그리고 이분법은 수백 줄 이상의 코드 중에서 어느 코드가 문제를 일으키는지 도저히 알 수 없는, 악몽 같은 디버깅 상황에도 응용할 수 있습니다.
참고로, 각종 CRT 메모리 검사 함수를 이용하면 버그를 좀 더 편하게 찾을 수도 있는데, 저는 그 함수를 자주 사용해 보지 않아서 잘 모릅니다.
댓글을 달아 주세요