CPM과 CCPM으로 프로젝트 일정과 자원 제약 관리하기
CPM과 CCPM의 일정 산정 방식, 임계 경로와 임계 사슬, 버퍼 관리 및 실무 적용 기준을 정리한다.
2026-08-14 · 최초 발행 2025-05-23
일정 지연을 만드는 경로와 제약을 구분하기
CPM(Critical Path Method)과 CCPM(Critical Chain Project Management)은 모두 프로젝트 완료 시점을 관리하기 위한 방법론이다. 다만 CPM은 작업 사이의 의존성에 집중하고, CCPM은 여기에 자원 제약과 작업자의 행동 요소까지 포함한다.
CPM은 1950년대에 개발된 전통적인 일정 관리 기법이다. 작업 간 선후 관계를 바탕으로 가장 오래 걸리는 경로, 즉 임계 경로를 찾아 프로젝트 완료 기간을 결정한다. CCPM은 1997년 Goldratt가 제안했으며, 자원 경쟁을 반영하고 개별 작업에 흩어진 안전 여유를 버퍼로 재배치한다.
CPM에서 확인해야 할 일정 구조
CPM의 네트워크를 구성하려면 작업, 이정표, 의존성, 임계 경로, 여유 시간을 분명히 구분해야 한다.
- 작업(Activity): 프로젝트를 이루는 개별 단위 작업
- 이정표(Milestone): 중요한 사건 또는 진행 단계
- 의존성(Dependency): 작업 사이의 선후 관계
- 임계 경로(Critical Path): 프로젝트 완료까지 가장 오래 걸리는 작업 경로
- 여유 시간(Float/Slack): 작업이 지연되어도 전체 일정에 영향을 주지 않는 시간
소프트웨어 개발 프로젝트를 예로 들면 작업의 기간과 관계는 다음과 같이 배치할 수 있다.
작업 관계를 네트워크로 보면 백엔드 개발 경로가 전체 완료 시점을 결정하는 것을 확인할 수 있다.
이 예시의 임계 경로는 요구사항 분석 → 시스템 설계 → 백엔드 개발 → 통합 테스트 → 성능 테스트 → 시스템 배포 → 사용자 교육이다. 총 프로젝트 기간은 10 + 15 + 20 + 8 + 5 + 3 + 7 = 68일이며, 백엔드 개발·통합 테스트·성능 테스트·시스템 배포·사용자 교육이 임계 작업에 해당한다.
여유 시간을 계산해 일정 변경에 대응하기
CPM 계산은 순방향 계산과 역방향 계산을 함께 사용한다. 순방향 계산에서는 시작일(ES)을 선행 작업의 최대 종료일로 정하고, 종료일(EF)은 시작일에 작업 기간을 더해 구한다. 역방향 계산에서는 늦은 종료일(LF)을 후속 작업의 최소 시작일로 정하며, 늦은 시작일(LS)은 늦은 종료일에서 작업 기간을 뺀 값이다.
총 여유(Total Float)는 LS - ES 또는 LF - EF로 계산한다. 임계 경로에 있는 작업의 여유 시간은 0이다.
데이터베이스 구현 작업을 적용하면 다음과 같다.
- ES = 25일: 요구사항 분석 10일과 시스템 설계 15일의 합
- EF = 37일: ES에 작업 기간 12일을 더한 값
- LF = 45일: 통합 테스트 시작일
- LS = 33일: LF에서 작업 기간 12일을 뺀 값
- 총 여유 = 8일: 비임계 작업
CCPM은 자원 경쟁을 일정에 포함한다
CCPM은 작업 의존성뿐 아니라 자원 경쟁까지 반영한다. 개별 작업에 분산된 안전 여유를 제거하고 프로젝트 버퍼, 피딩 버퍼, 자원 버퍼로 통합하며, 학생 증후군·파킨슨 법칙·멀티태스킹 같은 행동 요소도 관리 대상으로 본다.
앞선 프로젝트에 CCPM을 적용할 때는 먼저 작업 기간을 50% 확률로 완료 가능한 수준으로 재산정한다.
- 요구사항 분석: 10일 → 6일
- 시스템 설계: 15일 → 9일
- 데이터베이스 구현: 12일 → 7일
- 백엔드 개발: 20일 → 12일
- 프론트엔드 개발: 18일 → 11일
- 통합 테스트: 8일 → 5일
- 성능 테스트: 5일 → 3일
- 시스템 배포: 3일 → 2일
- 사용자 교육: 7일 → 4일
백엔드 개발과 프론트엔드 개발의 담당자가 같다고 가정하면 두 작업은 동시에 진행할 수 없다. 따라서 자원 제약을 일정에 반영해 순차 배치한다.
이때 자원 제약을 포함한 최장 경로, 즉 임계 사슬은 요구사항 분석 → 시스템 설계 → 백엔드 개발 → 프론트엔드 개발 → 통합 테스트 → 성능 테스트 → 시스템 배포 → 사용자 교육이다. 총 기간은 6 + 9 + 12 + 11 + 5 + 3 + 2 + 4 = 52일이다.
프로젝트 버퍼는 임계 사슬 작업 기간의 50%로 두며, 예시에서는 26일의 50%인 약 13일로 제시된다. 데이터베이스 구현 뒤 통합 테스트로 이어지는 경로에는 피딩 버퍼를 둔다.
버퍼 소비율로 위험 신호를 읽는다
CCPM에서는 계획 대비 실적보다 버퍼가 얼마나 소비됐는지를 중심으로 진행 상태를 판단한다.
프로젝트가 30일 경과한 시점에 임계 사슬상 완료되어야 할 작업이 요구사항 분석, 시스템 설계, 백엔드 개발, 프론트엔드 개발이라면 총 작업량은 38일이다. 실제로 요구사항 분석, 시스템 설계, 백엔드 개발만 완료되어 27일에 머물렀다면 지연은 11일이다. 전체 버퍼 13일 가운데 11일을 소비한 약 85% 상태이므로 빨간색 영역에 해당하며 즉각적인 조치가 필요하다.
일정 의존성과 자원 제약의 관점 차이
| 특성 | CPM | CCPM |
|---|---|---|
| 초점 | 작업 의존성 | 자원 제약 + 작업 의존성 |
| 일정 산정 | 안전 여유 포함된 보수적 일정 | 50% 확률의 공격적 일정 + 버퍼 |
| 안전 여유 | 개별 작업에 분산 | 프로젝트 끝과 주요 경로 결합점에 집중(버퍼) |
| 진행 관리 | 계획 대비 실적 | 버퍼 소비율 |
| 다중 프로젝트 | 개별 관리 | 용량 제약 고려한 통합 관리 |
IT 시스템 통합 프로젝트에서 초기에는 CPM으로 9개월 일정을 세웠지만, 핵심 개발자 리소스 부족으로 작업 지연이 발생한 사례가 있다. 작업 기간을 축소하고 프로젝트 버퍼 25일과 자원 버퍼를 배치하는 CCPM을 적용한 뒤 자원 충돌을 사전에 감지했으며, 통합 테스트 일정을 조정해 8.5개월 내에 완료했다.
건설 프로젝트에서는 전통적 CPM 적용 시 18개월을 예상했고 각 작업에 20%의 안전 여유를 포함했다. CCPM을 적용하면서 작업 기간을 30% 줄이고 2개월 프로젝트 버퍼와 핵심 자원인 크레인 일정을 최적화했다. 결과적으로 16개월 내에 완료했고 자원 유휴 시간은 40% 감소했다.
프로젝트에 맞춰 CPM과 CCPM을 조합하는 방법
CPM을 사용할 때는 과거 데이터를 바탕으로 예상 작업 시간을 산정하고, 임계 경로를 주기적으로 다시 계산해 변화에 대응해야 한다. 임계 경로의 중요성을 이해관계자와 공유하고, 비임계 작업의 여유 시간을 자원 최적화에 활용할 수 있다.
CCPM 도입에는 안전 여유 제거에 대한 저항을 다루는 조직 문화 변화 관리가 필요하다. 파일럿 프로젝트로 효과를 검증하고, 참여자가 CCPM 원칙을 이해하도록 교육과 코칭을 제공한다. 버퍼 관리 자동화를 위한 소프트웨어 도구도 활용 대상이다.
복잡한 프로젝트라면 CPM으로 초기 네트워크 다이어그램을 만든 뒤 자원 제약을 식별해 반영할 수 있다. 이후 안전 여유를 버퍼로 통합하고 버퍼 소비를 모니터링하면서 임계 경로와 임계 사슬을 함께 추적한다. 작업 의존성이 중심인 환경에서는 CPM이, 자원 충돌과 불확실성이 큰 환경에서는 CCPM이 더 직접적인 관리 기준이 된다.