소프트웨어 개발 계약, 검수와 하자 대응 기준 

소프트웨어 개발 계약의 검수 기준이 추상적이면 납품 뒤 무엇이 완성인지, 어떤 문제가 보수 대상인지 다투기 쉽습니다. 기능별 완료 조건·시험환경·오류 등급·수정 기한·재검수 절차를 계약에 연결하고, 완성형 도급인지 투입 시간 기준 용역인지 대금 약정과 실제 수행 방식으로 구분해야 합니다.

개발계약의 대금 구조부터 구분합니다

민법상 도급은 한쪽이 일을 완성하기로 하고, 상대방은 그 결과에 보수를 지급하기로 약정하는 계약입니다. 소프트웨어 개발·공급도 계약에 따라 도급으로 볼 수 있지만, 모든 개발계약이 완성된 프로그램을 납품하고 정액 보수를 한꺼번에 받는 방식이어야 하는 것은 아닙니다. 대법원은 구체적 약정에 따라 실제 투입 인력과 실적을 기준으로 보수를 정하는 계약도 가능하다고 판단했습니다. 그래서 계약 명칭에 ‘개발 용역’이라고 적혀 있다는 점만으로 완성 의무나 대금 지급 조건을 단정하기 어렵습니다.

고정 총액으로 특정 시스템을 완성하기로 했는지, 월별 인력 투입이나 실제 작업시간에 따라 비용을 지급하기로 했는지 계약 조항을 함께 읽습니다. 착수금·중도금·잔금이 어떤 산출물이나 단계에 연결되는지도 확인해야 합니다. 투입형 계약에서 결과물 전체의 완성을 유일한 지급 조건처럼 다루거나, 반대로 완성형 계약에서 일정이 지났다는 이유만으로 전액 지급을 예정하면 약정과 다른 분쟁이 생길 수 있습니다. 대법원도 소프트웨어 개발계약의 보수 방식은 개별 약정에 따라 달라질 수 있다고 보았습니다.

요구사항과 검수 기준을 한 문서로 연결합니다

계약서 본문에는 프로젝트 목적, 개발 범위, 일정, 대금 구조를 두고, 기능목록·화면정의서·인터페이스 규격·보안 요구사항 등 구체 자료를 별첨으로 특정합니다. 문서 버전과 승인 날짜를 표시하고, 문서 사이에 차이가 있을 때 무엇을 우선할지도 정합니다. 제안서나 회의록이 계약 내용에 포함되는지 불분명하면 요구사항 변경 때마다 원래 범위를 두고 이견이 커질 수 있습니다.

기능별로 입력값, 처리 결과, 권한별 동작, 예외 상황을 적습니다. 예를 들어 ‘검색 기능 구현’ 대신 어떤 항목을 어떤 조건으로 조회하고, 결과가 없거나 접근권한이 없을 때 어떤 화면과 기록이 나와야 하는지 정합니다. 처리속도·동시접속·장애복구·브라우저 지원을 요구한다면 측정 방법, 시험 데이터의 규모, 네트워크와 서버 환경도 명시합니다. 추상적인 ‘정상 작동’, ‘사용에 지장이 없을 것’만 두면 서로 다른 환경에서 같은 결과를 기대했다는 주장이 맞서기 쉽습니다.

검수는 발주자가 주관적으로 만족했는지로만 판단하지 않도록 설계합니다. 테스트 항목별 통과 조건, 실패로 볼 오류의 정의, 재현 방법, 시험 결과 기록 양식과 담당자를 미리 정합니다. 오류는 업무를 멈추게 하는 중대 오류, 일부 기능의 제한, 문구·화면 표시 등으로 나눌 수 있고, 등급에 따라 사용 개시 여부와 보완 기한을 달리 정할 수 있습니다. 다만 분류 이름만 두지 말고 각 등급의 실제 예시와 판정 기준을 연결해야 합니다.

단계별 인도·검수·지급을 맞춥니다

분석, 시제품, 주요 기능, 통합 시험, 운영 전환처럼 단계가 나뉜다면 각 단계의 결과물과 검수 기간, 다음 단계로 넘어가는 조건을 계약에 씁니다. 발주자가 검수 요청을 받은 뒤 며칠 안에 항목별 결과를 통지하는지, 미통지 시 검수 완료로 보는지, 그 경우에도 잠복 오류나 보안 문제를 별도로 다룰지 정합니다. 자동 승인 조항은 실제로 확인할 수 있는 기간과 담당 체계를 고려해 신중히 설계해야 합니다.

일부 기능에 사소한 오류가 있다고 전체 결과물의 인수를 무조건 거절하거나, 반대로 핵심 기능이 작동하지 않는데도 일부 화면이 보인다는 이유로 전체 검수가 완료됐다고 처리하면 위험합니다. 부분 인수와 유보할 기능, 미완료 항목의 보완 일정, 해당 부분의 대금 보류 범위를 나누어 둘 수 있습니다. 검수 완료가 대금 지급이나 권리 이전의 조건이라면 그 효과가 어떤 범위에 미치는지 명시합니다. 운영에 투입하거나 실제 데이터를 이관하는 행위를 검수 완료로 볼지 여부도 별도 합의가 필요합니다.

발주자는 시험 결과를 말로만 전달하지 말고 오류가 발생한 화면, 입력 데이터, 재현 순서, 로그와 발생 시각을 보존합니다. 개발자는 해당 문제를 재현했는지, 원인이 요구사항 변경·외부 시스템·사용자 설정 중 무엇인지, 수정 버전에서 어떻게 확인했는지 기록합니다. ‘검수 완료’ 또는 ‘불합격’이라는 한 줄 통지보다 항목별 결과표가 계약상 이행 정도와 남은 일을 설명하는 데 도움이 됩니다.

하자 보수 요청과 계약 해제는 요건이 다릅니다

민법 제667조는 완성된 목적물 또는 완성 전 성취된 부분에 하자가 있으면 도급인이 상당한 기간을 정해 보수를 청구할 수 있도록 합니다. 하자가 중요하지 않은데 보수에 지나치게 큰 비용이 들면 보수청구가 제한될 수 있고, 도급인은 요건에 따라 보수에 갈음하거나 보수와 함께 손해배상을 청구할 수 있습니다. 소프트웨어에서 문제가 생겼다는 사실만으로 곧바로 전체 계약 해제나 전액 환급이 인정되는 것은 아닙니다.

민법 제668조의 해제는 완성된 결과물의 하자로 계약 목적을 달성할 수 없는 경우가 기준입니다. 핵심 시스템을 사실상 사용할 수 없는 문제인지, 대체 방법이나 합리적인 수정으로 목적을 달성할 수 있는지, 계약에서 기대한 기능이 무엇인지 살펴야 합니다. 사소한 오류나 일부 요구사항의 미충족이 언제나 해제 사유가 된다고 단정하지 않습니다. 반대로 핵심 기능이 장기간 구현되지 않고 보완 가능성도 확인되지 않는다면, 단순 보수 요청을 넘는 대응을 검토할 수 있습니다.

발주자가 제공한 자료나 구체적인 지시 때문에 문제가 생긴 경우에는 민법 제669조에 따른 책임 제한이 문제될 수 있습니다. 다만 개발자가 그 자료나 지시가 부적절하다는 사실을 알고도 발주자에게 알리지 않았다면 예외가 될 수 있습니다. 요구사항 변경을 승인한 사람, 개발자가 위험을 설명한 시점, 발주자의 선택을 회의록과 변경요청서에 남겨야 하는 이유입니다. 책임을 한쪽에 일괄 귀속하는 문구보다 실제 원인과 당사자가 알고 있던 사정을 확인할 수 있는 기록이 중요합니다.

인도 후 1년 규정과 계약상 보증기간을 혼동하지 않습니다

민법 제670조는 제667조부터 제669조까지의 하자 보수·손해배상 청구와 계약 해제를 목적물 인도일부터 1년 안에 하도록 정하고 있습니다. 인도가 필요 없는 경우에는 일의 종료일부터 기간을 계산합니다. 이는 모든 계약상 손해배상청구의 소멸시효를 일률적으로 1년으로 정한 조항이라고 설명해서는 안 됩니다. 계약의 성격과 청구의 법적 근거, 인도나 종료 시점을 구체적으로 확인해야 합니다.

계약서에 정한 무상 유지보수나 별도 보증기간은 민법상 도급 하자담보 책임과 범위·기간·절차가 다를 수 있습니다. 계약상 보증이 끝났다는 이유만으로 모든 권리가 당연히 사라진다고 보거나, 보증기간이 남았다는 이유로 민법상 기간 계산을 무시하지 않습니다. 개발 결과물을 일부씩 인도했다면 어떤 시점이 각 부분의 인도인지, 사용 승인과 최종 인도가 언제인지 자료로 구분합니다. 초기에 오류를 발견했더라도 분쟁이 계속되는 동안 기간이 멈춘다고 당연히 전제하지 말고 권리 행사 시점을 점검해야 합니다.

중도 종료 때는 완성된 부분과 자료를 정산합니다

개발이 끝나기 전에 계약을 종료하는 경우에는 완성된 결과물, 재사용 가능한 코드와 문서, 미완성 기능, 이미 지급한 돈, 외부 라이선스 비용을 각각 정리합니다. 민법 제673조는 수급인이 일을 완성하기 전 도급인이 손해를 배상하고 계약을 해제할 수 있도록 합니다. 따라서 발주자가 언제든 위약금 없이 종료할 수 있다고 단정할 수 없습니다. 계약이 정한 중도 종료 조항과 실제 사유, 종료 시점의 진행률과 손해를 함께 검토해야 합니다.

대법원은 개발·공급계약이 중도에 해소된 구체적 사건에서 이미 공급·설치된 프로그램의 완성도와 보완 가능성, 발주자가 수정 제안을 거부한 사정 등을 살펴 완성된 부분의 보수 청구를 인정했습니다. 이 판결이 모든 개발 중단 사건에서 진행률만큼의 대금을 지급해야 한다는 뜻은 아닙니다. 계약의 보수 방식, 해소 경위, 이미 제공된 부분이 발주자에게 실제 이익이 되는지에 따라 결론이 달라질 수 있습니다.

종료 시 데이터 반환·삭제, 소스코드와 설계자료의 인도, 계정·접근권한 회수, 외부 서비스 전환 지원, 미지급 대금과 손해의 정산을 미리 정합니다. 저작권 귀속과 사용 허락, 오픈소스·제3자 모듈의 조건도 별도 조항으로 구체화합니다. “모든 결과물은 발주자 소유”라고만 두기보다 기존에 개발자가 보유한 도구, 프로젝트를 위해 새로 만든 코드, 제3자 라이선스를 구별하고 발주자가 실제 운영·수정·유지할 수 있는 권한을 정해야 합니다.

문제가 생기면 이 자료부터 한 묶음으로 보존합니다

분쟁 초기에는 계약서와 별첨의 적용 버전, 승인된 변경요청, 단계별 검수표, 오류 통지와 답변, 재현 로그, 배포 이력, 지급 내역을 시간 순서로 모읍니다. 계약상 검수기간과 보수·해제 통지 방법을 먼저 확인하고, 권리 행사 기한이 임박했는지도 따져야 합니다. 운영 중인 서비스라면 무리한 업데이트나 데이터 삭제가 장애 원인을 흐리거나 이용자 피해를 키우지 않도록 보존 절차를 마련합니다.

발주자와 개발자는 상대방의 설명만으로 원인을 확정하지 말고, 요구사항과 실제 동작을 항목별로 대조해야 합니다. 결과물을 인수하거나 사용했다는 사정만으로 모든 하자 주장이 당연히 배제되는 것은 아니지만, 계약상 검수·인수 조항과 실제 통지·사용 경위가 판단에 영향을 줄 수 있으므로 이를 함께 확인해야 합니다. 개발자도 ‘요구사항에 없었다’는 말만 반복하기보다 승인 문서, 협의 기록, 구현 범위와 보완 제안을 제시할 필요가 있습니다.

개발계약은 업무의 결과를 약정했는지, 투입 실적을 기준으로 비용을 정했는지부터 다르게 설계될 수 있습니다. 검수 기준, 변경 절차, 하자 등급과 보수 기한, 인도·지급 조건, 중도 종료 정산을 서로 연결하면 분쟁이 생겼을 때 무엇을 확인해야 하는지 분명해집니다. 이미 문제가 발생했다면 계약 문구만 읽고 결론을 정하지 말고, 실제 요구사항·검수·수정 경과와 권리 행사 기간을 함께 대조해야 합니다.

※ 본 글은 일반적인 정보 제공을 목적으로 작성되었으며, 구체적인 법률 조언을 대체할 수 없습니다.

※ 개인의 상황에 맞는 정확한 법률 자문은 반드시 전문 변호사와 상담하시기 바랍니다.

※ 본문에는 이해를 위한 가상 사례를 사용하지 않았으며, 구체적인 상황에 따라 대응 방법과 결과는 달라질 수 있습니다.