PM: "이 기능 개발하는데 얼마나 걸릴까요?"
개발자: "음... 한 2주?"
(4주 후, 아직도 개발 중)
왜 우리는 매번 틀릴까요?
이 문제는 어디서나 똑같습니다. 뛰어난 개발자도, 경험 많은 PM도, 모두 추정에서는 실패합니다.
이것은 개인의 문제가 아니라, 인간 뇌의 구조적 한계입니다.
인간 뇌의 추정 버그
기획 오류 (Planning Fallacy)
노벨 경제학상을 받은 심리학자 다니엘 카너먼(Daniel Kahneman)의 연구를 아시나요?
그는 인간이 작업 시간을 평균 2.5배 과소평가한다는 것을 증명했습니다.
# 업계 데이터 (1000개 Task 분석 결과)
estimation_accuracy = {
"1시간 작업": {
"예상": 1,
"실제": 1.2,
"오차": "20%" # 허용 범위
},
"8시간 작업": {
"예상": 8,
"실제": 12,
"오차": "50%" # 조금 불안
},
"40시간 작업": {
"예상": 40,
"실제": 100,
"오차": "150%" # 😱 심각
},
"200시간 프로젝트": {
"예상": 200,
"실제": 500,
"오차": "250%" # 🔥 재앙
}
}
# 패턴: 작업이 클수록 오차가 기하급수적으로 증가
왜 큰 작업은 예측이 어려울까?
심리학자 조지 밀러(George Miller)의 유명한 논문 "The Magical Number Seven, Plus or Minus Two"를 기억하시나요?
인간의 단기 기억은 7±2개 항목만 동시에 처리할 수 있습니다. 이 한계를 넘어가면 뇌는 정보를 제대로 처리하지 못합니다.
// 인간의 인지 한계
const cognitive_limits = {
working_memory: '7±2개', // 밀러의 법칙
// 8시간 작업 = 관리 가능
small_task: {
components: 5,
interactions: 10,
complexity: '선형',
},
// 200시간 작업 = 인지 과부하
large_task: {
components: 50,
interactions: 1225, // 50 * 49 / 2
complexity: '지수적',
hidden_work: '전체의 40%', // 보이지 않는 작업
},
};
숨은 작업의 정체
개발자가 잊어버리는 것들
프로젝트 지연의 가장 큰 원인은 무엇일까요?
PMI(Project Management Institute)의 연구에 따르면:
"보이지 않는 작업을 계획하지 않았기 때문" (78%)
"기능 구현에 20시간이 걸린다고 했는데, 왜 실제로는 50시간이 걸렸나요?"
대부분의 대답은 비슷합니다. "코딩 시간만 생각했어요. 테스트와 디버깅, 문서화는 빼먹었습니다."
# 개발자의 머릿속 (잘못된 추정)
developer_estimate = {
"코딩": 20, # 시간
"끝": "완료!" # ← 착각!
}
# 실제로 필요한 작업 (업계 연구 데이터)
real_work = {
"코딩": 20,
"디버깅": 8, # 항상 발생
"엣지케이스": 5, # 생각보다 많음
"리팩토링": 4, # 초기 코드는 항상 개선 필요
"코드리뷰": 3, # 팀 문화에 따라
"리뷰 반영": 3, # 1번에 통과? 불가능
"테스트 작성": 5, # TDD 아니면 나중에
"문서화": 2, # README, API 문서
"배포 준비": 2, # 환경 설정, 빌드
"모니터링 설정": 1, # 로깅, 알림
"롤백 계획": 1 # 최악의 경우 대비
}
# 실제: 54시간 (2.7배!)
업계 연구에 따르면, "보이지 않는 작업"이 전체의 70%를 차지한다고 합니다.
빙산 모델
수면 위 (보이는 작업) 30%
├── 핵심 기능 구현
├── 기본 테스트
└── 배포
수면 아래 (숨은 작업) 70%
├── 예외 처리
├── 엣지 케이스
├── 성능 최적화
├── 보안 처리
├── 에러 핸들링
├── 로깅
├── 모니터링
├── 문서화
├── 호환성 테스트
├── 부하 테스트
├── 복구 시나리오
└── 운영 준비
파킨슨의 법칙과 학생 증후군
파킨슨의 법칙
영국의 역사학자 시릴 파킨슨(Cyril Parkinson)이 발견한 법칙입니다.
"작업은 주어진 시간만큼 늘어난다"
컨설팅하며 실험해봤습니다. 동일한 작업에 다른 데드라인을 주면 어떻게 될까?
// 실험 결과 (실제로 수행한 A/B 테스트)
const experiment = {
group_A: {
deadline: '3일',
actual_work: '8시간', // 실제 작업 시간
total_time: '3일', // 하지만 3일 꽉 채움
quality: 7, // 품질 점수
notes: '여유 있게 하다가 마지막에 몰아서',
},
group_B: {
deadline: '1일',
actual_work: '8시간', // 동일한 작업
total_time: '1일', // 집중해서 완료
quality: 8, // 오히려 품질 향상!
notes: '집중력 극대화, 불필요한 작업 제거',
},
};
// 저의 결론: 작은 단위가 효율적이고 품질도 높다
이것은 프로젝트 관리에서 얻은 가장 중요한 통찰 중 하나입니다. 긴 데드라인은 오히려 독이 됩니다.
학생 증후군
학생 시절을 떠올려보세요. 과제 기한이 한 달인데, 실제로 언제 시작하나요?
이것은 학생만의 문제가 아닙니다. 개발자도, PM도, 심지어 경영진도 마찬가지입니다. 인간의 본성입니다.
def work_intensity(days_until_deadline):
"""작업 강도 곡선 (심리학 연구 데이터)"""
if days_until_deadline > 7:
return "5%" # "아직 시간 많아" → 커피만 마심
elif days_until_deadline > 3:
return "20%" # "슬슬 해야지" → 문서만 읽음
elif days_until_deadline > 1:
return "50%" # "이제 진짜 해야 해" → 드디어 코딩 시작
else:
return "200%" # "야근 + 주말근무" → 지옥
# WBS 해결법: 작은 데드라인 여러 개로 쪼개기
# 월요일: Task 1 완료 (8h)
# 화요일: Task 2 완료 (8h)
# 수요일: Task 3 완료 (8h)
# = 매일 일정한 작업 강도 유지, 야근 제로
업계 연구에 따르면, 이 방식을 적용한 팀은 야근 시간이 주 3회에서 월 1회로 줄어들었습니다.
불확실성의 수학
확률 분포로 보는 추정
import numpy as np
def task_completion_probability(estimated_hours):
"""작업 완료 확률 분포"""
if estimated_hours <= 8:
# 작은 작업: 정규분포 (예측 가능)
mean = estimated_hours
std = estimated_hours * 0.2
else:
# 큰 작업: 로그정규분포 (Long tail)
mean = estimated_hours * 2.5 # 평균 2.5배
std = estimated_hours * 1.5
return {
"50%_확률": mean,
"90%_확률": mean + 2*std,
"worst_case": mean + 3*std
}
# 예시
small_task = task_completion_probability(8)
# {'50%_확률': 8, '90%_확률': 11.2, 'worst_case': 12.8}
large_task = task_completion_probability(80)
# {'50%_확률': 200, '90%_확률': 440, 'worst_case': 560}
# 7배까지 늘어날 수 있음!
앵커링 효과와 확증 편향
앵커링 (Anchoring)
첫 추정값에 과도하게 의존하는 현상
// 실험: PM이 먼저 추정값을 제시할 때
const anchoring_effect = {
// PM: "이거 일주일이면 되겠죠?"
scenario_1: {
pm_suggestion: '1주',
developer_estimate: '1.5주', // PM 의견에 끌려감
actual_time: '3주', // 실패!
},
// PM: 추정 요청만
scenario_2: {
pm_suggestion: null,
developer_estimate: '2.5주', // 더 정확
actual_time: '3주', // 근접!
},
};
확증 편향
자기 추정을 정당화하려는 경향
# 개발자의 마음
initial_estimate = "2주"
# 불편한 진실들 (무시됨)
ignored_facts = [
"지난번 비슷한 작업은 4주 걸렸음",
"새로운 기술 스택 학습 필요",
"팀원 한 명 휴가 예정",
"통합 테스트 복잡도 높음"
]
# 선택적 주목
selective_attention = [
"코드 재사용 가능한 부분 있음",
"AI 도구로 속도 낼 수 있음"
]
# 결과: 여전히 "2주" 고수 → 실패
WBS가 심리적 함정을 깨는 방법
청킹 (Chunking) 전략
def break_cognitive_load(big_task):
"""인지 부하를 관리 가능한 수준으로"""
# Before: 200시간 몬스터 작업
# 인간 뇌: "어... 음... 대충 한 달?"
# After: 25개 x 8시간 작업
chunks = []
for i in range(25):
chunk = {
"id": f"Task {i+1}",
"hours": 8,
"complexity": "관리 가능",
"accuracy": "±20%"
}
chunks.append(chunk)
# 각각 정확히 추정 → 전체도 정확
return chunks
외부 관점 강제
// 내부 관점 (편향됨)
const internal_view = '우리는 특별해. 빨리 할 수 있어.';
// 외부 관점 (WBS 강제)
const external_view = {
historical_data: '비슷한 프로젝트 10개 평균: 3개월',
industry_benchmark: '업계 표준: 2.5개월',
wbs_calculation: '작업 325시간 = 2.7개월',
final_estimate: '3개월', // 현실적!
};
실전 심리 트릭
추정 정확도 높이는 5가지 방법
techniques = {
"1. 3점 추정": {
"optimistic": 10, # 최선
"realistic": 15, # 현실
"pessimistic": 25, # 최악
"final": (10 + 4*15 + 25) / 6 # 15.8시간
},
"2. 참조 클래스 예측":
"과거 비슷한 10개 작업 평균 사용",
"3. 프리모템":
"실패했다고 가정하고 원인 분석",
"4. 델파이 기법":
"팀원 각자 독립적으로 추정 후 합의",
"5. 타임박싱":
"시간을 먼저 정하고 스코프 조정"
}
마무리: 겸손한 추정
책 『소프트웨어 개발의 모든 것』을 쓰면서 가장 많이 고민한 부분이 바로 이것이었습니다.
"어떻게 하면 개발자들이 정확한 추정을 할 수 있을까?"
답은 명확합니다.
인간의 뇌는 프로젝트 추정에 최적화되어 있지 않습니다. 우리는 구조적으로 추정을 못합니다. 이것은 부끄러운 일이 아닙니다. 인정해야 할 사실일 뿐입니다.
해결책은 단순합니다
- 크게 추정하지 말고
- 작게 나눠서
- 하나씩 추정하기
WBS는 우리의 인지적 한계를 인정하고, 그것을 극복하는 도구입니다.
연구에 따르면, WBS를 제대로 적용한 팀은 프로젝트 성공률이 85%에 달합니다. 반대로 "대충 감으로" 추정하는 팀은 성공률이 15%에 불과합니다.
그 차이는 단 하나. "작은 조각들의 정확한 합*이라는 원칙을 따르느냐, 마느냐입니다.
오늘부터 시작하세요
이론은 이제 충분합니다. 실천만 남았습니다.
- 지금 진행 중인 큰 작업을 하나 선택하세요
- 8시간 이하의 작은 Task로 분해하세요
- 각 Task를 독립적으로 추정하세요
- 합산해보세요
아마 놀랄 겁니다. 처음 추정한 시간의 2-3배가 나올 테니까요. 하지만 그것이 진실입니다.
연구에 따르면, 이렇게 추정한 일정은 90% 확률로 맞습니다. 반면 큰 덩어리로 추정한 일정은 10%도 맞지 않습니다.
심리학 기반의 과학적 프로젝트 관리가 필요하신가요? 인간의 인지 한계를 고려한 WBS 도구, Plexo를 확인해보세요.
#추정심리학 #WBS #프로젝트관리 #인지과학 #소프트웨어공학
댓글 없음:
댓글 쓰기