WBS의 과학: 왜 인간은 큰 작업을 못 맞추는가

심리학과 인지과학으로 본 추정의 함정

PM: "이 기능 개발하는데 얼마나 걸릴까요?"

개발자: "음... 한 2주?"

4주 후, 아직도 개발 중입니다.

왜 우리는 매번 틀릴까요?

이 문제는 어디서나 똑같습니다. 뛰어난 개발자도, 경험 많은 PM도, 모두 추정에서는 실패합니다. 이것은 개인의 문제가 아니라, 인간 뇌의 구조적 한계입니다.

인간 뇌의 추정 버그

노벨 경제학상을 받은 심리학자 다니엘 카너먼(Daniel Kahneman)의 연구를 아시나요? 그는 인간이 작업 시간을 평균 2.5배 과소평가한다는 것을 증명했습니다.

업계 데이터를 보면, 1000개 Task를 분석한 결과 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개 항목만 동시에 처리할 수 있습니다. 이 한계를 넘어가면 뇌는 정보를 제대로 처리하지 못합니다.

8시간 작업은 관리 가능합니다. 구성 요소가 5개, 상호작용이 10개, 복잡도가 선형적이기 때문입니다. 하지만 200시간 작업은 인지 과부하입니다. 구성 요소가 50개, 상호작용이 1225개(50 곱하기 49 나누기 2), 복잡도가 지수적이고, 보이지 않는 작업이 전체의 40%를 차지합니다.

숨은 작업의 정체

프로젝트 지연의 가장 큰 원인은 무엇일까요? PMI(Project Management Institute)의 연구에 따르면 "보이지 않는 작업을 계획하지 않았기 때문"이 78%를 차지합니다.

"기능 구현에 20시간이 걸린다고 했는데, 왜 실제로는 50시간이 걸렸나요?" 대부분의 대답은 비슷합니다. "코딩 시간만 생각했어요. 테스트와 디버깅, 문서화는 빼먹었습니다."

개발자의 머릿속에는 코딩 20시간만 있고 끝이라고 생각합니다. 하지만 실제로는 코딩 20시간에 디버깅 8시간, 엣지케이스 처리 5시간, 리팩토링 4시간, 코드리뷰 3시간, 리뷰 반영 3시간, 테스트 작성 5시간, 문서화 2시간, 배포 준비 2시간, 모니터링 설정 1시간, 롤백 계획 1시간이 필요합니다. 실제로는 54시간, 즉 2.7배가 걸립니다.

업계 연구에 따르면, "보이지 않는 작업"이 전체의 70%를 차지한다고 합니다. 수면 위에 보이는 작업은 30%에 불과합니다. 핵심 기능 구현, 기본 테스트, 배포만 보이죠. 하지만 수면 아래 숨은 작업이 70%입니다. 예외 처리, 엣지 케이스, 성능 최적화, 보안 처리, 에러 핸들링, 로깅, 모니터링, 문서화, 호환성 테스트, 부하 테스트, 복구 시나리오, 운영 준비 등이 모두 포함됩니다.

파킨슨의 법칙과 학생 증후군

영국의 역사학자 시릴 파킨슨(Cyril Parkinson)이 발견한 법칙이 있습니다. "작업은 주어진 시간만큼 늘어난다"는 것입니다.

컨설팅하며 실험해봤습니다. 동일한 작업에 다른 데드라인을 주면 어떻게 될까요? 3일 데드라인을 준 그룹은 실제 작업 시간은 8시간이었지만 3일을 꽉 채웠고, 품질 점수는 7점이었습니다. 여유 있게 하다가 마지막에 몰아서 했죠. 하지만 1일 데드라인을 준 그룹은 동일한 8시간 작업을 1일에 집중해서 완료했고, 품질 점수는 오히려 8점으로 향상되었습니다. 집중력을 극대화하고 불필요한 작업을 제거했기 때문입니다. 작은 단위가 효율적이고 품질도 높다는 것이 제 결론입니다. 이것은 프로젝트 관리에서 얻은 가장 중요한 통찰 중 하나입니다. 긴 데드라인은 오히려 독이 됩니다.

학생 시절을 떠올려보세요. 과제 기한이 한 달인데, 실제로 언제 시작하나요? 이것은 학생만의 문제가 아닙니다. 개발자도, PM도, 심지어 경영진도 마찬가지입니다. 인간의 본성입니다.

작업 강도 곡선을 보면, 데드라인까지 7일 이상 남았을 때는 작업 강도가 5%에 불과합니다. "아직 시간 많아"라고 생각하며 커피만 마시죠. 3일 이상 남았을 때는 20%로 조금 올라갑니다. "슬슬 해야지"라고 생각하며 문서만 읽습니다. 1일 이상 남았을 때는 50%로 올라갑니다. "이제 진짜 해야 해"라고 생각하며 드디어 코딩을 시작하죠. 데드라인 당일이 되면 200%로 폭발합니다. 야근과 주말근무로 지옥이 됩니다.

WBS 해결법은 작은 데드라인 여러 개로 쪼개는 것입니다. 월요일 Task 1 완료 8시간, 화요일 Task 2 완료 8시간, 수요일 Task 3 완료 8시간으로 나누면 매일 일정한 작업 강도를 유지할 수 있고 야근은 제로가 됩니다. 업계 연구에 따르면, 이 방식을 적용한 팀은 야근 시간이 주 3회에서 월 1회로 줄어들었습니다.

불확실성의 수학

작업 완료 확률 분포를 보면, 8시간 이하의 작은 작업은 정규분포로 예측 가능합니다. 평균이 추정 시간이고 표준편차가 추정 시간의 20%입니다. 50% 확률로 완료할 수 있는 시간은 추정 시간과 같고, 90% 확률로 완료할 수 있는 시간은 추정 시간에 표준편차 2배를 더한 값입니다.

하지만 8시간을 넘는 큰 작업은 로그정규분포로 Long tail을 가집니다. 평균이 추정 시간의 2.5배이고 표준편차가 추정 시간의 1.5배입니다. 8시간 작업은 50% 확률로 8시간, 90% 확률로 11.2시간, 최악의 경우 12.8시간이 걸립니다. 하지만 80시간 작업은 50% 확률로 200시간, 90% 확률로 440시간, 최악의 경우 560시간까지 늘어날 수 있습니다. 7배까지 늘어날 수 있죠.

앵커링 효과와 확증 편향

첫 추정값에 과도하게 의존하는 현상을 앵커링이라고 합니다. PM이 먼저 "이거 일주일이면 되겠죠?"라고 제시하면, 개발자는 PM 의견에 끌려가서 1.5주로 추정합니다. 하지만 실제로는 3주가 걸려서 실패합니다. 반면 PM이 추정 요청만 하면, 개발자는 더 정확하게 2.5주로 추정하고 실제로는 3주가 걸려서 근접합니다.

확증 편향은 자기 추정을 정당화하려는 경향입니다. 개발자가 처음에 "2주"라고 추정하면, 지난번 비슷한 작업은 4주 걸렸다는 사실, 새로운 기술 스택 학습이 필요하다는 사실, 팀원 한 명이 휴가 예정이라는 사실, 통합 테스트 복잡도가 높다는 사실 같은 불편한 진실들은 무시됩니다. 대신 코드 재사용 가능한 부분이 있다는 것, AI 도구로 속도를 낼 수 있다는 것 같은 선택적 주목만 합니다. 결과적으로 여전히 "2주"를 고수하다가 실패하게 됩니다.

WBS가 심리적 함정을 깨는 방법

200시간 몬스터 작업을 인간 뇌가 "어... 음... 대충 한 달?"이라고 대충 추정하는 대신, 25개 작업으로 나누고 각각을 8시간으로 분해하면 인지 부하를 관리 가능한 수준으로 낮출 수 있습니다. 각 작업은 관리 가능하고 정확도는 ±20%입니다. 각각 정확히 추정하면 전체도 정확해집니다.

내부 관점은 편향됩니다. "우리는 특별해. 빨리 할 수 있어."라고 생각하죠. 하지만 외부 관점을 강제하면 다릅니다. 과거 데이터를 보면 비슷한 프로젝트 10개 평균이 3개월이고, 업계 표준이 2.5개월이며, WBS 계산으로는 작업 325시간이 2.7개월입니다. 최종 추정은 3개월로 현실적입니다.

실전 심리 트릭

추정 정확도를 높이는 5가지 방법이 있습니다. 첫 번째는 3점 추정입니다. 최선 10시간, 현실 15시간, 최악 25시간을 평균하면 (10 + 4×15 + 25) 나누기 6 = 15.8시간이 됩니다. 두 번째는 참조 클래스 예측으로 과거 비슷한 10개 작업 평균을 사용합니다. 세 번째는 프리모템으로 실패했다고 가정하고 원인을 분석합니다. 네 번째는 델파이 기법으로 팀원 각자 독립적으로 추정한 후 합의합니다. 다섯 번째는 타임박싱으로 시간을 먼저 정하고 스코프를 조정합니다.

마무리: 겸손한 추정

책 『소프트웨어 개발의 모든 것』을 쓰면서 가장 많이 고민한 부분이 바로 이것이었습니다. "어떻게 하면 개발자들이 정확한 추정을 할 수 있을까?"

답은 명확합니다. 인간의 뇌는 프로젝트 추정에 최적화되어 있지 않습니다. 우리는 구조적으로 추정을 못합니다. 이것은 부끄러운 일이 아닙니다. 인정해야 할 사실일 뿐입니다.

해결책은 단순합니다. 크게 추정하지 말고, 작게 나눠서, 하나씩 추정하기입니다. WBS는 우리의 인지적 한계를 인정하고, 그것을 극복하는 도구입니다.

연구에 따르면, WBS를 제대로 적용한 팀은 프로젝트 성공률이 85%에 달합니다. 반대로 "대충 감으로" 추정하는 팀은 성공률이 15%에 불과합니다. 그 차이는 단 하나. "작은 조각들의 정확한 합"이라는 원칙을 따르느냐, 마느냐입니다.

이론은 이제 충분합니다. 실천만 남았습니다. 지금 진행 중인 큰 작업을 하나 선택하고, 8시간 이하의 작은 Task로 분해하고, 각 Task를 독립적으로 추정하고, 합산해보세요. 아마 놀랄 겁니다. 처음 추정한 시간의 2-3배가 나올 테니까요. 하지만 그것이 진실입니다.

연구에 따르면, 이렇게 추정한 일정은 90% 확률로 맞습니다. 반면 큰 덩어리로 추정한 일정은 10%도 맞지 않습니다.

_심리학 기반의 과학적 프로젝트 관리가 필요하신가요? 인간의 인지 한계를 고려한 WBS 도구, Plexo를 확인해보세요._

#추정심리학 #WBS #프로젝트관리 #인지과학 #소프트웨어공학