노력 추정 정확도 높이기

3시간이 3주가 되는 이유와 해법

"금요일까지 끝낼 수 있을 것 같아요"

"이 기능 구현하는데 얼마나 걸릴까요?"
"음... 한 3일이면 충분할 것 같습니다."

2주 후, 그 개발자는 여전히 같은 기능과 씨름하고 있습니다.

처음엔 정말 3일이면 될 것 같았습니다. 코드 몇 줄 추가하면 끝날 것 같았는데, 테스트를 작성하다 보니 엣지 케이스가 나왔고, 리뷰에서 구조 변경 요청이 들어왔고, 배포 과정에서 호환성 문제가 발견됐습니다.

"왜 이렇게 오래 걸리지?" 하며 당황합니다. 처음엔 간단해 보였던 작업인데, 막상 진행하니 예상치 못한 문제들이 줄줄이 나타납니다.

Microsoft 연구에 따르면, 개발자들의 작업 추정은 평균적으로 실제 시간의 30%에 불과합니다. 3일 예상이 10일 걸리는 건 예외가 아니라 규칙입니다. 더 충격적인 건, 경력이 많은 개발자일수록 추정 정확도가 떨어진다는 사실입니다.

왜일까요? 그들은 더 많은 "만약"을 알기 때문입니다.

추정이 틀리는 5가지 과학적 이유

첫 번째는 계획 오류입니다. 스탠포드 대학의 뇌 스캔 연구가 흥미롭습니다. 개발자가 추정할 때 활성화되는 뇌 영역은 "희망"과 "낙관"을 담당하는 부분입니다. 우리는 무의식적으로 최선의 시나리오만 상상합니다. 3일 추정이 실제로는 7.5일이 걸리는 이유가 바로 이것입니다.

두 번째는 앵커링 효과입니다. "대충 일주일?" 누군가 먼저 던진 숫자에 우리의 추정이 끌려갑니다. PM이 "3일이면 되겠지?"라고 물으면, 실제로는 10일 걸릴 작업도 "5일이면..."이라고 답하게 됩니다. 첫 번째 숫자가 닻(anchor)이 되어 판단을 왜곡시킵니다.

세 번째는 더닝-크루거 효과입니다. 아는 것이 적을수록 자신감은 넘칩니다. "React? 써봤죠. 3일이면 충분해요"라고 말하는 개발자가 React 경험 1개월인 반면, "React로요? 음... 일주일은 필요할 것 같은데요"라고 말하는 개발자는 React 경험 3년입니다. 경험이 많을수록 모르는 것이 많다는 걸 알기에 보수적으로 추정합니다.

네 번째는 호프스태터의 법칙입니다. "호프스태터의 법칙을 고려하더라도 예상보다 오래 걸린다"는 재귀적 법칙이 무서운 이유는, 버퍼를 추가해도 여전히 부족하다는 점입니다. 30% 버퍼를 추가했는데도 지연되는 이유가 바로 이것입니다.

다섯 번째는 파킨슨의 법칙입니다. "일은 주어진 시간만큼 늘어난다"는 법칙입니다. 3일 작업에 일주일을 주면, 정말로 일주일이 걸립니다. 시간이 남으면 "더 완벽하게" 만들려고 하기 때문입니다.

추정 정확도를 높이는 실전 기법

첫 번째는 3점 추정 기법입니다. 하나의 숫자 대신 세 가지 시나리오를 추정합니다. 낙관적인 경우 모든 것이 완벽할 때 2일, 현실적인 경우 일반적인 상황에서 5일, 비관적인 경우 최악의 상황에서 12일이라고 하면, PERT 추정은 5.7일이고 표준편차는 1.7일입니다. 따라서 "5.7일 ± 1.7일"로 추정합니다.

두 번째는 참조 클래스 예측입니다. 비슷한 과거 작업들의 실제 소요 시간을 참조합니다. 로그인 API는 초기 추정 3일에서 실제 8일로 2.67배, 회원가입 API는 5일에서 12일로 2.40배, 비밀번호 재설정은 2일에서 6일로 3.00배 걸렸다고 하면, 평균 2.69배입니다. 새 작업 추정이 4일이면 4일 × 2.69 = 10.76일로 추정합니다.

세 번째는 작업 분해 후 재조합입니다. 큰 작업을 작은 단위로 쪼개면 정확도가 올라갑니다. "사용자 관리 시스템"을 2주로 추정했다면, DB 스키마 설계 4시간, API 엔드포인트 8시간, 인증/인가 로직 12시간, 프론트엔드 폼 6시간, 유효성 검증 4시간, 테스트 작성 8시간, 문서화 4시간, 코드 리뷰 및 수정 6시간, 배포 및 모니터링 4시간으로 분해하면 총 56시간, 즉 7일로 계산됩니다. 큰 덩어리로 추정할 때보다 30-40% 더 정확합니다.

네 번째는 플래닝 포커입니다. 팀원들이 동시에 추정하여 앵커링 효과를 제거합니다. 모두가 카드를 뒤집어 놓고 추정한 다음 동시에 공개하고, 최소/최대 추정자가 이유를 설명한 후 재추정하고 합의를 도출합니다. 이 방식으로 개인 편향을 50% 이상 줄일 수 있습니다.

다섯 번째는 속도 기반 추정입니다. 팀의 과거 속도를 기준으로 추정합니다. 지난 5개 스프린트 평균 속도가 45 포인트이고 이번 스프린트 계획이 50 포인트라면, 예상 완료율은 90%입니다.

여섯 번째는 불확실성 콘 활용입니다. 프로젝트 초기일수록 불확실성이 큽니다. 초기 구상 단계는 0.25배에서 4배 범위, 요구사항 정의 단계는 0.5배에서 2배, 설계 완료 단계는 0.75배에서 1.5배, 구현 중 단계는 0.9배에서 1.1배 범위로 추정합니다. 초기에는 범위로, 후기에는 점 추정으로 전환합니다.

추정 개선을 위한 체크리스트

작업 시작 전에는 유사한 과거 작업 3개 이상을 참조하고, 작업을 8시간 이하 단위로 분해하며, 테스트, 문서화, 배포를 포함하고, 코드 리뷰와 수정 시간을 고려하고, 의존성과 대기 시간을 포함해야 합니다.

추정 시에는 3점 추정(낙관/현실/비관)을 하고, 팀원들과 함께 추정하며, 불확실성을 수치화하고, 과거 추정 정확도를 반영해야 합니다.

작업 완료 후에는 실제 소요 시간을 기록하고, 추정 오차의 원인을 분석하며, 개선 사항을 문서화하고, 다음 추정에 반영할 교훈을 정리해야 합니다.

핵심 정리

"모든 추정은 틀렸다. 일부는 유용할 뿐이다"

추정의 목표는 정확한 숫자를 맞추는 것이 아닙니다. 합리적인 기대치를 설정하고, 리스크를 관리하며, 더 나은 의사결정을 하는 것입니다.

3시간이 3주가 되는 것을 막을 수는 없습니다. 하지만 그것이 일어날 가능성을 미리 알고 대비할 수는 있습니다. 추정은 약속이 아니라 가설입니다. 계속 검증하고 개선해 나가야 합니다. 오늘 소개한 기법들을 하나씩 적용해보세요. 완벽하지는 않아도, 확실히 나아질 것입니다.

정확한 프로젝트 추정과 일정 관리가 필요하신가요? Plexo를 확인해보세요.