민법 제544조(이행지체와 해제)당사자 일방이 그 채무를 이행하지 아니하는 때에는 상대방은 상당한 기간을 정하여 그 이행을 최고하고 그 기간내에 이행하지 아니한 때에는 계약을 해제할 수 있다. 그러나 채무자가 미리 이행하지 아니할 의사를 표시한 경우에는 최고를 요하지 아니한다.
계약서의 해제조항 - ‘채무불이행이 있으면 계약 해제된다’는 표현은 약정해제가 아니라 법정해제권을 주의적 규정에 불과한 것으로 해석될 수 있음
원칙적으로 이행제공, 이행 최고 후 계약 해제 가능
2.계약서의 해제조항 및 약정해제권
대법원 2016. 12. 15. 선고 2014다14429, 14436 판결
(1)계약에 특별히 해제권 관련 조항을 둔 경우 이는 법정해제권을 주의적으로 규정한 것이거나 약정해제권을 유보한 것 등 다양한 의미가 있을 수 있다.
(2)약정해제권을 유보한 경우에도 계약 목적 등을 고려하여 특별한 해제사유를 정해 두고자 하는 경우가 있고, 해제절차에 관하여 상당한 기간을 정한 최고 없이 해제할 수 있도록 한 경우 등도 있다.
(3)당사자가 어떤 의사로 해제권 조항을 둔 것인지는 결국 의사해석의 문제로서, 계약체결의 목적, 해제권 조항을 둔 경위, 조항 자체의 문언 등을 종합적으로 고려하여 논리와 경험법칙에 따라 합리적으로 해석하여야 한다.
(4)다만 해제사유로서 계약당사자 일방의 채무불이행이 있으면 상대방은 계약을 해제할 수 있다는 것과 같은 일반적인 내용이 아니라 계약에 특유한 해제사유를 명시하여 정해 두고 있고, 더구나 해제사유가 당사자 쌍방에 적용될 수 있는 것이 아니라 일방의 채무이행에만 관련된 것이라거나 최고가 무의미한 해제사유가 포함되어 있는 등의 사정이 있는 경우에는 이를 당사자의 진정한 의사를 판단할 때 고려할 필요가 있다.
(5)갑 주식회사와 을이 금형 제작에 관한 도급계약을 체결하면서 작성한 도급계약서에 ‘갑 회사는 을이 계약을 위반하여 기간 내에 제작을 완료할 수 없는 경우에 계약을 해제할 수 있다’는 조항을 두었는데, 을이 납품기한이 지나도록 납품을 하지 못하자 갑 회사가 이행 최고 없이 곧바로 계약해제를 통보한 사안에서, 제반 사정에 비추어 위 조항은 단순히 채무불이행으로 인한 법정해제권을 주의적으로 규정한 것이 아니라 특유한 해제사유를 정하고 해제절차에서도 최고 등 법정해제권 행사의 경우와 달리 정하고자 하는 당사자의 의사가 반영된 것이라고 볼 여지가 있는데도, 갑 회사의 계약해제가 법정해제권의 행사요건을 갖추지 못하여 효력이 없다고 본 원심판단에 법리오해 등의 잘못이 있다.
업무상 저작물 조항은 – “주문자가 전적으로 프로그램에 대한 기획을 하고 자금을 투자하면서 개발업자의 인력만을 빌려 그에게 개발을 위탁하고 이를 위탁받은 개발업자는 당해 프로그램을 오로지 주문자만을 위해서 개발ㆍ납품하는 것과 같은 예외적인 경우가 아닌 한 프로그램 제작에 관한 도급계약에는 적용되지 아니한다(대법원 2000. 11. 10. 선고 98다60590 판결 참조).”
대법원 2000. 11. 10. 선고 98다60590 판결
(1)저작권법 제9조는 프로그램 제작에 관한 도급계약에는 적용되지 않는 것이 원칙이다.
(2)발주자가 전적으로 프로그램에 대한 기획을 하고 자금을 투자하면서 개발업자의 인력만을 빌어 그에게 개발을 위탁하고 이를 위탁받은 개발업자는 당해 프로그램을 오로지 주문자만을 위해서 개발ㆍ납품하여 결국 주문자의 명의로 공표하는 것과 같은 예외적인 경우에는 법인 등의 업무에 종사하는 자가 업무상 작성한 저작물에 준하는 것으로 보아 이를 준용하여 주문자를 저작권자로 볼 수 있다.
서울고등법원 2023. 7. 6. 선고 2022나2051735 판결
(1)이 사건 프로그램 개발용역계약은 도급계약에 해당하고, 이 사건 프로그램을 개발한 개발자 원고가 그 저작권을 원시적으로 취득한다.
(2)이 사건 개발용역계약 제6조는 그 저작권이 발주자 회사에게 있다고 정하고 있으나, 회사가 받는 수익에 비해 개발자 원고가 받는 대금이 현저히 적으므로 불공정한 법률행위로 무효이거나, 약관의 규제에 관한 법률 제5조 제2항에 따라 원고에게 유리하게 미완성 저작물의 저작권은 원고에게 있다는 취지로 해석되어야 한다.
(3)게다가 이 사건 용역계약은 적법하게 해제되었거나, 사기에 의한 의사표시로 취소되었으므로, 그 저작권은 여전히 원고에게 있다.
(1)ERP 개발계약서 특약사항 제4항 ”MES DATA 연동작업은 피고가 책임을 지고 완성하여 R 사업의 감리에 문제가 없어야 한다(단, MES 내부에 문제시는 별도 협의 조치한다).“
(2)개발사는 발주사로부터 기존 사용하는 MES 프로그램의 소스코드 외에 그 로직, 설계서, 매뉴얼 등은 제공받지 못함.
(3)개발사 주장 - 계약금액만으로 자기부담으로 모든 MES 연동작업을 완성하고 나아가 필요한 테스트 환경도 구축하는 것은 과도한 것으로 양자는 전혀 그 업무범위, 비용부담 등이 다름
(4)발주사 주장 – 계약에 MES 연동작업은 개발사 피고가 책임을 지고 완성한다는 특약사항이 기재되어 있는바, 이는 피고가 원고로부터 기존 MES 프로그램의 소스코드 외에 그 로직, 설계서, 매뉴얼 등을 제공받지 못하는 것을 전제로 피고의 부담으로 MES 연동작업을 완성해주기로 하였기 때문이고, 따라서 원고로서는 피고에게 기존 MES 프로그램의 소스코드 외에 그 로직, 설계서, 매뉴얼 등을 제공하거나 나아가 그에 필요한 테스트 환경을 구축해줄 계약상 의무가 없다.
(5)쟁점 – 특약조항을 개발사의 전적인 책임으로 해석할 수 있는지 여부
(6)판결요지 – 발주사의 주장 배척
2.서울고등법원 판결 요지 – 개발사 책임 제한, 승소
(1)이 사건 MES 프로그램에 설계서(논리/물리 모델, 프로그램 사양서)가 존재하고 이를 기반으로 소스코드가 개발된 것인 사실을 인정할 수 있는바, 발주사 원고로서는 ERP 시스템 구축자인 피고에게 MES 인프라 구성, 데이터 구조, 프로그램 구조 등의 설계서와, MES 시스템을 통해 생성되는 데이터가 어떤 과정으로 생성되고 저장되는지, 피고가 구축하는 ERP 시스템에 어떤 정보가 언제, 어느 DB로 가야 기존 MES 시스템이 정상적으로 운영될 수 있는지 등을 제공, 설명해야 할 책임 있음.
(2)원고가 제시한 위 설명서의 ‘기존 MES 데이터와의 연계에 100% 문제가 없어야 함’이라는 문구만으로는 원고 주장의 위와 같은 내용이 포함되어 있다고 보기에 부족하다.
(3)선행 시스템 구축업체로부터 기존 MES 프로그램의 소스코드 외에 그 로직, 설계서, 매뉴얼 등을 입수할 수 없고, 나아가 테스트 환경 구축에 따른 추가 비용 부담 등의 문제가 발생할 수 있다는 사정은, 입찰 참여 업체로서는 투입 인원, 작업 기간 및 난이도, 소요 비용 등이 적잖게 추가될 수 있는 문제인 동시에 그에 대한 해결방안을 갖고 있다는 것이 입찰에 있어서 타 경쟁업체에 대하여 비교우위를 점할 수 있는 핵심적인 장점이라고 할 것임에도, 입찰 제안서에 이를 명시적으로 언급하지 않았다는 것은 쉽게 이해하기 어렵다.
(4)나아가 위와 같은 내용은 발주자인 원고로서도 시스템 구축 및 운용의 성패를 좌우할 수 있는 중요한 문제였다고 할 것인데, 제안요청서 또는 적어도 프레젠테이션 과정에서 입찰 참여 업체들에게 이 문제를 어떻게 해결할 수 있을 것인지에 관하여 집중하여 질문을 하고 그 답변 내용을 기재해두었을 것으로 보임에도 이에 관한 문답서 등도 남아 있지 않은바, 이 역시 쉽게 납득하기 어렵다.
(5)특약사항에는 ‘피고는 기존 MES 프로그램의 소스코드 외에 그 로직, 설계서, 매뉴얼 등은 제공받지 못한다는 것을 양해하고, 피고의 부담으로 MES 연동작업을 완성한다’든가 ‘피고의 부담으로 MES 연동작업에 필요한 테스트 환경을 구축한다’는 등의 내용이 구체적으로 명시되어 있지 않다.
(6)오히려 ”(단, MES 내부에 문제시는 별도 협의 조치한다)“라는 문구의 의미는, 선행 시스템 구축 업체로부터 MES 프로그램의 소스코드 외에 그 로직, 설계서, 매뉴얼 등을 제공받지 못하는 등의 문제가 발생할 경우에는 원고와 피고가 별도로 협의한다는 취지로 볼 여지도 있다
(7)위 특약사항의 의미가 원고가 피고에게 기존 MES 프로그램의 소스코드 외에 그 로직, 설계서, 매뉴얼 등을 제공할 수 없어 피고가 이를 독자 개발하여야 하고, MES 연동작업에 필요한 테스트 환경도 피고의 부담으로 구축하여야 한다는 취지였다면, 피고로서는 위와 같이 원고에게 각 보고를 함에 있어 그 초기 단계부터 이에 관한 현황 분석 및 일정 수립, 구체적 작업 내용 등을 명시하였어야 할 것이고, 원고로서도 피고에게 보고서에 위와 같은 내용을 명시하거나 별도의 추가 보고를 하도록 요구하였어야 할 것임에도 이에 관한 별다른 자료가 없다.
컴퓨터프로그램 소프트웨어의 개발납품 계약은 도급계약으로, 개발자(수급자)가 프로그램개발을 완성하여 납품하면 발주자가 그 보수, 용역대금을 지급하는 계약입니다. 개발자가 완성하여 납품하는 기준, 발주자가 요구하는 개발요구사항, 개발자의 개발범위를 명확하게 정하는 것이 매우 중요합니다. SW 개발공급계약서에서 프로그램의 목적과 기능을 구체적으로 특정하고, 해당 분야를 이해하는 개발자, 전문가의 검토를 거쳐 개발요구사항 및 개발범위를 기능별, 항목별로 구체적으로 정리하는 것이 바람직하고, 독립된 별지로 정리하여 첨부하면 분쟁을 예방할 수 있습니다. 원칙적으로 수급인 개발자는 개발완성을 입증할 책임 있고, 완성해야 보수(개발대금)을 청구할 수 있습니다.
프로그램개발의 완성 또는 미완성 판단기준: 소프트웨어 개발납품 계약서에서 정한 기준,예를 들어 개발요구사항 명세서, 개발범위 등에 따라 완성여부를 판단합니다. 계약서 문언에 따라 계약에 포함되어 있는 사양과 기능을 갖춘 제품의 개발, 그 이행 제공, 관련한 자료, 당시 관련 당사자들의 태도 등 제반 사정을 종합하여 판단합니다.
2.개발납품 완료 후 하자보수 vs 미완성의 구별
소프트웨어 개발공급계약에서 미완성에 대해서는 대금지급거절, 채무불이행으로 인한 계약해제 또는 계약해지가 문제되지만, 완성, 납품 후에는 발주자는 용약대금지급 의무가 있고 다만 개발자에 대한 하자보수요구가 문제됩니다.
소프트웨어 프로그램 개발 및 공급계약에서 일의 완성으로 보려면 계약상 예정된 최후의 공정까지 종료하였음과 함께 프로그램의 주요기능 부분이 약정된 대로 개발되어 사회통념상 일반적으로 요구되는 성능을 갖추고 있어야만 합니다. 또한 계약상 예정된 최후의 공정이 종료하였는지 여부는 개발자 수급인의 주관적인 주장이 아니라 개발 및 공급계약의 구체적 내용과 신의성실의 원칙에 비추어 객관적으로 판단해야 합니다.
개발자가 소프트웨어 개발의 일을 완성하고 이를 인도하면 발주자는 해당 소프트웨어 프로그램이 계약상 사양과 내용대로 완성되었는지 점검하여 수령하게 되는데, 법원은 제작물공급계약에서 목적물의 인도는 완성된 목적물에 대한 단순한 점유의 이전만을 의미하는 것이 아니라 도급인이 목적물을 검사한 후 그 목적물이 계약내용대로 완성되었음을 명시적 또는 묵시적으로 시인하는 것까지 포함한다고 봅니다.
그런데, 실무상 개발 납품한 프로그램이 계약상 요구사항을 모두 충족하였지만 발주자가 원하는 성능을 충분히 구현하지 못한다고 불만을 표시하면서 개발대금을 지급하지 않고 과도하게 보완을 계속 요구하는 경우가 있습니다. 이와 같은 하자 주장은, 법적으로 일의 완성과는 구별되는 다른 개념입니다. 하자가 있더라도 일이 완성되었다면 수급인은 도급인에게 보수의 지급을 청구할 수 있습니다.
하자여부도 일의 완성여부 판단, 그 완성도의 판단기준이 매우 중요합니다. 계약서에서 요구사항 각 항목을 특정하고, 목적하는 기능, 사용용도, 개발동기 등 배경사실을 기재하였거나 프로그램의 기능이 어떻게 구현되어야 하는지 등을 구체적으로 기재해 두었다면 완성여부 및 완성도를 판단하는데 큰 문제가 없을 것입니다.
발주자 도급인은 하자보수청구권을 가지므로 하자담보책임에 기한 항변을 행사하여 하자에 대한 보수 또는 그에 갈음하는 손해배상의 지금에 대한 대금의 지급을 거절할 수 있습니다. 그러나 하자를 이유로 대금 전부의 지급을 거절할 수는 없습니다.
정리하면, 발주한 소프트웨어 프로그램의 개발이 미완성인 때에는 대금지급을 거절할 수 있지만, 완성되었으나 하자가 있는 경우에는 발주자 도급인은 일의 완성을 요구하면서 대금지급을 거절할 수는 있습니다. 다만, 하자의 정도에 따라 대금감액 또는 손해배상을 청구할 수는 있습니다.
3.소프트웨어 프로그램의 완성, 납품 후 하자보수 또는 추가 개발계약
소프트웨어 개발 및 공급의 도급계약에 있어서의 하자는 완성된 일이 계약에서 정하거나 보증한 내용이 아니거나, 그 경제적 사용가치 또는 교환가치를 감소시키는 결함이 있거나, 또는 당사자가 미리 정한 사양 또는 기능을 가지지 못하는 등 결함을 말합니다. 그러나 하자의 정의는 모호하고 추상적이라 개별 사건마다 당사자간의 계약 내용을 검토하는 것이 중요합니다. 또한 계약상 합의된 사양과 내용과 함께 통상적인 용도에 적합한지 여부도 중요한 기준입니다.
납품 및 검수 후의 소프트웨어 버그에 대한 리포트를 받고 이를 즉시 보수하거나 도급인과 협의하여 상당한 조치를 취한 때에는 하자라고 보지 않을 것입니다. 그러나 도급인이 요구하는 구체적인 업무나 기능이 제대로 작동되지 않는 경우, 통신 및 인터넷과 연계된 컴퓨터 프로그램이 통신 및 네트워크와 연결하여서는 제대로 작동되지 않은 경우나, 컴퓨터 안에 보존된 다른 데이터 등을 잃어 버리는 경우 등은 하자에 해당합니다.
최초의 개발범위를 벗어난 추가 개발요구사항이 있는 경우 계약범위를 변경하는 추가 합의서를 첨부하거나 별도의 추가 개발계약을 체결할 수 있습니다. 추가 개발사항을 명시적으로 정리한 변경계약서 또는 추가 계약서가 없다면 기존 계약범위 내인지 추가 개발인지 여부가 불명확하여 분쟁의 소지가 있습니다. 추가 개발서를 별도 서면으로 작성하면, 추가개발에 대하여 상호 진지하게 고민하게 될 것이고, 그 추가 개발사항에 대한 분쟁도 줄어들 수 있습니다. 이때 추가 개발사항으로 개발비용이 추가되는지 여부도 명확하게 결정해야 합니다. 그렇지 않으면 추가 비용의 부담에 관한 분쟁원인이 될 것입니다.
4.완성 전 중간점검, 중도해지, 계약변경 시 입증자료
컴퓨터 프로그램의 납품 후 계약에 따른 완성 여부를 다투거나 하자를 다투는 것보다 중간에 미리 점검하고 확인하는 것이 바람직합니다. 개발단계에 따라 단계별로, 또는 모듈별로 개발정도를 점검하거나 또는 기간에 따라 정기적으로 점검하는 것이 바람직합니다. 만약 당초 계약내용을 변경하거나 수정, 보완해야 한다면 중도에 추가 계약서를 작성하는 등 명시적 자료를 남기는 것이 좋습니다.
개발공급계약서에 개발진도 점검, 검수, 중도 계약해지에 대한 조건 등을 명확하게 규정하는 것이 좋습니다. 중간단계 완성여부, 점검, 검수기준을 정해두고, 기준 미충족 시 중도 해지조건까지 정해두지 않으면 상호간 자기 주장만 하고 진행되지 않는 난관에 봉착합니다. 어떤 경우에 계약해제 또는 해지를 할 수 있는지, 그 경우 어떻게 정산을 할지 명확하게 정리하는 것이 바람직합니다.
5.개발 결과물의 납품 방식 및 저작권 귀속 사항
개발결과물을 어떤 방식으로 납품할 것인지, 그 결과물의 저작권 귀속에 대해 명확하게 정해 두어야 합니다. 통상 사용하는 SW 소유권 뿐만 아니라 그 저작권, 사용권을 갖는다는 점을 명확하게 정리하는 것이 필요합니다. 특히 당해 계약의 산출물인지 아니면 기존에 보유하고 있던 솔루션까지 포함한 것인지 등 명확하지 않으면 분쟁의 소지가 있습니다.
법리 – “도급에 관한 민법 제668조는 “도급인이 완성된 목적물의 하자로 인하여 계약의 목적을 달성할 수 없는 때에는 계약을 해제할 수 있다”고 규정하고 있는 바, 여기서 계약의 목적을 달성할 수 없다는 것은, 그 하자가 중대하고 보수가 불가능하거나 가능하더라도 장기간을 요하는 등 계약해제권을 행사하는 것이 정당하다고 인정되는 경우를 의미한다(대법원 2010. 6. 10. 선고 2010다10252 판결 참조).
2.개발능력 부족 및 중대하자 - 개발계약의 해제 사유 인정
이 사건 부동산플랫폼에 존재하는 하자는 중대한 하자이고, 수급인 피고의 역량으로 보수가 불가능하거나 또는 가능하더라도 장기간을 요하는 경우로서 ‘하자로 인하여 이 사건 도급계약의 목적을 달성할 수 없는 때’에 해당한다고 봄이 상당하다.
3.개발계약의 해제 및 대금반환 의무
발주자 원고는 이를 이유로 이 사건 도급계약을 해제할 수 있고, 원고의 해제 의사표시에 따라 이 사건 도급계약은 해제되었고, 이에 따라 개발자 피고는 원고에게 원상회복의무의 이행으로 지급받은 돈 및 이에 대한 받은 날로부터 이자 또는 지연손해금을 가산하여 반환하여야 한다.
4.미완성이나 일부완성의 기성고에 따른 보수 인정 여부
개발자 주장요지 - 이 사건 목적물에 대한 개발이 상당히 이루어졌으므로 원고의 이 사건 도급계약 해제 통보로 이 사건 계약관계가 중도에 해소되더라도 수급인인 피고는 당시까지의 보수를 청구할 수 있고, 피고가 지급받은 돈은 그 보수에 미치지 못하므로 결국 피고로서는 반환할 금액이 없다는 취지의 주장을 한다.
법원 판단 – 개발완성 부분의 사용가치 불인정, 기성고에 따른 일부보수 청구권 불인정
도급계약에서 수급인은 원칙적으로 일을 완성하여야 보수를 청구할 수 있고, 다만 이미 공급되어 설치된 목적물의 완성도가 약간의 보완을 가하면 업무에 사용할 수 있을 정도로서 이미 완성된 부분이 도급인에게 이익이 되는 경우 그 계약관계가 도급인의 해제통보로 중도에 해소되었다면 수급인은 당시까지의 보수를 청구할 수 있다고 할 것이나(대법원 1996. 7. 30. 선고 95다7932 판결 참조), 이 사건 부동산플랫폼의 완성 부분이 원고에게 이익이 된다고 볼 뚜렷한 증거가 없다.
(1)ERP 개발계약서 특약사항 제4항 ”MES DATA 연동작업은 피고가 책임을 지고 완성하여 R 사업의 감리에 문제가 없어야 한다(단, MES 내부에 문제시는 별도 협의 조치한다.)“
(2)개발사는 발주사로부터 기존 사용하는 MES 프로그램의 소스코드 외에 그 로직, 설계서, 매뉴얼 등은 제공받지 못함.개발사 주장 - 계약금액만으로 자기부담으로 모든 MES 연동작업을 완성하고 나아가 필요한 테스트 환경도 구축하는 것은 과도한 것으로 양자는 전혀 그 업무범위, 비용부담 등이 다름
(3)발주사 주장 – 계약에 MES 연동작업은 개발사 피고가 책임을 지고 완성한다는 특약사항이 기재되어 있는바, 이는 피고가 원고로부터 기존 MES 프로그램의 소스코드 외에 그 로직, 설계서, 매뉴얼 등을 제공받지 못하는 것을 전제로 피고의 부담으로 MES 연동작업을 완성해주기로 하였기 때문이고, 따라서 원고로서는 피고에게 기존 MES 프로그램의 소스코드 외에 그 로직, 설계서, 매뉴얼 등을 제공하거나 나아가 그에 필요한 테스트 환경을 구축해줄 계약상 의무가 없다.
(4)쟁점 – 특약조항을 개발사의 전적인 책임으로 해석할 수 있는지 여부
(5)판결요지 – 발주사의 주장 배척
2.서울고등법원 판결 요지 – 개발사 책임 제한, 승소
(1)이 사건 MES 프로그램에 설계서(논리/물리 모델, 프로그램 사양서)가 존재하고 이를 기반으로 소스코드가 개발된 것인 사실을 인정할 수 있는바, 발주사 원고로서는 ERP 시스템 구축자인 피고에게 MES 인프라 구성, 데이터 구조, 프로그램 구조 등의 설계서와, MES 시스템을 통해 생성되는 데이터가 어떤 과정으로 생성되고 저장되는지, 피고가 구축하는 ERP 시스템에 어떤 정보가 언제, 어느 DB로 가야 기존 MES 시스템이 정상적으로 운영될 수 있는지 등을 제공, 설명해야 할 책임 있음.
(2)원고가 제시한 위 설명서의 ‘기존 MES 데이터와의 연계에 100% 문제가 없어야 함’이라는 문구만으로는 원고 주장의 위와 같은 내용이 포함되어 있다고 보기에 부족하다.
(3)선행 시스템 구축업체로부터 기존 MES 프로그램의 소스코드 외에 그 로직, 설계서, 매뉴얼 등을 입수할 수 없고, 나아가 테스트 환경 구축에 따른 추가 비용 부담 등의 문제가 발생할 수 있다는 사정은, 입찰 참여 업체로서는 투입 인원, 작업 기간 및 난이도, 소요 비용 등이 적잖게 추가될 수 있는 문제인 동시에 그에 대한 해결방안을 갖고 있다는 것이 입찰에 있어서 타 경쟁업체에 대하여 비교우위를 점할 수 있는 핵심적인 장점이라고 할 것임에도, 입찰 제안서에 이를 명시적으로 언급하지 않았다는 것은 쉽게 이해하기 어렵다.
(4)나아가 위와 같은 내용은 발주자인 원고로서도 시스템 구축 및 운용의 성패를 좌우할 수 있는 중요한 문제였다고 할 것인데, 제안요청서 또는 적어도 프레젠테이션 과정에서 입찰 참여 업체들에게 이 문제를 어떻게 해결할 수 있을 것인지에 관하여 집중하여 질문을 하고 그 답변 내용을 기재해두었을 것으로 보임에도 이에 관한 문답서 등도 남아 있지 않은바, 이 역시 쉽게 납득하기 어렵다.
(5)특약사항에는 ‘피고는 기존 MES 프로그램의 소스코드 외에 그 로직, 설계서, 매뉴얼 등은 제공받지 못한다는 것을 양해하고, 피고의 부담으로 MES 연동작업을 완성한다’든가 ‘피고의 부담으로 MES 연동작업에 필요한 테스트 환경을 구축한다’는 등의 내용이 구체적으로 명시되어 있지 않다.
(6)오히려 ”(단, MES 내부에 문제시는 별도 협의 조치한다)“라는 문구의 의미는, 선행 시스템 구축 업체로부터 MES 프로그램의 소스코드 외에 그 로직, 설계서, 매뉴얼 등을 제공받지 못하는 등의 문제가 발생할 경우에는 원고와 피고가 별도로 협의한다는 취지로 볼 여지도 있다.
(7)위 특약사항의 의미가 원고가 피고에게 기존 MES 프로그램의 소스코드 외에 그 로직, 설계서, 매뉴얼 등을 제공할 수 없어 피고가 이를 독자 개발하여야 하고, MES 연동작업에 필요한 테스트 환경도 피고의 부담으로 구축하여야 한다는 취지였다면, 피고로서는 위와 같이 원고에게 각 보고를 함에 있어 그 초기 단계부터 이에 관한 현황 분석 및 일정 수립, 구체적 작업 내용 등을 명시하였어야 할 것이고, 원고로서도 피고에게 보고서에 위와 같은 내용을 명시하거나 별도의 추가 보고를 하도록 요구하였어야 할 것임에도 이에 관한 별다른 자료가 없다.
(1)소프트웨어 개발계약 성질 – 도급 계약: 당사자의 일방이 상대방의 주문에 따라 자기 소유의 재료를 사용하여 만든 물건을 공급하기로 하고 상대방이 대가를 지급하기로 약정하는 이른바 제작물공급계약은 그 제작의 측면에서는 도급의 성질이 있고 공급의 측면에서는 매매의 성질이 있어 대체로 매매와 도급의 성질을 함께 가지고 있으므로, 그 적용 법률은 계약에 따라 제작 공급하여야 할 물건이 대체물인 경우에는 매매에 관한 규정이 적용되지만, 물건이 특정 주문자의 수요를 만족하게 하기 위한 부대체물인 경우에는 당해 물건의 공급과 함께 그 제작이 계약의 주목적이 되어 도급의 성질을 띠게 된다(대법원 2006. 10. 13. 선고 2004다21862 판결 등 참조). 이러한 법리는 계약의 목적물이 유형물이 아니고 무체물인 전산프로그램인 경우에도 마찬가지로 적용된다고 봄이 타당하다.
(2)소프트웨어의 성격상 전체적인 기능이 구현되어 있어도 일부 부속품의 기능이 부족하거나 결함이 있는 경우, 전체적인 시스템의 목적을 달성하지 못하게 되는 경향이 있다. 또한 소프트웨어를 통해 기본적으로 실행되어야 하는 기능에 지속적인 오류 또는 오작동이 발생하거나, 호환성이 결여되어 하드웨어나 다른 프로그램과의 상호작용이 제대로 이루어지지 않고 이러한 현상이 소프트웨어 설치 초기에 이루어지는 안정화 작업을 거친 이후에도 지속된다면, 이는 당해 소프트웨어 자체의 하자로 볼 여지가 크다.
(3)이러한 소프트웨어상 오류 내지 오작동으로 인한 하자가 실제 존재하는지 여부를 판단함에 있어서는 오류가 발생한 부분이 전체 작업량에서 차지하는 비중, 오류가 전체 프로그램의 정상적인 작동과 업무의 흐름을 방해하는 정도, 프로그램을 도입하기 전후 정황, 계약 당사자가 계약을 체결하게 된 경위와 목적 등의 여러 사정들이 종합적으로 고려되어야 한다.
(4)구체적 사안의 판단: 개발사에서 설치한 이 사건 시스템은 가동 속도의 현저한 지연, 작동 중단 등으로 인하여 발주사의 직원들이 정상적인 업무를 수행할 수 없거나 결재기능이 정상적으로 이루어지지 않는 등 중대한 하자가 발생함으로써, 효율적이고 신속한 시스템 개발이라는 이 사건 각 계약상 목적을 달성할 수 없게 되었다고 봄이 타당하다. 계약을 해제한다는 통지로 계약은 적법하게 해제되었다.
(5)이 사건 시스템의 설계와 구축에 있어서 신속한 가동 속도를 현출하는 것은 이 사건 각 계약상 시스템을 공급하는 자로서 수행하여야 할 계약상 중요한 의무라고 봄이 상당하다.
(6)업무 처리에 필요한 가동 속도는, 시스템을 사용하는 사용자들에게 기본적으로 요구되는 성능이다. 특히 발주 회사와 같이 패션 업종 회사들은 기획, 설계부터 제작, 재고 관리에 이르기까지 데이터를 효과적으로 정리하는 것이 필수적이고, 패션 디자인에 대한 작업지시서를 작성하는 데 대용량의 이미지 파일을 자주 사용하게 되므로, 이러한 업무를 수행하기 위해서는 해당 정보에 쉽고 빠르게 접근할 수 있도록 하는 것이 중요하다. 그렇다면 이 사건 각 계약상 시스템의 구동 속도가 어느 수준 이상이어야 한다는 점이 명시적으로 기재되어 있지 않더라도, 위와 같은 원고 회사의 업무 특성, 기존에 원고가 사용하던 PDM 시스템의 기능을 유지하면서 더 개선되고, 발전된 형태의 시스템을 도입하기 위하여 이 사건 시스템을 도입하기로 한 계약의 목적 등을 고려하여 보면, 이 사건 각 계약에서 요구되는 이 사건 시스템의 속도 기능은 적어도 원고가 기존에 사용하던 PDM 시스템을 사용할 당시의 가동 속도라고 보는 것이 양 당사자들의 의사에 부합한다.
(7)이 사건 시스템에는 로딩속도 지연, 작동 중단 등 오류가 자주 발생하고, 과중한 부하가 걸릴 경우에는 속도가 현저하게 떨어져 정상적인 업무의 수행이 사회통념상 불가능할 정도에 이르는 하자가 존재한다고 봄이 타당하다.
(8)직원들의 의견 - 직원들이 이 사건 시스템을 사용하면서 남긴 내부 회의록에 의하면, ‘잦은 오류 및 늦은 속도, 잦은 쿨타임으로 생산성이 저하되며 조작법이 불편함, 속도가 너무 느림, 업무를 진행할수록 계속적으로 나타나는 오류들에 대한 빠른 개선 필요, 시험 사용결과 프로그램 속도 원활하지 못한 부분도 있음, 시스템 불안정 및 작업의뢰서 검색까지 경로, 버퍼링이 김‘과 같은 의견이 개진되고 있다. 이 사건 시스템에서 통상 나타나는 객관적인 오류 내지 오작동의 중요한 징표라고 볼 수 있다.
(1)개발계약상 해제사유: ‘개발회사의 귀책사유로 용역수행 기간까지 당해 용역을 완료하지 못하거나 완료할 가능성이 없다고 인정될 경우, 원고가 계획에 따른 용역수행 등 계약상 의무를 이행하지 않은 경우, 기타 계약 조건을 위반하고 그 위반으로 인하여 계약의 목적을 달성할 수 없다고 인정될 경우’ 계약을 해제할 수 있다.
(2)용역계약서 상 실행계획서에서 정한 바에 따라해당 용역업무를 완료하지 못한 것으로 보이는 점, ② 용역계약 상의 용역업무를 수행하는 장소였던 병원에서 인력을 철수하여 용역업무의 진행중단되었으므로 용역계약 상의 목적인 용역업무의 완성은 달성하기 어려운 상태라고 할 것인 점
(3)발주자 피고의 해제 의사표시에 의하여 그 의사표시가 원고에게 도달한 시점에 적법하게 해제되었다.
2.시스템 개발 실패의 책임 소재 – 법원 개발자로 판단
개발자는 용역계약 상의 용역 의무를 이행하지 못한 것은 발주자 병원의 귀책사유에 의한 것이라는 취지로 항변한다.
(1)용역계약 체결 후 발주자 병원에서 개발회사에 개발 범위에 대한 요구사항을 여러 번에 걸쳐 다수 전달하였던 것으로 보이나,
(2)한편, 개발자는 IT 시스템을 구축하는 전문가로서 이 사건 용역계약 상 정하여진 용역업무를 수행함에 있어 피고의 요구사항을 듣고 이를 반영할 의무가 있다고 할 것인 점, 용역계약 상 결과물은 ‘분석, 설계, 구현, 시험’으로 이루어지는 과정을 통과하여야 하는데, 원고가 제출한 ‘업무요건정의서’ 내용에 비추어 원고는 피고가 요구하는 사항에 대하여 명확히 인지한 후 이를 분석하여 프로그램 정의를 명확하게 하였던 것으로는 보이지 않는 점, 원고가 작성한 ‘업무요건정의서’ 상의 기재 내용이 미흡하였던 이유로 원고가 최종적으로 목표로 하였던 시스템에 대한 설계 자체가 수행될 수 없었던 것으로 보이고, 실제로 용역계약을 완료함에 있어 필요한 설계도서가 확정되지 못하였던 것으로 보이는 점 등에 비추어 보면, 원고가 제출한 증거만으로는 원고가 이 사건 용역계약 상의 용역업무를 이행하지 못한 것에 대하여 발주자 병원(피고)에게 귀책사유가 있다는 점을 인정하기 부족하다.
3.개발회사에서 기성고 62%에 상응하는 계약대금 주장 – 법원 불인정
용역계약은 병원의 환경에 적합한 업무용 응용프로그램을 개발하여 이를 병원에 구축하는 것을 주된 내용으로 하는 일종의 도급계약이다.
① 김정인은 최종 기성 비율을 61.14%로 산정하였으나, 이는 ‘이 사건 용역계약 체결 이후 원고와 피고가 입은 손실을 최소화한다는 차원에서 원고와 피고가 수행한 결과를 합리적으로 평가하여 기성고를 산정한 것’인 점,
② 한편으로 용역업무는 앞서 언급한 것과 같이 1단계 개발 부분에 속하는 ‘분석’ 업무가 완료되지 않았던 탓에 ‘설계’ 업무가 완성될 수 없었고, 그 결과 이 사건 용역계약 상 용역업무를 완성하는 데 필요한 설계도서가 마련되지 않았던 것으로 보이는 점,
③ 이러한 이유로 피고로서는 제3자에게 ‘원고가 만들어낸 결과물에 이어서 용역업무를 완성할 것’을 요구할 수는 없었던 것으로 보이는 점,
④ 감정인도 ‘쌍방이 합의한 설계도서가 없는 상태에서는 개발 기준이 확정되지 않은 상태이므로 현 상태 그대로 제3자가 업무를 완성할 수는 없다.’라고 감정하였는데, 위와 같은 취지에서 이와 같이 감정한 것으로 보이는 점,
⑤ 그렇다면 설령 원고가 이 사건 용역계약에 따른 용역업무를 일부 수행하여 결과물을 작성하였다 하더라도, 그 결과물을 피고가 이어받아 사용할 수 있었던 것으로 보기는 어렵고, 달리 원고가 만들어낸 결과물이 피고에게 이익이 되어 구체적인 기성 비율을 산정할 수 있는 정도에 이르렀다고 볼 만한 자료도 충분히 제출되었다고 보기는 어려운 점 등에 비추어 보면,
이 사건 용역계약 상 용역업무를 완성하지 못한 원고로서는 피고에게 기성 부분의 보수를 청구할 수 없다고 볼 것이다.
4.발주자의 개발회사에 대한 지체상금 청구 – 법원 일부 인정
(1)도급계약에서 미완성으로 계약해제 시 지체상금 조항에 따른 지체상금 인정 - 개발회사는 완성 불가에 따른 발주자에게 지체상금 지급 의무 있음
(2)지체상금 계산: 지체상금의 종기는 도급인이 도급계약을 해제할 수 있었을 때부터 도급인이 다른 업자에게 맡겨 그 업무를 완성할 수 있었던 시점(대법원 2006. 4. 28. 선고 2004다39511 판결 등 참조)
통상 컴퓨터프로그램 등 소프트웨어를 개발하여 납품하는 계약은 도급계약으로 볼 수 있습니다. 도급계약은 당사자 일방이 일을 완성할 것을 약정하고 상대방이 그 일의 결과에 대하여 보수를 지급할 것을 약정함으로써 성립하는 계약입니다(민법 제664조). 즉, 도급은 일의 완성을 목적합니다. 특정 목적의 소프트웨어 프로그램 개발공급 계약에서 수급인 개발자의 급부의무는 도급인 발주자의 주문 사양에 맞추어 하자 없이 주문한 기능을 가진 프로그램을 개발하여 공급하는 것입니다.
판례도 “소프트웨어 개발·공급계약은 일종의 도급계약”이라고 하고, (발주자 – 도급인 vs 개발자 – 수급인 구도) 수급인은 원칙적으로 일을 완성하여야 보수를 청구할 수 있다고 판시하고 있습니다. 도급계약에서는 일의 완성 여부가 매우 중요한 핵심 사항입니다.
판결은 일단 완성되었다면, “발주자 도급인이 프로그램 내용에 대하여 불만을 표시하며 수급인의 수정 제의를 거부하면서 계약해제 통보를 하는 등 특별한 사정이 있다면 수급인은 당시까지의 보수를 청구할 수 있다”고 판시합니다.
반면, 컴퓨터프로그램의 납품에 중점이 있는 것이 아니고 전문가로서 개발업무를 수행하는 것 자체에 중점이 있는 경우라면 도급계약이 아니라 위임계약으로 볼 수도 있습니다. 위임계약의 대표적 예를 들면, 의사가 환자를 치료하고 대가를 받는 관계입니다.
2. 분쟁원인 - 프로그램 개발완성 여부
소프트웨어 프로그램 개발공급계약에서 완성여부에 대한 채무불이행 여부가 문제되는데, 수급인 개발자가 채무이행을 제대로 하였는지 여부는 당사자가 합의한 계약내용을 기준으로 판단될 것입니다.
그런데 소프트웨어 프로그램 개발공급계약은 실무상 합의내용을 구체적으로 명확하게 계약서에 반영하는 것이 상당히 어렵습니다. 개발대상 프로그램이 크고 복잡한 경우 그 요구조건, 사양, 내용, 시스템 등을 계약에 명확하게 반영하기 어렵습니다. 그 결과 계약내용에 대해 당사자 사이에 이해내용상 상당한 차이가 발생할 수도 있습니다. 그 결과 개발진행 후 일의 완성 여부에 대한 분쟁이 자주 발생하는 것입니다.
3. 프로그램개발의 완성 또는 미완성 판단기준
소프트웨어 개발납품 계약서에서 정한 기준에 따라 완성여부를 판단합니다. 계약서 문언에 따라 계약에 포함되어 있는 사양과 기능을 갖춘 제품의 개발, 그 이행 제공, 관련한 자료, 당시 관련 당사자들의 태도 등 제반 사정을 종합하여 판단합니다. 따라서 발주자와 개발자는 계약서에 프로그램의 목적과 기능을 구체적으로 특정하고, 정확하고 구체적으로 기재해야 하는 것이 바람직합니다. 통상 계약서에 첨부하는 ‘개발사항 명세서’에 관련 사항을 가능하면 상세하게 작성하여야 합니다.
소프트웨어 프로그램 개발 및 공급계약에서 일의 완성으로 보려면 계약상 예정된 최후의 공정까지 종료하였음과 함께 프로그램의 주요기능 부분이 약정된 대로 개발되어 사회통념상 일반적으로 요구되는 성능을 갖추고 있어야만 합니다. 또한 계약상 예정된 최후의 공정이 종료하였는지 여부는 개발자 수급인의 주관적인 주장이 아니라 개발 및 공급계약의 구체적 내용과 신의성실의 원칙에 비추어 객관적으로 판단해야 합니다.
개발자가 소프트웨어 개발의 일을 완성하고 이를 인도하면 발주자는 해당 소프트웨어 프로그램이 계약상 사양과 내용대로 완성되었는지 점검하여 수령하게 되는데, 법원은 제작물공급계약에서 목적물의 인도는 완성된 목적물에 대한 단순한 점유의 이전만을 의미하는 것이 아니라 도급인이 목적물을 검사한 후 그 목적물이 계약내용대로 완성되었음을 명시적 또는 묵시적으로 시인하는 것까지 포함한다고 봅니다.
그런데, 실무상 개발 납품한 프로그램이 계약상 요구사항을 모두 충족하였지만 발주자가 원하는 성능을 충분히 구현하지 못한다고 불만을 표시하면서 개발대금을 지급하지 않고 과도하게 보완을 계속 요구하는 경우가 있습니다. 이와 같은 하자 주장은, 법적으로 일의 완성과는 구별되는 다른 개념입니다. 하자가 있더라도 일이 완성되었다면 수급인은 도급인에게 보수의 지급을 청구할 수 있습니다.
하자여부도 일의 완성여부 판단, 그 완성도의 판단기준이 매우 중요합니다. 계약서에서 요구사항 각 항목을 특정하고, 목적하는 기능, 사용용도, 개발동기 등 배경사실을 기재하였거나 프로그램의 기능이 어떻게 구현되어야 하는지 등을 구체적으로 기재해 두었다면 완성여부 및 완성도를 판단하는데 큰 문제가 없을 것입니다.
발주자 도급인은 하자보수청구권을 가지므로 하자담보책임에 기한 항변을 행사하여 하자에 대한 보수 또는 그에 갈음하는 손해배상의 지금에 대한 대금의 지급을 거절할 수 있습니다. 그러나 하자를 이유로 대금 전부의 지급을 거절할 수는 없습니다.
정리하면, 발주한 소프트웨어 프로그램의 개발이 미완성인 때에는 대금지급을 거절할 수 있지만, 완성되었으나 하자가 있는 경우에는 발주자 도급인은 일의 완성을 요구하면서 대금지급을 거절할 수는 있습니다. 다만, 하자의 정도에 따라 대금감액 또는 손해배상을 청구할 수는 있습니다.
4. 완성된 소프트웨어 프로그램의 하자 관련 쟁점
소프트웨어 개발 및 공급의 도급계약에 있어서의 하자는 완성된 일이 계약에서 정하거나 보증한 내용이 아니거나, 그 경제적 사용가치 또는 교환가치를 감소시키는 결함이 있거나, 또는 당사자가 미리 정한 사양 또는 기능을 가지지 못하는 등 결함을 말합니다. 그러나 하자의 정의는 모호하고 추상적이라 개별 사건마다 당사자간의 계약 내용을 검토하는 것이 중요합니다. 또한 계약상 합의된 사양과 내용과 함께 통상적인 용도에 적합한지 여부도 중요한 기준입니다.
납품 및 검수 후의 소프트웨어 버그에 대한 리포트를 받고 이를 즉시 보수하거나 도급인과 협의하여 상당한 조치를 취한 때에는 하자라고 보지 않을 것입니다. 그러나 도급인이 요구하는 구체적인 업무나 기능이 제대로 작동되지 않는 경우, 통신 및 인터넷과 연계된 컴퓨터 프로그램이 통신 및 네트워크와 연결하여서는 제대로 작동되지 않은 경우나, 컴퓨터 안에 보존된 다른 데이터 등을 잃어 버리는 경우 등은 하자에 해당합니다.
5. 최종 완성 전 개발 정도의 중간점검 및 계약변경시 입증자료 구비 필요
컴퓨터 프로그램의 납품 후 계약에 따른 완성 여부를 다투거나 하자를 다투는 것보다 중간에 미리 점검하고 확인하는 것이 바람직합니다. 개발단계에 따라 단계별로, 또는 모듈별로 개발정도를 점검하거나 또는 기간에 따라 정기적으로 점검하는 것이 바람직합니다. 만약 당초 계약내용을 변경하거나 수정, 보완해야 한다면 중도에 추가 계약서를 작성하는 등 명시적 자료를 남기는 것이 좋습니다.
이때 게약사항의 수정, 변경으로 개발비용이 추가되는지 여부도 명확하게 결정해야 합니다. 그렇지 않으면 추가 비용의 부담에 관한 분쟁원인이 될 것입니다.
(2)발주자의 개발요구사항 추가 변경 있음, 개발된 프로그램에 일부 오류 발생, 발주자의 개발요구사항 모두 만족시키지 못한 부분 있음
(3)그럼에도 불구하고 정부과제의 기간 만료일에 최종 완료보고, 과제 종료
(4)실제 검수 및 시험 단계 완결되지는 못함, 개발자는 정부 완료보고 이후 유지보수성 활동 수행하였음
(5)시험단계 최종확정이 미흡한 부분에 대해 발주자와 개발자 모두에게 책임 있음
(6)발주자 계약종료 통지 후 제3자에게 개발의뢰 및 완성
2.감정결과 – 책임소재 및 기성고 판단
소프트웨어 진흥법 및 관계 법령상 소프트웨어 개발 사업은 분석(요구검토, 요구확정), 설계(설계, 검토, 확정), 구현(개발, 단위시험, 보완), 시험(통합시험, 보완, 정리) 단계로 구분되고, 각 단계별로 분석 단계는 19%, 설계 단계는 24%, 구현 단계는 32%, 시험 단계는 25%의 수행 비율이 인정되는 점,
계약 체결 후 지속적인 협의를 통하여 분석 단계의 활동을 수행하였는데, 원고는 피고가 구현 단계의 활동에 해당하는 개발 업무에 착수한 이후에도 계속적으로 분석 단계의 활동에 해당하는 요구사항을 제시함으로써 개발된 프로그램의 품질 및 안정성에 대한 위험을 유발한 잘못이 있는 한편, 피고는 설계 단계에서 확정되지 않은 매뉴얼(설계 단계에서의 산출물)이라고 하더라도 초안을 원고에게 제시하는 등으로 원고가 매뉴얼을 참고하여 이 사건 시스템에 대한 자신의 요구사항에 대하여 검토할 수 있는 시간적 여유를 제공하였어야 함에도 불구하고 매뉴얼 초안의 제시 없이 개발 결과물을 바로 제시함으로써 원고가 요구사항을 사전에 구체적으로 확인할 수 있는 시간적 여유를 확보하지 못하게 한 잘못이 있는 점,
감정인은 사정을 종합하여, 설계 단계 확정활동의 25%, 구현 단계 확정활동의 25%, 시험단계 확정활동의 25%가 각각 제대로 수행되지 아니하였고, 이는 원고와 피고 모두에게 균등한 책임이 있으므로 이 사건 시스템의 기성률은 89.875%[= 100% - 각 단계별 미흡한 부분에 대한 피고의 책임 비율 합계 10.125%(= ㉠ 설계 단계의 수행비율 24% × 미흡한 정도 25% × 피고의 책임 비율 50% + ㉡ 구현 단계의 수행비율 32% × 미흡한 정도 25% × 피고의 책임 비율 50% + ㉢ 시험 단계의 수행비율 25% × 미흡한 정도 25% × 피고의 책임 비율 50%)]에 해당한다는 감정의견을 제시함
3.관련 법리 – 판단기준
(1)개발계약의 해제 가능성 – 부정적
민법 제544조에 의하여 채무불이행을 이유로 계약을 해제하려면, 당해 채무가 계약의 목적 달성에 있어 필요불가결하고 이를 이행하지 아니하면 계약의 목적이 달성되지 아니하여 채권자가 그 계약을 체결하지 아니하였을 것이라고 여겨질 정도의 주된 채무이어야 하고 그렇지 아니한 부수적 채무를 불이행한 데에 지나지 아니한 경우에는 계약을 해제할 수 없다.
또한 계약상의 의무 가운데 주된 채무와 부수적 채무를 구별함에 있어서는 급부의 독립된 가치와는 관계없이 계약을 체결할 때 표명되었거나 그 당시 상황으로 보아 분명하게 객관적으로 나타난 당사자의 합리적 의사에 의하여 결정하되, 계약의 내용·목적·불이행의 결과 등의 여러 사정을 고려하여야 한다(대법원2005. 11. 25. 선고 2005다53705, 53712 판결 등 참조).
(2)미완성 시 기성고에 따른 개발대금 지급
도급계약에서의 보수는 그 완성된 목적물의 인도와 동시에 지급하여야 하고, 인도를 요하지 않는 경우 일을 완성한 후 지체 없이 지급하여야 하며, 도급인은 완성된 목적물의 인도의 제공이나 일의 완성이 있을 때까지 그 보수 지급을 거절할 수 있는바,
위와 같은 법리는 소프트웨어 개발·공급계약에도 마찬가지로 적용되므로, 소프트웨어가 거의 완성되어 약간의 보완을 가하면 업무에 사용할 수 있는 정도인데도 도급인이 프로그램의 내용에 대하여 불만을 표시하며 수급인의 수정, 보완 제의를 거부하는 것과 같은 특별한 사정이 없는 한 소프트웨어 개발·공급을 완성하지 못한 수급인은 기성 부분의 보수를 청구할 수 없다. [대법원 2014. 6. 12. 선고 2014다10014(본소), 2014다10021(반소) 판결 참조].
4.법원의 판단 – 개발자의 기성고에 따른 대금 일부 청구 인정
원고가 제3자를 통하여 이 사건 시스템을 대체하는 내용의 MES 시스템을 개발하게 됨으로써 원고와 피고가 더 이상 이 사건 계약에 따른 피고의 이 사건 시스템 구축 의무의 범위를 확정하고 피고가 그 의무를 이행하는 것이 사실상 불가능하게 되었고, 이로써 피고는 그에 해당하는 의무 이행을 면하는 이익을 얻게 된 점 등의 사정을 종합하면, 이 사건 계약에 따른 피고의 대금 청구권은 공평의 원칙 또는 신의성실의 원칙에 따라 약정된 대금의 89.875%로 제한함이 타당하다고 봄이 타당하다.
법리 – “도급에 관한 민법 제668조는 “도급인이 완성된 목적물의 하자로 인하여 계약의 목적을 달성할 수 없는 때에는 계약을 해제할 수 있다”고 규정하고 있는 바, 여기서 계약의 목적을 달성할 수 없다는 것은, 그 하자가 중대하고 보수가 불가능하거나 가능하더라도 장기간을 요하는 등 계약해제권을 행사하는 것이 정당하다고 인정되는 경우를 의미한다(대법원 2010. 6. 10. 선고 2010다10252 판결 참조).
2. 개발능력 부족 및 중대하자 - 개발계약의 해제 사유 인정
이 사건 부동산플랫폼에 존재하는 하자는 중대한 하자이고, 수급인 피고의 역량으로 보수가 불가능하거나 또는 가능하더라도 장기간을 요하는 경우로서 ‘하자로 인하여 이 사건 도급계약의 목적을 달성할 수 없는 때’에 해당한다고 봄이 상당하다.
3. 개발계약의 해제 및 대금반환 의무
발주자 원고는 이를 이유로 이 사건 도급계약을 해제할 수 있고, 원고의 해제 의사표시에 따라 이 사건 도급계약은 해제되었고, 이에 따라 개발자 피고는 원고에게 원상회복의무의 이행으로 지급받은 돈 및 이에 대한 받은 날로부터 이자 또는 지연손해금을 가산하여 반환하여야 한다.
4. 미완성이나 일부완성의 기성고에 따른 보수 인정 여부
개발자 주장요지 - 이 사건 목적물에 대한 개발이 상당히 이루어졌으므로 원고의 이 사건 도급계약 해제 통보로 이 사건 계약관계가 중도에 해소되더라도 수급인인 피고는 당시까지의 보수를 청구할 수 있고, 피고가 지급받은 돈은 그 보수에 미치지 못하므로 결국 피고로서는 반환할 금액이 없다는 취지의 주장을 한다.
법원 판단 – 개발완성 부분의 사용가치 불인정, 기성고에 따른 일부보수 청구권 불인정
도급계약에서 수급인은 원칙적으로 일을 완성하여야 보수를 청구할 수 있고, 다만 이미 공급되어 설치된 목적물의 완성도가 약간의 보완을 가하면 업무에 사용할 수 있을 정도로서 이미 완성된 부분이 도급인에게 이익이 되는 경우 그 계약관계가 도급인의 해제통보로 중도에 해소되었다면 수급인은 당시까지의 보수를 청구할 수 있다고 할 것이나(대법원 1996. 7. 30. 선고 95다7932 판결 참조), 이 사건 부동산플랫폼의 완성 부분이 원고에게 이익이 된다고 볼 뚜렷한 증거가 없다.
소프트웨어의 개발, 공급과 관련한 계약은 성질상 처음부터 기능장애가 전혀 없는 완벽한 상태로 프로그램이 개발되는 상황을 상정하기 어려운 점에 비추어 보더라도 위 사이트에 관하여 오픈 후 지속적인 수정, 보완이 이루어졌다는 사실로써 개발의 전 단계인 원고의 업무가 완성되지 않았다는 점을 인정할 근거는 될 수 없는 점,
개발자 원고가 발주자 피고에 대하여 최종 산출물의 검수를 요청하였을 때 피고는 계약의 직접 당사자로서 검수를 실시할 책임이 자신에게 있음에도 이를 계약 발주자에게 미루며 명확한 답변을 하지 않은 점(위에서 본 이 사건 계약서 제11조 규정에 따르면 이를 검수 합격으로 간주할 여지가 있다),
발주자 피고는 개발자 원고가 일부 업무를 이행하지 않았다고 주장하나, 일부 증거만으로는 당초의 계약 대비 원고의 미이행 부분이 구체적으로 특정되지 않고, 발주자 피고가 주장하는 사항들이 위 고도화사업 진행 과정에서 추가로 요구한 사항이거나 일단 이행된 부분에 관하여 수정을 요구한 사항일 가능성도 있는 점 등을 종합하여 보면,
이 사건 계약에 기한 개발자 원고의 업무는 일단 마지막 단계까지 진행되어 이 사건 협약상 ‘맡은 업무 완료’ 조건은 충족되었다고 봄이 타당하고,
설령 일부 보완할 부분이 남아 있다고 하더라도 이는 계약의 미이행 문제가 아니라 완성물의 하자 문제에 불과하다 할 것이다
제10조(계약의 해지) 1. 발주자(피고)는 다음 각 호의 협력 사업의 성실한 이행을 요구하고, 개발자(원고)가 이를 불이행하거나 시정할 의사가 없다고 판단한 경우 원고에게 본 계약의 해지를 요구할 수 있다.
1) 발주자의 시정 요구를 개발자가 정당한 사유 없이 이행하지 않을 때
4. 개발자의 책임으로 계약이 해지되는 경우 기지급된 계약금 등을 반환하는 것으로 본 계약이 종료되며, 지금까지 제작된 일체의 성과물은 발주자의 소유로 한다.
2. 발주자(피고)의 계약해지 통지
발주자는 여러 차례 납품기한을 연장해 주었음에도 현재까지도 개발이 완료되지 않았으므로, 이 사건 용역계약서 제10조에 따라 이 사건 용역계약을 해지하고 지급받은 계약금액 전부와 현재까지 제작된 일체의 성과물을 발주자(피고)에게 반환하라.’는 취지의 내용증명 발송
3. 법원의 판단 – 발주자의 일방적 해지 불인정
용역계약서 제10조 제1항은, 발주자의 시정 요구를 개발자가 정당한 사유없이 이행하지 않거나 이행할 의사가 없다고 판단될 때 발주자는 계약을 해지할 수 있고, 제10조 제4항은, 제10조 제1항에 따라 계약을 해지할 경우, 즉 개발자의 책임으로 계약을 해지할 경우 ‘개발자는 지급받은 용역대금 전액을 발주자에게 반환하고, 그 때까지 제작된 일체의 용역 결과물까지 발주자의 소유로 한다.’라고 규정하고 있어 그 내용이 개발자(원고)에게 매우 불리함을 알 수 있다.
대법원 판례 중에는 공사도급계약과 유사하게 소프트웨어 개발, 공급계약에 대해서도 ‘일종의 도급계약으로서 수급인은 원칙적으로 일을 완성하여야 보수를 청구할 수 있으나, 도급인 회사에 이미 공급되어 설치된 소프트웨어 완성도가 87.87%에 달하여 약간의 보완을 가하면 업무에 사용할 수 있으므로 이미 완성된 부분이 도급인 회사에게 이익이 되고, 한편 도급인 회사는 그 프로그램의 내용에 대하여 불만을 표시하며 수급인의 수정, 보완 제의를 거부하고 나아가 수급인은 계약의 당사자가 아니므로 상대하지 않겠다고 하면서 계약해제의 통보를 하였다면, 그 계약 관계는 도급인의 해제통보로 중도에 해소되었고 수급인은 당시까지의 보수를 청구할 수 있다고 인정한 사례’가 있고(대법원 1996. 7. 30. 선고 95다7932 판결 참조),
일반 원칙으로 돌아가더라도, 수급인이 자신의 귀책사유로 일을 완성하지 못하였다면 도급인에게 보수를 청구할 수 없을 것이나, 그 때까지 성과물은 수급인에게 귀속된다고 보아야 할 것이다.
그런데 이 사건 용역계약은 개발 완성도와 무관하게 ‘발주자(피고)의 시정 요구를 개발자(원고)가 정당한 사유 없이 이행하지 아니하여 발주자(피고)가 계약을 해지할 경우’ 개발자(원고)가 지급받은 보수를 반환하여야 함은 물론, 그 때까지 진행한 용역 성과물까지 피고에게 귀속된다는 것으로 원고에게 매우 불리하므로, 설령 위와 같은 계약 내용이 유효하다고 하더라도, ‘원고가 정당한 사유없이 피고의 시정 요구를 이행하지 아니하였는지’는 엄격하게 해석할 필요가 있다.
