제가 없는 시간을 쪼개서 즐겨 보는 미국 드라마 중에 하나는 <하우스>입니다. 하우스는 일반적인 의학 드라마와 다르게 의사들 간의 사랑도 없고 병원에서 일어나는 아름다운 휴머니티도 존재하지 않습니다. 다만 원인 모를 병에 걸린 사람이 한 명 실려오는 걸로 시작해서 그 사람이 무슨 병에 걸렸는지를 추적해 나가는 추리물에 가깝습니다.

극중 하우스가 종사하는 분야가 바로 진단 의학입니다. 도저히 원인을 알 수 없는 병에 걸린 환자의 증상을 보고 어떤 병인지를 추측하는데 보통 수 십 혹은 수 백 개의 병명을 떠올립니다. 예를 들어 피를 토하고 열이 높다고 했을 때 말할 수 있는 병은 1-2개가 아니거든요. 진단 의학은 기본적으로 증상을 통해 병명을 나열하고 검사를 통해 리스트를 지워 나가는 방법이 기본입니다.

하우스를 보면서 재미있다고 생각한 것은 소프트웨어 개발자가 디버깅을 하면서 문제를 해결하는 방식과 놀랍도록 똑같기 때문입니다. 시나리오는 보통 다음과 같습니다.

원인을 알 수 없는 버그로 프로그램이 죽거나 이상 동작한다며 버그(환자)가 실려 옵니다. 개발자들은 증상을 보고 가능한 원인(병명)을 리스트합니다. 디버거를 붙이고 코드에 디버깅 메시지를 박아서(MRI, CT 촬영 등) 몇 가지 대안은 원인이 아니라는 사실을 알고 리스트를 지워나갑니다. 지우고 지우다 보니 결국 한 군데 밖에 원인이 안 남은 경우 문제를 해결하게 됩니다.

진단 의학은 기본적으로 경험이 매우 중요한 분야입니다. 기본 소양으로 폭넓은 지식이 기본으로 요구되지만 단순한 지식은 나열은 검사할 수 없는 엄청나게 많은 가능성만을 제시하게 됩니다. 여기서 아닐만한 병명을 빠르게 제거하는 과정이 바로 묘미입니다. 하우스가 제일 잘하는 부분인데, 하우스 부하 의사들이 여러 병명을 말하면 "이런 저런 이유 때문에 절대 아니다"라고 재빨리 말할 수 있는 것이죠.

디버깅의 기술도 유사합니다. 가능성은 많은데, 절대 아닐 만한 리스트를 재빨리 제거할 수 있는 능력은 소프트웨어 개발과 디버깅에 대한 오랜 경험을 요구합니다. 또한 개발 능력과는 조금 다른 순발력을 필요로 하기도 합니다. 소프트웨어 개발 방법론에 관한 책은 많이 있어도 디버깅 방법론에 대해서는 체계화된 방법론이 없는 것도 이런 순발력을 훈련시키거나 일반화하는 방법을 아직 발견하지 못했기 때문입니다.

그래도 소프트웨어 개발자가 하우스에게 배워야 할 점이 하나 있습니다. 병명을 맞추기 전에는 반드시 그 병이 환자의 현재 증상을 초래한 과정을 논리적으로 자세히 설명한다는 것이지요. 소프트웨어 개발자도 버그를 해결하기 전에는 반드시 어떤 과정을 거쳐서 그런 버그가 발생한 것인지를 논리적으로 설명할 수 있어야 합니다. 버그가 일어난 시나리오를 정확히 말할 수 없다면 그 버그를 제대로 알고 있지 못한 것이라고 봐야 합니다.

특히 레이스 컨디션이나 멀티 쓰레드 관련 버그의 경우 완벽한 시나리오 없이 코드를 이래 저래 뜯어 고치다 보면 버그가 사라지는 경우가 있는데, 이렇게 고친 버그는 주기적으로 다시 출몰해서 개발자를 괴롭히는 근원입니다. 여러 가지 검사(메모리 덤프, 디버깅 메시지) 등으로 시나리오를 찾아낸 후에야 버그를 잡을 수 있는 것이죠.

결론은? 소프트웨어 개발자 여러분, 하우스를 봅시다.