Practice/Debugging

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

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


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

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

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

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

저작자 표시 변경 금지
신고
크리에이티브 커먼즈 라이선스
Creative Commons License
  1. Favicon of http://unipro.tistory.com unipro M/D Reply

    우선 버그가 등장한 상황을 이해하기 위해서 필요한 자료를 모은다. 로그 파일, 사용자 설명, 시간, 이벤트, 쓰레드 덤프, 메모리 사용량, 시각적 그래프 등을 남김없이 모아서 다른 개발자와 실시간으로 공유한다.

    추측이나 상상이 아닌 정확한 논리에 근거해서 다음 단계를 설정하고, 검증한 길은 목록에서 하나씩 제거해 나간다.

    출처: http://www.zdnet.co.kr/column/column_view.asp?artice_id=20170131085723&lo=z46

알림

이 블로그는 구글에서 제공한 크롬에 최적화 되어있고, 네이버에서 제공한 나눔글꼴이 적용되어 있습니다.

카운터

Today : 13
Yesterday : 124
Total : 164,163

티스토리 툴바