진척률 측정 방법 6가지 — 0/100 규칙부터 물리적 측정까지

진척률은 담당자에게 물어보는 숫자가 아니라, 미리 정한 측정 방법이 출력하는 숫자다. "35% 됐습니다"라는 보고에 "그 숫자는 어떻게 나온 겁니까"라고 물었을 때 답이 없다면, 문제는 담당자의 정직성이 아니라 방법의 부재다. PMBok — 정확히는 PMI 의 EVM(Earned Value Management) 실무표준 — 은 진척(EV, Earned Value)을 측정하는 방법을 여섯 가지로 정의하고, 작업의 성격에 따라 골라 쓰게 한다. 이 글은 그 여섯 방법을 정의·계산·맞는 작업·함정 순으로 훑고, 작업 유형별 선택 기준과 손으로 검산할 수 있는 예제 하나로 끝낸다.

왜 방법이 먼저인가

"몇 % 됐어요?"로 수집한 숫자는 사람마다 다른 자(尺)로 잰 길이다. 같은 상태를 놓고도 낙관적인 담당자는 80% 라 하고 신중한 담당자는 60% 라 한다. 그 숫자들을 더하고 평균 내는 순간, 서로 다른 자로 잰 측정값들이 하나의 통계로 둔갑한다.

순서를 바꾸면 문제가 사라진다. 계획 단계에, 작업 단위로, 측정 방법을 먼저 배정한다. "이 작업은 완료 전 0%·완료 후 100%", "이 작업은 화면 개수로 센다"가 정해져 있으면 누가 입력해도 같은 숫자가 나온다. PMI 의 EVM 실무표준이 EV 측정 방법을 별도로 정의해 두는 이유가 이것이다 — 진척률은 수집하는 데이터가 아니라 산출하는 데이터다.

재량 퍼센트가 어떤 병리를 만드는지 — "80% 완료"가 8주 동안 80% 인 현상 — 는 '80% 완료'라는 거짓말에서 따로 다뤘다. 여기서는 그 처방의 원천, 방법 자체를 본다.

고정 공식 — 0/100과 50/50

정의: 작업 상태를 두세 개로만 인정한다. 0/100 규칙은 완료 전 0%, 완료 후 100%. 50/50 규칙은 착수하면 50%, 완료하면 100%. 그 사이 숫자는 존재하지 않는다.

계산: 판정할 것은 상태뿐이다 — 착수했는가, 완료·인수됐는가. 재량이 들어갈 자리가 없다.

맞는 작업: 1~2 보고주기 안에 끝나는 짧은 작업. 2주짜리 작업이 주간 보고에서 중간값을 가질 이유는 없다 — 이번 주 0(또는 50), 다음 주 100 이면 충분하다.

함정: 긴 작업에 쓰면 계단 왜곡이 생긴다. 8주짜리 작업에 0/100 을 붙이면 7주 동안 EV 가 0 이었다가 8주차에 한꺼번에 100 이 된다. 그 7주 동안 일정 지표는 실제보다 나쁘게 나온다. 고정 공식은 짧은 작업 전용이다.

가중 마일스톤

정의: 긴 작업을 중간 산출물(마일스톤)로 자르고 각각에 가중치를 배정한 뒤, 통과한 마일스톤의 가중치 합만 진척으로 인정한다.

계산: 설계서 제출 30·리뷰 통과 40·최종 승인 30 으로 나눴다면, 리뷰까지 통과한 시점의 진척률은 70% 다. 마일스톤 사이의 어중간한 상태는 직전 마일스톤 값에 머문다.

맞는 작업: 길고(3 보고주기 이상), 중간 산출물이 명확한 작업. 고정 공식의 계단 왜곡을 마일스톤 개수만큼 잘게 쪼개는 방법이다.

함정: 마일스톤의 완료 기준이 모호하면 이 방법은 재량 퍼센트로 퇴화한다. "설계 리뷰 통과"가 지적 사항 0건을 뜻하는지 회의 개최를 뜻하는지 계획 때 정의해 두지 않으면, 판정이 다시 의견이 된다.

퍼센트 완료 — 가장 흔하고 가장 위험하다

정의: 담당자가 재량으로 추정한 퍼센트를 그대로 쓴다. 대부분의 도구가 기본값으로 제공하고, 대부분의 조직이 실제로 쓰는 방법이다.

계산: 없다 — 그것이 문제다. 산출 근거가 담당자의 머릿속에만 있다.

맞는 작업: 다른 방법이 전부 안 맞을 때의 마지막 선택지다. 단, 두 가지 안전장치와 함께만 쓴다. 첫째, 완료 기준 선행 — 진척률을 입력하기 전에 그 작업의 완료 기준이 문서로 정의돼 있어야 한다. 둘째, 85% 상한 — 인수·검수가 남은 작업은 90%·95% 로 올리지 않는다. 마지막 15% 가 실제로는 절반의 시간을 먹는다.

함정: 방법 자체가 함정이다. 낙관은 언제나 재량이 있는 곳으로 들어온다. 안전장치 없이 쓰는 퍼센트 완료는 측정이 아니라 수집이다.

물리적 측정

정의: 셀 수 있는 단위로 센다. 화면 12개 중 9개 완료면 75% — 개수가 곧 진척률이다.

계산: 완료 단위 ÷ 전체 단위. 판정할 것은 각 단위의 완료 여부뿐이고, 완료 기준만 있으면 그것은 의견이 아니라 사실 확인이다.

맞는 작업: 반복 단위가 있는 작업의 최선이다. 화면·API·테스트 케이스·이관 대상 테이블·도면 — 산출물을 셀 수 있으면 이 방법이 이긴다.

함정: 단위 크기가 심하게 다르면 왜곡된다. 열두 화면 중 남은 세 개가 가장 복잡한 화면들이라면 75% 는 과대평가다. 난이도 편차가 크면 단위에 가중치를 두거나(사실상 가중 마일스톤이 된다) 단위를 더 잘게 쪼갠다.

배분 노력과 LOE

남은 두 방법은 자기 산출물로 측정할 수 없는 작업을 위한 것이다.

배분 노력(Apportioned Effort): 기준이 되는 다른 작업의 진척에 비례해서 따라가는 지원 작업에 쓴다. 개발을 따라다니는 품질 검토·기술 문서화가 전형이다. 기준 작업이 70% 면 지원 작업도 70% — 별도 측정이 없다.

LOE(Level of Effort): 시간 경과가 곧 진척인 작업에 쓴다. PM 업무·회의체 운영·환경 유지보수처럼 기간 내내 균일하게 계속되는 일이 대상이다. 전체 기간의 60% 가 지났으면 진척률 60% 다.

함정: LOE 는 정의상 EV 가 PV 를 정확히 따라간다 — 지연이라는 개념이 없다. 그래서 프로젝트에서 LOE 비중이 크면 SPI 가 1 쪽으로 무뎌진다. 실제 작업이 절반씩 밀려도 LOE 가 가중치의 큰 몫을 차지하면 지표는 그만큼 덜 나빠진다. LOE 는 전체 가중치의 소수로 묶어 두는 것이 안전하다.

어느 방법을 쓸 것인가

여섯 방법은 우열이 아니라 분담이다. 작업의 성격이 방법을 고른다.

위에서 아래로 읽어, 먼저 맞는 행이 그 작업의 방법이다. 퍼센트 완료가 마지막 행인 것은 우연이 아니다 — 재량은 다른 수단이 전부 소진된 뒤의 선택지이고, 그때도 안전장치 두 개를 달고 온다.

검산 예제 — 다섯 작업, 다섯 방법

가중치 합이 100 인 다섯 작업에 서로 다른 방법을 배정하고, 어느 한 주의 상태 스냅샷을 놓았다. 표의 숫자는 그대로 검산할 수 있다.

각 행의 기여분은 가중치 × 진척률 이다. 개발은 마일스톤 M1(30)·M2(40) 을 통과했으므로 진척률 70%, 기여분은 40 × 0.70 = 28.0. 통합 테스트는 착수했으므로 50/50 규칙에 따라 50%, 기여분은 20 × 0.50 = 10.0.

전체 진척률 69.0% 는 의견이 아니라 계산이다. 다섯 명 중 누구에게도 "몇 % 같습니까"라고 묻지 않았다 — 상태 사실(완료·개수·마일스톤 통과·착수·기간 경과)만 수집했고, 방법이 숫자를 출력했다.

그리고 이 69.0 이 그대로 EV 가 된다. 베이스라인에서 나온 PV 와 나란히 놓으면 일정 성과 지표가 나온다 — 그 계산과 해석은 SPI·CPI 계산법에서 이어진다.

도구에서의 운용

여섯 방법의 공통점이 하나 있다. 어떤 방법을 쓰든 최종 출력은 % 하나다. 도구에 저장되는 것은 그 숫자이고, 방법은 그 숫자가 나오기까지의 규약이다.

wbsgantt 의 구조도 그렇다 — leaf 작업에 진척률을 입력하면 weight 로 상위까지 rollup 되어 프로젝트 전체 진척과 EV 가 계산된다. 측정 방법 자체를 도구가 강제하지는 않는다 — 마일스톤 체크리스트나 고정 공식 잠금 같은 방법별 자동화는 없다. 그래서 방법은 팀 규약으로 세운다. 작업별 측정 방법과 완료 기준을 WBS Dictionary 에 적어 두면, 진척률을 입력하는 순간마다 그 산출 근거가 작업 옆에 붙어 있다.

이렇게 입력된 진척률이 실제로 경고를 울리는 장면을 하나 기록해 두었다 — 실행 7주차에 SPI 0.84 가 먼저 울렸고, 원인 작업까지 내려간 과정이 그 ERP 프로젝트, 실행 7주차에 밀리기 시작했다에 있다.

다음에 읽을 것

이 글은 삼부작의 가운데 편이다. 첫 편 "'80% 완료'라는 거짓말"이 문제 제기였다 — 재량 퍼센트가 왜 8주 동안 80% 에 머무는가. 본 글은 그 처방의 원천인 여섯 가지 측정 방법과 작업 유형별 선택 기준을 다뤘다. 마지막 편 "SPI·CPI 계산법"은 그렇게 얻은 진척률이 지표가 되는 곳이다 — 방법이 출력한 EV 를 베이스라인의 PV 와 비교해 일정 성과를 하나의 숫자로 읽는다. 문제를 알고, 방법을 정하고, 지표로 읽는다 — 이 순서가 진척 관리의 전부다.