# 소프트웨어 작업을 어떻게 추정하는가 > Clean Markdown view of GeekNews topic #26129. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=26129](https://news.hada.io/topic?id=26129) - GeekNews Markdown: [https://news.hada.io/topic/26129.md](https://news.hada.io/topic/26129.md) - Type: news - Author: [neo](https://news.hada.io/@neo) - Published: 2026-01-26T10:00:02+09:00 - Updated: 2026-01-26T10:00:02+09:00 - Original source: [seangoedecke.com](https://www.seangoedecke.com/how-i-estimate-work/) - Points: 25 - Comments: 2 ## Summary 소프트웨어 프로젝트의 **기간 추정은 본질적으로 불가능한 행위**이며, 대부분의 일정은 **알려지지 않은 변수들에 의해 결정**됩니다. 추정치는 생산성 지표가 아니라 **경영진의 의사결정과 자원 배분을 위한 정치적 도구**로 작동하며, 실제로는 이 추정이 작업의 형태와 기술적 접근을 규정합니다. 따라서 엔지니어는 정확한 수치를 맞추려 하기보다, **주어진 기간 안에서 가능한 시나리오와 위험 요소를 명확히 제시**하는 데 집중해야 합니다. ## Topic Body - **소프트웨어 프로젝트의 정확한 기간 추정은 불가능**하며, 대부분의 작업은 예측 불가능한 ‘미지의 일’에 의해 지배됨 - **추정치는 엔지니어가 아니라 경영진의 정치적 도구**로 사용되어, 프로젝트의 우선순위와 자금 배분을 결정하는 역할을 함 - 실제로는 **추정이 작업을 정의**하며, 팀은 주어진 기간 안에 가능한 기술적 접근 방식을 찾아내는 형태로 일함 - 효과적인 추정을 위해 엔지니어는 **정치적 맥락 파악, 미지의 위험 평가, 복수의 실행 시나리오 제시**에 집중해야 함 - 이러한 접근은 **정확성보다 신뢰와 현실적 협업**을 중시하며, 조직 내 의사결정 구조를 이해하는 엔지니어링 역량을 강조함 --- ### 소프트웨어 추정의 허구 - 업계에서는 숙련된 팀이 충분한 노력으로 **정확한 일정 예측이 가능하다는 ‘예의 있는 허구’** 가 존재 - 실제로는 대부분의 엔지니어가 **정확한 예측이 불가능함을 인식**하고 있음 - 일부 팀은 **티셔츠 사이즈 방식**으로 추정하지만, 이는 결국 시간 단위로 환산되어 관리 계층에 전달됨 - “초기 추정의 두 배에 20%를 더하라” 같은 **비현실적 휴리스틱**이 사용되기도 함 ### 왜 추정이 불가능한가 - **작고 명확한 작업**은 예측 가능하지만, 대부분의 프로젝트는 **불확실하고 복잡한 시스템**에서 수행됨 - 예: 단순한 링크 텍스트 변경은 45분으로 예측 가능하지만, 대규모 시스템 변경은 불가능 - 대다수의 프로그래밍은 **탐색적 연구 행위**로, 사전 계획만으로는 필요한 작업을 알 수 없음 - 과거의 **중앙집중식 아키텍처 설계 방식**은 실패했으며, 실제 코드를 다루는 개발자가 의사결정해야 함 - 결과적으로 **알려진 작업은 전체의 10%에 불과**, 나머지 90%는 미지의 영역으로 인해 추정 불가 ### 추정은 엔지니어가 아닌 경영진의 도구 - 추정은 **팀의 생산성 향상과 무관**하며, 많은 효율적인 팀은 추정 없이도 일함 - 경영진은 **원하는 결과에 맞게 추정을 조정**하려 하며, 긴 일정은 단축 압박을, 짧은 일정은 버퍼 추가를 받음 - **기술적으로 불가능한 프로젝트**만이 예외적으로 현실적 판단을 이끌어낼 수 있음 - **조직 내 관심이 낮은 영역**에서는 형식적 절차가 그대로 유지되기도 함 - 따라서 추정은 **비엔지니어가 프로젝트를 선택·취소하는 정치적 수단**으로 작동 ### 추정이 작업을 정의한다 - 일반적 인식과 달리, **작업이 아니라 추정이 먼저 정해지고**, 그에 맞는 기술적 접근이 결정됨 - 예: “PDF와 대화하기” 기능을 6개월 안에 구현할 때와 하루 안에 구현할 때의 접근 방식은 완전히 다름 - **시간 제약이 코드 설계의 깊이와 품질을 결정**하며, 엔지니어는 주어진 기간 내 가능한 해법을 선택 ### 실제 추정 방식 - 먼저 **정치적 맥락을 파악**해 프로젝트의 중요도와 기대 일정을 이해 - 이후 **이미 정해진 기간을 기준으로 가능한 접근법을 탐색** - **미지의 영역(unknowns)** 이 많을수록 추정치는 커지고, 접근 범위를 좁혀야 함 - 최종적으로는 **정확한 기간 대신 위험 평가와 여러 실행 시나리오**를 제시 - 예: 모든 요소를 직접 해결, 일부 우회, 다른 팀 지원 요청 등 - 엔지니어의 역할은 “얼마나 걸릴까”가 아니라 **“주어진 기간에 가능한 방법은 무엇인가”** 를 찾는 것 ### 반론과 대응 - 일부 엔지니어는 **불확실한 조건에서의 추정을 회피**하지만, 이는 비기술적 인물이 대신 추정하게 만듦 - 경영진과 협력하지 않고 **항상 대립하는 태도**는 비생산적이며, 신뢰를 약화시킴 - 압박을 느끼지 않는 팀은 단지 **조직 내 관심 밖의 영역**에 있을 가능성이 높음 ### 결론 - 실제로는 **관리자가 이미 염두에 둔 기간**을 가지고 팀에 접근하며, 팀은 그 안에서 가능한 기술적 해법을 찾음 - 추정은 **경영진 간 협상 도구**이며, 불가능한 프로젝트만이 예외적으로 현실을 전달하는 수단이 됨 - 올바른 추정은 **정확한 수치가 아니라 위험과 선택지의 제시**를 포함해야 함 - **소프트웨어 작업의 정확한 추정은 불가능**하며, 성공적인 추정은 미지의 위험을 인식하고 이를 관리하는 능력에 달려 있음 ## Comments ### Comment 52044 - Author: roxie - Created: 2026-02-27T22:30:55+09:00 - Points: 1 > 먼저 정치적 맥락을 파악해 프로젝트의 중요도와 기대 일정을 이해 > 이후 이미 정해진 기간을 기준으로 가능한 접근법을 탐색 오호 ### Comment 49922 - Author: neo - Created: 2026-01-26T10:01:01+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46742389) - 약간 농담 섞인 내 **프로젝트 추정 기준표**를 공유함 내부 프로젝트(예: 벤더 이전 등 사용자 영향 없음)는 상사에게 설득 가능한 만큼의 기간을 잡음 사용자에게 영향이 있는 프로젝트(예: 신규 기능 추가)는 **ROI가 양수인 동안** 진행함 외부 파트너와 협업이 필요한 프로젝트는 영업팀이 납기를 정하고, 엔지니어링팀은 그 일정에 맞춰 **MVP 정의를 살짝 조정**함 - 왜 아무도 **planning poker**나 **story point** 얘기를 안 하는지 의문이었음 완벽하진 않지만 꽤 괜찮은 방법임. 모든 작업은 스프린트 내에 끝나야 하고, 크면 쪼개야 함 팀원 전원이 포인트에 합의해야 하며, 그 과정에서 **진짜 논의의 가치**가 생김 몇 달 지나면 팀의 속도가 안정되어 ±10% 정도의 정확도로 예측 가능해짐 마법은 아니지만, 꾸준히 가치를 전달하고 매 스프린트마다 **비용 대비 효용**을 재검토하게 해줌 - 여러 추정 방식을 시도해봤지만, 결국 **경험 많은 사람의 의견**에 따라가는 경향이 있음 새로 합류한 사람은 같은 티켓이라도 2배 이상 걸릴 수 있음 게다가 조직은 PR 리뷰를 24시간 내에 끝내라 같은 규칙을 만들어서 현실과 괴리가 생김 - 우리 팀도 비슷하게 하지만 스프린트를 **버전 단위로 유연하게** 운영함 개발자와 QA가 함께 복잡도를 비교하며 추정하고, QA는 테스트 난이도나 자동화 가능성을 평가함 덕분에 **개발 속도 지표**가 안정적이고 버전별 추정도 꽤 정확함 - **story point는 단위가 아니기 때문에 합산이 불가능**하다고 생각함 팀 전체가 최소 단위에 대한 공통 이해가 있고, 그것을 시간으로 변환할 수 있을 때만 의미가 있음 결국 그때는 그냥 시간을 쓰면 되므로 포인트 자체가 불필요함 - 한 가지 추정치로 팀원 간 **숙련도 차이**를 어떻게 반영하냐는 의문이 있음 - 우리 소규모 팀은 **피보나치 수열**로 추정하는데 꽤 잘 맞음 - 나는 “2시간, 2일, 2주, 2개월, 2년” 단위로 질문하며 **신뢰 구간 기반 추정**을 함 범위가 너무 넓으면 더 쪼개고, 불가능하면 정보 수집에 시간 쓸 가치가 있는지 판단함 아니라면 프로젝트를 폐기함 - 나도 비슷하게 하지만 **1시간/1일/1주 단위**로 세분화함 결과를 명확히 정의하고, 아이디어를 세부 단계로 나누면 현실적인 추정이 가능함 하루나 일주일 단위로 쪼갤 수 없다면 아직 **계획이 부족한 상태**임 - 만약 일주일 시도 후 방향을 바꿔야 하는 **탐색형 프로젝트**라면? 이런 경우엔 계속 다른 접근을 시도하며 배우는 과정이므로 추정이 어렵다고 생각함 - “내일까지 끝낼 수 있나?” 같은 **구체적 질문**이 훨씬 실질적임 단순한 길이 추정보다 행동 중심으로 생각하게 만듦 - 이 방식이 **티셔츠 사이징보다 정확**하다고 느낌 - 예전에 단순히 비밀번호를 **평문에서 해시로 마이그레이션**하는 작업을 한 스프린트로 잡았는데, 실제로는 6개월 걸림 고객이 비밀번호를 대소문자 구분 없이 쓰던 걸 영상으로 보여줘서 알게 됨 게다가 PHP 이미지가 삭제되어 **빌드 실패**까지 겹침 추정은 언제나 즐거운 모험임 - 그 얘기를 듣고 [*How Big Things Get Done*](https://www.penguinrandomhouse.com/books/688734/how-big-things-get-done-by-bent-flyvbjerg-and-dan-gardner/) 책이 떠올랐음 실제 프로젝트 데이터를 기반으로 **예산 초과율 통계**를 보여줌 IT 프로젝트는 평균 73% 초과로, 원자력 저장소·올림픽·수력발전 다음으로 나쁨 18%의 IT 프로젝트가 50% 이상 초과하며, 그들의 평균 초과율은 447%임 결국 대부분의 산업에서 **추정은 구조적으로 낙관적**일 수밖에 없음을 보여줌 - 많은 엔지니어와 매니저가 **과거 프로젝트의 메트릭**을 기반으로 추정하지 않는 게 신기함 팀의 처리량 데이터를 보면 대략적인 기간과 **신뢰 구간(예: 90%, 70%, 50%)** 을 계산할 수 있음 이렇게 하면 외부 이해관계자에게도 확률적 맥락을 제공할 수 있음 - PMI의 **프로젝트 관리 방법론**에서도 과거 데이터를 기반으로 추정하라고 명시함 하지만 많은 엔지니어가 이를 행정적 부담으로 여김 좋은 관행은 **구간 추정**을 사용하는 것이며, PERT 방식처럼 최선·예상·최악 세 가지를 모델링함 최고의 기술자일수록 자기 시간 추정에 **과신**하는 경향이 있음 각자 추정 후 20% 보정하는 방식이 꽤 잘 맞았음 경영진이 일정을 강요하면, 그 시간 안에 가능한 범위를 설명하거나 **명확한 스코프 후 재추정**을 제안해야 함 참고: PMI PMP, PMBOK의 *Lessons Learned Repository* - “**크로스워드 퍼즐**이나 체스 한 판은 얼마나 걸리나?”라는 비유로, 추정의 불확실성을 풍자함 - 예측(prediction)과 **지시(prescription)** 의 차이로 설명함 예측은 오차를 통해 학습하지만, 지시는 오히려 **생산성 압박**으로 이어짐 - 나는 추정을 **협상 과정**으로 봄 자동차 트림처럼 Economy, Mid-tier, Luxury 세 가지 옵션을 제시함 비즈니스는 항상 3번의 기능성과 1번의 예산을 원하므로, 결국 내가 상황에 맞게 조정함 **#1 플랜**을 준비해두면 위기 시 빠르게 전환 가능하고, 협상 중 **지름길의 대가**를 시각화할 수 있음 덕분에 당황한 PM이나 임원의 **비합리적 결정**을 여러 번 피할 수 있었음 - 나는 FAANG급 **대규모 분산 시스템**을 다루는데, 여기선 정확한 추정이 거의 불가능함 **unknown-unknowns**가 너무 많고, 프로토타입만으로도 막대한 데이터와 시간이 필요함 그래서 추정보다는 **불확실성 관리**에 초점을 맞춤 - 현재 추정의 신뢰 수준 - 불확실성을 줄일 수 있는 작업(프로토타입, 실험, 전문가 투입 등) - 새로운 일이 발견될 경우의 **대응 계획** - 가장 신뢰할 수 있는 방법은 **유사 프로젝트와 비교**하는 것임 “이건 프로젝트 X보다 20% 복잡하니 20% 더 걸릴 것”처럼 단, 이를 위해선 과거 프로젝트의 **실제 소요 데이터**를 꾸준히 기록해야 함 - 처음엔 “추정은 불가능하다”는 주장에 반대하려 했지만, 실제로는 **조직 내 역할**이 더 중요하다는 걸 깨달음 팀이 추정 대비 용량을 보고 불가능하다고 해도, 일정은 바뀌지 않음 결국 **스코프 축소나 품질 절충**으로 맞추게 됨 그래서 “추정은 쓸모없다”는 말이 더 정확할지도 모름 - 추정의 핵심은 **모호성(ambiguity)** 이라고 느낌 UI 미세 조정처럼 작아 보이지만 실제로는 **하면서 배워가는 작업**이 많음 반대로 큰 변경이라도 명확히 정의되어 있으면 빠르게 끝남 LLM 시대에는 변화의 크기보다 **불확실성의 정도**가 소요 시간을 결정짓는 요소가 될 것임