WBS 작성 방법 : 실패 없는 프로젝트를 위한 작성 가이드

"계획의 부재는 곧 실패를 계획하는 것과 같습니다."

프로젝트 관리 협회(PMI)의 조사 결과에 따르면 전체 프로젝트의 약 70%가 계획 단계의 부실함 때문에 실패하거나 큰 어려움을 겪는다고 해요. 프로젝트의 성공은 결국 얼마나 꼼꼼하게 밑그림을 그리느냐에 달려 있는 셈이죠.

그래서 필요한 것이 바로 WBS(Work Breakdown Structure, 작업분류체계)입니다. WBS는 복잡한 업무 범위를 계층별로 쪼개어 눈에 보이게 시각화 해 주는 아주 유용한 도구인데요. 막막해 보이는 거대한 프로젝트도 WBS를 통해 업무를 명확히 정의하다 보면 산출물까지의 과정이 구체화되면서 WBS를 작성하기 전보다 쉽게 느껴질 거예요.

이번 가이드는 초보 PM과 기획자분들을 위해 WBS의 핵심 원칙부터 '모바일 앱 개발'과 같은 구체적인 실전 예시를 준비해봤어요. 더불어 계획이 얼마나 현실적인지 검증할 수 있는 신뢰도 측정 지표(KPI)까지 실무 중심으로 꼼꼼하게 정리해 보았으니 WBS 작성이 필요하신 분들은 참고해 보시길 바랍니다!

1. WBS란 무엇이며 왜 프로젝트 관리에 필수적인가요?

1-1. WBS란?

WBS는 프로젝트의 전체 범위를 누락 없이 관리하기 위한 계층형 작업 구조입니다. 프로젝트 목표 달성을 위해 전체 업무를 하위 작업 단위로 세분화하여 계층적으로 구조화하여 정확한 일정/예산 산출, 책임 소재 명확화를 돕는 프로젝트의 설계도 역할을 해요. 

1-2. WBS 작성이 필수적인 이유

WBS는 일정과 예산 산정의 기준이 되는 문서이기 때문에 필수적으로 작성해야 합니다. 그 외에도 WBS 작성이 필수적인 구체적인 이유는 다음과 같습니다.

① 범위의 시각화: 프로젝트의 시작과 끝을 한눈에 파악해 갑자기 업무가 늘어나는 현상을 방지해요.

② 정확한 견적 산출: 작업을 최소 단위로 쪼개야 시간과 비용을 신뢰할 수 있는 수준으로 계산할 수 있어요.

③ 책임 명확화: 각 작업 패키지에 담당자를 지정함으로써 나중에 역할과 책임 문제로 분쟁이 생기는 상황을 예방할 수 있어요.

2. WBS를 구성하는 3대 핵심 원칙과 작성 프로세스는 무엇인가요?

2-1. WBS 3대 핵심 원칙

성공적인 WBS는 '100% 규칙', '상호 배제(MECE)', '80시간 법칙'이라는 세 가지 원칙을 바탕으로 작성합니다. 이 원칙들을 지켜야 WBS가 프로젝트의 모든 범위를 포괄 하면서도 관리가 가능한 수준으로 유지될 수 있어요.

📌 WBS 3대 원칙의 핵심 내용 및 적용 가이드

2-2. 초보자도 따라 하는 WBS 작성 6단계 프로세스는?

WBS 작성은 '범위 명확화 → 접근법 선택 → 계층 분해 → 작업 패키지 정의 → 사전 작성 → 시각화'의 6단계 흐름을 따릅니다. 큰 덩어리를 작게 쪼개는 하향식(Top-down) 접근을 기본으로 합니다.

특히 Step 2 접근법 선택에서 실수가 발생할 확률이 높습니다. 접근법을 선택하는 기준은 간단히 얘기해서 상품 유형입니다. 상품이 결과물(산출물)기반인지, 단계/서비스 기반인지에 따라 작성법이 나뉘어요.

예를 들어 소프트웨어 개발처럼 산출물이 명확한 경우에는 결과물 기반이 유리하고 서비스나 프로세스가 중요한 경우에는 단계 기반으로 작성하는 것이 더 좋습니다. 최근에는 두 가지를 혼합한 하이브리드 형태도 사용되고 있어요. 

👉WBS 기반이 되는 요구사항 정의서 작성법이 궁금하다면?

3. 실전 예시: 프로젝트 유형별 WBS 샘플은 무엇인가요?

프로젝트 유형별 샘플은 웨딩 기획과 같은 서비스 기반 WBS 샘플과 앱 개발과 같은 산출물 기반 WBS 샘플이 있습니다. 두 가지 WBS 샘플을 참고하여 상황에 맞게 적용해보세요.

참고로 이 두 방식이 철저하게 분리되는 것은 아닙니다. 만약 IT 웹/앱 개발을 준비중이더라도 GTM 전략 등 비즈니스가 좀 더 중요할 때는 서비스 기반의 WBS를 작성해보시는 것이 도움이 될 수 있습니다.

3-1. 서비스 기반 프로젝트의 WBS 예시는 어떤 모습인가요?

서비스 기반 WBS는 경험과 운영 단위를 기준으로 구조화합니다. 하위 작업으로 갈수록 구체적인 실행 행동이 드러나도록 설계하여 서비스 품질의 균일성을 확보하는 것이 핵심입니다.

• 운영 중심의 계층 분화: 제품이 아닌 '경험'을 설계 하므로 식장, 의상, 초청 등 서비스 카테고리를 Level 2로 설정하여 관리 범위를 나눕니다.
• 행동 단위의 작업 패키지: Level 4의 '참석 여부 확인 전화'와 같이 실무자가 즉시 실행할 수 있는 행동 단위로 쪼개야 업무 누락을 방지할 수 있습니다.
• 정성적 품질 관리: 서비스는 산출물이 눈에 보이지 않으므로 각 단계마다 '메뉴 확정', '참석 리스트 완료' 등의 마일스톤을 설정하는 것이 중요합니다.

🔎 샘플 : 서비스/프로세스  기반 WBS

• Level 1 (프로젝트명): VIP 초청 웨딩 기획
  • Level 2 (서비스 카테고리): 1. 식장/연회, 2. 의상/메이크업, 3. 초청/의전, 4. 사진/영상
    • Level 3 (상세 서비스 - 식장): 1.1 대관 계약, 1.2 꽃장식 디자인, 1.3 식사 메뉴 시식 및 확정
    • Level 3 (상세 서비스 - 초청): 3.1 초대장 디자인, 3.2 발송 리스트 정리, 3.3 RSVP 확인 콜
      • Level 4 (작업 패키지): 3.3.1 1차 참석 여부 확인 전화 (담당자: 이매니저, 16H)

이를 도식화해서 나타내면 다음과 같습니다.

3-2. 모바일 앱 개발을 위한 산출물 기반 WBS 예시는 무엇인가요?

산출물 기반 WBS는 기능 단위 결과물을 중심으로 구성합니다. 이는 백엔드, 프론트엔드 등 기술적 구성 요소별로 팀을 나누고 책임 소재를 분명히 하는 데 최적화된 구조입니다.

• 신뢰성 강화: 예시의 '40H(시간)'와 같이 구체적인 공수를 할당하면 계획의 신뢰도가 상승합니다.
• 기술적 상호 의존성 고려: IT 프로젝트는 'API 분석'이 선행되어야 '로직 코딩'이 가능한 경우가 많으므로 WBS 작성 시 작업 간의 선후 관계를 명확히 인지해야 합니다.
• 산출물 중심의 구조화: '회원가입 화면', '결제 모듈' 등 눈에 보이는 결과물을 기준으로 분해하여 개발 완료 여부를 객관적으로 판단합니다.

🔎 샘플 : 산출물 기반 WBS

• Level 1 (프로젝트명): 00 쇼핑몰 앱 런칭
  • Level 2 (주요 산출물): 1. 기획/디자인, 2. 프론트엔드, 3. 백엔드/DB, 4. 테스트
    • Level 3 (하위 산출물 - 디자인): 1.1 와이어프레임, 1.2 UI 시안, 1.3 GUI 가이드
    • Level 3 (하위 산출물 - 프론트엔드): 2.1 회원가입 화면 구현, 2.2 상품 목록 UI, 2.3 결제 연동 모듈
• Level 4 (작업 패키지): 2.3.1 PG사 API 분석, 2.3.2 결제 승인 로직 코딩 (담당자: 김개발, 40H)

마찬가지로 도식화해서 나타나면 다음과 같습니다.

4. WBS 사전과 관리 툴은 실전에서 어떻게 활용하나요?

WBS 사전은 각 작업 패키지를 상세하게 정의하고 완료 기준을 기록한 보조 문서입니다. WBS 사전은 업무의 혼선을 방지하는 역할을 하기 때문에 필수적으로 작성 되어야 합니다. 이를 엑셀이나 전용 PM 도구에 기록하여 실시간으로 관리할 수 있습니다.

📌 실무에서 사용하는 WBS 항목

다음 항목들을 엑셀이나 관리 툴에 정리하면 효율적입니다.

1. WBS ID: 계층 구조를 보여주는 고유 번호입니다.
2. 작업명: '메인 화면 UI 디자인'처럼 명사형으로 간결하게 작성합니다.
3. 담당자: 해당 작업을 책임지고 수행할 담당자를 한 명 지정합니다.
4. 산출물: 디자인 원본 파일 등 작업 완료를 증명할 결과물입니다.
5. 예상 기간: 작업을 마치는 데 필요한 소요 시간입니다.
6. 선행 작업: 해당 작업 전에 미리 완료되어야 할 업무의 ID입니다.
7. 예산: 작업에 배정된 비용을 기록합니다.

5. WBS 기반 프로젝트 성과를 검증하는 정량적 측정 지표(KPI)는 무엇인가요?

WBS를 기반으로 프로젝트 성과를 검증하기 위해 획득가치 관리(EVM) 기법인 일정 성과 지수(SPI)와 원가 성과 지수(CPI)가 필요합니다. 두 지표가 1.0 이상일 때 프로젝트가 계획대로 건강하게 진행되고 있음을 의미해요.

만약 지표가 1.0 미만이라면 WBS의 일정 계획이 너무 낙관적이거나 예산 할당에 문제가 있다는 신호이므로 즉시 계획을 조정해야 합니다.

5-1. 핵심 측정 지표

프로젝트를 진행하며 핵심 측정 지표인 SPI와 CPI를 모니터링하고 필요한 경우 WBS를 조정합니다.

• SPI (일정 성과 지수)

$$SPI = \frac{EV(획득가치)}{PV(계획가치)}$$

• 해석
  • SPI < 1: 공정 지연으로 계획보다 일정이 늦어지고 있다는 뜻입니다. WBS에서 일정 계획이 너무 낙관적이진 않았는지, 어떤 작업에서 병목이 생겼는지 확인이 필요합니다. 
  • SPI = 1: 계획대로 진행 중입니다.
  • SPI > 1: 공정 조기 달성으로, 계획보다 작업이 많이 완료됐음을 의미합니다.

• CPI (원가 성과 지수)

$$CPI = \frac{EV(획득가치)}{AC(실제원가)}$$

• 해석
  • CPI < 1: 1.0 미만이면 예산을 초과해서 쓰고 있다는 신호입니다 WBS 예산 할당에 문제가 있음을 나타내요. 
  • CPI = 1: 계획대로 진행 중입니다.
  • CPI > 1: 계획보다 예산이 덜 쓰이고 있습니다. 

5-2. 정성적 검증을 위한 체크리스트

수치 외에도 프로젝트 착수 전에 다음 질문들을 통해 WBS의 논리적 완결성을 점검할 수 있어요. 아래 네 가지 질문에 모두 ‘네’라고 답할 수 있어야 합니다.

✅ 이 작업을 끝내기 위해 중간 산출물이 두 개 이상 필요한가요?

• WBS의 최하위 단위는 더 이상 나눌 수 없는 단일한 결과를 내야 합니다. 내부에 또 다른 하위 절차가 숨어 있다면, 진행 상황을 추적하기 어렵고 일정 지연이 발생했을 때 원인을 파악하기 힘들어집니다. 'Yes'라면 해당 작업을 더 하위 레벨로 분해해야 합니다.

✅ 작업에 필요한 자원과 시간을 90% 이상 확신하며 추정할 수 있나요?

• "이 작업은 대략 3주에서 2달 정도 걸릴 것 같아요"와 같이 불확실한 답이 나온다면, WBS가 충분히 상세하지 않다는 신호입니다. 경험적으로 80시간(2주) 이내로 작업을 쪼개면 예측의 오차 범위를 줄이고 신뢰도를 높일 수 있습니다. 확신할 수 없다면, 예측 가능한 단위가 될 때까지 더 쪼개야 합니다.

✅ 담당자가 업무의 완료 조건을 확실히 이해하고 있나요?

• 이 질문은 작업을 다른 사람에게 위임했을 때, 그가 추가적인 설명 없이도 무엇을 해야 하는지 아는가를 묻는 것입니다. WBS 사전에 인수 기준이 명확히 정의되어 있어야 책임 소재가 분명해지고, 품질 분쟁을 예방할 수 있습니다

✅ 요구사항 정의서의 모든 내용이 WBS에 100% 반영되었나요?

• 하위 작업들의 합은 상위 작업의 100%와 정확히 일치해야 합니다. 요구사항 정의서에는 있는데 WBS에 없다면 '누락'이고, 요구사항에 없는데 WBS에 있다면 '불필요한 작업’입니다. 이 질문을 통해 프로젝트 범위 밖의 일이 슬그머니 끼어드는 '범위 추가'를 차단할 수 있습니다.

6. WBS 기반 프로젝트 관리를 위한 툴이 있나요?

WBS 관리 툴은 Jira, Asana, 그릿지의 옵저버(Observer) 등이 있습니다. 프로젝트 구성원 모두가 작업 구조를 실시간으로 공유하고 업데이트하기 위해 사용해요. 최근에는 엑셀의 수동 관리 방식에서 벗어나 Jira, Asana, 옵저버와 같은 자동화 솔루션을 통해 관리 효율을 높이는 추세입니다.

6-1. 프로젝트 관리 자동화 툴을 사용하면 어떤 점이 좋나요?

자동화 툴은 실시간 데이터 분석을 통해 실수를 방지하고 SPI, CPI 같은 핵심 지표를 자동으로 산출하여 데이터 기반의 의사결정을 지원합니다.

프로젝트 규모가 커질수록 엑셀만으로는 실시간 진척도를 파악하기 어려워요. 자동화 툴을 사용하면 수동 입력 시 발생하는 데이터 누락을 차단할 수 있고, 시각화된 대시보드를 통해 프로젝트의 병목 구간을 즉시 확인할 수 있습니다. 또한 팀원 간의 협업 효율을 극대화하는 장점이 있어요.

• 실시간 데이터 분석 및 시각화: 수동으로 입력하던 일정과 비용 데이터를 자동화 툴이 즉시 계산하여 간트 차트나 대시보드 형태로 시각화해 줍니다.
• 객관적 지표 기반의 리스크 관리: SPI(일정 효율)나 CPI(비용 효율) 같은 핵심 지표를 자동으로 산출하므로 감이 아닌 수치에 근거하여 프로젝트의 병목 구간을 정확히 찾아낼 수 있습니다.
• 협업 효율성 극대화: 모든 팀원이 동일한 WBS 구조 위에서 소통하므로 업무 누락이나 중복을 방지하고 책임 소재를 명확히 할 수 있습니다.

6-2. 옵저버(Observer)는 어떻게 프로젝트 관리를 도울 수 있나요?

옵저버는 WBS 기반의 작업 데이터를 수치화하여 매주 분석 보고서를 제공함으로써 PM이 리스크를 선제적으로 파악하고 관리하도록 돕는 솔루션입니다. 일반적인 툴이 기록에 집중한다면 옵저버는 '분석'에 특화되어 있습니다. PM이 복잡한 계산식을 직접 입력하지 않아도 비용 지출 속도와 일정 준수 여부를 지표로 산출해 줘요. 

• 매주 자동 발송되는 심층 분석 보고서: PM이 복잡한 KPI를 직접 계산할 필요 없이 WBS 기반의 비용 지출과 일정 진척도를 분석한 리포트를 매주 받아볼 수 있습니다.
• 투명한 프로젝트 모니터링: 작업자의 실제 업무량과 산출물을 실시간으로 파악하여 외주 관리 시 발생할 수 있는 소통 문제나 일정 지연 리스크를 사전에 차단합니다.
• 데이터 기반의 정교한 의사결정: 축적된 수치 데이터를 바탕으로 현재 프로젝트의 상태를 진단하고 향후 발생할 수 있는 리스크를 예측하여 프로젝트가 성공할 수 있도록 돕습니다.

👉옵저버 서비스 자세히 확인하러 가기

자주 묻는 질문 (FAQ)

Q1. WBS와 프로젝트 일정표는 어떤 차이가 있나요? 

WBS는 '무엇을(What)' 할지 정의하는 범위 문서이고, 일정표는 '언제(When)' 할지 정하는 시간 문서입니다. 반드시 WBS를 먼저 확정해야 이를 기반으로 현실적인 작업 순서와 일정을 설계할 수 있습니다.

Q2. WBS 작업 패키지는 어느 정도로 상세하게 쪼개야 하나요? 

'80시간 법칙'에 따라 8시간에서 최대 80시간(약 2주) 이내에 완료 가능한 단위로 나눕니다. 너무 세세하면 관리 비용이 커지고, 너무 크면 진척 파악이 어려우므로 결과물 검증이 가능한 단위가 적절합니다.

Q3. 프로젝트 도중에 WBS를 수정해도 괜찮은가요? 

WBS는 승인된 기준선이므로 공식적인 변경 절차를 거치는 것이 원칙입니다. 다만 하이브리드 방식에서는 상위 마일스톤은 유지하되 하위 작업 패키지를 상황에 맞춰 유연하게 조정하며 관리 효율을 높일 수 있습니다.

Q4. 애자일(Agile) 프로젝트에서도 WBS가 필요한가요? 

네, 전체 범위를 놓치지 않기 위해 필수적입니다. 상위 계층을 기능으로 정의해 뼈대를 잡고, 하위 작업을 해당 기능을 개발하기 위해 필요한 작업 목록을 정리하면 유연성과 큰 그림을 동시에 확보할 수 있습니다.

Q5. WBS 작성 시 가장 빈번하게 발생하는 실수는 무엇인가요? 

결과물(명사)이 아닌 행동(동사) 중심으로 작성해 일정표와 혼동하는 경우가 가장 많습니다. 하위 작업의 합이 상위와 다른 '100% 규칙 위반'이나 과도한 세분화도 경계해야 할 주요 실수입니다.

Q6. 효율적인 WBS 관리를 위해 어떤 도구를 추천하나요? 

실시간 데이터 동기화와 시각적 관리가 가능한 전용 PM 툴을 추천합니다. 특히 그릿지의 '옵저버'는 WBS 기반의 진행 현황을 데이터화하여 비용과 일정 리스크를 수치로 보여주므로 신속하고 정확한 의사결정을 돕습니다.

🔎 프로젝트 관리를 보고서로 효율화하고 싶다면 그릿지에 문의 주세요!