앱 외주개발 하자보수와 유지보수: 인수 후 비용·범위를 나누는 법

앱을 인수한 뒤 오류가 발견되면 “무상으로 고쳐야 하나, 유지보수 비용을 다시 협의해야 하나”가 가장 먼저 헷갈립니다. 답은 기능이 처음 합의한 요구사항·검수기준을 충족하지 못한 결함인지, 아니면 인수 뒤의 운영 환경·업무 변화에 맞춰 기능을 바꾸거나 추가하는 일인지를 계약 문서와 증거로 나눠 보는 데 있습니다. 계약서에 이름만 적어 두면 경계가 흐려지므로, 인수 전에 판단 기준·처리 절차·비용 산정 방식을 함께 적어 두는 편이 안전합니다.

이 글은 일반적인 계약 점검을 돕기 위한 정보입니다. 앱 개발 계약이 언제나 민법상 도급에 해당하는지, 어떤 권리가 실제로 발생하는지는 계약 문구와 사실관계에 따라 달라질 수 있습니다. 분쟁이 있거나 법률 판단이 필요한 경우에는 계약 원문을 바탕으로 전문가에게 확인하세요.

먼저 구분할 것: “약속한 대로 동작하지 않음”과 “새로 바꾸고 싶음”

하자보수와 유지보수를 구분할 때는 요청을 접수한 날짜보다 인수 당시 무엇을 완료로 합의했는지가 출발점입니다. 로그인, 결제, 권한, 알림처럼 특정 기능을 납품 목록과 테스트 시나리오에 넣었다면, 그 시나리오를 충족하지 못하는 문제는 하자보수 검토 대상이 될 수 있습니다. 반대로 출시 후 새 요금제, 운영 절차 변경, 외부 API 정책 변경, OS·브라우저 변화에 맞춘 수정, 신규 화면 추가는 범위와 비용을 별도로 정하는 유지보수 또는 변경 요청에 가깝습니다.

한국소프트웨어산업협회의 공공 SW사업 안내 자료는 운영 단계에서 하자보수를 개발 결과의 결함 수정, 유지보수를 기능 변경·추가·보완과 운영 지원을 포함하는 활동으로 설명합니다. 다만 이 자료의 공공 SW사업 기준과 기간을 민간 외주 계약에 자동 적용할 수는 없습니다. 민간 계약에서는 아래의 분류를 계약서와 검수 기록에 직접 적는 방식이 실무적으로 더 중요합니다.

계약서에는 네 칸을 따로 둡니다

1. 기준선: 요구사항과 검수 시나리오

“앱을 완성한다”는 문장만으로는 나중에 비교할 기준이 부족합니다. 화면 목록, 사용자 역할, 데이터 입력·저장·조회 조건, 외부 연동의 정상·오류 흐름을 요구사항 ID로 관리하세요. 각 ID마다 인수 조건, 테스트 데이터, 확인 담당자, 증빙 위치를 남기면 수정 요청이 들어왔을 때 감상이나 기억 대신 기록으로 판단할 수 있습니다.

국가법령정보센터의 민법 용어 설명은 도급을 한쪽이 일을 완성하고 다른 쪽이 그 결과에 보수를 지급하기로 하는 계약으로 설명하며, 하자와 관련해 보수·손해배상·해제에 관한 규정을 함께 소개합니다. 앱 외주 계약의 법률상 성격을 이 글만으로 단정할 수는 없지만, 적어도 “무엇을 완성하기로 했는가”를 계약과 산출물 목록에 구체화해야 한다는 점은 같은 출발점입니다.

2. 분류 규칙: 결함인지 변경인지 누가 판단하는가

요청서에 “버그”라고 적혔다고 자동으로 하자가 되는 것은 아닙니다. 계약서에는 다음 네 가지를 함께 두세요.

1. 재현 가능한 조건과 기대 결과를 적는 접수 양식

2. 수급인과 발주자가 각자 확인할 수 있는 재현·분석 기한

3. 합의 범위를 벗어난 경우 변경 요청으로 전환하는 승인 절차

4. 의견이 다를 때 참고할 요구사항·회의록·테스트 기록의 우선순위

이 구조가 있으면 “수정해 주세요”라는 요청을 거절하거나 수용하는 문제가 아니라, 어떤 근거로 어떤 트랙을 적용할지 정리하는 문제가 됩니다. 개발사가 알고 있던 부적당한 재료나 지시에 대한 고지 문제처럼 법적 판단이 필요한 사안도 있을 수 있으므로, 책임을 단정하는 문구보다 사실 기록을 먼저 확보하는 것이 좋습니다.

3. 처리 방식: 우선순위와 완료 정의

하자보수든 유지보수든 “접수”만으로 끝내면 운영팀은 언제 정상화되는지 알 수 없습니다. 심각도, 임시 우회 가능 여부, 재현 환경, 배포 전 확인 항목, 롤백 기준을 정하세요. 완료는 개발사의 “수정 완료”가 아니라 합의된 테스트 시나리오가 통과했고, 변경된 앱 버전·배포 시점·확인자가 기록된 상태로 정의하는 편이 명확합니다.

공공 SW 계약·관리 지침은 국가기관 등의 SW사업에서 상세 요구사항, 일정·품질·위험·산출물을 관리하도록 규정합니다. 민간 계약의 의무를 정하는 자료는 아니지만, 요구사항과 산출물을 별도로 관리하는 방식은 민간 발주자가 계약서를 보완할 때 참고할 수 있습니다.

4. 비용과 권한: 유지보수 계약에서 빠지기 쉬운 항목

유지보수 계약에는 월 단가만 적지 말고 포함 시간·제외 시간, 추가 기능의 산정 방식, 긴급 장애의 연락 채널, 클라우드·앱스토어·도메인·분석 도구 접근권한을 나눠 적으세요. 특히 인프라 비용과 개발 인력 비용, 외부 서비스 구독료, 제3자 API 변경 대응은 서로 다른 비용 항목일 수 있습니다. 누가 계정을 소유하고 누가 결제·권한을 관리하는지도 인수인계 목록에 연결해야 합니다.

계정과 소스코드까지 인수할 계획이라면 앱 외주개발 인수인계 체크리스트에서 운영 권한 항목을 함께 확인할 수 있습니다. 결과물의 완료 기준은 앱 외주개발 검수 기준도 참고하세요. 두 글은 각각 인수권한과 검수 설계에 초점을 두며, 이 글의 하자·변경 분류와는 역할이 다릅니다.

요청이 들어왔을 때 5단계로 처리합니다

1. 증거를 고정합니다. 화면 녹화, 오류 시각, 계정 권한, 앱 버전, 재현 절차를 남깁니다. 개인정보나 운영 비밀은 필요한 범위만 공유합니다.

2. 기준선을 찾습니다. 요구사항 ID, 견적서 범위, 변경 승인서, 인수 테스트 결과를 같은 요청서에 연결합니다.

3. 하자·변경·운영 지원으로 임시 분류합니다. 아직 결론이 아니라, 누가 어떤 자료를 검토할지 정하는 분류입니다.

4. 처리안과 영향 범위를 확인합니다. 수정 내용, 테스트 방법, 일정, 비용 또는 무상 처리 근거를 서면으로 남깁니다.

5. 배포 뒤 재검증합니다. 동일 환경에서 테스트하고, 반영 버전과 확인 결과를 인수 기록에 추가합니다.

중간에 앱의 기능을 더 넣고 싶어졌다면 하자보수에 섞지 마세요. 변경 요청으로 전환한 뒤 비용·일정·우선순위를 다시 합의해야, 나중에 “원래 포함된 기능”이라는 해석 충돌을 줄일 수 있습니다.

인수 전 체크리스트

계약서와 인수 문서에서 아래 질문에 “문서 위치”까지 답할 수 있는지 확인해 보세요.

1. 각 핵심 기능의 요구사항 ID와 검수 시나리오는 어디에 있나?

2. 결함 판단에 쓰는 재현 조건과 제외 조건은 누가 승인했나?

3. 하자보수 요청과 변경 요청의 전환 기준은 무엇인가?

4. 수정 뒤 완료를 확인할 테스트와 확인 담당자는 누구인가?

5. 유지보수 범위에 포함된 운영 지원·환경 변경·외부 서비스 대응은 어디까지인가?

6. 클라우드·도메인·앱스토어·분석 도구의 소유자와 관리자 권한은 누구에게 있는가?

초기 MVP는 기능 수가 적어도 결제·회원·개인정보·외부 연동처럼 운영 영향이 큰 영역이 있을 수 있습니다. 사업 단계와 서비스 구조에 맞춰 요구사항, 인수, 유지보수, 계정 인수인계를 한 묶음으로 점검하고 싶다면 유인어스 상담 페이지에서 현재 준비 단계에 맞는 점검 항목을 확인해 보세요.

자주 묻는 질문

계약서에 무상 하자보수 기간이 없으면 어떻게 하나요?

기간과 범위가 없다고 해서 개별 상황의 책임이 이 글만으로 사라지거나 정해지는 것은 아닙니다. 계약서, 요구사항, 인수 기록, 요청·회신 내용을 확보하고 구체적 사실관계에 맞게 확인하세요. 앞으로 체결할 계약이라면 기간·대상·제외 조건·처리 절차를 명시하는 편이 좋습니다.

OS 업데이트에 맞춘 수정은 하자보수인가요?

인수 당시 어떤 OS·기기·브라우저 환경을 지원하기로 했는지와 변경 시점을 함께 봐야 합니다. 새 환경 대응이나 기능 보완은 유지보수·변경 요청으로 정하는 경우가 많지만, 실제 분류는 약정과 테스트 기록에 따라 달라질 수 있습니다.

기능을 수정하면 검수도 다시 해야 하나요?

수정한 기능만이 아니라 연결된 결제, 로그인, 권한, 데이터 저장 흐름에 영향이 있는지 확인해야 합니다. 변경 범위에 맞춰 재테스트 대상과 완료 기준을 요청서에 남기세요.

유지보수 계약만으로 계정 인수인계까지 해결되나요?

아닙니다. 유지보수 범위와 운영 계정의 소유·관리 권한은 별도로 적는 편이 명확합니다. 소스코드, 클라우드, 도메인, 앱스토어, 외부 API, 분석 도구의 계정별 소유자와 권한을 인수인계 목록으로 관리하세요.

요청을 하자보수와 유지보수 중 하나로 급히 이름 붙이기보다, 합의한 기준선·현재 재현 결과·변경 영향·완료 검증을 먼저 맞추는 것이 좋습니다. 계약서와 인수 기록을 기준으로 현재 앱의 개발·운영 준비 상태를 함께 점검하려면 유인어스 상담 페이지에서 확인할 수 있습니다.

공식 출처

1. 국가법령정보센터 법령용어사전: 도급 (2026-09-15 확인)

2. 한국소프트웨어산업협회: SW사업 관리감독 제도 안내 자료 p. 91-93 (2026-09-15 확인)

3. 국가법령정보센터: 소프트웨어사업 계약 및 관리감독에 관한 지침 제3조·제18조 (2026-09-15 확인)