앱 외주개발 추가 기능 요청: 비용·일정·승인을 다시 정하는 4단계

앱 외주개발 중 추가 기능 요청을 기존 계약 범위와 분리하고, 비용·일정·승인·검수 기준을 기록하는 방법을 안내합니다.

Sep 15, 2026

앱 외주개발을 시작한 뒤 “이 기능도 넣을 수 있나요?”라는 요청은 자연스럽게 생깁니다. 문제는 요청 자체가 아니라, 새 요청을 원래 계약의 수정인지 별도 작업인지 구분하지 않은 채 채팅으로만 넘기는 데서 시작됩니다. 처음 견적이 그대로인지, 출시일이 바뀌는지, 기존 검수 항목은 무엇인지가 한 문서에 남지 않으면 양쪽이 서로 다른 일을 기대하기 쉽습니다.

먼저 추가 기능을 ‘좋은 아이디어’와 ‘이번 계약에서 바로 해야 할 일’로 나누어 보세요. 그다음 요청 내용, 기존 범위와의 차이, 비용·일정 영향, 승인 결과를 한 흐름으로 남기면 현재 단계의 검수와 새 기능의 결정을 섞지 않을 수 있습니다.

추가 기능 요청이 들어오면 먼저 확인할 두 가지

첫째, 이미 계약서·제안서·기능 명세·화면 목록에 같은 기능이 포함되어 있는지 확인합니다. 기능 이름이 같아도 사용자 유형, 화면 수, 외부 연동, 관리자 기능, 예외 처리에 따라 실제 작업 범위가 달라질 수 있습니다. “로그인”이 적혀 있다는 이유만으로 소셜 로그인, 본인확인, 회원 전환, 관리자 권한까지 모두 포함된다고 단정하면 안 됩니다.

둘째, 요청이 기존 기능의 오류 보완인지 새로운 요구인지 구분합니다. 약속한 동작이 재현되지 않는 경우와, 약속하지 않았던 흐름을 추가하는 경우는 기록 방식이 다릅니다. 이 구분은 누가 맞는지를 바로 판단하기 위한 것이 아니라, 현재 검수·하자 보완과 새 기능의 비용·일정을 분리하기 위한 출발점입니다. 인수 뒤 오류와 유상 유지보수를 나누는 기준은 앱 외주개발 하자보수와 유지보수 글에서도 이어서 확인할 수 있습니다.

앱 개발 계약의 법적 성질과 적용 조항은 계약 내용과 실제 수행 방식에 따라 달라질 수 있습니다. 다만 국가법령정보센터의 민법은 도급을 일의 완성과 그 결과에 대한 보수 지급의 약정으로 규정합니다. 이 글에서는 모든 외주계약을 도급으로 단정하지 않고, 범위·완료 기준·보수의 연결을 먼저 문서로 확인하자는 실무 원칙만 다룹니다.

변경 요청서는 네 줄로 시작하면 됩니다

별도의 복잡한 양식보다, 요청 하나를 독립된 기록으로 만드는 것이 먼저입니다. 메신저 대화에만 남은 요청은 이후에 누락되거나 원래 요구와 섞이기 쉽습니다. 아래 네 항목을 한 장에 적어 두면 개발사와 발주자가 같은 대상을 보고 판단할 수 있습니다.

1. 요청 내용: 누가 어떤 상황에서 무엇을 하려는지, 화면 또는 기능 단위로 적습니다. “편하게 바꿔 주세요” 대신 바뀌어야 할 사용자 흐름을 씁니다.

2. 기존 범위와의 차이: 현재 명세·화면·검수 항목 중 어디에 없거나 무엇을 수정하는지 연결합니다. 기존 문서의 버전이나 링크를 함께 남깁니다.

3. 영향 확인: 개발사는 구현 방법, 추가 작업, 기존 기능 영향, 테스트 필요 범위, 예상 일정과 비용을 제안합니다. 확정 전 수치를 발주자가 약속된 값으로 읽지 않도록 ‘검토 중’ 상태를 표시합니다.

4. 승인 결과: 반영·보류·제외 중 하나를 결정하고, 승인자와 결정 시점을 기록합니다. 반영한다면 변경된 산출물과 검수 기준도 함께 적습니다.

이 네 줄은 법정 서식이 아니라 분쟁 가능성을 줄이기 위한 운영 제안입니다. 한국인공지능·소프트웨어산업협회는 SW 하도급 분쟁예방 자료에서 계약서, 대금 입금표, 세금계산서·영수증, 신고 내용 관련 입증 자료를 제출 서류로 안내합니다. 모든 거래에 같은 제도가 적용된다는 뜻은 아니지만, 변경의 근거와 합의 기록을 남겨야 한다는 이유는 분명합니다. 협회의 SW 하도급 분쟁예방 안내에서 관련 자료와 적용 요건을 직접 확인하세요.

비용·일정은 ‘추가냐 아니냐’보다 영향으로 판단합니다

추가 기능이 보인다고 해서 곧바로 별도 비용이라고 결론 내릴 수는 없습니다. 반대로 작은 화면 수정이라고 해서 일정 영향이 없다고도 말할 수 없습니다. 기능 요청을 받은 뒤에는 다음 질문을 순서대로 확인하는 편이 좋습니다.

확인 질문	기록할 내용	결정에 쓰는 이유
기존 명세에 있나	문서 위치, 화면명, 버전	원래 범위와의 연결 확인
다른 기능을 바꾸나	데이터, 권한, 연동, 관리자 영향	수정 범위와 테스트 범위 확인
어느 산출물이 바뀌나	기획서, 디자인, 개발, 테스트, 배포	대금·일정 조정의 근거 정리
기존 검수 기준은 유지되나	완료·제외·보완 항목	현재 단계와 변경 작업 분리
누가 최종 승인하나	승인자, 날짜, 기록 위치	나중의 해석 차이 축소

특히 출시 직전에는 ‘이 기능을 넣을지’와 ‘기존 버전이 계약상 완료인지’를 따로 판단해야 합니다. 새 요청 때문에 기존 검수를 무기한 열어두면, 완료 기준과 대금 지급 기준 모두 흐려질 수 있습니다. 대금 단계를 산출물·테스트·인수 기록에 연결하는 방법은 계약금·중도금·잔금 지급 기준 글에서 확인할 수 있습니다.

승인 전에는 작업 시작 여부를 분명히 하세요

가장 흔한 혼선은 ‘검토해 본다’는 대화가 ‘진행 승인’으로 받아들여지는 경우입니다. 개발사가 기술 검토를 시작하는 것과 기능 구현을 시작하는 것은 구분해 기록하는 편이 안전합니다. 견적 또는 일정 제안이 왔을 때도, 발주자의 승인 전에는 확정 변경인지 검토안인지 표시하세요.

승인이 끝났다면 원래 문서를 덮어쓰기보다 변경 이력을 남기는 방법이 좋습니다. 예를 들어 기존 기능 명세에 변경 번호를 붙이고, 요청서·수정 화면·변경된 검수 시나리오를 서로 연결합니다. 원래 범위에서 무엇이 빠졌거나 새로 들어왔는지 보이게 하면, 인수인계 시에도 현재 운영권자가 확인하기 쉽습니다. 소스코드와 계정 권한의 인수 범위는 앱 외주개발 인수인계 체크리스트를 참고할 수 있습니다.

과학기술정보통신부가 마련해 배포한 SW 분야 표준계약서는 정보시스템 개발·구축, 유지관리 등 유형별 계약서를 포함합니다. 이는 모든 민간 프로젝트에 그대로 적용되는 답안이 아니라, 계약 환경 개선을 위해 마련된 참고 틀입니다. 계약의 변경 조항, 승인 방식, 책임과 비용은 실제 계약서와 상황을 기준으로 확인해야 합니다. KOSA의 SW 분야 표준계약서 안내에서 유형과 원문 자료를 확인할 수 있습니다.

앱 외주 변경 요청, 이렇게 마무리하세요

추가 기능 요청은 숨기거나 피해야 할 일이 아닙니다. 다만 기존 범위와의 차이, 영향 검토, 승인, 변경된 검수 기준을 함께 남겨야 다음 단계의 대금·일정·인수 판단이 흔들리지 않습니다. 계약서 문구나 이미 발생한 분쟁의 법적 판단이 필요한 경우에는 개별 계약과 사실관계를 확인할 수 있는 전문가 상담이 필요합니다.

현재 앱 또는 MVP 계획에서 기능 우선순위와 준비 항목을 점검하려면 유인어스의 사업 준비 항목 점검을 활용해 보세요.

자주 묻는 질문

추가 기능 요청은 꼭 계약서를 다시 써야 하나요?

항상 같은 방식이 필요한 것은 아닙니다. 다만 기존 계약에 정한 변경 절차가 있다면 그 절차를 확인하고, 요청 내용·영향·승인 결과·변경된 산출물과 검수 기준은 서로 확인 가능한 형태로 남기는 편이 좋습니다.

개발사가 기능 검토를 했으면 진행 승인한 것 아닌가요?

기술 검토와 구현 승인은 다를 수 있습니다. 견적이나 일정 제안을 검토안으로 표시하고, 누가 어떤 범위와 조건을 승인했는지 기록해야 해석 차이를 줄일 수 있습니다.

작은 화면 수정도 변경 요청으로 남겨야 하나요?

기존 합의 범위 안의 단순 보완인지, 사용자 흐름·데이터·테스트·일정에 영향을 주는 새 요구인지 먼저 보세요. 영향이 있는 요청이라면 작은 수정이라도 기록을 남기는 편이 이후 검수에 도움이 됩니다.

승인한 변경 요청은 기존 검수 기준에 어떻게 반영하나요?

변경된 화면·기능·제외 항목과 테스트 시나리오를 기존 검수 기준에 연결하세요. 기존 버전과 바뀐 버전을 구분해 남기면, 원래 단계의 완료 판단과 새 요청의 완료 판단을 분리할 수 있습니다.

앱·MVP 개발의 범위와 실행 순서를 점검하려면 유인어스 진단으로 준비 항목 확인하기에서 현재 상황을 정리해 보세요.