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