왜 Agile Estimation은 연극인가 (그리고 대신 해야 할 일)

발행: (2026년 1월 10일 오전 03:08 GMT+9)
8 min read
원문: Dev.to

Source: Dev.to

번역을 진행하려면 실제 번역이 필요한 텍스트(본문)를 제공해 주세요.
본문을 주시면 그대로 한국어로 번역해 드리겠습니다.

소개

매주 수요일 오후 2시에, 열두 명의 개발자가 회의실에 모입니다. 그 다음 90분 동안 그들은 피보나치 수가 적힌 카드를 들어 보이며, 기능이 5점인지 8점인지 토론하고, 매일 변하는 시스템에서 작업이 얼마나 걸릴지를 예측할 수 있다고 가장합니다.
이것이 현대적인 애자일 추정 의식입니다. 연극에 불과합니다. 그리고 모두가 그것을 알고 있습니다.

추정의 문제

숨겨진 진실: 스토리 포인트, 캘리브레이션 교육, 플래닝 포커에 투자한 시간—이 모든 것이 추정 정확도를 높여주지는 않는다.

추정 비용

8인 팀의 일반적인 2주 스프린트:

  • 90분 백로그 정제
  • 2시간 스프린트 계획(추정 포함)
  • 30분 이월 작업 재추정
  • 스토리당 15분 명확화

이는 개발자당 스프린트당 4–6시간에 해당한다. 1년 동안 8인 팀은 1,664 – 2,496시간을 소비하게 되며, 이는 전담 추정 작업만 하는 풀타임 엔지니어 한 명과 같은 양이다.

왜 추정은 여전히 부정확한가

팀이 속도를 철저히 추적하고 정교한 캘리브레이션을 수행하더라도, 추정은 여전히 크게 빗나간다. 이는 규율의 문제가 아니라, 복잡한 작업에 대한 정확한 소프트웨어 추정이 수학적으로 불가능하기 때문이다.

당신은 다음과 같은 상황에서 추정을 하고 있다:

  • 요구사항에 대한 불완전한 정보
  • 알 수 없는 기술적 의존성
  • 지속적으로 변화하는 코드베이스
  • 새로운 방식으로 실패하는 통합 포인트
  • 구성 요소가 상호 작용할 때만 나타나는 emergent 복잡성

다른 접근법

성인적인 추정 실패에 대한 반응은 “더 나은 추정”이 아니다. 복잡한 지식 작업에서는 추정이 잘못된 정밀성을 제공한다는 것을 인정하는 것이다.

작업을 작고 배포 가능한 조각으로 나누기

하지 말 것: “알림 시스템 재구축 – 40 포인트”

해야 할 일:

  • “사용자의 게시물에 첫 댓글이 달리면 이메일 전송 – 바로 배포”
  • “이메일 선호도 토글 추가 – 바로 배포”
  • “즉시 전송 대신 다이제스트 모드 지원 – 바로 배포”

각 조각은 프로덕션에 배포되어 가치를 제공하며, 주가 아니라 일 단위로 걸린다.

중요한 것을 측정하라

스토리 포인트 전달을 측정하는 것을 중단하고 다음을 측정하라:

  • 사이클 타임: 작업 시작부터 프로덕션까지 걸리는 시간?
  • 처리량: 주당 완료된 항목 수?
  • 진행 중 작업 (WIP): 동시에 진행 중인 항목 수?

이 메트릭은 주관적인 포인트가 아니라 실제 데이터이다.

대규모 이니셔티브 관리

질문을 뒤바꾸세요. “이 기능에 얼마나 걸릴까요?” 대신 “4주 안에 무엇을 전달할 수 있을까요?” 라고 물어보세요.

  • 작업을 타임박스합니다.
  • 문제와 성공 지표를 정의합니다.
  • 반복적으로 작업하여, 타임박스가 끝날 때까지 점점 더 나은 솔루션을 제공해 나갑니다.

경영진과의 솔직한 대화

경영진은 확실성을 원합니다. 추정 연극은 실체 없는 환상을 제공합니다. 추정을 포기하면 더 어렵고 솔직한 대화를 해야 합니다:

“우리는 이것이 6월까지 출시될 것을 약속할 수 없습니다. 대신 출시될 때까지 다른 일은 하지 않겠다고 약속하고, 매주 증분을 배포하여 진행 상황을 확인하실 수 있게 하겠습니다.”

이러한 대화는 소프트웨어 개발의 불가피한 불확실성을 드러내기 때문에 불편하게 느껴질 수 있지만, 스토리 포인트가 예측 문제를 해결한다는 착각보다 더 솔직하고 모두의 시간을 존중하는 방식입니다.

실험 제안

추정 의식에 시간을 낭비하는 것을 멈추는 데 허가가 필요하지 않습니다.

  1. 실험 제안: 추정 없이 한 스프린트—우선순위와 사이클 타임만 사용합니다.
  2. 일어나는 일을 추적합니다.
  3. 처리량, 절약된 시간, 이해관계자 만족도를 측정합니다.

예측: 처리량은 동일하거나 향상되고, 이해관계자 만족도도 동일하거나 향상되며, 개발자 만족도는 확실히 향상됩니다. 연극을 없애고 실제 작업으로 대체했습니다.

결론

스토리를 가리키는 것을 멈추고 소프트웨어를 배포하세요.

실용적인 전환 체크리스트가 포함된 전체 기사 보기: AgileLie.com.

Back to Blog

관련 글

더 보기 »

Agile 단순성의 빈 약속

애자일 단순성의 문제 > “한 문장으로 표현한 애자일: Inspect and adapt.” > 혹은 “가치를 일찍 그리고 자주 전달한다.” 모든 컨설턴트는 엘리베이터 피...