추정은 왜 실패하는가 (그리고 왜 여전히 필요한가)

(leadership.garden)

7P by GN⁺ 20시간전 | ★ favorite | 댓글과 토론

소프트웨어 개발에서 작업 추정은 복잡계(Complex) 영역에 속하며, 아무리 숙련된 팀이라도 본질적으로 정확한 추정이 불가능함
#NoEstimates 운동은 추정이 성과 목표로 오용되는 현실에 대한 정당한 반발이었지만, 추정 자체를 거부하면 조직의 조율 능력이 사라짐
추정의 핵심 가치는 미래 예측이 아니라 불확실성 하에서의 의사소통과 조율이며, 외부 계약·팀 간 의존성·ROI 판단에 필수적
Steve McConnell의 불확실성 원뿔(Cone of Uncertainty) 에 따르면 프로젝트 초기에는 추정 오차가 4배까지 발생하며, 학습을 통해서만 범위가 좁아짐
추정을 약속으로 전환하는 조직적 습관을 바꾸고, 범위 기반·가정 명시·점진적 보정의 추정 방식을 채택해야 함

#NoEstimates 운동이 실제로 해결한 문제

팀이 문제에 대해 거의 아는 것이 없는 상태에서 추정을 요청받고, 그 숫자가 로드맵에 반영되어 고객에게 약속되는 패턴이 반복됨
현실이 추정과 괴리되면 팀이 "데드라인을 놓쳤다"는 비난을 받지만, 애초에 합의한 데드라인이 아니었음
추정이 예측이 아닌 약속(commitment) 으로 변질되는 것이 핵심 병리 현상
"추정하지 말자"는 해법은 고장 난 온도계에 대한 반응으로 온도라는 개념 자체를 부정하는 것과 같음
Maarten Dalmijn의 표현처럼, 추정은 실제 작업량을 바꾸지 않으며 기능 개발은 걸리는 만큼 걸림
- 추정이 영향을 미치는 것은 작업 자체가 아니라 그 주변의 기대치(expectations)
- 기대치를 정직하고 명확하게 관리하는 것은 충분히 할 가치가 있는 업무

조직이 실제로 추정을 필요로 하는 이유

#NoEstimates 논의에서 거의 빠지는 점: 추정은 작업을 수행하는 팀이 아니라 그 주변 조직을 위한 것
추정이 불가피한 세 가지 상황 존재
외부 약속(External commitments): 고객 계약, 마케팅 캠페인 연동 출시, 규제 데드라인 등에서 실현 가능성 판단에 작업 소요 시간 모델이 필수
- "우리는 추정하지 않습니다"는 고객에게 줄 수 있는 답이 아니며, 계약 종료로 이어질 수 있음
팀 간 의존성(Inter-team dependencies): 팀 B가 팀 A의 완료를 기다려야 할 때, 팀 A가 어떤 예측도 제공하지 않으면 팀 B는 계획 불가
- 대략적 신호("아마 6주, 최대 8주")가 침묵보다 무한히 유용하며, 이는 통제가 아니라 하류 팀 구성원에 대한 존중
ROI 계산: 기능 X와 기능 Y 중 무엇을 만들지 결정하려면 상대적 비용 모델이 필요
- 모든 것이 불가지라면 합리적 트레이드오프 불가능하고, 어차피 추측할 거라면 명시적 가정이 붙은 구조화된 추측이 나음

Joseph Pelrine이 보여준 추정의 본질적 어려움

Joseph Pelrine은 유럽 최초의 Certified Scrum Trainer로, 사회적 복잡성 과학 렌즈를 통해 소프트웨어 애자일을 연구
애자일 소프트웨어 개발에 종사하는 300명 이상을 대상으로 일상 업무 활동을 Cynefin 프레임워크(Dave Snowden의 센스메이킹 모델)의 영역에 배치하는 실험 수행
- Cynefin은 문제를 Clear, Complicated, Complex, Chaotic 네 영역으로 분류
작업 추정은 일관되고 반복적으로 Complex 영역에 배치됨
Complicated와 Complex의 차이가 핵심:
- Complicated 영역에서는 인과관계가 파악 가능하며, 전문가가 추적할 수 있고 전문 지식이 신뢰할 수 있는 예측 생성
- Complex 영역에서는 인과관계가 사후에만 파악 가능하며, 시스템이 너무 얽혀 있고 맥락 의존적이며 작은 변화에 민감
소프트웨어 개발이 제조업이 아닌 이유: 거의 항상 이전에 존재하지 않았던 것을 고유한 코드베이스 위에서 고유한 팀 역학으로 구축
- 목수 비유가 작동하지 않는 이유: 캐비닛은 다른 캐비닛과 대략 비슷하지만, 기능은 다른 기능과 대략 비슷하지 않음
뛰어난 팀도 평범한 수준의 추정만 가능하며, 이는 기술 부족이 아니라 Complex 영역에서의 정확도에 본질적 한계가 있기 때문
목표는 추정을 맞추는 것이 아니라 본질적 부정확성에도 불구하고 유용한 결정을 내리는 것

불확실성 원뿔(Cone of Uncertainty)이 말해주는 것

Steve McConnell의 불확실성 원뿔 개념: 프로젝트 초기에 추정 오차가 양방향으로 4배(총 16배 범위)까지 발생 가능
프로젝트가 진행되며 미지의 요소가 해결되면(요구사항 명확화, 아키텍처 확정, 어려운 문제 발견·해결) 원뿔이 좁아짐
아이러니: 추정이 가장 정확해지는 시점은 완료 직전이며, 그때는 추정이 가장 덜 필요한 시점
- 가장 유용할 초기(아직 방향 전환이나 프로젝트 중단이 가능한 때)에 가장 적게 앎
- 대부분의 조직이 바로 그 초기 시점에 가장 확고한 약속을 함
두 가지 추가 시사점:
- 원뿔은 숙련된 추정자의 최상의 경우를 나타내며, 대부분의 팀은 이보다 못함
- 초기 컨셉 단계에서 날짜를 확정하는 것은 계획이 아니라 소원을 빌고 그에 맞춰 일정을 잡는 것
- 원뿔은 시간이 아니라 불확실성을 제거하는 결정에 의해서만 좁아짐
- 스코프 정의, 아키텍처 미지 해결, 실제 코드 작성과 난점 발견이 원뿔을 좁히며, 3주간 회의만 하는 것은 좁히지 못함
이해관계자에게 "추정의 품질은 원뿔에서 우리가 어디에 있는지에 달려 있다"고 명시적으로 전달해야 함
- 1주차에 2주짜리 숫자를 줄 수 없지만, 범위를 주고 좁히기 위해 무엇이 확인되어야 하는지 설명 가능
- 대부분의 이해관계자는 원뿔을 설명하면 수용하며, 범위를 요청해도 된다는 것을 아무도 알려주지 않았을 뿐

피보나치 스케일을 사용하는 이유

피보나치 스케일(1, 2, 3, 5, 8, 13, 21)의 비선형성이 인식론적 작업을 수행
2와 3의 차이는 "대략적 차이 감지" 수준이지만, 8에서 13으로의 점프는 불확실성 대역이 추정값 자체보다 넓다는 것을 인코딩
- 13포인트 스토리는 "정확히 13"이 아니라 "8보다 확실히 불확실하고 21만큼은 아닌 범주"를 의미
피보나치 수 사이의 간격이 복잡성이 실제로 확장되는 방식을 반영
- 작은 것은 대략 추정 가능, 큰 것은 미지 요소·통합 지점·예상치 못한 상황이 많아 기하급수적으로 예측 어려움
- 21(또는 13) 이상의 스토리는 "아직 작업을 이해하지 못했으므로 분할해야 한다"는 의미
피보나치 추정의 또 다른 과소평가된 기능: 추정 대화 중에 일어나는 일
- 한 사람이 3, 다른 사람이 13을 말하면 숫자 자체는 거의 무관하고, 같은 팀이 같은 스토리를 왜 그렇게 다르게 봤는지가 중요
- 한쪽이 의존성을 발견했거나, 티켓에 없는 기술적 제약을 알고 있었을 수 있음
추정의 가장 큰 가치는 숫자가 아니라 공통 이해가 형성되었는지 확인하는 것
- 이 강제 장치를 제거하면 공유된 이해가 누군가가 작업 3일차에 숨겨진 복잡성을 만날 때까지 형성되지 않는 경우가 많음
"추정 회의가 낭비"라는 #NoEstimates 주장에 동의하기 어려운 이유: 잘 운영하면 그 대화에서 정렬(alignment) 이 이루어짐
- 잘못 운영되는 회의에 대한 답은 회의를 취소하는 것이 아님

약속의 함정(Commitment Trap)과 회피 방법

#NoEstimates 운동이 반응한 가장 깊은 역기능: 추정이 논리가 아닌 사회적 압력을 통해 약속으로 변환
관련 실패 모드: 작업을 수행하지 않는 사람들이 타임라인을 만들어 팀에 던지면 부정확한 추정 + 숫자에 대한 주인 의식 없는 팀이라는 최악의 조합 발생
- 현실이 괴리되면 누구 책임인지 모르므로 모두가 모두를 탓함
- 작업을 실행하는 사람들이 항상 추정을 소유해야 하며, 타인에게 추정을 부과하는 것은 낙관이 아니라 비난 게임의 전조
데드라인 집착이 자리 잡으면 모든 대화가 "어떻게 데드라인을 맞출까?"로 수렴하고, 올바른 것을 만들고 있는지의 질문이 시야에서 사라짐
대부분의 조직이 혼동하는 세 가지를 분리해야 함:
1. 추정(Estimate): 현재 불확실성 수준에서의 확률적 예측, 범위와 가정의 명시적 진술 동반 필요
  - 예: "요구사항 변경 없고 다음 금요일까지 API 질문에 답을 받는다는 전제하에 4~6주로 봄"
2. 계획(Plan): 결과가 아닌 프로세스에 대한 약속
  - 예: "2주간 작업 후 진행 상황을 검토하고 업데이트된 예측을 제공"
3. 약속(Commitment): 결과가 따르는 약속, 드물고 신중하게 원뿔이 충분히 좁아졌을 때만 해야 함
  - 초기 컨셉 단계에서의 약속은 대담함이 아니라 무모함
  - 약속을 강요받을 때 타임라인이 아닌 우선순위에 대한 약속을 시도하고, 그것도 안 되면 신뢰도 수준을 약속의 일부로 포함
추정을 발화 즉시 약속으로 취급하는 조직 관행이 역기능의 근원
- #NoEstimates의 정치적 해법(숫자를 아예 말하지 않기)은 이해하지만, 그 비용으로 조직이 자원 배분·의존성 순서·외부 이해관계자와의 정직한 대화 능력을 상실
더 나은 해법은 원뿔을 가르치고, 이해관계자를 교육하고, 숫자를 줄 때마다 추정과 약속의 구분을 명시하는 것
- 추정 거부보다 어렵고 시간이 더 걸리지만, 신뢰가 깨질 수 있는 상황을 회피하는 대신 신뢰를 구축

좋은 추정 실천 방법

늦게 추정하기: 원뿔은 학습을 통해서만 좁아지므로, 스파이크 수행·탐색적 코드 작성·통합 대상 팀과의 대화를 먼저 진행
- 의미 있는 숫자를 만들 학습 이전에 숫자를 내라는 압력에 저항해야 함
시작 전 과도한 분해 금지: 불확실성에 직면하면 작업을 더 작은 조각으로 쪼개고 싶어지지만, 충분한 분해가 신뢰할 수 있는 추정을 만들어주지 않음
- 정교한 사전 계획은 경직화되어 현실을 반영하지 못하는 시점이 지나도 팀이 매달리게 만들고, 결국 괴리가 더 혼란스러워짐
- 조정하기 쉬운 단순한 계획으로 시작해야 함
점 추정이 아닌 범위 제공: "3~5주"가 "4주"보다 정직하면서도 거의 동일한 수준으로 실행 가능
- 단일 숫자만 가능하다고 하면 범위의 중간값을 주되, 중간값임을 고지
- 이해관계자와 불확실성 원뿔 사용에 합의하고 추정 전달 시마다 참조
가정을 가시화: 추정은 가정만큼만 좋으므로, 스코프 변경 없음 전제·특정 기술적 접근 전제·다른 팀의 특정 날짜 인도 전제 등을 명시
- 머릿속에만 있는 가정은 최악의 순간에 표면화되는 오해가 됨
정확도를 추적하되 처벌 금지: 비난이 아니라 보정(calibration) 목적
- 6개월간 함께 추정하고 정확도를 검토한 팀은 체계적으로 어디서 과대·과소 추정하는지에 대한 공유된 감각 발달
- 부정확한 추정을 처벌하면 팀이 방어적으로 추정을 부풀리게 되고, 부풀린 추정은 정직하지만 불확실한 추정보다 더 쓸모없음
- Complex 영역에서의 틀린 추정은 성격적 결함이 아니라 영역의 속성
8 초과는 분할: 피보나치 13이나 21짜리 스토리는 거의 항상 아직 표면화되지 않은 숨겨진 복잡성을 포함
- 분할 행위가 실제로 무엇을 알고 있는지 명확히 표현하도록 강제
- 종종 3개 하위 스토리 중 2개는 작고, 1개에 모든 불확실성이 집중되어 있음을 발견

양 진영 모두에게 불편한 진실

추정은 계산이 아닌 커뮤니케이션의 한 형태이며, 목적은 미래 예측이 아니라 불확실성 하에서의 조율과 의사결정 지원
추정의 실패 모드는 무작위가 아니라 체계적: 너무 이른 추정, 범위를 점으로 취급, 추정을 약속으로 취급, 불확실성 원뿔의 인식론적 위치 무시, 실행자에게 추정 부과
Dalmijn이 말하는 복잡한 작업 추정의 오류(Complex Work Estimation Fallacy): 더 자주 추정하고 프로세스를 개선하고 더 오래 함께 일하면 결국 정확한 추정이 나올 것이라는 믿음
- Complex 영역에서 추정 정확도의 한계는 팀 성숙도의 함수가 아니라 영역 자체의 함수
- 더 나아질 수는 있지만 정확해지지는 않으며, 이 둘을 혼동하면 조직이 본질적으로 팀의 통제 밖에 있는 것에 대해 팀을 처벌하게 됨
추정 거부는 조율 게임에서의 이탈에 불과
- 완전 독립 운영, 지속적 배포, 외부 약속 없는 팀에는 가능하나 대부분의 경력에서 그런 맥락에 있지 않음
선택지는 "나쁜 추정" vs "추정 없음"이 아니라, 무의식적이고 낮은 품질의 추정(조직이 어차피 당신 없이도 만들 추정) vs 명시적이고 겸손한, 범위 기반의, 가정이 보이는 추정
작업 추정이 Complex 영역에 있기 때문에 복잡성 마인드셋으로 접근해야 함: 탐색, 관찰, 대응, 추정, 추적, 보정의 반복
원뿔은 기다림으로 좁아지지 않고 학습으로 좁아짐