외주 프로젝트 요구사항이 자꾸 바뀔 때, 스코프 크립 대응 5단계
외주 프로젝트 진행 중 요구사항이 계속 바뀌는 스코프 크립, 왜 생기고 어떻게 관리할 수 있을지 변경관리 프로세스 5단계로 정리했어요. 비용·일정에 미치는 영향까지 11년+ 운영한 개발사 기준으로 짚어봤어요.
스코프 크립(scope creep, 범위 확장)은 계약서에 없던 요구사항이 프로젝트 도중 하나둘 붙으면서 범위가 슬금슬금 커지는 현상이에요. 한 번쯤은 “이 정도는 당연히 포함 아니었나요”라는 말을 주고받아 본 적 있을 거예요. 막을 수는 없어도 변경이 생겼을 때 어떤 순서로 처리할지 미리 정해두면 일정과 비용 다툼은 대부분 피할 수 있어요.
“이번 주에 요청드린 기능 하나만 더 추가해주시면 안 될까요?” 프로젝트가 절반쯤 지나면 이런 요청이 자연스럽게 늘어나요. 하나씩 보면 사소해 보여도 쌓이면 일정이 밀리고 견적과 실제 작업량이 벌어지는 원인이 돼요. 요구사항 변경이 생겼을 때 대응하는 순서를 직접 운영해본 개발사 기준으로 정리했어요.
1. 스코프 크립, 정확히 무슨 상황을 말하나요
스코프 크립은 계약서나 기획 문서에 없던 기능·화면·연동이 프로젝트 진행 중 조금씩 추가되는 현상이에요. 변경 하나하나는 “이 정도는 별거 아니다”라는 느낌으로 들어와요. 그런데 열 개, 스무 개가 쌓이면 처음 견적을 냈던 범위와는 완전히 다른 프로젝트가 되어 있어요.
2. 왜 프로젝트 중간에 요구사항이 자꾸 늘어날까요
가장 흔한 원인은 착수 시점의 요구사항 정의가 느슨했던 경우예요. “쇼핑몰 만들어주세요” 정도로 뭉뚱그려 시작하면 화면을 하나씩 보면서 “이건 당연히 있어야죠”라는 말이 계속 나올 수밖에 없어요. 계약서에 범위와 산출물을 구체적으로 남기는 것부터가 첫 단추예요. 계약서에 꼭 넣어야 할 조항을 미리 확인해두면 도움이 돼요. 사용자 테스트 중 빠진 기능을 뒤늦게 발견하거나 발주사 내부 의사결정권자가 바뀌며 방향이 수정되는 경우도 흔해요.
3. 변경 요청이 들어오면 가장 먼저 무엇을 해야 하나요
요청을 받는 순간 바로 “가능해요, 진행할게요”라고 답하지 않는 게 원칙이에요. 구두로 승낙하면 이 변경이 원래 계약 범위였는지 추가 작업이었는지 나중에 증명하기 어려워지거든요. 접수 → 영향도 검토 → 문서화 → 착수 순서를 지켜야 해요. 급할수록 이 순서를 건너뛰기 쉬워요. 오히려 그럴 때 메일 한 통으로 짧게 남겨두는 습관이 나중에 서로를 지켜줘요.
4. 변경 요청서(CR)에는 어떤 항목이 들어가야 하나요
변경관리 프로세스의 핵심은 CR(Change Request, 변경 요청서)이에요. 거창한 양식이 아니어도 되지만 아래 항목만큼은 빠지지 않아야 해요.
- 요청 내용: 무엇을 바꾸거나 추가할지 구체적으로
- 사유: 왜 필요한지, 급한 사유가 있는지
- 영향 범위: 기존 화면·기능·일정 중 어디까지 건드리는지
- 예상 공수와 추가 비용: 숫자로
- 승인 여부와 날짜: 누가 언제 승인했는지
이 다섯 가지만 문서로 남겨도 “말한 적 없다”는 다툼은 거의 사라져요.
5. 비용과 일정, 어떤 기준으로 다시 계산해야 할까요
변경 규모가 정해지면 기존 견적 방식과 같은 기준으로 재계산하는 게 원칙이에요. 시간 단위(MM, Man-Month)로 계약했다면 추가된 인원·기간을 그대로 반영하고 고정가라면 변경 범위만큼 별도 견적을 내는 게 맞아요. 견적 방식이 헷갈린다면 MM·시간제·고정가 비교를 참고해보세요.
운영사 Tip. 저희는 변경 요청이 들어오면 “기존 일정 안에서 흡수 가능한지”부터 먼저 봐요. 흡수 가능하면 비용을 따로 청구하지 않고 범위가 확실히 커질 때만 CR로 넘겨요. 모든 요청을 유료로 처리하면 관계가 불편해지고 반대로 다 무상으로 넘기면 프로젝트가 끝없이 늘어나거든요.
6. 실무에서 자주 저지르는 실수는 무엇일까요
- 구두 요청을 그냥 진행함: 나중에 “이건 원래 범위였다”는 주장으로 이어지기 쉬워요.
- 작은 요청이라 CR 없이 진행함: 작은 변경도 쌓이면 총량은 결코 작지 않아요.
- 일정만 미루고 비용은 언급 안 함: 일정 지연은 눈에 보이지만 늘어난 공수는 문서 없이는 설명하기 어려워요.
7. Creative Soft가 요구사항 변경을 다루는 방식
저희는 자체 SaaS 4종을 오래 운영하면서 출시 이후에도 요구사항은 절대 멈추지 않는다는 걸 몸으로 배웠어요. 그래서 착수 단계부터 변경관리 프로세스를 계약서 안에 넣어두는 편이에요. 어떤 경우 CR을 발행하고 어떤 경우 협의 없이 바로 반영할지 기준을 미리 정해두면 프로젝트 중간에 감정 소모할 일이 크게 줄어들어요.
8. 자주 묻는 질문
스코프 크립을 완전히 막을 방법이 있을까요
완전히 막긴 어려워요. 요구사항은 실제로 화면을 써봐야 보이는 부분이 많거든요. 다만 착수 시점에 범위를 구체적으로 정의하고 변경이 생기면 CR로 남기는 습관만 지켜도 다툼으로 번지는 경우는 크게 줄어들어요.
작은 변경도 매번 CR을 써야 하나요
오타 수정이나 문구 변경처럼 영향이 거의 없는 건 CR 없이 처리해도 괜찮아요. 다만 화면 구조나 기능 흐름에 영향을 주는 변경이라면 규모가 작아 보여도 문서로 남겨두는 게 나중에 서로를 지켜줘요.
개발사가 변경 요청을 거절할 수도 있나요
가능해요. 일정이나 예산상 반영하기 어려운 요청이라면 대안을 제시하거나 다음 단계로 미루자고 협의하는 게 정상이에요. 요청을 전부 다 받아주는 개발사보다 영향도를 솔직하게 설명해주는 개발사가 장기적으로는 더 믿을 만해요.
9. 정리하며
요구사항이 바뀌는 것 자체는 문제가 아니에요. 그 변경을 아무도 기록하지 않고 넘어가는 순간부터 문제가 시작돼요. 접수하고 영향도를 확인하고 문서로 남기고 합의한 뒤 진행하는 네 단계만 지켜도 스코프 크립은 충분히 관리할 수 있는 범위 안에 들어와요. 저희는 11년 넘게 50개 이상의 프로젝트를 진행하고 자체 SaaS 4종을 직접 운영해온 개발사예요. 롯데·캐논 같은 곳과 진행한 프로젝트에서도 요구사항이 바뀔 때마다 이 순서로 함께 조율해왔고요.
함께 읽으면 좋은 글이에요.