소프트웨어 개발 프로젝트의 일정 예측에 대한 의견
소프트웨어 개발 프로젝트 일정 예측은 언제나 골치 아픈 문제입니다.항상 이런 질문을 받습니다. 이 작업은 며칠에 끝나는지, 혹은 지금까지 진척을 비율로 표현하면 얼마인지 같은 것들입니다. 이 질문들에 바로바로 답할 준비가 되어 있다면 대단히 능력 있는 실무자이거나 대단한 프로젝트 매니저일 거라고 생각합니다. 부끄럽지만 저는 저런 질문에 즉시 답할 준비가 되어 있지 않습니다.
실무자로써 어떤 일이 끝나는 대략적인 시점을 말할 수는 있습니다. 이번 주 초, 중, 후반 같은 식으로요. 또 이번 마일스톤 안에 달성할 수 있을 가능성을 높음, 낮음, 위험함 정도로 말할 수 있습니다. 관리자로써 일의 진행을 단계로 나눠 말할 수는 있습니다. 기획서 준비중, 서버, 클라이언트, 툴 개발중, 에셋 제작중, 조립중, QA중 같은 식으로요. 여전히 이게 전체의 몇 퍼센트가 진행된 것인지 답할 수는 없었습니다. 하지만 고위 의사결정자에게 이런 식으로 답하면 보통 나쁜 평가를 받게 됩니다. 75% 정도 개발됐고 다음주 목요일에 개발이 끝난다는 식으로 말할 수 있으면 능력 있는 관리자로 인식되겠지만 제 기준에서 그건 거짓말입니다. 거짓말을 할 수는 없습니다. 만약 거짓말을 하지 않은 결과로 나쁜 평가를 받는다면 이 고위 의사결정자와 함께 일할 수 없다고 봐야 합니다.
소프트웨어 개발 프로젝트의 일정 예측은 쉽지 않습니다. 애초에 요구사항이 불확실한 상태에서 시작해 불확실성을 줄여 가면서 개발을 진행합니다. 요구사항의 불확실성이 줄어들면 각 기능 사이에 상호작용으로 인한 불확실성이 나타납니다. 전통적인 SI 프로젝트에서는 초기에 요구사항을 명확히 하고 개발 도중에 일어날 수 있는 상호작용을 예측해 설계에 반영하기도 한다고 들었습니다. 그래도 예측하지 못한 문제가 나타나 일정 예측을 어렵게 만듭니다. 이런 절차 없이 진행하는 게임 소프트웨어 프로젝트는 예측하지 못한 기능 간 상호작용으로 인한 문제가 더 많이 일어나며 각 문제를 해결하는데 시간이 필요하고 그 결과는 또 다른 상호작용을 만들어냅니다. ‘언제까지 끝난다’는 개념의 일정예측과 잘 맞지 않습니다.
일정 예측을 할 수 없다는 입장은 아닙니다. 소프트웨어 프로젝트도 여느 다른 프로젝트와 같이 시간과 돈이 필요하고 시간과 돈을 통제하기 위해 일정을 예측하지 않을 수 없습니다. 다만 다른 분야에서 경험을 쌓은 사람이 고위 의사결정을 담당할 때 종종 소프트웨어 개발 분야의 특징을 고려하지 않는 일정 예측 요구를 하는 것 같습니다. 가령 작업자 개개인이 자신의 작업 기한을 예측하면 이를 종합해 마감 날짜를 정확하게 계산할 수 있다고 생각하곤 합니다.
이전에 어떤 프로젝트에서는 목표 하나를 완료하는데 필요한 전체 작업을 규격화해 늘어놓고 작업자를 할당한 다음 각 작업자가 자신의 작업 예상일을 입력하게 하고 이에 따라 나머지 작업자의 작업 시작일이 알아서 당겨지거나 밀리는 도구를 사용한 적이 있었습니다. 4월 1일에 기획서 작성을 시작해 4월 3일에 끝나면 그 날부터 5일간 개발하면 4월 9일에는 개발이 끝날 것으로 기대하는 식이었습니다. 당시 고위 의사결정자들은 이 도구를 좋아했는데 자신들이 원하는 방식으로 정보를 얻을 수 있었기 때문인 것 같습니다.
예상할 수 있듯 실제 작업은 마감일에 정확히 종료되지 않았습니다. 각 작업은 작업 진행에 따라 불확실성이 감소하며 추가 작업이 생깁니다. 하지만 마감일은 이를 고려하지 않아 문제가 있음을 파악하고 이를 해결할 방법도 알고 있지만 이를 무시하고 그냥 곧이곧대로 결과만 뽑아내는데 집중하게 만들었습니다. 누군가 기능 간의 상호작용에 의해 발생한 문제를 해결하려고 하면 마감 기한을 어긴 사람이 되기 일쑤였습니다. 전반적으로 품질이 감소하고 각자의 책임감이 사라졌습니다.
각 작업자에게 마감일을 직접 예측하라고 하면 심리적 안정감을 위협 받게 됩니다. 고위 의사결정자가 마감을 준수하지 못할 때 패널티를 주려는 의도가 아니라고 말해도 - 근데 보통 패널티를 주려는 의도 맞음 - 이를 곧이 곧대로 받아들이지 못합니다. 때문에 일정 준수 압력을 받아 초과근무를 강요받거나 일정을 보수적으로 추산하게 됩니다. 각자의 보수적인 일정 추정이 모이면 프로젝트 전체 관점에서는 갑자기 비용이 몇 배 단위로 증가한 것처럼 보이게 되는데 이 상황을 해결하기 위해 일정을 줄이라고 압박해 팀을 심리적으로 무너뜨릴 수도 있습니다.
소프트웨어 프로젝트의 일정 예측은 마감일과 진행률이 날짜 하나와 숫자 하나로 나타나는 모양보다는 날짜와 숫자를 포함한 정규분포에 가까운 모양이라고 생각합니다. 이번주 금요일에 기획서를 마무리 할 작정이라고 누군가 말한다면 이 일정은 금요일을 중심으로 한 정규분포를 따른다고 인식하는 겁니다. 금요일에 끝날 가능성이 높지만 더 일찍 또는 더 늦게 끝날 가능성이 있습니다. 분산에는 위에서 단순하게 설명한 소프트웨어 프로젝트의 복잡성이 추상화 되어 있습니다. 요구사항이 불확실하며 기능 사이에 상호작용으로 인한 문제가 자주 발생하고 구성원 각각이 여러 일을 같은 시간대에 처리하고 있어 한 작업에 완전히 집중하기 어려운 상황 같은 것들을 하나하나 고려하는 대신 단순한 모양으로 고려할 수 있습니다
이 모양의 문제는 고위 의사결정자들이 이해하기에는 직관적이지 않다는 점입니다. 하지만 고위 의사결정자들의 요구 대로 진행률과 날짜로 의사소통 하는 것은 거짓말이라고 생각합니다. 관리자의 역할이 중간에서 거짓 보고를 하고 실제 진행상황과 거짓말 사이의 간극을 줄이는 거라면 올바르지 않습니다.
