WBS 작성법: 일정·담당자·선후행 관계까지 정리하는 실무 예시

WBS 작성법을 찾다 보면 예쁜 일정표부터 만들고 싶어진다. 그런데 날짜와 담당자부터 채우면 빠진 산출물이 뒤늦게 발견되고, 일정이 바뀔 때마다 표 전체가 흔들리기 쉽다. WBS는 프로젝트의 전체 범위를 산출물 중심으로 빠짐없이 나눈 뒤, 가장 아래 작업 단위에 담당자·기간·선후행 관계를 연결하는 문서다. 이번 글에서는 초보 IT PM이 바로 써볼 수 있도록 회원가입 개선 프로젝트 예시와 빈칸 템플릿, 검토 체크리스트까지 차근차근 정리해 보았다!

WBS란 무엇인가?

WBS는 Work Breakdown Structure의 약자로, 프로젝트에서 만들어야 할 결과와 필요한 일을 계층적으로 분해한 작업분류체계다. PMI의 WBS Practice Standard 안내는 WBS가 프로젝트의 전체 범위를 조직하고, 일정·예산·리스크·성과 추적의 기반이 된다고 설명한다.

핵심은 단순히 할 일을 길게 나열하는 것이 아니다.

• 프로젝트 목표를 큰 산출물로 나눈다.
• 큰 산출물을 관리 가능한 하위 산출물로 분해한다.
• 가장 아래의 작업 패키지에 완료 기준과 책임을 연결한다.
• 전체 범위가 빠지거나 중복되지 않았는지 확인한다.

즉, WBS는 “언제 할까?”보다 먼저 “무엇을 완성해야 프로젝트 범위가 모두 충족될까?”에 답한다.

WBS와 일정표·간트차트는 무엇이 다를까?

실무에서는 WBS와 일정표를 한 시트에서 함께 관리하는 경우가 많아 두 개념이 섞이기 쉽다.

구분	WBS	일정표·간트차트
핵심 질문	무엇을 빠짐없이 완성해야 하는가?	누가 언제 어떤 순서로 수행하는가?
중심	범위와 산출물	시간과 작업 순서
구조	상위 산출물 → 하위 산출물 → 작업 패키지	작업 → 기간 → 선행·후행 관계
주요 결과	범위 누락·중복 방지	시작일·종료일·병목 확인

좋은 순서는 WBS로 범위를 먼저 정리하고, 가장 아래 작업 패키지를 일정 활동으로 구체화한 뒤 날짜와 의존성을 연결하는 것이다. WBS와 일정표는 경쟁하는 문서가 아니라 앞뒤로 이어지는 도구다.

좋은 WBS의 핵심 원칙 4가지

1. 산출물 중심으로 나눈다

회의하기, 디자인하기, 개발하기처럼 활동만 적으면 무엇이 완성되어야 끝나는지 모호하다. 대신 요구사항 목록 승인, 회원가입 화면 최종안, 회원가입 API, 통합 테스트 결과서처럼 확인 가능한 결과를 중심으로 적는다.

나쁜 예

디자인 검토하기

좋은 예

회원가입 화면 최종안 승인 완료

동사로 적힌 활동이 필요하다면 작업 패키지 아래 일정 활동으로 연결한다. WBS의 상위 구조는 가능하면 산출물이 보이도록 만드는 편이 범위 관리에 유리하다.

2. 100% 규칙으로 빠짐과 중복을 확인한다

PMI의 WBS 안내 자료는 WBS가 프로젝트 범위의 모든 일을 포함해야 한다는 100% 규칙을 설명한다. 상위 항목을 하위 항목으로 나눴다면 하위 항목의 합이 상위 범위를 전부 설명해야 한다.

• 범위에 있는 일을 빠뜨리지 않는다.
• 범위 밖의 일을 슬쩍 추가하지 않는다.
• 같은 일을 두 항목에 중복 배치하지 않는다.
• 기획·개발뿐 아니라 프로젝트 관리, 검수, 인수인계 같은 일도 범위에 있다면 포함한다.

3. 관리 가능한 작업 패키지까지 분해한다

작업 패키지는 WBS의 가장 아래에서 일정·비용·담당자를 관리할 수 있는 단위다. 무조건 작은 단위로 잘게 쪼개는 것이 목적은 아니다. 다음 질문에 답하기 어렵다면 한 단계 더 나눌 필요가 있다.

• 완료 결과를 한 문장으로 설명할 수 있는가?
• 담당 책임자를 한 명으로 정할 수 있는가?
• 필요한 기간과 자원을 합리적으로 추정할 수 있는가?
• 완료 여부를 객관적으로 확인할 수 있는가?
• 진행 상황을 보고할 수 있을 만큼 크기가 적절한가?

4. 같은 레벨에서는 같은 분해 기준을 유지한다

기획, 디자인, 로그인 API, 3일을 같은 레벨에 두면 단계·산출물·작업·기간이 뒤섞인다. 한 레벨을 프로젝트 단계로 나눴다면 그 아래도 단계 기준을 유지하고, 산출물 기준을 선택했다면 같은 층에는 비슷한 크기의 산출물을 둔다.

WBS 작성법 7단계

1. 목표와 범위를 한 문장으로 고정한다

WBS를 열기 전에 프로젝트가 무엇을 끝내야 하는지 먼저 적는다.

예시: 기존 회원가입 이탈을 줄이기 위해 가입 흐름을 개선하고, 검증된 새 버전을 운영 환경에 적용한다.

포함 범위와 제외 범위도 함께 확인한다. 예를 들어 회원가입 화면과 인증 API는 포함하지만, 가입 이후 프로필 입력 개편은 제외한다고 명시하면 범위가 번지는 일을 줄일 수 있다.

2. 최상위 산출물을 나눈다

회원가입 개선 프로젝트라면 다음처럼 큰 결과부터 잡을 수 있다.

1. 요구사항 확정
2. UX·UI 설계
3. 개발 완료
4. 테스트·출시
5. 프로젝트 관리

프로젝트 단계로 시작할 수도 있지만, 각 항목 안에서 무엇이 완성되는지 산출물이 드러나야 한다.

3. 하위 산출물과 작업 패키지로 분해한다

각 상위 항목을 관리 가능한 수준까지 나눈다.

1. 회원가입 개선 프로젝트
  1.1 요구사항 확정
    1.1.1 현행 이슈 목록
    1.1.2 요구사항 정의서 승인본
  1.2 UX·UI 설계
    1.2.1 사용자 흐름도
    1.2.2 회원가입 화면 최종안
  1.3 개발 완료
    1.3.1 인증 API
    1.3.2 회원가입 클라이언트 기능
  1.4 테스트·출시
    1.4.1 통합 테스트 결과서
    1.4.2 운영 배포 및 확인 기록

WBS 코드는 1.2.2처럼 계층을 추적하는 식별자다. 문서·티켓·회의록에서도 같은 코드를 쓰면 변경 영향을 찾기 쉬워진다.

4. 작업 패키지의 완료 기준을 적는다

회원가입 화면 최종안만 적으면 담당자마다 완료를 다르게 해석할 수 있다. 간단한 WBS 사전 또는 비고 열에 다음 내용을 붙인다.

• 산출물 설명
• 포함·제외 범위
• 책임자
• 검토·승인자
• 완료 기준
• 연결된 요구사항·화면·티켓 ID

예를 들어 완료 기준을 정상·오류·로딩 상태가 포함되고 기획·개발 검토 의견이 반영된 디자인 링크 승인처럼 적으면 진행률을 느낌으로 판단하는 일을 줄일 수 있다.

5. 담당자와 협업자를 연결한다

작업을 실제 수행하는 사람이 여러 명이어도 최종 책임자는 한 명으로 명확히 두는 편이 좋다. 담당자를 부서명만으로 적으면 확인 요청이 떠돌 수 있으니, 조직 상황에 맞게 책임자와 협업자를 구분한다.

실제 이름이 정해지지 않았다면 임의로 만들지 말고 {{프론트엔드 담당자 — 실제 배정 후 입력}}처럼 표시한다.

6. 선후행 관계를 연결한다

일정은 모든 작업을 위에서 아래로 순서대로 놓는다고 완성되지 않는다. 어떤 작업이 끝나야 다음 작업을 시작할 수 있는지 확인해야 한다.

가장 흔한 관계는 완료 후 시작(Finish-to-Start, FS)이다. 예를 들어 요구사항 승인이 끝난 뒤 개발 착수가 시작되는 관계다. Microsoft Project 공식 안내는 FS 외에도 동시 시작 조건인 SS, 동시 완료 조건인 FF, 드물게 사용하는 SF 관계를 설명한다.

초보 PM이라면 먼저 다음만 분명하게 적어도 충분하다.

• 선행 작업 ID
• 관계 유형: 기본은 FS
• 반드시 기다려야 하는 승인·검수
• 병렬로 진행 가능한 작업
• 외부 일정이나 의사결정에 의존하는 항목

7. 기간과 날짜를 넣고 팀과 검토한다

작업 패키지와 의존성이 정리된 뒤 기간을 추정하고 시작일·종료일을 계산한다. 담당자 휴가, 외부 심사, 검수 회차, 배포 가능 요일 같은 제약도 함께 확인한다.

일정을 PM 혼자 확정하지 말고 실제 수행자와 다음을 검토하자.

• 빠진 산출물이 없는가?
• 작업 크기와 기간 추정이 현실적인가?
• 동시에 맡은 다른 업무가 반영되었는가?
• 선행 작업이 늦어지면 어떤 일정이 영향을 받는가?
• 검토·승인 시간이 포함되었는가?

회원가입 개선 프로젝트 WBS 실무 예시

아래 표는 구조를 이해하기 위한 간단한 예시다. 실제 기간과 담당자는 팀 데이터에 맞게 바꿔야 한다.

WBS ID	작업 패키지·산출물	책임자	선행 작업	기간	완료 기준
1.1.1	현행 이슈 목록	PM	-	{{기간}}	이탈 구간·문의·기술 제약 정리 및 팀 확인
1.1.2	요구사항 정의서 승인본	PM	1.1.1 FS	{{기간}}	범위·예외·인수 조건 승인
1.2.1	사용자 흐름도	UX	1.1.2 FS	{{기간}}	정상·오류·중단 흐름 검토 완료
1.2.2	회원가입 화면 최종안	UI	1.2.1 FS	{{기간}}	주요 상태와 반응형 화면 승인
1.3.1	인증 API	백엔드	1.1.2 FS	{{기간}}	API 명세 기준 기능·오류 처리 확인
1.3.2	회원가입 클라이언트 기능	프론트엔드	1.2.2 FS, 1.3.1 FS	{{기간}}	화면·API 연동 및 코드 리뷰 완료
1.4.1	통합 테스트 결과서	QA	1.3.2 FS	{{기간}}	정상·예외·경계값 결과와 잔여 이슈 기록
1.4.2	운영 배포 확인 기록	개발 리드	1.4.1 FS	{{기간}}	배포·모니터링·롤백 준비 확인

여기서 중요한 점은 날짜를 그럴듯하게 채우는 것이 아니라, 작업의 완료 결과와 연결 관계를 먼저 합의하는 것이다. 실제 일정은 팀의 생산성, 병행 업무, 검수 정책을 확인한 뒤 입력하자.

바로 복사해 쓰는 WBS 템플릿

# {{프로젝트명}} WBS

## 프로젝트 기준
- 목표:
- 포함 범위:
- 제외 범위:
- 기준일:
- 일정 단위:
- 상태 기준:

## WBS
| WBS ID | 상위 ID | 산출물·작업 패키지 | 설명 | 책임자 | 협업자 | 선행 작업·관계 | 기간 | 시작일 | 종료일 | 완료 기준 | 상태 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| 1.1.1 | 1.1 |  |  |  |  |  |  |  |  |  | 예정 |

## WBS 사전
### {{WBS ID와 항목명}}
- 산출물 설명:
- 포함 범위:
- 제외 범위:
- 입력 자료:
- 완료 기준:
- 검토자·승인자:
- 연결 문서·티켓:
- 가정·제약:

WBS 작성할 때 자주 하는 실수

날짜부터 채운다

일정 압박 때문에 날짜를 먼저 넣으면 누락된 범위를 발견할 때 전체 일정이 다시 흔들린다. 먼저 산출물 구조와 완료 기준을 합의한 뒤 일정을 연결한다.

한 항목이 너무 크다

앱 개발처럼 몇 주 동안 상태가 바뀌지 않는 항목은 관리가 어렵다. 완료 결과와 책임이 달라지는 지점으로 나눈다.

모든 항목을 같은 깊이까지 억지로 나눈다

복잡한 개발 항목은 깊게 나뉘고, 단순한 공지 작성은 얕게 끝날 수 있다. 레벨 수를 맞추는 것보다 관리 가능성과 범위 완전성이 중요하다.

진행률을 감으로 적는다

80% 완료라고 써도 남은 일이 무엇인지 알 수 없다면 의미가 약하다. 가능하면 완료 기준을 충족한 항목은 완료, 아직이면 진행 중으로 판단하고 잔여 작업을 따로 적는다.

담당자와 승인자를 구분하지 않는다

작업자는 끝났다고 생각하지만 승인자는 검토하지 않은 상태가 생길 수 있다. 수행 책임과 검토·승인 책임을 분리해 표시한다.

WBS 검토 체크리스트

• 프로젝트 목표와 포함·제외 범위가 적혀 있다.
• 상위 항목이 산출물 또는 일관된 단계 기준으로 나뉘어 있다.
• 하위 항목의 합이 상위 범위를 100% 설명한다.
• 범위 밖 작업과 중복 항목이 없다.
• 중간 산출물, 검수, 프로젝트 관리 업무도 필요한 만큼 포함했다.
• 작업 패키지마다 완료 결과를 확인할 수 있다.
• 책임자를 한 명으로 식별할 수 있다.
• 기간을 실제 수행자와 검토했다.
• 선행 작업과 병렬 작업이 구분되어 있다.
• 검토·승인·외부 의존 일정이 반영되어 있다.
• 요구사항·화면·개발 티켓·테스트 항목과 연결된다.
• 변경 시 영향받는 일정과 산출물을 추적할 수 있다.

WBS 작성법 FAQ

WBS는 어느 수준까지 쪼개야 하나요?

정해진 단계 수보다 관리 가능성이 기준이다. 완료 결과, 책임자, 기간, 비용을 합리적으로 추정하고 진행 상황을 확인할 수 있다면 작업 패키지로 충분하다. 판단하기 어렵다면 한 단계 더 나눈다.

WBS에 날짜와 담당자를 꼭 넣어야 하나요?

WBS 자체의 핵심은 범위와 산출물 구조다. 다만 실무에서는 작업 패키지를 일정 관리에 바로 연결하기 위해 담당자, 기간, 선행 작업, 시작일·종료일을 같은 표에 두기도 한다. 구조와 일정의 역할을 구분해서 관리하면 된다.

WBS와 백로그는 같은 문서인가요?

같지 않다. WBS는 프로젝트 전체 범위를 계층적으로 보여 주고, 백로그는 제품에 필요한 항목을 우선순위에 따라 관리한다. 애자일 프로젝트에서도 주요 산출물과 릴리스 범위를 WBS로 정리하고 상세 개발 항목은 백로그로 연결할 수 있다.

일정이 바뀌면 WBS도 다시 써야 하나요?

기간만 바뀌고 범위와 산출물이 같다면 WBS 구조는 유지하고 일정 정보를 조정하면 된다. 산출물이 추가·삭제되거나 완료 기준이 달라진다면 범위 변경으로 보고 WBS와 연결 문서를 함께 갱신한다.

WBS 작성법 핵심 정리

WBS 작성법의 핵심은 할 일을 촘촘하게 적는 데 있지 않다. 프로젝트 범위를 산출물 중심으로 나누고, 100% 규칙으로 누락과 중복을 확인한 뒤, 관리 가능한 작업 패키지에 완료 기준·책임자·선후행 관계를 연결하는 것이 중요하다. 일정은 그다음이다. 이 순서를 지키면 지연 원인과 변경 영향을 훨씬 빠르게 찾을 수 있다~

참고한 최신 출처

• PMI: Practice Standard for Work Breakdown Structures – Third Edition
• PMI: Developing and elaborating effective work breakdown structures
• Atlassian: Work breakdown structure (WBS) definition and guide
• Microsoft Support: How Project schedules tasks