WBS 작성법 — 작업분류체계를 제대로 쪼개는 원칙과 예시
WBS를 한 번이라도 만들어 봤다면 이런 경험이 있을 겁니다. 열심히 쪼개서 표를 채웠는데 막상 프로젝트가 시작되니 "이건 누가 하지?", "이 일은 표에 없는데?"가 계속 튀어나오는 상황이요. 원인은 대부분 쪼개는 원칙 없이 생각나는 대로 나열했기 때문입니다. 이 글에서는 WBS를 만들 때 지켜야 할 100% 규칙과 8/80 규칙, 산출물 중심 분해, 분해를 멈추는 기준을 설명하고, 실제 예시 WBS 표 두 개로 어디까지 쪼개야 하는지 감을 잡도록 돕습니다. 일정 관리 4단계 글에서 다룬 개요보다 한 단계 깊게, WBS 작성 자체에만 집중합니다. 만든 WBS에 날짜를 붙여 막대로 그리는 법은 간트차트 보는 법, 작업 사이의 선후 관계를 따지는 법은 크리티컬 패스 계산법에서 이어집니다.
WBS란 무엇이고 왜 만드는가
WBS(Work Breakdown Structure, 작업분류체계)는 프로젝트가 만들어 내야 할 결과물을 위에서 아래로 계층적으로 분해한 구조입니다. 맨 위에는 프로젝트 전체가 있고, 그 아래에 큰 덩어리(단계나 주요 산출물), 그 아래에 더 작은 덩어리가 이어지며, 가장 아래에는 한 사람이 며칠 안에 끝낼 수 있는 작업 패키지(work package)가 놓입니다.
WBS를 만드는 목적은 세 가지입니다. 첫째, 범위를 고정합니다. WBS에 있으면 이 프로젝트의 일이고, 없으면 아닙니다. 둘째, 추정의 근거가 됩니다. "앱 개발 한 달"은 감이지만, 작업 패키지 30개에 각각 2~5일씩 붙이면 왜 한 달인지 설명할 수 있습니다. 셋째, 책임을 나누는 단위가 됩니다. 담당자·기간·진행율은 모두 WBS의 가장 아래 항목에 붙고, 위로 집계됩니다.
WBS를 쪼개는 원칙 5가지
WBS가 실제로 작동하려면 아래 다섯 가지 원칙을 지켜야 합니다. 순서대로 중요합니다.
원칙 1. 100% 규칙 — 자식을 다 합치면 부모가 되어야 한다
WBS에서 가장 중요한 원칙입니다. 어떤 항목의 하위 항목들을 전부 합치면 그 항목이 하는 일의 100%가 되어야 하고, 그 이상도 이하도 아니어야 합니다. 예를 들어 "2. 디자인" 아래에 "2.1 와이어프레임, 2.2 시안"만 있는데 실제로는 디자인 리뷰와 수정 작업이 반복된다면, 그 시간은 표 어디에도 없습니다. 반대로 "2.3 개발 API 명세"처럼 디자인이 아닌 일이 섞여 있으면 부모의 범위를 벗어난 것입니다.
실무에서 100% 규칙을 점검하는 가장 간단한 방법은 각 부모 항목 옆에서 "이것들만 다 끝나면 이 항목이 완료된 건가?"라고 소리 내어 물어보는 것입니다. "아니, 아직 ~도 남았는데"라는 답이 나오면 그 ~를 하위에 추가합니다. 프로젝트 관리, 회의, 리뷰, 배포 같은 관리성 작업이 이 질문에서 가장 자주 발견됩니다.
원칙 2. 8/80 규칙 — 작업 패키지의 크기
가장 아래 항목(작업 패키지)의 크기는 대략 8시간(하루) 이상, 80시간(2주) 이하가 적당하다는 경험칙입니다. 하루보다 작으면 관리하는 비용이 일하는 비용보다 커지고, 2주보다 크면 중간에 얼마나 됐는지 알 수 없어 지연을 늦게 발견합니다.
숫자 자체보다 의도가 중요합니다. 주 1회 진행율을 갱신하는 팀이라면 작업 패키지는 보고 주기 안에 상태가 바뀔 정도의 크기여야 합니다. 2주 단위로 점검하는 팀은 80시간까지도 괜찮지만, 매일 스탠드업을 하는 팀은 1~3일짜리로 더 잘게 가는 편이 자연스럽습니다. 프로젝트 초반 작업은 크게, 당장 다음 2~4주의 작업은 잘게 쪼개는 롤링 웨이브(rolling wave) 방식도 흔히 씁니다.
원칙 3. 산출물 중심으로 쪼갤 것인가, 단계 중심으로 쪼갤 것인가
2단계(맨 위 바로 아래)를 무엇으로 나누느냐에 따라 WBS의 성격이 정해집니다.
| 분해 방식 | 2단계 항목 예 | 장점 | 주의점 |
|---|---|---|---|
| 산출물 중심 | 회원가입 기능 / 결제 기능 / 관리자 화면 | 범위가 명확하고 100% 규칙 점검이 쉬움. "무엇이 남았나"가 바로 보임 | 기획·디자인·개발이 산출물마다 반복돼 같은 담당자의 일이 여기저기 흩어짐 |
| 단계(phase) 중심 | 기획 / 디자인 / 개발 / 테스트 / 배포 | 담당 조직과 잘 맞고 시간 순서대로 읽힘 | "개발"이 뭉뚱그려지기 쉬워 빠진 산출물을 놓치기 쉬움 |
| 혼합 | 2단계는 단계, 3단계는 산출물 (또는 그 반대) | 실무에서 가장 흔한 형태 | 계층마다 기준이 일관돼야 함. 같은 층에 단계와 산출물이 섞이면 안 됨 |
정답은 없지만, 처음 만든다면 산출물 중심을 권합니다. "무엇을 만들어야 끝나는가"에서 출발하면 100% 규칙을 지키기가 훨씬 쉽고, 나중에 단계별로 다시 묶는 것은 어렵지 않기 때문입니다. 단, 같은 층에서는 기준을 섞지 않아야 합니다. "1. 기획, 2. 결제 기능, 3. 개발"처럼 단계와 산출물이 같은 층에 있으면 결제 기능의 개발이 2번인지 3번인지 아무도 모릅니다.
원칙 4. 번호 체계와 이름 붙이기
WBS 항목에는 1, 1.1, 1.1.1처럼 점으로 이어지는 번호를 붙입니다. 번호만 봐도 몇 단계인지, 누구의 자식인지 알 수 있어야 하기 때문입니다. 회의에서 "1.2.3 말하는 거예요"처럼 이름 대신 번호로 부를 수 있다는 점도 큽니다.
- 상위 항목은 명사로 씁니다. "결제 기능", "행사 장소" 같은 산출물·묶음 이름입니다.
- 작업 패키지는 동사형으로 씁니다. "결제 API 연동", "장소 계약서 서명"처럼 무엇을 하면 끝나는지가 드러나야 합니다.
- 이름에 완료 조건이 암시되면 좋습니다. "테스트"보다 "결제 시나리오 20건 테스트 통과"가 진행율을 판단하기 쉽습니다.
원칙 5. 분해를 멈추는 기준
"어디까지 쪼개야 하나"는 WBS를 만들 때 가장 많이 받는 질문입니다. 아래 조건이 모두 만족되면 그 항목은 더 쪼개지 않아도 됩니다.
- 담당자 한 명(또는 한 팀)이 책임질 수 있다. 두 부서가 나눠 해야 하면 더 쪼갭니다.
- 기간을 자신 있게 추정할 수 있다. "3일에서 3주 사이"처럼 폭이 넓으면 아직 덩어리가 큰 것입니다.
- 끝났는지 아닌지 판단할 산출물이 있다. 문서, 코드, 계약서, 승인 메일 등 무엇이든 좋습니다.
- 8/80 규칙 안에 들어온다.
- 더 쪼개도 관리에 도움이 안 된다. "메일 쓰기 → 메일 보내기"처럼 쪼개면 표만 길어집니다.
실제 예시 WBS 표 2개
원칙만으로는 감이 안 오니, 성격이 다른 두 프로젝트의 WBS를 통째로 보여 드립니다.
예시 1. 소규모 앱 출시 WBS (4단계)
기획자 1명, 디자이너 1명, 개발자 2명이 8주 정도에 걸쳐 작은 서비스를 출시하는 상황입니다. 2단계는 단계 중심, 3단계 이하는 산출물 중심으로 섞은 혼합형입니다. 기간은 영업일입니다.
| 번호 | 항목 | 담당 | 기간(영업일) |
|---|---|---|---|
| 1 | 기획 | — | (하위 집계) |
| 1.1 | 요구사항 정의서 | 기획 | 4 |
| 1.2 | 화면 목록·흐름도 | 기획 | 3 |
| 1.3 | 기획 리뷰 및 확정 | 기획 | 2 |
| 2 | 디자인 | — | (하위 집계) |
| 2.1 | 와이어프레임 | 디자인 | 4 |
| 2.2 | UI 시안 (1차·2차 수정 포함) | 디자인 | 6 |
| 2.3 | 디자인 가이드·아이콘 내보내기 | 디자인 | 2 |
| 3 | 개발 | — | (하위 집계) |
| 3.1 | 회원가입·로그인 | — | (하위 집계) |
| 3.1.1 | 인증 API | 개발A | 4 |
| 3.1.2 | 가입·로그인 화면 | 개발B | 3 |
| 3.1.3 | 화면·API 연동 및 예외 처리 | 개발B | 2 |
| 3.2 | 핵심 기능(목록·상세) | — | (하위 집계) |
| 3.2.1 | 데이터 모델·조회 API | 개발A | 5 |
| 3.2.2 | 목록·상세 화면 | 개발B | 5 |
| 3.3 | 배포 환경 구성(서버·도메인·모니터링) | 개발A | 3 |
| 4 | 테스트·출시 | — | (하위 집계) |
| 4.1 | 통합 테스트 및 버그 수정 | 개발A·B | 5 |
| 4.2 | 스토어 등록 자료(스크린샷·설명) 준비 | 기획·디자인 | 2 |
| 4.3 | 출시 및 출시 후 이틀 모니터링 | 개발A | 3 |
| 5 | 프로젝트 관리(주간 회의·보고) | 기획 | 전 기간 |
눈여겨볼 점은 1.3 리뷰, 2.2의 수정 포함, 3.1.3 연동·예외 처리, 3.3 배포 환경, 5 프로젝트 관리입니다. 처음 WBS를 만들면 대부분 빠지는 항목들이고, 실제 일정에서는 이 항목들이 전체의 20~30%를 차지합니다.
예시 2. 사내 행사(100명 규모 워크숍) 준비 WBS (3단계)
총무팀 2명이 6주 전부터 준비하는 상황입니다. 이번에는 2단계부터 산출물 중심입니다. 개발 프로젝트가 아니어도 WBS는 똑같이 작동합니다.
| 번호 | 항목 | 담당 | 기간(영업일) |
|---|---|---|---|
| 1 | 장소·식사 | — | (하위 집계) |
| 1.1 | 후보 장소 3곳 견적 비교 | 김OO | 3 |
| 1.2 | 장소 계약 및 결제 품의 | 김OO | 4 |
| 1.3 | 식사·다과 메뉴 확정 및 인원 통보 | 김OO | 2 |
| 2 | 프로그램 | — | (하위 집계) |
| 2.1 | 세션 구성안 및 연사 섭외 | 박OO | 5 |
| 2.2 | 발표 자료 취합 및 형식 통일 | 박OO | 3 |
| 2.3 | 팀 빌딩 활동 준비물 구매 | 박OO | 2 |
| 3 | 참석자 안내 | — | (하위 집계) |
| 3.1 | 초대 메일 발송 및 참석 확인 취합 | 김OO | 5 |
| 3.2 | 이동 버스 예약 및 좌석 배정 | 김OO | 2 |
| 3.3 | 당일 안내문·명찰 제작 | 박OO | 2 |
| 4 | 당일 운영·정산 | — | (하위 집계) |
| 4.1 | 당일 진행(등록·진행·촬영) | 김OO·박OO | 1 |
| 4.2 | 비용 정산 및 결과 보고서 | 박OO | 3 |
행사처럼 마감일이 고정된 프로젝트는 WBS를 만든 뒤 뒤에서부터 거꾸로 날짜를 붙이는 방식이 잘 맞습니다. 행사일에서 3.3(2일)과 3.2(2일)를 빼면 그 전에 3.1이 끝나야 한다는 식으로요.
담당자와 기간은 어디에 붙이나
원칙은 간단합니다. 담당자·기간·진행율은 가장 아래 작업 패키지에만 적고, 상위 항목은 하위에서 집계합니다. 상위 항목의 기간은 하위 작업들의 가장 이른 시작일부터 가장 늦은 종료일까지이고, 진행율은 하위 작업의 기간이나 공수로 가중 평균합니다. 상위 항목에 직접 기간을 입력하기 시작하면 하위와 어긋나기 시작하고, 어느 쪽이 맞는지 아무도 모르게 됩니다.
기간은 달력일이 아니라 영업일로 잡는 것이 안전합니다. 예시 1의 "4.1 통합 테스트 5일"이 달력으로 5일이면 주말이 끼는 순간 실제 작업일은 3일로 줄어듭니다. 영업일 계산은 영업일 계산법 글에서 자세히 다룹니다.
흔한 실수 5가지
- 활동을 나열만 한다. "회의, 조사, 개발, 테스트"처럼 동사만 늘어놓으면 100% 규칙을 점검할 기준(산출물)이 없습니다. 각 항목이 무엇을 만들어 내는지 적으세요.
- 너무 잘게 쪼갠다. 반나절짜리 항목이 100개면 갱신 자체가 일이 됩니다. 8/80 규칙을 기준으로 합치세요.
- 관리 작업을 빠뜨린다. 주간 회의, 리뷰, 승인 대기, 문서화, 배포 준비는 "일이 아닌 것 같아서" 빠지지만 실제로는 가장 자주 일정을 잡아먹습니다.
- 같은 층에 기준이 섞인다. 단계와 산출물, 부서와 기능이 한 층에 섞이면 중복과 누락이 동시에 생깁니다.
- 한 사람이 혼자 만든다. 담당자가 보지 않은 WBS는 담당자의 일과 다릅니다. 아래 합의 과정을 거치세요.
팀과 합의하는 방법
WBS는 만드는 것보다 합의하는 것이 더 중요합니다. 실제로 잘 작동했던 순서는 이렇습니다.
- PM(또는 기획자)이 2단계까지만 초안을 만듭니다. 30분이면 됩니다.
- 2단계 항목별로 담당 팀이 3단계 이하를 직접 채웁니다. 이때 8/80 규칙과 "이것만 다 하면 끝인가?" 질문을 안내합니다.
- 한자리에 모여 항목을 하나씩 읽으며 중복(두 팀이 같은 일을 넣음)과 누락(아무도 안 넣은 인터페이스 작업)을 찾습니다. 보통 팀 사이의 경계에서 누락이 나옵니다.
- 작업 패키지마다 담당자와 영업일 기간을 담당자가 직접 말하게 합니다. 남이 정해 준 기간은 지켜지지 않습니다.
- 합의된 버전을 기준선으로 저장하고, 이후 변경은 이유와 함께 기록합니다.
엑셀로 만들까, 도구를 쓸까
WBS는 엑셀로도 충분히 만들 수 있고, 처음에는 오히려 엑셀이 빠릅니다. 문제는 기간을 붙이고 진행율을 갱신하기 시작한 뒤입니다. 상위 항목 집계, 영업일 계산, 오늘 기준으로 지연된 작업 표시를 엑셀 수식으로 유지하다 보면 항목 하나를 끼워 넣을 때마다 수식이 깨집니다.
이 사이트의 WBS·간트차트 도구는 최대 4레벨 계층으로 항목을 넣으면 번호가 자동으로 붙고, 시작일·종료일을 넣으면 주말과 공휴일 관리에 등록한 날을 뺀 영업일이 계산되며, 상위 항목의 기간과 진행율이 하위에서 집계됩니다. 합의가 끝난 WBS를 엑셀(.xlsx)로 내려받아 공유하는 것도 됩니다. 다만 위 예시를 도구에 옮길 때 알아 둘 동작이 세 가지 있습니다.
- 번호는 행의 위치로 매겨집니다. 1.2 행을 드래그해 1.1 위로 올리면 두 항목의 번호가 서로 바뀝니다. 회의에서 번호로 항목을 부르는 팀이라면, 기준선을 확정한 뒤에는 순서를 옮기지 말고 새 항목은 해당 그룹의 맨 끝에 추가하세요. 그래야 지난주 보고서의 "3.1.2"와 이번 주의 "3.1.2"가 같은 일을 가리킵니다.
- 계층은 4레벨이 한계입니다. 예시 1처럼 4단계(3.1.1)면 충분히 들어가지만, 5단계 이상이 필요하다면 그 아래는 비고 칸이나 담당자의 체크리스트로 넘깁니다.
- "프로젝트 관리 — 전 기간" 같은 행은 업무량을 부풀립니다. 예시 1의 5번 항목을 8주짜리 행으로 넣으면 영업일 40일이 업무량 합계와 진행율 가중치에 그대로 더해져, 실제 작업 진척이 희석되어 보입니다. 관리성 작업은 주간 회의처럼 짧은 반복 행 몇 개로 나누거나, 전체 진행율에서 빼고 싶다면 날짜를 비워 두고 비고에 "매주 월 10시"처럼만 적어 두는 방법이 있습니다. 날짜가 없는 행은 업무량 0으로 계산됩니다.
어느 쪽을 쓰든 WBS 구조를 먼저 합의하고, 그 다음에 도구로 옮기는 순서가 맞습니다.
자주 묻는 질문
WBS는 몇 단계까지 쪼개야 하나요?
정해진 단계 수는 없습니다. 보통 3~4단계면 충분하고, 더 중요한 것은 가장 아래 작업 패키지가 8/80 규칙(대략 1일~2주 분량)에 들어오고 담당자 한 명이 책임질 수 있느냐입니다. 큰 프로젝트라도 5단계를 넘기면 표가 읽히지 않으므로, 그 아래는 담당자의 체크리스트로 넘기는 편이 낫습니다.
WBS에 기간과 담당자를 꼭 넣어야 하나요?
WBS 자체는 '무엇을 할 것인가'의 구조이고, 기간·담당자는 그 다음 단계인 일정 계획에서 붙입니다. 다만 실무에서는 한 표에 같이 적는 것이 편하므로, 가장 아래 작업 패키지에만 담당자와 영업일 기준 기간을 적고 상위 항목은 하위에서 자동 집계되게 두면 됩니다.
WBS와 할 일 목록(To-do)은 뭐가 다른가요?
할 일 목록은 생각나는 활동을 평면적으로 나열한 것이고, WBS는 최종 산출물에서 출발해 빠짐없이(100% 규칙) 계층적으로 분해한 것입니다. 그래서 WBS는 '이 일이 왜 필요한지'가 상위 항목으로 설명되고, 빠진 일과 중복된 일을 구조적으로 찾아낼 수 있습니다.
WBS를 만들었는데 일정이 계속 바뀝니다. WBS도 매번 고쳐야 하나요?
기간과 담당자가 바뀌는 것은 일정 변경이므로 WBS 구조는 그대로 두고 값만 갱신하면 됩니다. WBS 구조 자체를 고쳐야 하는 경우는 범위가 바뀔 때(새 기능 추가, 산출물 삭제)이며, 이때는 100% 규칙이 유지되는지 상위 항목까지 다시 확인해야 합니다.
정리
WBS는 프로젝트의 결과물을 100% 규칙에 맞게 계층적으로 쪼갠 구조이며, 가장 아래 작업 패키지는 8/80 규칙 안에서 담당자 한 명이 책임지고 완료를 판단할 수 있는 크기여야 합니다. 같은 층에서는 분해 기준(산출물 또는 단계)을 섞지 말고, 번호 체계로 계층을 드러내며, 리뷰·승인·배포·관리 같은 숨은 작업을 반드시 포함하세요. 담당자와 기간은 작업 패키지에만 붙이고 상위는 집계하게 두면 표가 어긋나지 않습니다. 마지막으로, WBS는 혼자 만드는 문서가 아니라 담당자들과 항목 하나하나를 읽으며 합의하는 문서입니다.
4단계 WBS를 만들면 번호·영업일 기간·상위 집계가 자동으로 계산되고, 같은 화면에서 간트차트로 볼 수 있습니다. 설치·가입 없이 무료이며, 데이터는 브라우저에만 저장됩니다.
WBS·간트차트 도구 열기