이재원의 티스토리

문제를 진단하기 위해 코드를 고쳤을 때 아무런 효과가 없다면 원했던 부분을 고친 게 아니다. 혹시 고친 파일이 아닌 다른 파일을 컴파일 하는건 아닌지? 컴파일을 제대로 해놓곤 다른 바이너리를 실행하는건 아닌지? 고친 코드가 프리프로세서 때문에 비활성화돼 있는건 아닌지? 브라우저가 개발 서버가 아닌 제품 서버에 접속하는 건 아닌지? 이런 함정은 너무 흔하고 햇갈려서 빠지기 쉽다. 항상 마음 한구석에 함정에 대한 가능성을 염두에 두는 것 외에는 다른 방도가 없다. 함정에 빠진 것을 알 수 있는 가장 쉬운 방법은 코드에 일부러 명확한 실패 코드를 추가하는 것이다. 명백한 에러 문법을 추가하거나 System.exit() 를 호출하는 방법도 있다. 이렇게 해도 컴파일이 잘 되고 프로그램도 죽지 않고 실행된다면 내..

버그 버그는 게이머나 프로그래머들 사이에는 익숙한 용어로 프로그램 또는 시스템의 오류 또는 오작동을 의미한다. 이는 1945년 9월 9일 Mark.II 컴퓨터의 회로에 나방이 들어가 합선을 일으킨 것을 코볼의 발명자인 그레이스 호퍼가 발견한 것에서 유래됐다고 한다. 이런 버그들을 제거하는 행위를 디버깅(debuggig)이라고 부르며 디버깅을 도와주는 도구를 디버거(debugger)라고 부른다. 소프트웨어공학 관점에서 증상 및 발생원인에 따라 결함, 오류, 버그 등을 명확히 분리하기도 하지만 실제 프로그램을 작성하는 개발자 관점에서는 모든 의도하지 않은 동작을 통틀어서 버그라고 부르기도 한다. 버그와 스펙 간혹 버그 리포팅을 받아보면 버그와 스펙(요구사항명세)을 구분하지 못한 경우가 많다. 기존에 작성된 ..

문제를 재현하거나 가설을 세우기 전에 먼저 지금 어떤일이 일어나고 있는지부터 알아야 한다. 마찬가지로 현재 어떤일이 벌어져야만 하는지를 아는 것도 중요하다. 버그 리포트가 있다면 이미 원하는 정보가 거기에 있을 것이다. 하지만, 버그 리포트 역시 틀리기 쉽다는 점을 잊지 말아야 한다. 버그 리포트에 '~대신 ~이어야 합니다' 라고 돼 있다고 해서 이 말이 소프트웨어의 명세를 의미하는 것은 아니다. 스펙이 명확하지 않다면 정확하게 알기 전까지는 아무런 변경도 해서는 안된다. 정확한 스펙을 모르는 상황에서 제대로 돌아가던 것을 틀리게 수정하는 것이야 말로 최악이다. "나는 결코 추측하지 않는다. 추측은 논리력을 파괴하는 무서운 습관이다." (셜록홈즈 中)

디버깅을 정의해보라고 하면 대부분 수정해야 할 부분을 찾는 것 이라고 생각한다. 하지만 이건 디버깅의 여러 목표 중 하나일 뿐이고, 더욱이 가장 중요한 목표도 아니다. 효과적인 디버깅의 단계는 아래와 같다. 소프트웨어가 왜 이상하게 작동하는지 알아낸다. 문제를 수정한다. 다른 곳이 깨지지 않게 한다. 코드의 전반적인 품질(가독성, 구조, 테스트 커버리지, 성능 등)을 유지하거나 향상시킨다. 같은 문제가 다른 부분에는 없는지 살펴보고, 재발 방지책을 마련한다. 이 중 첫 번째 항목이 가장 중요하고, 디버깅의 시작이 되는 부분임을 잊지 말자.

코딩을 하다보면 같은 곳에 여러 버그가 발생하는 경우가 있습니다. 이 때 개발자는 문제들을 동시에 해결하고 싶은 유혹에 빠지게 됩니다. "이왕 하는김에 다 고치면 좋지 않나요?" 물론 너무너무너무 간단한 문제라던가 운 좋게 모든게 정상 동작할 수도 있습니다. (혹은 그렇게 보일수도) 하지만, 이는 매우 위험한 생각이며 시간 좀 아끼려다 야근각이 나오기 일수입니다. 어떤 버그를 잡으려고 실험하다 보면 다른 버그에 영향을 줄 수 있어 현재 정확히 어떤일이 벌어지고 있는지 알기 어려워집니다. 심지어 버그 하나에 원인이 여러개인 경우에는 스스로의 함정에 빠지기도 합니다. 개인적으로 아무리 경험이 쌓이고 능숙해져도 디버깅이란 이미 충분히 어렵고 고된 작업입니다. 쓸데없이 흙탕물을 만들지 말고 한 번에 한 문제 만..