전 개발할 때 디버거를 자주 사용하지 않는 편입니다. C/C++, 자바, 파이썬, 하스켈 등 개발 언어를 가리지 않고 디버거는 거의 사용하지 않습니다. 물론 디버거를 안 사용하는 게 무슨 개발 철학 같은 건 아닙니다. 직관적으로 디버거를 사용하는 편이 좋겠다는 생각이 들 때도 있고 프로그램이 C 코드 안에서 죽을 때는 디버거를 실행시켜서 메모리와 변수 값을 보기도 합니다.

하지만 디버거로 절대 잡기 힘든 멀티쓰레드 버그가 난무하고 메모리 보호도 없는 임베디드 시스템 개발로 개발을 시작하다보니 버그가 생겨도 디버거를 써야지라는 생각을 잘 안 하게 된 것 같습니다. 대신 저는 디버깅에 크게 2가지 방법을 사용합니다. (다른 개발자도 마찬가지겠지만요)

1) 콘솔 출력

언어마다 다르지만 결국 중요한 지점 몇 군데가 변수 값을 찍어보는 걸로 디버깅이 시작됩니다. printf, System.out.println, print가 디버깅 도구인 셈이죠. 간단한 버그들은 보통 원인이 짐작이 되기 때문에 중요 변수를 콘솔로 몇 번 출력해 보면 문제가 파악됩니다.


2) 코드 검토

멀티쓰레드 버그에 대해서는 가장 강력한 디버깅 방법이 머리 속으로 시뮬레이션하는 것입니다. 증상을 놓고 왜 이런 문제가 생겼을지 의심가는 여러 쓰레드를 놓고 생각해 보는 것이죠. 하루종일 책상에 앉아서 왜 이런 현상이 생길지 생각만 하다가 집에 간 날도 있습니다.


버그를 찾아내면 기쁘긴 하지만 디버깅 자체는 괴롭습니다. 처음부터 버그를 안 만드는 게 최선이겠죠.  하지만 나름대로 열심히 짠다고 해도 버그 없는 프로그램을 만들기란 너무 힘듭니다. 코드를 작성했는데 한 번에 컴파일되고 돌아가면 스스로 의심합니다. "그럴리가 없는데." 어릴 때는 그래도 머리가 잘 돌아가서 가끔 실행은 제대로 안 되더라도 컴파일 에러 없는 코드 정도는 만들어내곤 했는데 요즘은 그나마도 힘들어 그냥 포기하고 무슨 마약처럼 컴파일러에 의존(주기적으로 컴파일을 해보지 않으면 불안함)해 살고 있습니다.

버그는 사람이 만들지만 버그를 유도하는 것은 개발 환경입니다. 특히 프로그래밍 언어는 개발자가 얼마나 많은 버그를 만드는지를 결정하는 중요한 요소입니다. 함수 언어를 사용하면서 느낀 점 중에 하나는 적당히 컴파일되게만 짜면 다른 언어에 비해 버그가 현저히 적다는 사실입니다. 물론 강력한 정적 타입 시스템에 도움이 큰 셈이죠. 여기에 덧붙여 버그를 줄이는 프로그래밍 언어의 특징으로는 변조불가능(Immutability), 순수(Purity), 참조 투명성(Referential Transparency) 등이 있습니다. 세 가지 단어는 서로 다 관련이 있습니다.

하스켈을 비롯한 함수 언어 개발자들이 다른 개발자들과 차이를 보이는 점 중에 하나가 디버거를 거의 사용하지 않는다는 사실입니다. 물론 GHCi에 보면 디버거가 없는 건 아닙니다. 앞서 언급한 언어적 특성 때문에 하스켈 디버깅은 디버거를 통해 변수에 잘못된 값이 들어가 있는지 확인하는 일이 필요가 없습니다. (사실 변수라고 부를만한 것도 별로 없습니다.) 그저 함수 명세에 맞춰서 코드가 제대로 작성되었는지 테스트 값 몇 개만 넣어보면 됩니다.

특히 하스켈의 중요 특징의 하나인 참조 투명성은 테스트 혹은 디버깅에서 강력한 힘을 발휘합니다. 참조 투명성이란 하스켈의 함수가 수학적인 함수와 동일하게 같은 입력(인자)에 대해서는 언제나 같은 값을 리턴함을 의미합니다. 하스켈의 순수 함수는 전역 변수를 참조하거나 IO에 영향을 받지 않기 때문에 테스트나 디버깅을 위해 가짜 오브젝트(Mock Object) 등을 만들어내는 수고를 할 필요가 없습니다. 그저 함수의 명세(specification)만 테스트하면 됩니다. 이런 특성 때문에 하스켈의 테스트프레임워크 중 하나인 QuickCheck은 명세 기반 테스트라는 용어를 사용하고 있습니다.

나는 연장질을 잘 못한다고 생각하기 보다는 내 연장이 나쁜게 아닐까라는 생각의 전환이 필요합니다.