1. 산출물은 여덟 개 영역으로 나누어 확인하세요.
현재 운영본과 일치하는 전체 소스, 저장소 접근권한, 운영 기준 브랜치·태그 등
편집 가능한 화면 디자인, 이미지·아이콘·폰트 등 필요한 디자인 자산과 사용조건
DB 구조, 필요한 데이터, 업로드 파일, 마이그레이션과 백업·복구 정보
클라우드, 서버, DNS, SSL, 스토리지 등 실제 서비스 운영환경
결제, 문자, 메일, 지도, 앱스토어, 분석·모니터링 등 외부 서비스
개발환경 구성, 빌드, 테스트·운영 배포와 필요한 설정 방법
시스템 구성, 관리자 업무, 배치, 로그, 장애 대응 등 후속 운영에 필요한 정보
미해결 오류, 임시처리, 알려진 제약, 추가개발 예정사항과 기술적 주의점
2. ‘받았음’보다 ‘무엇을 받았는지’를 구체적으로 기록하세요.
| 영역 | 최종 확인 예시 | 확인 결과 |
|---|---|---|
| 소스·Git | 저장소 URL, 관리자 권한, 운영본 기준 커밋·태그 | □ 완료 □ 확인 필요 |
| 디자인 | 편집 가능한 원본, 이미지·아이콘, 라이선스 확인 | □ 완료 □ 확인 필요 |
| DB·파일 | 스키마, 마이그레이션, 파일 위치, 백업·복구 방법 | □ 완료 □ 확인 필요 |
| 인프라 | 서버, 클라우드, 도메인, DNS, SSL, 관리자 권한 | □ 완료 □ 확인 필요 |
| 외부서비스 | 결제·문자·메일 등의 계약·관리계정·비용 | □ 완료 □ 확인 필요 |
| 배포 | 환경 구성, 빌드, 테스트·운영 배포 절차 | □ 완료 □ 확인 필요 |
| 문서 | 시스템 구성, 운영절차, 로그·장애 확인방법 | □ 완료 □ 확인 필요 |
| 이슈 | 잔여 버그, 임시조치, 미완료·추가 예정사항 | □ 완료 □ 확인 필요 |
3. 산출물은 ‘파일’만 의미하지 않습니다.
서비스를 계속 운영하려면 파일뿐 아니라 접근권한과 운영방법도 필요합니다. 예를 들어 서버 구성 문서를 받았더라도 관리자 계정이 없으면 실제 서버를 관리하기 어렵고, Git 저장소를 받았더라도 배포 절차를 모르면 긴급 수정 후 운영환경에 반영하기 어렵습니다.
4. 최종 인수는 실제로 해보면서 검증하세요.
Git·서버·도메인·외부계정 로그인 확인
전달받은 소스로 개발환경 실행
DB·파일 연결과 주요 업무 확인
테스트 환경에 직접 배포
로그·백업·관리자 업무와 잔여 이슈 확인
가능하다면 프로젝트를 개발하지 않은 사람이 인계자료만 보고 실행·배포해보는 것이 좋습니다. 이 과정에서 누락된 계정, 설정값, 문서가 가장 잘 드러납니다.
5. 최종 완료·잔금 처리 전에 인수 범위를 함께 확인하세요.
인수 산출물은 계약 종료 후 요청하기보다 계약 단계에서부터 정의하는 편이 좋습니다. 최종 검수 시에는 기능 정상 여부와 함께 약정된 산출물의 전달 여부, 계정 이전, 잔여 이슈, 하자보수 또는 유지보수 조건을 확인하면 이후 분쟁을 줄일 수 있습니다.
| 최종 확인 | 질문 |
|---|---|
| 기능 검수 | 합의한 주요 기능과 업무 시나리오가 정상 동작하는가? |
| 산출물 | 계약에서 정한 소스·문서·디자인·데이터가 전달됐는가? |
| 계정 | 서비스 운영주체가 필요한 관리자 권한을 확보했는가? |
| 미해결 항목 | 남아 있는 오류와 추가 작업이 명확하게 구분되어 있는가? |
| 완료 후 대응 | 하자보수·유지보수의 범위와 연락방법이 정리되어 있는가? |
6. 최종 인수 체크리스트
최종 산출물의 기준은 ‘무엇을 받았는가’가 아니라 ‘이것만으로 서비스를 계속 운영할 수 있는가’입니다.
개발 결과물을 보관하는 인수에서, 서비스를 이어갈 수 있는 인수로 기준을 바꾸세요.