프로젝트를 서서히 망치는 범위 잠식의 덫

그 실체를 파악하고 단호하게 대처하는 기술

by 김용진

6시간전

I. 보이지 않는 괴물, 범위 잠식(Scope Creep)

'그것은 아주 사소한 "잠깐만요"라는 말로 시작된'

프로젝트를 진행하다 보면 가장 무서운 순간은 갑작스러운 대형 사고가 아니다.

"이거 하나만 더 추가해주면 안 돼요?"

혹은 "살짝만 고치면 될 것 같은데"

라는 아주 작고 달콤한 요청들이 쌓여가는 순간이다.

이처럼 프로젝트의 범위가 공식적인 승인이나 추가 자원 투입 없이 야금야금 늘어나는 현상을 'Scope Creep(Scope Creep - 범위 잠식)'이라고 부른다.

'삶아지는 개구리 증후군과 실무자의 비극'

처음엔 작아서 티도 안 나지만 정신 차려보면 마감일은 내일이고 할 일은 태산인 상태가 된다.

IT 영업직이나 PM이라면 누구나 겪어봤을 기획서에 없던 유령 업무들이 프로젝트를 지배하기 시작하는 것이다.

이는 단순한 업무 증가를 넘어 프로젝트 전체의 방향성을 잃게 만드는 치명적인 독이 된다.

II. '네, 알겠습니다'의 대가 : 문제점과 영향

'침몰하는 배에는 반드시 이유가 있다'

첫 번째 문제는 일정의 도미노 붕괴이다.

작은 기능 하나 추가가 DB(Database - 데이터베이스) 구조를 바꾸고 테스트 케이스를 수백 개 늘리며 결국 전체 마감일을 지연시킨다.

두 번째는 품질의 하향 평준화이다.

정해진 리소스로 더 많은 일을 하려다 보니 정작 중요한 핵심 기능에 구멍이 뚫리기 시작한다.

'신뢰의 역설과 번아웃의 주범'

고객의 요구를 다 들어주면 신뢰가 쌓일 것 같지만 결과적으로 일정이 밀리고 품질이 떨어지면 "왜 이것밖에 못 했냐"는 비난만 돌아온다.

보상 없는 추가 노동은 팀원의 사기를 꺾고 프로젝트 종료 후 다시는 이 팀과 일하기 싫다는 부정적 인식을 남기게 된다.

결국 모두가 패배하는 게임이 되는 것이다.

III. 도대체 왜 자꾸 늘어나는가?

'범인은 불명확한 약속에 있다'

가장 큰 원인은 RDD(Requirements Definition Document - 요구사항 정의서)의 부실함이다.

무엇을 할지는 정했지만 무엇을 안 할지는 정하지 않았을 때 발생한다.

또한 DoD(Definition of Done - 완료의 정의)가 부재하면 어디까지 해야 끝인지 서로 합의가 안 되어 고객은 끝도 없이 수정을 요구하게 된다.

'거절하지 못하는 마음과 소통의 부재'

거절하면 관계가 나빠질까 봐 혹은 영업 기회를 놓칠까 봐 일단 예라고 답하는 과도한 친절함이 문제이다.

현업 부서와 IT 부서 사이의 언어 장벽 때문에 생기는 오해들이 결국 범위 밖 업무로 둔갑하여 실무자에게 내려오는 경우가 허다하다.

IV. 철벽 방어 전략 : 대응 전략과 실천

'예방과 방어를 위한 단계별 조치'

착수 단계에서는 Baseline(Baseline - 기준점)을 확정해야 한다.

RDD와 계약 범위를 문서로 명확히 하고 최종 승인을 완료하는 것이 필수이다.

진행 단계에서는 CR(Change Request - 변경 요청서) 절차를 가동해야 한다.

추가 요청이 오면 안 된다고 잘라 말하기보다 공식적인 절차를 밟자고 제안하며 일정과 비용을 재산정해야 한다.

'마무리를 짓는 법'

사전에 합의된 DoD를 근거로 프로젝트 종료를 선언해야 한다.

추가 사항은 이번 차수가 아닌 차기 고도화 사업으로 분리하여 관리하는 것이 프로젝트의 완성도를 지키는 길이다.

[예시] '단순한 코딩 종료를 넘어선 마감의 기준'

기능 개발 업무는 단순히 코딩을 마쳤다고 해서 종료되는 것이 아니다. 실무에서 적용하는 구체적인 완료 기준은 다음과 같은 엄격한 과정을 포함해야 한다.

먼저 작성된 소스 코드가 사전에 약속된 코딩 표준을 완벽히 준수해야 한다. 이후 동료 개발자를 통한 코드 리뷰(Code Review - 소스 코드 검토) 절차를 거쳐 모든 개선 권고 사항이 실제 코드에 반영되어야 한다.

기술적인 검증 단계에서는 단위 테스트(Unit Test - 단위 기능 테스트)를 수행하여 모든 테스트 케이스를 통과해야 한다. 또한 해당 기능 추가로 인해 변경된 사항을 RDD(Requirements Definition Document - 요구사항 정의서)나 사용자 매뉴얼 등 관련 문서에 업데이트하는 작업도 필수적으로 수행되어야 한다.

마지막으로 실제 운영 환경과 유사한 스테이징 서버에서 기획자나 고객사로부터 최종 승인(Sign-off - 최종 승인)을 받아야만 비로소 '완료'되었다고 공식적으로 선언할 수 있다.

V. 상황별 거절 대응 시나리오

'상황 1. 고객사가 "살짝만 추가해달라"고 요청할 때'

고객이 말한 기능은 서비스의 완성도를 높이는 데 매우 좋은 아이디어이다.

다만 현재 확정된 RDD 범위를 벗어나는 내용이라 공식적인 CR(Change Request - 변경 요청서) 절차를 거쳐야 한다.

이 기능을 지금 추가하면 전체 테스트 일정이 일주일 정도 밀릴 수 있는데 일정을 조정하고 진행할지 아니면 다음 업데이트 때 반영할지 결정해 주면 감사하겠다.

'상황 2. 상사가 "VIP 고객이니까 그냥 해줘"라고 지시할 때'

해당 기능을 추가하는 취지는 충분히 공감한다.

다만 현재 팀원들의 업무 로드가 DoD를 맞추기에도 빠듯한 상황이다.

이 작업을 우선순위로 올린다면 기존에 진행 중인 핵심 기능 개발 일정 중 어떤 것을 뒤로 미뤄야 할지 가이드라인을 주면 바로 조정하도록 하겠다.

'상황 3. "원래 이런 거 다 해주는 거 아니냐"며 압박할 때'

최상의 서비스를 제공하고 싶지만 약속된 범위를 넘어서는 작업은 프로젝트 전체의 안정성을 해칠 수 있다.

현재 계약된 범위와 산출물 목록을 다시 한번 확인해 주길 바란다.

요청한 부분은 별도의 추가 과업으로 구성하여 진행하거나 현재 범위 내의 다른 업무와 교체하는 방식으로 협의하는 것이 합리적이다.

결론

결국 범위 잠식을 관리하는 핵심은 기록과 절차이다.

구두로 오가는 모든 요청을 공식적인 변경 관리 프로세스로 유도하고 사전에 합의된 마감 기준을 명확히 제시할 때 비로소 실무자의 프로젝트는 보호받을 수 있다. 무조건적인 수용은 친절함이 아니라 프로젝트를 파멸로 이끄는 방관임을 명심해야 한다.

#범위잠식 #ScopeCreep #프로젝트관리 #PM #ProjectManager #업무효율 #직장인팁 #기획자 #개발자 #요구사항정의 #완료의정의 #DoD #RDD #ChangeManagement

keyword