개발사에서 MVP를 넘겨받을 때 무엇을 직접 확인하나요?

인수는 산출물 목록 확인과 어떻게 다른가요?

인수는 파일과 계정을 받는 일이 아니라, 넘겨받은 환경에서 직접 돌려 보고 그 결과를 문서로 남기는 일입니다. 산출물 목록 확인은 받을 것이 다 왔는지 보는 단계이고, 인수는 그 산출물만으로 서비스를 다시 띄울 수 있는지 보는 단계입니다.

이 둘을 같은 날 한꺼번에 하면 거의 목록 확인으로 끝납니다. 개발사가 화면을 띄워 보여 주고 담당자가 고개를 끄덕이면 인수가 된 것처럼 느껴지지만, 그 환경은 개발사의 컴퓨터와 개발사의 계정으로 돌아가고 있습니다. 개발사가 빠진 뒤 처음 배포를 시도하는 날 막히는 일이 여기서 생깁니다.

공공 소프트웨어사업에 적용되는 기준도 순서를 나눠 둡니다. 발주기관은 먼저 인수 계획을 세워 인수를 준비하고, 납품되는 소프트웨어가 계약서의 요구사항을 충족했는지 시험과 검사를 수행한 뒤에 최종 산출물을 인수하고 사업을 종료합니다. 민간 외주 계약에 이 고시가 그대로 적용되지는 않지만, 순서의 뼈대로는 그대로 쓸 수 있습니다.

인수 계획에는 무엇을 적나요?

인수 계획은 한 장이면 됩니다. 검사할 항목, 검사할 사람, 검사에 쓸 환경, 통과로 볼 기준을 적습니다. 항목을 미리 적어 두지 않으면 개발사가 보여 주는 순서를 따라가게 되고, 무엇이 빠졌는지 알 수 없습니다.

검사에 쓸 환경을 적는 이유는 분명합니다. 개발사의 노트북에서 돌아간 결과는 우리 환경에서 돌아간다는 증거가 아닙니다. 우리 계정으로 만든 저장소, 우리 이름으로 결제하는 서버, 우리가 받은 운영 키로 한 번씩 확인해야 합니다.

검사 일정도 계획에 넣습니다. 공공사업 기준에서도 발주기관이 사업 수행 상태와 산출물을 검사하기 위한 합동검토계획을 세워 계약상대자와 함께 검토하도록 정하고 있습니다. 인수를 마지막 하루에 몰면 문제를 찾아도 고칠 시간이 남지 않으므로, 계약 종료 2~3주 전에 1차 검사를 넣습니다.

문서는 분량이 아니라 재현 가능성으로 봅니다. 담당자가 그 문서만 보고 같은 결과를 만들 수 있으면 충분하고, 그렇지 않으면 쪽수가 많아도 부족합니다. 빌드 절차, 배포 절차와 되돌리는 절차, 환경 변수와 키의 목록과 발급처, 외부 연동의 계정 명의와 요금 결제 주체, 데이터베이스 구조와 변경 이력, 장애 시 먼저 볼 화면이 들어가면 1차 인수에는 쓸 수 있습니다.

문서에 적힌 값 중 실제 운영 키는 문서 본문에 적지 말고 전달 경로와 보관 위치만 적게 합니다. 키가 문서와 함께 돌아다니면 인수 뒤에 누가 그 키를 가지고 있는지 추적할 수 없습니다.

넘겨받은 자리에서 직접 해 보는 네 가지

네 가지는 개발사의 설명을 듣는 것이 아니라 우리 쪽 담당자가 직접 실행합니다. 실행이 막히면 그 자리에서 무엇이 없어서 막혔는지 적습니다. 막힌 이유가 대부분 보완해야 할 문서나 권한의 이름입니다.

1. 빌드 — 받은 저장소를 우리 계정으로 내려받아, 넘겨받은 문서만 보고 빌드가 끝까지 돌아가는지 확인합니다. 구두 설명이 필요했다면 그 내용을 문서에 추가받습니다.
2. 배포와 되돌리기 — 운영 환경에 한 번 올려 보고, 올린 것을 이전 버전으로 되돌려 봅니다. 되돌리기는 설명만 듣지 말고 실제로 실행합니다.
3. 핵심 흐름 1건 — 고객이 실제로 하는 한 가지를 처음부터 끝까지 완주하고, 관리자 화면과 외부 연동에 그 건이 보이는지 확인합니다.
4. 계정과 키 — 저장소·서버·결제·알림·도메인의 소유자가 우리 회사 명의인지, 개발사 계정을 지워도 서비스가 계속 도는지 확인합니다.

채워 본 인수 확인표 — 예약 MVP

표의 왼쪽 칸은 검사 전에 정하고, 가운데와 오른쪽 칸은 검사한 날 채웁니다. 비어 있는 줄이 남아 있으면 인수를 끝내지 않고, 그 줄만 따로 보완 기한을 받습니다.

인수를 멈춰야 하는 경우

세 가지는 보완 기한을 받고 인수를 끝내지 않습니다. 첫째, 우리 명의 계정으로 배포가 한 번도 성공하지 않은 경우입니다. 둘째, 운영 데이터를 지우거나 복구하는 절차를 아직 실행해 보지 못한 경우입니다. 셋째, 외부 연동의 계정이 개발사 명의로 남아 있어 계약이 끝나면 그 기능이 멈추는 경우입니다.

반대로 화면의 문구나 디자인 보완처럼 서비스가 도는 데 영향이 없는 항목은 인수를 막는 조건으로 쓰지 않고, 인수 확인서의 보완 목록에 적어 두고 진행합니다.

인도일을 문서에 남깁니다

도급 계약에서 보수는 완성된 목적물의 인도와 동시에 지급하는 것이 원칙이고, 하자의 보수나 손해배상 청구, 계약 해제는 목적물의 인도를 받은 날부터 1년 안에 해야 합니다. 그래서 인도일이 언제인지가 뒤에 남는 권리의 시작점이 됩니다.

인수 확인서에는 인도일, 인도받은 목록, 통과하지 못한 항목과 보완 기한을 함께 적습니다. 출시일이나 잔금 지급일을 인도일처럼 적어 두면 나중에 기준일이 흔들립니다. 분할로 받았다면 각 회차의 인도일을 따로 적습니다.

이번 주에 정할 한 가지

인수 확인표의 왼쪽 칸, 즉 검사할 항목 목록을 먼저 만들어 개발사에 보냅니다. 항목을 미리 공유하면 개발사도 그 항목에 맞춰 문서와 권한을 정리하므로, 인수 당일에 처음 보는 문제가 줄어듭니다.