[IT 외주 검수 기준] 모호한 납품 기준이 부르는 분쟁과 예방 가이드

"다 만들었습니다" vs "쓸 수가 없는데요"

IT 외주 프로젝트의 종착역은 '검수'입니다. 하지만 수많은 프로젝트가 이 종착역을 앞두고 멈춰 서거나, 법정 싸움으로 번지곤 합니다. 개발사는 "계약서에 적힌 기능을 모두 구현했다"고 주장하는 반면, 발주사는 "버그가 너무 많고 UI가 생각했던 것과 달라 도저히 쓸 수 없다"며 잔금 지급을 거절하기 때문입니다.

이러한 갈등의 핵심에는 불명확한 IT 외주 검수 기준이 있습니다. 단순히 '성실히 개발하여 납품한다'는 식의 추상적인 문구는 분쟁 발생 시 누구의 손도 들어주지 못합니다. 오늘은 법적 근거와 판례를 바탕으로, 분쟁 없는 IT 외주를 위한 검수 기준 설정법을 상세히 살펴보겠습니다.

소프트웨어의 '완성'은 법적으로 무엇을 의미할까?

IT 외주 계약은 법적으로 '도급 계약(민법 제664조)'의 성격을 가집니다. 도급이란 당사자 일방이 어느 일을 완성할 것을 약정하고, 상대방이 그 일의 결과에 대하여 보수를 지급할 것을 약정함으로써 성립하는 계약입니다.

여기서 가장 중요한 지점은 **'일의 완성'**입니다. 소프트웨어가 어느 정도 수준까지 도달해야 '완성'되었다고 볼 수 있을까요?

대법원이 말하는 소프트웨어 완성의 기준

대법원 판례(대법원 2004. 12. 9. 선고 2004다11548 판결)에 따르면, 소프트웨어 개발의 경우 "예정된 최후의 공정을 일단 종료하였다면" 미완성이 아닌 '하자'가 있는 것으로 봅니다. 즉, 주요 기능이 구현되어 돌아간다면 일부 버그가 있더라도 법적으로는 '일단 완성'된 것으로 간주되어 발주자는 잔금을 지급할 의무가 발생할 수 있습니다.

IT 외주 검수 기준이 모호할 때 발생하는 3가지 리스크

1. 무한 수정의 굴레 (Scope Creep)

검수 기준이 없으면 발주자는 "이것도 당연히 해줘야 하는 것 아니냐"며 새로운 기능을 요구하고, 개발사는 "그건 추가 비용 발생 건이다"라며 맞서게 됩니다. 기준이 없기에 어디까지가 계약 범위이고 어디부터가 유지보수인지 경계가 사라집니다.

2. 잔금 지급의 지연 및 거부

발주자는 검수를 완료해주지 않음으로써 대금 지급을 미루는 강력한 무기를 갖게 됩니다. 반대로 개발사는 완성도가 현저히 낮은 결과물을 던져놓고 '일단 끝났으니 돈을 달라'고 압박할 수 있습니다.

3. 하자보수 책임의 범위 불분명

검수 통과 시점은 보통 '하자보수 기간'의 시작점입니다. 검수가 제대로 이루어지지 않으면 하자보수 기간이 언제부터인지 확정할 수 없어, 1년 전 개발한 기능에 대해 여전히 무상 수리를 요구받는 상황이 벌어집니다.

분쟁을 막는 명확한 검수 기준 설정법

성공적인 프로젝트 종료를 위해서는 계약 체결 단계부터 다음의 사항들을 IT 외주 검수 기준으로 명시해야 합니다.

1. 검수 항목의 정량화 (Checklist)

'사용자가 쓰기 편한 UI'와 같은 주관적인 표현은 피해야 합니다. 대신 '기능 명세서에 기재된 50개 항목의 정상 작동 여부'처럼 정량화된 기준을 사용해야 합니다.

• 과업지시서(SOW) 첨부: 계약서의 부속 서류로 상세 기능 리스트를 반드시 첨부하세요.
• 성능 지표 설정: 동시 접속자 수, 페이지 로딩 속도 등 수치로 확인 가능한 지표를 포함하세요.

2. 검수 기간과 '검수 간주' 조항

많은 발주사가 바쁘다는 핑계로 검수를 차일피일 미룹니다. 이를 방지하기 위해 **'검수 간주 조항'**이 필수적입니다.

3. 단계별 검수 (Milestone)

프로젝트가 대규모라면 마지막에 한 번에 검수하는 것은 위험합니다. 기획 단계, 디자인 단계, 개발 단계별로 중간 검수를 진행하고 각 단계마다 검수 확인서를 작성하는 것이 좋습니다.

공정거래위원회 'SW 표준도급계약서' 활용하기

정부에서도 이러한 분쟁을 예방하기 위해 표준안을 제시하고 있습니다. 공정거래위원회의 소프트웨어사업 표준도급계약서 제14조(검수)에 따르면 다음과 같은 원칙을 제시합니다.

1. 개발자는 인도 후 10일 이내에 검수를 요청해야 한다.
2. 발주자는 검수 요청을 받은 날로부터 10일 이내에 검수를 완료해야 한다.
3. 정당한 사유 없이 검수를 지연할 경우 검수 기간이 종료된 다음 날 검수에 합격한 것으로 본다.

이 기준은 업계의 표준적인 공정 기준으로 작동하므로, 계약서 작성 시 이를 참고하면 법적 안정성을 크게 높일 수 있습니다.

실무자를 위한 검수 가이드라인 3단계

1단계: 과업 확정 (계약 시)

• 무엇이 '완성'인지 정의하세요.
• 디자인 시안 확정 방식, 사용 기술 스택, 결과물 형태(소스코드, 설치 파일 등)를 명시하세요.

2단계: 테스트 및 수정 (개발 중)

• 단순히 '봤다'가 아니라, 테스트 시나리오(Test Case)에 따라 구동 여부를 확인하세요.
• 발견된 오류는 '치명적 결함(Critical)'과 '사소한 UI 오류(Minor)'로 구분하여 대응하세요.

3단계: 검수 확인서 작성 (종료 시)

• 모든 검수가 끝났다면 반드시 **'검수 완료 확인서'**에 양측 서명을 남기세요.
• 이 시점부터 잔금 청구권이 발생하며, 하자보수 기간이 카운트됩니다.

결론: 검수 기준은 신뢰의 도구입니다

명확한 IT 외주 검수 기준을 세우는 것은 개발사를 압박하기 위함이 아닙니다. 오히려 서로의 역할과 책임을 명확히 함으로써, 불필요한 감정 소모를 줄이고 프로젝트를 성공적으로 완수하기 위한 '신뢰의 안전장치'입니다.

지금 여러분의 계약서에는 "검수는 관례에 따른다"는 위험한 문구가 적혀 있지는 않나요? 아니면 검수 기간이 무기한으로 설정되어 있지는 않나요?

소프트웨어 개발 계약은 그 특수성 때문에 일반적인 물품 매매 계약과는 완전히 다른 접근이 필요합니다. 법률 전문가의 검토를 거친 명확한 계약서만이 여러분의 자산과 시간을 보호할 수 있습니다.