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 시대에는 변화의 크기보다 불확실성의 정도가 소요 시간을 결정짓는 요소가 될 것임