![](http://photos1.blogger.com/blogger/3619/2095/320/whyprogramsfail.png)
jrogue군이 연속으로 리눅스 디버깅과 성능 튜닝에 이어 리눅스 문제 분석과 해결을 번역한 이유는 얼마나 디버깅이 개발자를 괴롭히는지 익히 알고 있기 때문이었다. 참새가 방앗간을 그냥 지나갈 수 없듯이 "Why Program Fails: A Guide to Systematic Debugging"이라는 제목이 붙은 이 책을 안 읽고 넘어갈 수 없었다. 인천에서 프랑크푸르트를 왔다갔다 하면서 틈틈히 읽었고, 귀국해서 며칠 집중 투자를 해서 수식이 가득한 부록만 가뿐하게 제껴주고 남은 부분은 모두 읽었다.
이 책은 프로그램에서 발생하는 문제점을 체계적으로 따져서 위치를 발견하고 원인을 찾아 해결하는 방법을 다룬다. 목차를 잠깐 정리해보자면 문제 추적, 프로그램을 죽게(?) 만들기, 문제 재현, 문제 단순화, 과학적인 디버깅, 오류 추론, 사실 관찰, 근원 추적, 기대 가정, 원인과 결과, 오류 원인 격리, 원인-결과 연쇄 격리, 결함 수정에 이르기까지 폭넓은 주제를 다룬다. 특히 수학적인 이론을 바탕으로 만든 델타 디버깅과 그래프 추적 방식은 무척 참신한 접근 방법이라고 생각한다. 또한
gdb의 그래픽 프론트엔드인 DDD를 만든 사람 답게 저자는 여러 가지 디버깅 도구를 활용하는 방법 역시 본문 여러 곳에서 다루고 있다(물론 jrogue군이 번역한 책을 읽은 독자라면 데자뷰가 느껴지겠지만... :P).
하지만 동전에 앞 뒷면이 있듯이 이 책을 읽고나서 2% 부족하다는 느낌이 들었다. 실제로 문제 원인을 추적하는 과정에서 이 책에 나온 내용만으로 모든 경우를 따지기 어려울 뿐더러 개발자는 디버깅을 하면서 전문 분야에 얽히고 ?힌 다양한 지식을 활용하는 방법을 사용하기 때문에 아무리 '디버깅' 자체를 과학적으로 정의한 다음 이를 따르려고 해도 빈틈이 생기기 마련이다. 이 책에 나오는 코드 예제는 너무 쉽기 때문에(설명을 위해 어쩔 수 없었으리라는 생각이 든다) 실제로 여러분이 현장에서 부딪히는 문제로 scale up을 하기에는 역부족이라는 문제도 있다. 설상가상으로 소프트웨어-하드웨어-운영체제 등이 이리저리 꼬인 상황에서는 _행운_이라는 요소도 개입하므로 체계적으로 접근하더라도 잘 안되는 경우도 생긴다는 점을 고려해볼 때 역시 이론과 현실은 다른 모양이다. T_T
"디버깅"에 상당히 관심이 많고 평상시에 프로그램 디버깅 과정에서 이런저런 고민을 많이 한 개발자라면 이 책을 읽고 건질 내용이 있겠지만, 만병통치약을 바라고 이 책을 드는 순간 입맛만 버릴 가능성이 높기 때문에 이 책에 대한 너무 과도한 기대는 금물이라는 사실을 미리 밝혀둔다.
EOB
댓글 없음:
댓글 쓰기