뽀빠이 아저씨의 말씀 뿌뿌 ==3

IBM DeveloperWorks 에 기고한 허접한 글입니다.

http://www.ibm.com/developerworks/kr/library/dwclm/20090512/index.html

퇴고를 별루 못해서 그냥 막 이야기하듯 나열한거 같아 개인적으로는 아쉽습니다.

---

프로그래머라면 누구나 다른 사람이 작성한 ‘나쁜’ 버그 리포트를 받아보았을 것이다. 아무 내용도 없는 것, 예를 들면 그냥 "안 돼요" 같은 것이 이런 유형의 버그 리포트일 것이다. 이런 리포트는 이치에도 맞지 않을 뿐만 아니라 충분한 정보를 제공하지 않거나 아예 잘못된 정보를 제공하는 것이나 다름없다. 또는 다른 프로그램이나 네트워크 등의 오류처럼 사용자 과실로 밝혀지는 문제를 리포트하는 것도 이와 비슷한 부류일 것이다. 기술 지원 부서 일이 끔찍해 보이는 이유 중 하나는 바로 이러한 버그 리포트 덕분이다.
이 글에서는 ‘좋은’ 버그 리포트에는 어떤 내용이 필요한지에 대해 말해보고자 한다. 세상 모든 사람이 이 글을 읽어봤으면 좋겠지만, 적어도 내게 버그 리포트 보내는 사람은 꼭 읽어줬으면 좋겠다.

버그 리포트의 목적은 간단히 말해 프로그래머가 프로그램의 오류를 직접 보게 하기 위함이라고 할 수 있다. 직접 만나 보여줄 수도 있고, 오류 나는 과정을 자세하고 상세히 알려줄 수도 있을 것이다. 프로그래머에게도 마찬가지 오류가 나타나면 원인을 알 때까지 정보를 좀 더 모을 것이고, 같은 오류가 생기지 않으면 정보를 달라고 계속 요구할 것이다. 또 버그 리포트에서는 실제 발생하는 현상과 자신의 추측을 명확하게 구분해 밝혀야 한다. 추측은 생략해도 무방하지만 사실에 대해서는 절대로 생략해서는 안 된다.

버그 리포트는 버그가 고쳐지길 바라는 마음으로 쓰는 것이다. 프로그래머를 비방한다거나 의지를 꺾어 버리는 행위는 도움이 되지 않는다. 프로그래머의 실수일 수도, 사용자의 실수일 수도 있다. 그리고 프로그래머에게 약간 화가 났을 수도 있겠지만, 알고 싶어 하는 모든 정보를 알려주어 프로그래머를 도와야 버그가 좀 더 빨리 고쳐질 것이다.

"잘 안 돼요"

프로그래머의 기본적인 지식을 믿어야 한다. 프로그램이 동작하지 않는다면 배포했을 리가 없다. 아니면 적어도 공지는 했을 것이다. 알려진 바가 없다면 프로그램은 잘 돌아가야만 한다. 그러므로 무언가 다른 점이 없는지, 특이한 설정이 없는지 확인해야 한다.

프로그래머에게는 정보가 있어야만 한다. 이러한 정보를 제공하는 것이 버그 리포트이고 이 정보는 많을수록 좋을 수밖에 없다. 오픈 소스 프로그램이라면 사이트에 올려진 이미 알려져 있는 버그 목록을 살펴보는 것도 좋다. 알려진 버그 목록에 있는 내용이라면 굳이 같은 내용을 또 알려줄 필요가 없을 것이다. 하지만 그 내용이 좀 모자라면 더 많은 내용을 덧붙이는 것이 버그를 해결하는 데 도움이 될 것이다.

"보여 주세요"

가장 좋은 버그 리포트 방법 중 하나는 바로 프로그래머에게 보여주는 것이다. 프로그램을 실행한 후에 프로그램에 어떤 동작을 했고 어떤 입력을 했는데 어떤 반응이 있었는지 직접 보게 하는 것이다.

프로그래머는 프로그램에 대해서는 훤히 꿰고 있다. 어떤 부분이 확실하고 어떤 부분에서 문제가 생길 수 있는지도 잘 안다. 어디를 더 살펴봐야 하는지도 직관적으로 알고 있고, 전에 잘못되었던 부분을 이미 알고 있으므로 단서가 될만한 부분을 찾아낼 것이다.

"제가 확인할 수 있게 알려 주세요"

지금은 인터넷 시대다. 프로그램에 이상이 생겼다고 해서 프로그래머를 내 컴퓨터 앞에 오게 할 수는 없다. 앞에서 얘기한 대로 직접 보여주는 것이 좋긴 하지만 그럴 수 없는 경우가 훨씬 더 많다. 그렇다면 프로그래머가 확인할 수 있도록 버그를 재현하는 것이 좋다. 정확히 어떠한 동작을 했는지에 대해 설명해야 한다.

GUI 프로그램이라면 어떤 순서로 어느 버튼을 눌렀는지, CUI 프로그램이라면 무슨 명령어를 입력했는지 정확히 알려줘야 한다. 그리고 입력 값을 다 알려주어야 한다. 프로그램이 파일을 읽는다면 그 파일 복사본도 보내야 하고, 네트워크로 다른 컴퓨터와 통신을 한다면 다른 컴퓨터의 프로그램을 보내주지 못하더라도 적어도 어떤 종류의 컴퓨터인지, 거기엔 어떤 프로그램이 돌고 있는지 정도는 알려주어야 한다.

"난 잘 되는데, 뭐가 문제죠?"

이렇게 했는데도 프로그래머의 컴퓨터에서는 잘 동작한다면 아직도 정보가 충분하지 않다는 것인데, 아마도 모든 컴퓨터에서 문제가 발생하지는 않는다는 의미일 것이다. 무언가 다르게 동작한다는 것일 테고, 프로그램의 의도된 바를 정확히 모를 수도 있다. 틀렸다고 생각하는 것이 프로그래머가 알기엔 맞게 동작하는 것일지도 모른다.

그래서 정확하게 설명하는 것이 중요하다. 보이는 것을 정확히 알려주고, 왜 틀렸다고 생각하는지 설명한다. 어떻게 나오기를 기대했는지까지 알려주면 더욱 좋다.

에러 메시지를 보았다면 정확히 알려주어야 한다. 정말로 중요하다. 실제로 에러 메시지는 숫자 형태로 많이 나오는데 이 숫자가 정말 중요하다. 프로그래머는 금방 알 수 있고, 치명적인 단서가 될 수 있는 여러 정보를 포함하고 있다. 에러 메시지나 이해되지 않는 어떤 문자열, 숫자들 그리고 예기치 않은 지연까지도 범죄 현장의 지문과 같이 중요한 단서로 사용된다.

유닉스 계열 프로그램에서는 coredump가 좋은 단서로 사용된다. 대용량 파일이다 보니 주고받는 데 문제가 될 때도 있고, 개인 정보나 기밀 정보 같은 비밀스런 내용을 포함할 수도 있으므로 프로그래머에게 보내기 전에 한 번 확인해보는 것이 좋겠다.

"제 생각에는 이 모듈에서 문제인 거 같은데요?"

프로그래머들이 쓰는 버그 리포트는 도움이 될 때가 많다. 동업자 정신을 발휘하여 프로그래머를 도우려고 자신의 지식을 이용하는 데 이것이 정확한 분석이라면 프로그래머로서는 문제를 절반은 해결한 거나 다름없다. 그러나 프로그래머라고 다른 프로그램에 대한 분석도 꼭 정확하리라는 보장이 없다. 그래서 더 혼란을 일으키는 경우도 있다.

증상에 대한 설명 없이 나름의 분석 결과만 알려주는 것보다는 증상만을 정확히 알려주는 것이 훨씬 도움이 된다. 요즘 유행하는 신종 독감으로 병원에 가더라도 "태미플루 처방전 주세요"라고 하진 않을 것이다. 의학 지식이 있어도 "열이 좀 나고 두통이 있어요"와 같이 자신의 정확한 증상에 대해서만 설명하는 것이 의사가 훨씬 더 정확하고 빠른 진단을 하는 데 도움이 된다.

"참 재미있어요. 좀 전에는 됐거든요"

간헐적으로 발생하는 버그는 프로그래머에게 상당히 곤란한 경우 중 하나다. 일련의 간단한 동작으로 생기는 문제점이라면 정말 쉽지만, 테스트 조건을 쉽게 만들기도 어렵고, 어쩌다 가끔 발생하는 문제점이라면 난감한 일이 아닐 수 없다.

하지만 이런 버그 중 대부분은 어딘가 논리적인 문제에서 기인하는 경우가 대부분이다. 갑자기 메모리가 부족하다든지 특정 시점에 다른 프로그램이 중요한 파일을 수정했다든지 하는 것들이다. 아니면 서로 다른 환경에서 서로 다른 방식으로 동작한 차이점을 정확히 파악하면 알아낼 수 있는 것들이다. 예를 들어, 1024×768 해상도에서는 잘 동작하던 야구 게임이 800×600 해상도에서는 타자가 화면에 보이지도 않는 경우가 있었다.

프로그래머들은 가끔씩 발생하는 이런 버그들은 특정 시스템에 한하는 경우가 대부분이라고 생각하는 경향이 있다. 그래서 이런 경우라면 프로그램, 운영체제 등의 버전 정보를 알려주는 것이 많은 도움이 된다.

"그래서 내 컴퓨터에서 디스크를 읽었는데요."

버그 리포트의 가장 중요한 부분 중 하나가 ‘명확한 표현’이다. 모호하게 표현하면 누구든 오해하기 쉽다.

• 확실하고 구체적인 표현: 같은 내용을 여러 방법으로 표현할 수 있다. 예를 들면 "열기를 선택했어요"보다는 "파일 메뉴의 열기를 클릭했어요"나 "Alt-L을 눌렀어요"가 좀 더 구체적인 표현이다.


• 장황한 내용: 정보는 많을수록 유용하다. 많아도 프로그래머는 이 중에 필요한 것을 걸러 이용할 수 있다. 하지만 양이 적다면 유용한 정보를 얻을 때까지 계속 질문을 할 수밖에 없을 것이다.


• 정확한 대상: "FooBar 프로그램을 실행했더니 경고 창이 나왔어요. 닫으려고 했더니 죽어버렸죠"라고 하면 Foobar 프로그램을 닫았는지 경고 창을 닫았는지 모호하다. "경고 창의 확인 버튼을 눌러 경고 창을 닫으려 했더니 Foobar 프로그램이 죽었죠"라고 표현하는 게 좀 더 정확한 대상을 지칭하는 것이다. 또한 대명사도 자주 쓰면 정확한 대상이 되는 명사를 놓치기 쉽기 때문에 사용을 최소화하는 것이 좋다.


• 검토하기: 리포트를 보내기 전에 한 번 읽어보는 것이 좋다. 버그 재현을 위해 일련의 동작을 기술했다면, 동작들을 그대로 해보면서 다른 사람이 그대로 따라 한다고 가정하고 빠진 부분이 없는지 살펴본다.

마지막으로 요약하면 다음과 같다.

• 프로그래머의 눈으로 확인할 수 있는 버그 리포트: 버그 리포트의 첫 번째 목적은 프로그래머가 자신의 눈으로 에러를 확인하게 하는 것이다. 앞에서 세워놓고 직접 보여줄 수 없다면, 프로그래머가 버그를 재현할 수 있도록 자세히 설명한다.


• 문제점을 파악할 수 있는 버그 리포트: 첫 번째 목적대로 프로그래머의 눈으로 확인하기가 어려울 수 있다. 무엇이 잘못된 것인지 프로그래머가 알도록 기술하는 것이 버그 리포트의 두 번째 목적이다. 본 것, 예상했던 것을 최대한 자세히 기술하고, 에러 메시지나 숫자 등이 나오면 잊지 말고 함께 기술한다.


• 입증할 수 있는 증거로서 버그 리포트: 있는 그대로 보이는 내용을 기술한다. 자기 나름대로의 분석도 유용할 수 있지만 사실적 증상을 대신할 수는 없다.


• 명확한 버그 리포트: 보고하려는 내용에 맞게 기술되어 있는지 다시 한 번 읽어보고 오해할 여지가 있는지 확인한다.

정확해야 한다. 프로그래머는 정확함을 좋아한다.
컴퓨터에게 모든 것은 정확하면 1이고 아니면 0일 뿐이다.
"맞아? 틀려?" "if? else?" "0 or 1"