테스트 공수 산정 심화 — 와이드밴드 델파이 세션, PERT 신뢰수준, 과거 데이터에서 생산성 지표 뽑기

개념

이 레슨이 모듈 4와 다른 지점

모듈 4 레슨 4에서 산정의 세 가지 근거 — 유사 프로젝트 비교, 테스트 케이스 수 환산, 3점 산정 — 를 배웠다. 그 레슨은 한 사람이 자기 담당 범위를 계산하는 법 이었다. 테스트 매니저의 산정은 세 가지가 더 붙는다.

세 가지를 하나씩 본다. 기본 개념(O·M·P, 회귀 배수, 대기 시간)은 모듈 4 레슨 4에 있으므로 여기서 반복하지 않는다.

1. 와이드밴드 델파이 — 집단의 판단을 앵커링 없이 모으는 절차

혼자 낸 숫자는 한 사람의 경험과 편향을 그대로 담는다. 회의에서 다 같이 내면 더 나빠질 수도 있다. 먼저 말한 사람의 숫자가 기준점이 되고(앵커링), 상사가 배석하면 아무도 큰 숫자를 말하지 않기 때문 이다.

와이드밴드 델파이는 이 두 문제를 절차로 막는다. 핵심은 개별 추정을 먼저, 익명으로, 근거 토론은 숫자를 본 뒤에 다.

세션 진행 절차

[준비]
 ① 진행자 선정 — 이 추정에 이해관계가 없는 사람. 매니저가 진행자를 겸하지 않는다
 ② 참가자 3~7명 — 실제로 그 일을 할 사람 + 인접 영역을 아는 사람
 ③ 사전 배포 — 범위 문서, 알려진 제약, 지난 유사 릴리스의 실적 지표
 
[킥오프 — 60분]
 ④ 범위 설명과 질문 (진행자는 숫자를 말하지 않는다)
 ⑤ 가정 목록을 함께 만든다 — "환경은 2개", "개발 빌드는 주 3회", "회귀는 자동화 범위 내"
 ⑥ WBS 합의 — 추정 항목을 같은 단위로 쪼갠다
 ⑦ 단위 확정 — 인일? 인시간? 소수점 자리?
 
[라운드 1]
 ⑧ 각자 혼자, 서로 보지 않고 항목별 추정 제출 (익명)
 ⑨ 진행자가 취합해 분포만 공개 — 누가 무엇을 냈는지는 공개하지 않는다
 
[토론 — 30분]
 ⑩ 편차가 가장 큰 항목부터 다룬다. "왜 3일인가"가 아니라
    "3일을 낸 사람은 무엇을 포함했고, 12일을 낸 사람은 무엇을 포함했나"를 묻는다
 ⑪ 새로 드러난 작업·가정을 목록에 추가한다
 
[라운드 2 …]
 ⑫ 다시 익명 개별 추정 → 취합 → 토론. 보통 2~3라운드에서 멈춘다
 
[종료]
 ⑬ 수렴 판정 → 합의값 확정 → 가정 목록·미해소 쟁점과 함께 기록

가장 자주 무너지는 단계는 ⑩이다. 편차가 큰 항목을 "누가 맞나"로 다루면 목소리 큰 사람이 이긴다. 편차는 틀린 사람이 있다는 신호가 아니라 범위 해석이 다르다는 신호다. 실제로 편차의 대부분은 "그 항목에 테스트 데이터 준비가 들어가는가", "회귀를 포함했는가" 같은 범위 불일치 에서 나온다. 이것을 드러내는 것이 델파이의 진짜 산출물이다.

실제 라운드 기록 예시

"정기 구독 결제 도입" 릴리스의 테스트 공수를 5명이 추정했다(단위: 인일).

"정기 결제 배치"의 라운드 1 범위가 10인일이었다는 사실 자체가 가장 값진 정보다. 2인일을 낸 사람은 배치가 한 번 도는 것만 봤고, 12인일을 낸 사람은 실패 재시도·부분 성공·중복 청구 방지까지 봤다. 토론에서 이 차이가 드러나자 "실패 재시도는 이번 범위에 포함한다"는 결정이 내려졌고, 동시에 환불 일할 계산의 반올림 규칙이 아직 정의되지 않았다 는 요구사항 구멍이 발견됐다. 산정 세션이 요구사항 리뷰의 기능을 한 셈이다.

수렴을 언제 멈추나

라운드를 무한히 돌 수는 없다. 실무에서 쓰는 종료 기준은 셋 중 하나다.

끝까지 수렴하지 않는 항목이 남는 것은 실패가 아니다. 그 항목은 "합의 불가 — 근본 원인은 요구사항 미정의"로 기록하고, 불확실성이 큰 채로 다음 단계(PERT)로 넘긴다. 억지로 평균을 내서 하나의 숫자로 만들면 그 불확실성이 보이지 않게 된다.

델파이가 실패하는 패턴

• 진행자가 의견을 낸다. 진행자의 한마디가 곧 앵커다. 진행자는 질문만 한다.
• 평가 권한이 있는 상사가 배석한다. 같은 방에 있으면 익명성은 형식일 뿐이다. 필요하면 결과만 보고받게 한다.
• 가정 목록을 만들지 않는다. 가정이 없으면 편차의 원인을 추적할 수 없고, 나중에 "그건 포함 안 된 줄 알았다"는 분쟁이 난다.
• 한 라운드로 끝낸다. 라운드 1의 평균은 그냥 여러 사람의 감의 평균이다. 값은 토론 뒤 라운드 2부터 나온다.

2. PERT 심화 — 세 값에서 신뢰수준이 붙은 커밋 값으로

모듈 4 레슨 4에서 기대값 E = (O + 4M + P) / 6 과 표준편차 σ = (P − O) / 6 을 봤다. 매니저가 추가로 해야 할 일은 항목별 σ를 프로젝트 전체의 σ로 합치고, 거기서 신뢰수준별 값을 뽑는 것 이다.

합산할 때 σ는 그냥 더하지 않는다

이것이 실무에서 가장 자주 틀리는 계산이다. 항목들이 서로 독립이라면 분산(σ²)을 더한 뒤 제곱근 을 취한다.

E_total = Σ Eᵢ
σ_total = √( Σ σᵢ² )        ← σ를 그냥 더하면 과대 추정이 된다

델파이 라운드 2의 결과에 O·M·P를 붙여 계산해 보자.

σ_total = √4.647 = 2.156 인일
 
(σ를 그대로 더했다면 4.417 — 두 배 넘게 부풀려진다)

신뢰수준별 커밋 값

기대값 27.58인일은 "절반의 확률로 이 안에 끝난다" 는 뜻이다. 그대로 약속하면 두 번에 한 번은 늦는다. 정규 근사를 쓰면 원하는 확률의 값을 낼 수 있다.

커밋 값 = E_total + z × σ_total
 
  z = 0.84 →  80% 확률로 이 안에 끝난다
  z = 1.28 →  90%
  z = 1.645 → 95%

이 표가 협상 테이블에서 하는 일이 있다. "28일 주세요"가 아니라 "28일이면 절반의 확률로 맞고, 30일이면 열에 아홉은 맞습니다. 어느 쪽으로 약속할까요?" 가 된다. 일정 지연의 책임이 QA의 무능이 아니라 조직이 선택한 확률의 결과가 된다.

조직 관행으로 80% 커밋을 기본 으로 두는 곳이 많다. 90~95%는 규제·안전 영역이나 대외 계약 일정에 쓰고, 50%는 내부 목표(스트레치 목표)로만 쓴다.

독립 가정이 깨질 때

σ² 합산은 항목들이 서로 독립적으로 지연된다 는 가정 위에 있다. 현실에서는 자주 깨진다.

가장 실용적인 보정은 "전부 동시에 나빠지는 요인"을 항목에서 빼내 독립된 위험 항목으로 세우는 것 이다. 환경 불안정, 핵심 인력 이탈, 공통 모듈 대규모 재작업이 그런 항목이다. 이들은 σ² 합산에 넣지 말고 별도의 예비비로 관리한다(모듈 44 레슨 7의 변경 예비비와 같은 취급).

3. 과거 데이터에서 생산성 지표 뽑기

델파이도 PERT도 참가자의 판단 에서 출발한다. 기준선이 없으면 다섯 명이 나란히 틀릴 수 있다. 기준선은 기억이 아니라 이미 조직에 쌓여 있는 기록 에서 계산한다.

원자료는 이미 있다

계산할 지표 다섯 개

케이스 수를 그대로 쓰면 안 되는 이유와 정규화

"케이스 한 건"은 팀마다, 기능마다 크기가 다르다. 로그인 실패 메시지 한 줄 확인과 정산 배치 대사 검증이 같은 1건으로 세어지면 생산성 지표가 의미를 잃는다. 복잡도 가중치로 정규화 한다.

[정규화 케이스 수 = Σ (케이스 수 × 가중치)]
 
 가중치  기준                                        예
  1     단일 화면, 데이터 준비 불필요                   필수값 미입력 오류 메시지
  2     다중 화면·API 확인, 간단한 데이터 준비          주문 생성 후 목록 반영 확인
  4     배치·외부 연동·상태 조건, 사전 데이터 구성 필요   정기 결제 실패 후 재시도 3회차 처리
  8     다중 시스템 대사, 시간 이동·환경 조작 필요        월 마감 정산 원장 대사

가중치의 절대값은 중요하지 않다. 같은 자를 계속 쓰는 것 이 중요하다. 조직 안에서 한 번 정하고 바꾸지 않으면 그 자체로 비교 가능한 단위가 된다.

실제 계산 — 네 릴리스에서 기준선 만들기

변동계수(표준편차 ÷ 평균)가 판정 도구다.

• 0.1 미만 — 안정적인 기준선이다. 그대로 써도 된다. 위 표의 실행 생산성 29.7케이스/인일과 결함 밀도 11.3건/100케이스가 여기 해당한다.
• 0.10.3 — 쓸 수는 있으나 범위로 말한다. "비실행 시간 2030%".
• 0.3 이상 — 단위가 잘못됐거나 서로 다른 성격의 일을 한 통에 넣은 것이다. 쪼개서 다시 센다.

이 기준선으로 신규 릴리스를 추정하면 이렇게 된다.

[정기 구독 결제 — 기준선 기반 추정]
정규화 케이스 추정          240
실행 공수  240 ÷ 29.7   =   8.1 인일
예상 결함  240 × 0.113  =   27 건
재작업     27 × 0.45인일 =  12.2 인일      (결함당 재작업 3.6시간 = 0.45인일)
소계                        20.3 인일
비실행 시간 보정 ÷ (1−0.25) = 27.1 인일
 
→ 델파이·PERT 결과(E 27.6인일)와 0.5인일 차이. 세 기법이 같은 곳을 가리킨다.

세 기법은 교차 검증한다

세 값이 모이면 신뢰도가 올라간다. 하나가 크게 튀면 그 자체가 신호다. 기준선은 27인데 델파이가 45라면, 팀은 이번 일이 과거와 다르다고 보고 있다는 뜻이다. 무엇이 다른지 묻는 것이 다음 할 일이다.

4. 산정 근거를 방어하기

산정은 반드시 도전받는다. 방어는 말솜씨가 아니라 미리 써 둔 한 장 에서 나온다.

산정 근거서 — 한 장

[산정 근거서 — 정기 구독 결제 테스트, 2026-09-24]
 
범위에 포함   구독 생성·해지, 정기 결제 배치(재시도 포함), 환불·일할 계산,
              PG 연동 장애 시나리오, 관련 회귀
범위에서 제외  성능·부하 시험(별도 항목), 마케팅 페이지, 기존 단건 결제 재검증
단위          인일(1인일 = 7시간 순작업), 소수점 1자리
 
가정          ① 테스트 환경 2개, 가용률 90% 이상
              ② 개발 빌드 주 3회 이상 인도
              ③ 회귀는 기존 자동화 스위트 범위 내, 신규 자동화 없음
              ④ 일할 계산 반올림 규칙이 개발 착수 전까지 확정된다
 
방법          와이드밴드 델파이 2라운드(참가 5인) → PERT → 과거 4개 릴리스 기준선 대조
데이터 출처    TestRail 실행 기록·Jira 결함(24.06~25.03), 스프린트 타임시트
 
결과          기대값 27.6 인일 / 표준편차 2.16
              50% 27.6 · 80% 29.4 · 90% 30.3 · 95% 31.1
권고 커밋      80% = 29.4 인일 (조직 기본값)
 
미해소 쟁점    가정 ④가 깨지면 환불·일할 계산 항목이 +3~5인일
재산정 조건    (a) 요구사항 확정 시점  (b) 개발 완료 시점
              (c) 가정 ①~④ 중 하나가 깨진 날
작성/검토      QA 매니저 ○○○ / 개발 리드 ○○○ 확인

"미해소 쟁점"과 "재산정 조건" 두 칸이 이 문서의 핵심이다. 산정은 틀린다. 틀렸을 때 "그때 그렇게 말했잖아"가 아니라 "가정 ④가 깨졌으므로 재산정한다"는 절차가 돌아가게 만드는 것이 이 두 칸의 역할이다.

네 가지 도전과 답변 구조

네 답변의 공통 구조는 같다. 숫자를 방어하지 않고 구성 요소와 가정을 보여 준다. 깎으려는 사람에게 "깎을 수 있는 항목의 목록"을 주면, 대화는 싸움이 아니라 선택이 된다.

산정 정확도를 측정한다

산정 능력은 기록에서 자란다. 프로젝트마다 다음 두 값을 남긴다.

상대 오차 MRE = |실제 − 추정| ÷ 실제
편향        = (실제 − 추정) ÷ 추정      ← 부호가 중요하다

편향의 부호가 네 번 다 같다는 것이 중요한 발견이다. 무작위 오차가 아니라 체계적 과소 추정이다. 원인은 대개 하나 — 비실행 시간을 덜 잡았거나, 회귀 배수를 낮게 잡았다. 이 경우 다음 산정에는 보정 계수 1.13을 명시적으로 곱하거나, 아예 비실행 시간 비율을 기준선에서 올린다. MRE만 보면 "11% 정도 틀리는구나"로 끝나지만, 편향을 보면 고칠 곳이 보인다.

롤링 웨이브 — 한 번 내고 끝내지 않는다

산정은 정보가 가장 적은 시점에 요구된다. 그래서 한 번 내고 끝내면 구조적으로 틀릴 수밖에 없다. 정보가 늘어나는 시점마다 다시 낸다.

초기 단계에서 하나의 숫자를 요구받으면 범위로 답하고 그 이유를 밝힌다. "지금 정보로는 20~40인일입니다. 요구사항이 확정되는 10월 5일에 ±25% 수준으로 다시 내겠습니다"가 정직하면서도 쓸모 있는 답이다.

실무에서 왜 필요한가

테스트 공수가 깎이는 진짜 이유는 숫자가 커서가 아니라 근거가 한 겹이기 때문 이다. "제 경험상 30일입니다"는 다른 사람의 경험 앞에서 무력하다. 델파이로 다섯 사람의 판단을 모으고, PERT로 불확실성을 확률로 바꾸고, 과거 실측으로 기준선을 대조한 숫자는 한 사람의 의견이 아니라 조직의 데이터가 된다.

효과는 숫자 방어에 그치지 않는다. 델파이 세션은 범위 해석의 불일치와 요구사항의 구멍을 개발 착수 전에 드러내고, 신뢰수준 표는 일정 위험을 QA 혼자가 아니라 결정권자가 함께 지는 구조로 바꾼다. 산정은 일정을 맞히는 기술이 아니라 불확실성을 조직이 함께 다루게 만드는 절차 다.

채용시장에서의 위치

테스트 매니저·QA 리드 면접에서 "공수를 어떻게 산정하나"는 거의 반드시 나온다. 대부분의 지원자는 "과거 경험과 케이스 수를 기준으로"에서 멈춘다. 여기서 델파이 세션을 진행해 본 경험, σ 합산과 신뢰수준 커밋, 산정 정확도 추적(MRE·편향) 을 말할 수 있으면 다른 층위의 답이 된다. ISTQB CTAL-TM v3.0도 산정 기법과 산정 근거의 제시를 테스트 매니저의 핵심 성과로 둔다.

포트폴리오로는 산정 근거서 한 장과 산정 정확도 추적표가 가장 강하다. 두 문서 모두 회사 기밀 없이 형식만으로도 역량이 드러난다.

실습 과제

과제 1 — 와이드밴드 델파이 모의 세션 (30분)

동료 2~4명(구하기 어려우면 혼자 세 개의 다른 역할을 맡아)과 함께 임의의 기능 하나를 골라 세션을 진행한다.

• 킥오프에서 가정 목록을 5개 이상 만든다
• 라운드 1 결과를 항목별 최솟값·최댓값·범위로 표에 적는다
• 범위가 가장 큰 항목의 원인이 "판단 차이"인지 "범위 해석 차이"인지 판정해 기록한다
• 라운드 2까지 진행하고 수렴 기준(최댓값÷최솟값 ≤ 1.5)을 충족했는지 확인한다

과제 2 — PERT 신뢰수준 계산 (20분)

과제 1의 항목들에 O·M·P를 매기고 다음을 계산한다.

1. 항목별 E와 σ, σ²
2. E_total 과 σ_total (제곱합의 제곱근으로)
3. 50%·80%·90% 커밋 값
4. σ를 그냥 더했을 때와 σ_total 의 차이를 적고, 왜 후자가 맞는지 한 문장으로 쓴다

과제 3 — 생산성 기준선 뽑기 (30분)

지금 팀의 테스트 관리 도구와 이슈 트래커에서(접근이 없으면 가상의 4개 릴리스 데이터를 만들어) 다음을 계산한다.

과제 4 — 산정 근거서와 도전 대응 (20분)

과제 1~3의 결과를 "산정 근거서 — 한 장" 형식으로 정리하고, "예산을 30% 줄여 달라"는 요청에 대해 가정을 바꾸는 세 가지 선택지 와 각각의 위험을 붙여 답변을 쓴다.

자가 체크리스트

• 와이드밴드 델파이의 진행 단계를 준비·킥오프·라운드·토론·종료로 설명할 수 있다
• 라운드 1의 큰 편차가 "누가 틀렸나"가 아니라 범위 해석 차이의 신호임을 설명할 수 있다
• 수렴 종료 기준 세 가지를 말하고 하나를 골라 적용할 수 있다
• 항목별 σ를 σ² 합산의 제곱근으로 합치는 이유를 설명하고 계산할 수 있다
• 기대값에 z × σ를 더해 80%·90% 커밋 값을 낼 수 있다
• 독립 가정이 깨지는 상황 세 가지와 보정 방법을 말할 수 있다
• 원자료 다섯 곳에서 생산성 지표 다섯 개를 뽑는 계산식을 쓸 수 있다
• 변동계수로 기준선을 쓸 수 있는지 판정할 수 있다
• 산정 근거서에 가정·미해소 쟁점·재산정 조건을 적을 수 있다
• MRE와 편향을 구분하고 편향의 부호에서 개선점을 찾을 수 있다

흔한 실수

• 델파이를 회의에서 다 같이 숫자를 말하는 방식으로 진행한다. 그 순간 앵커링이 일어나 델파이가 아니라 그냥 회의가 된다. 개별·익명 추정이 먼저다.
• σ를 그냥 더한다. 합계의 표준편차는 분산의 합의 제곱근이다. 더하면 불확실성이 두 배 넘게 부풀려져 오히려 신뢰를 잃는다.
• 기대값을 커밋 값으로 약속한다. 기대값은 성공 확률 50%다. 두 번에 한 번 늦는 약속을 한 셈이 된다.
• 케이스 수를 정규화하지 않고 생산성을 계산한다. 케이스 입도가 다르면 생산성 비교는 무의미하고, 팀 간 비교에 쓰면 해롭다.
• MRE만 보고 편향을 보지 않는다. 항상 같은 방향으로 틀리고 있다면 그건 운이 아니라 고칠 수 있는 구조적 원인이다.
• 산정을 한 번 내고 끝낸다. 정보가 가장 적은 시점의 숫자를 프로젝트 끝까지 들고 간다. 재산정 조건을 근거서에 미리 적어 둔다.
• 가정 목록을 남기지 않는다. 산정이 빗나갔을 때 원인을 추적할 수 없고, "그건 포함 안 된 줄 알았다"는 분쟁으로 끝난다.

참고 자료

• Karl E. Wiegers — Stop Promising Miracles (Wideband Delphi) — 와이드밴드 델파이 세션의 진행 절차와 진행자 역할
• Wikipedia — Wideband delphi — 절차 요약과 원전(Barry Boehm, Software Engineering Economics) 참조
• PMI — PMBOK Guide — 3점 추정(삼각·베타 분포), 유사 추정, 모수 추정, 롤링 웨이브 계획
• ISTQB — CTAL-TM v3.0 — 테스트 산정 기법과 산정 근거 제시
• ISO/IEC/IEEE 29119-2:2021 — 테스트 계획 프로세스의 산정 활동
• 레슨 s2-m04-l04 — 산정의 세 가지 근거, 재작업·대기 시간, 종료 조건
• 레슨 s2-m44-l01 — 위험에서 공수를 도출하고 비즈니스 케이스로 협상하기
• 레슨 s2-m44-l03 — 지표의 정의를 맞추지 않으면 생기는 문제