소프트웨어 공학 100 주제 시리즈의 71번째 글이다. (카테고리: 프로젝트 관리와 추정)

한 줄 요약

프로젝트 초기의 추정은 실력이 좋아도 몇 배씩 빗나갈 수 있다. 불확실성의 원뿔(Cone of Uncertainty)은 이 오차가 결정을 내릴수록 줄어든다는 모형이다. 하지만 원뿔은 시간이 흐른다고 저절로 좁아지지 않는다. 그리고 실제 데이터에서는 원뿔이 아니라 “관(pipe)” 모양이 나오기도 한다.

왜 필요한가

“이거 언제 끝나요?” 는 개발자가 가장 자주 받는 질문이다. 대답은 대개 숫자 하나다. “6주요.” 그 숫자는 곧 약속이 되고, 약속은 일정표에 박히고, 6주 뒤에 지켜졌는지만 남는다.

문제는 그 숫자를 말한 시점에 아는 것이 거의 없었다는 데 있다. 요구사항은 한 문단이고, 기존 코드에서 무엇을 건드려야 할지 모르며, 외부 API 의 제약도 아직 모른다. 이런 상태의 추정을 확정된 약속으로 다루면 생기는 일은 정해져 있다.

  • 추정한 사람은 “틀린 사람” 이 되고, 다음부터 방어적으로 부풀린다.
  • 관리자는 부풀린 숫자를 다시 깎는다. 숫자가 협상 대상이 된다.
  • 일정이 밀리면 범위를 줄이는 대신 품질을 줄인다(SE100 #079 에서 다룬다).

원뿔 모형의 쓸모는 정확한 배수를 외우는 데 있지 않다. 추정과 약속을 구분하고, 언제 약속해야 하는지를 판단하는 기준을 준다는 데 있다.

핵심 개념

추정·목표·약속은 다른 것이다

용어 뜻 예
추정(estimate) 지금 아는 정보로 본 결과의 분포 “50% 확률로 6주, 90% 확률로 10주 안”
목표(target) 비즈니스가 원하는 값 “분기 말 전에 출시하고 싶다”
약속(commitment) 팀이 지키겠다고 한 값 “8주 차에 이 범위를 배포한다”

목표가 추정의 분포 안 어디쯤에 있는지 보여 주는 것이 추정자의 일이다. 목표에 맞춰 추정을 고치는 순간 그것은 더 이상 추정이 아니다.

Boehm 의 원뿔

원뿔의 원형은 Barry Boehm 의 Software Engineering Economics(Prentice Hall, 1981)에 실린 그림이다. Todd Little 은 IEEE Software 2006년 논문(저자 공개본)에서 이 그림을 이렇게 요약한다. 타당성(Feasibility) 단계의 불확실성 폭은 0.25배~4배, 즉 16배다. 운영 개념(Concept of operation) 단계에서는 4배로, 요구사항 명세가 끝나면 2.25배로 줄어든다.

Steve McConnell 은 Software Estimation: Demystifying the Black Art(Microsoft Press, 2006)에서 이 그림을 다시 그려 널리 알렸다. 그가 운영하는 Construx 의 해설 페이지에 그 내용이 정리되어 있다.

 추정 오차 배수
  4x  \
       \
  2x    \___
             \___
  1x  ------------======================  (실제)
             ___/
 0.5x   ___/
       /
0.25x /
      초기     제품정의   요구사항   UI 설계   상세설계   완료
      개념     승인       완료       완료       완료

McConnell 의 해설에서 실무에 바로 쓸 수 있는 주장은 다음과 같다.

  • 초기 개념 단계의 추정은 위로 4배, 아래로 4배(0.25배)까지 틀릴 수 있다. 위아래를 합친 폭은 16배다.
  • 원뿔은 숙련된 추정자가 낼 수 있는 최선이다. 그보다 더 정확해질 수는 없고, 운이 좋을 수 있을 뿐이다.
  • 원뿔은 변동성을 없애는 결정을 내려야만 좁아진다. 제품 비전을 정하고(하지 않을 일 포함), 요구사항을 정하고, UI 를 설계하는 일이 그런 결정이다. 프로젝트를 잘 통제하지 못하면 원뿔이 아니라 끝까지 걷히지 않는 “구름” 이 된다.
  • 초기 개념이나 제품 정의 시점에 약속하면 추정에 2~4배의 오차가 실린다. 의미 있는 약속은 프로젝트의 약 30% 지점 이후에 가능하다.

원뿔은 저절로 좁아지지 않는다 — Little 의 반론

Little 은 Landmark Graphics 의 1999~2002년 소프트웨어 프로젝트 106개를 매주 기록한 데이터를 분석했다(논문). 결과는 다음과 같다.

관찰 값
실제 기간 ÷ 최초 추정의 분포 로그정규 분포
그 비율의 중앙값 / 평균 약 1.8 / 약 2.0
p90 ÷ p10 3.25 (DeMarco 데이터는 5.2)
단계별 “남은 기간” 비율의 분포 단계마다 거의 같음

마지막 줄이 핵심이다. 남은 일의 실제 기간을 남은 일의 추정으로 나눈 비율을 단계별로 보면, 불확실성 폭이 줄지 않고 p10~p90 사이 3~4배로 거의 일정했다. Little 은 이것을 원뿔과 대비해 “불확실성의 관(pipe)” 이라고 불렀다. 기간 전체에 대한 오차 비율은 완료 시점에 당연히 1.0 으로 수렴한다. 그러니 그 그래프가 원뿔 모양이라는 사실만으로는 남은 일을 더 잘 예측하게 됐다는 증거가 되지 않는다.

이 데이터는 원뿔 모형과 모순되지 않는다. 원뿔은 “결정을 내려 변동성을 없애면” 좁아진다고 했고, Landmark 팀은 추정을 “증명할 수 없는 가장 이른 날짜” 같은 목표처럼 다루는 문화였다고 Little 은 적었다. 교훈은 하나다. 단계가 지났다고 추정이 좋아졌다고 믿지 말라.

오차는 대칭이 아니다

Little 의 분포가 오른쪽으로 꼬리를 끄는 로그정규라는 점이 중요하다. 일찍 끝나는 데는 하한이 있지만(0 보다 짧을 수 없다) 늦어지는 데는 상한이 없다. 그래서 평균이 중앙값보다 크다. Little 이 인용한 Tom DeMarco 의 정의는 이 비대칭을 잘 보여 준다. “추정이란 실현될 확률이 0 이 아닌 가장 낙관적인 예측이다.”

심리학에서도 같은 현상을 다룬다. Buehler·Griffin·Ross 의 1994년 연구 제목은 “사람들은 왜 과제 완료 시간을 과소평가하는가” 이고, 이 경향을 계획 오류(planning fallacy) 라고 부른다. 소프트웨어 공학 쪽에서는 Magne Jørgensen 이 전문가 추정 연구를 리뷰 논문으로 정리했다.

실무 적용

1. 숫자 하나 대신 범위와 확률로 말한다

나쁜 답:  "6주요."
좋은 답:  "지금 정보로는 6~14주입니다. 절반의 확률로 8주 안에 끝납니다.
          외부 결제 API 의 제약을 확인하고(다음 주 금요일) 다시 좁히겠습니다."

좋은 답에는 세 가지가 들어 있다. 범위, 그 범위의 신뢰 수준, 그리고 원뿔을 좁힐 다음 결정과 그 날짜다.

2. 원뿔을 좁히는 활동을 일정에 넣는다

불확실성 원천 좁히는 활동
무엇을 만들지 비전·비목표(non-goals) 문서, 우선순위 합의
기술적으로 가능한가 스파이크, 프로토타입(SE100 #020 에서 다룬다)
외부 의존 계약·API 문서 확인, 샌드박스 연동
팀 처리 속도 처음 몇 주의 실측 처리량(SE100 #077 에서 다룬다)

3. 재추정은 이벤트로 남긴다

추정을 몰래 고치지 않는다. 날짜, 이유, 새 범위를 기록한다. 이 기록이 쌓이면 팀의 추정 편향을 볼 수 있다. Little 의 데이터처럼 중앙값이 1.8이라면 “최초 추정 × 2” 가 나쁜 출발점이 아니다.

# 과거 프로젝트의 (실제/최초 추정) 비율로 '보정 배수'를 구한다
ratios = [1.2, 2.5, 1.8, 1.1, 3.0, 1.6, 2.2, 1.4]   # 팀 자신의 기록 (예시)
ratios.sort()
def q(p):
    return ratios[min(int(p * len(ratios)), len(ratios) - 1)]
naive = 6  # 주
print(f"p50 ≈ {naive * q(0.5):.1f}주, p90 ≈ {naive * q(0.9):.1f}주")

예시 데이터로 실행하면 p50 ≈ 10.8주, p90 ≈ 18.0주 가 나온다. 비율은 꼭 자기 팀의 기록으로 구해야 한다. 남의 배수를 그대로 가져오는 것은 남의 몸무게로 내 옷 치수를 정하는 것과 같다.

흔한 오해와 함정

  • “원뿔의 배수(4x, 2x, 1.25x…)는 법칙이다.” 원뿔은 특정 시대·조직의 데이터에서 나온 그림이다. 자기 조직의 폭은 직접 재야 한다.
  • “시간이 지나면 추정이 좋아진다.” Little 의 데이터에서 남은 일에 대한 불확실성 폭은 단계가 지나도 거의 줄지 않았다. 결정이 원뿔을 좁히지, 달력이 좁히지 않는다.
  • “추정을 더 오래 하면 더 정확해진다.” McConnell 은 추정에 일주일을 더 써도 프로젝트 자체의 변동성은 줄지 않는다고 지적한다. 시간은 추정을 다듬는 데가 아니라 불확실성을 없애는 결정에 써야 한다.
  • “애자일이면 원뿔이 없다.” McConnell 은 반복마다 작은 원뿔을 지난다고 설명한다. 짧은 반복은 원뿔을 빨리 지나게 해 줄 뿐, 몇 반복 뒤의 범위·일정 조합을 미리 알게 해 주지는 않는다.
  • “추정이 틀렸으니 추정자가 무능하다.” 분포의 한 표본이 평균에서 벗어난 것은 정상이다. 평가해야 할 것은 표본 하나가 아니라 보정(calibration) 이다. 90% 범위라고 말한 것이 실제로 열에 아홉 번 맞는지를 본다.

확인 문제

  1. 추정·목표·약속의 차이를 한 문장씩 설명하라.
  2. Boehm 의 원뿔에서 타당성 단계의 불확실성 폭은 몇 배이며, 이 값은 어떻게 계산되는가?
  3. McConnell 은 원뿔을 “최선의 경우” 라고 부른다. 그 이유는?
  4. Little 의 Landmark 데이터가 원뿔에 대한 통념과 충돌하는 지점은 무엇인가?
  5. 소프트웨어 일정 오차 분포가 오른쪽으로 치우치는 이유를 설명하라.

풀이

  1. 추정은 지금 정보로 본 결과의 분포다. 목표는 비즈니스가 원하는 값이다. 약속은 팀이 지키겠다고 공언한 값이다.
  2. 16배. 상한 4배를 하한 0.25배로 나눈 값이다.
  3. 숙련된 추정자가 잘 통제되는 프로젝트에서 낼 수 있는 정확도의 한계이기 때문이다. 더 나빠지기는 쉽지만 체계적으로 더 좋아질 수는 없다.
  4. 남은 기간의 실제/추정 비율 분포가 단계별로 거의 같았다(p10~p90 사이 3~4배). 단계가 진행되어도 남은 일에 대한 불확실성이 줄지 않은 것이다.
  5. 일찍 끝나는 데는 물리적 하한이 있지만, 늦어지는 데는 상한이 없다. 그래서 분포가 로그정규처럼 오른쪽 꼬리를 길게 끌고 평균이 중앙값보다 커진다.

더 읽을거리 (References)