프로젝트 범위 정의: 스코프 크립을 막는 법

“이것도 좀 추가해주세요”라는 한마디. 별것 아닌 듯한 이 요청이 쌓이고 쌓여 프로젝트를 무너뜨립니다. 처음 정한 것보다 할 일이 슬금슬금 늘어나 일정은 밀리고 팀은 지치는 현상, 바로 스코프 크립(scope creep, 범위추가)입니다. 이를 막으려면 프로젝트가 무엇을 하고 무엇을 하지 않을지, 그 경계를 처음부터 명확히 그어야 합니다. 이 글에서 범위 정의와 스코프 크립 방지법을 다루겠습니다.

범위란 무엇인가

프로젝트 범위(Scope)는 “이 프로젝트가 무엇을 만들고 무엇을 포함하는가”의 경계입니다. 어떤 작업이 프로젝트에 속하고 어떤 것은 속하지 않는지를 정하는 것이죠.

범위 정의가 중요한 이유는, 이것이 프로젝트의 크기와 일정과 비용을 결정하기 때문입니다. 범위가 넓으면 그만큼 시간과 자원이 더 들고, 좁으면 덜 듭니다. 범위가 흐릿하면 프로젝트가 얼마나 클지 아무도 정확히 알 수 없게 됩니다.

무엇을 ’안 하는지’도 정하라

범위 정의에서 흔히 놓치는 것이 있습니다. “무엇을 할 것인가”만 정하고 “무엇을 하지 않을 것인가”는 명시하지 않는 것이죠.

명확한 범위 정의는 포함 항목뿐 아니라 제외 항목도 분명히 합니다. “이번 프로젝트에서는 A, B, C를 하고, D와 E는 하지 않는다”고 못 박아두면, 나중에 “그거 당연히 포함되는 거 아니었어요?“라는 분쟁을 예방할 수 있습니다. 경계의 안쪽만큼 바깥쪽을 명확히 하는 것이 핵심입니다.

스코프 크립은 왜 생기나

스코프 크립은 프로젝트가 진행되면서 범위가 통제 없이 조금씩 늘어나는 현상입니다. 대개 악의 없이 시작됩니다. “이왕 하는 김에 이것도”, “이 정도는 금방 되잖아요” 같은 요청들이죠.

문제는 이런 작은 추가들이 개별적으로는 사소해 보여도, 쌓이면 프로젝트를 짓누른다는 것입니다. 명확한 기준 없이 요청을 받아들이다 보면, 어느새 프로젝트는 처음 계획의 두 배로 부풀고 일정과 예산은 걷잡을 수 없이 초과됩니다. 게다가 이런 추가는 대개 일정이나 예산의 조정 없이 이루어져, 팀에게 고스란히 부담으로 돌아갑니다.

스코프 크립을 막는 법

스코프 크립을 막는 핵심은 “명확한 기준”과 “통제된 변경”입니다.

첫째, 범위를 처음에 명확히 문서화합니다. 무엇을 포함하고 제외하는지를 이해관계자와 합의해 기록해두면, 이후 요청이 들어왔을 때 “이것이 원래 범위 안인가 밖인가”를 판단할 기준이 생깁니다.

둘째, 범위 밖 요청은 공식 변경 절차를 거치게 합니다. 새 요청을 무조건 거절하라는 뜻이 아닙니다. 다만 그것이 일정과 비용에 미치는 영향을 함께 검토하고, 이해관계자의 승인을 받아 반영하라는 것입니다. “추가하려면 그에 맞게 일정이나 자원도 조정해야 한다”는 원칙을 세우면, 무분별한 추가가 통제됩니다. 이 변경 관리 프로세스는 별도 글에서 자세히 다루겠습니다.

셋째, 거절이 아니라 협상으로 접근합니다. 좋은 PM은 요청을 무작정 막기보다, “이걸 넣으면 대신 무엇을 빼거나 일정을 얼마나 늘려야 하는지”를 제시해 이해관계자가 스스로 판단하게 합니다.

범위 관리는 신뢰의 문제

범위를 지키는 것은 단순히 일을 덜 하려는 것이 아닙니다. 오히려 약속한 것을 제대로 완성하기 위한 것입니다. 무분별하게 범위를 늘리면 결국 아무것도 제대로 끝내지 못하고, 이는 프로젝트 전체의 신뢰를 무너뜨립니다.

명확한 범위는 이해관계자에게 “우리가 무엇을 언제까지 확실히 해내겠다”는 약속이며, 그 약속을 지키는 것이 진짜 프로 정신입니다.

마무리

프로젝트 범위 정의는 무엇을 하고 하지 않을지의 경계를 명확히 그어, 프로젝트의 크기와 방향을 확정하는 활동입니다. 포함과 제외를 함께 문서화하고, 범위 밖 요청은 공식 변경 절차로 다루며, 거절이 아닌 협상으로 접근하면, 프로젝트를 무너뜨리는 스코프 크립을 막을 수 있습니다.

범위를 확정했다면, 이제 그 범위를 관리 가능한 작업 단위로 쪼갤 차례입니다. 다음 글에서는 WBS로 작업을 분해하는 법을 다루겠습니다.