참고로 버그를 제대로 고치면 시스템의 일부가 사라지고 더 단순해지면서 설계가 전체적으로 나아지는 때도 있다. 나중에 이에 관해 더 자세히 이야기할 기회가 있을 것이다. 일단 지금 중요한 건 이 정도다. 버그를 잘 고치면 코드 일부가 삭제되고 시스템이 단순화된다.

다시 디버깅 프로세스로 돌아와보자. 그러면 무엇을 해야 할까? 추측은 시간 낭비다. 문제의 원인을 상상하는 것도 마찬가지다. 문제를 처음 접했을 때 머릿속에 떠오르는 생각은 대체로 시간 낭비에 불과하다. 이때 해야 할 일은 다음과 같다.

 

1. 정상 시스템의 작동 방식 기억하기

2. 더 많은 데이터를 모을 수 있는 방법 알아내기

 

이를 통해 디버깅의 가장 중요한 원칙을 알 수 있다.

 

디버깅을 완료하려면 문제의 원인을 이해할 때까지 데이터를 수집해야 한다.

 

데이터를 모으는 방법은 보통 무언가를 보는 것이다. 페이지를 보여주지 못하는 웹 서버라면 로그를 보면 될 것이다. 아니면 문제를 재현해서 문제가 발생할 때 서버에서 어떤 일이 일어나는지 확인해도 된다. 그래서 사람들은 종종 ‘재현 조건(해당 문제를 재현할 수 있게 해주는 일련의 과정)’을 원한다. 버그가 발생할 때 어떤 일이 일어나는지 보기 위해서다.