1. 문제는 ‘수정’이라는 한 단어에서 시작됩니다.
발주자가 말하는 수정에는 오류 수정, 문구 변경, 정책 변경, 화면 개선, 신규 기능 추가가 모두 섞여 있을 수 있습니다. 반대로 개발업체가 모든 변경 요청을 추가개발로 처리하면 계약 범위 안에서 해결해야 할 오류까지 비용 분쟁으로 이어질 수 있습니다.
2. 변경 요청을 네 가지로 나누면 판단하기 쉬워집니다.
합의된 기능이나 조건대로 동작하지 않는 경우. 예: 저장 버튼을 눌러도 약속된 데이터가 저장되지 않음.
기존 요구의 의미는 유지하면서 세부 표현이나 동작을 명확하게 하는 경우. 범위 영향에 따라 협의가 필요할 수 있습니다.
기존에 합의한 정책·화면·처리방식을 다른 방식으로 바꾸는 경우.
최초 합의 범위에 없던 기능이나 업무 흐름을 새롭게 추가하는 경우.
3. 같은 화면에서도 버그와 추가개발이 함께 나올 수 있습니다.
| 요청 | 판단 방향 | 이유 |
|---|---|---|
| 회원가입 후 로그인되지 않는다 | 오류 가능성 높음 | 회원가입·로그인이 합의된 기능이고 정상 흐름이 동작하지 않는 경우 |
| 회원가입에 추천인 기능을 추가해 달라 | 추가개발 가능성 높음 | 기존 범위에 없던 새로운 데이터와 처리기능 추가 |
| 관리자 목록에서 합의된 검색조건이 작동하지 않는다 | 오류 가능성 높음 | 합의된 검색기능의 구현 결과가 기준과 다름 |
| 관리자 목록에 엑셀 다운로드를 새로 넣어 달라 | 추가개발 가능성 높음 | 기존 요구에 없던 기능 추가 |
| 결제 완료 후 상태값이 잘못 저장된다 | 오류 가능성 높음 | 합의된 업무 규칙과 실제 처리 결과가 다름 |
| 결제 후 적립금 제도를 새로 적용한다 | 추가개발 가능성 높음 | 새로운 사업정책과 처리 로직이 추가됨 |
위 예시는 일반적인 판단 방향입니다. 실제 프로젝트에서는 계약서와 요구사항, 변경 합의 내용에 따라 결론이 달라질 수 있습니다.
4. 가장 어려운 것은 처음부터 명확하지 않았던 요구사항입니다.
예를 들어 요구사항에 “회원관리 기능”이라고만 적혀 있고 상세 화면과 기능이 정의되지 않았다면, 검색·엑셀·권한·탈퇴처리 중 어디까지 포함되는지 서로 다르게 이해할 수 있습니다. 이 경우 단순히 어느 한쪽의 버그 또는 추가개발이라고 단정하기보다 당시 합의 자료와 미팅 기록을 확인하고 범위를 다시 정리해야 합니다.
| 확인 자료 | 무엇을 확인할까? |
|---|---|
| 계약서·견적서 | 개발범위와 제외범위가 어떻게 표현되어 있는가? |
| 요구사항 목록 | 해당 기능과 처리조건이 명시되어 있는가? |
| 화면설계·프로토타입 | 버튼·항목·업무 흐름이 합의되어 있는가? |
| 회의·메신저 기록 | 개발 전에 세부 요구를 합의한 기록이 있는가? |
| 변경 이력 | 개발 도중 원래 요구를 바꾸기로 합의했는가? |
5. 애매한 요청일수록 바로 개발하지 말고 변경관리 절차를 거치세요.
무엇을 어떻게 바꾸려는지 작성
기존 요구사항과 차이를 확인
개발범위·일정·비용 영향 확인
버그·변경·추가개발을 구분해 처리
작은 요청이라고 구두로 계속 반영하다 보면 어느 순간 최초 범위와 현재 범위의 차이를 알기 어려워집니다. 변경사항을 간단하게라도 기록해두면 비용과 일정 분쟁을 크게 줄일 수 있습니다.
“작은 수정인데 왜 돈이 드나요?”도 작업시간만으로 판단하기 어렵습니다.
화면에서 문구 하나를 바꾸는 것처럼 보여도 DB 구조, 업무 로직, 외부 연동, 테스트 범위까지 영향을 줄 수 있습니다. 반대로 작업시간이 크더라도 애초 합의된 기능이 정상적으로 동작하지 않아 필요한 작업이라면 단순히 “시간이 많이 든다”는 이유만으로 추가개발이라고 볼 수는 없습니다.
6. 비용 협의 전에 확인할 체크리스트
버그와 추가개발은 작업량이 아니라 ‘기존 합의 범위가 무엇이었는가’에서 구분을 시작하세요.
기존 합의대로 만들기 위한 수정인지, 기존 합의를 바꾸거나 새로운 기능을 추가하는 것인지를 먼저 확인하면 불필요한 비용 분쟁을 줄일 수 있습니다.