▲

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

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

소프트웨어 추정의 허구

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

왜 추정이 불가능한가

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

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

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

추정이 작업을 정의한다

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

실제 추정 방식

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

반론과 대응

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

결론

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

  • 약간 농담 섞인 내 프로젝트 추정 기준표를 공유함
    내부 프로젝트(예: 벤더 이전 등 사용자 영향 없음)는 상사에게 설득 가능한 만큼의 기간을 잡음
    사용자에게 영향이 있는 프로젝트(예: 신규 기능 추가)는 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 책이 떠올랐음
      실제 프로젝트 데이터를 기반으로 예산 초과율 통계를 보여줌
      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 시대에는 변화의 크기보다 불확실성의 정도가 소요 시간을 결정짓는 요소가 될 것임

답변달기