개발 중간에 요구사항 바뀌면 어떻게 처리하나?
소프트웨어 외주 개발 도중 요구사항 변경이 발생했을 때의 영향도 분석, 비용 처리, 일정 조정 방법을 실무 프로세스 중심으로 설명합니다.
- •개발 중 요구사항 변경은 진행률에 따라 영향도가 기하급수적으로 커집니다 (초반 1배 → 중반 3배 → 후반 5배).
- •변경 요청 시 "영향도 분석 → 비용/일정 재산정 → 승인 → 반영" 절차를 반드시 거쳐야 합니다.
- •주간 스프린트 리뷰로 방향을 조기에 확인하면 대규모 변경을 예방할 수 있습니다.
변경 시점에 따른 영향도
요구사항 변경의 비용은 변경 시점에 따라 크게 달라집니다. 늦게 변경할수록 비용이 기하급수적으로 증가합니다.
| 변경 시점 | 영향도 | 추가 비용 | 예시 |
|---|---|---|---|
| 기획/설계 단계 | 낮음 | 거의 없음 | 문서 수정만 필요 |
| 개발 초반 (20%) | 보통 | 1~1.5배 | 일부 코드 수정 |
| 개발 중반 (50%) | 높음 | 2~3배 | 설계 변경 + 코드 재작업 |
| 개발 후반 (80%+) | 매우 높음 | 3~5배 | 전면 재설계 가능 |
| QA/배포 단계 | 극도로 높음 | 5배+ | 전체 재테스트 필요 |
왜 이렇게 비용이 커지나?
이미 완성된 코드를 수정하면 연관된 코드도 함께 수정해야 합니다
DB 구조가 바뀌면 API + 프론트엔드 + 테스트 전부 수정
이미 테스트한 부분을 처음부터 다시 테스트해야 합니다
다른 기능 개발이 중단되므로 전체 일정에 영향
기획 단계에서 1시간이면 바꿀 수 있는 것이, 개발 후반에는 1주일이 걸릴 수 있습니다. "가능하면 빨리, 가능하면 적게" 변경하는 것이 핵심입니다.
변경 요청 처리 프로세스
변경이 불가피한 경우, 아래 프로세스를 따르세요.
STEP 1: 변경 요청서 작성
무엇을 / 왜 / 언제까지 변경하고 싶은지를 문서로 작성합니다.
변경 대상 기능명
현재 상태 (AS-IS)
원하는 상태 (TO-BE)
변경 이유
희망 반영 시점
우선순위 (필수/선택)
STEP 2: 영향도 분석 (개발사, 1~3영업일)
개발사가 해당 변경이 미치는 영향을 분석합니다.
영향받는 화면/기능 목록
추가 소요 공수 (일 단위)
일정 변경 여부
추가 비용
STEP 3: 승인/보류/거절 (발주사)
분석 결과를 보고 진행 여부를 결정합니다. 이 단계를 건너뛰고 "일단 해주세요"라고 하면 나중에 비용 분쟁이 발생합니다.
STEP 4: 반영 및 확인
승인된 변경을 개발하고, 기존 기능에 사이드 이펙트가 없는지 함께 확인합니다.
대규모 변경을 예방하는 방법
1. 주간 스프린트 리뷰
매주 1회 개발 진행 상황을 데모로 확인하세요. 화면을 직접 보면서 피드백하면 방향이 크게 벗어나지 않습니다.
2. 프로토타입 우선 확인
전체 디자인이 완성되기 전에 와이어프레임이나 프로토타입으로 흐름을 먼저 확인하세요. 이 단계에서 수정하면 비용이 거의 들지 않습니다.
3. MVP 사고방식
"일단 핵심만 빠르게 만들고 → 사용해보고 → 피드백 반영"하는 방식이 대규모 변경 리스크를 줄입니다.
4. 변경 예산 확보
초기 예산의 15~20%를 변경 예산으로 별도 확보해두세요. 변경이 없으면 다행이고, 있으면 대응할 여유가 생깁니다.
변경 vs 버그 수정 — 구분 기준
"이건 변경이 아니라 버그 아닌가요?"라는 분쟁이 자주 발생합니다. 명확한 구분 기준을 세워야 합니다.
버그 수정 (무상)
요구사항 명세서에 명시된 기능이 작동하지 않는 경우
특정 환경(브라우저/기기)에서 오류가 발생하는 경우
데이터가 잘못 저장·표시되는 경우
개발사 귀책의 오류
변경 요청 (유상)
요구사항 명세서에 없는 새로운 기능 추가
기존 기능의 동작 방식 변경
디자인/레이아웃 변경
비즈니스 로직 변경
새로운 외부 연동 추가
회색 지대 처리
"요구사항 명세서에 명시되지 않았지만 상식적으로 당연한 기능"은 가장 분쟁이 많은 영역입니다. 이를 방지하려면 기획 단계에서 가능한 한 상세하게 문서화하고, 명시되지 않은 사항은 유상 CR로 처리한다는 조항을 계약서에 넣으세요.