소프트웨어 작업을 어떻게 추정하는가

• 소프트웨어 프로젝트의 정확한 기간 추정은 불가능하며, 대부분의 작업은 예측 불가능한 ‘미지의 일’에 의해 지배됨
• 추정치는 엔지니어가 아니라 경영진의 정치적 도구로 사용되어, 프로젝트의 우선순위와 자금 배분을 결정하는 역할을 함
• 실제로는 추정이 작업을 정의하며, 팀은 주어진 기간 안에 가능한 기술적 접근 방식을 찾아내는 형태로 일함
• 효과적인 추정을 위해 엔지니어는 정치적 맥락 파악, 미지의 위험 평가, 복수의 실행 시나리오 제시에 집중해야 함
• 이러한 접근은 정확성보다 신뢰와 현실적 협업을 중시하며, 조직 내 의사결정 구조를 이해하는 엔지니어링 역량을 강조함

소프트웨어 추정의 허구

• 업계에서는 숙련된 팀이 충분한 노력으로 정확한 일정 예측이 가능하다는 ‘예의 있는 허구’ 가 존재
  • 실제로는 대부분의 엔지니어가 정확한 예측이 불가능함을 인식하고 있음
• 일부 팀은 티셔츠 사이즈 방식으로 추정하지만, 이는 결국 시간 단위로 환산되어 관리 계층에 전달됨
• “초기 추정의 두 배에 20%를 더하라” 같은 비현실적 휴리스틱이 사용되기도 함

왜 추정이 불가능한가

• 작고 명확한 작업은 예측 가능하지만, 대부분의 프로젝트는 불확실하고 복잡한 시스템에서 수행됨
  • 예: 단순한 링크 텍스트 변경은 45분으로 예측 가능하지만, 대규모 시스템 변경은 불가능
• 대다수의 프로그래밍은 탐색적 연구 행위로, 사전 계획만으로는 필요한 작업을 알 수 없음
• 과거의 중앙집중식 아키텍처 설계 방식은 실패했으며, 실제 코드를 다루는 개발자가 의사결정해야 함
• 결과적으로 알려진 작업은 전체의 10%에 불과, 나머지 90%는 미지의 영역으로 인해 추정 불가

추정은 엔지니어가 아닌 경영진의 도구

• 추정은 팀의 생산성 향상과 무관하며, 많은 효율적인 팀은 추정 없이도 일함
• 경영진은 원하는 결과에 맞게 추정을 조정하려 하며, 긴 일정은 단축 압박을, 짧은 일정은 버퍼 추가를 받음
• 기술적으로 불가능한 프로젝트만이 예외적으로 현실적 판단을 이끌어낼 수 있음
• 조직 내 관심이 낮은 영역에서는 형식적 절차가 그대로 유지되기도 함
• 따라서 추정은 비엔지니어가 프로젝트를 선택·취소하는 정치적 수단으로 작동

추정이 작업을 정의한다

• 일반적 인식과 달리, 작업이 아니라 추정이 먼저 정해지고, 그에 맞는 기술적 접근이 결정됨
  • 예: “PDF와 대화하기” 기능을 6개월 안에 구현할 때와 하루 안에 구현할 때의 접근 방식은 완전히 다름
• 시간 제약이 코드 설계의 깊이와 품질을 결정하며, 엔지니어는 주어진 기간 내 가능한 해법을 선택

실제 추정 방식

• 먼저 정치적 맥락을 파악해 프로젝트의 중요도와 기대 일정을 이해
• 이후 이미 정해진 기간을 기준으로 가능한 접근법을 탐색
• 미지의 영역(unknowns) 이 많을수록 추정치는 커지고, 접근 범위를 좁혀야 함
• 최종적으로는 정확한 기간 대신 위험 평가와 여러 실행 시나리오를 제시
  • 예: 모든 요소를 직접 해결, 일부 우회, 다른 팀 지원 요청 등
• 엔지니어의 역할은 “얼마나 걸릴까”가 아니라 “주어진 기간에 가능한 방법은 무엇인가” 를 찾는 것

반론과 대응

• 일부 엔지니어는 불확실한 조건에서의 추정을 회피하지만, 이는 비기술적 인물이 대신 추정하게 만듦
• 경영진과 협력하지 않고 항상 대립하는 태도는 비생산적이며, 신뢰를 약화시킴
• 압박을 느끼지 않는 팀은 단지 조직 내 관심 밖의 영역에 있을 가능성이 높음

결론

• 실제로는 관리자가 이미 염두에 둔 기간을 가지고 팀에 접근하며, 팀은 그 안에서 가능한 기술적 해법을 찾음
• 추정은 경영진 간 협상 도구이며, 불가능한 프로젝트만이 예외적으로 현실을 전달하는 수단이 됨
• 올바른 추정은 정확한 수치가 아니라 위험과 선택지의 제시를 포함해야 함
• 소프트웨어 작업의 정확한 추정은 불가능하며, 성공적인 추정은 미지의 위험을 인식하고 이를 관리하는 능력에 달려 있음