핵심 인사이트
- 본질: WBS (Work Breakdown Structure)는 프로젝트 인도물(Deliverable)을 관리 가능한 단위로 계층적으로 분해한 구조체로, "100% 규칙"이 핵심—하위 요소의 합이 상위 요소를 완전히 포괄해야 한다.
- 가치: WBS가 없으면 일정(CPM), 비용(EVM), 자원 계획이 모두 부실해진다—WBS는 프로젝트 계획 전체의 골격이다.
- 판단 포인트: WBS는 "어떻게 할 것인가(How)"가 아니라 "무엇을 만들 것인가(What)"를 분해하는 것이다—활동이 아닌 인도물 중심으로 구성해야 한다.
Ⅰ. 개요 및 필요성
WBS (Work Breakdown Structure, 작업 분류 체계)는 프로젝트 범위(Scope)를 인도물(Deliverable) 중심으로 계층적으로 분해한 구조이다. PMBOK 범위관리(Scope Management) 지식 영역의 핵심 도구로, 프로젝트의 전체 작업을 누락·중복 없이 정의하기 위해 사용된다.
WBS가 필요한 이유는 프로젝트 범위가 명확하지 않으면 일정·비용·자원 계획이 모두 불안정해지기 때문이다. 범위 확산(Scope Creep)—승인되지 않은 작업이 점진적으로 추가되는 현상—도 WBS가 없을 때 발생하기 쉽다. WBS를 확정하면 계획된 것 외의 작업 추가를 공식 변경 프로세스를 통해서만 허용할 수 있다.
실무에서 WBS는 단순한 작업 목록이 아니다. WBS의 최하위 단위인 작업 패키지(Work Package)에 예산·일정·자원이 할당되고, EVM (Earned Value Management) 측정의 기반이 된다. WBS 사전(WBS Dictionary)은 각 작업 패키지의 세부 정의, 담당자, 기간, 비용, 완료 기준을 문서화한다.
📢 섹션 요약 비유: WBS는 레고 세트의 설명서와 같다. 완성품(프로젝트)을 만들기 위해 필요한 모든 부품(인도물)을 조각별로 정의하고, 어떤 순서로 조립할지 기준을 제공한다.
Ⅱ. 아키텍처 및 핵심 원리
WBS 계층 구조
┌───────────────────────────────────────────────────────────────┐
│ 프로젝트 (레벨 0) │
│ [ERP 구축 프로젝트] │
└───────────────────────┬───────────────────────────────────────┘
┌─────────────┼──────────────┐
▼ ▼ ▼
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ 1.요구분석 │ │ 2.설계 │ │ 3.구현 │ ← 레벨 1
└──────┬──────┘ └──────┬──────┘ └──────┬──────┘
│ │ │
┌────┴────┐ ┌────┴────┐ ┌────┴────┐
▼ ▼ ▼ ▼ ▼ ▼
[1.1] [1.2] [2.1] [2.2] [3.1] [3.2]
인터뷰 요구 아키텍처 UI 백엔드 프론트 ← 레벨 2
수행 문서 설계 설계 개발 개발
│
┌────┴────┐
▼ ▼
[1.2.1] [1.2.2]
SRS작성 검토회의 ← 레벨 3 (Work Package)
100% 규칙 (100% Rule)
핵심 원칙:
┌────────────────────────────────────────────────────────┐
│ 상위 WBS = Σ(하위 WBS) │
│ │
│ 2. 설계 (100%) │
│ = 2.1 아키텍처 설계 (40%) │
│ + 2.2 UI 설계 (30%) │
│ + 2.3 DB 설계 (30%) │
│ │
│ ✅ 누락 없음 (100% 포괄) │
│ ✅ 중복 없음 (각 항목 고유) │
└────────────────────────────────────────────────────────┘
WBS 관련 핵심 개념
| 개념 | 설명 | 역할 |
|---|---|---|
| Work Package (작업 패키지) | WBS 최하위 단위, 추정·할당 가능 | 일정·비용의 기본 단위 |
| WBS Dictionary (사전) | 각 요소의 세부 정의 문서 | 의미 명확화 |
| Control Account (통제 계정) | EVM 측정 지점 | EV/PV/AC 측정 |
| Planning Package (계획 패키지) | 미래 상세화 대기 항목 | 점진적 구체화 |
| 범위 기준선 (Scope Baseline) | WBS + WBS Dictionary + 범위 기술서 | 변경 통제 기준 |
WBS vs OBS vs RBS
┌──────────────────────────────────────────────────────────────┐
│ WBS (Work Breakdown Structure): 인도물 중심 분해 │
│ 프로젝트 → 단계 → 인도물 → 작업 패키지 │
│ │
│ OBS (Organizational Breakdown Structure): 조직 중심 분해 │
│ PMO → 개발팀 → 테스트팀 → 운영팀 │
│ │
│ RBS (Resource Breakdown Structure): 자원 중심 분해 │
│ 자원 → 인력 → 장비 → 소프트웨어 │
│ │
│ RAM (Responsibility Assignment Matrix): │
│ WBS × OBS → RACI 매트릭스 생성 │
└──────────────────────────────────────────────────────────────┘
📢 섹션 요약 비유: WBS의 100% 규칙은 퍼즐 조각과 같다. 모든 조각을 빠짐없이 맞춰야(누락 없음) 하고, 같은 조각이 두 번 들어가면 안 된다(중복 없음). 하나라도 빠지거나 겹치면 완성된 그림이 나오지 않는다.
Ⅲ. 비교 및 연결
WBS 분해 방식 비교
| 분해 방식 | 설명 | 장점 | 단점 |
|---|---|---|---|
| 인도물 중심 (Deliverable-based) | 산출물 단위로 분해 (권장) | 범위 명확, 검증 쉬움 | 활동 도출 추가 필요 |
| 단계 중심 (Phase-based) | SDLC 단계로 분해 | 이해하기 쉬움 | 인도물 불명확 위험 |
| 팀 중심 (Team-based) | 조직 단위로 분해 | 자원 할당 쉬움 | 통합 관리 어려움 |
WBS 수준 결정 기준
| 기준 | 설명 |
|---|---|
| 80시간 규칙 | 작업 패키지당 최대 80시간 (약 2주) |
| 추정 가능성 | 비용·기간을 합리적으로 추정할 수 있는 수준 |
| 책임 할당 가능성 | 단일 담당자나 팀에게 명확히 할당 가능한 수준 |
| 측정 가능성 | 진도 측정이 가능한 수준 |
WBS vs 간트 차트 vs 네트워크 다이어그램
| 도구 | 표현 | 주요 용도 |
|---|---|---|
| WBS | 계층 구조 (트리) | 범위 정의, 분해 |
| 간트 차트 (Gantt Chart) | 수평 막대 시간표 | 일정 시각화 |
| 네트워크 다이어그램 | 화살표 흐름도 | 의존성·주공정 분석 |
📢 섹션 요약 비유: WBS, 간트 차트, 네트워크 다이어그램은 같은 프로젝트를 보는 다른 안경이다. WBS는 "무엇을"(목차), 간트는 "언제"(달력), 네트워크는 "어떤 순서로"(흐름도)를 보여준다.
Ⅳ. 실무 적용 및 기술사 판단
WBS 작성 프로세스
1단계: 프로젝트 범위 기술서 검토
→ 프로젝트의 목표, 인도물, 제외 사항 확인
2단계: 1수준(레벨 1) 정의
→ 주요 인도물 또는 단계 식별 (보통 5~9개)
3단계: 점진적 분해 (Progressive Decomposition)
→ 각 레벨을 관리 가능한 수준까지 분해
→ 80시간 규칙 적용
4단계: WBS Dictionary 작성
→ 각 Work Package별 정의, 담당자, 기간, 비용, 완료 기준
5단계: 검토 및 승인
→ 팀원, 이해관계자와 함께 100% 규칙 검증
6단계: 범위 기준선 확정
→ WBS + WBS Dictionary + 범위 기술서 = 범위 기준선
기술사 시험 판단 포인트
-
WBS ≠ 활동 목록: WBS는 인도물(Deliverable) 분해이고, 활동 목록(Activity List)은 WBS를 실현하기 위한 행위의 목록이다.
-
Control Account: Work Package를 하나 이상 묶어 EVM 측정 지점으로 삼는 것. 프로젝트 관리자가 직접 관리하는 단위.
-
Planning Package vs Work Package: Planning Package는 미래에 상세화될 WBS 구성요소로, 현재는 범위만 정의되고 세부 작업은 미확정 상태.
-
Gold Plating 방지: WBS에 정의되지 않은 기능을 자발적으로 추가하는 행위(Gold Plating)는 PMBOK에서 지양해야 할 나쁜 관행으로 분류.
실무 WBS 예시: 웹 서비스 구축
1. 웹 서비스 구축
1.1 프로젝트 관리
1.1.1 프로젝트 헌장
1.1.2 주간 상태 보고서
1.2 요구사항 분석
1.2.1 사용자 인터뷰
1.2.2 SRS (Software Requirements Specification)
1.3 설계
1.3.1 시스템 아키텍처 설계서
1.3.2 UI/UX 프로토타입
1.3.3 DB 설계서
1.4 개발
1.4.1 백엔드 API
1.4.2 프론트엔드 화면
1.4.3 DB 구축
1.5 테스트
1.5.1 단위 테스트 결과서
1.5.2 통합 테스트 결과서
1.5.3 사용자 인수 테스트 결과서
1.6 배포 및 운영 이관
1.6.1 운영 환경 배포
1.6.2 운영 매뉴얼
📢 섹션 요약 비유: WBS 작성은 여행 짐 싸기 리스트와 같다. "옷"이라고만 쓰면 뭘 챙겼는지 모르지만, "반팔 3장, 긴바지 2벌, 속옷 5세트"로 쓰면 빠진 게 없는지 바로 확인할 수 있다.
Ⅴ. 기대효과 및 결론
WBS를 체계적으로 작성하면:
- 범위 확산 방지: "WBS에 없으면 프로젝트 범위 밖"이라는 명확한 기준을 제공해 비공식 추가 작업을 방지한다.
- 비용·일정 정확성 향상: Work Package 수준에서 추정하므로 상향식 추정의 정확도를 높인다.
- 책임 명확화: 각 작업 패키지에 담당자를 지정해 책임 공백을 제거한다.
- EVM 기반 마련: Control Account를 통해 EVM 측정이 가능해져 프로젝트 성과를 객관적으로 모니터링한다.
WBS는 단 한 번에 완벽하게 만드는 것이 아니라 **점진적 구체화(Progressive Elaboration)**를 통해 발전시킨다. 프로젝트 초기에는 상위 수준만 정의하고, 해당 단계가 다가오면 상세 분해한다.
📢 섹션 요약 비유: WBS 없는 프로젝트는 설계도 없이 집을 짓는 것과 같다. 공사는 시작할 수 있지만 중간에 무엇이 빠졌는지, 얼마나 남았는지 아무도 정확히 알 수 없어 결국 예산과 시간이 두 배가 든다.
📌 관련 개념 맵
| 개념 | 설명 | 연관 키워드 |
|---|---|---|
| WBS (Work Breakdown Structure) | 인도물 중심 계층적 작업 분해 | 범위관리, PMBOK |
| 100% 규칙 (100% Rule) | 하위 WBS 합 = 상위 WBS (누락·중복 없음) | 범위 기준선 |
| Work Package (작업 패키지) | WBS 최하위 단위, 80시간 이내 | Control Account |
| WBS Dictionary (사전) | 각 요소의 세부 정의·담당·비용 | 범위 기준선 |
| Control Account (통제 계정) | EVM 측정 지점 | EVM, PV, EV, AC |
| Scope Creep (범위 확산) | 비공식 범위 추가 현상 | 변경 통제 |
| OBS (Organizational Breakdown Structure) | 조직 계층 분해 | RACI, RAM |
| PBS (Product Breakdown Structure) | 제품 중심 분해 (WBS의 변형) | 시스템 엔지니어링 |
👶 어린이를 위한 3줄 비유 설명
- WBS는 케이크 만들기 레시피예요 — 완성된 케이크(프로젝트)를 만들려면 필요한 재료(인도물)를 하나도 빠짐없이 목록에 적어야 해요.
- 100% 규칙은 퍼즐 조각 규칙이에요 — 모든 조각을 한 번씩만 써야 완성된 그림이 나오고, 하나 빠지거나 겹치면 그림이 이상해져요.
- WBS가 없으면 중간에 "이거 누가 해?" 하는 작업이 계속 생겨서, 결국 모든 것이 늦어지고 비용이 많이 들어요.