앱 외주개발 계약금·중도금·잔금: 지급 기준을 산출물로 정하는 법

앱 외주 견적을 받으면 계약금·중도금·잔금 비율부터 정하려는 경우가 많습니다. 하지만 금액 비율만 합의하면 “중간 결과물이 나왔다”는 말과 “아직 확인할 수 없다”는 말이 충돌하기 쉽습니다. 지급 시점은 달력의 특정 날짜보다 무엇을 제출하고, 누가 어떤 환경에서 확인하며, 확인 결과를 어디에 남길지에 연결하는 편이 분명합니다.

민법은 도급을 한쪽이 일을 완성하고 상대방이 그 결과에 보수를 지급하기로 하는 약정으로 설명하며, 목적물 인도가 필요한 경우 보수는 인도와 동시에 지급하는 것을 원칙으로 둡니다. 다만 앱 개발 계약의 성격과 실제 지급 의무는 계약 문구·개발 범위·사실관계에 따라 달라집니다. 이 글은 개별 분쟁의 결론이나 법률 자문이 아니라, 계약 전에 지급 기준을 운영 가능하게 정리하는 방법입니다.

먼저 답: 지급 단계는 ‘진행률’이 아니라 확인 가능한 상태로 정합니다

계약금·중도금·잔금이라는 이름만으로는 지급 조건이 완성되지 않습니다. “개발 50% 완료”처럼 모호한 표현 대신, 각 단계에 산출물, 확인 방법, 승인 또는 보완 절차, 다음 단계로 넘어가는 기록을 붙이세요. 그래야 발주자는 돈을 지급하기 전 무엇을 확인할지 알 수 있고, 개발사는 어떤 자료를 준비해야 하는지 예측할 수 있습니다.

예를 들어 기획 단계의 지급 기준은 화면 수가 아니라 요구사항 목록·화면 흐름·예외 처리 범위의 버전과 승인 기록일 수 있습니다. 개발 중간 단계는 테스트 가능한 URL 또는 빌드 파일, 핵심 기능의 테스트 시나리오, 알려진 제한사항 목록으로 잡을 수 있습니다. 최종 단계는 인수 테스트 결과, 소스코드·계정·배포 관련 인수 자료, 계약에서 약속한 최종 산출물 목록으로 확인합니다. 어느 기준을 택하든 실제 서비스와 계약 범위에 맞게 구체화해야 합니다.

계약금: 착수 전에 ‘무엇을 만들지’와 ‘어떻게 바꿀지’를 고정합니다

계약금 단계에서 가장 중요한 산출물은 완성된 앱이 아니라 기준선입니다. 기능 이름만 나열하지 말고 사용자 역할, 화면 또는 API 범위, 외부 서비스 연동 여부, 데이터가 입력·저장·조회되는 조건, 지원 환경을 가능한 범위에서 목록화하세요. 아직 결정되지 않은 항목은 확정된 것처럼 적지 말고 `추후 결정`, `별도 변경 요청 필요`처럼 상태를 표시하는 편이 낫습니다.

또한 계약금 지급 전에는 변경 요청의 처리 방법을 정해야 합니다. 초기 대화에서 나온 아이디어가 자동으로 개발 범위에 들어가는지, 어느 문서의 승인으로 범위가 바뀌는지, 변경이 일정·비용에 미치는 영향을 누가 확인하는지를 적어 두세요. 이 기준이 없으면 중도금 시점에 새 기능 요청과 기존 범위 확인이 섞여 지급 조건 자체가 흔들릴 수 있습니다.

민법 제664조는 도급을 ‘일의 완성’과 그 결과에 대한 보수 지급의 약정으로 설명합니다. 이를 앱 외주에 그대로 법률 판정처럼 적용할 수는 없지만, 발주자가 기대하는 결과와 대가의 연결을 계약서·요구사항·산출물 목록으로 구체화해야 한다는 실무적 출발점은 분명합니다.

중도금: 시연 영상보다 재현 가능한 테스트 조건을 받습니다

중도금은 화면을 보여 주는 것으로 끝내기보다, 발주자가 직접 또는 지정한 담당자가 핵심 흐름을 확인할 수 있는 상태에 연결하는 편이 좋습니다. 로그인, 회원가입, 주문·결제, 관리자 등록처럼 이 사업에서 중요한 흐름을 먼저 고르고, 각 흐름마다 시작 조건·입력값·기대 결과·확인 담당자를 정합니다. 실제 결제나 개인정보를 다뤄야 한다면 테스트 계정·테스트 데이터·접근 권한을 따로 마련해야 합니다.

시연은 이해에 도움이 되지만, 영상만으로는 같은 결과가 반복되는지와 예외 흐름이 어떻게 처리되는지 확인하기 어렵습니다. 따라서 중도금 확인서에는 테스트할 주소나 앱 빌드, 버전 또는 커밋 식별 정보, 확인한 날짜, 통과·보완 항목, 다음 확인 예정 항목을 남기세요. 외부 API, 앱스토어 심사, 결제대행사 설정처럼 개발사가 단독으로 완료할 수 없는 전제조건도 별도 목록으로 분리하는 것이 좋습니다.

중도금 단계에서 발견된 차이를 일률적으로 ‘미완성’으로만 보지 않아야 합니다. 처음 합의한 요구사항을 충족하지 못한 문제인지, 발주자의 운영 방식이 바뀌어 새로 추가한 요구인지, 제3자 서비스의 조건 때문에 조정이 필요한지 판단 근거를 남기세요. 하자·변경·운영 지원의 경계가 궁금하다면 앱 외주개발 하자보수와 유지보수의 범위도 함께 확인할 수 있습니다.

잔금: ‘배포했다’가 아니라 약정한 인수 조건을 확인합니다

잔금 조건은 앱이 스토어에 올라갔는지, 서버가 켜졌는지 한 가지 사실만으로 정하기보다 계약서의 인수 조건을 묶어 확인하는 방식이 안전합니다. 핵심 기능의 인수 테스트가 어떻게 끝났는지, 약정한 산출물이 빠지지 않았는지, 아직 남은 보완이 있다면 누가 언제 어떤 방식으로 처리하는지가 한 문서에서 보이게 하세요.

민법 제665조는 목적물의 인도가 필요한 경우 보수는 인도와 동시에 지급한다고 규정합니다. 다만 앱에서 ‘인도’가 소스코드 전달, 계정 권한 이전, 배포 완료, 운영 문서 제공 중 무엇을 뜻하는지는 계약에서 별도로 정해야 할 수 있습니다. 그러므로 잔금 기준에는 해당 계약에서 인수해야 하는 항목을 빠짐없이 열거하고, 제공 방식과 접근 확인 방법까지 적는 편이 좋습니다.

인수 항목에는 소스코드 저장소 접근, 배포 절차 문서, 서버·도메인·앱스토어·분석 도구의 권한, 사용 중인 외부 서비스 목록처럼 운영에 필요한 정보가 포함될 수 있습니다. 다만 계약에 없는 자료를 자동으로 요구할 수 있다는 뜻은 아닙니다. 처음부터 산출물 목록과 계정 권한의 소유·관리 기준을 합의해야 합니다. 자세한 항목은 앱 외주개발 인수인계 체크리스트에서 연결해 점검할 수 있습니다.

지급 기준 문서는 네 묶음으로 관리합니다

첫째, 범위 문서에는 기능·화면·연동·제외 항목과 변경 요청 절차를 둡니다. 둘째, 산출물 목록에는 단계별로 제출할 링크·파일·문서와 버전 표기 방법을 둡니다. 셋째, 확인 기록에는 테스트 시나리오·확인자·결과·보완 요청을 남깁니다. 넷째, 인수 기록에는 최종 권한·자료·알려진 제한사항·이후 유지보수 창구를 정리합니다.

이 네 문서를 같은 버전 체계로 연결하면 지급을 미루기 위한 문서가 아니라, 다음 단계의 일을 선명하게 만드는 운영 도구가 됩니다. 특히 지급 조건이 충족되지 않았다고 판단할 때는 ‘마음에 들지 않는다’ 대신 어느 산출물의 어느 확인 항목이 비어 있는지 적어야 대화가 진행됩니다. 반대로 발주자가 추가로 바라는 기능이 생겼다면 기존 지급 단계의 보완과 구분해 변경 요청으로 관리하세요.

초기 앱·MVP의 개발 범위, 산출물, 인수 조건을 현재 사업 단계에 맞게 점검하려면 유인어스 상담 페이지에서 준비 항목을 확인할 수 있습니다.

계약 전에 확인할 질문

1. 계약금 지급 전에 요구사항·제외 범위·변경 절차의 최신 버전이 정해졌는가?

2. 중도금 단계에서 발주자가 직접 재현할 핵심 흐름과 테스트 환경은 무엇인가?

3. 확인 결과가 통과인지 보완인지 기록하는 담당자와 방식은 정해졌는가?

4. 잔금 전 인수할 코드·문서·계정 권한·배포 자료는 계약의 산출물 목록에 있는가?

5. 남은 보완과 새 기능 요청을 각각 어느 문서에서 관리할 것인가?

지급 비율의 정답은 서비스 규모와 계약 구조에 따라 다르지만, 각 지급 단계의 확인 기준은 모호하면 안 됩니다. 계약서의 금액 표와 요구사항·테스트·인수 기록을 함께 맞추고 싶다면 유인어스 상담 페이지에서 현재 준비 상태를 점검할 수 있습니다.

자주 묻는 질문

중도금은 개발 진행률 몇 퍼센트에 지급해야 하나요?

정해진 비율을 이 글에서 제시할 수는 없습니다. 서비스 범위와 계약 구조에 따라 달라지므로, 퍼센트보다 해당 단계에서 확인할 산출물·테스트 조건·보완 절차를 먼저 합의하세요.

시연 영상을 받았으면 중도금 조건이 충족된 건가요?

영상은 진행 상황을 이해하는 자료가 될 수 있지만, 계약에서 정한 지급 조건을 충족하는지는 별도입니다. 핵심 흐름을 실제로 확인할 환경, 테스트 시나리오와 결과, 미완료·제외 항목을 함께 확인하세요.

잔금을 지급하면 소스코드와 계정 권한도 자동으로 받나요?

자동으로 단정할 수 없습니다. 계약의 산출물 목록과 권리·권한 관련 약정에 무엇이 포함됐는지 확인해야 합니다. 소스코드, 클라우드, 도메인, 앱스토어, 분석 도구는 제공 방식과 관리자 권한을 구체적으로 적어 두는 편이 좋습니다.

중도금 단계에서 새 기능을 요청하면 어떻게 하나요?

처음 합의한 범위를 벗어난 요청이라면 기존 단계의 미완성과 분리해 변경 요청으로 기록하세요. 영향 범위, 일정, 비용, 승인 여부를 확인한 뒤 계약서에 정한 절차에 따라 반영 여부를 결정합니다.

공식 출처

1. 국가법령정보센터: 민법 제664조(도급의 의의) (2026-09-15 확인)

2. 국가법령정보센터: 민법 제665조(보수의 지급시기) (2026-09-15 확인)

3. 국가법령정보센터: 민법 제667조(수급인의 담보책임) (2026-09-15 확인)