3줄 요약
- PMBOK 6장 일정 관리의 핵심은 크리티컬 패스(CPM) — 가장 긴 경로에 있는 작업이 지연되면 전체 프로젝트가 지연된다.
- 공수 산정은 구조적으로 틀릴 수밖에 없다. 3점 추정과 팀 합의로 “왜 틀렸는지”를 설명할 수 있는 근거를 만드는 게 목표다.
- PSTA는 Action에 시작일·종료일·상태를 부여해 기본적인 일정 추적을 지원하지만, 의존성·크리티컬 패스·간트 차트는 지원하지 않는다.
“3주면 됩니다.” — 그 말을 믿었다가 6주째 여전히 ‘거의 다 됐습니다’를 듣고 있는 PM이 이 세상에 얼마나 많을까. PMBOK 6장은 바로 그 문제를 다룬다.
일정이 지연되지 않는 프로젝트는 없다. 하지만 “왜 지연됐는지”를 설명하지 못하는 PM과 “이 작업이 지연되면 전체가 밀린다”는 걸 미리 알고 있는 PM 사이에는 큰 차이가 있다. PMBOK 6장 일정 관리는 공수 산정, 크리티컬 패스, 간트 차트, 일정 산정 기법을 체계적으로 다루며 그 차이를 만드는 개념적 틀을 제공한다. 이 장을 읽고 나서 바뀐 것은 하나였다. “일정이 틀렸다”가 아니라 “어떤 가정이 틀렸고, 그래서 어디서 밀렸다”고 말할 수 있게 됐다는 것.
📖 PMBOK이 말하는 일정 관리: 크리티컬 패스와 3점 추정
PMBOK 6장은 일정 관리를 크게 다섯 단계로 구조화한다. 활동 정의 → 활동 순서 배열 → 기간 산정 → 일정 개발 → 일정 통제. 각 단계는 연결되어 있고, 앞 단계 산출물이 다음 단계 입력이 된다.
크리티컬 패스(CPM, Critical Path Method)란, 프로젝트 내 모든 작업 경로 중 가장 긴 경로를 말한다. 이 경로에 놓인 작업은 여유 시간(float)이 0이기 때문에, 단 하루라도 지연되면 전체 프로젝트 완료 일정이 그대로 밀린다. 반대로 크리티컬 패스에 없는 작업은 어느 정도 지연돼도 전체에 영향을 주지 않는다. 이것이 CPM의 핵심 통찰이다. 어디가 진짜 병목인지를 드러내는 도구.
기간 산정에서 PMBOK이 소개하는 3점 추정(Three-Point Estimating)은 PERT 기법을 기반으로 한다. 낙관값(O), 비관값(P), 최빈값(M) 세 가지 시나리오를 산정한 뒤 가중 평균으로 기대 기간을 구한다. 공식은 (O + 4M + P) / 6. 이 접근법의 핵심은 불확실성을 숨기지 않는다는 점이다. “3주입니다”가 아니라 “잘 되면 2주, 문제가 생기면 5주, 가장 가능성 높은 건 3주”라고 말하게 만든다.
그 외에 간트 차트는 작업과 기간을 시각적으로 표현하는 가장 범용적인 일정 도구이며, 자원 평준화(Resource Leveling)는 특정 시점에 자원이 초과 할당되는 것을 방지하기 위해 일정을 조정하는 기법이다. 선후행 의존성(FS·SS·FF·SF)을 정의하는 것도 이 장에서 다룬다.
✅ 읽으며 좋았던 점: 병목을 보이게 만드는 구조
이 장에서 가장 인상 깊었던 것은 두 가지였다.
첫째, 의존성을 명시적으로 정의하게 만든다. 선후행 관계(A가 끝나야 B를 시작할 수 있는가, 동시에 할 수 있는가)를 그림으로 그리는 것 자체가 팀이 공유하지 못했던 암묵적 가정을 수면 위로 올린다. “그거 당연히 기다려야 하는 거 아닌가요?”라는 말이 나올 때, 그게 당연하지 않았음을 발견하게 된다.
둘째, 3점 추정이 불확실성을 정면으로 인정하는 방식이라는 점. “모른다”를 숨기지 않고 세 가지 시나리오로 구조화하면, 나중에 틀렸을 때 “왜 틀렸는가”를 분석할 수 있다. 낙관 시나리오가 붕괴됐는지, 비관 시나리오가 현실이 됐는지. 그 분석이 다음 프로젝트의 입력이 된다.
⚠️ 공수 산정은 왜 매번 틀리나 — IT 현장과의 괴리
PMBOK이 설명하는 일정 관리 프로세스는 논리적으로 완결돼 있다. 문제는 SW 개발 현장에서 이 논리가 작동하는 전제 조건이 잘 충족되지 않는다는 것이다.
- 요구사항이 고정돼 있지 않다. PMBOK 일정 관리는 범위가 확정된 상태에서 활동을 정의하고 기간을 산정하는 것을 전제한다. 하지만 실제 SW 프로젝트에서 요구사항은 기획 단계부터 개발 중간까지 계속 바뀐다. 요구사항이 바뀌는 순간 크리티컬 패스는 무력화된다.
- 과거 데이터가 없거나 의미가 없다. 3점 추정이 제대로 작동하려면 유사 작업의 실적 데이터가 있어야 한다. 하지만 창의적·비반복 작업이 많은 SW 개발에서 “이전에 비슷한 걸 만들어봤다”는 전제가 성립하지 않는 경우가 많다. 추정의 추정이 된다.
- 개인 의존도가 높다. 자원 평준화는 자원을 교환 가능한 단위로 다루지만, SW 개발에서는 특정 모듈을 아는 사람, 특정 기술을 가진 사람이 병목이 되는 경우가 많다. 사람은 평준화되지 않는다.
- 간트 차트가 실제와 갈라진다. 프로젝트 초기에 공들여 만든 간트 차트는 첫 번째 지연이 발생하는 순간부터 현실과 멀어지기 시작하고, 결국 아무도 보지 않는 문서가 된다.
가장 근본적인 문제는 이것이다. SW 공수 산정은 구조적으로 틀릴 수밖에 없다. 새로운 것을 만드는 작업을 만들어보기 전에 얼마나 걸릴지 정확히 아는 것은 불가능에 가깝다. PMBOK은 이 불확실성을 3점 추정으로 인정하지만, 현장에서 클라이언트나 경영진은 여전히 단일 날짜를 요구한다.
🔧 실전 번역: 그래서 IT PM은 일정을 어떻게 관리하나
정석의 한계를 알면서도 일정은 관리해야 한다. 현장에서 실제로 작동하는 방법들을 정리했다.
- 3점 추정 + 팀 합의 추정(플래닝 포커). 혼자 산정하지 않는다. 개발자가 직접 낙관·비관·최빈을 제시하게 하면 숨겨진 리스크가 드러난다. 플래닝 포커처럼 팀이 동시에 카드를 내는 방식은 앵커링(특정 숫자에 끌려가는 현상)을 방지한다.
- 불확실성엔 버퍼(여유)를 명시적으로 확보. “20% 버퍼”를 숨기지 말고, “이 산정에는 요구사항 변경 여지 10%, 기술 불확실성 10%가 포함됩니다”라고 설명한다. 버퍼는 PM의 비밀 창고가 아니라 공개된 리스크 대응이다.
- 세부 간트보다 마일스톤만 고정. 3개월 프로젝트를 날짜 단위로 쪼갠 간트는 첫 주부터 틀린다. 대신 “MVP 완성 / 베타 오픈 / 출시”처럼 핵심 마일스톤만 고정하고, 그 사이 세부 일정은 스프린트 단위로 조정한다.
- 속도(velocity) 기반 예측. 애자일 팀이라면 스프린트를 몇 번 돌고 나서 팀의 평균 처리량(velocity)이 나온다. 그 숫자로 “남은 백로그를 소화하려면 몇 스프린트가 필요한가”를 예측하면, 초기 추정보다 훨씬 현실적인 일정이 나온다.
- 산정 근거를 문서화. 지연이 발생했을 때 “왜 틀렸는가”를 분석하려면, 처음 어떤 가정으로 산정했는지 기록이 있어야 한다. “3주라고 했던 이유: 유사 작업 실적 없음, API 연동 복잡도 낙관 가정, 요구사항 미확정 리스크 고려 안 함.” 이 기록이 다음 프로젝트의 입력이 된다.
크리티컬 패스 개념도 실전에서 완전히 포기할 필요는 없다. 복잡한 CPM 다이어그램이 아니어도 “이 작업이 늦어지면 전체가 밀린다”는 감각을 팀이 공유하는 것은 중요하다. 주간 스탠드업에서 “지금 크리티컬 패스에 있는 작업이 무엇인가”를 확인하는 것만으로도 충분히 가치가 있다.
🟥 PSTA로 보면 / 🟨 PSTA도 아쉬운 점
PSTA로 보면
PSTA에서 일정 관리의 핵심 단위는 Action이다. 각 Action에 시작일·종료일·상태를 부여할 수 있고, Service → Action 계층에서 하위 Action의 상태가 자동으로 상위에 집계된다. “이 기능이 몇 % 완료됐는가”를 별도로 보고할 필요 없이 Action 상태만 갱신하면 된다. 회의에서 ‘대충 다 됐다’는 구두 보고가 아니라, 상태값으로 진행을 추적하는 것이 가능해진다.
다만 PSTA도 솔직히 말해야 할 게 있다. 선후행 의존성, 크리티컬 패스, 간트 차트, 스프린트(반복 주기)는 지원하지 않는다. A가 완료돼야 B를 시작할 수 있다는 의존성을 시스템이 강제하거나 시각화하는 기능이 없다. 일정망이 복잡한 대형 프로젝트에서는 이 부분이 아쉬운 게 사실이다. 그런 팀이라면 MS Project나 Jira 같은 전문 일정 관리 도구를 병행하거나, PSTA를 마일스톤·업무 배정 레이어로만 활용하는 방식을 고려해야 한다.
🎓 이 장을 떼면 당신은 이것을 할 수 있다
- 3점 추정(낙관·비관·최빈)으로 단일 숫자가 아닌 근거 있는 일정 범위를 제시할 수 있다.
- 크리티컬 패스 개념을 활용해 팀에서 “지금 진짜 병목이 어디인가”를 물을 수 있다.
- 일정 지연이 발생했을 때 “누가 잘못했나”가 아니라 “어떤 가정이 깨졌나“로 원인을 분석할 수 있다.
- 간트 차트를 세부 계획보다 마일스톤 커뮤니케이션 도구로 전략적으로 사용할 수 있다.
- 산정 근거를 문서화해 다음 프로젝트의 추정 정확도를 높이는 습관을 만들 수 있다.
❓ FAQ
공수 산정은 왜 매번 틀리나?
SW 개발은 새로운 것을 만드는 창의적 작업이라, 만들어보기 전에 정확히 얼마나 걸릴지 아는 것이 구조적으로 어렵다. 여기에 요구사항 변경, 기술 부채, 예상 못한 연동 이슈가 더해진다. 목표는 “정확히 맞추는 것”이 아니라, “왜 틀렸는지 설명할 수 있는 근거를 만드는 것”이다. 그 근거가 다음 산정을 개선한다.
크리티컬 패스(Critical Path)란 정확히 무엇인가?
프로젝트의 모든 작업 경로 중 가장 긴 경로다. 이 경로에 있는 작업은 여유(float)가 0이므로, 단 하루 지연되면 전체 프로젝트 완료일이 그만큼 밀린다. 반대로 크리티컬 패스에 없는 작업은 어느 정도 여유가 있다. PM이 가장 집중해서 모니터링해야 할 작업이 크리티컬 패스 위에 있다.
애자일 팀은 일정 산정을 어떻게 하나?
스토리 포인트와 팀 속도(velocity)를 기반으로 한다. 스프린트를 몇 번 반복하면 팀이 평균적으로 몇 포인트를 처리하는지 데이터가 쌓이고, 그 숫자로 남은 백로그를 언제 소화할 수 있을지 예측한다. 초기 추정보다 실적 기반 예측이 현실적이기 때문에, 빠른 주기로 데이터를 축적하는 것이 핵심이다.
간트 차트는 SW 프로젝트에 맞나?
요구사항이 고정된 예측형(Waterfall) 프로젝트에서는 유용하다. 하지만 변화가 잦은 SW 프로젝트에서는 세부 간트가 금방 현실과 멀어진다. 이럴 때는 날짜 단위 세부 계획보다 주요 마일스톤만 표시하는 간단한 간트가 더 실용적이다. 이해관계자와 소통하는 커뮤니케이션 도구로 활용하되, 내부 일정은 스프린트 단위로 유연하게 운영하는 것이 균형 잡힌 접근이다.
일정 관리에 대해 더 이야기하고 싶다면, 주니크 문의 페이지에서 연락주시거나 PSTA를 직접 살펴보시기 바란다.
『PMBOK 완독기』 시리즈
← 이전: 03. 범위관리: WBS와 스코프 크립 (5장)
→ 다음: 05. 원가관리: EVM·번다운 (7장)
