크리티컬 패스(핵심경로) 계산법 — 어떤 작업이 늦으면 전체가 늦어지나
"이 작업 이틀 늦어도 괜찮아요?"라는 질문에 바로 답할 수 있다면 일정 관리의 절반은 끝난 것입니다. 답을 주는 것이 크리티컬 패스(critical path, 핵심경로)입니다. 어떤 작업은 일주일 늦어도 마감이 안 바뀌고, 어떤 작업은 하루만 늦어도 전체가 밀립니다. 이 글에서는 의존관계에서 출발해 전진 계산·후진 계산·여유시간을 7개 작업 예시로 손으로 직접 계산해 보고, 핵심경로가 여러 개일 때, 일정을 줄여야 할 때, 그리고 간트차트에서 핵심경로를 읽는 방법까지 다룹니다. 간트차트 보는 법에서 한 줄로 언급했던 개념을 계산할 수 있는 수준까지 내려갑니다. 계산으로 찾은 핵심경로 끝에 여유를 얼마나 둘지는 일정 버퍼와 리스크 관리 기초에서 이어집니다.
의존관계 — 선행 작업과 후행 작업
핵심경로 계산의 재료는 두 가지뿐입니다. 각 작업의 기간과 작업 사이의 순서(의존관계)입니다. "B는 A가 끝나야 시작할 수 있다"에서 A는 B의 선행 작업, B는 A의 후행 작업입니다.
의존관계는 이론적으로 네 종류(끝나야 시작, 시작해야 시작, 끝나야 끝, 시작해야 끝)가 있지만, 실무에서 쓰는 의존관계는 대부분 "끝나야 시작(Finish-to-Start)"입니다. 이 글도 그 경우만 다룹니다. 중요한 것은 의존관계를 진짜 필요한 것만 넣는 일입니다. "디자인이 끝나야 개발 시작"은 진짜 의존이지만, "같은 사람이 하니까 순서대로"는 자원 제약이지 논리적 의존이 아닙니다. 의존관계를 습관적으로 다 걸어 버리면 모든 작업이 한 줄로 늘어서고 핵심경로 계산이 의미를 잃습니다.
네트워크 다이어그램으로 그리기
작업을 상자로, 의존관계를 화살표로 그린 것이 네트워크 다이어그램입니다. 아래 예시를 끝까지 사용합니다. 작은 웹 기능 하나를 만드는 7개 작업이고, 기간은 영업일입니다.
| 작업 | 내용 | 기간(일) | 선행 작업 |
|---|---|---|---|
| A | 요구사항 정리 | 3 | 없음 |
| B | 화면 설계 | 4 | A |
| C | DB 설계 | 2 | A |
| D | 프론트 개발 | 6 | B |
| E | 백엔드 개발 | 5 | C |
| F | 통합 테스트 | 3 | D, E |
| G | 배포 | 1 | F |
그림으로 그리면 A에서 두 갈래(B→D, C→E)로 갈라졌다가 F에서 다시 합쳐진 뒤 G로 끝나는 모양입니다. 시작에서 끝까지 가는 경로는 두 개입니다.
- 경로 1: A → B → D → F → G = 3 + 4 + 6 + 3 + 1 = 17일
- 경로 2: A → C → E → F → G = 3 + 2 + 5 + 3 + 1 = 14일
경로가 두세 개뿐이면 이렇게 더해 보는 것만으로도 가장 긴 경로, 즉 핵심경로(17일)를 찾을 수 있습니다. 하지만 경로가 많아지면 어떤 작업에 며칠 여유가 있는지까지는 알 수 없습니다. 그래서 전진·후진 계산이 필요합니다.
전진 계산 — 가장 빨리 시작·끝낼 수 있는 시점(ES/EF)
전진 계산은 시작에서 끝 방향으로, 각 작업의 가장 빠른 시작(ES, Early Start)과 가장 빠른 종료(EF, Early Finish)를 구합니다. 규칙은 두 줄입니다.
- EF = ES + 기간
- ES = 선행 작업들의 EF 중 가장 큰 값 (선행이 없으면 0)
여기서는 프로젝트 시작 시점을 0으로 두는 방식을 씁니다. "ES 3"은 3일이 지난 시점(즉 4일째 아침)에 시작한다는 뜻입니다. 교과서에 따라 첫날을 1로 두고 EF = ES + 기간 − 1로 쓰기도 하는데, 결과는 같으니 한 가지로 통일해서 쓰면 됩니다.
| 작업 | 기간 | ES | EF | 계산 근거 |
|---|---|---|---|---|
| A | 3 | 0 | 3 | 선행 없음 → ES 0, EF 0+3 |
| B | 4 | 3 | 7 | A의 EF 3 → ES 3, EF 3+4 |
| C | 2 | 3 | 5 | A의 EF 3 → ES 3, EF 3+2 |
| D | 6 | 7 | 13 | B의 EF 7 → ES 7, EF 7+6 |
| E | 5 | 5 | 10 | C의 EF 5 → ES 5, EF 5+5 |
| F | 3 | 13 | 16 | D의 EF 13과 E의 EF 10 중 큰 값 13 → EF 13+3 |
| G | 1 | 16 | 17 | F의 EF 16 → EF 16+1 |
마지막 작업 G의 EF가 17, 즉 이 프로젝트는 아무리 빨라도 17일이 걸립니다. F에서 "큰 값을 택한다"는 부분이 핵심입니다. 통합 테스트는 프론트와 백엔드가 둘 다 끝나야 시작할 수 있으므로, 더 늦게 끝나는 쪽(D, 13일)을 기다려야 합니다.
후진 계산 — 가장 늦게 시작·끝내도 되는 시점(LS/LF)
후진 계산은 끝에서 시작 방향으로 거꾸로 가며, 프로젝트 종료일(17)을 지키는 조건에서 각 작업이 가장 늦게 끝나도 되는 시점(LF, Late Finish)과 가장 늦게 시작해도 되는 시점(LS, Late Start)을 구합니다.
- LS = LF − 기간
- LF = 후행 작업들의 LS 중 가장 작은 값 (후행이 없으면 프로젝트 종료 시점 17)
| 작업 | 기간 | LF | LS | 계산 근거 |
|---|---|---|---|---|
| G | 1 | 17 | 16 | 마지막 작업 → LF 17, LS 17−1 |
| F | 3 | 16 | 13 | G의 LS 16 → LF 16, LS 16−3 |
| D | 6 | 13 | 7 | F의 LS 13 → LF 13, LS 13−6 |
| E | 5 | 13 | 8 | F의 LS 13 → LF 13, LS 13−5 |
| B | 4 | 7 | 3 | D의 LS 7 → LF 7, LS 7−4 |
| C | 2 | 8 | 6 | E의 LS 8 → LF 8, LS 8−2 |
| A | 3 | 3 | 0 | B의 LS 3과 C의 LS 6 중 작은 값 3 → LS 3−3 |
이번에는 A에서 "작은 값을 택한다"가 핵심입니다. A는 B와 C 둘 다의 선행이므로, 더 급한 쪽(B는 3일째에 시작해야 함)에 맞춰 끝나야 합니다.
여유시간 — 총여유와 자유여유
전진·후진 계산이 끝나면 여유시간(float, slack)이 나옵니다. 두 종류를 구분해야 합니다.
- 총여유(Total Float) = LS − ES (또는 LF − EF). 프로젝트 종료일을 바꾸지 않고 이 작업이 늦어질 수 있는 최대 일수입니다.
- 자유여유(Free Float) = 후행 작업들의 ES 중 가장 작은 값 − 이 작업의 EF. 바로 다음 작업의 가장 빠른 시작조차 미루지 않고 늦어질 수 있는 일수입니다.
| 작업 | ES | EF | LS | LF | 총여유 | 자유여유 | 핵심경로 |
|---|---|---|---|---|---|---|---|
| A | 0 | 3 | 0 | 3 | 0 | 0 | 예 |
| B | 3 | 7 | 3 | 7 | 0 | 0 | 예 |
| C | 3 | 5 | 6 | 8 | 3 | 0 (E의 ES 5 − 5) | 아니오 |
| D | 7 | 13 | 7 | 13 | 0 | 0 | 예 |
| E | 5 | 10 | 8 | 13 | 3 | 3 (F의 ES 13 − 10) | 아니오 |
| F | 13 | 16 | 13 | 16 | 0 | 0 | 예 |
| G | 16 | 17 | 16 | 17 | 0 | 0 | 예 |
총여유가 0인 작업 A, B, D, F, G를 이으면 핵심경로 A→B→D→F→G, 17일이 됩니다. 처음에 경로를 더해서 찾은 결과와 일치합니다.
C와 E의 차이를 보세요. 둘 다 총여유는 3일이지만, C의 자유여유는 0입니다. C가 하루 늦으면 종료일은 안 바뀌지만 E는 하루 늦게 시작해야 합니다. C와 E가 다른 담당자라면 C 담당자는 "전체엔 영향 없다"고 안심하고, E 담당자는 갑자기 일정이 밀리는 상황이 생깁니다. 총여유는 경로 전체가 나눠 쓰는 여유라서 C가 3일을 다 쓰면 E의 여유는 0이 됩니다. 이것이 총여유와 자유여유를 구분해야 하는 이유입니다.
핵심경로가 여러 개일 때
예시에서 백엔드 개발 E가 5일이 아니라 8일이었다면 경로 2도 3+2+8+3+1 = 17일이 되어 두 경로가 모두 핵심경로가 됩니다. 이때는 7개 작업 전부 총여유가 0이 되고, 어느 작업이든 하루 늦으면 전체가 늦어집니다.
핵심경로가 여럿이면 프로젝트가 더 취약합니다. 늦어질 수 있는 지점이 그만큼 늘어나기 때문입니다. 실무에서는 총여유가 0인 경로뿐 아니라 여유가 1~2일밖에 없는 준핵심경로도 같이 관리합니다. 예시의 C→E 경로는 여유가 3일이라 여유로워 보이지만, C가 이틀 늦고 E가 이틀 늦으면 그 순간 핵심경로가 바뀝니다.
일정을 줄여야 할 때 — 크래싱과 패스트트래킹
17일이 너무 길어 14일로 줄이라는 요구가 왔다고 합시다. 여유가 있는 C나 E를 줄이는 것은 아무 효과가 없습니다. 핵심경로 위의 작업만 줄여야 종료일이 앞당겨집니다. 방법은 두 가지입니다.
크래싱(crashing) — 자원을 더 넣어 기간을 줄인다
프론트 개발 D(6일)에 개발자를 한 명 더 붙여 4일로 줄이는 식입니다. 비용이 늘고, 사람이 두 배라고 기간이 절반이 되지는 않습니다(인수인계·조율 시간). 핵심경로 작업 중 하루 줄이는 비용이 가장 싼 작업부터 줄이는 것이 원칙입니다.
패스트트래킹(fast tracking) — 순서대로 하던 일을 겹친다
화면 설계 B가 다 끝나기 전에, 확정된 화면부터 프론트 개발 D를 시작하는 식입니다. 비용은 안 들지만 재작업 위험이 생깁니다. 설계가 바뀌면 이미 만든 화면을 고쳐야 하니까요.
어느 쪽이든 핵심경로를 줄이다 보면 어느 순간 다른 경로가 핵심경로가 됩니다. 예시에서 경로 1을 14일까지 줄이면 경로 2(14일)와 같아져 둘 다 핵심경로가 되고, 그 이상 줄이려면 두 경로를 동시에 줄여야 합니다. 단축할 때마다 다시 계산해야 하는 이유입니다.
간트차트에서 핵심경로 읽는 법
네트워크 다이어그램은 계산에는 좋지만 날짜가 안 보입니다. 실제 관리는 간트차트에서 합니다. 핵심경로를 표시하는 기능이 있다면 그 막대들을 보면 되고, 없더라도 다음 특징으로 찾을 수 있습니다.
- 핵심경로 작업들은 막대 끝과 다음 막대 시작 사이에 빈틈이 없습니다. 앞 막대가 끝나는 날 바로 다음 막대가 시작합니다. 단, 이것은 필요조건일 뿐입니다. 예시의 C→E도 빈틈없이 붙어 있지만(C의 자유여유 0) 둘 다 총여유가 3일이라 핵심경로가 아닙니다. 빈틈없는 사슬이 마지막 작업까지 끊기지 않고 이어질 때만 핵심경로입니다.
- 여유가 있는 작업은 막대 뒤에 다음 작업이 시작하기까지 빈 구간이 있습니다. 그 빈 구간의 길이가 자유여유입니다.
- 여러 막대가 한 작업으로 합쳐지는 지점(예시의 F)에서는, 가장 늦게 끝나는 막대가 핵심경로입니다.
- 오늘 날짜선 기준으로, 핵심경로 위에 있는데 진행율이 기간진행율보다 낮은 작업이 있다면 그것이 지금 종료일을 위협하는 작업입니다. 진행율 비교는 진행율 계산법에서 다룹니다.
계산 결과를 실제 날짜로 옮기기
ES·EF는 "시작 후 며칠째"라는 상대 숫자라서 달력에 옮겨야 쓸 수 있습니다. 예시 프로젝트를 2026년 11월 2일(월)에 시작하고 그 사이 공휴일이 없다고 가정하면, ES가 n인 작업은 시작일로부터 n영업일 뒤에 시작하고 EF − 1번째 영업일에 끝납니다.
| 작업 | ES → 시작일 | EF → 종료일 | 늦어도 되는 시작일(LS) |
|---|---|---|---|
| A | 0 → 11/2(월) | 3 → 11/4(수) | 11/2 (여유 없음) |
| B | 3 → 11/5(목) | 7 → 11/10(화) | 11/5 (여유 없음) |
| C | 3 → 11/5(목) | 5 → 11/6(금) | 6 → 11/10(화) |
| D | 7 → 11/11(수) | 13 → 11/18(수) | 11/11 (여유 없음) |
| E | 5 → 11/9(월) | 10 → 11/13(금) | 8 → 11/12(목) |
| F | 13 → 11/19(목) | 16 → 11/23(월) | 11/19 (여유 없음) |
| G | 16 → 11/24(화) | 17 → 11/24(화) | 11/24 (여유 없음) |
17영업일짜리 프로젝트가 달력으로는 11/2~11/24, 23일에 걸칩니다. E의 총여유 3일도 달력으로 보면 11/13(금)에 끝나도 되고 11/18(수)까지 늦어져도 된다는 뜻이라, 주말이 끼면서 달력상 여유는 5일로 보입니다. 담당자에게 "3일 여유"라고 말할지 "18일까지"라고 말할지 정해 두지 않으면 서로 다른 날을 마감으로 알게 됩니다. 날짜로 말하는 편이 오해가 적습니다. 영업일을 날짜로 바꾸는 엑셀 WORKDAY 함수는 영업일 계산법에 있습니다.
작은 프로젝트에서 실용적으로 쓰는 요령
작업이 10~30개인 프로젝트라면 ES/LS 표를 매번 그리지 않아도 됩니다. 실제로 쓰는 간단한 방법입니다.
- 마지막 산출물에서 거꾸로 묻습니다. "배포하려면 뭐가 끝나야 하지? 테스트. 테스트하려면? 프론트와 백엔드." 이렇게 거슬러 올라가며 가장 오래 걸리는 갈래만 따라가면 핵심경로가 나옵니다.
- 합류 지점만 계산합니다. 여러 작업이 하나로 모이는 곳(예시의 F)에서만 어느 갈래가 더 긴지 비교하면 됩니다. 일직선 구간은 계산할 것이 없습니다.
- 담당자 사슬을 따로 그립니다. 논리적 의존이 없어도 같은 사람이 하는 작업은 순서대로 진행됩니다. 담당자별로 작업을 이어 보면 논리 의존만으로는 안 보이던 숨은 핵심경로가 드러납니다.
- 기간은 영업일로 잡고 날짜로 옮깁니다. 17일이 달력으로 17일인지 영업일로 17일인지에 따라 종료일이 일주일 가까이 달라집니다. 이 사이트의 WBS·간트차트 도구는 시작일·종료일을 넣으면 주말과 공휴일 관리에 등록한 날을 뺀 영업일을 자동으로 계산해 줍니다. 다만 의존관계를 입력하거나 핵심경로를 자동으로 표시하는 기능은 없으므로, 위 방법으로 찾은 핵심경로 작업은 이름 앞에 "★"를 붙이고 비고 칸에 선행 작업 번호를 적어 두면 막대를 볼 때 구분이 됩니다.
- 주 1회 다시 봅니다. 핵심경로는 고정된 것이 아니라 진행에 따라 바뀝니다. 진행율을 갱신할 때 남은 기간으로 가장 긴 갈래가 어디인지 다시 확인하세요.
자주 묻는 질문
핵심경로 위의 작업이 하루 늦으면 정말 프로젝트가 하루 늦어지나요?
다른 조건이 같다면 그렇습니다. 핵심경로 작업은 총여유가 0이므로 지연이 그대로 종료일로 전달됩니다. 다만 뒤에 있는 핵심경로 작업을 단축하거나 병렬로 돌려 만회할 수는 있습니다. 반대로 여유가 있는 작업은 여유만큼은 늦어도 종료일이 바뀌지 않습니다.
작업 기간을 달력일로 계산해도 되나요?
계산 방법 자체는 같지만 결과 날짜가 달라집니다. 기간을 영업일로 두고 계산한 뒤 주말·공휴일을 건너뛰어 실제 날짜로 옮기는 것이 정확합니다. 달력일로 잡으면 주말이 끼는 작업의 실제 작업일이 줄어들어 핵심경로가 실제보다 짧게 보입니다.
의존관계가 거의 없는 작은 프로젝트에도 핵심경로가 의미가 있나요?
의존관계가 없으면 모든 작업이 병렬이므로 가장 긴 작업 하나가 핵심경로입니다. 이 경우에도 '가장 긴 작업이 늦으면 전체가 늦는다'는 사실은 유효하며, 실제로는 같은 담당자가 여러 작업을 맡아 순서가 생기는 경우가 많으므로 담당자 기준으로 사슬을 그려 보면 숨은 핵심경로가 드러납니다.
핵심경로는 프로젝트 도중에 바뀔 수 있나요?
네, 자주 바뀝니다. 여유가 3일이던 작업이 4일 늦어지면 그 작업이 새 핵심경로가 됩니다. 그래서 진행율을 갱신할 때마다 남은 기간으로 다시 계산해야 하며, 여유가 1~2일밖에 안 남은 준핵심경로 작업도 함께 지켜봐야 합니다.
정리
핵심경로는 시작에서 끝까지 이어지는 경로 중 가장 긴 경로이며, 그 위의 작업은 총여유가 0이라 하루 늦으면 프로젝트가 하루 늦어집니다. 계산은 전진 계산(ES/EF, 선행의 최대값)과 후진 계산(LS/LF, 후행의 최소값)을 거쳐 총여유 = LS − ES를 구하는 것이고, 자유여유까지 보면 다음 담당자에게 미치는 영향도 알 수 있습니다. 일정을 줄일 때는 핵심경로 위의 작업만 크래싱하거나 패스트트래킹해야 효과가 있고, 줄일수록 다른 경로가 핵심경로로 올라옵니다. 작은 프로젝트에서는 합류 지점만 비교하고 담당자 사슬을 함께 보는 것으로 충분하며, 기간은 반드시 영업일로 잡으세요.
작업마다 시작일·종료일을 넣으면 영업일 기간이 자동 계산되고, 오늘 날짜선과 진행율 막대로 핵심경로 작업이 늦고 있는지 바로 확인할 수 있습니다. 핵심경로 표시는 작업 이름에 직접 표시해 두세요.
WBS·간트차트 도구 열기