PMBOK 완독기 – 05. 원가관리: EVM·번다운, ‘진척 70%’는 왜 못 믿나 (7장)

2026.10.29

·

3줄 요약

  • EVM(획득가치관리)은 PV·EV·AC 세 수치로 일정과 비용을 한 프레임에서 측정하는 원가관리의 정수다.
  • SW 현장에서는 EV 산정 자체가 추정이어서 ‘진척 70%’가 거짓말이 되기 쉽다 — 번다운 차트와 이진 완료 기준이 더 정직하다.
  • PSTA는 하위 Action 완료 상태를 자동 집계해 진척을 수치화하지만, 비용(원가) 축은 없다 — 예산 관리는 별도 도구가 필요하다.

“이 기능 얼마나 됐어요?” “한 70% 정도요.” — 이 대화를 열 번쯤 반복하다 보면, 70%가 영원히 70%인 프로젝트가 있다는 걸 알게 된다.

PMBOK 7장 원가관리(Cost Management)는 그 70%의 거짓말을 수치로 끊어내려는 시도다. EVM, 즉 획득가치관리(Earned Value Management)는 “진척률을 돈의 언어로 환산하면 거짓말이 줄어든다”는 발상이다. 프로젝트 진척률 측정과 원가관리를 한 프레임에 묶으려 한 이 장을 완독하고 나서, 실제로 쓸 수 있는 것과 쓰기 어려운 것을 솔직하게 정리해본다.

Sponsored


📖 EVM과 원가관리, 정석은 무엇을 말하는가

PMBOK 6판 기준으로 원가관리 지식영역은 세 프로세스로 구성된다. 원가 산정(Estimate Costs), 예산 책정(Determine Budget), 원가 통제(Control Costs). 각각 “얼마 들까”, “얼마 쓸 수 있나”, “지금 어떻게 쓰이고 있나”를 다룬다.

이 중 원가 통제의 핵심 도구가 EVM(획득가치관리, Earned Value Management)이다. EVM은 세 가지 기준값을 정의한다.

  • PV(Planned Value, 계획가치) — 지금 시점까지 완료돼 있어야 하는 작업의 예산 금액. “계획대로라면 이 돈어치의 일이 끝나 있어야 한다.”
  • EV(Earned Value, 획득가치) — 실제로 완료된 작업의 예산 금액. “실제로 끝낸 일이 이 돈어치다.”
  • AC(Actual Cost, 실제원가) — 지금까지 실제로 지출한 비용. “여기까지 오는 데 이 돈이 들었다.”

이 세 숫자로 두 가지 성과지수를 뽑는다. SPI(일정성과지수, Schedule Performance Index) = EV / PV, CPI(원가성과지수, Cost Performance Index) = EV / AC. SPI가 1 미만이면 일정이 지연되고 있다는 뜻이고, CPI가 1 미만이면 예산보다 더 쓰고 있다는 뜻이다. 1.0이 딱 맞다. 이 두 지수와 세 가지 기준값을 조합하면 완료 시 예상 원가(EAC, Estimate At Completion)도 계산할 수 있다.

번다운 차트(Burndown Chart)는 EVM과 맥이 닿아 있는 대안적 시각화다. 남은 작업량(이야기 포인트·태스크 수)을 시간 축으로 그려 “이 속도라면 언제 끝나는가”를 직관적으로 보여준다. 스프린트 기반 팀에서는 EVM보다 번다운이 일상 도구로 쓰이는 경우가 많다.


✅ 읽으며 좋았던 점 — 진척을 수치로 보려는 발상

EVM에서 가장 공감한 지점은 주관적 감을 객관 지표로 대체하려는 의도다. “70% 완료”라는 말은 그 자체로 감이다. 누가 측정했고, 무엇을 기준으로 70%인지 불분명하다. EVM은 그 감을 화폐 단위로 환산함으로써 기준을 강제한다. 이미 끝낸 작업의 계획 예산이 전체의 몇 퍼센트냐 — 이 방식은 최소한 “무엇을 완료로 볼 것인가”를 명시적으로 정의하게 만든다.

또 하나 좋은 점은 일정과 비용을 한 프레임에서 보는 통합 시각이다. 일정 지연이 곧 추가 비용이라는 사실을 수식 하나로 드러낸다. SPI와 CPI를 함께 보면 “빠르게 달리고 있지만 돈을 훨씬 많이 쓰는 중”인지, “예산은 맞는데 일정이 밀리는 중”인지가 한눈에 보인다. 이건 말로만 설명할 때보다 훨씬 강력한 의사소통 도구다.


⚠️ IT/SW 현장에서 EVM이 잘 안 되는 이유

솔직하게 말하자. EVM을 SW 프로젝트에 그대로 가져오면 여러 군데서 삐걱거린다.

첫째, AC(실제원가)의 변별력이 약하다. 건설이나 제조에서 원가는 자재·장비·외주비 등 항목이 다양하고 실제로 들쭉날쭉 변한다. 그래서 AC 추적이 의미 있다. 그런데 SW 개발 원가는 대부분 인건비(월 고정)다. 팀원 다섯 명이 이 달에 풀타임으로 일하면, 프로젝트가 잘 되든 안 되든 AC는 거의 동일하다. CPI = EV / AC에서 분모가 거의 상수면, CPI는 사실상 EV 하나만 추적하는 것과 다름없다.

둘째, EV(획득가치) 산정이 자의적이다. EVM의 핵심인 EV는 “완료된 작업의 계획 예산”이다. 이 계산이 성립하려면 각 작업의 계획 예산(PV 분해)이 정확하고, 완료 여부 판단도 명확해야 한다. 그런데 “로그인 기능 완료”가 실제로 몇 퍼센트인가? UI는 됐는데 백엔드 연동이 50%면? 예외처리는? 이런 부분 완료 판단이 결국 담당자의 추정에 의존한다. “이 기능 70% 됐습니다”라는 말을 EV 수치로 올리면, 정밀해 보이는 숫자가 됐지만 내용은 여전히 감이다.

셋째, PV(계획가치) 기준선이 흔들린다. SW 프로젝트에서 요구사항은 살아있다. 기획이 바뀌고, 스코프 크립(Scope Creep)이 일어나고, 우선순위가 조정된다. EVM은 기준선(Baseline) PV가 고정돼야 SPI·CPI가 의미 있다. 기준선이 두 달마다 바뀌면, EVM 차트는 현실이 아니라 기준선 변경 이력을 보여주는 그래프가 된다.


🔧 실전 번역 — SW 팀이 진짜로 쓸 수 있는 진척 측정

EVM을 버리자는 말이 아니다. 적용 가능한 형태로 번역하자는 것이다. 아래는 현장에서 실제로 작동하는 대안과 조합이다.

  • 이진 완료 기준(0-100 룰) — 작업은 “완료/미완료” 두 상태만 인정한다. 70% 같은 부분 완료 없음. DoD(Definition of Done, 완료 정의)를 팀이 사전에 합의하고, 그 기준을 충족하면 100%, 아니면 0%. 이렇게 하면 EV 산정의 자의성이 사라진다.
  • 개수 기반 진척 — 완료된 작업 수 / 전체 작업 수. 예산 환산 없이도 “우리 백로그 50개 중 32개 완료, 64%”는 명확하다. EVM의 핵심 아이디어(완료 기준으로 진척 환산)를 단순화한 버전이다.
  • 번다운 차트 — 남은 작업량(스토리 포인트나 태스크 수)을 매일/매 스프린트 시각화한다. 속도가 꺾이면 바로 보인다. “이 속도라면 마감을 못 지킨다”는 경보를 빨리 줄 수 있다.
  • 칸반 메트릭 — 리드타임·처리량 — 스프린트가 없는 팀에서는 항목 하나가 시작부터 완료까지 얼마나 걸리는지(리드타임), 일정 기간 몇 개를 처리했는지(처리량, Throughput)가 진척의 신뢰 가능한 지표가 된다.

요약하면, SW 팀의 진척 측정 우선순위는 다음과 같다.

  • 1순위: 이진 완료 기준 + 개수 기반 진척(가장 정직, 도입 쉬움)
  • 2순위: 번다운 차트(속도 추세 시각화, 마감 예측)
  • 3순위: 칸반 메트릭(흐름 기반 팀)
  • EVM: 예산이 항목별로 실제로 다르고, 기준선이 안정적인 프로젝트에서만 효용 있음

🟥 PSTA로 보면 — 진척 자동화와 정직한 한계

PSTA에서 하위 Action의 완료 상태는 상위 Service와 Project로 자동 집계된다. 담당자가 Action을 “완료”로 바꾸는 순간, 상위 진행률이 자동으로 업데이트된다. 수기 집계도 없고, “이 기능 몇 % 됐나요?” 감 기반 보고도 없다. 이진 완료 기준을 팀이 지키는 한, 진행률 숫자는 신뢰할 수 있다. EVM의 핵심 아이디어(완료 기준으로 진척 환산)를 단순화해 구현한 셈이다.

🟨 PSTA도 아쉬운 점: PSTA는 진척(스케줄) 축만 자동화한다. 원가(비용) 축은 없다. PV·EV·AC·CPI·EAC를 계산하거나 예산 집행을 추적하는 기능이 없기 때문에, 예산 관리가 중요한 프로젝트라면 재무 도구나 ERP와 병행해야 한다. 진척은 PSTA, 비용은 별도 — 이걸 명확히 해두는 게 좋다.


🎓 이 장을 떼면 당신은 무엇을 할 수 있나

  • PV·EV·AC가 각각 무엇을 뜻하는지, SPI·CPI를 어떻게 읽는지 설명할 수 있다.
  • “진척 70%입니다”라는 보고에서 어떤 질문을 던져야 하는지 안다 — “70%는 어떻게 산정했나요? DoD 기준이 있나요?”
  • EVM을 전면 도입하기 어려운 SW 프로젝트에서, 이진 완료 기준·번다운·칸반 메트릭 중 무엇이 팀에 맞는지 판단할 수 있다.
  • 일정 지연과 원가 초과를 동시에 보고해야 할 때, SPI와 CPI를 이용해 데이터 기반으로 보고서를 구성할 수 있다.
  • 번다운 차트를 그려 마감 예측이 어긋날 때 이해관계자에게 조기 경보를 줄 수 있다.

❓ 자주 묻는 질문

EVM(획득가치관리)이란 무엇인가?

EVM이란 프로젝트의 실제 진척(EV)을 계획 기준(PV)·실제 지출(AC)과 비교해 일정과 원가 성과를 동시에 측정하는 관리 기법이다. SPI(EV/PV)로 일정 편차를, CPI(EV/AC)로 비용 편차를 수치로 파악할 수 있어, 주관적 보고 대신 데이터 기반 진척 파악이 가능하다.

번다운 차트와 EVM의 차이는?

EVM은 비용 단위로 진척을 환산해 일정·원가를 통합 관리하는 정량 기법이고, 번다운 차트는 남은 작업량을 시간 흐름으로 시각화하는 도구다. EVM은 예산 기반 분석에, 번다운은 스프린트·속도 추이 파악에 더 강하다. SW 팀에서는 예산 변별력이 낮아 번다운이 일상 도구로 더 많이 쓰인다.

소규모 SW 팀에 EVM이 꼭 필요한가?

필수는 아니다. EVM은 예산이 항목별로 실제로 달라지고, 기준선이 안정적인 프로젝트(공공·건설·하드웨어 등)에서 효용이 높다. 인건비 중심의 소규모 SW 팀이라면 이진 완료 기준 + 개수 기반 진척 + 번다운이 더 현실적이고 신뢰 가능한 조합이다. EVM의 개념을 이해한 뒤 팀 상황에 맞게 단순화하는 게 핵심이다.

진척률을 어떻게 해야 신뢰할 수 있나?

가장 확실한 방법은 완료 기준을 이진(0/100)으로 고정하는 것이다. 부분 완료를 인정하는 순간 진척률은 담당자의 감이 된다. 팀이 사전에 DoD(완료 정의)를 합의하고, 그 기준을 충족한 작업만 완료로 집계하면, 진척 숫자는 훨씬 신뢰할 수 있다. “이 기능 완료”가 정확히 무엇을 의미하는지 팀이 동의할 때, 진척 측정이 비로소 의미를 가진다.


원가관리 장에서 가장 얻어가야 할 것은 지표 공식이 아니라 “진척을 어떻게 측정 가능하게 만들 것인가”라는 질문이다. EVM의 해법이 현장에 맞지 않더라도, 그 질문 자체는 어떤 팀에나 유효하다. 진척을 신뢰 가능하게 보고하고 싶다면 → psta.app에서 이진 완료 기반 Action 관리를 살펴보거나, 주니크에 문의해보라.


『PMBOK 완독기』 시리즈
← 이전: 04. 일정관리: 공수 산정과 크리티컬 패스 (6장)
→ 다음: 06. 품질관리: DoD와 검수 기준 (8장)


MORE POSTS

다른 글 보기

테크 랩

PMBOK 완독기 – 09. 리스크관리: 아무도 안 보는 관리대장을 살리는 법 (11장)

리스크 관리 대장과 확률×영향 분석의 핵심, 그리고 방치되는 대장을 경량 Top 5 로그로 살아있게 유지하는 법.
2026.11.04
테크 랩

PMBOK 완독기 – 08. 의사소통관리: 보고 오버헤드 줄이기 (10장)

채널 수 폭증 공식과, 주간보고에 반나절을 쓰는 오버헤드를 자동 집계·push 알림으로 줄이는 실전 번역.
2026.11.03
테크 랩

PMBOK 완독기 – 07. 자원관리: RACI와 역할 분담 (9장)

RACI(책임배정매트릭스)와 ‘Accountable 1명’ 원칙으로 역할 혼선을 없애는 법, 그리고 워크로드 관리의 현실.
2026.11.02

프로젝트 문의 환영합니다

기획부터 개발, 운영까지 함께 만들어 드립니다.

무료 3분 자가진단

우리 회사, 자체 클라우드가 답일까?

AWS vs 자체 인프라 · 11개 항목 3분 체크