버젼 관리 시스템을 사용하여 문제를 해결하기

초반에는 문제의 원인을 충분히 넓게 잡아라."에서 중요한 디버깅 기법 하나를 간단하게 언급하고 넘어갔다.

분석의 과정이 없이 추론에 근거하여 새로 추가된 원격 기능과 캐싱 알고리즘만을 의심했다.
코드를 수정해도 상태가 개선되지 않았다.
... 중략 ...
이전 버젼과 차이점을 면밀하게 비교하면서 비로서 문제의 원인을 발견했다.
같은 환경과 같은 기능(즉, 로컬 파일 읽기)에서도 새 버젼에서 동일한 문제가 일어났다.
즉, 새로운 기능이 동작할 때 발생하는 것이 아니란 의미이다.
로깅 시스템을 리펙토링을 했는데, 이와 연관이 깊을 것으로 추정했고 다양한 테스트로 이를 검증했다.

- 2014/07/15 - [Practice/Debugging] - 초반에는 문제의 원인을 충분히 넓게 잡아라.

버젼 콘트롤 시스템(VCS)^[각주:1]를 잘 활용하는 기법을 말하지 않았다.
가장 기본은 문제가 처음 발생된 변경 이력을 찾는 것이다.

버젼 별로 문제 상황을 재현하면서 범위를 좁혀나간다.
이진 탐색의 기법이 유용하다.
버젼 15에서는 괜찮았고 23에서 문제를 재현했다면, 적절한 중간값에서 확인해본다.
재현이 되면 15와 방금 재현된 버젼의 중간값을,
아니면 나머지 반의 중간값을 고른다.
이와 같은 과정을 반복하여 문제가 최초로 발생하는 버젼을 찾는다.
이전 버젼과 차이점을 분석하면 원인을 찾을 수 있다.

문제가 되는 버젼의 범위를 대강 파악할 수 있다면 시간을 많이 단축할 수 있다.
문제를 둘러싼 환경(적용 시기나 장비 등)을 잘 분석하면 많은 도움이 된다.
버그가 발생하기 시작한 시기를 조사하면, 문제의 코드(또는 환경 변화)가 발생한 때는 대략 파악할 수 있다.
장비에 설치된 버젼이 다르고 장비마다 오류 상황이 다르다면 문제가 되는 구간이 많이 좁혀진다.

커밋 로그를 잘 작성했다면 이를 최대한 활용한다.
문제가 될만한 변경 이력을 참고하면 원인을 빨리 추측할 수 있다.
원인으로 지목된 커밋 로그의 앞/뒤 버젼에서 문제가 재현되는지 확인한다.^[각주:2]

1. SCM(Source Code Management)이라고도 불린다. [본문으로]
2. "현상을 분석하여 문제의 원인을 찾아내라"에서 언급했듯이 문제를 재현하여 원인을 확실하게 증명해야 한다. [본문으로]