Career Skills_P3 - Ch32. 디버깅

소프트웨어 개발자가 되면 코드 디버깅에 아주 많은 시간을 들이게 될 것이다. 다행히 디버깅하는 기술도 다른 기술처럼 배우면 는다. 디버깅에 접근하는 태도가 무엇보다 중요하다는 걸 깨달아야 한다.

 

 

| 디버깅이란 무엇인가? |

디버깅이란 코드 베이스에서 문제의 근원을 찾아서 그 문제를 일으킬 요인을 가려내고, 여러 가설을 시험해보는 과정을 토해 뿌리가 되는 진정한 원인을 찾고 그 원인을 제거한 후, 다시는 그 문제가 일어나지 않도록 하는 것이다.

 

 

| 디버깅 첫 번째 규칙 : 디버거를 쓰지 마라 |

코드를 디버그할 문제가 생기면 프로그래머들은 늘 쓰는 디버거를 켜고 버그를 찾는데 돌입한다. 틀렸다. 디거거는 최후의 수단으로 남겨둬야 한다.(즉 디버거는 훌륭하고 강력한 도구지만 디버거부터 켜지 말라는 의미다. 디버거에 손도 대기 전에 해결할 수 있는 버그가 많기 때문이다.)

 

 

| 에러를 재현하라 |

분별 있는 사람이라면 디버깅을 시작하기 전에 버그를 재현해서 진짜 버그가 발생한 게 맞는지 확인부터 한다. 100% 재현할 수 없는 없는 문제는 디버깅할 수 없기 때문에 디버깅의 의미가 없다. 재현할 수 없다면 다른 이에게 도움을 청하라. 테스터가 보고한 버그라면 테스터가 직접 재현하게 하라. 버그가 간헐적으로 발생해서 확실하게 재현하는 게 불가능할 때는 재현에 필요한 환경이 무엇인지 모른다는 뜻이다. 

 

 

| 앉아서 생각하라 |

문제를 재현한 다음 단계는 대부분의 소프트웨어 개발자가 빨리 문제를 해결하고 싶은 마음에 건너뛰는 단계다. 하지만 이 단계가 없으면 안된다. 어디를 살펴보고 무엇을 찾을지부터 아는 게 중요하다. 정말 아무것도 생각도 나지 않아서 디버거를 켜고 싶은 충동을 느낀다면 그 대신 소스 코드를 훑어보라. 시스템이 원래 어떻게 작동했어야 할지 단서를 조금 더 모아보라. 다음 단계로 가기 전에 적어도 2~3가지 쓸 만한 가설은 생각해내야 한다. 

 

| 가설을 테스트하라 |

자신이 세운 가설을 테스트할 단위 테스트를 작성하라. 단위 테스트를 작성하고 하났힉 통과할 때마다 가능성을 제거하는 것이다. 가설을 계속 다시 확인하다고 느끼거나 하여 잘못된 경로를 계속해서 다시 방문하게 하는 게 디버거의 아주 큰 단점이다. 

가설을 테스트하기 위해 단위 테스트를 쓰는 게 아주 어렵거나 불가능할 때도 있다. 그럴 때는 디버거를 써도 좋다. 단, 한 가지 규칙을 지켜야 한다. 디버거를 쓰는 목적을 분명히 하라.

 

 

| 가정을 확인하라 |

사람의 코드가 특정한 방식으로 작동한다거나 입력 또는 출력으로 어떤 값이 나와야 한다고 가정하는 경향이 있다. 그 가정과 틀린 결과가 나온다면 가정을 확인해라.  가정을 확인하는 가장 좋은 방법도 역시 단위 테스트다.

디버거 사용은 최소롤 줄여라. 꼭 써야 한다면 이미 세운 특정한 가정이 유효한지 확인하는 용도로만 활용하라.

 

 

| 분할 정복하라 |

디버깅이 잘 안 풀릴 때, 때로는 문제를 반으로 자를 방법을 찾아보는 것도 좋다. 아니면 최대한 큰 덩어리를 떼어내는 것도 좋다. 상황에 따라 매우 다른 양상을 띨 수도 있다. 하지만 코드, 시스템, 변수를 최대한 제거한 후 그래도 버그가 재현되는지 확인하라. 시스템에서 에러를 일으키는 부분을 완전히 제거하는 테스트를 만들 수 있을지 생각해보라. 그리고, 하고 또 하는 것이다. 그렇게 하다보면 에러를 발생시키는 핵심적 컴포넌트를 찾아낼 확률이 높다. 그러면 문제 해결이 상대적으로 쉬워진다.

 

 

| 고칠 때는 이유를 이해하라 |

저자의 조언은 다음과 같다.

"문제를 고칠 때는 자신이 한 행위가 어떻게 그 문제를 고쳤는지 이해해야 한다."

그 문제가 왜 고쳐졌는지 이해하지 못하면 아직 문제를 다 고친 게 아니다. 문제가 저절로 사라지는 일은 없다. 반대로 문제를 고쳤다면 거기서 멈추지 말고 조금 더 나아가라. 애초에 문제를 일으킨 원인이 정확히 무엇이었는지, 어떻게 고친 것인지 제대로 이해해라.

마구잡이로 시스템을 수정하고 코드 여기저기를 대충 손보다가는 부지불식간에 온갖 문제를 일으킬 수 있다. 무엇이 망가졌고 왜 어떻게 고쳤는지 이해해야 할 뿐 아니라 고쳤다는 걸 확인하는 절차도 반드시 거쳐야 한다. 사실 고쳐졌는지만 확인하지 말고 회귀 테스트를 작성해서 그런 일이 다시 발생하지 않게 하는 게 좋다. 마지막으로 버그가 발생한 클래스의 다른 인스턴스를 살펴보라. 버그는 서로 붙어 다니는 경향이 있다. 시스템이나 부정확한 코드가 들어 있는 컴포넌트에 대한 가정에서 문제를 발견했다면 그 문제가 일으킨 다른 문제도 숨어 있을 확률이 매우 높다. 진짜 문제가 무엇인지 자신이 만든 해결책으로 그 문제가 해결된 이유가 무엇인지 이해하는 것이 그토록 중요한 이유가 여기에 있다. 무슨 일이 왜 일어났는지 안다면 동일한 기저의 문제 때문에 일어난 다른 문제도 쉽게 해결할 수 있을 것이다.

 

 

| 예술과 과학 |

소프트웨어 개발이 그렇듯이 디버깅도 예술과 과학의 영역에 속하는 활동이다. 디버깅을 잘하려면 연습해야 한다. 연습만으로는 부족하다. 디버거를 가지고 노는 데 그치지 마라. 구체적이고 체계적인 방법으로 디버깅해야 한다. 이 장을 통해 그렇게 할 수 있는 방법을 잘 배웠기를 바란다. 이제 나머지는 당신 몫이다.