예측은 왜 매번 틀리는가?
추정의 실전 함정
『The Mythical Man-Month』 8장은 소프트웨어 일정 예측에 대해 다룹니다.
제목은 "Calling the Shot." 개발자라면 누구나 한 번쯤은 겪어봤을 "일정 산정의 저주"를 다룬 장입니다.
놀라운 것은, 이 책이 1975년에 출간됐음에도 불구하고 오늘날의 개발 현장과 거의 똑같은 문제들이 반복되고 있다는 사실입니다.
브룩스는 다음과 같은 말을 남깁니다.
“모든 작업은 예상보다 두 배는 오래 걸린다.”
그리고 그것은 단지 개발자가 무능하거나 낙관적이어서가 아닙니다.
예측은 본질적으로 불확실한 활동이기 때문입니다.
예측은 왜 틀릴 수밖에 없는가?
브룩스는 다음과 같은 이유로 일정 예측이 어긋난다고 설명합니다.
회의, 문서 작성, 테스트, 운영 등 비개발 업무의 과소평가
병목이나 외부 의존성 고려 부족
업무 자체의 불확실성 (정확히 무엇을 만들어야 할지 명확하지 않음)
인력 투입과 결과물 산출 사이의 비선형 관계
즉, 개발 시간은 단순히 '코딩에 드는 시간'만으로 측정할 수 없으며,
코딩 외의 수많은 활동이 일정에 영향을 미칩니다.
게다가, 일정은 항상 '가장 낙관적인 경우'를 기준으로 잡히는 경향이 있습니다.
브룩스는 이를 다음과 같이 요약합니다:
“현실적인 일정보다는 희망적인 일정을 기준으로 계획이 세워진다.”
이 얼마나 오늘날에도 익숙한 말인가요?!
실무에서의 '6배 원칙'
브룩스는 자신이 사용하던 경험적 일정 추정 방식을 공유합니다. 흥미롭게도 그는 단순히 '코딩 시간에 2~3을 곱하라'는 방식이 아니라, 실제로 개발이 어떤 비율로 이루어지는지를 다음과 같이 제시합니다:
1/3: 기획 및 설계
1/6: 코딩
1/4: 컴포넌트 테스트 및 초기 시스템 테스트
1/4: 전체 시스템 테스트 및 통합
이를 보면, 코딩은 전체 일정의 1/6에 불과합니다.
단지 '코딩이 얼마나 걸릴지'만 계산해 봤자,
전체 일정을 예측하는 데 거의 도움이 되지 않는다는 뜻입니다.
오히려 코딩 외의 활동들이 훨씬 더 많은 시간을 차지하고, 예측이 어려운 영역이기도 하죠.
실무에서 많이 사용하는 방식인 '버퍼 포함 추정(2배)'은 사실 이 비율 구조를 암묵적으로 반영한 것일지도 모릅니다.
일정 산정의 심리적 요인
개발자들이 일정 추정에서 실수하는 이유는 기술적인 것뿐만 아니라, 심리적인 요인도 큽니다.
상사가 기대하는 일정에 맞춰 주려고 함
자신감 과잉 혹은 팀의 압박감
"이번만은 다를 거야"라는 낙관주의
이런 상황에서는 일정 산정이 '객관적인 분석'이 아니라, 조직 내 심리게임이 됩니다. 브룩스는 이를 매우 솔직하게 지적합니다.
“정확한 예측이 불가능한 것이 아니라, 솔직한 예측이 어려운 것이다.”
오늘날에도 유효한 원칙들
현재에도 브룩스의 통찰은 크게 달라지지 않았습니다.
아래는 2020년대에도 여전히 적용되는 몇 가지 원칙입니다.
불확실성을 포함해 추정하라. 버퍼는 약점이 아니라 전략이다.
개발 외 활동을 일정에 포함시켜라. 테스트, 리뷰, 회의, 문서화도 개발이다.
예상 일정의 근거를 명확히 남겨라. 근거 없는 숫자는 언제든 공격받는다.
사후 회고를 통해 예측 정확도를 개선하라. 조직의 학습 곡선을 만든다.
실제로 많은 팀이 '플래닝 포커', 'T-Shirt 사이징', '스프린트 예측 정확도 측정' 등의 기법을 사용해 이 문제를 완화하고 있습니다. 하지만 여전히 핵심은 일정을 맞추는 것보다, 흐름을 예측하고 대응하는 능력입니다.
개발 일정이란 본질적으로 '확실하지 않은 미래를 수치로 표현하는 행위'입니다.
브룩스는 이 어려운 과제를 풀기 위해 단순한 곱셈이 아니라, 작업의 전체 흐름을 이해하라고 조언합니다.
그리고 무엇보다 중요한 메시지는 이것입니다.
"정직한 예측이야말로 좋은 프로젝트의 시작이다."
우리는 여전히 예측을 잘 못합니다. 그러나 그 실패에서 배우는 조직만이 조금씩 정확해질 수 있습니다.
추정은 맞히는 게 목적이 아니라, 함께 나아가기 위한 정렬 도구라는 사실을 잊지 말아야 합니다.
→ 6편: 생산성은 무엇으로 측정해야 하는가? — 코드량의 신화
