[IT소송] 소프트웨어 용역계약 핵심 포인트, 어디까지가 ‘완료’인가?

[IT소송] 소프트웨어 용역계약 핵심 포인트, 어디까지가 ‘완료’인가?

Article posted in 2025-04-22 14:52:25 | VEAT

 

 

 

디지털 전환이 가속화되면서, 기업들은 자체 시스템 개발이나 앱 구축, 자동화 툴 도입 등을 위해 다양한 소프트웨어 용역계약을 체결하고 있습니다. 하지만 이러한 기술 기반 계약이 증가할수록, 계약 당사자 간의 법적 분쟁도 함께 늘어나고 있는 것이 현실입니다. 소프트웨어 용역계약에서 자주 발생하는 분쟁의 핵심은 “해당 용역을 완전히 수행하여 과업이 완료되었는지” 여부입니다. 즉, 소프트웨어 개발 및 구축이 완료되었다고 주장하는 개발자(또는 수급인)와, 여전히 미완성 상태라고 보는 발주자(또는 위탁인) 간의 입장 차이가 발생하는 경우입니다.

이러한 상황에서 분쟁 해결 여부를 좌우하는 핵심 요소는 바로 ‘검수 기준’입니다. 계약서에 과업의 범위가 아무리 구체적으로 명시되어 있더라도, 과업이 완료되었는지를 판단할 수 있는 명확한 기준이 부재할 경우에는, 분쟁을 사전에 예방하거나 사후에 해결하는 데 어려움이 따를 수밖에 없습니다. 특히 소프트웨어와 같은 무형의 결과물이 계약 대상인 경우, 그 성과가 물리적으로 확인되기 어렵기 때문에 ‘완성’의 개념 자체가 불명확해질 수 있으며, 이에 따라 검수 기준의 설정이 더욱 중요해집니다.

소프트웨어 용역계약의 시작부터 ‘완료’의 기준을 설정해야 합니다.

소프트웨어 용역계약을 체결할 때, 많은 기업이나 스타트업들이 기능 요구사항이나 개발 일정에는 집중하면서도, 정작 중요한 ‘완료’의 기준, 즉 검수 절차와 판단 기준 설정은 뒷전으로 미루는 경우가 많습니다. 하지만 현실적으로 가장 빈번히 발생하는 법적 분쟁은 검수 기준의 부재 또는 모호함에서 비롯됩니다.

계약이 체결되기 전, 발주자와 수급인은 어떤 상태를 ‘완료’로 볼 것인지를 구체적으로 합의하고, 그 내용을 계약서에 명시해야 합니다. 예컨대 아래와 같은 항목들이 명확히 설정되어야 합니다.

이처럼 완료 기준을 객관화한 검수 항목을 계약서 내에 명시하지 않을 경우, 발주자는 검수를 유보하며 잔금 지급을 미루게 되고, 수급자는 이를 두고 계약 위반 또는 부당한 대금 미지급이라 주장할 수 있어 갈등으로 이어집니다. 실제로 이러한 사안이 소송으로 이어지는 경우도 적지 않습니다.

결국 ‘완료’라는 개념은 양측이 구두나 관행에 의존해서 해석할 것이 아니라, 사전에 계약서상에서 구체적으로 정의해 놓는 것이 가장 확실한 분쟁 예방책입니다. 프로젝트가 종료되었는지를 둘러싼 불필요한 해석 차이를 막기 위해서라도, 검수 기준은 계약 초안 단계에서부터 반드시 설정되어야 할 필수 항목입니다.

소프트웨어 용역계약 검수 기준 구성 요소

검수 절차 및 기한

검수의 시작일, 검토 기간, 피드백 제출 기한, 수정 기한 등을 구체적으로 정해야 합니다. 예컨대, “납품 후 7일 이내 검수 진행, 발주자가 피드백을 서면으로 통지하며, 미통지 시 자동 검수 완료로 간주”와 같은 조항이 대표적입니다.

검수 테스트의 내용 및 방식

기능 테스트, 통합 테스트, UI/UX 검토, 성능 테스트 등 어떠한 테스트를 수행할 것인지, 그리고 어떤 도구나 환경에서 테스트할 것인지를 명시해야 합니다.

검수 완료의 판단 기준

테스트를 통해 발견된 버그의 허용 수준(예: 치명적 오류 없음, 경미한 UI 오류는 예외)이나, SLA(Service Level Agreement) 기준 등을 구체화합니다.

인도자료의 목록

소스코드, 실행파일, 사용자 매뉴얼, API 문서, 개발 가이드, 테스트 시나리오 등 인도 대상 자료들을 명확히 작성해야 합니다. 이는 ‘무엇을 인도하면 용역이 완료된 것으로 본다’는 판단의 근거가 됩니다.

소스코드, 언제 어떻게 인도받을지 명시해야 합니다.

소프트웨어 용역계약에서 결과물을 실제로 운영·관리할 수 있는 소스코드의 귀속과 전달 방식에 대해서는 명확한 규정을 두지 않아 향후 분쟁의 원인이 되곤 합니다. 그러나 소스코드는 단순한 산출물이 아닌, 유지보수와 향후 확장 개발의 기반이 되는 핵심 기술 자산입니다.

따라서 소스코드의 인도 시점을 ‘검수 완료일’ 또는 ‘잔금 지급일’ 등과 연동해 명확히 정하고, 디지털 파일이나 저장 매체, 혹은 코드 저장소 링크(Git 등) 형태로 전달하는 방식까지 구체화할 필요가 있습니다. 아울러 인도 범위에는 핵심 기능 소스코드뿐만 아니라 연동 API, 데이터베이스 설계서 등 필수 문서가 포함되어야 하며, 인도된 소스코드에 대해 자유롭게 수정하거나 재사용할 수 있는 권한까지 명시되어야 합니다.

이처럼 소스코드 인도와 그 범위, 권한 등에 대한 세부적인 계약 조항이 마련되어 있어야 추후 발생할 수 있는 소유권 분쟁, 유지보수 거부, 시스템 이전 거절 등의 리스크를 효과적으로 예방할 수 있습니다. 만약 이를 소홀히 할 경우, 개발사는 “단순 사용권만 제공했을 뿐, 소유권은 자신에게 있다”고 주장할 여지를 가질 수 있으며, 실제 법원도 계약서에 기재된 문언을 가장 우선적으로 판단 근거로 삼을 수 있습니다.

검수와 인도를 ‘과업 범위’로부터 분리해야 합니다.

소프트웨어 용역계약서를 작성할 때는 과업 범위(What), 검수 기준(How to approve), 소스코드 인도(When & How)를 하나의 포괄적인 문장으로 묶지 말고, 각각 독립된 조항으로 구분해 구체적으로 명시하는 것이 중요합니다. "웹사이트 개발 및 유지보수"처럼 과업 범위만 설정한 경우, 실제 프로젝트 종료 시점이나 결과물 인도 범위에 대한 해석 차이가 생기기 쉽고, 특히 검수 기준이나 인도 조건을 과업 범위에 포함된 요소로 간주할 경우, 그 판단 기준이 흐려질 수 있습니다.

검수 기준이 명확하지 않으면, 발주사는 품질에 문제가 있어도 이를 입증하기 어렵고, 개발사는 일정에 맞춘 인도를 근거로 용역 완료를 주장하게 됩니다. 하지만 계약서에 상세한 검수 절차와 테스트 방식이 기재되어 있다면, 발주사는 이를 근거로 기능 누락이나 오류에 대해 권리를 행사할 수 있습니다. 이러한 구조는 특히 플랫폼 중심의 비즈니스 모델이나, 추후 투자 유치 및 M&A를 계획하는 기업에게 기술자산의 귀속과 정당한 권리 확보를 위한 필수 요소입니다.

법무법인 비트는 다수의 소프트웨어 개발사 및 IT 스타트업과 협업하며 IT 프로젝트, 스타트업 플랫폼 개발 계약, 공공기관 시스템 구축 용역 등의 법률 자문을 수행한 경험을 바탕으로 전문적인 법률 자문을 제공합니다. 계약서를 단순히 ‘서명하는 문서’가 아닌, 당사의 기술 자산을 보호하는 방패로 만들기 위해 법률 자문은 필수입니다. 개발자와 발주자 모두가 안심하고 협업할 수 있는 기반은, 결국 명확하고 실효성 있는 계약서에서 시작됩니다. 소프트웨어 계약 관련 자문이나 검토가 필요하시다면, 언제든 법무법인 비트에 문의주시기 바랍니다.

감사합니다.

출처: https://www.veatlaw.kr/main/board_detail/1334