3줄 요약
- 범위 관리의 핵심은 “무엇을 할 것인가”보다 “무엇을 하지 않을 것인가”를 먼저 정의하는 것이다.
- WBS(작업분류체계)는 100% 규칙으로 산출물을 빠짐없이 분해하는 강력한 도구이지만, 유동적인 SW 요구사항 앞에서는 에픽→스토리 방식의 진화형 분해와 병행해야 한다.
- 스코프 크립(범위 슬금슬금 확장)은 프로젝트의 가장 흔한 실패 원인 중 하나다. 요구사항 변경 로그와 “그럼 무엇을 뺄까” 협상이 유일한 대응이다.
“프로젝트 막바지에 범위가 처음 계획의 두 배가 됐는데 일정은 그대로였다.” 이 문장에 고개를 끄덕인다면, 이 장이 당신을 위한 것이다. PMBOK 5장은 범위 관리(Scope Management)를 다룬다. WBS 작성법, 요구사항 수집, 그리고 범위가 조용히 커지는 현상인 스코프 크립까지. 결론부터 말하면, 범위 관리의 본질은 경계를 그리는 일이다. “우리가 할 것”과 “하지 않을 것”의 선을 이해관계자 모두가 납득한 상태로 확정하는 것. 이 경계가 흐릿할수록 일정도, 원가도, 품질도 다 흔들린다.
📖 PMBOK 5장이 말하는 범위 관리란?
PMBOK 6판 기준, 범위 관리는 여섯 개 프로세스로 구성된다. 순서대로 짚어보자.
- 범위 관리 계획: 이 프로젝트에서 범위를 어떻게 정의하고, 확인하고, 통제할지 방식을 먼저 정한다.
- 요구사항 수집: 이해관계자의 필요와 기대를 인터뷰·워크숍·설문 등으로 끌어낸다. 여기서 빠진 요구사항이 나중에 스코프 크립의 씨앗이 된다.
- 범위 정의: 수집한 요구사항을 바탕으로 프로젝트 범위 기술서(Project Scope Statement)를 작성한다. 무엇을 만들 것인지, 그리고 무엇은 만들지 않는지(Out of Scope)를 문서로 확정한다.
- WBS 생성: 범위를 계층적으로 쪼개 작업분류체계(Work Breakdown Structure)를 만든다. 최하위 단위는 작업 패키지(Work Package)로, 더 이상 쪼개기 어려운 실행 가능한 산출물 단위다.
- 범위 확인: 완료된 인도물을 이해관계자가 공식 수락하는 프로세스다. 고객 서명 혹은 명시적 승인이 해당한다.
- 범위 통제: 승인된 범위 기준선(Scope Baseline)과 실제 진행을 비교해 변경이 생겼을 때 공식 절차를 밟게 한다.
이 중 가장 핵심은 WBS다. WBS의 핵심 원칙은 100% 규칙이다. 자식 노드들의 합이 반드시 부모 노드 전체를 커버해야 한다. 아무것도 빠지면 안 되고, 중복도 안 된다. WBS는 활동(동사)이 아니라 산출물(명사) 중심으로 작성한다. “기능 개발”이 아니라 “회원가입 화면”, “API 명세서”, “테스트 리포트”처럼. 이 차이가 중요하다. 산출물이 명확해야 완료 기준도 명확해지기 때문이다.
✅ 정석에서 여전히 유효한 것들
솔직히 말하면 범위 관리의 뼈대 논리는 지금도 틀린 게 없다. 경험으로 배운 것들이 정석에 이미 있었다는 걸 PMBOK을 읽으면서 다시 확인하게 된다.
첫째, “Out of Scope”를 문서에 명시하는 것. 범위 기술서에 “우리가 하지 않을 것”을 적는 행위는 단순한 문서화가 아니다. 이해관계자와의 계약이자, 나중에 “그거 당연히 해주는 거 아닌가요?”라는 말을 막는 증거다. 많은 PM이 할 것 목록만 적고 안 할 것은 생략하는데, 이게 스코프 크립의 첫 번째 구멍이다.
둘째, WBS로 분해해 누락을 잡는 사고. 머릿속에서 “다 될 것 같은데”라고 느끼는 것과, WBS로 계층을 그려 내려가며 확인하는 것은 다르다. 분해 과정에서 “아, 이 부분은 누가 하지?”라는 질문이 나오는 지점이 반드시 있다. 그 지점을 초기에 잡을 수 있다는 것만으로 WBS는 충분히 가치 있다.
셋째, 요구사항 수집을 공식 프로세스로 다루는 것. 비공식적인 구두 대화만으로 요구사항을 정리하면 나중에 “제가 그런 말 한 적 없는데요”가 나온다. PMBOK이 인터뷰·워크숍·프로토타입을 별도 기법으로 열거하는 이유가 있다. 요구사항은 수집하는 게 아니라 끌어내고, 정제하고, 합의하는 과정이다.
⚠️ IT 현장에서 이 정석이 깨지는 지점
그런데 현실 SW 프로젝트에서 PMBOK 5장 그대로 적용하면 금방 벽에 부딪힌다.
첫 번째 벽: SW 요구사항은 프로젝트 초기에 100% 확정되지 않는다. WBS의 100% 규칙은 범위가 초기에 완전히 파악 가능하다는 전제를 깔고 있다. 건축이나 제조라면 그럴 수 있다. 하지만 소프트웨어는 다르다. 첫 화면을 보고 나서야 “아, 이게 필요하네”를 깨닫는 게 이해관계자의 본성이다. 착수 시점에 WBS를 100% 완성해야 한다는 압박 자체가 현실과 맞지 않는다.
두 번째 벽: WBS는 산출물 중심인데, 개발은 활동 중심으로 돌아간다. “회원가입 화면”이라는 산출물 하나에도 기획·설계·개발·QA·배포라는 복수의 활동이 붙는다. WBS를 엄격히 산출물로만 유지하면 업무 배정과 일정 관리가 따로 놀게 된다. 실무에서는 산출물과 활동을 혼합한 변형 WBS를 많이 쓰는데, 이게 PMBOK의 정석과는 다소 멀어진다.
세 번째 벽: 스코프 크립(Scope Creep)은 막을 수 없는 상수다. 스코프 크립이란 공식 변경 관리 절차 없이 범위가 조금씩 늘어나는 현상이다. 원인은 대부분 악의가 아니다. “하는 김에 이것도요”, “사실 이게 있어야 완성인 거 아닌가요?” 같은 말이 쌓이면 범위는 조용히 두 배가 된다. PMBOK은 범위 통제 프로세스로 이를 막으라고 하지만, 현장에서 이해관계자에게 “공식 변경 요청서를 써오세요”라고 말하기가 쉽지 않다.
🔧 실전 번역 — 그래서 어떻게 하나
정석이 깨지는 지점을 알았다면, 실전에서 어떻게 변형해 쓸지를 봐야 한다.
- 범위 기술서는 “안 할 것”부터 적어라. 할 것 목록은 누구나 만든다. 하지 않을 것(Out of Scope)을 명시하는 순간 이해관계자의 기대 범위가 좁아진다. 킥오프 미팅에서 이 목록을 스크린에 띄우고 “이것들은 이번에 하지 않습니다”를 공식화하는 것만으로 나중의 수많은 논쟁을 줄일 수 있다.
- WBS 대신 에픽→스토리로 진화형 분해를 써라. SW 프로젝트라면 최상위 산출물(에픽)만 선확정하고, 하위 스토리는 스프린트를 진행하면서 채워나가는 방식이 현실적이다. 100% 규칙을 처음부터 강제하는 것보다, 에픽 단위 범위 합의 → 스토리 단위 점진적 구체화가 유동적 요구사항에 더 잘 맞는다.
- 요구사항 변경 로그를 남겨라. 별도 시스템이 없어도 된다. 스프레드시트 하나에 “요청 일자 / 요청자 / 내용 / 영향도 / 수락 여부”를 기록하는 것만으로 나중에 “저 그런 말 안 했는데요”를 막을 수 있다. 변경은 거절이 아니라 “그럼 기존 항목 중 무엇을 빼거나 미룰까요?”로 협상하라. 추가만 있고 제거가 없는 범위는 프로젝트를 죽인다.
- 범위 기준선(Baseline)을 스냅샷으로 남겨라. 범위가 변경될 때마다 직전 버전을 보관해두면, 현재 범위가 초기 대비 얼마나 늘었는지를 객관적으로 보여줄 수 있다. 이 데이터가 있어야 “범위가 두 배가 됐으니 일정도 재협상해야 한다”는 주장에 설득력이 생긴다.
| PMBOK 정석 | IT 현장 실전 변형 |
|---|---|
| WBS 100% 선확정 | 에픽 선확정 + 스토리 점진적 채움 |
| 산출물(명사) 중심 WBS | 산출물·활동 혼합 + 도구별 형식 조정 |
| 공식 변경 요청서 | 경량 요구사항 변경 로그 + 범위 트레이드오프 협상 |
| 범위 기술서 (Out of Scope 포함) | 킥오프 때 Out of Scope 목록 공식화 |
🟥 PSTA로 보면
PSTA의 계층 구조는 범위 관리의 핵심 문제를 구조적으로 풀려 시도한다. Project(프로젝트) → Service(기능·메뉴 단위) → Action(실제 실행 단위)의 3계층이 WBS의 하향식 트리 골격과 맞닿아 있다. Project와 Service는 PM·PO가 상위에서 범위를 설정하는 축이고, Action은 팀원이 하위에서 직접 등록하는 상향식 채움이다. 이 혼합형 구조 덕분에 초기에 모든 범위를 선확정하지 않아도 팀이 진행하면서 점진적으로 범위를 구체화할 수 있다. 유동적인 SW 요구사항에 현실적으로 대응하는 방식이다.
🟨 다만 PSTA도 아쉬운 점이 있다. WBS의 100% 규칙을 강제하지 않기 때문에, 팀원이 Action을 누락해도 시스템이 경고하지 않는다. 범위 완결성을 보장하려면 PM이 Service 단위로 직접 점검해야 한다. 또한 범위 기준선(Baseline) 스냅샷 기능이 약해서, 초기 범위 대비 현재 범위가 얼마나 늘었는지를 한눈에 추적하기 어렵다. 스코프 크립 감지는 사람 손이 필요하다.
🎓 이 장을 떼면 당신은 이것을 할 수 있다
- 프로젝트 킥오프 전 “Out of Scope” 목록을 작성해 이해관계자와 합의할 수 있다.
- WBS 또는 에픽→스토리 구조로 범위를 계층적으로 분해하고, 누락된 작업 패키지를 조기에 발견할 수 있다.
- 스코프 크립을 감지했을 때 “그럼 무엇을 뺄까”로 범위 트레이드오프를 협상할 수 있다.
- 요구사항 변경 로그를 유지해, 범위 변경의 히스토리와 영향도를 언제든 설명할 수 있다.
- 범위 기준선 스냅샷을 남겨 초기 범위와 현재 범위의 차이를 데이터로 보여줄 수 있다.
❓ FAQ — 범위 관리·WBS에 대해 자주 묻는 것들
WBS를 꼭 만들어야 하나요?
WBS 형식을 반드시 따를 필요는 없지만, “범위를 계층적으로 분해한다”는 사고 자체는 필수다. SW 프로젝트라면 에픽→스토리→태스크 구조가 WBS의 실질적 대체제다. 이름이 중요한 게 아니라, 범위를 쪼개어 누락을 잡는 행위가 중요하다.
스코프 크립을 어떻게 막나요?
100% 막기는 어렵고, 막으려 해서도 안 된다. 요구사항은 변한다. 핵심은 “변경을 가시화하는 것”이다. 변경 요청이 올 때마다 변경 로그에 기록하고, 수락 시 “대신 기존 무엇을 조정할지”를 함께 결정하면 된다. 변경 자체가 아니라 변경의 비용을 이해관계자가 인식하게 만드는 것이 스코프 크립 통제의 본질이다.
요구사항이 계속 바뀌면 WBS가 의미 있나요?
최상위 레벨의 WBS(에픽 수준)는 여전히 유효하다. 세부 항목이 바뀌더라도, 큰 산출물 단위의 합의는 유지되기 때문이다. 세부 레벨은 진화형으로 채워나가면 된다. WBS를 한 번 만들고 끝내는 문서가 아니라 살아있는 구조로 관리하는 게 현실적인 접근이다.
WBS와 백로그의 차이는 무엇인가요?
WBS는 산출물 중심의 계층적 분해 구조로, 전통적 프로젝트 관리에서 범위의 완결성을 보장하는 도구다. 백로그는 우선순위가 붙은 요구사항 목록으로, 애자일에서 점진적으로 구체화되고 변경되는 것을 전제한다. WBS는 계획 수립 시 한 번 만들고 기준선으로 고정하는 반면, 백로그는 상시 조정된다. 실무에서는 에픽 수준 WBS + 스토리 단위 백로그를 함께 쓰는 혼합형이 많다.
범위 관리는 기술이 아니라 협상이다. 무엇을 할 것인지를 합의하는 일이자, 무엇을 하지 않을 것인지를 용기 있게 못 박는 일이다. PMBOK이 제시하는 WBS와 범위 기술서는 그 협상을 구조화하는 도구다. 도구는 상황에 맞게 변형해 쓰면 된다. 중요한 것은 경계를 그리는 습관이다. 범위 관리에 대해 더 이야기하고 싶다면 주니크에 문의하거나 PSTA를 직접 살펴보세요.
『PMBOK 완독기』 시리즈
← 이전: 02. 통합관리: 헌장과 변경통제 (4장)
→ 다음: 04. 일정관리: 공수 산정과 크리티컬 패스 (6장)
