개발 일정 산정 시 간과되는 3가지 실수
개발 일정 산정, 수많은 프로젝트 실패의 시작점이기도 하죠. 저 역시 일정 추정 하나 잘못해서 팀 분위기, 고객 신뢰, 개인 컨디션까지 무너졌던 경험이 있습니다. 그런데요, 돌이켜보면 그때 저를 실수하게 만든 건 기술적인 지식 부족이 아니라, '보이지 않는 변수들'이었어요. 오늘은 현장 실무자와 PMO 관점에서, 개발 일정 산정 시 많은 사람들이 놓치는 세 가지 핵심 실수를 공유해볼까 합니다. 한번쯤 내가 했던 실수와 비교해보세요.
목차
1. 숨은 작업을 일정에 반영하지 않는다
많은 일정 산정이 ‘기능 구현’ 위주로만 계산되죠. 하지만 실제 개발에선 회의, 설계 검토, 버전 충돌 해결, 코드 리뷰, 테스트 환경 구축 등 눈에 보이지 않는 작업들이 상당한 시간을 차지합니다. 특히 QA 전 준비 작업은 대부분 일정에 반영되지 않고, 결과적으로 일정 초과의 주범이 됩니다. 제가 PMO로 활동했던 한 프로젝트에선 이 숨은 작업만 추려도 전체 일정의 25%를 차지했어요.
2. 인수인계 구간의 지연을 간과한다
“이거 끝났으니 QA에 넘기면 되죠?” 실제론 안 그렇습니다. 개발 → QA, 기획 → 개발 간 인수인계 구간은 늘 텀이 생겨요. 파일 정리, 전달 문서 보완, 테스트 계정 생성 같은 소소한 작업들이 줄줄이 발생하죠. 일정 산정 시 이 구간을 ‘즉시 연결’로 가정하면 반드시 오류가 납니다. 실제 데이터상, SI 프로젝트 기준 인수인계 소요 평균은 1~2일입니다.
3. 사람은 기계가 아니다
일정은 결국 사람이 수행하는 작업입니다. 하지만 산정할 땐 ‘최상의 컨디션’을 기준으로 계산하는 경우가 많아요. 피로도, 컨텍스트 스위칭, 회의 피로, 체력 저하 등은 무시되고, 결과적으로 일정은 틀어집니다. 저는 일정 산정 시 ‘작업 6시간 + 커뮤니케이션 2시간’으로 하루를 계산하길 추천해요. 사람은 하루 8시간 일하지 않아요. 최대 6시간이 집중의 마지노선입니다.
- 개발자 기준 하루 생산 시간: 4~6시간
- 집중력이 분산되는 구간에는 ‘작업 전환 비용’ 고려 필요
실제 사례와 전문가 인용
“개발자의 집중 작업 시간은 하루 평균 5.6시간이며, 그 외 시간은 문서 작업, 회의, 지연 응답 등으로 소진된다.”
— Stack Overflow Developer Survey Report 2023
이 자료처럼, 실제 개발자의 하루 작업 시간은 우리가 계획에서 가정하는 8시간과 거리가 있습니다. 일정이 계획보다 길어지는 이유는 결국, 현실을 과소평가하기 때문입니다. 특히 제가 품질 감리했던 모 게임 플랫폼 프로젝트에선 초기 일정 6개월이었지만, 실제 8개월 이상 소요되었고, 그 중 15%는 ‘비개발 작업’이 차지했어요. 산정 초기에 이 범주를 포함했더라면, 일정 지연 리스크는 훨씬 줄었을 겁니다.
심리학적으로 ‘계획 오류(Planning Fallacy)’가 작용하기 때문입니다.
반드시 별도 일정으로 분리해야 합니다.
작업 성격에 따라 다르지만, 최소 15~20%는 필요합니다.
‘긴 일정은 승인받기 어렵다’는 조직 문화 때문입니다.
과거 프로젝트의 작업 소요시간 데이터를 기반으로 추정해야 합니다.
일정 산정, 단지 숫자 맞추기의 기술이 아닙니다. 그것은 현실을 얼마나 냉정하게 바라보는가에 대한 조직의 태도이자, 리스크를 조율하는 협업의 기술입니다. 숨겨진 작업, 인수 구간, 인간의 한계를 고려하지 않은 일정은 결국 실패할 수밖에 없습니다. 오늘 소개한 세 가지 실수, 이제 여러분 프로젝트에선 반복되지 않길 바랍니다. 일정이 맞을 때, 비로소 모든 것이 흐르기 시작합니다.
일정 산정, 개발 일정, 프로젝트 계획, 일정 오류, 버퍼 시간, QA 일정, PM 실수, WBS, 개발자 작업 시간, 인수인계