민법 제544조(이행지체와 해제)당사자 일방이 그 채무를 이행하지 아니하는 때에는 상대방은 상당한 기간을 정하여 그 이행을 최고하고 그 기간내에 이행하지 아니한 때에는 계약을 해제할 수 있다. 그러나 채무자가 미리 이행하지 아니할 의사를 표시한 경우에는 최고를 요하지 아니한다.
계약서의 해제조항 - ‘채무불이행이 있으면 계약 해제된다’는 표현은 약정해제가 아니라 법정해제권을 주의적 규정에 불과한 것으로 해석될 수 있음
원칙적으로 이행제공, 이행 최고 후 계약 해제 가능
2.계약서의 해제조항 및 약정해제권
대법원 2016. 12. 15. 선고 2014다14429, 14436 판결
(1)계약에 특별히 해제권 관련 조항을 둔 경우 이는 법정해제권을 주의적으로 규정한 것이거나 약정해제권을 유보한 것 등 다양한 의미가 있을 수 있다.
(2)약정해제권을 유보한 경우에도 계약 목적 등을 고려하여 특별한 해제사유를 정해 두고자 하는 경우가 있고, 해제절차에 관하여 상당한 기간을 정한 최고 없이 해제할 수 있도록 한 경우 등도 있다.
(3)당사자가 어떤 의사로 해제권 조항을 둔 것인지는 결국 의사해석의 문제로서, 계약체결의 목적, 해제권 조항을 둔 경위, 조항 자체의 문언 등을 종합적으로 고려하여 논리와 경험법칙에 따라 합리적으로 해석하여야 한다.
(4)다만 해제사유로서 계약당사자 일방의 채무불이행이 있으면 상대방은 계약을 해제할 수 있다는 것과 같은 일반적인 내용이 아니라 계약에 특유한 해제사유를 명시하여 정해 두고 있고, 더구나 해제사유가 당사자 쌍방에 적용될 수 있는 것이 아니라 일방의 채무이행에만 관련된 것이라거나 최고가 무의미한 해제사유가 포함되어 있는 등의 사정이 있는 경우에는 이를 당사자의 진정한 의사를 판단할 때 고려할 필요가 있다.
(5)갑 주식회사와 을이 금형 제작에 관한 도급계약을 체결하면서 작성한 도급계약서에 ‘갑 회사는 을이 계약을 위반하여 기간 내에 제작을 완료할 수 없는 경우에 계약을 해제할 수 있다’는 조항을 두었는데, 을이 납품기한이 지나도록 납품을 하지 못하자 갑 회사가 이행 최고 없이 곧바로 계약해제를 통보한 사안에서, 제반 사정에 비추어 위 조항은 단순히 채무불이행으로 인한 법정해제권을 주의적으로 규정한 것이 아니라 특유한 해제사유를 정하고 해제절차에서도 최고 등 법정해제권 행사의 경우와 달리 정하고자 하는 당사자의 의사가 반영된 것이라고 볼 여지가 있는데도, 갑 회사의 계약해제가 법정해제권의 행사요건을 갖추지 못하여 효력이 없다고 본 원심판단에 법리오해 등의 잘못이 있다.
컴퓨터프로그램 소프트웨어의 개발납품 계약은 도급계약으로, 개발자(수급자)가 프로그램개발을 완성하여 납품하면 발주자가 그 보수, 용역대금을 지급하는 계약입니다. 개발자가 완성하여 납품하는 기준, 발주자가 요구하는 개발요구사항, 개발자의 개발범위를 명확하게 정하는 것이 매우 중요합니다. SW 개발공급계약서에서 프로그램의 목적과 기능을 구체적으로 특정하고, 해당 분야를 이해하는 개발자, 전문가의 검토를 거쳐 개발요구사항 및 개발범위를 기능별, 항목별로 구체적으로 정리하는 것이 바람직하고, 독립된 별지로 정리하여 첨부하면 분쟁을 예방할 수 있습니다. 원칙적으로 수급인 개발자는 개발완성을 입증할 책임 있고, 완성해야 보수(개발대금)을 청구할 수 있습니다.
프로그램개발의 완성 또는 미완성 판단기준: 소프트웨어 개발납품 계약서에서 정한 기준,예를 들어 개발요구사항 명세서, 개발범위 등에 따라 완성여부를 판단합니다. 계약서 문언에 따라 계약에 포함되어 있는 사양과 기능을 갖춘 제품의 개발, 그 이행 제공, 관련한 자료, 당시 관련 당사자들의 태도 등 제반 사정을 종합하여 판단합니다.
2.개발납품 완료 후 하자보수 vs 미완성의 구별
소프트웨어 개발공급계약에서 미완성에 대해서는 대금지급거절, 채무불이행으로 인한 계약해제 또는 계약해지가 문제되지만, 완성, 납품 후에는 발주자는 용약대금지급 의무가 있고 다만 개발자에 대한 하자보수요구가 문제됩니다.
소프트웨어 프로그램 개발 및 공급계약에서 일의 완성으로 보려면 계약상 예정된 최후의 공정까지 종료하였음과 함께 프로그램의 주요기능 부분이 약정된 대로 개발되어 사회통념상 일반적으로 요구되는 성능을 갖추고 있어야만 합니다. 또한 계약상 예정된 최후의 공정이 종료하였는지 여부는 개발자 수급인의 주관적인 주장이 아니라 개발 및 공급계약의 구체적 내용과 신의성실의 원칙에 비추어 객관적으로 판단해야 합니다.
개발자가 소프트웨어 개발의 일을 완성하고 이를 인도하면 발주자는 해당 소프트웨어 프로그램이 계약상 사양과 내용대로 완성되었는지 점검하여 수령하게 되는데, 법원은 제작물공급계약에서 목적물의 인도는 완성된 목적물에 대한 단순한 점유의 이전만을 의미하는 것이 아니라 도급인이 목적물을 검사한 후 그 목적물이 계약내용대로 완성되었음을 명시적 또는 묵시적으로 시인하는 것까지 포함한다고 봅니다.
그런데, 실무상 개발 납품한 프로그램이 계약상 요구사항을 모두 충족하였지만 발주자가 원하는 성능을 충분히 구현하지 못한다고 불만을 표시하면서 개발대금을 지급하지 않고 과도하게 보완을 계속 요구하는 경우가 있습니다. 이와 같은 하자 주장은, 법적으로 일의 완성과는 구별되는 다른 개념입니다. 하자가 있더라도 일이 완성되었다면 수급인은 도급인에게 보수의 지급을 청구할 수 있습니다.
하자여부도 일의 완성여부 판단, 그 완성도의 판단기준이 매우 중요합니다. 계약서에서 요구사항 각 항목을 특정하고, 목적하는 기능, 사용용도, 개발동기 등 배경사실을 기재하였거나 프로그램의 기능이 어떻게 구현되어야 하는지 등을 구체적으로 기재해 두었다면 완성여부 및 완성도를 판단하는데 큰 문제가 없을 것입니다.
발주자 도급인은 하자보수청구권을 가지므로 하자담보책임에 기한 항변을 행사하여 하자에 대한 보수 또는 그에 갈음하는 손해배상의 지금에 대한 대금의 지급을 거절할 수 있습니다. 그러나 하자를 이유로 대금 전부의 지급을 거절할 수는 없습니다.
정리하면, 발주한 소프트웨어 프로그램의 개발이 미완성인 때에는 대금지급을 거절할 수 있지만, 완성되었으나 하자가 있는 경우에는 발주자 도급인은 일의 완성을 요구하면서 대금지급을 거절할 수는 있습니다. 다만, 하자의 정도에 따라 대금감액 또는 손해배상을 청구할 수는 있습니다.
3.소프트웨어 프로그램의 완성, 납품 후 하자보수 또는 추가 개발계약
소프트웨어 개발 및 공급의 도급계약에 있어서의 하자는 완성된 일이 계약에서 정하거나 보증한 내용이 아니거나, 그 경제적 사용가치 또는 교환가치를 감소시키는 결함이 있거나, 또는 당사자가 미리 정한 사양 또는 기능을 가지지 못하는 등 결함을 말합니다. 그러나 하자의 정의는 모호하고 추상적이라 개별 사건마다 당사자간의 계약 내용을 검토하는 것이 중요합니다. 또한 계약상 합의된 사양과 내용과 함께 통상적인 용도에 적합한지 여부도 중요한 기준입니다.
납품 및 검수 후의 소프트웨어 버그에 대한 리포트를 받고 이를 즉시 보수하거나 도급인과 협의하여 상당한 조치를 취한 때에는 하자라고 보지 않을 것입니다. 그러나 도급인이 요구하는 구체적인 업무나 기능이 제대로 작동되지 않는 경우, 통신 및 인터넷과 연계된 컴퓨터 프로그램이 통신 및 네트워크와 연결하여서는 제대로 작동되지 않은 경우나, 컴퓨터 안에 보존된 다른 데이터 등을 잃어 버리는 경우 등은 하자에 해당합니다.
최초의 개발범위를 벗어난 추가 개발요구사항이 있는 경우 계약범위를 변경하는 추가 합의서를 첨부하거나 별도의 추가 개발계약을 체결할 수 있습니다. 추가 개발사항을 명시적으로 정리한 변경계약서 또는 추가 계약서가 없다면 기존 계약범위 내인지 추가 개발인지 여부가 불명확하여 분쟁의 소지가 있습니다. 추가 개발서를 별도 서면으로 작성하면, 추가개발에 대하여 상호 진지하게 고민하게 될 것이고, 그 추가 개발사항에 대한 분쟁도 줄어들 수 있습니다. 이때 추가 개발사항으로 개발비용이 추가되는지 여부도 명확하게 결정해야 합니다. 그렇지 않으면 추가 비용의 부담에 관한 분쟁원인이 될 것입니다.
4.완성 전 중간점검, 중도해지, 계약변경 시 입증자료
컴퓨터 프로그램의 납품 후 계약에 따른 완성 여부를 다투거나 하자를 다투는 것보다 중간에 미리 점검하고 확인하는 것이 바람직합니다. 개발단계에 따라 단계별로, 또는 모듈별로 개발정도를 점검하거나 또는 기간에 따라 정기적으로 점검하는 것이 바람직합니다. 만약 당초 계약내용을 변경하거나 수정, 보완해야 한다면 중도에 추가 계약서를 작성하는 등 명시적 자료를 남기는 것이 좋습니다.
개발공급계약서에 개발진도 점검, 검수, 중도 계약해지에 대한 조건 등을 명확하게 규정하는 것이 좋습니다. 중간단계 완성여부, 점검, 검수기준을 정해두고, 기준 미충족 시 중도 해지조건까지 정해두지 않으면 상호간 자기 주장만 하고 진행되지 않는 난관에 봉착합니다. 어떤 경우에 계약해제 또는 해지를 할 수 있는지, 그 경우 어떻게 정산을 할지 명확하게 정리하는 것이 바람직합니다.
5.개발 결과물의 납품 방식 및 저작권 귀속 사항
개발결과물을 어떤 방식으로 납품할 것인지, 그 결과물의 저작권 귀속에 대해 명확하게 정해 두어야 합니다. 통상 사용하는 SW 소유권 뿐만 아니라 그 저작권, 사용권을 갖는다는 점을 명확하게 정리하는 것이 필요합니다. 특히 당해 계약의 산출물인지 아니면 기존에 보유하고 있던 솔루션까지 포함한 것인지 등 명확하지 않으면 분쟁의 소지가 있습니다.
(1)소프트웨어 개발·공급계약은 일종의 도급계약으로서 수급인은 원칙적으로 일을 완성하여야 보수를 청구할 수 있다.
(2)다만 도급인에게 이미 공급되어 설치된 소프트웨어 완성도가 약간의 보완을 가하면 업무에 사용할 수 있을 정도에 달하였다면, 이미 완성된 부분이 도급인에게 이익이 된다고 할 것이므로, 계약관계가 도급인의 해제통보로 중도에 해소되는 경우에라도 수급인은 당시까지의 보수를 청구할 수 있다(대법원 1996. 7. 30. 선고 95다7932 판결 참조).
(3)이미 공급되어 설치된 소프트웨어 완성도가 약간의 보완을 가하면 업무에 사용할 수 있을 정도에 달하였고, 이미 완성된 부분이 도급인에게 이익이 된다고 보이므로, 원고들은 피고에게 중단된 시점까지의 보수를 청구할 수 있다고 봄이 타당하다.
2.감정 결과의 중요성 – 기성고 인정 및 정도 판단
(1)감정인의 감정 결과는 그 감정 방법 등이 경험칙에 반하거나 합리성이 없는 등의 현저한 잘못이 없는 한 이를 존중하여야 한다(대법원 2009. 7. 9. 선고 2006다 67602, 67619 판결, 대법원 2012. 1. 12. 선고 2009다84608, 84615, 84622, 84639 판결 등 참조).
(2)감정 결과에 의하면, 시스템 완성도는 이 사건 계약을 인프라, 패키지, in-house ERP로 나누어 보았을 때 인프라는 99.9%, 패키지는 100%, in-house ERP는 87.3%이고, 계약 금액 비율에 따라 가중치로 계산한 전체 완성도는 95.8%인바, 원고들은 직접 개발하여야 하는 in-house ERP 부분을 제외한 나머지 하드웨어, 소프트웨어 등을 모두 공급한 것으로 보이며, in-house ERP 부분의 완성도만 보더라도 87.3%에 이른다.
(3)감정인은 미완성된 이 사건 시스템을 완성하겠다는 제3의 개발자가 존재할 수 있는지 여부, 제3자에 대한 프로그램의 전체 구조 및 기능들에 대해 교육을 최소화한 상태에서도 개발이 가능한 것인지 여부 등 현실적인 어려움을 최대한 고려하여 보더라도 원고들이 개발에 사용한 언어와 개발 프레임워크의 범용성이 높고 만들어진 산출물의 완성도가 높아 다른 용역 수행자를 선정해서 이 사건 시스템을 완성할 수 있을 것이라 평가하였다.
3.기성고 인정 시 개발대금 인정 범위 – 감정 중요
(1)계약은 기존 시스템을 대체하는 새로운 시스템을 구축하는 것을 목표로 하는 계약이고, 개발 완료가 인정되기 위해서는 피고의 장비에 소프트웨어 및 응용 소프트웨어를 내장하는 것뿐만 아니라 피고 또는 피고가 지정하는 사람의 검사에 합격한 후 정상적인 서비스가 가능하도록 기능을 갖추어야 한다. 즉, 이 사건 시스템의 완성도를 평가하기 위해서는 소프트웨어 자체의 완성도뿐만 아니라 실제 소프트웨어를 적용하였을 때 그 사용에 장애가 될 정도의 오류 없이 정상적인 서비스 제공이 가능한지를 알 수 있어야 하는데, in-house ERP 시스템 완성도는 원고들과 피고가 이 사건 시스템 개발을 위해 상정한 5단계 공정 중 3단계인 구현 단계에 해당하고, 그 이후의 통합 테스트 단계나 이행 및 안정화 단계는 in-house ERP 시스템이 제대로 운용 가능한지 여부 등을 검토하는 단계이므로, 결국 이 사건 계약에서 상정한 원고들의 용역업무 수행 정도는 공정별 완성도를 고려하여 판단함이 타당하다.
(2)감정인은 이 사건 시스템의 완성도와 관련하여 원고들이 직접 용역 업무를 수행한 부분에 해당하는 in-house ERP 부분을 87.3%라 감정하였다.
(3)감정인의 감정 결과가 경험칙에 반하거나 합리성이 없는 등 현저한 잘못이 있다고 인정하기에 부족하고, 달리 이를 인정할 증거가 없다.
4.지체상금 인정 및 감액 여부
(1)수급인이 완공 기한 내에 공사를 완성하지 못한 채 완공 기한을 넘겨 도급계약이 해제된 경우에 있어서 그 지체상금 발생의 시기는 완공 기한 다음 날이고 종기는 수급인이 공사를 중단하거나 기타 해제 사유가 있어 도급인이 이를 해제할 수 있었을 때를 기준으로 하여 도급인이 다른 업자에게 의뢰하여 같은 건물을 완공할 수 있었던 시점이다(대법원 1999. 10. 12. 선고 99다14846 판결, 대법원 2001. 1. 30. 선고 2000다56112 판결 등 참조).
(2)지체상금에 관한 약정은 수급인이 그와 같은 일의 완성을 지체한 데 대한 손해배상액의 예정이므로, 수급인이 약정된 기간 내에 그 일을 완성하여 도급인에게 인도하지 아니하여 지체상금을 지급할 의무가 있는 경우, 법원은 민법 제398조 제2항의 규정에 따라 계약 당사자의 지위, 계약의 목적과 내용, 지체상금을 예정한 동기, 실제의 손해와 그 지체상금액의 대비, 그 당시의 거래 관행 및 경제 상태 등 제반 사정을 참작하여 약정에 따라 산정한 지체상금액이 일반 사회인이 납득할 수 있는 범위를 넘어 부당하게 과다하다고 인정하는 경우에 이를 적당히 감액할 수 있는 것이다(대법원 1999. 10. 12. 선고 99다14846 판결, 대법원 2002. 9. 4. 선고 2001다1386 판결 등 참조).
(3)비록 변경 계약 체결에까지 이르지는 못하였으나 피고도 계약 기간을 연장하게 되면 위약금 약정을 두는 조건 하에 지체상금을 감면하여 주려고 하는 등 원고들의 용역 업무 수행 지연을 어느 정도 양해하고 있었던 것으로 보이는 점, ③ 이 사건 시스템의 완성 여부를 판단하기 위한 목적이었다고는 하나 피고의 네트워크 차단으로 인해 원고들의 업무 수행이 지연되기도 하였고, 이 사건 계약에 따른 정당한 요구였다고 하더라도 피고의 요구로 인해 원고들의 업무가 어느 정도 영향을 받았을 것으로 보이는 점 등에 비추어 보면, 이 사건 계약의 지체상금약정에 따라 단순히 계산한 지체상금은 부당히 과다하다고 할 것이므로, 원고들이 부담할 금액을 위 지체상금의 70%로 제한한다.
