프로젝트가 후반부에 접어들면 신규 기능 구현보다는 버그 수정이 주 업무가 됩니다. 사내 테스트, 알파 테스트, 베타 테스트 등 출시 일정도 잡히게 됩니다. 끝날 것 같지 않던 프로젝트의 끝이 보이기 시작하면서 지쳐 있던 팀원들도 마지막 힘을 내 스퍼트를 하고 있습니다.

하지만 개발 PM 입장에서는 말 못할 고민이 하나 있습니다. 이미 출시 일정은 잡혔는데, 버그 수정에 관해서는 도무지 일정을 추정할 수 없기 때문입니다. 다급한 마음에 팀원들을 재촉하지만 반응이야 뻔합니다.

버그가 언제 잡힐지 어떻게 알아요? 해봐야 알죠.

기능 구현에 비해 버그 수정은 일정 산출이 훨씬 어렵습니다. 일정을 물어보면 대부분의 PM은 모른다고 답하거나, 스스로도 지키지 못할 약속만 할뿐입니다. 사실 버그 원인도 모르는데 수정에 얼마나 시간이 걸릴지 추정한다는 건 의미가 없습니다. 겉으로 보기에 간단한 버그라도 원인 파악부터 수정까지 상당한 시간이 걸릴 수도 있습니다.

예전에 같이 일했던 모 대기업의 수석님이 본인이 노하우를 살짝 공개하신 적이 있습니다.

버그가 30개, 사원이 5명이 있다고 칩시다. 사원들한테 각자 버그를 6개씩 나눠주고 내일 아침까지 잡아오라고 하면 됩니다. 아무 말도 안 하고 있으면 버그가 안 잡히는데, 이렇게 명시적으로 버그를 나눠주고 기한을 주면 어떻게든 버그가 잡혀요.

이 말을 듣고 어떤 표정을 지어야 할지 난감했던 기억이 있습니다. 그리고 그날 울 것 같은 표정으로 선임들 옆을 멍하니 서성이던 신입 사원들의 표정을 잊을 수가 없습니다. 사실 특별히 유난스런 사례도 아닙니다. 이 단계가 되면 대부분의 사람들이 대동단결하여 이렇게 외칩니다.

난 잘 모르겠고, 어쨌거나 출시까지 버그 다 고쳐와.

버그 수정은 작업의 특성상 일정 산출이 어려운 것이 사실이지만, 다행히 일정 산출의 리스크를 줄일 수 있는 방법이 있습니다. 버그를 우선순위에 따라 분류하고, 버그 해결을 원인 파악과 수정 두 단계로 나눠서 생각하는 것입니다.

우선, 모든 버그를 분류합니다. 각각의 버그는 우선순위와 심각도를 표시합니다. 여기서 우선순위는 해결해야할 버그의 순서를 말합니다. 우선순위가 높을수록 먼저 해결해야 하는 버그입니다. 보통 상, 중, 하로 구분합니다. 심각도는 소프트웨어에 미치는 여파를 말합니다. 크래시가 나거나 멈추는 버그는 심각도가 높고, 폰트가 1px 정도 밀리는 버그는 심각도가 낮습니다.

이렇게 버그를 우선순위와 심각도에 따라 분류하는 것을 버그 트리아지(bug triage)라고 부르는데, 트리아지라는 말 자체가 병원에서 치료 우선순위를 정하기 위한 부상자 분류에서 온 말입니다. 예를 들어, 큰 사고가 생겨 많은 환자가 한꺼번에 병원 응급실로 이송되어 온 상황입니다. 물론 도의적 차원에서야 환자 한명 한명이 소중한 생명이고 모두를 살리는 것이 가장 좋지만, 투입할 수 있는 의사나 간호사의 인력은 제한되어 있고 약품이나 물자도 부족하기 때문에 환자 중에 누구를 먼저 치료할 것인지 부상의 정도나 긴급성에 따라 분류를 하지 못하면 더 많은 희생을 치를 수밖에 없습니다.

예를 들어, 모바일 게임을 만들고 있는데, 스플래시 스크린의 게임 제목에 오타가 발견되었습니다. 이 버그는 심각도는 낮지만 우선순위는 매우 높습니다. 오타 있어서 게임 플레이에는 아무런 지장이 없지만, 모두가 보는 첫화면에 오타가 있으므로 빨리 고쳐야 하는 긴급한 버그로 분류됩니다. 반대의 예도 있습니다. 게임 캐릭터가 특정한 아이템을 착용하고, 특정한 위치에서 필살기를 사용했을 때 게임이 멈추는 버그가 발견되었습니다. 이런 버그는 심각도는 높지만, 우선순위는 낮은 것으로 분류됩니다. 자주 일어나는 증상이 아니기 때문입니다.

우선순위는 상대적입니다. 버그를 상, 중, 하로 분류한다고 해서 하로 분류된 버그는 안 고쳐도 되는 버그란 뜻이 아닙니다. 다만, 버그를 잡을 수 있는 시간과 인력에 제한이 있으므로 우선순위가 높은 버그를 먼저 잡기 위해서는 분류가 필요한 것뿐입니다. 제가 같이 일해본 어떤 회사는 상, 중, 하 분류법으로는 부족하다고 생각했는지 최상, 긴급, 초긴급, 초초긴급, 당일 해결, 즉시 해결 등등을 만들어내기 시작했습니다. 하지만 이런 건 그저 다급함이 만들어낸 웃지 못할 촌극일뿐 실제로 문제 해결에 필요한 건 상대적 우선순위일 뿐입니다.

하지만 버그 트리아지만으로는 버그 수정 일정을 산출할 수는 없습니다. 어떤 버그를 언제까지 잡을지 일정을 산출한 것이 아니라 시간이 모자랄 경우 어떤 버그를 포기할 것인지만 정했을 뿐입니다. 버그 수정 일정 산출의 불확실성은 버그의 원인을 모르기 때문에 발생합니다. 일정을 산출하기 위해서는 버그의 원인부터 파악해야 합니다. PM 입장에서 아직 원인도 모르는 버그는 일정을 전혀 추산할 수 없는 블랙박스나 마찬가지고, 일단 원인 파악이 끝난 버그는 신규 기능 작성과 마찬가지로 명확한 일이 되기 때문입니다.

해당 버그가 기획 단계에서 미처 생각하지 못했던 코너 케이스라면 해당 케이스에 대해 기획을 보강하고 코드를 추가로 구현해야 할 것이고, 코딩 작업에서 발생한 단순 실수라면 해당 코드만 수정하면 될 것입니다. 혹은 코드의 구조적인 문제로 생긴 버그라면 상당량의 코드를 새로 작성하지 않는 이상 해결할 수 없을 수도 있습니다. 따라서 트리아지된 버그를 하나씩 개발자에게 할당하고 해결할 것이 아니라, 일단 버그들의 원인부터 먼저 파악하고 수정 방식이나 여부는 따로 결정하는 것이 좋습니다.

버그 원인을 알면 버그 수정이 쉬울지 어려울지 예상 가능하기 때문에 버그 수정에도 도움이 됩니다. 수학 시험을 볼 때 일단 전체적으로 문제를 훑어보고 쉬운 문제 먼저 풀고 어려운 문제를 나중에 푸는 것처럼, 버그들의 원인을 먼저 파악하고 쉬운 버그, 어려운 버그를 구분하면 쉬운 버그 먼저 잡고 어려운 버그를 나중에 잡을 수 있기 때문입니다. 물론 우선순위를 무시하고 쉬운 버그 먼저 잡으라는 뜻이 아니라, 비슷한 우선순위의 버그라면 쉬운 버그를 먼저 잡으란 뜻입니다.

버그가 10개가 있는데, 한번에 하나씩 버그를 수정하는 방식으로 진행을 하면 남은 버그 수정에 시간이 얼마나 더 걸릴지 전혀 알 수가 없습니다. 하지만 10개 버그의 원인 먼저 파악하고, 누가 어떻게 수정할지 계획이 있는 상태면 10개 버그 수정에 시간이 얼마나 걸릴지 대략적인 예측이 가능합니다. 물론 어떤 방식이든 절대적으로 버그 수정에 걸리는 시간은 똑같을 수도 있고, 경우에 따라 원인만 먼저 파악하는 방식이 오히려 시간이 더 걸릴 수도 있습니다. 하지만 원인을 먼저 파악하면 일정의 불확실성을 줄일 수 있습니다.

프로젝트에 있어 가장 큰 리스크는 불확실성입니다. 그리고 일정 관리란 일을 더 빨리하는 방법이 아니라 불확실성을 줄이는 방법입니다. 버그 수정도 예외는 아닙니다. PM의 역할은 버그 하나라도 더 잡으라고 개발자들을 독촉하는 것이 아니라 문제가 발생하지 않도록 미리 대비하는 것입니다.