칼럼 및 연구자료

소프트웨어 개발계약은 납품 또는 서비스 오픈으로 모든 절차가 끝나는 계약이 아닙니다.

오히려 프로젝트 완료 이후 오류 수정, 기능 보완, 성능 미달, 추가 요청의 범위를 둘러싸고 분쟁이 본격화되는 경우가 적지 않습니다. 그 중심에는 대체로 하자담보책임 문제가 있습니다.

소프트웨어는 일반 제조물과 달리 결과물이 무형이고, 기능 범위나 완성 기준이 문서에 따라 달라질 수 있습니다. 같은 문제라도 발주사는 “원래 구현되었어야 할 사항”이라고 보고, 개발사는 “계약 범위를 벗어난 추가 요청”이라고 보는 경우가 많습니다. 결국 분쟁의 핵심은 단순히 오류가 발생했는지 여부가 아니라, 그 문제가 계약상 하자인지 아닌지를 판단할 기준이 계약서와 관련 문서에 명확히 정리되어 있는지에 달려 있습니다.

소프트웨어 개발계약에서 하자담보책임이 문제되는 이유

소프트웨어 개발계약은 일반적으로 도급계약의 성격을 가집니다. 개발사인 수급인은 약정된 결과물을 완성할 의무를 부담하고, 발주사인 도급인은 그 결과물에 대한 보수를 지급하는 구조입니다. 이때 하자담보책임이란, 완성된 결과물이 계약 내용에 부합하지 않을 경우 수급인이 일정 범위에서 이를 보수할 책임을 지는 것을 말합니다.

문제는 소프트웨어 분야에서는 “완성” 자체의 기준이 불명확한 경우가 많다는 점입니다. 기능 일부가 구현되지 않았거나, 오류가 발생하거나, 기대한 성능에 미치지 못한 경우에도 그것이 곧바로 계약상 하자로 인정되는 것은 아닙니다. 해당 문제가 하자인지 여부는 결국 계약서, 기능 명세서, 요구사항 정의서, 테스트 기준, 검수 문서에 따라 판단되게 됩니다.

즉, 소프트웨어 개발 분쟁은 기술적 문제처럼 보이지만, 실제로는 계약 문서가 어디까지 구체적으로 작성되어 있었는지에 따라 결론이 달라지는 경우가 많습니다.

버그가 있으면 바로 계약을 해제할 수 있을까?

소프트웨어에 오류나 결함이 있다고 해서 언제나 곧바로 계약 해제가 가능한 것은 아닙니다. 민법 제668조는 하자로 인해 계약의 목적을 달성할 수 없는 경우 도급계약의 해제를 인정하고 있으나, 실무상 법원은 하자의 중대성, 보수 가능성, 계약 목적 달성 가능성을 종합적으로 고려하여 판단하고 있습니다.

대법원도 다음과 같이 판시한 바 있습니다.

“하자가 중대하고 보수가 불가능하거나 가능하더라도 장기간을 요하는 등 계약해제권을 행사하는 것이 정당하다고 인정되는 경우를 의미한다 할 것이고, 단지 도급인이 상당한 기간을 정하여 하자의 보수를 청구하였음에도 수급인이 그 하자를 보수하지 않는다는 사정만으로 계약해제권을 행사할 수는 없다.”
— 대법원 2010. 6. 10. 선고 2010다10252 판결

즉, 단순히 버그가 존재한다는 사정이나 보수가 지연되었다는 사정만으로는 계약 해제가 당연히 인정되기 어렵습니다. 핵심은 해당 문제가 계약 목적을 달성할 수 없을 정도의 중대한 하자인지, 그리고 보수로 회복 가능한 상태인지 여부입니다.

하자와 추가 개발 요청은 어떻게 구별될까?

실무상 가장 빈번하게 분쟁이 발생하는 지점은, 발주사가 요구하는 수정 사항이 하자보수 대상인지, 아니면 별도의 추가 개발 요청인지를 구별하는 문제입니다.

예를 들어 계약서와 기능 명세서에 이미 포함된 기능이 정상적으로 구현되지 않았거나, 합의된 성능 기준에 미달하거나, 검수 기준을 충족하지 못한 경우라면 일반적으로 하자 문제로 볼 가능성이 높습니다.

반면 계약 체결 이후 새롭게 추가된 운영 정책, 기능 확대 요구, 사용자 편의 개선, UI/UX 변경 요청 등은 원칙적으로 별도 개발 또는 추가 용역으로 평가될 여지가 큽니다.

이러한 구분은 추상적으로 정리해서는 부족합니다. 실무에서는 다음과 같은 기준을 계약 단계에서 문서화해 둘 필요가 있습니다.

• 해당 기능이 계약서나 제안서, 명세서에 이미 포함되어 있는지
• 요구사항 정의서상 예정된 동작이나 성능을 충족하지 못했는지
• 검수 당시 합의된 테스트 시나리오를 통과하지 못했는지
• 프로젝트 이후 발주사의 정책 변경이나 신규 요구로 발생한 사항인지

이 경계가 불명확할수록, 발주사는 하자보수를 주장하고 개발사는 추가 비용을 주장하게 되어 분쟁이 커질 가능성이 높습니다.

분쟁 예방을 위한 계약서 작성 포인트

소프트웨어 개발계약의 하자담보책임 분쟁은 대부분 계약상 기준이 불명확할 때 확대됩니다. 따라서 계약 단계에서 아래 사항을 구체적으로 정해두는 것이 중요합니다.

1. 기능 명세서 및 요구사항 정의서의 구체화

무엇을 개발하기로 했는지, 어떤 기능과 범위가 포함되는지, 어떤 성능을 목표로 하는지를 문서로 명확히 확정해 두어야 합니다.
추후 분쟁이 발생할 경우 하자 여부를 판단하는 가장 중요한 기준이 됩니다.

2. 검수 기준 및 절차의 명시

완성 여부를 어떤 기준으로 판단할 것인지, 검수 기간은 얼마인지, 이의 제기는 어떤 방식으로 해야 하는지 계약서에 구체적으로 기재해야 합니다.
검수 기간 내 이의를 제기하지 않은 경우의 효과, 보완 요청 절차, 재검수 방식까지 함께 규정해 두는 것이 바람직합니다.

3. 하자보수 기간 및 범위의 설정

어떤 경우를 하자로 볼 것인지, 무상보수 기간은 언제까지인지, 어느 범위까지 보수 의무를 부담하는지 명확히 정리해야 합니다.
특히 운영 환경의 변경, 제3자 솔루션 문제, 발주사 측 자료 오류 등 책임 제외 사유도 함께 검토할 필요가 있습니다.

4. 변경 요청 및 추가 개발의 처리 기준 마련

계약 체결 이후 발생하는 요구사항이 하자보수 대상인지, 별도 유상 개발인지 구별하는 기준을 사전에 마련해야 합니다.
실무에서는 변경 요청서, 승인 절차, 일정·비용 조정 방식까지 함께 두는 것이 분쟁 예방에 도움이 됩니다.

5. 관련 문서 간 우선순위의 정리

계약서, 제안서, 기능 명세서, 요구사항 정의서, 회의록, 이메일 등 여러 문서가 혼재하는 경우가 많기 때문에, 문서 간 충돌 시 어떤 문서를 우선 적용할 것인지 정해 두는 것이 중요합니다.
이 부분이 빠져 있으면 사후적으로 각자 유리한 문서를 근거로 주장하게 되는 경우가 많습니다.

소프트웨어 개발계약 시 실무상 유의해야 할 점

소프트웨어 개발계약의 하자담보책임 문제는 단순히 결과물의 완성도가 높고 낮은지를 평가하는 문제가 아닙니다.

실제로는 무엇을 만들기로 했는지, 어떤 상태를 하자로 볼 것인지, 보수 의무는 언제까지인지, 추가 요청은 어떤 절차로 처리할 것인지가 계약서와 관련 문서에 충분히 정리되어 있는지가 핵심입니다.

계약서 문언만으로는 드러나지 않는 리스크도 적지 않습니다. 실제 개발 방식, 기능 정의 구조, 테스트 흐름, 검수 절차를 함께 검토해야 비로소 확인되는 쟁점들이 존재합니다.

따라서 소프트웨어 개발계약은 일반적인 법률 검토만으로 접근하기보다, 기술 구조와 프로젝트 운영 방식까지 함께 고려한 실무형 검토가 필요합니다.

법무법인 비트의 IT 특화 법무 서비스

법무법인 비트는 IT를 전공한 변호사들이 함께 설립한 부티크로펌으로, 서울대학교 컴퓨터공학과 출신 최성호 대표변호사, 대한변호사협회 인증 IT전문변호사 백승철 파트너 변호사, 안일운 파트너 변호사를 비롯하여, 공학적 배경을 갖춘 변호사들로 구성된 IT법무팀을 운영하고 있습니다.

소프트웨어 개발계약, 하도급계약, 기능 변경·추가 개발 분쟁, 검수 기준 설계, 하자보수 범위 설정 등 다양한 IT 분쟁 자문 경험을 바탕으로, 계약 체결 단계부터 분쟁 예방을 위한 구조 설계를 지원하고 있습니다. 특히 기능 명세서 작성, 검수 절차 수립, 하자와 추가 개발의 구분 기준 설정, 책임 배분 조항 정비 등 실제 프로젝트 운영 과정에서 문제되는 지점을 중심으로 한 실무형 자문을 제공합니다.

소프트웨어 개발계약서 및 관련 하자담보책임과 관련하여 자문이 필요하신 경우, 법무법인 비트로 문의하시기 바랍니다. 

감사합니다.