스태프 엔지니어의 일정 추정법: 추정은 정치적 도구이고, 먼저 데드라인이 정해진다

• 스태프 엔지니어가 쓴 "소프트웨어 일정 추정(estimation)은 근본적으로 불가능하다"는 글인데, 불가능하다고 안 하는 게 아니라 추정의 실제 작동 방식을 적나라하게 파헤침

추정이 불가능한 이유

• 소프트웨어 프로젝트의 시간은 알려진 작업이 아닌 미지의 작업이 90%를 차지함. 그런데 정확하게 추정 가능한 건 알려진 작업뿐이니, 결국 전체 추정은 불가능

• "계획 단계에서 미지의 질문을 해결하라"는 반론이 있지만, 이건 한 명의 아키텍트가 모든 걸 미리 설계하던 시대의 사고방식. 실제로 코드를 만지기 전에는 답을 알 수 없는 질문들임

• 티셔츠 사이즈(S/M/L)로 추정하는 팀이 많은데, 어차피 매니지먼트 체인을 거치면서 바로 시간/일로 환산됨. "초기 추정치를 2배 하고 20% 더해라"는 휴리스틱은 사실상 포기 선언

추정의 진짜 작동 방식

• 추정은 엔지니어가 만드는 게 아님. VP가 원하는 프로젝트에 긴 추정이 나오면 줄이라고 압박하고, 원치 않는 프로젝트에 짧은 추정이 나오면 늘리라고 함. 추정은 비엔지니어들이 프로젝트 예산 배분을 협상하기 위한 정치적 도구

• 흔히 "먼저 작업이 있고, 그 다음 시간을 추정한다"고 생각하지만 실제로는 반대. 먼저 추정치(=데드라인)가 있고, 그 안에 무슨 작업이 가능한지 엔지니어가 역으로 찾는 것

• 예시: LLM 챗봇에 "PDF와 대화" 기능을 넣는다고 할 때, 6개월이면 파일 업로드 시스템 + 청크 & 임베딩 파이프라인 + 이미지 추출까지 가능. 하루면? 클라이언트에서 텍스트로 변환해서 통째로 컨텍스트에 넣는 방법을 찾게 됨

저자의 추정법

• 코드를 보기 전에 정치적 맥락부터 파악함. 이 프로젝트에 압박이 얼마나 있는지, CTO가 1주일 안에 원하는 건지, 아니면 팀에 일감 주려고 던진 건지

• 이상적으로는 코드를 보러 갈 때 이미 추정치를 갖고 감. "이걸 하는 데 얼마나 걸릴까" 대신 "1주일 안에 가능한 접근법은 뭘까"를 질문

• 매니저에게 돌아갈 때 절대 "4주 걸림" 같은 단일 숫자를 주지 않음. 대신 리스크 평가와 선택지 메뉴를 줌:

  1. X, Y, Z를 직접 해결 → 잘 되면 빠르지만 터지면 한 달
  2. Y, Z를 우회 → 다른 리스크가 생기지만 데드라인 달성 가능
  3. 다른 팀 도움 요청 → Z에만 집중

• HN 댓글 중 재밌는 반응: "고연봉 전문가라면 추정이 완전히 허구더라도 기대되는 거 아니냐". 저자의 답: "네, 허구인 걸 서로 인정하면 됩니다!"

• Lobsters 댓글에서 좋은 지적: 팀 역량이 추정에 미치는 영향이 크지만, 대부분의 회사는 추정이 엔지니어 간에 대체 가능(fungible)하다고 잘못 가정함. 실제로 어떤 팀은 10배 빠르게, 어떤 팀은 시간이 무한해도 못 끝냄