개발 외주 인수검수 기준을 작성하는 방법

인수검수 기준은 계약 전에 적습니다

검수는 화면의 완성도를 감상하는 절차가 아니라 합의한 조건을 충족했는지 확인하는 절차입니다. 기능별 입력과 예상 결과, 사용 권한과 오류 처리를 적으면 개발사와 발주사가 같은 기준으로 작업할 수 있습니다.

시험 방법과 보완 절차를 함께 정하세요

검수 환경과 시험 데이터, 담당자와 확인 기간을 합의합니다. 외부 서비스 장애 등 시험 조건의 영향을 구분하고, 미통과 항목은 재현 방법과 보완 기한을 기록하세요. 승인된 변경 요청도 최종 검수 범위에 반영하고 소스코드·문서·계정 인수는 기능 검수와 별도 항목으로 확인합니다.

계약과 검수에서 확인할 항목

• 기능별 합격 조건: "회원가입이 된다"가 아니라 "정상 입력·중복 이메일·형식 오류 등 정의된 케이스에서 각각 어떤 화면과 메시지가 나오는가"를 케이스 단위로 적습니다.
• 판정 가능한 표현으로 변환: '빠르게', '안정적으로' 같은 형용사는 모두 '지정한 조건에서 정상 응답이 돌아오는가', '동시 접속 상황에서 오류 없이 처리되는가'처럼 누가 봐도 같은 판정이 나오는 문장으로 바꿉니다.
• 테스트 데이터와 환경 명시: 어떤 데이터로, 어떤 브라우저·기기·서버 환경에서 검수하는지 고정합니다. 환경이 다르면 결과도 달라지고, 그 자체가 새 분쟁거리가 됩니다.
• 검수 주체와 절차: 누가, 며칠 안에, 어떤 양식으로 합격/보완 요청을 회신하는지 정합니다. 검수 기간이 무한정 늘어지는 것도, 회신이 없어 자동 합격으로 간주되는 것도 미리 막아야 합니다.
• 변경 요청 양식: 무엇을, 왜 바꾸는지와 함께 그로 인한 비용·일정 변동을 한 장에 정리하는 표준 양식을 만들어 둡니다.
• 일정·비용 재산정 원칙: 변경된 작업의 의존 관계와 검수 범위를 확인합니다. 변경이 일정에 미치는 영향을 그때그때 반영하지 않으면, 막판에 모든 지연 책임이 한쪽에 몰리게 됩니다.
• 변경 이력 관리: 승인된 변경요청서를 모아두면 그 자체가 최신 사양서가 됩니다. 최종 검수는 '원래 계약서'가 아니라 '계약서 + 누적된 변경요청서'를 기준으로 한다는 점을 명확히 합니다.

프로젝트를 준비하고 있다면 위 항목을 요구사항과 검수 목록으로 정리해 개발 범위를 확인하세요. 개발 외주 상담에서 상담 범위를 확인할 수 있습니다.