SPI·CPI 계산법 — EVM 입문

SPI 는 일정 성과, CPI 는 비용 성과를 하나의 숫자로 답한다. 공식은 각각 SPI = EV / PV, CPI = EV / AC 다. 1보다 작으면 계획보다 뒤처졌거나 더 썼다는 뜻이고, 1이면 계획대로다. "80% 쯤 됐습니다"라는 보고를 "SPI 0.86"으로 바꾸는 것이 EVM(Earned Value Management)의 목적이다.

SPI·CPI 가 답하는 질문

두 지표는 서로 다른 질문에 답한다. SPI 는 "계획한 속도로 가고 있는가", CPI 는 "계획한 돈으로 사고 있는가" 다. 둘 다 1을 기준으로 읽으므로, 회의에서 "지금 0.86입니다"라고 말하면 추가 설명 없이 상태가 전달된다 — 이것이 진척 보고를 퍼센트에서 지표로 바꾸는 이유다.

한 가지 주의: 두 지표는 원인을 말하지 않는다. 0.86 이 왜 나왔는지는 지표가 아니라 그 아래 작업별 기여분을 봐야 알 수 있다. 이 글은 세 값(PV·EV·AC)에서 두 지표를 손으로 계산해 보고, 그 숫자를 어떻게 읽는지, 그리고 어느 작업이 그 숫자를 만들었는지 내려가는 순서까지 다룬다. 표의 숫자는 그대로 검산할 수 있다.

먼저 세 값: PV·EV·AC

• PV (Planned Value) — 오늘까지 계획상 완료됐어야 할 가치. 베이스라인에서 나온다.
• EV (Earned Value) — 오늘까지 실제로 완료한 가치. 현재 진척률에서 나온다.
• AC (Actual Cost) — 오늘까지 실제로 투입한 비용. 회계·공수 실적에서 나온다.

여기서 "가치"의 단위가 무엇이냐가 실무의 갈림길이다. 정식 EVM 은 각 작업에 예산(BAC, Budget at Completion)을 배정해 금액으로 계산한다. 비용 데이터가 없는 조직은 대신 가중치(weight)를 가치의 프록시로 쓴다 — 작업의 상대적 크기를 100 으로 나눠 갖는 방식이다.

가중치 방식의 성질을 알아 두면 좋다. BAC 가 금액이 아니라 100 이 되므로 SPI 계산에서 단위가 상쇄되어 사라진다. 즉 비용 데이터가 없어도 SPI 는 계산할 수 있다. 반면 CPI 는 AC 가 필요하므로 비용 데이터 없이는 계산할 수 없다. 이 비대칭이 "간이 EVM = SPI 중심"이라는 실무 관행의 이유다.

SPI 계산 — 예제로

작업 5개, 가중치 합 100 인 프로젝트다. 오늘 기준으로 각 작업의 계획 진척률(베이스라인 시작~종료 사이의 경과 비율)과 실제 진척률을 놓는다.

각 행의 기여분은 가중치 × 진척률 이다. 예를 들어 개발은 30 × 0.40 = 12.0(PV), 30 × 0.20 = 6.0(EV).

• SPI = EV / PV = 55.0 / 64.0 = 0.86
• SV (Schedule Variance) = EV − PV = 55.0 − 64.0 = −9.0 %p

읽는 법: 계획대로라면 지금 64% 를 벌었어야 하는데 55% 를 벌었다. 진척이 계획의 86% 속도로 가고 있다는 뜻이다.

주목할 점은 어느 작업이 문제인지 표가 이미 말해 준다는 것이다. 상세 설계(−3.0)와 개발(−6.0)이 부족분 −9.0 을 전부 만들었다. 전체 SPI 하나만 보는 것보다, 기여분을 작업별로 세워 놓고 큰 음수부터 보는 편이 실행에 가깝다.

CPI 계산 — 예제로

CPI 는 같은 EV 를 비용과 비교한다. 위 프로젝트의 총예산(BAC)이 10억 원이고, 오늘까지 실제로 6.2억 원을 썼다고 하자. EV 는 진척 55% 이므로 금액으로는 5.5억 원이다.

• CPI = EV / AC = 5.5 / 6.2 = 0.89
• CV (Cost Variance) = EV − AC = 5.5 − 6.2 = −0.7억
• EAC (Estimate at Completion) = BAC / CPI = 10.0 / 0.89 = 약 11.2억

읽는 법: 1원어치 일을 하는 데 1.12원을 쓰고 있다. 이 효율이 끝까지 유지되면 총비용은 11.2억이 된다 — 계획보다 1.2억 초과다.

주의: CPI·CV·EAC 는 모두 AC 가 있어야 계산된다. 비용 실적을 프로젝트 관리 도구가 아니라 회계 시스템이 갖고 있는 조직에서는, 이 지표들이 자동으로 나오지 않는다. wbsgantt 도 현재 비용 데이터를 다루지 않기 때문에 SPI 만 계산하고 CPI 는 제공하지 않는다 — 위 계산은 개념 설명이며, 비용 지표는 회계 데이터와 함께 별도로 산출해야 한다.

해석 기준: 0.9 와 1.1 사이

지표는 소수점이 아니라 구간으로 읽는다.

마지막 줄이 중요하다. SPI 가 너무 좋으면 계획이나 측정을 의심하는 것이 정상이다. 실무에서 1.2 가 나오는 프로젝트는 대개 잘하고 있는 것이 아니라, 진척률을 관대하게 매기고 있거나 베이스라인에 여유가 과하게 들어간 것이다.

또 하나: 추세가 값보다 중요하다. SPI 0.92 가 3주 연속 0.92 라면 관리 가능한 상태지만, 0.98 → 0.95 → 0.92 라면 같은 값이라도 다른 이야기다.

진척률을 정직하게 만드는 규칙

SPI 의 신뢰도는 EV 의 신뢰도, 즉 진척률 산정의 정직함에 전부 달려 있다. "80% 완료"가 8주 동안 80% 인 현상이 왜 반복되는지는 '80% 완료'라는 거짓말에서 따로 다뤘고, 여기서는 처방만 정리한다.

• 0/50/100 규칙 — 시작 전 0%, 착수했으면 50%, 완료·인수됐으면 100%. 그 사이 숫자를 만들지 않는다. 짧은 작업에 특히 강력하다.
• 물리적 측정 — "화면 12개 중 7개 완료 = 58%"처럼 셀 수 있는 단위로 센다. 감(感)으로 매긴 퍼센트를 금지하는 것이 핵심이다.
• 완료 기준 선행 — 진척률을 입력하기 전에 그 작업의 완료 기준이 정의돼 있어야 한다. 정의가 없으면 100% 를 판정할 사람이 없다.
• 85% 상한 — 인수·검수가 남은 작업은 95%·99% 로 올리지 않는다. 마지막 15% 가 실제로는 절반의 시간을 먹는다.

이 규칙들의 공통점은 PM 의 재량을 줄이는 것이다. 재량이 있는 곳에 낙관이 들어오고, 낙관이 들어온 EV 로 계산한 SPI 는 위험을 감춘다.

SPI 가 거짓말하는 두 경우

첫째, 베이스라인이 없거나 오래됐다. PV 는 베이스라인에서 나온다. 베이스라인이 없으면 PV 가 없고, SPI 는 계산 자체가 불가능하다. 더 흔한 함정은 변경을 반영하지 않은 낡은 베이스라인이다 — 범위가 늘었는데 기준선은 그대로면 SPI 는 실제보다 나쁘게 나오고, 반대로 슬쩍 기준을 재수립했다면 지연이 통계에서 사라진다. 이 문제의 본질은 일정이 밀린 게 아니라, 기준이 사라진 것이다에 적었다.

둘째, 가중치가 왜곡돼 있다. 가중치 방식에서 EV·PV 는 전부 weight 에 비례한다. 형제 합이 100 이 아니거나, 큰 작업에 작은 가중치가 붙어 있으면 SPI 는 조용히 틀린다. 예컨대 전체 공수의 절반을 먹는 개발 작업에 가중치 10 이 붙어 있으면, 그 작업이 통째로 지연돼도 SPI 는 0.95 근처에 머문다. 그래서 가중치 검증은 SPI 를 보기 전에 끝나 있어야 한다.

프로젝트가 실제로 SPI 로 경고를 받는 장면을 하나 기록해 두었다 — 실행 7주차에 SPI 0.84 가 먼저 울렸고, S-Curve 와 지연 상위 목록으로 원인 작업까지 내려간 과정이 그 ERP 프로젝트, 실행 7주차에 밀리기 시작했다에 있다.

다음에 읽을 것

SPI 를 보려면 그 앞에 세 가지가 서 있어야 한다 — 가중치가 검증된 WBS, 승인된 베이스라인, 정직하게 입력된 진척률.

wbsgantt 는 이 셋을 전제로 SPI 를 자동 계산한다. 가중치는 형제 합이 100 이 되도록 자동으로 채워 주고 어긋나면 위반 배지로 알려 주며, 베이스라인은 불변 스냅샷으로 남고, PV 는 베이스라인 일정을 달력일로 선형 보간해 산출한다. 화면에는 SPI 카드와 함께 계획(PV)·실적(EV) S-Curve, 그리고 지연 기여가 큰 작업 목록이 나란히 놓인다 — 숫자 하나가 아니라 원인 작업까지 내려가는 것이 목적이다. 비용 지표(CPI·EAC)는 비용 baseline 이 들어오는 단계에서 다룰 주제로 남겨 두었다.