프로젝트 일정 관리 방법 — WBS와 간트차트로 일정 짜는 법
프로젝트 일정이 자꾸 밀리는 가장 큰 이유는 "프로젝트를 큰 덩어리로만 생각하기" 때문입니다. "개발 2주, 디자인 1주"처럼 뭉뚱그리면, 실제로 무엇을 언제 해야 하는지가 흐릿해지고 빠진 일이 뒤늦게 튀어나옵니다. 이 글에서는 큰 목표를 작업 단위로 쪼개고(WBS), 영업일 기준으로 기간을 잡고, 간트차트로 시각화한 뒤, 진행율로 추적하는 4단계 일정 관리 방법을 정리합니다. 이 글은 네 단계가 어떻게 이어지는지 보여 주는 개요이고, 단계별 세부 방법(WBS 분해 원칙, 영업일 세기, 핵심 경로 계산, 진행율 집계, 버퍼 크기)은 각 단락 끝에 연결한 전용 글에서 다룹니다.
1단계. 일을 쪼갠다 — WBS(작업분류체계)
WBS는 Work Breakdown Structure, 우리말로 작업분류체계입니다. 이름은 거창하지만 핵심은 단순합니다. "프로젝트라는 큰 덩어리를, 실제로 실행할 수 있는 작은 작업들로 계층적으로 쪼개는 것"이죠. 일정을 짜기 전에 WBS를 먼저 만들어야 하는 이유는 분명합니다.
- 빠진 일을 미리 발견합니다. 쪼개다 보면 "아, 테스트도 해야 하고 배포 문서도 써야 하네" 하는 숨은 작업이 드러납니다.
- 기간 추정이 정확해집니다. "개발 2주"는 감이지만, "로그인 API 2일 + 화면 3일 + 연동 2일"은 근거가 있습니다.
- 담당과 책임이 명확해집니다. 작업 단위가 작을수록 누가 무엇을 맡는지가 분명합니다.
WBS 작성 4단계
- 최종 목표(산출물)를 한 줄로 정의합니다. 예: "신규 회원가입 기능 오픈".
- 큰 단계로 나눕니다. 보통 기획 → 디자인 → 개발 → 테스트 → 배포처럼 단계(phase) 수준으로 먼저 나눕니다.
- 각 단계를 실행 가능한 작업으로 분해합니다. 이때 유용한 기준이 8/80 규칙입니다. 하나의 작업이 대략 8시간보다 작거나 80시간보다 크면 다시 쪼개라는 경험칙으로, 너무 잘게 쪼개 관리비용이 커지거나 너무 크게 묶어 추정이 흐려지는 것을 막아 줍니다.
- 각 작업에 담당자·기간을 붙입니다. 여기까지 하면 일정의 뼈대가 완성됩니다.
WBS를 쪼개는 원칙(100% 규칙, 산출물 중심 분해, 번호 체계)과 예시 표는 WBS 작성법에 따로 정리했습니다.
2단계. 기간은 "영업일"로 잡는다
일정을 짤 때 많은 사람이 달력 날짜 그대로 기간을 계산합니다. 하지만 실제로 일하는 날은 주말과 공휴일을 뺀 영업일입니다. "10일 걸린다"가 달력으로 10일인지 영업일로 10일인지에 따라 마감일이 크게 달라집니다.
- 업무량(공수)은 주말·공휴일을 제외한 영업일로 세는 것이 현실적입니다.
- 대체공휴일, 회사 휴무일도 빼고 계산해야 마감이 어긋나지 않습니다.
- 추정이 불확실하면 낙관치와 비관치의 가중평균(예: (낙관 + 4×보통 + 비관) ÷ 6)으로 잡으면 한쪽으로 치우치지 않습니다.
일일이 달력을 세기 번거롭다면, 시작일과 종료일만 넣으면 주말·공휴일을 자동으로 빼 주는 도구를 쓰는 편이 정확합니다.
"5영업일 이내" 같은 표현을 세는 법과 엑셀 NETWORKDAYS·WORKDAY 사용법은 영업일 계산법을 참고하세요.
3단계. WBS를 간트차트로 옮긴다
간트차트(Gantt chart)는 작업을 가로 막대로 표현해 "언제부터 언제까지"를 한눈에 보여 주는 일정표입니다. WBS가 "무엇을 할 것인가"의 목록이라면, 간트차트는 그 작업들을 시간 축 위에 펼쳐 놓은 그림입니다. WBS 표 옆에 간트차트를 나란히 두면, 작업 목록과 일정 막대를 동시에 보며 관리할 수 있습니다.
간트차트에서 챙기면 좋은 것
- 선후 관계(의존성) — "디자인이 끝나야 개발 시작"처럼 앞 작업이 밀리면 뒤 작업도 밀립니다. 핵심 경로(가장 긴 작업 체인)를 알면 전체 마감을 좌우하는 작업이 보입니다.
- 마일스톤 — 중간 점검일, 오픈일 같은 중요한 시점을 표시해 두면 팀이 같은 목표를 봅니다.
- 오늘 날짜선 — 오늘이 일정 어디쯤인지 선으로 표시하면, 어떤 작업이 늦고 있는지 즉시 보입니다.
도구마다 지원 범위가 다르다는 점도 알아 두세요. 이 사이트의 WBS·간트차트 도구는 작업 막대·진행율 막대·오늘 날짜선은 그려 주지만, 작업 사이를 잇는 의존 화살표나 마름모 모양의 마일스톤 기호는 따로 없습니다. 선후 관계는 비고 칸에 "선행: 2.1" 식으로 적고, 마일스톤은 시작일과 종료일을 같은 날로 둔 1일짜리 행으로 표시하는 것이 현실적인 대안입니다.
막대 색·화살표·오늘선을 읽는 법은 간트차트 보는 법, 핵심 경로를 직접 계산하는 방법은 크리티컬 패스 계산법에 있습니다.
4단계. 진행율로 추적한다
일정은 한 번 짜고 끝이 아니라, 실제 진척을 계속 비교해야 의미가 있습니다. 이때 두 가지 진행율을 함께 보면 좋습니다.
- 진행율 — 실제로 얼마나 진척됐는지 직접 입력하는 값(예: 60% 완료).
- 기간진행율 — 오늘 날짜 기준으로 계획상 시간이 얼마나 지났는지(경과 영업일 비율)를 자동 계산한 값.
이 둘을 비교하면 일정 대비 진척을 객관적으로 볼 수 있습니다. 기간진행율은 70%인데 실제 진행율이 40%라면, 시간은 70% 흘렀는데 일은 40%만 됐다는 뜻이므로 지연 신호입니다. 반대로 진행율이 더 높으면 일정보다 앞서가는 셈이죠. 이렇게 차이를 조기에 발견하면 마감 직전에 당황하는 일을 줄일 수 있습니다.
진행율을 매기는 방식, 상위 작업으로 집계하는 법, 지연 판정 기준과 주간 보고 양식은 프로젝트 진행율 계산법에서 다룹니다.
일정 초안을 잡는 3가지 접근 — 순산·역산·병행
WBS와 기간이 나왔다면 이제 달력 위에 올려야 합니다. 어디서부터 채우느냐에 따라 세 가지 방식이 있고, 상황에 따라 맞는 것이 다릅니다.
| 접근 | 방법 | 맞는 상황 | 주의 |
|---|---|---|---|
| 순산(전진) | 오늘부터 작업을 차례로 쌓아 종료일을 구한다 | 마감이 정해지지 않았거나 협의 가능할 때 | 나온 종료일이 곧 "현실적인 마감"이므로 협상 근거로 남겨 둘 것 |
| 역산(후진) | 마감일에서 거꾸로 작업을 배치해 시작일을 구한다 | 오픈일·행사일·계약 납기가 고정일 때 | 시작일이 오늘보다 앞서면 이미 늦은 것. 범위를 줄이거나 인력을 늘려야 함 |
| 병행 | 순산과 역산을 둘 다 해서 겹치는 구간을 확인한다 | 마감은 있지만 약간의 조정 여지가 있을 때 | 두 결과의 차이가 곧 "부족한 기간"이며, 이것이 협의 안건이 됨 |
예를 들어 오늘이 11월 2일이고 순산으로 계산한 종료일이 12월 18일인데 고객이 요구한 오픈일이 12월 4일이라면 영업일 10일이 부족합니다. 이 숫자를 들고 "범위를 줄일지, 사람을 더 넣을지, 마감을 미룰지" 세 가지 중 하나를 고르는 것이 일정 협의의 실체입니다. 숫자 없이 "열심히 하겠습니다"로 넘기면 마감 직전에 반드시 터집니다.
버퍼는 얼마나, 어디에 두나 — 요약
버퍼(여유 기간)는 작업마다 몰래 늘려 두는 것이 아니라, 작업 기간은 "보통 걸리는 시간"으로 잡고 "버퍼"라는 이름의 행을 단계 끝과 프로젝트 끝에 눈에 보이게 넣는 것입니다. 합계는 핵심 경로 길이의 20% 안팎에서 시작하고, 고객 검토·외주 납품·심사처럼 통제할 수 없는 구간에는 약속 기간의 50~100%를 따로 얹습니다. 버퍼 크기를 정하는 세 가지 방법, 소진율 신호등, 리스크 목록 양식은 일정 버퍼와 리스크 관리 기초에 정리했습니다.
이 사이트 도구로 4단계를 옮길 때 알아 둘 동작
위 4단계를 WBS·간트차트 도구에 그대로 옮길 수 있지만, 도구가 자동으로 해 주는 일과 사람이 직접 챙겨야 하는 일이 나뉩니다. 처음 쓸 때 헷갈리기 쉬운 부분만 추렸습니다.
| 단계 | 도구가 해 주는 일 | 직접 챙겨야 하는 일 |
|---|---|---|
| ① WBS | 행을 들여쓰기하면 최대 4레벨까지 1, 1.1, 1.1.1 번호가 자동으로 붙음. 하위 행이 있는 행은 그룹이 되어 기간·업무량·진행율을 하위에서 집계 | 100% 규칙(빠진 작업이 없는지)은 도구가 검사하지 않음 |
| ② 영업일 | 시작일·종료일을 넣으면 토·일과 공휴일 관리에 등록한 날을 빼고 업무량(영업일)을 계산 | 법정 공휴일·대체공휴일·회사 휴무일은 직접 등록해야 반영됨. 등록 전에는 주말만 빠짐 |
| ③ 간트차트 | 막대·오늘 날짜선, 일·주·월·분기·반기·년 보기 전환 | 선후 관계는 자동으로 밀어 주지 않음. 앞 작업이 밀리면 뒤 작업 날짜를 손으로 옮김 |
| ④ 진행율 | 그룹 진행율은 하위 작업의 업무량 가중평균, 기간진행율은 오늘까지 경과한 영업일 비율로 자동 계산. 종료일이 지났는데 진행율이 100% 미만이면 상태가 "지연" | 작업별 진행율 숫자는 사람이 입력. 입력 규칙을 팀이 먼저 합의해야 함 |
특히 ③이 중요합니다. 전용 일정 소프트웨어는 선행 작업의 종료일을 바꾸면 후행 작업이 따라 움직이지만, 이 도구는 그렇지 않습니다. 대신 화면이 단순해서 작업 50개 안팎의 소규모 프로젝트는 표 하나로 관리가 됩니다. 의존 관계가 복잡하게 얽힌 프로젝트라면 크리티컬 패스를 먼저 손으로 계산해 핵심 경로 작업에만 비고로 표시해 두는 편이 안전합니다.
팀 합의와 리뷰 주기
혼자 짠 일정은 지켜지지 않습니다. 담당자가 자기 작업의 기간을 직접 말했을 때만 책임감이 생깁니다. 초안을 만든 뒤 아래 순서로 합의를 받으면 한 시간 안에 끝납니다.
- 초안 간트차트를 띄우고, 담당자별로 자기 막대만 보게 합니다.
- "이 기간에 이 작업, 가능한가요?"를 한 명씩 묻고 답을 그대로 반영합니다. 못 한다는 답은 기간을 늘리거나 범위를 줄여 그 자리에서 고칩니다.
- 같은 사람의 막대가 같은 주에 겹치는지 확인합니다. 겹치면 순서를 정합니다.
- 마일스톤(중간 점검일·오픈일)을 소리 내어 읽고 모두가 같은 날짜를 보게 합니다.
리뷰 주기는 프로젝트 길이에 맞춥니다. 4주 이내는 매일 5분 스탠드업에서 오늘선 기준 지연 막대만 보고, 2~3개월 프로젝트는 주 1회 30분에 진행율을 갱신하며, 6개월 이상이면 주간 점검에 월 1회 마일스톤 리뷰를 더합니다. 어떤 주기든 "진행율을 갱신하는 사람"과 "시각"을 정해 두는 것이 핵심입니다. 예를 들어 매주 금요일 오후 4시까지 각자 갱신, 월요일 회의에서 확인, 이런 식입니다.
변경이 생겼을 때 재계획 순서
요구사항이 추가되거나 핵심 인력이 빠지는 일은 반드시 생깁니다. 이때 막대를 아무렇게나 늘리지 말고 아래 순서로 처리하면 일정의 신뢰가 유지됩니다.
- 변경 내용을 WBS에 먼저 반영합니다. 새 기능이면 작업 패키지를 추가하고, 범위 축소면 작업을 삭제합니다. 일정보다 목록이 먼저입니다.
- 영향받는 작업만 다시 추정합니다. 전체를 다시 짜지 않습니다. 추가된 작업의 영업일과, 그 뒤에 화살표로 연결된 작업의 새 시작일만 계산합니다.
- 핵심 경로가 바뀌었는지 확인합니다. 추가 작업이 핵심 경로 위에 있으면 마감이 밀리고, 여유가 있는 경로에 있으면 마감은 그대로일 수 있습니다.
- 버퍼로 흡수할지, 마감을 옮길지 결정합니다. 단계 버퍼 안에서 해결되면 마감 유지, 넘치면 그 초과분만큼 마감 변경을 요청합니다.
- 바뀐 일정을 기준선으로 다시 저장하고, 변경 사유와 날짜를 한 줄 기록합니다. 나중에 "왜 마감이 두 번 바뀌었는지"를 설명할 수 있어야 합니다.
이 사이트 도구에는 기준선(baseline)을 따로 보관하는 기능이 없습니다. 대신 재계획 직전에 [💾 저장]으로 JSON 파일을 내려받으면 파일 이름 끝에 그날 날짜(예: _20261116)가 붙으므로, 그 파일이 곧 변경 전 기준선 사본이 됩니다. 변경 사유는 해당 작업의 비고 칸에 "11/16 범위 추가로 +3일"처럼 남겨 두면 엑셀로 내려받을 때도 함께 나옵니다.
소규모 예시 일정표 — 회원가입 기능, 영업일 21일
위 내용을 한 표에 담으면 다음과 같습니다. 3명(기획 1, 디자인 1, 개발 1)이 11월 2일(월)에 시작하고 그사이 공휴일이 없다고 가정했으며, 기간은 모두 영업일입니다.
| 번호 | 작업 | 담당 | 영업일 | 기간 | 선행 |
|---|---|---|---|---|---|
| 1 | 기획 | 기획 | 4 | 11/2~11/5 | — |
| 1.1 | 요구사항·화면 흐름 정리 | 기획 | 3 | 11/2~11/4 | — |
| 1.2 | 기획 리뷰·확정 | 전원 | 1 | 11/5 | 1.1 |
| 2 | 디자인 | 디자인 | 5 | 11/6~11/12 | 1.2 |
| 2.1 | 가입·로그인 화면 3종 | 디자인 | 4 | 11/6~11/11 | 1.2 |
| 2.2 | 디자인 버퍼 | — | 1 | 11/12 | 2.1 |
| 3 | 개발 | 개발 | 10 | 11/6~11/19 | 1.2 |
| 3.1 | 가입 API·DB | 개발 | 4 | 11/6~11/11 | 1.2 |
| 3.2 | 화면 구현·연동 | 개발 | 5 | 11/12~11/18 | 2.1, 3.1 |
| 3.3 | 개발 버퍼 | — | 1 | 11/19 | 3.2 |
| 4 | 테스트·배포 | 전원 | 7 | 11/20~11/30 | 3.3 |
| 4.1 | 테스트·결함 수정 | 전원 | 4 | 11/20~11/25 | 3.3 |
| 4.2 | 프로젝트 버퍼 | — | 2 | 11/26~11/27 | 4.1 |
| 4.3 | 배포 ◆ 마일스톤 | 개발 | 0 | 11/30 | 4.2 |
이 표에서 읽을 점은 세 가지입니다. 첫째, 디자인(2.1)과 API 개발(3.1)은 담당자가 달라 같은 기간에 병행하고, 둘 다 4일이라 어느 쪽이 밀려도 3.2가 밀립니다. 둘째, 버퍼가 단계 끝(2.2, 3.3)과 프로젝트 끝(4.2)에 이름을 달고 들어가 있어 총 4일, 전체의 약 19%입니다. 셋째, 배포는 기간 0인 마일스톤이라 모두가 11월 30일 하루를 봅니다. 여기에 진행율을 매주 갱신하면 4단계가 그대로 돌아갑니다.
자주 하는 실수 3가지
- 여유(버퍼)를 0으로 잡는다 — 모든 작업을 빈틈없이 붙이면 한 작업만 밀려도 전체가 무너집니다. 단계마다 약간의 여유를 둡니다.
- 한 사람에게 같은 기간 여러 작업을 동시 배정 — 달력상으로는 가능해 보여도 실제로는 한 사람이 동시에 두 일을 못 합니다. 담당자별로 겹치지 않는지 확인하세요.
- 짜 놓고 업데이트하지 않는다 — 일정은 살아 있는 문서입니다. 주 1회라도 진행율을 갱신해야 추적의 의미가 생깁니다.
자주 묻는 질문
일정은 얼마나 잘게 짜야 하나요?
가장 아래 작업이 대략 1일~2주(8/80 규칙) 안에 들어오면 충분합니다. 하루 미만 단위까지 쪼개면 갱신하는 데 시간이 더 들고, 2주를 넘기면 지연을 늦게 발견합니다. 4주짜리 소규모 프로젝트라면 작업 15~25개 정도가 관리하기 적당합니다.
마감이 이미 정해져 있어 역산하면 시작일이 지났습니다. 어떻게 하나요?
그 차이가 곧 부족한 기간이므로 숨기지 말고 숫자로 보고해야 합니다. 대응은 세 가지뿐입니다. 범위를 줄이거나(우선순위 낮은 기능을 다음 버전으로), 인력을 더 넣거나(병행 가능한 작업에 한해 효과), 마감을 옮기는 것입니다. 셋 중 무엇을 고를지는 의사결정자의 몫이고, 일정 담당자는 각 선택의 결과를 간트차트로 보여 주면 됩니다.
버퍼를 두면 팀이 느슨해지지 않나요?
작업마다 숨겨 두면 그렇게 됩니다. 대신 작업 기간은 보통 걸리는 시간으로 타이트하게 잡고, 버퍼는 단계 끝과 프로젝트 끝에 이름을 붙여 눈에 보이게 두세요. 버퍼가 얼마나 남았는지를 매주 같이 보면 오히려 긴장감이 유지됩니다.
진행율 갱신을 팀원이 잘 안 합니다.
갱신 시각과 방법을 정해 두지 않아서인 경우가 대부분입니다. 매주 같은 요일·시간에 5분간 함께 갱신하는 자리를 만들고, 진행율 대신 남은 영업일을 물어보면 답이 훨씬 빨리 나옵니다. 남은 일수를 알면 진행율은 계산으로 나옵니다.
정리
프로젝트 일정 관리는 결국 ① WBS로 일을 쪼개고 → ② 영업일 기준으로 기간을 잡고 → ③ 간트차트로 시각화하고 → ④ 진행율로 추적하는 흐름입니다. 거창한 도구가 아니라, 이 네 단계를 꾸준히 지키는 것만으로도 "왜 자꾸 밀리는지 모르겠다"에서 벗어날 수 있습니다.
위 4단계를 한 곳에서 — WBS 표 + 간트차트 + 영업일 계산 + 진행율 추적을 설치·가입 없이 무료로 사용할 수 있습니다.
WBS·간트차트 도구 열기