"이번 전자서명 패치, 언제 끝나요?"
발주사 PM의 질문에 두 담당자가 다르게 답합니다.
A는 "음… 한 2주? 개발하고 테스트하면 될 것 같은데요"라고 말합니다. 감(感)으로 답한 2주입니다. 막상 시작하니 고객 테스트 일정이 잡히지 않아 닷새가 비고, 운영 반영은 변경 승인 창(window)을 놓쳐 다음 주로 밀립니다. 결국 3주 반.
B는 다르게 답합니다. "요구 확인 1일 → 영향 분석 2일 → 개발·패치 4일 → 고객 테스트 3일(고객 일정 의존) → 운영 반영 1일(주말 점검창) → 정상 확인 1일 → 결과 보고 1일. 이 중 고객 테스트가 고객 쪽 일정에 묶여 있어 가장 위험합니다. 거기를 먼저 잡으면 13영업일, 못 잡으면 +α입니다."
둘의 차이는 성실함이 아니라 일을 쪼개고(WBS), 순서를 세우고(의존성), 어디가 전체를 좌우하는지(핵심경로) 보는 눈입니다. A는 '대충 2주'를 약속했고, B는 '무엇이 일정을 결정하는가'를 약속했습니다. 이 모듈은 B의 방식 — WBS와 일정 관리 — 를 다룹니다.
- 1작업분해구조(WBS)로 큰 일을 산출물·작업 단위로 쪼개고, 100% 규칙으로 누락·과잉을 점검할 수 있다
- 2작업패키지에 담당(Owner)·마감(Due)·선행(의존성)을 붙여 "누가 언제까지, 무엇 다음에"를 정의할 수 있다
- 3마일스톤과 핵심경로(Critical Path)의 의미를 구분하고, 왜 핵심경로 작업을 더 촘촘히 관리해야 하는지 설명할 수 있다
- 4지연 사유(자원·의존·범위변경)를 식별하고, 상황에 맞는 일정 회복 옵션(크래싱·패스트트래킹·재계획)을 고를 수 있다
- 5전자서명 패치 프로젝트를 예로, WBS 표와 일정 회복 옵션 표를 직접 작성할 수 있다
큰 일을 쪼갠다 — WBS와 100% 규칙
WBS는 '할 일 목록'이 아니라 '범위를 빠짐없이 나눈 지도'다
프로젝트가 막막한 이유는 일이 하나의 큰 덩어리로 보이기 때문입니다. "전자서명 패치"는 그 자체로는 견적도, 일정도, 담당도 붙일 수 없습니다. 너무 큽니다.
WBS(Work Breakdown Structure, 작업분해구조) 는 이 덩어리를 관리 가능한 단위로 계층적으로 쪼갠 것입니다. 위에서 아래로 내려갈수록 작아집니다.
- 1단계(프로젝트): 전자서명 패치
- 2단계(주요 산출물/단계): 분석 / 개발 / 검증 / 반영
- 3단계(작업패키지): "영향 분석서 작성", "패치 모듈 개발", "고객 테스트 수행" …
가장 아래 단위를 작업패키지(Work Package) 라고 부릅니다. 작업패키지는 "한 사람(또는 한 팀)에게 맡겨 기간·비용을 추정할 수 있을 만큼 작은" 단위입니다. 보통 며칠~한두 주짜리로 쪼갭니다 — 너무 크면 추정이 부정확하고, 너무 잘게 쪼개면 관리 비용만 늡니다.
WBS의 핵심 규칙은 100% 규칙입니다.
| 규칙 | 의미 | 어기면 생기는 일 |
|---|---|---|
| 100% 규칙(누락 금지) | 하위 작업의 합 = 상위 작업의 범위, 빠진 일이 없어야 함 | 막판에 "결과 보고서 누가 쓰죠?" 같은 누락 작업이 터짐 |
| 100% 규칙(과잉 금지) | 범위 밖의 일이 WBS에 들어오면 안 됨 | 안 해도 될 일에 일정·비용을 낭비(범위 부풀림) |
| 상호 배타(중복 금지) | 한 작업이 두 곳에 걸치지 않게 | 같은 일을 두 번 추정·청구하는 혼선 |
| 산출물 중심 | "무엇을 만드는가"로 쪼갬(동사 나열 X) | "회의함" 같은 비(非)산출물로 진척이 흐려짐 |
100% 규칙이 지켜지면 강력한 약속이 성립합니다 — "WBS에 있는 것만 다 하면 프로젝트는 끝난다." WBS에 없는 일은 곧 '범위 밖'이고, 그게 필요하면 정식 범위 변경 절차를 타야 합니다. 즉 WBS는 일정의 기초일 뿐 아니라 범위의 울타리이기도 합니다.
작업에 순서를 매긴다 — 의존성·마일스톤·핵심경로
언제 시작할 수 있는가는 '앞 작업'이 정한다
WBS로 일을 쪼개면 "무엇을 할지"는 정해집니다. 하지만 일정은 "어떤 순서로 할 수 있는가" 가 결정합니다. 작업 사이의 이 선후 관계를 의존성(dependency) 또는 선후행 관계라고 합니다.
가장 흔한 의존성은 FS(Finish-to-Start, 종료-시작) 입니다 — "앞 작업이 끝나야 뒤 작업을 시작할 수 있다". 예: '패치 개발'이 끝나야 '고객 테스트'를 시작할 수 있습니다. (이 외에 SS·FF·SF 같은 유형도 있지만, 실무 일정의 대부분은 FS로 설명됩니다. 지금은 개념만 잡습니다.)
여기서 두 핵심 개념이 갈립니다.
| 개념 | 한 줄 정의 | 왜 중요한가 |
|---|---|---|
| 마일스톤(Milestone) | 기간이 0인 '중요 시점' 표시(완료/관문) | "이때까지 이건 끝나 있어야 한다"는 합의 지점. 발주사 보고·결제·관문의 기준 |
| 의존성(Dependency) | 작업 간 선후 관계(예: FS) | 어떤 작업이 무엇 '다음'에만 가능한지를 정의 → 병렬 가능 여부 결정 |
| 여유시간(Float/Slack) | 전체 일정을 밀지 않고 작업을 늦출 수 있는 여유 | 여유가 있는 작업은 조금 밀려도 안전, 여유 0이면 핵심경로 |
| 핵심경로(Critical Path) | 시작→종료로 이어진 경로 중 기간 합이 가장 긴 경로 | 이 경로가 하루 밀리면 프로젝트가 하루 밀림 → 가장 촘촘히 관리 |
핵심경로가 일정 관리의 심장입니다. 모든 작업이 똑같이 중요한 게 아닙니다. 의존성으로 이어진 사슬 중 가장 긴 사슬, 즉 여유시간이 0인 사슬이 전체 종료일을 좌우합니다. 핵심경로가 아닌 작업은 며칠 밀려도 (여유 안에서는) 종료일에 영향이 없지만, 핵심경로 작업이 하루 밀리면 그날로 프로젝트 종료일이 하루 밀립니다.
그래서 노련한 관리자는 "오늘 핵심경로 작업이 계획대로 갔는가"를 매일 봅니다. 핵심경로 밖에서 아무리 바빠도 종료일은 안 당겨지고, 핵심경로 한 곳이 막히면 나머지가 한가해도 프로젝트는 멈춥니다.
그림: 큰 일을 작업패키지로 분해하고, 의존성으로 이어진 가장 긴 사슬(핵심경로)을 찾는다 — 핵심경로 작업이 하루 밀리면 종료일도 하루 밀린다.
지연을 진단하고 회복한다
먼저 '어디서, 왜' 밀렸는지를 본다
일정은 거의 항상 밀립니다. 중요한 건 밀리지 않는 게 아니라, 밀렸을 때 빠르게 진단하고 회복하는 것입니다. 진단의 두 질문은 정해져 있습니다.
- 어디서 밀렸나 — 핵심경로 위인가, 여유 있는 작업인가? 핵심경로 밖이고 여유 안이라면 종료일에 영향이 없어 '회복 불필요'일 수도 있습니다. 핵심경로 위라면 즉시 회복 대상입니다.
- 왜 밀렸나 — 사유는 대개 셋 중 하나입니다.
| 지연 사유 | 전형적 모습 | 1차 대응 방향 |
|---|---|---|
| 자원(Resource) | 사람이 부족·중복 투입, 장비·환경 대기 | 자원 추가/재배치(→ 크래싱 검토) |
| 의존(Dependency) | 앞 작업·외부(고객·협력사)가 안 끝남 | 선후 조정, 일부 병렬화(→ 패스트트래킹), 외부 일정 협의 |
| 범위 변경(Scope) | "이것도 해주세요"가 슬쩍 들어옴 | 정식 변경 절차로 일정·비용 재산정(범위 크리프 차단) |
진단이 끝나면 회복 수단을 고릅니다. 대표적인 두 가지가 크래싱과 패스트트래킹입니다.
- 크래싱(Crashing): 핵심경로 작업에 자원을 더 투입해 기간을 줄입니다. 일정은 당겨지지만 비용이 오르고, 인원을 두 배 넣는다고 기간이 절반이 되지도 않습니다(의사소통 비용·러닝커브). "돈으로 시간을 산다"에 가깝습니다.
- 패스트트래킹(Fast-tracking): 원래 'A 끝나고 B 시작'이던 작업을 일부 겹쳐 병렬로 진행합니다. 추가 비용은 적지만, 앞 작업(A)이 나중에 바뀌면 그에 의존한 B를 다시 해야 하는 재작업 리스크가 큽니다.
둘 다 안 되면(시간이 근본적으로 부족하면) 재계획 — 마일스톤·종료일을 발주사와 다시 협의하거나, 합의된 절차로 범위를 조정합니다. 회복의 마지막 카드는 "거짓 약속을 유지하는 것"이 아니라 "현실적인 약속으로 다시 맞추는 것"입니다.
직접 해보기 — 전자서명 패치 WBS와 일정 짜기
전자서명 패치 프로젝트를 WBS로 쪼개고, 각 작업패키지에 담당(Owner)·기간·선행(의존성)을 붙여 보세요. 아래 표를 채운다고 생각하고, 마지막에 핵심경로가 어디인지 따져 봅니다.
작업 흐름(요구 확인 → 영향 분석 → 개발·패치 → 고객 테스트 → 운영 반영 → 정상 확인 → 결과 보고)을 그대로 작업패키지로 봅니다.
| ID | 작업패키지 | 담당(Owner) | 기간(영업일) | 선행 | 마일스톤 |
|---|---|---|---|---|---|
| W1 | 요구 확인(패치 대상·범위 합의) | PM | 1 | — | |
| W2 | 영향 분석(연계 시스템·리스크 분석서) | 분석 담당 | 2 | W1 | M1 분석 완료 |
| W3 | 개발·패치(모듈 수정·단위 테스트) | 개발자 | 4 | W2 | |
| W4 | 고객 테스트(고객 환경 검증) | 고객 + QA | 3 | W3 | M2 고객 승인 |
| W5 | 운영 반영(주말 점검창에 배포) | 운영자 | 1 | W4 | M3 운영 반영 |
| W6 | 정상 확인(반영 후 모니터링·검증) | 운영자 | 1 | W5 | |
| W7 | 결과 보고(완료 보고서·증빙) | PM | 1 | W6 | M4 종료 |
이 예시는 작업이 한 줄(W1→W2→…→W7) 로 이어지는 단순 구조입니다. 직접 할 때는 "어떤 작업이 병렬 가능한가?"를 따져 보세요 — 예를 들어 'W7 결과 보고서 양식 준비'는 앞 작업과 무관하게 미리 시작할 수 있어 핵심경로 밖일 수 있습니다.
작업 쪼개기 → 담당·마감·선행 붙이기 → 핵심경로 표시- 기간 합: 1+2+4+3+1+1+1 = 13영업일. 작업이 한 줄로 이어지므로 이 사슬 전체가 핵심경로다(여유시간 0).
- 100% 규칙 점검: W1~W7을 다 하면 "패치가 운영에 반영되고 보고까지 끝"인가? 빠진 일(예: 롤백 계획 수립, 이해관계자 공지)이 없는지 되묻는다 — 있으면 누락이므로 WBS에 추가.
- 가장 위험한 작업 = W4 고객 테스트. 기간이 길고(3일) "고객 일정"이라는 외부 의존이 걸려 있어, 여기가 밀리면 13일이 곧장 늘어난다. 핵심경로 위의 외부 의존이 최우선 관리 대상.
- 마일스톤은 기간이 0인 "관문". M2(고객 승인)가 안 떨어지면 W5 운영 반영을 시작할 수 없다 → 마일스톤은 의존성을 "보고 가능한 합의 지점"으로 드러낸다.
- 핵심 감각: 13일은 "각 작업의 합"이 아니라 "선후행으로 이어진 가장 긴 사슬의 합". 병렬 가능한 작업이 있었다면 합보다 짧아진다.
이제 변수를 넣습니다. W4(고객 테스트)가 고객 측 사정으로 이틀 밀렸다고 가정하세요. 핵심경로 위(W4)에서 외부 의존 때문에 밀린 상황입니다. 회복 옵션을 비교하는 표를 채워 봅니다.
| 회복 옵션 | 무엇을 하나 | 효과 | 대가/리스크 | 이 상황 적합성 |
|---|---|---|---|---|
| 크래싱(W3에 개발 인력 추가) | 앞선 개발(W3)을 인력 투입으로 단축 | 개발이 일찍 끝나 테스트를 당겨 시작 | 비용 증가, 인원 비례 효과 아님 | 보조적(개발은 이미 끝났다면 효과 X) |
| 패스트트래킹(W3·W4 일부 겹침) | 개발 일부 완료분부터 고객 테스트 선(先)착수 | 테스트 시작을 앞당김 | 후속 개발 변경 시 테스트 재수행 | 가능하나 재작업 리스크 평가 필요 |
| 외부 일정 협의 | 고객과 테스트 일정·우선순위 재조정 | 지연의 '근본 원인'(외부 의존)을 직접 해소 | 고객 협조 필요, 협상 시간 | 최우선 — 외부 의존 지연의 정공법 |
| 재계획(M3·M4 재협의) | 운영 반영·종료 마일스톤을 이틀 미룸 | 현실적 일정으로 재합의 | 종료일 지연을 공식화 | 위 셋이 안 될 때의 안전망 |
표를 다 채웠다면 스스로 답해 보세요 — "내부에서 밤샘한다(크래싱·패스트트래킹)"가 먼저인가, "고객과 일정을 다시 잡는다(외부 협의)"가 먼저인가? 지연의 사유(외부 의존) 가 답을 정합니다.
사유 식별 → 회복 옵션 비교 → 선택- W4가 핵심경로 위이므로 이틀 지연 = 종료일 이틀 지연. 즉시 회복 대상이 맞다.
- 사유가 "외부(고객) 의존"이므로 1차 정공법은 외부 일정 협의 — 내부 자원을 갈아넣는 크래싱은 원인을 못 건드린다(개발은 이미 끝났으므로 더 빨리 해도 소용없음).
- 패스트트래킹(개발 완료분부터 테스트 선착수)은 효과가 있을 수 있으나, 남은 개발이 바뀌면 테스트를 다시 해야 하는 리스크를 먼저 평가해야 한다.
- 어떤 수단으로도 못 당기면 재계획(M3·M4 이틀 연기)을 공식화 — "원래 날짜를 지킨 척"하는 것이 가장 나쁜 선택이다.
- 핵심 감각: 회복 수단 선택은 "사유"에서 나온다. 자원 부족 → 크래싱, 순서 여유 → 패스트트래킹, 외부 의존 → 협의, 시간 부족 → 재계획.
현장에서 자주 보는 함정
증상: WBS 표는 잘 만들어 발주사에 보고까지 했습니다. 그런데 (1) 작업이 자꾸 밀리고, (2) "왜 종료일이 또 밀리나요?"라는 질문에 "이것저것 바빠서요"밖에 답하지 못합니다.
원인: 흔한 두 가지가 겹쳐 있습니다.
- 의존성과 핵심경로를 안 그렸다. 작업을 나열만 하고 "무엇이 무엇 다음인가"를 정의하지 않으면, 어떤 지연이 종료일에 영향을 주는지 알 수 없습니다. 그래서 핵심경로 밖에서 밤새 일하고도 종료일은 그대로인 헛심을 씁니다.
- 외부 의존을 '내 작업'처럼 추정했다. 'W4 고객 테스트 3일'을 내부 작업처럼 적었지만, 실제로는 고객 일정에 묶여 있습니다. 외부 의존은 기간보다 언제 시작 가능한가가 변수입니다.
해결 방향(이 트랙·후속 모듈에서 깊어짐):
- 작업마다 선행(의존성) 을 반드시 적어, 한 줄 사슬인지 병렬 가능한지 드러낸다.
- 핵심경로를 표시하고, 매일 "핵심경로 작업이 계획대로 갔는가"만이라도 본다.
- 외부 의존 작업은 별도로 표시하고, 마일스톤(고객 승인 등) 으로 합의 시점을 못 박는다.
- 밀리면 "바빠서"가 아니라 사유(자원·의존·범위변경) 로 말한다 — 그래야 올바른 회복 수단이 나온다.
WBS와 일정은 '예쁜 표'가 목적이 아니라, "무엇이 종료일을 좌우하고, 밀렸을 때 어디를 손대야 하는가" 를 보이게 만드는 도구입니다.
이 일은 SI/SM 현장에서 PM·PMO·운영관리자가 매일 하는 일입니다. 발주사는 "기능 다 됐나요"보다 "약속한 날짜에 끝나나요, 안 되면 왜고 언제로 미뤄지나요" 를 먼저 묻습니다. 이때 "열심히 하고 있습니다"는 답이 아니라, WBS·핵심경로·지연 사유로 설명하는 것이 답입니다.
특히 협력사(하도급) 엔지니어가 실제 작업을 하는 구조에서, 관리자는 직접 코드를 치기보다 "이 작업패키지는 누가, 무엇 다음에, 언제까지 하고, 핵심경로 위인가, 밀리면 무엇으로 회복하는가" 를 통제합니다. 협력사가 "이번 주 안에 됩니다"라고 두루뭉술하게 말할 때, WBS와 의존성을 아는 관리자는 "그 작업은 W3가 끝나야 시작인데 W3가 아직인데요?"라고 되물을 수 있습니다.
또한 일정 회복은 곧 신뢰 관리입니다. 밀린 일정을 숨기다 막판에 터뜨리는 PM은 신뢰를 잃습니다. 반대로 "핵심경로 W4가 고객 의존으로 이틀 밀려, 이러이러한 옵션 중 외부 협의를 택했고 종료일은 이틀 조정됩니다"라고 진단·옵션·결정을 투명하게 보고하는 PM은, 일정이 밀려도 신뢰를 얻습니다. 기술을 아는 관리자가 강한 이유가 여기 있습니다 — 협력사의 추정을 검증하고, 잘못된 일정 약속에 속지 않으며, 밀렸을 때 갈아넣을 곳과 협의할 곳을 구분합니다.
관련 모듈로 더 깊이:
- 범위와 요구사항 — WBS의 출발점인 범위·요구사항을 확정하는 법
- 원가·자원·M/M 산정 — 일정 위에 원가·자원·M/M를 얹어 통제하는 법
- 리스크와 이슈 관리 — 핵심경로 지연 같은 일정 리스크를 식별·추적하는 법
다음 모듈에서는 일정 위에 '돈과 사람'을 얹습니다 — 원가(비용) 산정과 자원 관리, 그리고 투입 공수를 표현하는 M/M(맨먼스) 개념으로, "이 일정에 얼마가, 몇 명이 드는가"를 추정하고 통제하는 방법을 다룹니다.