1. 들어가며

소프트웨어 개발은, 통상 소프트웨어를 사용하고자 하는 발주자(이하 ‘甲’이라고 합니다)가 소프트웨어 개발업자(이하 ‘乙’이라고 합니다)에게 자신이 원하는 소프트웨어의 개발 용역을 의뢰하고, 소프트웨어 개발업자는 자신이 직접 모든 소프트웨어 개발하거나, 다른 소프트웨어 개발업자(이하 ‘丙’이라고 합니다)에게 소프트웨어 개발의 일부 또는 전부를 다시 의뢰하는 형태로 업무가 진행됩니다. 본 논단에서는 먼저 甲과 乙 사이의 계약에 대하여 법적성격, 통상 발생하는 분쟁의 형태 및 그 해결모습에 대하여 간단히 소개하도록 하겠습니다.1)

2. 소프트웨어 개발공급계약의 법적성격 및 특징

소프트웨어 개발공급계약은 기본적으로 민법상의 도급계약으로 취급되고, 개별적인 계약의 내용은 계약 해석의 일반적인 방법에 따라 해석됩니다(아래 대법원 판례 참조).

“소프트웨어의 개발·공급계약이 통상 도급계약의 형태로 이루어지고 수급인이 그 일을 완성하면 미리 확정된 용역의 대가를 전액 지급하는 것이 일반적이라고 할지라도, 모든 소프트웨어의 개발·공급계약이 성질상 반드시 정액급의 보수 지급방식을 취하여야 하는 것은 아니고 개별계약의 구체적인 약정에 따라 얼마든지 보수지급의 방식을 달리하여 실제로 투입한 인력의 실적에 따라 용역대가를 지급하기로 약정할 수 있으며, 또한 일반적으로 계약내용을 해석함에 있어서는 당사자가 표시행위에 부여한 객관적 의미를 명백하게 확정하는 것이므로 먼저 서면의 기재 내용에 의하여 당사자가 표시행위에 부여한 객관적 의미를 합리적으로 해석하여야 할 것이고, 당사자가 표시한 문언에 의하여 객관적인 의미가 명확하게 드러나지 않는 경우에는 문언의 내용과 계약이 이루어지게 된 동기 및 경위, 당사자가 계약에 의하여 달성하려고 하는 목적과 진정한 의사, 거래의 관행 등을 종합적으로 고려하여 사회정의와 형평의 이념에 맞도록 논리와 경험의 법칙, 그리고 사회일반의 상식과 거래의 통념에 따라 합리적으로 해석하여야 한다(97다45259판결, 95다7932판결 등 참조).

”다만, 소프트웨어 개발공급계약의 특성상 甲은 개발과정에 참여하여 요구사항을 명확하게 전달하고 개발진행단계에 따라 프로그램의 내용을 구체화하거나 명백하게 할 계약상 또는 신의칙상 일정한 협력의무를 부담한다고 할 것입니다.2) 즉, 甲은 乙에게 생산관리, 판매관리, 인사관리 등 일련의 업무가 처리 가능한 소프트웨어를 개발해 달라고 요청하면, 乙이 그 기술력을 이용하여 개발할 수 있는 시스템의 내용 및 개발기간 등을 담은 제안서와 개발비용 등을 제시하는 절차를 거쳐 체결되고, 甲과 乙은 서로의 업무에 대하여는 비전문가이기 때문에 서로 의견교환이나 협상 과정에서 개발하여야 하는 소프트웨어의 내용이나 시스템 사양 등에 대한 인식의 차이가 생길 수 있으므로, 개별적인 소프트웨어 개발공급계약에서는 甲도 개발과정에 반드시 참여하여야 하기 때문입니다.

즉 소프트웨어 개발공급계약은 기본적으로 도급계약의 성질을 갖지만, 소프트웨어 개발공급계약 고유의 특성을 고려하여 구체적인 사안마다 개별적으로 해석되어야 할 것입니다.

3. 통상적인 분쟁의 형태 및 해결 모습

(가) 검수과정에서의 분쟁과 해결

도급계약의 경우 수급인(乙)은 도급받은 일을 완성할 의무가 있고, 도급인(甲)은 그 일의 결과에 대하여 보수를 지급할 의무가 있습니다(민법 제664조). 다만, 수급인(乙)은 일의 완성과 동시에 보수의 지급을 청구할 수 있는 것이 아니라, 목적물을 인도함과 동시에 도급인(甲)에게 보수의 지급을 청구할 수 있고(민법 제665조 제1항), 도급인(甲)은 일이 미완성인 경우 수급인(乙)의 채무불이행을 이유로 보수의 지급을 거절할 수 있습니다.

통상적인 소프트웨어 개발공급계약에서는 ‘목적물의 인도’를 ‘검수’라고 표현하면서, 甲이 ‘검수확인’을 마친 경우 乙에게 대금(주로 잔금)을 지급하는 내용으로 계약을 체결하게 됩니다.

검수 과정에서 甲은 개발된 소프트웨어에 기능장애가 있어 계약의 목적을 달성할 수 없다면서 검수확인을 지연하고, 乙에게 기능의 충족을 지속적으로 요청하면서 이러한 기능을 충족하지 않으면 계약을 해제하겠다고 주장하는 반면, 乙은 개발된 소프트웨어는 과업내역서 등을 기초로 볼 때 초기 계약상 합의된 부분은 완성되었다고 주장하면서, 기능충족이 되지 않는 것은 甲이 설계과정 등 개발과 관련하여 충분한 협조를 하지 않은 결과이고 오히려 甲이 최초 계약서에 없는 기능의 구현을 요청하여 이로 인해 투입비용이 증가되고 개발 일정이 제때 준수되지 못한 것이라고 주장하며 분쟁에 이르는 것이 보통입니다.

즉 乙의 입장에서는 소프트웨어 개발의 구체적인 설계, 분석과정을 통해 상세설계가 확정되면 계약의 목적물이 무엇인지 확정짓게 되지만, 甲의 입장에서는 이러한 상세설계 과정이 아니라 검수과정에 진입하여 소프트웨어가 구체적으로 구현되어 실제 작동되어서야 계약의 목적물이 완성되었는지 여부를 판단하게 되는 것이 현실이기 때문에, 결국 甲과 乙이 ‘일의 완성‘에 대하여 가지는 관념의 차이에서 분쟁이 비롯되는 것입니다.

그러나 일의 완성여부는 甲과 乙의 어느 일방적인 입장에서 쉽게 판단할 수 있는 문제가 아니므로, 위 문제가 소송에 이르게 되면 법원은 통상 감정을 실시하여 객관적인 관점에서 일의 완성여부를 판단하게 될 것입니다. 그리고 감정결과에 따라 법원은, (i)일이 미완성이라면 그 진척도에 따라 乙에게 어느 정도의 기성금을 인정할 수 있는가를 판단하고,3) (ii)일이 완성되었다면 甲의 계약해제를 배척하되, 甲이 하자보수에 갈음하는 손해배상금을 주장하는 경우 이러한 손해에 甲이 어느 정도 기여를 하였는가를 별도로 판단하여 잔금에서 적정 금액을 감액하는 방식으로 판단하게 될 것입니다.

(나) 검수완료 이후의 분쟁과 해결

수급인(乙)은 일의 완성 이후에도 상당기간 동안 도급인(甲)에 대하여 하자보수의무가 있고(민법 제667조 제1항 본문), 하자보수에 갈음하여 손해배상을 청구할 수도 있으며(민법 제667조 제2항), 완성된 목적물의 하자로 인하여 계약의 목적을 달성할 수 없는 때에는 건물 기타 공작물이 아니라면 계약을 해제할 수 있습니다(민법 제668조).

이에 甲은, 검수를 마치고 잔금지급을 한 이후, 개발된 소프트웨어를 사용하다 발견된 하자를 원인으로 乙에 대하여 계약을 해제하고 원상회복을 청구하기도 합니다.

그러나 위와 같은 경우는 이미 甲이 목적물의 완성 여부에 대하여 충분히 검증을 하여 잔금까지 지급하였기 때문에 완성된 목적물의 하자로 계약의 목적이 달성할 수 없는 경우라고 볼 수 없을 것이므로, 통상 계약의 해제나 원상회복은 인정되기 곤란할 것이고 하자보수나 이에 갈음하는 손해배상만이 인정될 것입니다.

4. 결론

이상에서는 소프트웨어 개발공급계약에 있어서 ‘검수’ 전후에 발생할 수 있는 일부 법적 쟁점과 그 해결모습을 민법규정 및 소프트웨어 개발공급계약의 특성에 비추어 살펴보았습니다. 그러나 소프트웨어 개발공급계약에서 일의 완성, 하자 등과 관련된 문제는 계약 체결의 단계에서 계약서상에 명백하게 약정하기 어려운 면이 있고, 이는 민법의 규정에 따라 일률적으로 다루어 질 수도 없습니다. 따라서 소프트웨어 개발공급계약과 관련된 여러 문제는 결국 개별 사안마다 당사자의 합의와 소프트웨어 개발공급계약의 특성 및 거래의 관행을 잘 살펴 합리적으로 해결되어야 할 것입니다. 

1)乙과 丙, 甲과 丙사이의 법률적 쟁점은 추후 다래 논단에서 검토하도록 하겠습니다.

2)東京地判 平成9. 9.24. 判タ 967号101頁. 소프트웨어 개발위탁계약에 있어서, 위탁자와 수탁자는 서로 협력해서 위탁의 내용을 확정시킬 계약상 및 신의칙상 의무를 부담한다고 판시.

3)대법원 1996. 7. 30. 선고 95다7932 판결: 전체적으로 87.87%의 완성도를 보이고 있고, 미완성 부분은 간단한 프로그램 수정, 직원 교육 등으로 보완될 수 있는 것이므로, 이미 완성된 부분이 피고회사에 이익이 되므로 원고에게 이미 완성된 부분에 대한 보수채권이 발생하였다고 판단함.