[1Week/5day] 프로젝트 범위(Scope)와 WBS 기초

 

 

1장. 프로젝트 목표와 범위(Scope)의 관계

1-1. 프로젝트 목표 vs 산출물 vs 범위

헷갈리기 쉬운 단어들을 먼저 정리해볼게요.

• 프로젝트 목표(Project Objective)
  • “왜 이 프로젝트를 하는가?”
  • 예: “6개월 안에 신규 모바일 앱을 런칭하여 월간 활성 사용자 5만 명을 달성한다.”
• 산출물(Deliverable)
  • 프로젝트가 만들어내는 구체적인 결과물
  • 예: 앱 실행 파일, 관리자 페이지, 매뉴얼, 교육자료, 보고서 등
• 범위(Scope)
  • 어떤 산출물을 어떤 수준까지 만들 것인지에 대한 경계
  • 쉽게 말해 “할 일(포함) 과 안 할 일(제외) 을 정해놓은 것”

시험에서 Scope는 보통

• “무엇까지 해주기로 한 것인가?”
• “어디까지가 프로젝트 책임인가?”
  를 명확히 하는 개념이라고 기억하면 좋아요.

---

1-2. Product Scope vs Project Scope

PMP에서 자주 나오는 구분입니다.

1. Product Scope (제품 범위)
   • 제품/서비스 자체의 기능·특성에 대한 범위
   • 예:
     • “앱은 iOS/Android를 모두 지원한다.”
     • “로그인, 푸시 알림, 결제 기능을 포함한다.”
2. Project Scope (프로젝트 범위)
   • 그 제품을 만들기 위해 프로젝트가 수행할 작업의 범위
   • 예:
     • 요구사항 분석, 설계, 개발, 테스트, 교육, 배포, 초기 운영 지원 등
     • 외부 솔루션 연동, 데이터 마이그레이션 포함 여부 등

기억 팁

• Product Scope: “뭘 가진 제품인지”
• Project Scope: “그걸 만들기 위해 무슨 일을 하는지”

---

2장. 범위 관리의 기본 흐름

범위 관리는 대략 이런 순서로 진행됩니다.

1. 요구사항 수집(Collect Requirements)
   • 이해관계자로부터 “원하는 것/필요한 것”을 모은다.
2. 범위 정의(Define Scope)
   • 수집된 요구사항을 정리·우선순위화해서
     범위 명세서(Project Scope Statement) 로 만든다.
3. WBS 작성(Create WBS)
   • 범위를 잘게 쪼개어 작업 구조도(WBS) 를 만든다.
4. 범위 기준선(Scope Baseline) 설정
   • 범위 명세서 + WBS + WBS Dictionary(설명서)
   • 이후 변경관리는 이 기준선을 기준으로 판단.
5. 범위 검증(Validate Scope)
   • 고객/스폰서가 산출물을 공식적으로 “오케이” 하는 과정.
6. 범위 통제(Control Scope)
   • 변경요청, 요구사항 추가 등으로 범위가 계속 늘어나지 않도록 관리.

Key Point

• “요구사항 무조건 다 해주기”가 아니라
  정해진 범위 안에서 우선순위와 변경을 관리하는 것이 PMP 스타일입니다.

---

3장. WBS(Work Breakdown Structure) 기초

3-1. WBS란?

프로젝트의 전체 범위를, 관리 가능한 작은 작업 덩어리로 단계적으로 쪼개서 나무 구조로 표현한 것

• 위쪽(상위 레벨): 큰 덩어리(단계, 인도물 그룹 등)
• 아래쪽(하위 레벨): 더 작고 구체적인 작업 단위
• 가장 아래 레벨을 보통 Work Package(작업 패키지) 라고 부릅니다.

3-2. WBS를 만드는 이유

1. 전체 범위를 한눈에 볼 수 있다.
2. 누락 방지: “이 트리 안에 없는 일은 범위 밖이다”라고 기준을 세울 수 있다.
3. 역할·일정·비용 계획의 기반이 된다.
   • Work Package 단위로 담당자, 일정, 예산을 배분.

3-3. 100% 규칙(100% Rule)

WBS에서 가장 중요한 규칙:

상위 작업 = 그 아래 모든 하위 작업의 100% 합

• 상위 항목의 범위는
  • 아래에 있는 자식 노드들의 합과 정확히 일치해야 한다.
• 즉,
  • 빠진 것도, 겹치는 것도 없어야 한다 는 의미.

3-4. 좋은 WBS의 특징

• 산출물(Deliverable) 중심으로 쪼개면 좋다.
  • 예: “설계 완료 문서”, “테스트 완료 시스템” 등
• 레벨을 너무 깊게(10단계 이상) 파지 않도록 조절
• 각 Work Package는
  • 담당자/일정/비용을 현실적으로 관리 가능한 크기(예: 며칠~몇 주 단위)

---

3-5. 간단 예시 – “PMP 자격증 취득 프로젝트” WBS

텍스트 버전으로 예시를 그려볼게요.
(실제 WBS 도면은 박스/트리 구조지만, 여기서는 들여쓰기로 표현)

1. PMP 자격증 취득 프로젝트
　1.1. 준비 계획 수립
　　- 1.1.1. 시험 일정/응시 요건 확인
　　- 1.1.2. 교재/강의 선택
　　- 1.1.3. 주간 공부 계획 작성

　1.2. 이론 학습
　　- 1.2.1. 도메인 개요 학습 (People/Process/Business)
　　- 1.2.2. PMBOK 원칙/성과 도메인 학습
　　- 1.2.3. 영역별 심화 학습 (범위/일정/비용/리스크 등)

　1.3. 문제 풀이
　　- 1.3.1. 기본 문제집 1회독
　　- 1.3.2. 오답노트 정리
　　- 1.3.3. 모의고사 2~3회 실시

　1.4. 시험 신청 및 응시
　　- 1.4.1. 경험 정리 및 신청서 작성
　　- 1.4.2. 시험 일정 예약/결제
　　- 1.4.3. 시험장 준비(장비, 신분증, 동선 확인)
　　- 1.4.4. 실제 시험 응시

여기서 가장 아래 레벨(예: 1.2.3, 1.3.2 등)이 Work Package 가 됩니다.
각 Work Package마다 “언제까지, 누가, 어떻게, 어느 정도 분량”을 할지 계획하면 되는 거죠.

---

4장. 오늘 내용 5줄 요약

1. Scope(범위) 는 프로젝트에서 “어디까지 할 것인지/안 할 것인지”를 정하는 개념으로, Product Scope(제품 기능) 와 Project Scope(작업 범위) 를 구분해서 본다.
2. 범위 관리는 요구사항 수집 → 범위 정의 → WBS 작성 → 범위 기준선 설정 → 검증/통제 의 흐름으로 진행된다.
3. WBS(Work Breakdown Structure) 는 전체 범위를 작은 작업 덩어리로 나눈 “작업 구조도”로, 범위 관리의 핵심 도구다.
4. WBS의 100% 규칙: 상위 작업의 범위는 하위 작업들의 합과 정확히 일치해야 하며, 빠짐·중복이 없어야 한다.
5. Work Package 수준까지 잘 쪼개야 이후 역할 배분, 일정 계획, 비용 추정을 현실적으로 할 수 있다.

---

5장. 연습문제 (Day 5 Check)

객관식·O/X 8문제 + 서술형 2문제

문제 1

다음 중 Product Scope 의 예로 가장 적절한 것은?

A. 요구사항 분석, 설계, 개발, 테스트를 수행한다.
B. 앱은 iOS와 Android를 모두 지원하며, 로그인·푸시 알림·결제 기능을 제공한다.
C. 프로젝트 팀은 주 1회 상태 회의를 진행한다.
D. 시험 신청서를 작성하고 응시료를 납부한다.

---

문제 2

다음 중 Project Scope 의 예로 가장 적절한 것은?

A. 웹 서비스는 초당 1,000건 이상의 트래픽을 처리할 수 있어야 한다.
B. 앱은 심플한 디자인을 가져야 한다.
C. 요구사항 워크숍 3회를 진행하고, 정리된 요구사항 문서를 승인받는다.
D. 서비스는 회원가입 없이도 일정 부분 기능을 제공해야 한다.

---

문제 3

다음 설명 중 WBS에 대한 내용으로 옳지 않은 것은?

A. WBS는 프로젝트 범위를 계층 구조로 분해한 것이다.
B. WBS의 가장 아래 레벨 작업을 Work Package라고 부른다.
C. WBS는 주로 프로젝트 일정 관리에만 사용되며, 범위 관리와는 관련이 없다.
D. WBS는 누락 없이 전체 범위를 포함해야 한다.

---

문제 4 (O/X)

“WBS의 100% 규칙은, 상위 작업이 하위 작업들의 합으로 완전히 표현되어야 하며, 하위 작업들 밖에서 추가로 해야 할 일이 없어야 한다는 의미이다.”

---

문제 5

다음 중 범위 관리 프로세스 흐름을 올바른 순서로 나열한 것은?

① 범위 정의(Define Scope)
② WBS 작성(Create WBS)
③ 범위 기준선 설정(Scope Baseline)
④ 요구사항 수집(Collect Requirements)

A. ④ → ① → ② → ③
B. ① → ④ → ② → ③
C. ④ → ② → ① → ③
D. ① → ② → ③ → ④

---

문제 6

다음 상황에서 PMP 관점에서 가장 적절한 PM의 행동은?

프로젝트 진행 중, 특정 이해관계자가
“이왕 하는 김에 이 기능도 같이 넣어주세요. 간단해요.”
라며 추가 기능을 요청했다.
일정·예산은 이미 꽉 찬 상태다.

A. 고객이니까 무조건 받아주고, 팀에게 야근을 요청한다.
B. 추가 기능은 더 좋은 서비스이므로 계획에 상관없이 바로 개발한다.
C. 변경요청으로 접수하여 영향(일정·비용·리스크)을 평가하고, 공식 변경관리 절차에 따라 승인 여부를 결정한다.
D. 귀찮으니 무시하고 진행한다.

---

문제 7

다음 중 Scope 명세서(Project Scope Statement) 의 내용으로 보기 어려운 것은?

A. 프로젝트 산출물 목록과 각 산출물의 주요 특징
B. 프로젝트 범위에 포함되는 것과 제외되는 것
C. WBS의 각 Work Package에 대한 코드(번호 체계)
D. 주요 제약조건과 가정조건(Assumptions)

---

문제 8 (O/X)

“WBS는 반드시 시간 순서로 작업을 나열해야만 한다.”

---

서술형

문제 9 (서술형)

최근에 해본 프로젝트(또는 가상의 예시)를 하나 골라서,
간단한 WBS를 3레벨 정도까지 작성해보세요. (텍스트로, 예: 1 → 1.1 → 1.1.1 형태)

• 1단계: 프로젝트 이름
• 2단계: 큰 작업 덩어리 3~5개
• 3단계: 각 큰 작업 아래에 2~3개의 세부 작업

---

문제 10 (서술형)

다음 문장을 채워보세요.

“내가 경험한 프로젝트에서 Scope가 흔들렸던 사례는 ____ 이고,
그때 생긴 문제는 ____ 이었다.
PMP 관점에서 돌아보면, 미리 ____ 를 했더라면 더 나았을 것 같다.”

---

6장. 정답 & 짧은 해설

문제 1 정답: B

• B: 제품이 어떤 기능을 가지는지에 대한 설명 → Product Scope
• A, C, D: 프로젝트에서 수행하는 작업 → Project Scope에 가깝습니다.

---

문제 2 정답: C

• C: “워크숍 3회 진행 + 문서 승인” → 프로젝트가 수행할 작업 범위(Project Scope)
• A, B, D: 제품이 가져야 할 성능/특성 → Product Scope에 가까움.

---

문제 3 정답: C

• C: WBS는 범위 관리의 핵심 도구이며, 일정·비용 계획에도 쓰입니다. “범위와 관련이 없다”는 설명은 오답.
• A, B, D는 모두 옳은 설명.

---

문제 4 정답: O

• 100% 규칙 = 상위 작업 = 하위 작업들 전체의 합.
• WBS 밖에서 추가로 해야 하는 일이 생기면, WBS·범위를 다시 점검해야 한다는 신호입니다.

---

문제 5 정답: A

• 올바른 흐름:
  ④ 요구사항 수집 → ① 범위 정의 → ② WBS 작성 → ③ 범위 기준선 설정.

---

문제 6 정답: C

• PMP 관점에서는 “좋게 봐서 범위 늘리기” 가 아니라
  공식 변경관리 절차를 밟는 것이 정답입니다.
• A, B: Scope Creep(슬금슬금 범위 증가)의 전형적 사례.
• D: 무시도 안 됨.

---

문제 7 정답: C

• C: Work Package 코드 체계는 보통 WBS 자체나 WBS Dictionary에 포함되는 정보.
• A, B, D: Scope Statement에 충분히 들어갈 수 있는 내용입니다.

---

문제 8 정답: X

• WBS는 작업의 논리적/산출물 중심 구조이지, 반드시 시간 순서일 필요는 없습니다.
• 일정 순서는 이후에 네트워크 다이어그램/스케줄링 단계에서 다룹니다.

---

문제 9·10 (서술형)

• 정답은 없고, “내 프로젝트를 Scope/WBS 관점으로 다시 보는 연습”이 핵심입니다.
• 실제로 간단한 WBS를 작성해 보면, 나중에 일정·비용·리스크 배울 때 훨씬 이해가 잘 될 거예요.