외주 개발 중 요구사항이 바뀌면? 스코프 크리프 대응법

스코프 크리프가 뭔가요?

스코프 크리프(Scope Creep)는 프로젝트 진행 중에 원래 범위에 없던 기능이 하나둘 추가되면서 비용과 일정이 눈덩이처럼 불어나는 현상이에요. 한국어로는 "범위 확장" 정도로 번역할 수 있어요.

"이것만 하나 더 추가해주세요"가 10번 반복되면 어떻게 될까요? 기능 10개가 추가되는 거예요. 기능 하나당 50~200만 원이니까, 500~2,000만 원이 갑자기 늘어나는 거죠. 외주 개발에서 예산 초과의 가장 큰 원인이 바로 이거예요.

왜 이렇게 되는 걸까요?

처음에 기능 범위를 확정하지 않아서. "대충 이런 느낌"으로 시작하면 기준이 없으니까 "이것도 당연히 포함이죠?"가 반복돼요.

만들어진 걸 보면 욕심이 생겨서. 사람 심리예요. 빈 집을 보면 가구를 넣고 싶고, 가구를 넣으면 소품을 놓고 싶고. 개발도 마찬가지예요. 화면이 보이기 시작하면 "여기에 이것도 넣으면 좋겠는데?"가 자연스럽게 나와요.

개발사가 거절을 못 해서. "고객이 원하니까"하고 다 받아주면 결국 일정이 밀리고, 품질이 떨어지고, 아무도 행복하지 않은 결과가 나와요.

스코프 크리프를 막는 5가지 방법

1. 기능 명세서를 확정하고 시작하세요. 어떤 기능이 이번 프로젝트에 포함되고, 어떤 기능이 아닌지를 문서로 정리하세요. "포함 / 미포함" 목록을 만들면 나중에 분쟁이 줄어요.

2. 변경 요청(CR) 프로세스를 만드세요. 추가 기능을 요청하려면 서면(이메일이나 슬랙)으로 요청하고, 개발사가 추가 비용과 일정 영향을 회신하고, 의뢰인이 승인해야 진행. 이 3단계를 거치면 충동적인 추가를 막을 수 있어요.

3. "넣을까 말까"는 "뺀다"가 정답. 확신이 없으면 빼세요. 나중에 추가하는 건 쉽지만, 만든 걸 빼는 건 심리적으로도 어렵고 기술적으로도 낭비예요. MVP의 핵심은 "최소"예요.

4. 2주 단위로 검수하세요. 2주마다 만든 걸 확인하면 방향 수정이 작아져요. 2개월 뒤에 한 번에 보면 "이거 전부 바꿔야 해요"가 될 수 있어요.

5. 예산의 10~15%를 버퍼로 두세요. 아무리 계획을 잘 세워도 예상 못한 변경은 생겨요. 처음부터 예산에 여유를 두면 작은 변경에는 유연하게 대응할 수 있어요.

이미 스코프 크리프가 시작됐다면?

일단 멈추세요. 추가 요청을 전부 모아서 목록으로 만들어요. 그 중에서 "이번에 반드시 필요한 것"과 "다음 버전으로 미룰 수 있는 것"을 나누세요. 대부분은 미룰 수 있어요.

기존 기능과 교체하세요. 꼭 넣어야 하는 새 기능이 있으면, 기존 기능 중 덜 중요한 걸 빼세요. "추가만 하고 빼지 않으면" 프로젝트는 절대 끝나지 않아요.

저희 딱4주는 4주라는 기간 자체가 스코프 크리프를 막는 장치예요. 기간이 고정되어 있으니 자연스럽게 핵심에만 집중하게 돼요. 변경 요청도 체계적으로 관리하니까, "이것도 넣고 저것도 넣다가 일정이 폭발하는" 상황을 미리 방지해요.