[15장 보충] 버그 경향을 통한 제품 출시 일정 결정

제품을 언제 출시해야하는지는 모든 이의 고민입니다. 개발자는 하루라도 늦게 제품을 출시하기를 바라고 영업/마케팅은 하루라도 빨리 제품을 출시하기를 바랍니다. 고객은 당연히 빨리 신제품을 보기를 원하겠지요? 그렇다면 어떤 기준에 의해 제품 출시 일정을 결정해야 할까요? 그냥 사장님 마음? 갑의 변덕? 영업/마케팅과 연구소 사이의 권력 투쟁? 권력을 쥐고 있는 높으신 분이 날씨나 기분에 따라 들이대는 자의적인 기준이 아니라 뭔가 정량적인 기준이 있으면 좋겠다는 생각이 들지 않습니까?

마이크로소프트 사에서 채택하고 있는 출시 일정 결정 방법은 바로 버그 경향 분석을 통한 황금율입니다. 제품 출시 준비가 가까워질수록 새로운 버그 감지 비율이 0에 가까워집니다. 따라서 버그 경향 분석이 제대로 이뤄진다면 얼마나 제품이 빨리 안정화되는지 감지가 가능하고, 이 정보에 따라 제품 출시일을 근접하게 추정할 수 있습니다. 이번에 무척 말이 많았던 마이크로소프트의 신형 운영체제인 비스타도 버그 경향 분석에 따라 제품 출시 일정이 여러 차례 바뀌었던 걸로 보입니다.

비록 조금 오래된 통계 자료이지만 마이크로소프트 맥 워드 4.0 사후 분석 보고서에 실린 버그 감지 비율 그래프를 예를 들어보자면, 1988년 3월달 평균 버그 숫자가 100이라면(이후 버그 숫자는 100에 대해 상대적인 비율), 여러차례 등락을 거듭해서 1988년 10월 코드 완료 시점에서 30을 가리킵니다. 후반 테스트가 강화되면서 1988년 말에는 다시 급상승해서 거의 60을 가리키게 되며, 차츰 낮아져서 1989년 4월 무렵에는 10 이하로 떨어져서 안정화 됩니다. 마이크로소프트와 같이 오피스 프로그램에 강한 회사조차도 코드 완료 시점에서 버그 감지 비율이 0에 가까워지기까지 거의 5개월이 결렸다는 사실을 비춰볼 때, 소프트웨어 부문에서 안정화 작업이 얼마나 어려운지 감이 올겁니다.

이런 이유로 인해 제품 출시가 가까워지면, 프로젝트 관리자, 개발자, 테스터가 눈코뜰새 없이 바빠지게 됩니다. 모든 사람이 코드를 테스트하고 버그를 감지해서 평가하고 결함을 수정하는 작업에 매달립니다. 테스트는 모든 사람이 진행할 수 있지만, 수정은 개발자만이 가능하므로, 개발자가 코드를 바꿔서 거의 매일 체크인한 다음에 일일 빌드를 통해 제품을 안정적이고 항상 준비된 상황으로 유지해줘야 합니다. 이런 작업을 계속 진행하다보면 어느 순간 개발자가 테스터를 따라잡는 순간 - 다시 말해 알려진 모든 심각한 버그를 잡는 순간이 오기 마련입니다. 바로 이 때를 제로 버그 반동(zero bug bounce)라고 부릅니다. 마이크로소프트 버그 경향 황금률에 따르면 응용 프로그램 부문에서 제로 버그 반동이 일어나면 대략 6주 후에 제품 출시가 가능하다고 합니다. 물론 요즘 나오는 복잡한 프로그램의 경우에는 6주가 아니라 6달이 될지도 모르지만 말입니다.

이렇게 개발팀은 황금률을 뒷받침하는 자료를 확보하고 있어야 합니다. 그래야 위에서 낙하산 식으로 떨어진 출시일정에 휘말리는 바람에 불어오는 피바람을 피할 수 있습니다. 여러분 회사는 어떻습니까? 체계적으로 버그 데이터베이스를 구축/운영하는 노하우를 보유하고 있습니까? 만일 이런 노하우가 있는 회사에 근무한다면 당신은 행운아입니다.

"The Art of Project Management: 마음을 움직이는 프로젝트 관리" 역자 박재호 올림