외주 개발 검수 체크리스트: 기능·계정·운영 인수 기준 [2026]

외주 개발 검수는 마지막 날 화면을 눌러 보는 행사가 아니라 계약 전에 합의한 요구사항을 실행 가능한 시험·증거·수락 상태로 바꾸는 과정입니다. 기능이 보인다는 이유만으로 수락하면 권한·데이터·보안·배포·복구·소스와 계정 인수가 빠진 채 운영 책임만 발주사로 넘어올 수 있습니다.

검수 범위는 사용자 기능만이 아닙니다. 관리자 권한, 데이터 이관과 대사, 외부 연동 실패, 로그와 알림, 개인정보 처리, 백업·복구, 배포 재현, 저장소·클라우드·도메인 계정, 운영 문서까지 실제 서비스를 이어가는 조건을 포함해야 합니다.

잔금·하자·변경 요청의 처리 기준은 계약마다 다릅니다. 이 글은 법률 판단이나 지급 거절 조언이 아니라 요구사항별 수락 증거를 만드는 실무 구조입니다. 계약서·발주서·변경 합의와 충돌하는 경우 해당 문서와 전문가 검토를 우선하세요.

조달 단계부터 보안 요구와 개발 증거를 명시한다#

CISA의 Secure by Demand 가이드는 구매 전 질문, 계약 단계 요구, 도입 뒤 지속 평가를 연결하도록 권고합니다. NIST SSDF는 공급자와 구매자가 안전한 개발 관행을 공통 언어로 논의할 수 있는 기반을 제공합니다. 두 문서는 특정 계약의 수락·지급 조건을 정하는 법률 문서가 아니라 검수 범위에 보안과 공급망 증거를 포함하기 위한 공식 실무 기준입니다.

• CISA Secure by Demand Guide: 구매 전 질문·계약 요구·도입 후 평가의 연결
• NIST SP 800-218 SSDF: 구매자와 공급자가 사용할 안전한 개발의 공통 언어
• CISA Software Supply Chain Customer Guide: 소프트웨어 고객의 공급망 보안 요구와 확인 질문

결함·변경·보류 상태를 분리하고 증거 묶음을 버전 관리한다#

요구사항 ID마다 구현 버전, 시험 환경, 입력 데이터, 기대 결과, 실제 결과, 증거 링크, 담당자, 판정 시각을 묶습니다. 화면 캡처만 남기지 말고 API 응답, 로그, 데이터 전후값과 배포 버전을 함께 보존하세요.

결함은 합의한 기준을 충족하지 못한 상태, 변경은 합의 범위를 새로 바꾸는 요청, 운영 보류는 외부 승인·계정·데이터가 준비되지 않은 상태로 분리합니다. 서로 다른 상태를 한 작업 목록에 섞으면 책임과 일정이 왜곡됩니다.

수락 회의에는 사업 책임자, 실제 사용자, 개발, 보안·인프라, 데이터 담당자를 참여시키고 차단 결함·조건부 수락·잔여 위험의 승인권자를 정합니다. 지급과 하자 처리는 수락 기록을 근거로 계약 절차에 따라 결정합니다.

계약 전 확인 항목은 외주 개발 계약 체크리스트로 연결합니다. 코드와 계정 권리는 소스코드 소유권 가이드에서 구분합니다. 운영 전환 기준은 유지보수 업체 선정과 함께 보세요.

대체 담당자가 회사 계정에서 배포·복구하면 최종 승인한다#

정상 흐름만 보지 말고 권한 거부, 중복 요청, 외부 연동 지연, 데이터 누락, 결제 실패, 대량 처리, 백업 복원, 비밀 키 회전과 롤백을 표본에 포함합니다.

발주사 담당자가 외주사의 개인 장비와 개인 계정 없이 저장소를 받아 새 환경에서 빌드하고, 회사 계정으로 배포·관찰·장애 복구하며, 데이터와 비용·권한을 확인할 때 운영 인수를 완료합니다.