버그를 보고하는 법과 버그를 고치는 법. 그리고 버그를 찾는법에 관한 짤막한 얘기
1부, 버그 보고하기.
회사에서 프로그래머로 일하는 사람이라면 대부분 다른 개발자나 QA팀으로 부터, 혹은 고객에게 버그에 대한 보고 - 특정한 형식의 보고가 아니라 버그에 대한 전달을 통틀어서 - 를 받은 적이 있을 것이다. 가장 쉽게 들을 수 있는 버그보고가 바로 이것이다.
"이거 안되요~"
대체 뭐가 안된다는 것일까? 몇가지 예를 더 들어보자
"이거 왜 클릭해도 반응이 없지?"
이 얘길 한 사람은 뭘 클릭했을까?
"자꾸 다운되요 ㅜ.ㅜ"
응 근데 난 괜찮다고? 어쩌란 말야?
버그를 보고하는 목적이 무엇인지 살펴보면, 그 버그를 고쳐줄 프로그래머에게 무엇을 얘기해야 하는지 확실히 알 수 있다. 버그가 생기면 그걸 왜 프로그래머에게 알리는가? 단지 짜증을 내려고? 짜증은 짜증을 유발해서 프로그래머 역시 버그 보고한 사람을 화풀이의 대상으로 삼게 될지 모른다. 버그를 보고 하는 이유는 다름아닌 버그를 고치기 위해서이다.
프로그래머라는 족속들이 버그를 고치기 위해서 가장 중요한 점이 있는데, 바로 버그를 재현(reproduction) 하는 것이다. 마치 형사사건을 해결하기 위해서 사건 현장을 그대로 재현해보고 추적하는 것과 비슷하다. 버그를 재현하는 것에 대한 중요성은 잠시 뒤에 다시 살펴보기로 하고, 버그를 재현하는데 필요한 것이 무엇이 있는가 부터 살펴보기로 하자.
버그를 재현하기 위해서는 충분한 정보가 필요하다. 이것을 간단히 6하원칙을 이용해서 분류할 수 있다. '언제 어디서 누가 무엇을 어떻게 왜' 물론 저것들이 다 필요한 것은 아니지만 정보는 많을 수록 좋으므로 최대한 항목을 채우는 것이 좋다.
언제라는 것은 시간에 관련 된 것인데, 타이밍이나 시간에 관련된 기능인 경우 시간정보가 주어지지 않으면 재현하기 힘든 경우가 많다. 대부분의 linux 머신들은 새벽3시~5시 정도에 cron이 돌아가는데, 이때에 부하가 증가하는 작업이 이루어지는 경우가 많다. updatedb, prelink등이 그것이다. 그런데 어떤 관리자가 서버 머신의 부하가 매일 특정시간에 증가하는 것을 보고는, "가끔 서버의 부하가 증가합니다" 라는 식의 보고를 했다가는 프로그래머가 삽질하기 딱 좋다.
만약 그 시간을 정확히 알려줬다면 조금만 상식이 있는 사람이라면 cron의 짓을 거라는 의심을 할 수 있을 것이다. - 사실 이정도는 버그보고 하기 이전에 관리자라는 인간이 제대로 처리를 했어야 할 사항이기에 적절한 예라고 보기는 어렵다.
마찬가지로 어디서는 어떤 환경에 대한 것이다. 버그가 특정 환경에서만 발생한다면 프로그래머가 자신의 환경에서 아무리 재현을 해보려 해도 발생하지 않을 것이다. 특정 환경에 대한 정확한 정보를 알려주고, 필요하면 그 환경자체를 프로그래머에게 제공하는 것이 필요할 지도 모른다 - 환경을 똑같이 재현해보는 것이 그 환경을 그대로 주는 것 보다 버그 해결의 실마리를 제공하능 경우가 많다.
누가라는 것은 사실 별로 중요하지 않은데, 왜냐하면 누가 하든지 동일한 버그가 발생해야 버그를 잡을 수 있기 때문에, 특정인을 대상으로 발생하는 버그는 사용자 불량일 확률이 대단히 높다 - 혹은 그사람은 버그를 찾아내는 귀신이다. 하지만 '누가'라는 정보는 그 사람만의 특별한 환경을 알 수 있는 단서가 될 수 있다는 점을 명심하자.
무엇을, 어떻게. 이것이 버그 해결에 가장 실마리가 되는 부분이다. 버그에 도달하기까지의 방법. 가장 좋은 표현 방법은 step-by-step 으로 표기하는 것이다. 바보라도 똑같이 따라 할 수 있도록, 타이핑 하나까지 자세히 설명하라. 이런 버그 보고를 쓸데 없이 자세하다고 신경질 내는 프로그래머는 없다. 있다면 굉장히 나쁜 놈이거나 혹은 천재일 것이다.
그리고 왜. 이것은 이 버그가 얼마나 긴급을 다투는지를 결정하는 요소가 된다. 단지 관리자가 심심해서 필요한 기능에 버그가 있는데 천만원짜리 프로젝트의
DDay를 일주일 남긴 프로그래머가 거기에 신경 써 줄 여유는 없다. 물론 이건 상황에따라서 얼마든지 달라 질 수 있는데, 공개소프트웨어 개발이라면 개발자의 의향이 우선될 것이며, SI 사업이라면 회사의 입장이 우선될 것이다.
쓸데없이 얘기가 길어졌는데, 이러한 사항을 만족하는 버그보고를 통해서 버그는 보고자(reporter) 에서 프로그래머(owner)로 넘어가게(assign) 된다. 이제 프로그래머는 이 보고를 토대로 버그를 재현해 보게 된다.
여기서 잠깐, 어째서 버그를 재현하는 것이 중요할까? 존재하지 않는 버그를 고치는 것이 불가능하기 때문이다. 고치는 사람의 입장에서, 그 버그를 눈앞에 대하기 전까지 버그는 단순히 어떤 바보가 사용자 불량으로 일으킨 사고에 지나지 않는다. 그러나 버그를 눈앞에서 보여주면 그건 남의 일이 아니라 자신이 고쳐야 할 문제로 인식할 수 있다. (혹은 다른 누군가에게 떠 넘길수도 있을 것이다, 물론 :p )
이제 버그를 눈앞에 접한 프로그래머는 자신이 버그를 제어 할 수 있기 때문에 즐겁게 버그를 수정하며 가끔은 그 버그를 보고한 사람에게 확인차 질문을 할 수도 있을 것이며, 몇분 혹은 몇일이 지난 후에는 그 버그는 SCM의 저장소에 있는 소스에는 이미 흔적도 없이 고쳐져 있을 것이다.
다시 말하지만, 버그가 얼마나 빨리 고쳐질 수 있는가는 버그를 얼마나 잘 보고하는가에 달려있다. 버그가 빨리 고쳐지기를 원한다면 늦장부리는 프로그래머를 탓하기 전에, 얼마나 제대로 버그보고를 했는가를 되돌아 보시라!
