# 추정은 왜 실패하는가 (그리고 왜 여전히 필요한가) > Clean Markdown view of GeekNews topic #27932. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=27932](https://news.hada.io/topic?id=27932) - GeekNews Markdown: [https://news.hada.io/topic/27932.md](https://news.hada.io/topic/27932.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2026-03-28T09:25:01+09:00 - Updated: 2026-03-28T09:25:01+09:00 - Original source: [leadership.garden](https://leadership.garden/estimation/) - Points: 21 - Comments: 0 ## Summary 소프트웨어 개발의 추정은 본질적으로 **정확할 수 없는 Complex 영역의 활동**이지만, 추정을 버리면 조직의 조율 능력이 함께 사라집니다. 핵심은 미래를 맞히는 게 아니라, **불확실성 속에서 기대치를 정렬하는 구조화된 대화**를 유지하는 데 있습니다. 추정을 약속으로 오용하는 관행을 끊고, 범위 기반·가정 명시·점진적 보정으로 다루면 비난 대신 학습이 쌓입니다. AI가 코드 생산 속도를 높이면서 "이제 추정이 필요 없다"는 분위기도 있는데, 실행이 빨라질수록 **무엇을 언제 하겠다는 조율의 가치**는 오히려 올라갑니다. ## Topic Body - 소프트웨어 개발에서 작업 추정은 **복잡계(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 영역에 있기 때문에 **복잡성 마인드셋**으로 접근해야 함: 탐색, 관찰, 대응, 추정, 추적, 보정의 반복 - 원뿔은 기다림으로 좁아지지 않고 **학습으로 좁아짐** ## Comments _No public comments on this page._