TL;DR

  • 대규모 소프트웨어 프로젝트는 초기 직감이나 세부 작업 추정치의 단순 합산보다 유사 프로젝트 비교를 바탕으로 추정하고, 익숙함의 정도에 따라 불확실성 범위를 함께 제시하는 방식이 더 유용함.
  • 초기 직감은 개발의 핵심 기능만 떠올리고 나머지 업무를 놓치기 쉬워, 몇 달로 예상한 프로젝트가 1년 걸리는 식의 큰 과소 추정으로 이어질 수 있음.
  • 작은 작업으로 나눠 각각 추정하는 방식은 한 명이 약 한 달 수행하는 프로젝트에는 효과적일 수 있지만, 대규모 프로젝트에서는 통합 과정의 변수와 추정 작업의 부담을 놓치기 쉬움.
  • 비교 가능한 프로젝트가 있다면 전체 작업량을 일반 기능 개발과 프로젝트별 작업으로 나누고, 새 프로젝트의 차이를 반영해 조정하는 방식이 적합함.
  • 유사성에 따라 추정치는 약 ±25%, 최대 2배, 또는 4~8배까지 실제 작업량과 차이 날 수 있으므로, 범위와 위험을 솔직하게 전달해야 함.

효과가 없는 추정 방식

  • 소프트웨어 작업을 추정할 수 없거나 추정해서는 안 된다고 주장하며 추정을 거부하는 관점에는 동의하지 않음. 기업은 절충안, 마감일, 제한된 자원을 조율해야 하며, “끝날 때 끝난다”는 답으로는 기능 A와 기능 B 중 무엇을 만들지, 5월까지 일을 끝내려면 몇 명이 필요한지 결정하기 어려움.
  • 제대로 된 추정은 특히 여러 분기에 걸친 프로젝트에서 어려움. 소프트웨어 분야에서 15년간 여러 방법을 시도한 결과는 크게 빗나간 경우부터 제법 괜찮은 경우까지 다양했으며, 최근 몇 년간은 다음 두 요소를 결합하는 방식이 어느 정도 효과적이라고 판단함.
  • 초기 추정에 적절한 방법론 사용
  • 적절한 수준의 불확실성 반영
  • 이 글은 개발자를 위한 프로젝트 관리 입문 시리즈의 보충 글이며, 시리즈의 다른 글을 먼저 읽을 필요는 없음.
  • 반복해서 실패하는 두 가지 방식은 모두 큰 폭의 과소 추정을 낳음.
  • 첫째, 초기 직감에만 의존하는 추정임. 특히 소프트웨어를 처음부터 끝까지 제공해 본 경험이 부족할 때 위험함. 소프트웨어 제공에 필요한 일을 모르는 비즈니스 담당자뿐 아니라, 프로젝트 전체를 관리해 보지 않은 개발자도 핵심 기능을 코딩하는 일만 떠올리고 프로젝트 완수에 필요한 나머지 90%의 일을 놓치기 쉬움. 이 때문에 몇 달이면 된다고 본 프로젝트가 실제로는 1년 걸리는 상황이 생김.
  • 둘째, 작업을 몇 시간에서 며칠 단위의 작은 단계로 나눈 뒤 각각 추정해 합산하는 방식임. 놀랍게도 이 방식은 개발자 한 명이 한 달 정도면 끝낼 프로젝트에서는 꽤 효과적이지만, 더 큰 프로젝트에서는 자주 실패함.
  • 프로젝트를 아무리 철저히 설계하고 계획해도 진행 방향 수정, 팀 간 마찰, 누락되거나 변경된 요구사항, 기타 예상 밖의 일이 발생하며, 이런 일은 상당한 에너지를 소모하지만 사전에 규모를 추정하기 어려움.
  • 세부 작업을 추정하는 데 시간이 많이 듦. 대개 첫 몇 번의 스프린트만 추정한 뒤 지쳐서 포기하고, 프로젝트 나머지 부분은 직감으로 추정함.
  • 두 번째 방식도 첫 번째 방식보다는 나은 추정치를 낼 가능성이 높음. 그러나 정말 철저하게 수행하지 않는다면 추정치가 실제와 10배 이상 차이 나도 놀랍지 않음.

대규모 프로젝트 추정 방법

  • 지금까지 가장 효과적이었던 방법은 비교 가능한 프로젝트를 활용하는 것임. 이 접근법은 연구로 뒷받침되며, 여러 산업에서 반복적으로 적용됨. Flyvbjerg와 Gardner의 저서 *How Big Things Get Done*도 사례임.
  • 지난해 만든 기능과 유사한 새 기능을 추정하는 사례에서는, 지난해 프로젝트가 개발자 4명이 6개월간 수행한 일이므로 총 작업량이 약 24 개발자-월임.
  • 그중 약 4분의 1은 일반적인 기능 코드에 들어갔고, 나머지는 특성과 차이가 제각각인 은행 6곳과의 연동에 들어감.
  • 새 기능은 같은 프런트엔드와 백엔드를 다루지만 은행 연동은 6곳이 아니라 4곳임.
  • 일반 기능 작업은 이전과 같은 약 6 개발자-월, 은행별 작업은 이전의 약 18 개발자-월 중 4/6인 약 12 개발자-월로 추정함.
  • 총 추정치는 약 18 개발자-월임.
  • 은행 연동 코드를 재사용해 개발자-월 1개월을 절약할 수 있다고 확신한다면 그만큼 차감하는 식으로 세부 조정할 수 있음. 다만 실제 불확실성이 적어도 약 25%이므로, 작은 조정에 지나치게 신경 쓸 필요는 없음.
  • 비교 프로젝트를 활용하면 작은 작업부터 상향식으로 추정할 때 규모를 가늠하기 어려운 진행 방향 수정, 팀 간 마찰, 기타 예상 밖의 일을 대부분 자동으로 반영할 수 있음.
  • 적절한 비교 대상이 없다면 유사성이 낮은 프로젝트를 찾아 차이를 조정하거나, 다른 팀의 비교 가능한 프로젝트 또는 다른 회사에서 경험한 프로젝트를 참고할 수 있음.
  • 다른 방법이 모두 여의치 않으면 프로젝트를 더 큰 단위로 나눈 뒤 각 단위를 비교 사례를 바탕으로 추정할 수 있음. 다만 이 방식을 쓰면 여러 부분을 결합할 때 필연적으로 생기는 일부 변수를 다시 놓치게 됨.

추정치를 범위로 바꾸기

  • 초기 추정치가 마련되면 실제 추정에는 항상 범위 또는 불확실성 수준이 따른다는 점을 반영해야 함.
  • 적절한 불확실성 수준을 정하는 단계에서는 과학이나 엄밀한 방법론을 내세우기 어렵고, 과거 경험에 의존해야 함.
  • 익숙한 영역: 확실한 비교 대상이 있고 팀이 정기적으로 다루는 분야가 대부분인 경우임. 추정치와 실제 작업량의 차이는 대략 ±25%일 가능성이 큼.
  • 다소 새로운 영역: 좋은 비교 대상은 없지만 대부분 익숙한 분야인 경우임. 새로운 종류의 기능을 만들거나, 함께 일한 적 없는 팀 또는 API와 연동하거나, 새로운 인프라를 구축하는 상황이 여기에 해당함. 실제 작업량은 초기 추정치의 최대 2배일 가능성이 큼.
  • 완전히 미지의 영역: 처음 해 보는 일이며 개념 증명(POC) 결과나 개별 작업 항목을 조합해 추정해야 하는 경우임. 적어도 4배 과소 추정할 가능성이 있으며, 경험상 초기 추정치의 4~8배가 현실에 더 가까울 가능성이 큼.
  • 앞서 든 급여 기능의 사례를 각 상황에서 다음처럼 제시할 수 있음.
  • 익숙한 영역: “다른 기능을 만드는 데 걸린 시간을 기준으로 보면, 3~4명이 몇 분기 정도 작업하면 될 것 같음.”
  • 다소 새로운 영역: “예상치 못한 일이 무엇인지, 재사용할 수 있는 것이 무엇인지에 따라 3~4명이 두세 분기 정도 작업할 수 있음.”
  • 완전히 미지의 영역: “이런 일을 해 본 적이 없음. 겉으로는 별것 아닌 것 같지만, 이런 프로젝트가 크게 불어나는 경우를 봤음. 팀 전체가 완성까지 1~2년을 쓰더라도 놀랍지 않음.”
  • 가장 불확실한 추정치는 범위를 제한하고 가능한 한 이른 시점에 유용한 결과를 제공하는 방안을 놓고 활발한 논의로 이어질 가능성이 큼.

불확실성 수준을 붙여 추정치 제시하기

  • 때로는 범위 대신 “내년 3월까지 끝낼 수 있는가?” 같은 질문에 답해야 함.
  • 같은 방법론을 적용해 3월이 추정 범위의 어디에 위치하는지 확인할 수 있음. 단, 기준 시점은 현재가 아니라 작업을 시작하는 시점이어야 함.
  • 상황에 따른 답변의 예시는 다음과 같음.
  • “정말 가능성이 낮음. 비슷한 기능을 만드는 데 더 오래 걸렸음.”
  • “가능성은 있지만 모든 일이 순조롭고 팀 전체가 투입되는 경우에만 해당함. 범위를 줄이는 편이 더 안전함.”
  • “거의 확실히 가능하지만, 확실히 끝내려면 4~5명을 투입하는 편이 좋음.”
  • “가능함. 확실함.”

맺음말

  • 추정은 부정확하고 자주 빗나가지만, 그렇다고 최선을 다해 의사결정자를 도울 수 없는 것은 아님.
  • 추정의 근거를 현실에 두고 불확실성 수준을 솔직하게 전달하면, 아는 것보다 더 많이 안다고 가장하지 않으면서도 유용한 정보를 제공할 수 있음.
  • 목표는 미래를 완벽하게 예측하는 것이 아니라, 주어진 정보로 더 나은 결정을 내리는 것임.