3.1 범위 정의 | 프로젝트 매니지먼트 입문

3.1 범위 정의

프로젝트 매니지먼트에서 프로젝트 범위를 정의하는 일은 가장 중요한 단계 중 하나입니다. 왜일까요? 범위가 곧 운동장을 정해주기 때문입니다. 프로젝트가 무엇을 책임지고, 무엇을 인도하려 하는지 — 그리고 똑같이 중요한, 무엇이 범위 밖인지 — 를 정의해 주거든요.

범위가 모호한 채로 프로젝트를 시작하면 오해, 추가되는 일, 일정 압박, 예산 초과를 자초하게 됩니다. 분명히 정의된 범위는 팀에 자신감을 주고 의사결정을 위한 단단한 토대를 만들어 줍니다.

범위란 무엇인가?

PMBOK(프로젝트 매니지먼트 지식 체계)는 범위를 이렇게 정의합니다.

"명시된 기능과 특성을 갖춘 제품, 서비스, 또는 결과물을 인도하는 데 필요한 작업."

그러니까 범위에는 산출물과 그것을 만들기 위한 작업 모두 포함됩니다. 그리고 똑같이 중요한 점이 하나 더 있어요. 포함되지 않는 것을 정의하는 것 — 즉 범위 외 항목입니다.

범위 정의가 왜 중요한가

• 이해관계자의 기대 관리: "그것도 같이 해주겠지" 같은 말로 표현되지 않은 가정을 막아줍니다.
• 프로젝트의 경계 명확화: 팀이 무엇을 책임지고 무엇은 책임지지 않는지에 대한 분명한 기준점을 줍니다.
• 변경 통제 가능: 새로 들어온 요청이 범위 안인지 공식 변경이 필요한지 판단할 수 있습니다.
• 진척 추적 지원: 잘 정의된 범위는 무엇이 완료되고 무엇이 남았는지 측정하기 쉽게 해줍니다.

모호한 범위는 흔히 지연, 비용 초과, 품질 이슈의 근본 원인이 됩니다.

범위 정의 단계

1. 요구사항 수집

이해관계자를 인터뷰해 기대와 니즈를 모읍니다. 처음에는 폭넓게 모으세요 — 디테일은 나중에 다듬으면 됩니다.

2. 범위 기술서 작성

요구사항을 구체적인 작업 정의로 옮깁니다. 무엇을 할 것이고 무엇을 하지 않을 것인지 분명히 적고, 이해관계자의 동의를 받습니다.

3. WBS로 분해

범위를 작업 분해 구조도(WBS)를 통해 작고 다룰 수 있는 태스크로 변환합니다. 이는 일정 수립과 자원 배분의 토대가 됩니다.

4. 범위 기준선(Scope Baseline) 수립

범위 기술서, WBS, WBS 사전을 묶어 범위 기준선으로 만듭니다. 이는 추적과 변경 관리의 공식 기준점이 됩니다.

범위 문서의 일반적인 구성

• 프로젝트 배경과 목표
• 산출물 목록
• 범위 내 작업
• 범위 외 제외 항목
• 제약 조건
• 가정 사항

흔한 함정

• 이해관계자 어긋남: 범위 세부 내용을 공유하지 않으면 "그게 포함 안 되는지 몰랐는데"가 나옵니다.
• 제외 항목이 분명하지 않음: 예상치 못한 일과 자원 부담으로 이어집니다.
• 너무 일찍 너무 자세히 잡음: 시작 시점에 정밀도가 과하면 나중에 유연성이 줄어듭니다.

요약: 범위는 상호 합의입니다

범위는 단순한 태스크 목록이 아닙니다. 팀과 이해관계자 사이의 공동 합의 — 이후 모든 결정의 토대이죠.

프로젝트를 성공적으로 이끌려면 분명한 선을 그을 수 있는 스킬과 용기가 필요합니다. 무엇이 안에 있고 무엇이 밖에 있는지를요. 그게 바로 범위 정의가 다루는 일입니다.

AB에서는 이렇게 동작합니다

AB Project Management에서는 프로젝트 자체가 곧 범위 경계입니다 — 태스크는 떠다니지 않고 프로젝트 안에 살아요. 프로젝트 설명란에는 한 줄짜리 범위 기술이 들어가고, 프로젝트 위키에는 "Out of Scope" 표시가 분명한 더 긴 범위 문서가 들어갑니다. 나중에 어떤 이해관계자가 "X도 같이 해주신 거 아니에요?"라고 묻는다면, 그 페이지와 변경 이력을 가리키면 됩니다. 새로 들어오는 요청은 태스크로 받아 "Backlog / Out of Scope" 섹션으로 태깅하거나 옮기면, 범위를 늘릴지 말지에 대한 대화가 자연 누적이 아니라 명시적으로 일어납니다.

→ 다음: 3.2 프로젝트 일정 수립