Photo by Grove Brands on Pexels
B사의 늪: "이것도 살짝 넣어주세요"가 불러온 프로젝트 붕괴
중견 제조기업 B사의 마케팅팀 김 과장은 최근 사내 고객 관리 시스템 개편 프로젝트를 진행하며 극심한 스트레스에 시달렸습니다. 최초 기획 단계에서 합의된 과업 범위는 기존 고객 데이터베이스 정리와 신규 회원가입 절차 2단계 단축이 전부였습니다. 예정된 기간은 8주였고, 개발팀 2명과 디자이너 1명이 투입된 소규모 프로젝트였습니다.
하지만 개발이 3주 차에 접어들자 상황이 꼬이기 시작했습니다. 영업팀 이 부장이 사내 메신저로 쓱 메시지를 보냈습니다. "김 과장, 이번 개편할 때 영업사원별 실적 조회 탭도 하나만 슬쩍 추가해 주면 안 될까? 어려운 거 아니잖아?" 며칠 뒤에는 CS팀에서 요청이 들어왔습니다. "환불 처리 버튼 위치를 바꾸는 김에 카카오톡 알림톡 자동 발송 기능도 같이 붙여주세요. 어차피 시스템 건드리는 김에 하면 금방 하죠?"
김 과장은 타 부서와의 관계를 고려해 "네, 확인해 보겠습니다"라며 요청을 하나씩 받아주었습니다. 문제는 이러한 구두 요청이 기록조차 되지 않은 채 쌓여갔다는 점입니다. 6주 차가 되자 개발팀은 당초 계획에 없던 기능 12개를 구현하느라 야근을 반복했고, 정작 핵심 기능인 회원가입 절차 단축 코드에는 오류가 무더기로 발생했습니다. 최종 오픈 예정일을 사흘 앞두고 시스템은 작동 불능 상태가 되었으며, 영업팀과 CS팀은 "우리가 요청한 핵심 기능이 왜 안 되냐"며 김 과장을 질타했습니다.
이것이 바로 프로젝트 관리에서 가장 흔히 발생하는 '범위 확장(Scope Creep)' 현상입니다. 명확한 기준 없이 추가 요청을 수용하다가 일정, 예산, 품질이 모두 무너지는 전형적인 사례입니다. 현업 담당자가 이러한 범위 확장의 늪에서 벗어나 프로젝트를 지켜내려면 어떤 실무 장치가 필요할까요? B사가 이 문제를 해결해 나간 과정을 통해 구체적인 실천 방안을 살펴보겠습니다.
방어선 1: 착수 단계에서 '수용 기준'과 '제외 범위' 명시하기
프로젝트가 흔들리는 가장 큰 이유는 '완료'에 대한 정의가 서로 다르기 때문입니다. 기획자는 "고객 편의성 개선"이라는 추상적인 목표를 생각하고, 개발자는 "오류 없는 기능 구현"을 생각하며, 현업 부서는 "내가 원하는 모든 기능의 집합"으로 이해합니다. B사는 이 문제를 해결하기 위해 프로젝트 착수 시 작성하는 과업 지시서에 '수용 기준(Acceptance Criteria)'과 '명시적 제외 범위(Out of Scope)' 항목을 mandatory(필수)로 추가했습니다.
수용 기준이란 특정 작업이 완료되었다고 판단하기 위해 반드시 충족해야 하는 객관적인 조건입니다. 단순히 "로그인 페이지 개선"이라고 적는 대신, 어떤 조건이 갖춰져야 작업이 끝나는지 구체적으로 명시해야 합니다.
| 구분 | 불명확한 기존 목표 작성 방식 | 실무 적용 가능한 수용 기준(Acceptance Criteria) |
|---|---|---|
| 회원가입 절차 단축 | 회원가입 단계를 줄여서 사용자 편의성을 높인다. | 1. 입력 항목을 기존 12개에서 5개로 축소한다. 2. 본인 인증 완료 후 가입 완료까지 소요 시간을 30초 이내로 단축한다. 3. 가입 완료 시 DB에 회원 정보가 즉시 정상 저장되어야 한다. |
| 주문 내역 조회 기능 | 영업팀이 쉽게 볼 수 있도록 조회 기능을 만든다. | 1. 최근 6개월간의 주문 내역만 기본으로 조회된다. 2. 엑셀 다운로드 기능은 대상에서 제외한다(다음 분기 과제로 이관). 3. 조회 결과 출력 시간은 3초 이내여야 한다. |
특히 중요한 것은 '명시적 제외 범위'를 문서 하단에 굵은 글씨로 작성하는 것입니다. B사 김 과장은 이 서식을 도입한 후 "이번 프로젝트에서는 카카오톡 알림톡 연동, 엑셀 데이터 대량 추출, 모바일 전용 페이지 개발의 3가지 항목은 제외 범위에 해당하며, 해당 기능은 차기 프로젝트에서 별도 예산을 편성하여 진행한다"는 문구를 명확히 남겼습니다. 이 문서에 관계 부서 팀장들의 서명을 받아두는 것만으로도 무분별한 요청의 70% 이상을 사전에 차단할 수 있었습니다.
방어선 2: 구두 요청을 차단하는 '변경 제안서(CR) 3단계 필터'
착수 단계에서 범위를 아무리 잘 정의해도, 프로젝트 진행 중에 사업 환경이 바뀌거나 필수적인 요건이 누락되었음이 발견될 수 있습니다. 모든 변경 요청을 무조건 거절하는 것은 바람직한 프로젝트 관리가 아닙니다. 핵심은 '비공식적인 구두 요청'을 '공식적인 검토 프로세스'로 전환하는 것입니다.
B사는 사내 메신저나 구두로 전달되는 모든 수정 요청을 금지하고, 아래의 3단계 필터를 거치는 '변경 제안서(Change Request)' 양식을 통하게 했습니다.
1단계: 변경 요청 양식 작성 (요청 부서)
요청자는 구두로 말하는 대신, 구체적으로 무엇을 변경하고 싶은지 서면으로 작성해야 합니다. 단순히 "이 기능 추가해 주세요"가 아니라, 이 기능이 왜 필요한지 사업적 타당성을 직접 적게 만드는 것입니다.
2단계: 영향도 평가 (프로젝트 담당자 및 개발/실무진)
담당자는 해당 요청을 수용할 경우 추가되는 일정, 비용, 리소스 위험도를 산출합니다. "이 기능을 추가하면 일정이 4일 지연되고, 기존 결제 모듈의 재테스트가 필요하여 개발자 1명의 추가 공수가 들어갑니다"와 같이 수치화된 데이터로 평가합니다.
3단계: 트레이드오프(Trade-off) 결정 (의사결정권자)
일정과 예산이 고정되어 있다면, 새로운 기능을 넣기 위해 기존 기능 중 무엇을 뺄 것인지(Trade-off)를 결정합니다. "A 기능을 새로 추가하려면, 기존에 계획했던 B 기능 구현을 다음 회차로 미루거나 오픈 일을 5일 연기해야 합니다"라는 선택지를 제시하는 것입니다.
B사에서 실제로 사용한 변경 제안서 양식은 다음과 같습니다.
| 항목 | 작성 내용 (예시) |
|---|---|
| 요청 제목 | CS팀 요청: 고객 환불 처리 시 자동 알림톡 발송 기능 추가 |
| 요청 사유 | 환불 진행 상황 문의 전화가 일일 평균 50건 이상 발생하여 CS 병목 심화 |
| 영향도 평가 결과 | - 소요 공수: 개발 3일, QA 1일 (총 4일 작업) - 일정 영향: 전체 오픈일 3일 지연 발생 - 추가 비용: 알림톡 연동 API 모듈 구매비 약 50만 원 |
| 조정안 (Trade-off) | [안 1] 오픈 일정을 3일 연기하고 알림톡 기능 포함 [안 2] 예정대로 오픈하되, CS팀의 '1:1 문의 게시판 개편' 과업을 취소하고 알림톡 개발로 대체 |
| 최종 승인 여부 | 안 2로 승인 (승인자: 사업본부장 / 승인일: 2026-03-15) |
이러한 변경 프로세스를 구축하자, 단순히 "해두면 좋을 것 같아서" 던져보던 무책임한 요청들이 급격히 줄어들었습니다. 양식을 작성하고 영향도를 검토받는 과정 자체에서 진짜 필요한 요청만 걸러지는 선순환이 생긴 것입니다.
방어선 3: '지연 일수'를 시각화하여 거절하는 실무 대화 공식
프로젝트 담당자를 가장 힘들게 하는 것은 상사나 타 부서 임원의 직접적인 압박입니다. "김 과장, 이거 한 줄 고치는 건데 그냥 오늘 야근해서 해주면 안 돼?"라는 요청을 받았을 때, 무작정 "안 됩니다"라고 거절하면 감정적인 대립이 발생합니다. 현업 담당자는 감정이 아닌 '데이터와 시각화된 여파'를 바탕으로 대화해야 합니다.
B사 김 과장은 상급자의 감성적 압박에 대응하기 위해 '단위 작업 공수표'와 '일정 지연 예측 시트'를 적극적으로 활용했습니다. 어떠한 추가 요청이 들어오면 다음의 3단계 대화 공식을 적용했습니다.
1단계: 요청의 가치 인정하기 (공감)
"부장님, 말씀해주신 영업 실적 자동 집계 기능은 확실히 영업사원들의 이동 시간을 줄여줄 수 있는 좋은 아이디어 같습니다."
2단계: 수치화된 영향도 제시하기 (팩트 전달)
"다만, 이 기능을 구현하려면 DB 구조를 재설계해야 해서 최소 16시간의 개발 작업과 8시간의 테스트 작업이 필요합니다. 현재 저희 팀의 일별 가용 공수는 100% 차 있는 상태입니다."
3단계: 선택권 넘기기 (트레이드오프 제안)
"현재 계획대로 진행하면 10일에 정상 오픈할 수 있지만, 이 기능을 지금 포함하면 오픈일이 14일로 4일 지연됩니다. 4일 지연을 감수하고 이 기능을 넣을지, 아니면 예정대로 10일에 오픈한 뒤 2차 고도화 때 반영할지 결정해 주시면 감사하겠습니다."
이 대화 방식의 핵심은 담당자가 '안 해주는 게으른 사람'이 되는 것이 아니라, '프로젝트의 리스크를 정확히 알려주고 올바른 선택을 돕는 전문가'의 위치에 서는 것입니다. 상급자 역시 "오픈일이 4일 밀린다"는 구체적인 수치를 확인하면 함부로 추가 작업을 강요하지 못하게 됩니다.
실무에 바로 적용하는 범위 관리 체크리스트
프로젝트 진행 시 매 단계마다 범위 확장의 위험 요소가 없는지 점검할 수 있는 체크리스트입니다. 현업 담당자는 각 단계별로 항목을 확인하고 서류로 남겨두어야 합니다.
기획 및 착수 단계
- 프로젝트 목표가 정량적 수치로 측정 가능한 형태인가?
- '수용 기준(Acceptance Criteria)'이 각 과업별로 명확히 작성되었는가?
- 이번 프로젝트에서 수행하지 않을 '명시적 제외 범위(Out of Scope)'가 문서화되었는가?
- 이해관계자(타 부서장, 임원)가 기획서 내용과 제외 범위에 합의하고 서명했는가?
진행 및 개발 단계
- 메신저, 전화, 구두로 전달된 작업 요청을 즉시 작업 목록에 반영하지 않고 차단하고 있는가?
- 모든 범위 변경 요청에 대해 '변경 제안서(CR)' 양식이 작성되었는가?
- 변경 요청 수용 시 추가되는 일수와 비용이 수치로 산출되었는가?
- 새로운 기능 추가 시 취소하거나 뒤로 미룰 기존 기능(Trade-off)을 확정했는가?
검수 및 종료 단계
- 최초에 합의한 '수용 기준'에 따라 테스트와 검수가 진행되고 있는가?
- 검수 과정에서 새로 발견된 오류가 아닌 '신규 개선 요청'은 차기 과제로 분류했는가?
- 프로젝트 완료 보고서에 당초 범위 대비 추가/변경된 내역이 기록되었는가?
현업 담당자가 오늘부터 바로 실행할 4가지 수칙
프로젝트 관리는 거창한 방법론이나 복잡한 소프트웨어를 도입한다고 해서 해결되지 않습니다. 매일 쏟아지는 타 부서의 요청과 변경사항 속에서 현업 담당자가 자신의 프로젝트를 지키려면 소소한 일상 업무 수칙부터 바꾸어야 합니다. 다음 4가지 핵심 실행 항목을 기억하고 오늘 업무부터 바로 적용해 보시기 바랍니다.
- 구두 요청을 받은 즉시 텍스트로 기록하고 공식 양식을 요구하세요. 메신저나 말로 들어오는 요청에는 "요청 내용의 정확한 검토를 위해 표준 변경 제안서 양식을 작성해 보내주시면 기술 검토를 진행하겠습니다"라고 정중하게 답변하세요. 양식 작성 과정에서 불필요한 요청의 절반이 스스로 철회됩니다.
- 모든 과업에 '안 하는 것(Out of Scope)'을 명확히 쓰세요. 기획서나 과업 지시서를 쓸 때 '포함 사항'보다 더 중요한 것이 '제외 사항'입니다. 이번 프로젝트에서 다루지 않을 범위 3가지를 명시하고 이해관계자의 서명을 받으세요.
- 추가 요청에는 반드시 'Trade-off(맞교환)' 조건을 제시하세요. 무조건적인 거절 대신 "A 기능을 넣으려면 B 기능을 빼거나, 일정을 3일 연기해야 합니다"라는 선택지를 상급자나 요청자에게 넘기세요. 결정의 책임은 요청자가 지게 됩니다.
- 수용 기준을 수치화하여 '완료'의 기준을 객관화하세요. "화면을 깔끔하게 바꾼다"가 아니라 "클릭 단계를 3단계에서 1단계로 줄이고 로딩 속도를 2초 이내로 유지한다"처럼 누가 봐도 성공 여부를 판단할 수 있는 수치 기준을 만드세요.
범위 확장을 막는 것은 이기적인 태도가 아닙니다. 제한된 자원과 시간 속에서 약속된 품질의 성과물을 제때 내기 위한 프로젝트 관리자의 가장 기본적인 책무입니다. 위에서 소개한 방어선과 체크리스트를 활용해 여러분의 프로젝트를 일정 지연과 재작업의 늪으로부터 안전하게 지켜내시길 바랍니다.