앱 외주개발 검수 기준: 계약 전에 완료를 정의하는 법
앱 외주계약에서 “완성되면 검수한다”는 문장만으로는 무엇을 확인할지 정해지지 않습니다. 화면이 열린다는 것과 계약한 범위가 구현됐다는 것, 실제 운영을 넘겨받을 수 있다는 것은 서로 다른 확인입니다. 계약서에 서명하기 전에 검수의 대상·방법·결과 처리를 한 장으로 합의해 두면, 개발 막바지의 대화를 기능 추가 협상으로 바꾸지 않고 같은 기준으로 확인할 수 있습니다.
공식 안내 확인일: 2026년 9월 14일 · 작성: 유인어스(UINUS)
먼저 답: 검수는 ‘작동 여부’가 아니라 ‘합의한 결과물의 확인’입니다
검수 기준은 개발사가 잘 만들었는지 감으로 평가하는 목록이 아닙니다. 계약 시점에 정한 기능·화면·연동·산출물을 어떤 환경에서, 누가, 어떤 결과로 확인할지를 정리한 합의서에 가깝습니다. 그래서 기능명만 나열하기보다 “누가 어떤 계정으로 어떤 행동을 했을 때 어떤 화면·데이터·알림이 확인돼야 하는가”로 적는 편이 실무에 맞습니다.
소프트웨어진흥법은 소프트웨어사업의 공정한 거래질서를 위해 표준계약서를 마련하고 사용을 권장하도록 규정합니다. 과학기술정보통신부도 정보시스템 개발·구축 사업 표준계약서를 포함한 SW 분야 표준계약서 활용을 안내하고 있습니다. 다만 표준 양식을 쓴다는 사실만으로 여러분의 앱 범위와 검수 절차가 자동으로 채워지는 것은 아닙니다. 프로젝트에 맞는 별첨 기준을 함께 확인해야 합니다.
민법상 도급에서는 완성된 목적물에 하자가 있을 때 보수 청구 등에 관한 규정이 있습니다. 그러나 실제로 무엇이 계약상 목적물인지, 어떤 상태를 하자로 볼지, 어떤 조항이 적용되는지는 계약 문구와 사실관계에 따라 달라집니다. 민법 제667조부터 제670조의 일반 규정을 앱 외주에 그대로 대입해 결론 내리기보다, 분쟁 가능성이 있으면 계약서와 산출물을 바탕으로 전문가에게 별도 검토를 받으세요.
계약 전에 정할 검수 기준은 네 묶음으로 나눌 수 있습니다
첫째는 범위입니다. 화면 목록, 사용자 역할, 핵심 흐름, 연동 대상, 관리자 기능을 적고 각각의 우선순위를 표시합니다. “예약 기능”처럼 넓은 단어만 두지 말고, 예약 생성·변경·취소·알림 중 이번 계약에 포함되는 행동을 나눕니다. 기획서의 기능명과 계약서의 과업 범위가 다르면, 어느 문서가 우선하는지도 정해 두는 것이 좋습니다.
둘째는 확인 시나리오입니다. 기능마다 시작 조건, 입력값, 기대 결과, 확인할 사람을 짧게 씁니다. 예를 들어 회원가입이라면 “신규 이메일로 가입 → 인증 절차 완료 → 사용자 화면에서 로그인 가능 → 관리자 화면에 가입 기록 표시”처럼 끝까지 이어지는 한 흐름으로 씁니다. 단순히 버튼이 보인다는 확인과 데이터가 남는다는 확인을 구분할 수 있습니다.
셋째는 검수 환경입니다. 운영 주소인지, 검수용 주소인지, 어떤 브라우저·기기·OS에서 확인할지, 외부 서비스의 테스트 계정을 누가 준비하는지 적습니다. 푸시 알림·결제·지도·로그인처럼 제3자 서비스가 끼는 기능은 실제 운영 계정 전환 전까지 가능한 범위와 제한도 표시하세요. 이 항목은 특정 기기에서 완벽히 동일하게 보인다는 약속이 아니라, 이번 검수에서 재현할 조건을 맞추기 위한 것입니다.
넷째는 완료와 보완의 처리입니다. 합격·보완 필요·범위 외 요청을 어떻게 구분할지, 보완 요청은 어떤 문서로 남길지, 수정 확인은 누가 언제 하는지를 정합니다. 새 기능 요청이 발견됐을 때 곧바로 하자로 부르지 않고, 기존 합의 범위와 대조할 통로를 만드는 것이 핵심입니다.
검수 묶음 | 계약 전에 적을 질문 | 남길 수 있는 근거 |
|---|---|---|
범위 | 이번 계약에 포함된 사용자 행동과 관리자 기능은 무엇인가? | 화면 목록, 기능 정의, 연동 목록 |
시나리오 | 어떤 조건에서 무엇을 입력하면 어떤 결과가 나와야 하는가? | 테스트 케이스, 캡처 또는 기록 |
환경 | 어떤 주소·계정·기기에서 확인할 것인가? | 검수 URL, 테스트 계정 책임표 |
처리 | 보완, 범위 변경, 최종 인수를 어떻게 구분할 것인가? | 보완 목록, 변경 합의, 인수 확인 |
‘기능 목록’에서 ‘확인 가능한 문장’으로 바꾸는 방법
계약서 또는 별첨 문서에 아래처럼 한 기능당 한 줄을 먼저 만드세요. 이 표는 법정 서식이 아니라, 발주자와 개발사가 같은 장면을 떠올리기 위한 실무 예시입니다.
기능: 고객 문의 등록
조건: 로그인한 사용자가 제목과 내용을 입력
기대 결과: 등록 완료 화면이 보이고, 관리자 목록에 같은 내용이 표시
확인 환경: 계약서에 적은 검수 URL과 테스트 계정
판정: 기대 결과가 재현되면 확인 완료, 재현되지 않으면 현상·시각·화면을 기록
이 형식의 장점은 “예쁘게 만들어 주세요”, “문제없이 동작해야 합니다” 같은 해석 여지가 큰 문장을 줄인다는 데 있습니다. 반대로 속도, 보안, 접근성, 장애 대응처럼 수치·도구·측정 조건이 필요한 항목은 기능 시나리오에 섞지 말고 별도 기준으로 분리하세요. 근거 없이 “빠른 로딩”이라고 쓰기보다 측정 대상 화면, 조건, 책임 범위를 협의해야 합니다.
개발 범위를 처음 잡는 단계라면 MVP 개발이란? 실패 비용을 줄이는 핵심 기능 선정법도 함께 참고할 수 있습니다. 이 글이 최소 기능의 우선순위를 다룬다면, 지금 글은 정한 기능을 어떤 기준으로 인수할지에 초점을 둡니다.
사업계획과 앱/MVP 준비 항목을 현재 단계에 맞춰 정리하고 싶다면 준비 항목을 점검해 보세요.
검수 직전에 멈추지 않으려면, 인수 자료도 범위에 넣으세요
앱이 열리는 것만으로 운영 인수가 끝나지는 않습니다. 관리자 계정의 소유자, 도메인·스토어·외부 서비스 계정의 이전 방식, 소스코드와 디자인 파일의 전달 여부, 배포 방법, 운영자가 알아야 할 제한을 계약 단계에서 목록화하세요. 어떤 자료를 전달하는지는 계약 범위에 따라 다르므로, “소스코드 일체”처럼 포괄적으로 적기보다 저장소 접근권한, 파일 형식, 전달 시점처럼 확인할 수 있는 형태로 합의하는 편이 좋습니다.
특히 외부 로그인·결제·알림·분석 도구는 계정 명의와 권한이 분리돼 있을 수 있습니다. 검수 당일에 처음 확인하지 말고, 누가 계정을 만들고 누가 관리자 권한을 받는지 미리 확인하세요. 인수 목록에 없는 새로운 기능·연동 요청은 기존 하자 판단과 분리해 변경 요청으로 기록하는 것이 양쪽의 의사결정을 선명하게 합니다.
유인어스는 민간 사업 지원 서비스이며 법률 자문기관이나 개발 계약의 당사자가 아닙니다. 개발 완료, 예산, 계약상 권리·의무, 지원사업의 선정·집행 결과는 프로젝트별 계약과 개별 검토에 따라 달라집니다.
계약서에 붙이기 전 10분 점검표
기능명만이 아니라 사용자 행동과 기대 결과가 적혀 있는가?
검수 URL·계정·기기·외부 서비스의 준비 책임이 구분돼 있는가?
합격, 보완, 범위 변경을 판단하는 기록 방식이 있는가?
인수할 계정·파일·접근권한과 전달 시점이 정리돼 있는가?
계약서, 제안서, 기능정의서 사이에서 우선할 문서가 확인되는가?
자주 묻는 질문
검수 기준은 계약서 본문에만 적어야 하나요?
본문에 모두 넣기 어렵다면 기능 정의서나 검수 시나리오를 별첨으로 두고, 계약서에서 그 문서의 명칭·버전·우선순위를 확인하는 방식이 가능합니다. 실제 효력과 적용은 계약 문구에 따라 달라질 수 있으므로 필요하면 전문가에게 검토를 받으세요.
앱이 실행되면 검수는 끝난 것 아닌가요?
실행은 한 가지 확인일 뿐입니다. 약정한 사용자 흐름, 관리자 기능, 연동, 인수 자료가 어떤 범위였는지와 함께 봐야 합니다. 계약 전 합의한 시나리오로 확인해야 판단 기준이 분명해집니다.
검수 중 새로 떠오른 기능은 하자로 요청할 수 있나요?
새 요구가 기존 계약 범위에 포함되는지는 기능 정의와 계약 문서를 대조해야 합니다. 범위에 없던 기능이라면 하자와 별도로 변경 요청으로 기록하고 일정·비용·우선순위를 다시 협의하는 편이 좋습니다.
외부 서비스 계정도 인수 목록에 넣어야 하나요?
로그인·결제·알림·배포·분석처럼 운영에 필요한 서비스라면 계정 소유자, 관리자 권한, 전달 방식, 책임 범위를 미리 정리하는 것이 좋습니다. 실제 이전 가능 여부와 절차는 각 서비스 약관과 계정 상태를 확인하세요.
계약 전 개발 범위와 사업 준비 항목을 함께 정리해야 한다면 우리 회사의 준비 항목을 확인해 보세요.