이재원의 티스토리

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

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

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

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