디버깅의 예술 - 무작정 시행착오를 겪지 않는 방법

 어제 글을 포함해서 "아, 세상엔 똑똑한 사람이 정말 많고 나는 한없이 바보같구나" 하는 식의 논리에 빠져있던 것 같다. 하지만 어떻게 하면 똑똑한 사람들처럼 단계적 사고를 잘 할 수 있는지에 대한 설명은 잔뜩 쌓여있다. 내가 그런 것들을 찾아보고 시행하지 않았을 뿐이다.

---

 

 "소프트웨어 테스팅의 정석"이라는 이름으로 번역된 위 책에서는 디버깅 방식에 대해 잘 설명해놓았다. 저자인 Glenford Myers는 초기 IBM과 인텔에서 근무했고 자체 인터넷 회사를 두 차례 창업하여 상당한 돈을 번 사람이니 이런 제목으로 책을 써도 될 정도의 전문가임은 틀림없어 보인다.

 

 이 책에서 말하는 디버깅 방법은 총 세 가지이다. 1) Brute-Force 2) Induction 3) Deduction 으로 각각 방법을 살펴보고, 모두에 적용할 수 있는 간략한 디버깅 원칙에 대해서 살펴보자.

 

1.  Brute-Force

 네 자리 비밀번호 자물쇠가 주어지고, 비밀번호를 풀으라는 명령을 받게 된다면 어떻게 해야할까? 별 수 없이 0000부터 차례대로 비밀번호를 대입해봐야할 것이다. 이런 식의 차례대로 대입하는 방법을 Brute Force라고 한다. 

 

 어떤 일이 잘 진행되지 않을 때, 내가 가장 많이 의존하는 방법이기도 하다. 이 방법이 매력적인 이유는, 무엇보다도 생각할 여지가 적기 때문이다. 하지만 역시 주어진 정보를 몽땅 무시한다는 점에서 비효율적이기 짝이 없는 방법이다. 문제 해결을 운에 맡기는 것과 동일하기 때문에 나로서는 고쳐야 할 습관이다.

 

귀납 vs 연역

2. Induction

 귀납적 추론이라고 할 수 있다. 다양한 사례들을 수집한 뒤에 가설을 세우고 검증하는 절차를 밟는 것이다. 사례 수집에는 1) 어떤 부분이 잘 작동하고 있는지 2) 어떤 부분이 작동하지 않고 있는지를 확인해야 한다. 충분히 많은 데이터가 쌓이게 되면 서로 충돌하는 부분이 생기게 된다(충돌하는 부분이 없다면 제대로 정보수집을 하지 않은 것이라고 생각해도 좋다). 해당 부분을 활용해서 가설을 세우고 검증한다.

 

표를 활용한 정보 수집 방법

3. Deduction

 연역적 추론은 귀납과는 반대로 곧바로 가설 설정부터 시작한다. 그 뒤에 주어진 사례들을 바탕으로, 가설들을 솎아낸 뒤 가능성이 높은 가설들을 대상으로 검증작업에 착수하는 것이다. 웬만한 숙련자가 아니라면 곧바로 가설을 만들어내는 것은 상당히 섣부른 작업이 될 것이다. 

---

디버깅 원칙

 디버깅은 사실 두 단계로 이뤄진다. 문제의 원인을 찾고, 고치는 것이다. 그 와중에도 사실은 원인을 찾는 것에만 95% 정도의 노력이 투입된다. 디버깅 방법 중에서는 귀납적 추론을 활용하는 것이 초보자로서 적절하겠지만, 다른 방법을 사용할 때도 적용가능한 디버깅 원칙이 있다. 

 

 

 오늘만 하더라도, 지난 번에 주문했던 I2C Extender가 제대로 작동하지 않아 하루 종일 끙끙대다가 집에 돌아왔다. 말 그대로 끙끙댔을 뿐인지라 "오늘 뭐했지?" 생각해보면 딱히 할 말이 없다. 어떤 식으로 했어야했는지 좋은 사례가 될 것 같다.

 

1) 기록할 것

 생각만으로는 부족하다. 앞서 표에서도 살펴봤지만, 어떤 부분이 잘 작동하고 어떤 부분이 그렇지 않은지를 정리해둘 필요가 있다. I2C 부품을 디버깅할 때는 전혀 뭘 써놓지 않았다. 사실 납땜이 많이 필요한 작업이라 체력 소모가 컸기에, 얼른 이것저것 해보자 하는 마음으로 대충 고치려고 했다고 할 수 있다. 내일 연구실에 가게 되면 정확히 어떤 현상이 일어나는지 적어보아야겠다.

 

2) 막다른 길이라고 느껴진다면, 일단 다른 일을 해라

 사실 막다른 길이라고 느껴지지 않는 것이 문제다. 나도 "이것만 해보면 되지 않을까?" 하는 마음으로 부품을 붙잡고 있었기 때문이다. 사실 그 때가 막다른 길이다. 다음 원칙에서 알 수 있다.

 

3) 괜히 이것저것 해보지 마라

 "이것만 바꿔보고 어떻게 되나 보자!" 하는 실험적인 정신은 순전히 운에 맡기는 행동이다. 명확한 문제파악을 하지 않고 요행으로 문제해결을 한 뒤에 "이래서 문제였구나" 하는 식으로 원인을 찾는 것도 지양해야 한다. 게다가 하나하나 추가/제거를 통해 상황이 바뀌다 보면 문제의 원인이 추가되거나 금세 바뀔 수 있다. 

---

 이외에도, "에러가 하나 있으면 두 번째도 있을 가능성이 크다", "에러를 수정하기 위한 코드는 본래 코드보다 잘못되어 있을 확률이 높다" 같은 주옥같은 격언들이 수록되어 있다. 헛된 희망으로 Brute Force 방법을 시도하는 내 정신머리를 통째로 고쳐줄 수 있을 법한 말들이다. 

 

 내일은 연구실에서 괜히 또 이것저것 하지 말고, 책에서 시키는 대로 현상에 대한 명확한 고찰을 이어가봐야겠다.