개발자는 왜 항상 일정을 못 맞출까
인간 뇌의 체계적 실패 메커니즘
"이거 얼마나 걸릴 것 같아요?"
"음... 한 3일이면 될 것 같은데요?"
일주일 후에도 아직 개발 중인 상황, 어디서나 똑같습니다.
익숙한 대화죠?
개발자들이 일정을 못 맞추는 건 능력 부족이 아닙니다. 인간의 뇌가 복잡한 작업을 추정할 때 체계적으로 실패하도록 설계되어 있기 때문입니다.
충격적인 통계
Standish Group의 CHAOS 리포트에 따르면 프로젝트 중 정시 완료는 29%, 지연 완료는 52%, 실패나 취소는 19%입니다. 평균 지연율은 89%에 달합니다.
71%의 프로젝트가 일정을 못 맞춥니다.
추정이 실패하는 5가지 이유
첫 번째는 계획 오류(Planning Fallacy)입니다. 노벨상 수상자 대니얼 카너먼이 발견한 인지 편향으로, 우리는 항상 최선의 시나리오만 상상합니다. 버그가 없을 거야, 요구사항이 바뀌지 않을 거야, 아무도 아프지 않을 거야, 서버가 다운되지 않을 거야라고 생각하죠. 현실은 머피의 법칙이 지배합니다.
두 번째는 호프스태터의 법칙입니다. 일은 항상 예상보다 오래 걸리고, 호프스태터의 법칙을 고려해도 그보다 더 지연됩니다. 재귀적 아이러니입니다. 버퍼를 추가해도 실제로는 그보다 더 오래 걸립니다.
세 번째는 앵커링 효과입니다. 처음 들은 숫자에 집착하게 됩니다. PM이 "이거 하루면 되지 않아?"라고 물으면, 개발자는 속으로는 3일이라고 생각하지만 "음... 이틀이면 될 것 같아요"라고 답합니다. 처음 제시된 "하루"가 앵커가 되어 추정을 왜곡합니다.
네 번째는 학생 증후군입니다. 마감일까지 시간이 있으면 미루게 됩니다. 5일 여유가 있을 때 첫 3일은 "아직 시간 많아"라고 하며 다른 일을 하고, 4일째에야 "이제 시작해볼까"라고 생각하다가 5일째에 "헉! 시간이 부족해!"라고 깨닫습니다.
다섯 번째는 90% 증후군입니다. 마지막 10%가 전체의 90%를 차지합니다. 90% 완료는 기본 기능 구현이지만, 나머지 10%는 예외 처리, 테스트, 문서화, 배포, 버그 수정 등이 포함되어 실제로는 엄청난 시간이 필요합니다.
개발자 뇌의 추정 메커니즘
개발자의 뇌는 추정할 때 코딩 시간만 계산합니다. 8시간이라고 생각하지만, 무의식적으로 무시하는 것들이 있습니다. 디버깅은 "버그 안 생길 거야"라고 생각하고 0시간, 테스트는 "나중에..."라고 하며 0시간, 리뷰는 "빨리 통과하겠지"라고 하며 0시간, 문서는 "코드가 문서야"라고 하며 0시간, 회의는 "개발 시간이지"라고 하며 0시간, 배포는 "그냥 올리면 되지"라고 하며 0시간으로 계산합니다. 결과적으로 8시간이라고 추정했지만 실제로는 24시간이 걸립니다.
정확한 추정을 위한 3단계 공식
첫 번째 단계는 작업 분해입니다. "로그인 기능"이라는 40시간짜리 작업 대신, 로그인 UI 2시간, 이메일 검증 1시간, 비밀번호 암호화 2시간, 세션 관리 3시간, API 연동 2시간, 에러 처리 2시간, 테스트 3시간으로 최대 4시간 단위로 쪼갭니다.
두 번째 단계는 3점 추정법(PERT)입니다. 낙관적(모든 게 완벽할 때), 현실적(보통의 경우), 비관적(모든 게 꼬일 때) 세 가지 시나리오를 고려합니다. 예를 들어 로그인 API의 경우 최선 4시간, 현실 8시간, 최악 16시간으로 추정하면 (4 + 32 + 16) / 6 = 8.67시간이 나옵니다.
세 번째 단계는 버퍼 추가입니다. 개발 시간 10일 중 집중 개발 7일(70%), 통합과 디버깅 2일(20%), 예비 버퍼 1일(10%)로 구성합니다.
실전 체크리스트
일정 추정 전에 확인해야 할 사항들입니다. 작업을 4시간 이하로 쪼갰는지, 비개발 시간을 포함했는지(회의, 리뷰, 문서), 테스트 시간을 별도로 계산했는지, 의존성과 대기 시간을 고려했는지, 팀원 휴가나 병가 가능성을 고려했는지, 3점 추정을 적용했는지, 최소 20% 버퍼를 추가했는지 확인하세요.
팀별 추정 개선법
추정 포커는 팀원들이 동시에 추정값을 공개하는 방법입니다. 개발자A는 5일, 개발자B는 3일, 개발자C는 8일이라고 하면 차이가 크므로 토론을 통해 합의를 도출합니다.
실적 기반 보정은 과거 10개 프로젝트를 분석하여 평균 초과율을 계산합니다. 평균 초과율이 1.8배라면, 원래 추정 20일을 36일로 조정하고, 표준편차를 고려하여 30일에서 42일 사이의 범위로 제시합니다.
마무리: 정직한 추정이 모두를 구한다
"3일이면 될 것 같아요"라고 말하기 전에, 잠시 멈추고 생각해보세요. 정말 3일일까요? 아니면 희망사항일까요?
정확한 추정의 비결은 작게 쪼개기, 숨은 작업 찾기, 3점 추정 적용, 버퍼 추가, 과거 데이터 참고입니다.
낙관적 추정은 모두를 불행하게 만듭니다. 차라리 비관적으로 추정하고 일찍 끝내는 게 낫습니다.
정확한 일정 추정과 프로젝트 관리가 필요하신가요? Plexo를 확인해보세요.