외주 개발 납품 검수는 무엇을 기준으로 해야 합니까?

「완료」의 해석이 갈리는 이유

민법 제664조는 도급을 「어느 일을 완성할 것을 약정하고 상대방이 그 일의 결과에 대하여 보수를 지급할 것을 약정」하는 계약으로 정하고, 제665조는 보수를 완성된 목적물의 인도와 동시에 지급하도록 합니다. 소프트웨어 개발 계약이 어떤 성격의 계약인지는 그 내용에 따라 판단되지만, 어느 경우든 무엇을 「완성」으로 볼지가 대금 지급과 곧바로 연결된다는 점은 같습니다.

그런데 그 기준이 계약서에 없으면 양쪽은 서로 다른 잣대를 듭니다. 개발사는 기능 목록에 적힌 화면이 모두 있으니 완료라고 보고, 현업은 실제 업무를 처음부터 끝까지 처리할 수 없으니 미완료라고 봅니다. 둘 다 틀리지 않았기 때문에 다툼이 길어집니다. 그래서 검수 기준은 납품 시점이 아니라 착수 시점에 정해야 합니다.

1. 착수
2. 검수 기준 합의
3. 시나리오 작성
4. 인수 테스트
5. 결함 조치
6. 완료 확인

검수 기준의 다섯 층

검수 기준은 한 줄이 아니라 여러 층으로 이뤄집니다. 다음 다섯 층을 계약서 별첨에 나눠 적으면 빠지는 곳이 줄어듭니다.

비기능 기준은 특히 자주 빠집니다. 사용자가 몇 명일 때 어느 정도 속도로 응답해야 하는지, 어떤 보안 점검을 통과해야 하는지, 어떤 브라우저와 휴대폰에서 동작해야 하는지가 적혀 있지 않으면, 납품 뒤 「느리다」 「이 기기에서 깨진다」는 문제를 하자로 볼지 개선으로 볼지가 다시 다툼이 됩니다.

데이터 이관도 별도 기준이 필요합니다. 옮긴 뒤 화면이 열린다는 것만으로는 부족하고, 이관 전후의 건수와 금액 합계가 일치하는지, 무작위로 고른 몇 건의 상세 내용이 원본과 같은지를 확인해야 합니다. 이관 대상에서 일부러 뺀 데이터가 있다면 그 목록도 검수 기록에 남겨 두십시오.

시나리오는 기능 목록이 아니라 업무 순서로 씁니다

기능 목록으로 검수하면 각 화면은 동작하는데 화면과 화면 사이가 끊긴 상태를 잡아내지 못합니다. 시나리오는 실제 담당자가 하루 동안 하는 일의 순서로 씁니다. 작성할 때는 다음을 챙기십시오.

• 정상 흐름과 함께 반려·취소·중복 입력 같은 예외 흐름을 넣습니다
• 작성자·승인자·관리자처럼 역할별로 같은 시나리오를 따로 돌립니다
• 권한이 없는 사용자가 시도했을 때 막히는지도 확인합니다
• 실제와 비슷한 데이터를 쓰되, 운영 개인정보는 가명 처리합니다
• 기대 결과를 숫자나 화면 상태로 적어 판정이 갈리지 않게 합니다

시나리오는 현업이 쓰고 개발사가 검토하는 순서가 바람직합니다. 업무를 가장 잘 아는 쪽이 쓰고, 만드는 쪽은 그 시나리오가 합의한 범위 안에 있는지를 확인하는 방식입니다. 범위 밖의 시나리오가 나오면 그 자리에서 변경 요청으로 분리해 두면 일정과 비용의 근거가 남습니다.

모든 경우의 수를 다 쓰려고 하면 시나리오 작성 자체가 일정을 잡아먹습니다. 매일 반복되는 핵심 업무, 그리고 금액·재고·개인정보처럼 틀리면 바로 손실이 나는 업무부터 쓰고, 드물게 일어나는 예외는 그다음에 덧붙이는 순서가 현실적입니다. 이렇게 만든 시나리오 문서는 검수가 끝난 뒤 신규 직원 교육 자료와 다음 개편의 회귀 시험 목록으로도 그대로 쓸 수 있습니다.

결함 등급과 조건부 완료

「결함이 하나도 없을 것」을 완료 기준으로 삼으면 사소한 표시 오류 하나로도 검수가 끝나지 않을 수 있습니다. 그래서 결함이 남아 있어도 완료로 볼 수 있는 조건을 미리 정해 두어야 검수가 끝없이 늘어지지 않습니다.

조건부 완료를 쓸 때는 남은 결함 목록과 수정 기한을 검수 확인서에 함께 적어 두십시오. 목록에 없는 결함이 나중에 발견되면 그것은 하자 대응의 영역으로 넘어갑니다.

등급을 누가 정하는지도 미리 합의해 두는 편이 좋습니다. 현업과 개발사는 같은 결함의 무게를 서로 다르게 보기 쉽기 때문입니다. 등급 정의를 업무 영향 기준으로 적어 두고, 의견이 갈리면 양쪽 책임자가 함께 판정한다고 정해 두면 검수가 감정 싸움으로 번지지 않습니다. 재검수를 몇 차례까지 하는지도 함께 정해 두면 일정이 예측 가능해집니다.

검수 기간과 통지 방식

마지막으로 절차를 정합니다. 납품 후 며칠 안에 검수를 마칠지, 결과를 어떤 방식으로 통지할지, 기간 안에 통지가 없으면 어떻게 처리할지입니다. 계약서에 「기간 안에 이의가 없으면 완료로 본다」는 간주 조항이 들어 있다면, 그 기간 안에 테스트할 인력과 일정을 미리 확보해 두셔야 합니다. 현업이 바쁜 시기와 검수 기간이 겹치면 확인하지 못한 채 완료로 처리될 수 있습니다.

검수가 끝나면 검수 확인서를 남깁니다. 확인한 시나리오 목록과 결과, 남은 결함과 수정 기한, 받은 인도물 목록, 확인한 날짜와 양쪽 서명이 들어가면 충분합니다. 이 문서는 대금 지급의 근거가 되고 하자 대응 기간을 세는 기준일로도 쓰이는 경우가 많으므로, 메일 답장 한 줄로 갈음하지 않는 편이 좋습니다.

빌드업웍스도 착수 때 합의한 범위와 동작 기준을 놓고 함께 확인하는 인수 확인 절차로 구축 완료를 판정하며, 그 과정에서 나온 항목은 하자 대응 범위에 넣습니다.

참고 자료

• 민법 제664조(도급의 의의) — 국가법령정보센터
• 민법 제665조(보수의 지급시기) — 국가법령정보센터
• 과학기술정보통신부 — 소프트웨어(SW)분야 표준계약서(6종) 활용 안내