[계약분쟁 소프트웨어개발] 소프트웨어 개발공급 계약의 법적 성질과 분쟁 시의 입증 책임

소프트웨어 개발공급 계약은 통상 발주자와 개발자의 개별계약에 의하여 발주자가 원하는 업무상 목적을 위한 컴퓨터 프로그램을 제작하여 공급하는 형태입니다. 통상개발된 소프트웨어는 범용성이 없고 발주자의 업무상 목적만을 위한 것으로 부대체물의 성격을 가지고 있습니다. 이 경우에 대법원은 제작물 공급계약의 제작물이 부대체물인 경우에는 물건의 제작이 계약의 주목적이 되어 도급의 성질을 띠는 것이라고 판시한 바 있습니다(대법원 1996. 6. 28. 선고 94다42976 판결).

또한 컴퓨터 프로그램도 일종의 제작물이라고 볼 수 있고 해당 프로그램의 제작과 공급을 위해서는 수급인인 개발자의 노무에 의한 일의 완성이 필요합니다. 따라서통상 소프트웨어 개발공급 계약은 도급계약의 일종이라고 할 것입니다.

도급계약은 당사자 일방이 어느 일을 완성할 것을 약정하고 그 상대방이 그 일의 결과에 대하여 보수를 지급할 것을 약정함으로써 그 효력이 발생하는 쌍무계약입니다(민법 제664조). 수급인인 개발자는 도급인인 발주자의 주문사양에 따라 하자 없는 프로그램을 개발하여 공급할 채무가 있습니다. 즉, 개발자는 계약에서 정해진 내용의 일을 완성하고 완성물의 인도의무를 부담합니다. 이 때에 일의 완성 그 자체가 아니라 그 인도가 보수 지급과 동시이행관계가 있는 것이므로, 일의 완성의무는 선이행 의무에 해당합니다. 따라서 일이 미완성된 경우에는 수급인은 원칙적으로 보수의 지급을 청구할 수 없고 도급인은 일의 완성을 청구할 수 있으며 보수지급 자체를 거절할 수 있습니다.

이에 반하여 하자는 일의 미완성과는 구별되고, 일이 완성되고 인도되었으나 하자가 있는 경우 수급인인 개발자는 도급인인 발주자에게 보수의 지급을 청구할 수 있습니다. 다만, 도급인은 원칙적으로 하자담보책임을 물어 하자보수청구권을 행사하여 하자부분의 보수 또는 그에 갈음하는 손해배상을 청구할 수 있습니다. 따라서 도급인은 하자가 있다는 이유만으로 보수의 지급을 거절할 수 없습니다(대법원 1994. 9. 30. 선고 94다32986 판결).

대개의 소프트웨어 개발공급 분쟁은 일의 완성 여부와 하자 등의 문제로 발생합니다. 이 때에 수급인인 개발자는 일이 완성되었다는 점을 먼저 입증해야만 보수의 지급이 인용될 수 있습니다. 이에 반하여 완성된 목적물에 하자가 있는 경우에는 하자의 존부 여부는 담보책임(하자보수청구권 또는 손해배상청구권)의 요건으로 도급인인 발주에게 주장 및 입증의 책임이 있습니다.

따라서 통상 약자에 해당하는 수급인인 개발자가 보수지급 등을 청구하는 소송을 제기하는 경우에 일이 완성되었자는 점을 입증하여야 하는 불리함이 있다는 점을 인식하고 개발과정에서 발주자의 요구사양을 완성하였다는 점을 일지 형태로 계속 기재하고 주요 사양의 완성 여부는 도급인에게 확인을 받아 두는 것도 필요하다고 보입니다. 이에 반하여 도급인인 발주자는 보수지급 전에 일의 완성 여부를 다투거나 보수지급 후에 하자보수청구 또는 손해배상소송의 경우를 대비하기 위하여 계약서 또는 별도 서면으로 미리 요구사양을 구체적으로 작성하여 수급인이 인도한 프로그램에 요구사양에 기재된 기능이 없어 일이 완성되지 못하였다거나 기능이 제대로 작동하지 않거나 성능이 미흡하다는 등의 하자를 주장입증할 수 있어야 합니다.

정회목 변호사

[소프트웨어 용역분쟁] 소프트웨어 개발공급 용역 계약에서 해당 소프트웨어의 완성 여부에 대한 판단의 기준

소프트웨어 개발공급을 위해서는 통상 발주자인 도급인과 개발자인 수급인 간의 계약을 맺게 됩니다. 위 계약서(과업내역서)에는 발주자가 원하는 소프트웨어의 구성, 성능, 사양, 개발 언어 등을 구체적으로 기재하여야 합니다. 설계도에 의하여 발주자가 원하는 건축 목적물을 구체적으로 특정할 수 있는 건축도급계약과는 달리 소프트웨어 개발계약은 위와 같이 발주자가 원하는 기능과 구성 등을 구체적으로 적시하고 이에 대하여 개발자와 협의하여 개발자인 수급인의 이행 범위를 확정하여야 합니다. 이 경우에 대금의 지급 등의 분쟁이 발생하게 된다면, 수급인이 계약상 이행 범위를 모두 완료하여 일(소프트웨어)을 완성하였는지 여부가 다투어지게 됩니다. 아래에서 소프트웨어의 완성에 대하여 다른 도급계약의 사례를 참조하여 소프트웨어 완성의 기준에 대하여 살펴보겠습니다.

건축 도급계약과 관련하여 대법원은 “공사가 도중에 중단되어 예정된 최후의 공정을 종료하지 못한 경우에는 공사가 미완성된 것으로 볼 것이지만, 공사가 당초 예정된 최후의 공정까지 일응 종료하고 그 주요 구조 부분이 약정된 대로 시공되어 사회통념상 일이 완성되었고 다만 그것이 불완전하여 보수를 하여야 할 경우에는 공사가 완성되었으나 목적물에 하자가 있는 것에 지나지 아니한다고 해석함이 상당하고, 예정된 최후의 공정을 종료하였는지 여부는 수급인의 주장이나 도급인이 실시하는 준공검사 여부에 구애됨이 없이 당해 공사 도급계약의 구체적 내용과 신의성실의 원칙에 비추어 객관적으로 판단”할 수밖에 없다고 판단하였습니다(대법원 1997. 10. 10. 선고 97다23150 판결).

말씀드린 바와 같이 소프트웨어 개발공급계약에서는 건축과는 달리 구체적인 설계도가 없으므로 도급인이 구체적인 개발요구사항을 수급인에게 전달하여야 수급인이 개발해야 할 내역이 확인될 수 있습니다. 또한 수급인도 도급인과 협의하거나 조언하여 개발에 필요한 변경사항을 요구할 수 있고 이러한 협의 과정을 거쳐 계약의 구체적인 내용을 확정하게 됩니다.

그러므로 도급계약의 일의 완성에 해당하는 소프트웨어의 완성 여부는 당사자 사이에 합의된 객관적인 계약 내용을 이행해야 할 것이고, 대법원의 법리에 의하면 소프트웨어 개발공급계약에서 일의 완성은 당초 예정된 최후의 공정까지 일단 종료하였다는 점만으로는 부족하고 목적물의 주요 구성 및 기능이 약정된 대로 개발되어 사회통념상 일반적으로 요구되는 성능을 갖추고 있어야 한다고 보입니다(대법원 2006. 10. 13. 선고 2004다21862 판결 참고).

따라서 소프트웨어 개발공급계약에서 일이 완성되었다는 사실이 인정되려면, 객관적인 계약의 내용과 사회통념상으로 예정된 최후의 공정이 종료되고 목적물의 주요 구성 및 기능이 약정대로 개발되고 일반적으로 요구되는 성능을 갖추었다는 사실을 입증하여야 합니다. 그리고 일의 완성은 수급인의 책임이므로 위와 같은 일의 완성 여부에 대한 입증책임은 수급인인 개발자에게 있습니다.

소프트웨어 개발 용역 사업을 하는 개발회사가 위와 같은 사항들을 참조하여 업무에 적용한다면, 발주자와의 분쟁의 발생을 줄일 수 있고 대금의 지급도 담보할 수 있을 것입니다.

정회목 변호사