외주개발 스코프 변경 관리 가이드: ‘기능 하나만 더’가 비용·일정 폭탄이 되지 않게 하는 방법
결론부터 말하면, 외주개발 중 요구사항이 바뀌는 것 자체는 문제가 아닙니다. 문제는 변경 요청을 ‘대화’로만 처리하고, 비용·일정·검수 기준을 다시 합의하지 않은 채 개발에 들어가는 순간부터 시작됩니다. 예약 조건 하나, 관리자 권한 하나, CRM 연동 하나, AI 추천 로직 하나가 겉으로는 작은 기능처럼 보여도 실제로는 데이터베이스, API, 화면, 권한, 테스트, 배포, 운영문서까지 건드릴 수 있습니다.
따라서 외주개발 스코프 변경 관리는 요청을 거절하기 위한 절차가 아닙니다. 고객사와 개발사가 같은 장부를 보면서 ‘무엇을 추가할지’, ‘무엇을 빼거나 미룰지’, ‘어떤 비용과 일정 변화가 생길지’를 결정하는 운영 체계입니다. 이 글은 창업자, 정부지원사업 수행팀, PM, 마케터, 비개발 임원이 외주개발 진행 중 스코프 크리프를 줄이기 위해 계약서와 실무 프로세스에 넣어야 할 기준을 정리한 가이드입니다.
1. ‘기능 하나만 더’가 위험한 이유
외주개발에서 요구사항 변경은 자연스럽습니다. 첫 견적 시점에는 실제 운영자가 어떤 관리자 화면을 매일 보게 될지, 고객이 결제 직전에 어떤 조건을 비교할지, 내부 직원이 어떤 엑셀을 내려받아야 하는지 완전히 알기 어렵습니다. MVP나 SaaS 프로토타입은 더 그렇습니다. 출시 전 사용자 인터뷰, 지원사업 중간점검, 투자자 미팅, 영업 제안 과정에서 기능 아이디어가 계속 늘어납니다.
하지만 개발 프로젝트에는 기준선이 있습니다. 기준선은 처음에 합의한 기능목록, 화면 설계, 견적서, 일정표, 검수 조건의 묶음입니다. 이 기준선이 있어야 현재 요청이 기존 범위 안의 보완인지, 추가 범위인지, 또는 기존 기능과 교체 가능한 우선순위 조정인지 판단할 수 있습니다. 기준선 없이 ‘이 정도는 당연히 되는 것 아닌가요?’와 ‘그건 견적에 없었습니다’가 반복되면, 프로젝트는 기능 논의가 아니라 책임 논쟁으로 이동합니다.
좋은 변경 관리는 ‘변경을 못 하게 하는 것’이 아니라 ‘변경의 대가와 선택지를 보이게 하는 것’입니다. 비용을 숨기지 않고, 일정 영향을 미루지 않고, 검수 기준을 다시 쓰는 과정입니다.
2. 먼저 구분해야 할 것: 버그, 명세 보완, 추가 기능, 정책 변경
스코프 분쟁의 상당수는 ‘변경’이라는 단어를 서로 다르게 쓰기 때문에 발생합니다. 고객사는 ‘원래 의도한 기능을 제대로 쓰려면 당연히 필요한 수정’이라고 생각하고, 개발사는 ‘기존 견적에 없던 신규 작업’이라고 판단할 수 있습니다. 그래서 변경 요청서보다 먼저 필요한 것은 변경 유형 판정표입니다.
| 유형 | 예시 | 판단 기준 | 비용·일정 처리 원칙 |
|---|---|---|---|
| 버그 수정 | 명세에 있는 쿠폰 적용이 특정 조건에서 실패함 | 합의된 수용 기준을 충족하지 못함 | 검수·하자보수 범위에서 처리하는 것이 일반적 |
| 명세 보완 | 필드명, 문구, 버튼 위치, 관리자 목록 정렬 기준 정리 | 기능의 목적과 데이터 구조는 유지됨 | 작업량이 작으면 기존 범위 내 조정, 구조 변경이면 재평가 |
| 추가 기능 | 예약 대기, 포인트, 추천인 코드, 다중 관리자 승인 기능 추가 | 새 화면, 새 데이터, 새 정책, 새 검수 기준이 생김 | 변경 요청서와 추가 견적 또는 우선순위 교체 필요 |
| 비즈니스 정책 변경 | 월 정산에서 건별 정산으로 변경, 권한 체계 변경 | 운영 규칙이 바뀌어 백엔드·관리자·알림이 함께 영향받음 | 영향분석 후 일정·비용·검수 기준 재합의 |
| 외부 의존 변경 | PG사, CRM, ERP, 문자 발송, AI API, 지도 API 변경 | 외부 서비스의 승인, 문서, 정책, 테스트 환경에 의존 | 고객사 준비 지연과 제3자 이슈를 일정 리스크로 분리 |
핵심은 ‘작아 보이는가’가 아니라 ‘영향 범위가 어디까지 가는가’입니다. 예를 들어 사용자 화면에서 체크박스 하나를 추가하는 작업도 관리자 검색 조건, DB 컬럼, 개인정보 처리, 엑셀 다운로드, 통계 집계, 알림 문구까지 이어지면 작은 수정이 아닙니다.
3. 계약서에 넣어야 할 변경 관리 조항
외주개발 계약서에는 개발 범위, 검수, 소스코드, 유지보수만 넣고 끝나는 경우가 많습니다. 그러나 실제 분쟁은 계약 후 개발 중간에 생깁니다. 따라서 계약서나 SOW, 과업범위서에는 변경 요청 절차를 별도 조항으로 두는 것이 좋습니다. 기본 계약 구조를 먼저 점검하려면 외주개발 계약서 필수 조항 체크리스트를 함께 참고해도 좋습니다.
| 조항 | 넣어야 할 내용 | 주의할 점 |
|---|---|---|
| 범위 기준 문서 | 견적서, 기능목록, 화면설계서, 요구사항 명세서, 회의록 중 무엇을 기준선으로 볼지 명시 | 카카오톡·구두 설명이 기준 문서인지 불명확하면 분쟁이 커집니다. |
| 변경 요청 제출 방식 | 이메일, 협업툴, 변경 요청서 양식 등 공식 접수 채널 지정 | 구두 요청은 아이디어로만 보고, 승인된 변경으로 보지 않는 원칙이 필요합니다. |
| 영향분석 항목 | 기능, 화면, DB, API, 권한, 보안, 테스트, 배포, 일정, 비용 영향 | 개발자가 ‘됩니다’라고 답하기 전 분석할 시간을 계약상 인정해야 합니다. |
| 승인권자 | 고객사 승인자와 개발사 승인자를 지정 | 실무자가 좋다고 한 내용이 예산 승인으로 해석되지 않게 해야 합니다. |
| 비용 산정 방식 | 정액 추가 견적, 투입공수, 스프린트 단위, 우선순위 교체 방식 중 선택 | 단가만 정해도 충분하지 않습니다. 분석·QA·배포·문서 수정 포함 여부를 써야 합니다. |
| 일정 조정 방식 | 승인일 기준으로 마일스톤을 재산정하거나 기존 기능과 교체 | 기능은 늘리면서 출시일은 그대로 두면 품질이나 테스트가 희생됩니다. |
| 승인 전 착수 금지 | 비용·일정 영향 승인 전에는 개발 착수하지 않는 원칙 | 선의로 먼저 개발하면 나중에 청구와 검수 기준이 모호해집니다. |
| 고객사 지연 처리 | 자료, 계정, 정책 결정, 외부 API 승인 지연 시 일정 연장 기준 | 개발사 지연과 고객사 의사결정 지연을 같은 지연으로 보면 안 됩니다. |
| 변경 로그 | 요청일, 요청자, 결정, 영향분석, 승인일, 반영 버전 기록 | 프로젝트 후반부에는 기억보다 변경 로그가 더 강한 증거가 됩니다. |
공공 소프트웨어사업에는 과업내용 확정·변경과 계약금액·기간 조정을 심의하는 제도적 장치가 존재합니다. 민간 외주계약에 그대로 적용되는 것은 아니지만, ‘범위가 바뀌면 공식 절차와 조정 기준이 필요하다’는 점에서는 참고할 만합니다. 단, 실제 계약 문구와 법적 효력은 프로젝트 구조에 따라 달라질 수 있으므로 중요한 계약은 법률 전문가의 검토를 받는 것이 안전합니다.
4. 실무 프로세스: 변경 요청은 7단계로 처리한다
변경 요청 관리는 복잡한 문서 행정이 아닙니다. 작은 팀이라도 아래 7단계만 지키면 불필요한 오해를 크게 줄일 수 있습니다.
- 요청 접수: 요청자는 변경 요청서 또는 이슈 티켓으로 배경과 원하는 결과를 남깁니다. 회의 중 나온 아이디어도 회의록에 남긴 뒤 공식 요청으로 전환해야 합니다.
- 유형 분류: 버그, 명세 보완, 추가 기능, 정책 변경, 운영 이슈 중 어디에 해당하는지 분류합니다.
- 영향분석: 개발사는 UI, 백엔드, DB, 관리자, 권한, 외부 API, 보안, QA, 배포, 운영문서 영향을 확인합니다.
- 선택안 제시: 추가 비용·일정으로 반영, 기존 기능과 교체, 2차 버전으로 보류, 수동 운영 실험 중 하나 이상을 제시합니다.
- 승인: 승인권자가 비용, 일정, 검수 기준을 확인하고 승인합니다. ‘좋습니다’라는 채팅 반응만으로는 부족합니다.
- 계획 업데이트: 기능목록, 일정표, 스프린트 백로그, 검수표, 견적서를 업데이트합니다.
- 검수와 기록: 반영된 변경이 어떤 버전에서 배포됐는지, 어떤 수용 기준으로 검수됐는지 남깁니다.
애자일 방식이라고 해서 변경을 아무 때나 밀어 넣어도 된다는 뜻은 아닙니다. 스프린트 목표를 해치지 않는 범위에서 스코프는 협의할 수 있지만, 목표 자체가 바뀌거나 테스트 안정성을 해치면 다음 스프린트나 별도 변경으로 넘겨야 합니다. ‘변경을 환영한다’는 원칙은 ‘비용과 일정 영향이 없는 척한다’는 뜻이 아닙니다.
5. 변경 요청서 템플릿: 원하는 기능보다 결정 정보가 먼저다
변경 요청서는 길 필요가 없습니다. 다만 개발사가 영향분석을 할 수 있을 정도의 정보는 있어야 합니다. 아래 항목을 복사해 프로젝트 협업툴, 노션, 구글문서, 지라, 슬랙 워크플로우 등에 넣어두면 실무에 바로 사용할 수 있습니다.
| 항목 | 작성 예시 | 필요한 이유 |
|---|---|---|
| 요청명 | 관리자 예약 취소 사유 필수 입력 추가 | 변경 로그에서 식별하기 위함 |
| 요청자·승인권자 | 운영팀 김OO 요청, 대표 승인 필요 | 아이디어와 예산 승인을 구분하기 위함 |
| 비즈니스 배경 | CS 문의 시 취소 사유 추적이 필요함 | 기능 필요성을 판단하고 대안을 찾기 위함 |
| 현재 기준 문서 | 기능목록 v1.3, 관리자 예약 상세 화면 | 기존 범위와의 차이를 확인하기 위함 |
| 변경 상세 | 취소 버튼 클릭 시 사유 선택, 기타 입력, 이력 저장 | 개발 범위를 구체화하기 위함 |
| 수용 기준 | 사유 없이 취소 불가, 이력에서 관리자명·시간 확인 가능 | 검수 기준을 명확히 하기 위함 |
| 영향 화면·데이터 | 예약 상세, 취소 모달, 취소 이력, 엑셀 다운로드 | 누락된 영향 범위를 줄이기 위함 |
| 희망 반영 시점 | 베타 오픈 전 또는 2차 배포 가능 | 일정 협상 범위를 정하기 위함 |
| 교체 가능 범위 | 통계 대시보드 일부는 2차로 미뤄도 됨 | 예산을 늘리지 않고 우선순위를 조정하기 위함 |
| 결정 | 추가 견적 승인, 2차 보류, 기존 기능과 교체 중 선택 | 실행 가능한 결론을 남기기 위함 |
처음부터 요구사항을 잘 정리하고 싶다면 요구사항 명세서 템플릿과 실전 예시를 먼저 작성해보는 것이 좋습니다. 변경 요청 관리는 초기 명세가 완벽해야 가능하다는 뜻이 아닙니다. 오히려 초기 명세가 있어야 변경의 차이를 설명할 수 있습니다.
6. MVP에서는 ‘추가’보다 ‘교체’가 더 중요하다
MVP 외주개발에서 가장 흔한 실수는 새로 떠오른 기능을 모두 1차 출시 범위에 넣는 것입니다. 정부지원사업 최종보고, 투자자 데모, 파일럿 고객 미팅이 다가오면 ‘이 기능도 있어야 설득력이 있지 않을까’라는 불안이 커집니다. 그러나 MVP의 목적은 완성형 제품을 만드는 것이 아니라 핵심 가설을 검증하는 것입니다.
| 선택지 | 언제 적합한가 | 주의할 점 |
|---|---|---|
| 추가 비용·일정으로 반영 | 매출, 검증 지표, 계약 조건에 직접 연결될 때 | QA와 배포 일정까지 함께 늘려야 합니다. |
| 기존 기능과 교체 | 예산과 마감일은 고정되어 있지만 새 기능의 우선순위가 더 높을 때 | 빠지는 기능을 명확히 기록해야 합니다. |
| 2차 버전으로 보류 | 출시 후 사용자 반응을 보고 판단해도 될 때 | 보류 이유와 재검토 조건을 남겨야 합니다. |
| 수동 운영으로 실험 | 자동화 전 수요 확인이 필요할 때 | 운영자가 감당할 수 있는 수작업 범위를 정해야 합니다. |
예를 들어 매칭 플랫폼 MVP에서 AI 추천 기능을 넣고 싶다면, 바로 모델 연동과 추천 관리자까지 개발할 필요가 있는지 먼저 물어야 합니다. 초기에는 운영자가 후보를 수동으로 태깅하고, 추천 결과를 관리자 화면에서 확인한 뒤, 실제 전환율이 나오면 자동화하는 방식이 더 합리적일 수 있습니다. 반대로 추천 품질 자체가 사업의 핵심 검증 지표라면 AI 기능을 1차 범위로 올리고 덜 중요한 통계 화면을 2차로 미루는 선택이 맞을 수 있습니다.
7. 관리자·백엔드·AI 기능은 영향분석을 더 보수적으로 한다
랜딩페이지 문구 변경과 SaaS 백엔드 정책 변경은 같은 ‘수정’이 아닙니다. 특히 관리자 시스템, 예약·결제·정산, CRM 연동, AI 자동화 기능은 운영 흐름과 데이터 책임을 함께 바꿉니다. 변경 요청이 들어오면 아래 관점으로 영향 범위를 확인해야 합니다.
| 영향 영역 | 확인 질문 | 누락 시 발생하는 문제 |
|---|---|---|
| 데이터 모델 | 새 필드, 상태값, 이력 테이블, 마이그레이션이 필요한가? | 기존 데이터 오류, 통계 불일치, 배포 지연 |
| 권한 | 일반 관리자, 슈퍼관리자, 파트너, 고객사 계정별 권한이 달라지는가? | 개인정보 노출, 운영자 실수, 승인 흐름 누락 |
| 결제·정산 | 환불, 부분취소, 쿠폰, 세금계산서, 정산 주기가 바뀌는가? | 금전 분쟁, 회계 처리 오류, CS 증가 |
| 알림 | 문자, 이메일, 카카오 알림, 푸시 발송 조건이 바뀌는가? | 중복 발송, 누락 발송, 사용자 혼란 |
| 외부 연동 | API 키, 테스트 계정, 승인 절차, 호출 제한, 장애 대응 방식이 준비됐는가? | 개발 완료 후 실제 연동 불가, 일정 공백 |
| AI 기능 | 입력 데이터, 프롬프트, 평가 기준, 실패 시 대체 흐름, 비용 모니터링이 있는가? | 품질 불안정, 운영비 예측 실패, 개인정보 리스크 |
| 검수 | 정상 케이스뿐 아니라 예외 케이스와 권한별 테스트가 정의됐는가? | 출시 직전 버그 발견, 책임 소재 불명확 |
AgentMit이 BizMit 기반 SaaS, 업무 자동화, 관리자 대시보드, AI 기능 개발 범위를 검토할 때도 먼저 보는 것은 ‘이 기능을 만들 수 있는가’가 아니라 ‘운영 흐름과 데이터 책임이 어디까지 바뀌는가’입니다. 이 관점이 있어야 추가 견적도 납득 가능한 숫자가 됩니다.
8. 일정 동결 시점을 정해야 개발팀이 흔들리지 않는다
변경 요청을 잘 받는 팀일수록 동결 시점도 명확해야 합니다. 동결은 고객의 아이디어를 막는 장치가 아니라 현재 배포 단위를 안전하게 끝내기 위한 장치입니다. 예를 들어 2주 스프린트라면 스프린트 계획 회의 이후에는 신규 기능을 바로 넣지 않고 백로그에 등록한 뒤 다음 계획 회의에서 우선순위를 정합니다. 단, 배포를 막는 치명적 결함이나 법적·보안 리스크는 예외로 다룰 수 있습니다.
마감이 있는 프로젝트라면 더 구체적으로 정해야 합니다. 예를 들어 데모데이, 지원사업 최종보고, 마케팅 캠페인 오픈이 있다면 D-14에는 기능 동결, D-7에는 콘텐츠와 운영 정책 동결, D-3에는 치명 버그 수정만 허용하는 식의 기준을 둘 수 있습니다. 이 날짜는 정답이 아니라 협상 기준입니다. 중요한 것은 ‘언제부터 무엇을 바꾸지 않을지’를 양쪽이 알고 있어야 한다는 점입니다.
9. 비용 재산정에서 빠지기 쉬운 항목
추가 견적을 볼 때 많은 고객사가 ‘개발자가 코딩하는 시간’만 생각합니다. 하지만 변경 작업에는 기획 재정의, UI 수정, 백엔드 구현, DB 변경, 기존 데이터 보정, 테스트 케이스 추가, 배포, 운영문서 수정, 고객사 검수 대응이 포함될 수 있습니다. 특히 이미 구현된 기능을 되돌리거나 구조를 바꾸는 작업은 처음부터 개발하는 것보다 더 조심스러울 수 있습니다.
견적을 받을 때는 ‘며칠 걸립니다’보다 다음 질문을 하는 것이 좋습니다. 이 변경은 어떤 화면과 API를 건드리는가? 기존 데이터는 유지되는가? 테스트 범위는 어디까지인가? 배포는 기존 일정 안에서 가능한가? 기존 기능 중 무엇을 빼면 비용 증가 없이 처리 가능한가? 초기 견적의 구조를 이해하고 싶다면 외주개발 비용 산정 방법을 먼저 보면 변경 견적을 해석하는 데 도움이 됩니다.
10. 고객사가 변경 요청 전에 준비할 체크리스트
좋은 변경 요청은 ‘이 기능 만들어주세요’가 아니라 ‘왜 필요하고, 어디까지 필요하며, 무엇과 교환할 수 있는지’를 설명합니다. 요청 전 아래 항목을 확인하면 개발사와의 논의가 훨씬 빨라집니다.
- 이 변경이 매출, 전환율, 운영시간 절감, 지원사업 KPI, 고객 계약 조건 중 무엇과 연결되는가?
- 기존 기능목록이나 화면설계서에서 어느 부분이 바뀌는가?
- 사용자 화면, 관리자 화면, 알림, 결제, 정산, 엑셀 다운로드 중 영향받는 부분은 무엇인가?
- 반드시 1차 출시 전에 필요한가, 아니면 2차 배포로 미뤄도 되는가?
- 예산을 늘릴 수 있는가, 아니면 기존 기능과 교체해야 하는가?
- 고객사 내부 승인권자는 누구이며, 언제까지 결정할 수 있는가?
- 외부 API, PG, CRM, 데이터 파일, 운영 정책 등 고객사가 제공해야 할 자료는 준비됐는가?
- 검수 시 성공으로 볼 조건과 실패로 볼 조건이 명확한가?
이 체크리스트를 채우지 않은 요청은 개발사가 견적을 내기도 어렵고, 개발 후 검수도 흔들립니다. 반대로 이 정보가 있으면 개발사는 ‘그 기능은 1차에 넣는 대신 통계 대시보드를 2차로 미루면 됩니다’처럼 현실적인 선택지를 제시할 수 있습니다.
11. 분쟁을 줄이는 커뮤니케이션 원칙
스코프 변경 분쟁은 대부분 기술 문제가 아니라 기록과 승인 문제입니다. 아래 원칙만 지켜도 감정적 갈등을 줄일 수 있습니다.
- 구두 합의는 요청으로만 본다. 승인된 변경은 반드시 문서, 이슈, 이메일, 변경 로그에 남깁니다.
- 회의록은 24시간 안에 공유한다. 참석자가 기억하는 내용이 다르면 바로 수정합니다.
- 하나의 진실 저장소를 둔다. 기능목록은 노션, 이슈는 지라, 파일은 드라이브처럼 흩어져도 최종 기준 문서 링크는 한 곳에 모읍니다.
- 승인권자를 줄인다. 마케터, 운영자, 대표, 투자자 의견이 모두 개발 지시가 되면 우선순위가 붕괴합니다.
- 품질을 협상 카드로 쓰지 않는다. 일정이 부족하면 기능을 줄여야지 테스트를 빼면 안 됩니다.
- 변경의 이유를 남긴다. 나중에 기능을 유지할지 제거할지 판단할 때 당시 결정 배경이 중요합니다.
12. 언제 프로젝트를 멈추고 재기획해야 할까
변경 요청이 많다고 항상 나쁜 것은 아닙니다. 시장을 더 잘 이해하게 되면서 제품 방향이 선명해지는 경우도 있습니다. 하지만 아래 상황이라면 단순 추가 견적이 아니라 프로젝트 기준선 재설정, 즉 리베이스라인이 필요합니다.
- 핵심 고객이 바뀌어 주요 사용자 흐름이 달라졌다.
- 무료 서비스에서 유료 SaaS로 전환되어 결제·권한·과금 구조가 새로 필요해졌다.
- 관리자 중심 MVP였는데 고객 셀프서비스 포털이 필요해졌다.
- AI 기능이 보조 기능에서 핵심 기능으로 올라왔다.
- 기존 DB 구조로는 새 정책을 안정적으로 담기 어렵다.
- 출시일은 그대로인데 1차 범위가 30% 이상 늘어난 느낌이 든다.
이때 억지로 기존 계약 안에서 계속 밀고 가면 나중에 더 큰 재작업이 생길 수 있습니다. 차라리 1~2회 워크숍으로 기능목록, 화면흐름, 데이터 구조, 일정, 비용을 다시 정리하는 편이 안전합니다.
13. AgentMit과 논의하면 좋은 상황
AgentMit은 단순히 ‘추가 개발비가 얼마입니다’라고 답하는 방식보다, 변경 요청이 서비스 목표에 필요한지 먼저 검토하는 접근을 선호합니다. 특히 MVP, SaaS, 관리자 시스템, 예약·매칭·결제, CRM 연동, 업무 자동화, AI 기능처럼 범위가 유동적인 프로젝트에서는 기능 추가보다 우선순위 재조정이 더 큰 비용 절감으로 이어질 때가 많습니다.
이미 외주개발을 진행 중인데 요구사항이 계속 늘어나고 있다면, 현재 기능목록과 견적서, 화면설계, 진행률, 남은 마감일을 기준으로 범위 리뷰를 받아보는 것이 좋습니다. AgentMit은 기획, UI, 백엔드, 관리자 대시보드, 자동화, AI 기능, 배포와 유지보수 관점에서 어떤 변경은 1차에 넣고 어떤 변경은 2차로 미뤄야 하는지 함께 정리할 수 있습니다.
외주개발 스코프 변경으로 일정과 비용이 불안정해졌다면 AgentMit 개발 상담을 통해 현재 범위 리뷰, MVP 재견적, 실서비스 개발 전환 가능성을 문의할 수 있습니다.
FAQ
Q1. 외주개발 중 요구사항을 바꾸면 무조건 추가 비용이 발생하나요?
아닙니다. 기존 명세의 오탈자, 명확한 버그, 합의된 기능을 구현하는 과정에서 필요한 세부 조정은 보통 기존 범위 안에서 처리됩니다. 다만 새로운 화면, 데이터 구조, 권한, 결제·알림·외부 연동, 관리자 기능, AI 로직이 추가되면 일정과 비용을 다시 산정하는 것이 안전합니다.
Q2. 계약서에는 변경 요청 절차를 어떻게 써야 하나요?
최소한 기준 문서, 변경 요청서 제출 방식, 영향분석 항목, 승인권자, 비용 산정 방식, 일정 조정 방식, 승인 전 착수 금지, 변경 로그 관리, 고객사 응답 지연 시 일정 처리 기준을 넣는 것이 좋습니다. 법적 문구는 프로젝트 규모와 거래 구조에 따라 전문가 검토가 필요합니다.
Q3. 개발사가 사소한 수정도 모두 추가 견적으로 처리하면 어떻게 해야 하나요?
먼저 해당 수정이 기존 요구사항의 수용 기준 안에 있는지 확인해야 합니다. 수용 기준 안이라면 버그 또는 미완료로 볼 수 있고, 기준 밖이라면 추가 범위일 수 있습니다. 판단 기준이 없다면 감정싸움이 되므로 화면별 수용 기준과 변경 유형 표를 먼저 합의하는 것이 좋습니다.
Q4. 스프린트 중간에 급한 기능을 넣어도 되나요?
가능은 하지만 현재 스프린트 목표, 테스트, 배포 일정에 영향을 주는지 먼저 봐야 합니다. 급한 요청을 넣는다면 같은 크기의 기존 작업을 빼거나, 마감일을 조정하거나, 다음 스프린트로 넘기는 선택지를 함께 결정해야 합니다. ‘그냥 추가’는 거의 항상 리스크를 남깁니다.
Q5. MVP 외주개발에서 아이디어가 계속 늘어날 때 가장 좋은 관리 방법은 무엇인가요?
모든 아이디어를 바로 개발하지 말고 Must, Should, Could, Later로 나눈 뒤 MVP 검증 지표와 연결된 기능만 1차 범위에 남겨야 합니다. 나머지는 2차 로드맵, 수동 운영 실험, 관리자 임시 기능으로 분리하면 예산과 출시일을 지키면서도 학습을 이어갈 수 있습니다.
참고한 기준 및 자료
이 글은 외주개발 실무 의사결정을 돕기 위한 참고 자료이며, 개별 계약에 대한 법률 자문은 아닙니다. 계약 문구와 책임 범위는 프로젝트 구조, 발주 방식, 거래 조건에 따라 전문가 검토가 필요할 수 있습니다.
