Joel on Software   조엘 온 소프트웨어

한글로된 다른 "Joel on Software" 글들

영어로된 다른 "Joel on Software" 글들

필자 메일주소(영어만 사용)

과거, TRS-80 Level-I BASIC은 오로지 A$와 B$라는 두 개의 문자열 변수만을 저장할 수 있었다. 마찬가지로, 필자가 타고난 두뇌 속의 버그 저장용 슬롯도 두 개밖에 되지 않는다. 즉, 필자가 한번에 기억할 수 있는 버그의 수는 두 개를 넘지 못한다. 만일 한꺼번에 세 개의 버그를 기억해야 한다면, 필경 셋 중의 하나는 놓쳐버렸을 테고 바닥에 떨어뜨린 이 버그는 침대 밑으로 쓸려 들어가 결국 먼지덩어리 속에 파묻히고 말 것이다.

버그 정보를 꾸준히 데이터베이스화 하는 것은 훌륭한 소프트웨어 팀이 갖춰야 할 덕목임에도 불구하고, 실제로 이를 제대로 실천하고 있는 소프트웨어 팀은 극소수라는 사실에 놀라지 않을 수 없다. 프로그래머들이 좀처럼 버리지 못하는 잘못된 믿음 중의 하나가 바로 모든 버그 정보를 기억할 수 있다거나 혹은 메모지에 적어두는 것만으로 충분하다는 것이다.

여러분이 잠시만 귀를 기울여준다면, 필자가 앞서 쓴 손쉬운 스케줄 관리법과 손쉬운 스펙 작성법에 이어 아주 손쉬운 버그 추적 방법에 대해서도 설명을 좀 해볼까 한다.

무엇보다, 버그 추적을 위해서는 진짜 데이터베이스가 필요하다. 두 사람의 프로그래머가 주말 동안 작은 코드를 하나 만들어내는 경우라면 그냥 텍스트 파일을 버그 추적용 데이터베이스로 사용해도 무방하다. 하지만, 이보다 작업 규모가 커지는 경우에는 실제 버그 추적용 데이터베이스가 필요하다. 시중에 나와있는 버그 추적 데이터베이스 제품은 매우 다양하다. (막간을 이용한 자사 홍보: 필자의 회사인 Fog Creek Software에서 내놓은 FogBUGZ는 사용이 매우 간편하면서도 기능은 강력한 웹 기반의 버그 추적 데이터베이스 제품이다. 자화자찬 같기는 하지만.)

버그 추적 과정의 예를 살펴보기 위해, 그 탄생의 순간부터 누군가에 의해 소멸될 때까지, 한 버그의 일생을 따라가 보자. 여기서는 저 유명한 버그 1203의 일생을 추적하기로 한다. 다음은 이 버그에 대한 데이터베이스의 내용이다.

이야기인즉 다음과 같다.

프로그래머인 마이키는 자신의 매킨토시 소프트웨어 구버전에 대한 새로운 FTP 클라이언트 기능을 만드느라 컴퓨터와 씨름하고 있다. 코딩 과정에서 마이키는 자신이 만든 문자열 복사 기능을 이용한다. 이것이 장차 코드 재사용의 필요성을 일깨워줄 사건의 화근이 된다는 사실을 모른 채… 하하!

이봐, 마이키, 코드를 재사용하지 않으면 나쁜 일이 생긴다니까. 그리고, 이날 마이키에게 일어난 나쁜 일이란 그가 복사한 문자열을 널(null) 문자로 종료하는 것을 깜빡 잊어버렸다는 것이다. 하지만 그는 그런 사실을 알아차리지 못했다. 이전에 그가 간혹 문자열을 복사했을 때는 공교롭게도 메모리가 미리 널-종료된 상태였기 때문이다.

같은 주 후반, 이 회사의 매우, 매우 유능한 테스트 담당자인 질은 이 코드를 놓고 무자비하게 꼼꼼한 테스트를 진행하고 있다. 그녀는 컴퓨터 앞에서 머리를 앞뒤로 흔들어가며 자판을 열심히 두드리고 있다. (말이 난 김에 하는 말인데, 왜 유능한 테스트 담당자들의 이름은 주로 질이나 질리안, 뭐 그런 식일까?) 그때 갑자기 아주 이상한 일이 일어났다. 그녀가 테스트하고 있던 ftp 데몬이 다운된 것이다. 분명히 그 컴퓨터는 리눅스 시스템이었고 리눅스 시스템은 다운되는 법이 없는데 (‘컴’ 도사님들의 야유가 빗발치겠군), 그런데도 이 망할 것이 다운돼 버린 것이다. 게다가, 그녀는 서버에는 아직 접속하지도 못한 채로, 마이키가 짠 매킨토시 코드를 사용하여 FTP 파일 작업만 하고 있었는데 말이다.

질은 매우, 매우 유능한 테스트 담당자이기 때문에, 자신이 하는 모든 일을 항상 꼼꼼히 기록해둔다 (가령, 그녀가 자판을 두드리며 머리를 흔들 때 앞뒤로는 얼마나 또, 좌우로는 얼마나 흔드는지 등을 모두 기록해둔다). 그녀는 시스템을 재부팅한 후, 자신의 기록을 바탕으로, 다시 방금 전의 단계들을 그대로 되풀이해본다. 그러자, 이것 봐라! 똑같은 일이 다시 일어난 것이다. 리눅스 ftp 데몬이 또 다운됐다. 리눅스 시스템이 하루에 두 번씩이나 다운되다니! 이봐, 리누스, 이 사실을 받아들여.

질은 두 눈을 가늘게 뜨고 버그 재현 단계 목록을 유심히 들여다본다. 재현 과정은 약 20 단계쯤 된다. 그 중 일부는 시스템 다운과는 아무 관련이 없어 보인다. 약간의 실험을 해본 후에 질은 언제나 동일한 결과를 야기하는 네 개의 단계로 문제의 범위를 압축할 수 있었다. 이제, 버그를 데이터베이스에 등록할 준비가 완료된 것이다.

질은 이 새로운 버그를 버그 추적 데이터베이스에 등록한다. 자, 버그 정보를 입력하는 데에도 훈련이 필요하다. 세상에는 좋은 버그보고서와 나쁜 버그보고서가 있기 때문이다.

좋은버그보고서의3요소

그러자 신께서 말씀하시기를, "그대는 먼저 ‘성스러운 핀’을 뽑을지어다. 그리고 나서 셋을, 더도 말고 덜도 말고, 셋을 셀지어다. 반드시 숫자는 세 번만 세어야 하나니, 오로지 셋까지만 셀지어다. 넷도 아니 되고 둘도 아니 되느니, 둘은 셋을 세기 위해 거쳐가는 것만 허락될지니라. 다섯은 더더욱 아니 되느니라. 셋이 되거든, ‘성스러운 안티오크의 수류탄’을 그대의 적들을 향해 천천히 던질지어다. 그리하면, 사악한 적들이 그 연기를 들이쉬게 될지니라."

-- 영화‘몬티파이톤과성배’ 중에서

좋은 버그 보고서를 만다는 규칙은 간단하다. 좋은버그보고서에는항상세가지정보가필요하다.

1.      버그를 재현할 수 있는 과정

2.     당초 기대했던 적정 결과

3.     버그로 인한 실제 결과

보라! 간단하지 않은가? 사실은 그다지 간단하지 않을 수도 있다. 필자의 경험으로 볼 때, 프로그래머에게 버그 수정을 요청하는 사람들은 항상 이중에서 한 가지는 빼먹기 때문이다.

버그를 재현할 수 있는 방법을 설명해주지 않으면, 프로그래머는 도대체 어떤 버그를 말하는 것인지조차 감을 잡을 수가 없다. “프로그램이 다운되더니 시스템이 엉망이 돼 버렸어.” 아주 친절한 설명이로군. 구체적으로 무엇을어떻게했는지를 말해주지 않으면 프로그래머는 아무것도 할 수가 없다. 정확한 버그 재현 과정을 설명하기 어렵다는 점을 프로그래머가 인정할 수 있는 경우는 두 가지다. 첫 번째는 가끔씩 그저 기억이 잘 나질 않거나 혹은 그냥 “필드” 테스트에서 버그 결과만 그대로 옮기는 경우다. (그런데, 왜 “필드”(field, 밭)이라는 말을 쓸까? ‘호밀밭’ 할 때 그 밭하고 같은 의민가? 아무튼...). 버그 재현 과정을 정확하게 보고하기 어려운 또 다른 경우는 버그가 매번 발생하는 것이 아니라 이따금씩 발생하는 경우다. 하지만, 이런 경우에도 버그 재현 과정은 설명해주어야 한다. 버그가 자주 발생하는 것은 아니라는 주석과 함께. 이처럼 정확한 버그 재현 과정을 파악할 수 없는 경우 버그를 찾아내기란 매우 어렵지만, 그래도 프로그래머들은 디버깅을 시도한다.

또, 당초기대했던적정상태가 어떤 것인지 구체적으로 이야기해주지 않으면, 프로그래머는 도대체 이게 왜 버그라는 것인지 이해할 수 없게 된다. 스플래쉬 화면에 핏자국이 있어요. 그래서요? 그건 코딩할 때 내가 손가락을 다쳐서 그때 묻은 거예요. 도대체 그게 뭐가 잘못됐다는 거죠? 아, 원래 스펙에는 핏자국은 포함되지 않았다는 말이구나. 진작에 그렇게 말씀을 해주시지.

마지막으로, 버그로 인한 결과를 설명해줘야 프로그래머가 버그의 정체를 알 수 있다. 마지막 규칙은 비교적 지키기 쉬운 편이다. 눈에 보이는 상태를 이야기하면 되니까.

처음의이야기로다시돌아와서

여하튼, 질은 이 버그를 데이터베이스에 등록한다. 효과적인 버그 추적 시스템의 경우, 버그를 입력하면 해당 프로젝트의 수석 개발자에게 자동으로 할당된다. 그리고, 여기에 두 번째 핵심 개념이 들어있다. 즉, 모든 버그는 그것이 완전히 종결될 때까지 한사람이 처리해야 한다는 것이다. 버그는 프로그래머들에겐 뜨거운 감자다. 일단 자신에게 할당되면 책임지고 이것을 해결하든가 아니면 어떻게 해서든 다른 사람한테 넘겨야 한다.

수석 개발자인 윌리는 이 버그를 살펴보고는 아마도 ftp 서버와 관련된 문제일 것이라고 판단한다. 그리고는 “수정 불가” 판정을 내린다. 어쨌든 ftp 서버는 윌리의 개발팀에서 만든 것이 아니니까.

해결 판정이 내려지면, 이 버그는 처음 버그를 등록한 사람에게로 되돌아온다. 이는 매우 중요한 사실이다. 프로그래머가 해결된 것으로 생각한다고 해서 버그가 사라지는 것은 아니다. 황금률은 버그를 처음 등록한 사람만이 그 버그 문제를 종결할 수 있다는 것이다. 프로그래머는 버그를 해결하고 “드디어 이 버그를 고쳤다!” 라고 말할 수는 있지만, 실제로 이 버그 문제를 종결하고 상황을 종료할 수 있는 사람은 처음 이 버그를 등록한 당사자뿐이다. 처음 버그를 등록한 사람이 이 버그가 실질적으로 수정되었음을 확인하거나 혹은 어떤 이유로든 그 버그를 수정할 수 없다는 데 동의해야만 상황이 종료된다.

질은 이 버그가 자신에게 다시 되돌아왔다는 이메일을 받게 된다. 그녀는 이메일을 열어 수석 개발자인 윌리의 의견을 읽는다. 하지만, 뭔가 석연치 않다. 지금까지 몇 년 동안 사람들이 이 ftp 서버를 사용해 왔지만 다운된 적은 없었다. 마이키의 코드를 사용할 때만 다운되는 것이다. 그래서, 질은 이 버그를 데이터베이스에 재등록하고 자신의 의견을 덧붙인다. 버그 추적 데이터베이스에 입력된 버그는 다시 윌리에게 할당된다. 그는 이번에는 이 버그를 마이키에게 할당한다.

마이키는 이 버그를 오랫동안 열심히 들여다보고는 전혀 엉뚱한 진단을 내린다. 엉뚱한 버그를 수정한 후, 그는 질이 등록한 버그가 해결되었다고 판정한다.

버그는 다시 질에게 되돌아온다. 이번에는 “해결 – 수정 완료” 라는 표시가 붙은 채로. 질은 버그 재현 과정을 되풀이해본다. 그러자, 이게 웬일인가? 리눅스 서버가 또 다운되었다. 질은 이 버그를 데이터베이스에 다시재등록하고 이번에는 곧바로 마이키에게 버그 수정을 할당한다.

마이키는 당황했지만, 마침내 버그의 원인을 찾아낸다. (여러분은 아직 찾아내지 못했는가? 이 버그는 독자 여러분을 위한 연습문제로 남겨두겠다. 힌트는 이미 충분히 제공했으니까.) 마이키는 그것을 수정했고 테스트했고 그리고는 마침내 해냈다! 버그 재현 과정을 그대로 반복해도 더 이상 ftp 서버는 다운되지 않는다. 다시 한번, 마이키는 이 버그를 “수정 완료” 상태로 판정했다. 질도 버그 재현 과정을 되풀이해보았고 버그가 완전히 수정되었음을 확인하고는 이 버그를 종결했다.

효과적인버그추적을위한10계명

1. 유능한 테스트 담당자는 항상 버그 재현 과정을 최소한의범위로 축소하기 위해 노력한다. 이런 노력은 프로그래머가 버그의 원인을 찾아내는 데 크게 도움이 된다.
2. 처음 버그를 등록한 사람만이 그 버그를 종결할 수 있다는 점을 명심하라. 누구든 버그를 수정할 수는 있지만, 처음 버그를 발견한 사람만이 그 버그가 완벽하게 고쳐졌는지도 확인할 수 있다.
3. 버그를 해결하는 방법에는 여러 가지가 있다. FogBUGZ 데이터베이스를 이용하면, 수정완료, 수정불가, 연기, 재현불가, 중복버그, 설계상의오류 등으로 버그를 처리할 수 있다.
4. ‘재현 불가’라 함은 어느 누구도 그 버그를 다시 재현해낼 수 없는 경우를 말한다. 버그 보고서에 버그 재현 과정이 누락되어 있는 경우, 프로그래머들은 종종 재현 불가 판정을 이용한다.
5. 버전 관리에 유의하라. 테스트 담당자에게 제출하는 소프트웨어에는 항상 빌드(build) ID를 명시해야 한다. 그렇지 않으면, 가엾은 테스트 담당자가 디버깅도 되지 않은 소프트웨어 버전을 가지고 버그 수정 여부를 테스트하는 상황이 벌어질 수도 있다.
6. 테스트 담당자들이 버그 추적 데이터베이스를 사용하려 들지 않아서 애를 먹고 있는 프로그래머들이 있다면, 버그 데이터베이스 이외의방법으로는아예버그보고서를접수하지도마라. 혹시 테스트 담당자가 이메일로 버그 보고서를 보내오거들랑, “이 내용을 버그 데이터베이스에 입력해 주세요. 이메일은 추적관리가 불가능하답니다.” 라는 짤막한 메시지와 함께 버그 보고서를 되돌려보내라.
7. 반대로, 프로그래머들이 버그 추적 데이터베이스를 사용하려 들지 않아서 애를 먹고 있는 테스트 담당자들이 있다면, 그냥 아무말도하지마라. 버그 정보를 버그 데이터베이스에 입력하면, 데이터베이스가 알아서 프로그래머에게 이메일을 보내줄 테니까.
8. 동료 프로그래머들이 버그 추적 데이터베이스를 사용하려 들지 않는다면, 버그 수정 업무를 할당할 때 꼬박꼬박 버그 추적 데이터베이스를 이용하라. 결국은 동료들도 그 뜻을 이해하게 될 것이다.
9. 거금을 들여 설치한 버그 추적 데이터베이스를 아무도 사용하지 않아서 고민하는 관리자가 있다면, 프로그래머들한테 새로 개발할 기능을 할당할 때도 버그를 이용해 보라. 버그 추적 데이터베이스는 “구현 예정 기능” 데이터베이스로서도 손색이 없다.
10. 버그 추적 데이터베이스에 새로운 필드를 추가하고픈 유혹을 이겨내라. 아마 매달 누군가는 데이터베이스에 추가할 새 필드에 대한 그럴듯한 아이디어를 내놓을 것이다. 솔깃한 아이디어는 얼마든지 있을 수 있다. 이를테면, 버그가 발견된 파일을 추적할 필드를 만든다거나, 버그 재현 가능 비율을 퍼센티지로 추적할 필드를 추가한다거나, 버그 발생 횟수를 기록할 필드를 만든다거나, 버그가 발생한 시스템에 설치된 DLL의 버전을 기록할 필드를 추가한다거나, 기타 등등. 이런 아이디어에 현혹되어서는 안 된다. 이런 제안에 넘어가다 보면, 버그 추적 데이터베이스는 결국 수천 개의 데이터 필드로 가득차게 될 것이고 아무도 그 데이터베이스에 버그 보고서를 입력하려 들지 않을 것이다. 버그 추적 데이터베이스가 실효성을 거두려면 모든 사람들이 그것을 사용해야 한다. 그런데, “공식적으로” 버그를 입력하는 일이 너무 번거로운 작업이 된다면 아무도 버그 추적 데이터베이스를 이용하려 들지 않을 것이다.

프로그래머 혼자서 단독으로 코드를 개발하는 경우라도, 체계적인 버그 관리 없이는 좋은 코드를 만들어낼 수 없다. 유능한 소프트웨어 개발팀의 경우, 팀원들 모두가 버그 추적 데이터베이스를 사용할 뿐만 아니라, 버그 추적 데이터베이스를 활용하여 각자의 “작업계획표”를 만드는 데에도 익숙해져 있고, 각자에게 할당된 버그 목록을 웹 브라우저의 기본 페이지로 설정하며, 급기야는 ‘버그 수정 업무를 사장님한테도 할당할 수 있다면 좋을 텐데’ 하는 생각까지 하게 된다.

Fog Creek Software사가개발한편리한버그추적패키지FogBUGZ.