추측이 아닌 계산으로 버퍼 정하기
"이 프로젝트 언제 끝날까요?"
"음... 버퍼 20% 넣어서 6주요."
잠깐, 왜 20%인가요?
"그냥... 경험상?"
이제 추측이 아닌 계산으로 버퍼를 정합시다.
프로젝트 버퍼, 어떻게 정하시나요? 대부분 이렇게 합니다. "무조건 30% 추가", "지난번에 늦었으니 50%", "중요한 프로젝트니까 100%", "그냥 느낌상..."
결과는? 너무 적으면 프로젝트 지연, 너무 많으면 자원 낭비와 파킨슨 법칙입니다. 적정선은? 아무도 모릅니다.
리스크를 측정하면 버퍼를 계산할 수 있습니다. 리스크 요소별 가중치를 적용합니다. 신기술 사용은 가중치 3, 팀 경험 부족은 가중치 3, 요구사항 불명확은 가중치 3, 복잡도는 가중치 2, 의존성은 가중치 2, 변경 가능성은 가중치 2입니다.
각 요소를 0-10점으로 평가하여 리스크 점수를 계산합니다. 리스크 비율로 버퍼를 계산하면 10-70% 범위의 버퍼 비율이 나옵니다.
두 프로젝트를 비교해보겠습니다.
고위험 프로젝트인 블록체인 결제 시스템의 경우 기본 추정 60일, 신기술 사용 8점, 팀 경험 없음 9점, 스펙 미완성 7점, 분산 시스템 7점, 외부 API 다수 6점, 자주 바뀜 8점으로 리스크 점수는 67점입니다. 권장 버퍼는 50%(30일), 최종 예상은 90일입니다.
저위험 프로젝트인 관리자 페이지 CRUD의 경우 기본 추정 30일, 익숙한 스택 1점, 경험 풍부 1점, 명확한 스펙 2점, 단순 CRUD 2점, 독립적 1점, 거의 없음 2점으로 리스크 점수는 15점입니다. 권장 버퍼는 15%(5일), 최종 예상은 35일입니다.
똑같이 "경험상 20%"를 넣었다면? 블록체인 프로젝트는 실패하고, CRUD는 자원을 낭비했을 겁니다.
버퍼는 한 번 정하고 끝이 아닙니다. 매일 소비를 추적하고 패턴을 분석해야 합니다.
프로젝트 진행률과 버퍼 소비율을 비교합니다. 버퍼 소비가 진행률보다 1.5배 빠르면 위험 상태로 근본 원인 분석, 스코프 재검토, 자원 추가가 필요합니다. 1.2배 빠르면 주의 상태로 리스크 재평가, 일정 조정 검토가 필요합니다. 그 외에는 정상 상태입니다.
더 정교한 예측을 원한다면 시뮬레이션을 돌려보세요. 1000번 시뮬레이션으로 적정 버퍼를 계산합니다. 각 작업은 최선 케이스와 최악 케이스 사이에서 랜덤하게 선택되고, PERT 분포로 시뮬레이션됩니다. 결과를 분석하여 50% 확률 완료 시간과 90% 확률 완료 시간을 계산하고, 권장 버퍼는 90% 확률 시간에서 50% 확률 시간을 뺀 값입니다.
버퍼가 왜 소비되는지 추적하면 다음 프로젝트를 개선할 수 있습니다. 원인별 버퍼 소비를 집계하여 상위 3개 원인을 파악합니다. 요구사항 변경이 주 원인이면 요구사항 동결이 필요하고, 기술적 이슈가 주 원인이면 기술 검증을 강화해야 합니다.
한 핀테크 회사의 실제 사례입니다.
초기 계획(경험적 버퍼)에서는 예상 3개월 + 20% = 3.6개월이었지만 실제 5.5개월로 실패했습니다.
리스크 분석 후 재계획에서는 PCI 규정 준수 9점, 레거시 연동 8점, 실시간 처리 7점, 보안 경험 부족 8점으로 리스크 점수 72점, 권장 버퍼 55%, 새 예상 4.65개월이었습니다.
결과는 실제 4.5개월로 성공했고, 버퍼 사용은 85%였습니다.
리스크 기반 버퍼가 프로젝트를 구했습니다.
리스크 기반 버퍼 도입 시 리스크 요소 정의(기술, 팀, 요구사항), 각 요소 0-10점 평가, 가중치 적용하여 점수 계산, 버퍼 비율 산출(10-70%), 일일 버퍼 소비 추적, 주간 리스크 재평가, 트리거 포인트 설정, 버퍼 소비 원인 분석, 패턴 기반 개선을 진행합니다.
리스크 기반 버퍼는 "감"이 아닌 "계산"입니다.
불확실성은 제거할 수 없지만, 측정하고 대비할 수는 있습니다.
다음 프로젝트에서 리스크 기반 버퍼를 시도해보세요. 추측이 아닌 데이터로 프로젝트를 관리하는 첫걸음이 될 겁니다.
체계적인 프로젝트 관리가 필요하신가요? Plexo를 확인해보세요.