개발자라면 누구나 한 번쯤 겪어봤을 그 순간. “분명히 한 달이면 끝난다고 했잖아요?”라는 클라이언트의 말에, 혹은 “왜 이렇게 늦어지죠?”라는 PM의 물음에 머릿속이 하얗게 변하는 경험. 일정 산출은 개발 프로세스에서 가장 냉혹한 영역이다. 데이터에 따르면, 무려 66%의 소프트웨어 프로젝트가 원래 계획했던 일정을 초과한다. 이건 단순한 삐끗이 아니다. 절반 이상의 프로젝트가 예산과 시간의 늪에서 허우적대는 현실.
하지만 이 지옥에서 탈출하는 방법은 존재한다. 단순한 경험담이 아닌, 시스템과 데이터에 기반한 노하우의 집합체가 바로 그것이다.
더 이상의 ‘감’은 그만: 데이터 기반으로 전환하라
프로젝트 일정을 산출할 때 가장 위험한 단어는 “아마도”와 “대충”이다. 당신의 직감이 아무리 뛰어나도, 과거 데이터를 무시한 추정은 점술에 불과하다.
- 개인 속도(Individual Velocity)를 측정하라: 추정 시간과 실제 소요 시간을 추적하는 습관을 들여라. 추정 시간을 실제 시간으로 나누면 당신만의 ‘속도(Velocity)’ 지표가 나온다. 이 숫자가 1.0에 가까울수록 당신의 추정 능력은 정확하다는 증거다. 데이터가 쌓이면, 더 이상 감으로 일정을 말하지 않아도 된다.
- 역사 데이터베이스는 금고와 같다: 과거 프로젝트의 기능 점수(Function Point)나 라인 수(LOC) 데이터는 미래 일정 산출의 금맥이다. 프로젝트 종료 후, 실제 투입된 인력과 시간을 기록하지 않는다면, 당신은 똑같은 실수를 무한 반복하게 될 것이다. 이러한 데이터는 다음 프로젝트의 견적을 방어할 수 있는 강력한 무기가 되어준다.
추정의 기술: 거시적 안목과 미시적 분해
일정 산출은 마치 양복을 맞추는 것과 같다. 전체적인 핏을 보는 동시에 1mm 단위의 디테일을 놓쳐선 안 된다.
1. WBS: 거대한 덩어리를 쪼개라
프로젝트를 ‘전체’로 바라보는 순간, 추정은 실패한다. 업무 분류 체계(WBS) 를 활용해 프로젝트를 4~16시간 이내의 작은 작업 단위로 분해하라. 한 번에 16시간이 넘어가는 작업 단위는 분해가 덜 된 것이다. 이렇게 쪼개면 놓치기 쉬운 테스트, 문서화, 코드 리뷰 같은 ‘보이지 않는 작업’까지 추정 범위에 포함시킬 수 있다.
2. 확률적 추정: 하나의 숫자는 거짓말이다
“3일 걸립니다”라는 말은 완벽한 거짓말일 확률이 높다. 대신 “낙관적(Optimistic), 일반적(Most Likely), 비관적(Pessimistic)” 세 가지 시나리오를 제시하라. 예를 들어 “버그가 없으면 2일, 평균적으로 3일, 예상치 못한 이슈가 터지면 5일”이라는 식이다. 이를 3점 추정법으로 계산하면 단일 숫자보다 훨씬 현실성 있는 기댓값을 도출할 수 있다.
협업의 기술: 혼자 하지 말고, 전략적으로 협상하라
개발자는 종종 혼자서 모든 일정을 산출하려는 경향이 있다. 하지만 일정 산출은 혼자 하는 수학 문제가 아닌, 모두가 함께 하는 전쟁 게임이다.
- 플래닝 포커(Planning Poker): 팀원 모두가 피보나치 수열 카드를 이용해 각 작업의 크기를 추정한다. 각자 카드를 공개하고 의견이 갈리면 논의한다. 이 과정에서 개인의 낙관론은 팀의 냉철한 시선으로 교정되고, 프론트엔드 개발자가 미처 몰랐던 백엔드의 복잡성을 자연스럽게 공유할 수 있다.
- 추정(Estimate)과 목표(Target)를 분리하라: 여기서 큰 오해가 발생한다. ‘추정’은 특정 기능을 구현하는 데 필요한 시간을 말하는 것이고, ‘목표’는 특정 날짜까지 완성할 기능의 양을 말한다. 클라이언트가 “3주 안에 되죠?”라고 물을 때, “네, 가능합니다”라고 답하는 순간, 당신은 ‘추정’을 버리고 ‘목표’에 동의한 셈이다.
여유(Buffer)의 미학: 10% 룰은 더 이상 통하지 않는다
많은 개발자들이 일정에 10~20%의 버퍼를 추가한다. 하지만 복잡도가 높은 프로젝트에서 10%는 사실상 ‘없는’ 것과 마찬가지다. 여유는 단순히 ‘더하기’가 아니라 ‘전략’이어야 한다.
- 인지적 여유: 점심시간, 피로도, 예상치 못한 인터럽트(급한 버그 수정, 잡담)를 작업 시간에 포함시켜라. 하루 8시간 중 ‘순수 코딩 시간’이 4~5시간을 넘기기 어렵다는 사실을 안다면, 일정 산출도 그에 맞춰져야 한다.
- 기술적 여유: 새로운 기술 도입이나 외부 API 연동이 포함된 작업은 일반 작업 대비 1.5배에서 2배의 시간을 할당하라. 익숙하지 않은 영역에서 발생하는 삽질은 누구도 예측할 수 없다.
당신의 일정을 망치는 3대 적
모든 준비를 마쳤음에도 일정이 무너지는 이유는 명확하다. 바로 아래 세 가지다.
- 스코프 크리프(Scope Creep): “이거 하나만 더 추가하면 안 될까요?”라는 말에 ‘네’라고 대답한 순간, 당신은 일정을 망가뜨리기로 자발적으로 동의한 것이다. 기능 추가는 일정 재산출의 트리거다.
- 파킨슨의 법칙(Parkinson’s Law): 작업은 할당된 시간을 모두 채우기 마련이다. 3일을 주면 3일이 걸린다. 마감을 타이트하게 설정하고, 결과물은 더 빨리 내는 구조를 만들어라.
- 낙관주의 편향(Optimism Bias): 아무리 경� 많은 시니어라도, 자신이 맡은 부분에 대해 ‘잘 될 거야’라는 막연한 기대를 버리기 어렵다. 그렇기에 반드시 제3자(외부 인력이나 다른 팀 리더)의 검토를 거쳐라.
추정 기법 한눈에 보기
| 기법 | 핵심 개념 | 적용 상황 | 난이도 |
|---|---|---|---|
| 델파이 기법 | 전문가 집단의 익명 의견 수렴 및 합의 도출 | 초기 단계, 모호한 요구사항 | 중 |
| 플래닝 포커 | 팀원 전원이 카드로 상대적 복잡도 투표 | 기능 단위가 명확한 애자일 환경 | 하 |
| COCOMO II | 프로젝트 규모(LOC)와 비용동인(Cost Drivers)을 고려한 수식 모델 | 대규모, 엔터프라이즈 프로젝트 | 상 |
| 유추 추정 | 유사한 과거 프로젝트 데이터를 현재에 적용 | 유사 프로젝트 경험이 풍부한 조직 | 중 |
| 기능 점수(FP) | 사용자 관점의 기능 개수와 복잡도를 기준으로 추정 | 기능 기반 명세서 존재 시 | 상 |
일정 산출은 단순한 ‘시간 계산’이 아니다. 이는 프로젝트에 대한 이해도, 팀원에 대한 신뢰, 그리고 미래에 대한 정직함을 요구하는 고도의 기술이다. 당신의 다음 프로젝트는 더 이상 ‘기적’에 의존하지 않는다. 이 노하우를 스타일 가이드 삼아, 데이터라는 최고의 패브릭으로 맞춤 제작된 일정을 제시하라. 그 순간, 당신은 더 이상 일정에 쫓기는 개발자가 아닌, 일정을 컨트롤하는 아키텍트가 되어 있을 것이다.
프로젝트 착수 미팅 때, “일정이 조금 빡빡해 보이시죠? 저희는 일정을 정확하게 지키기 위해 오히려 충분한 시간을 할당하는 전략을 씁니다. 제 추정은 마감이 아닌, 완성도를 위한 약속입니다.”라고 말해보라. 당신의 전문성이 달라 보일 것이다.
