테스트와 검수의 차이: 개발의 마지막 단계가 아니라 계약의 기준

일정표에서 테스트는 보통 한 칸입니다. 구현 다음, 오픈 앞에 놓인 2주짜리 칸 하나. 그 칸 안에서 개발팀이 버그를 잡고, 같은 칸 안에서 고객이 화면을 눌러 보고, 문제가 없으면 오픈합니다.

그런데 이 한 칸에는 목적도 주체도 기준도 다른 두 가지 일이 들어 있습니다. 하나는 우리가 품질을 확인하는 일이고, 다른 하나는 고객이 계약 이행을 확인하는 일입니다. 뒤쪽은 법이 절차를 정해 둔 행위입니다.

한 단어에 묶여 있는 두 개의 다른 활동

두 활동을 나란히 놓으면 겹치는 부분이 거의 없습니다.

	개발 테스트	검수
주체	만든 쪽	받는 쪽
목적	결함을 찾아 고치기	계약대로 이행됐는지 확인
기준	우리가 정함	계약서와 설계서
결과물	수정된 코드	합격 또는 불합격 판정
실패했을 때	고치고 다시 돌림	대금 지급이 미뤄짐

마지막 줄이 가장 큽니다. 개발 테스트가 실패하면 일이 늘어나고, 검수가 실패하면 돈이 안 들어옵니다. 같은 칸에 넣을 수 있는 성질의 일이 아닙니다.

검수의 기준이 설계서라고 못 박은 법 조문

검수가 무엇을 기준으로 이뤄지는지는 취향의 문제가 아닙니다. 국가를 당사자로 하는 계약에 관한 법률 제14조는 검사를 이렇게 규정합니다.

각 중앙관서의 장 또는 계약담당공무원은 계약상대자가 계약의 전부 또는 일부를 이행하면 이를 확인하기 위하여 계약서, 설계서, 그 밖의 관계 서류에 의하여 검사하거나 소속 공무원에게 그 사무를 위임하여 필요한 검사를 하게 하여야 한다. (국가계약법 제14조)

"설계서에 의하여"입니다. 검수자가 보는 것은 화면이 잘 도는지가 아니라 설계서에 적힌 것이 실제로 있는지입니다. 설계서에 없는 기능은 아무리 잘 만들어도 검수 항목이 아니고, 설계서에 있는데 없는 기능은 아무리 사소해도 불합격 사유가 됩니다.

스토리보드를 다룬 글에서 설계서가 계약 문서이기도 하다고 적었는데, 그 성격이 가장 직접적으로 작동하는 순간이 검수입니다. 설계서의 빈칸은 개발 중에는 협의 대상이지만 검수 단계에서는 판정 불가 항목이 됩니다.

검사조서가 만드는 되돌릴 수 없는 시점

같은 조문은 검사하는 사람이 검사조서를 작성해야 한다고 정합니다(대통령령이 정하는 경우에만 생략 가능합니다).

이 문서가 만들어지는 순간이 중요합니다. 검수는 회의가 아니라 기록을 남기는 절차이고, 그 기록이 대금 지급과 사업 종료일의 근거가 됩니다. 구두로 "확인했습니다"를 주고받는 것과 조서가 작성되는 것은 법적으로 다른 사건입니다.

민간 외주에는 검사조서라는 이름의 서식이 없는 경우가 많습니다. 그래도 기능은 같은 문서가 필요합니다. 무엇을 확인했고 무엇이 남았고 언제 합격 처리됐는지가 적힌 한 장이 없으면, 나중에 "그건 검수 때 이야기한 건데요"가 양쪽에서 서로 다르게 기억됩니다.

검수 완료일부터 다시 시작되는 하자담보 1년

검수가 끝나면 프로젝트가 끝난다고 생각하기 쉬운데, 법은 반대로 봅니다. 소프트웨어 진흥법 제60조는 하자담보책임을 이렇게 정합니다. 소프트웨어사업자는 사업을 종료한 날부터 1년 이내에 발생한 하자에 대해 담보책임을 집니다. 그리고 이 조문은 "사업을 종료한 날"을 괄호로 정의해 둡니다. 시험 및 검사를 수행하여 최종 산출물을 인도한 날입니다.

검수 완료일이 책임 기간의 종료점이 아니라 시작점이라는 뜻입니다. 오픈은 결승선처럼 보이지만 실제로는 1년짜리 시계가 켜지는 지점입니다.

이 구조를 모르고 견적을 짜면 빠지는 비용이 생깁니다. 오픈 이후 1년 동안 하자 대응에 쓸 시간이 계산에 없으면, 그 시간은 다음 프로젝트에서 빼 오게 됩니다.

일정표에서 테스트가 한 칸을 차지하는 문제

다시 일정표로 돌아오면, 한 칸으로 그린 테스트에는 두 가지가 숨습니다.

첫째, 검수 기간이 우리 통제 밖이라는 사실입니다. 개발 테스트는 우리가 밤을 새워 줄일 수 있지만, 고객이 화면을 확인하는 데 걸리는 시간은 고객의 일정에 달려 있습니다. 담당자가 휴가를 가면 검수는 그만큼 밀립니다.

둘째, 재검수 회차가 몇 번인지 정해져 있지 않다는 점입니다. 1차 검수에서 지적 사항이 나오면 수정하고 다시 받는데, 이 왕복이 몇 번까지인지 계약서에 없으면 무한합니다. 지적 사항이 설계서 범위 안인지 밖인지 매번 다투게 되고, 그 다툼의 기준이 되는 것은 다시 설계서입니다.

검수 기준이 비어 있는 중소기업 외주의 위험

공공사업에는 검사 절차가 법으로 정해져 있지만 중소기업 외주에는 그런 틀이 없습니다. 그래서 계약서에 "검수 후 잔금 지급"이라고만 적히고 검수가 무엇인지는 안 적히는 경우가 흔합니다.

이 한 줄은 겉보기에 평범하지만 해석의 여지가 넓습니다. 고객이 만족해야 검수 합격인지, 설계서대로면 합격인지가 정해져 있지 않기 때문입니다. 앞쪽 해석이면 잔금 지급 시점이 고객의 주관에 걸리고, 그 주관에는 상한이 없습니다.

저는 이 공백이 외주에서 가장 조용히 위험한 항목 중 하나라고 봅니다. 개발 중에는 아무 문제도 일으키지 않다가 마지막에 한 번에 터지고, 그 시점에는 이미 모든 일을 다 해 놓은 상태라 협상력이 가장 낮습니다.

공공사업에는 이 상황을 위한 장치가 하나 더 있습니다. 소프트웨어 진흥법 제50조가 정한 과업심의위원회입니다. 과업내용의 확정과 변경, 그에 따른 계약금액·계약기간 조정을 심의하는 기구인데, 주목할 것은 제3항입니다. 계약을 체결한 사업자가 위원회 개최를 요청할 수 있고, 발주기관은 특별한 사정이 없으면 그 요청을 수용해야 합니다(제50조).

수주 측이 먼저 "이건 범위 밖입니다"를 제기할 통로를 법이 열어 둔 것입니다. 민간 외주에는 이런 통로가 없습니다. 그래서 그 역할을 계약서가 대신해야 하고, 계약서에 없으면 그냥 목소리 큰 쪽이 이깁니다.

오픈 전에 합의해 두어야 하는 합격 조건

그래서 검수 조건은 오픈 직전이 아니라 계약 시점에 정해 두는 편이 안전합니다. 정해 둘 항목은 많지 않습니다.

합격 기준이 무엇인지(설계서 기준인지 별도 시나리오인지), 검수 기간이 며칠인지, 그 기간에 응답이 없으면 어떻게 되는지, 재검수는 몇 회까지인지, 그리고 설계서에 없던 요청이 검수 단계에서 나오면 그것을 하자로 볼지 추가 과업으로 볼지입니다.

마지막 항목이 실제로 가장 자주 다투는 지점입니다. 검수 단계에서 나오는 요청의 상당수는 결함이 아니라 새 요구사항인데, 시점이 늦다 보니 결함처럼 제기됩니다. 이 구분을 계약 전에 문장으로 정해 두면 그때 가서 사람의 성격에 기대지 않아도 됩니다.

테스트를 개발의 마지막 단계로 두면 이 항목들이 전부 일정표 밖에 남습니다. 검수를 계약의 한 절차로 보면 그때부터 각각이 정해야 할 값이 됩니다.