현상을 분석하여 문제의 원인을 찾아내라

현상을 재현하고 로그를 세심하게 살펴보고 필요하면 다른 도구(디버거, 성능 분석 도구 등)를 사용해서 분석한 후에 문제의 원인을 밝혀야 한다. 대충 추론하고 수정하여 적용한 뒤에 결과를 보는 방법은 생각보다 효과적이지 못하다.

소스를 공개하지 않은 상용 소프트웨어의 파일 읽기 플러그인을 개발하였다. 지금까지 탈없이 잘 쓰고 있었는데, 최근에 시스템에 문제가 생기면 플러그인과 상관없는 부분에서 행(hang)이 걸리는 문제가 발생하었다.

처음에는 문제의 원인을 추측하고 수정하고 검증하는 것을 반복하는 방법으로 접근하였다. 문제는 직감에 기반한 추론은 확율이 떨어졌다. 검증할때마다 여전히 문제가 발생하여, 수정과 검증의 과정을 여러번 반복해야 했다. 검증 과정을 준비하고 결과를 분석하는데도 상당한 시간이 들었기 때문에 한번의 실패할 때마다 보통 하루씩 시간을 잡아먹었다. 이렇게  문제는 해결되지 않고 시간만 흘러갔다.

오랜 삽질 끝에 방법을 바꿔보기로 마음을 먹었다. 내가 개발한 파일 읽기 플러그을 이용하여 이 소프트웨어의 I/O 동작 방식을 분석해보았다. 분석을 마치고 보니 이 제품의 I/O의 설계가 생각보다 엉성하였다. 다른 제품의 일반적인 I/O 작동 방식과 꽤 동떨어진 구조였다. 왜 이전의 추론들이 틀렸는지는 알 수 있었다. 이제 시스템의 문제가 어떻게 해서 이 제품의 문제까지 이르게 하는지 그 과정이 서서히 눈에 들어오기 시작했다.

이번 경험으로 문제를 해결하려면 문제의 원인과 발생하는 과정을 데이타를 기반하여 면밀히 분석해야 한다는 교훈을 얻었다. 문제의 분석은 직감에만 의존하기 보다는 실험과 결과로 나온 데이타를 토대로 접근해야한다. 빨리 결과를 보려고 조급하게 반복 시도할 것이 아니라 문제를 재현하면서 필요한 데이타를 충분히 모아야 한다. 문제에 대한 이해가 높아질 수도록 해결의 가능성이 높아지고 더불어 근본적인 대처도 가능해진다.