Kasan Insight :: 과학, 기술 그리고 법

- 제약/화학/바이오 분야의 실용적 법률정보와 해결방안

1.    ERP 개발계약서 특약 조항 및 당사자 주장요지 

(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 연동작업에 필요한 테스트 환경도 피고의 부담으로 구축하여야 한다는 취지였다면, 피고로서는 위와 같이 원고에게 각 보고를 함에 있어 그 초기 단계부터 이에 관한 현황 분석 및 일정 수립, 구체적 작업 내용 등을 명시하였어야 할 것이고, 원고로서도 피고에게 보고서에 위와 같은 내용을 명시하거나 별도의 추가 보고를 하도록 요구하였어야 할 것임에도 이에 관한 별다른 자료가 없다.

첨부: 서울고등법원 2023. 1. 12. 선고 2022나2001273 판결

[질문 또는 상담신청 입력하기]

(1)   소프트웨어 개발계약 성질 – 도급 계약: 당사자의 일방이 상대방의 주문에 따라 자기 소유의 재료를 사용하여 만든 물건을 공급하기로 하고 상대방이 대가를 지급하기로 약정하는 이른바 제작물공급계약은 그 제작의 측면에서는 도급의 성질이 있고 공급의 측면에서는 매매의 성질이 있어 대체로 매매와 도급의 성질을 함께 가지고 있으므로, 그 적용 법률은 계약에 따라 제작 공급하여야 할 물건이 대체물인 경우에는 매매에 관한 규정이 적용되지만, 물건이 특정 주문자의 수요를 만족하게 하기 위한 부대체물인 경우에는 당해 물건의 공급과 함께 그 제작이 계약의 주목적이 되어 도급의 성질을 띠게 된다(대법원 2006. 10. 13. 선고 2004다21862 판결 등 참조). 이러한 법리는 계약의 목적물이 유형물이 아니고 무체물인 전산프로그램인 경우에도 마찬가지로 적용된다고 봄이 타당하다.

(2)   소프트웨어의 성격상 전체적인 기능이 구현되어 있어도 일부 부속품의 기능이 부족하거나 결함이 있는 경우, 전체적인 시스템의 목적을 달성하지 못하게 되는 경향이 있다. 또한 소프트웨어를 통해 기본적으로 실행되어야 하는 기능에 지속적인 오류 또는 오작동이 발생하거나, 호환성이 결여되어 하드웨어나 다른 프로그램과의 상호작용이 제대로 이루어지지 않고 이러한 현상이 소프트웨어 설치 초기에 이루어지는 안정화 작업을 거친 이후에도 지속된다면, 이는 당해 소프트웨어 자체의 하자로 볼 여지가 크다.

(3)   이러한 소프트웨어상 오류 내지 오작동으로 인한 하자가 실제 존재하는지 여부를 판단함에 있어서는 오류가 발생한 부분이 전체 작업량에서 차지하는 비중, 오류가 전체 프로그램의 정상적인 작동과 업무의 흐름을 방해하는 정도, 프로그램을 도입하기 전후 정황, 계약 당사자가 계약을 체결하게 된 경위와 목적 등의 여러 사정들이 종합적으로 고려되어야 한다.

(4)   구체적 사안의 판단: 개발사에서 설치한 이 사건 시스템은 가동 속도의 현저한 지연, 작동 중단 등으로 인하여 발주사의 직원들이 정상적인 업무를 수행할 수 없거나 결재기능이 정상적으로 이루어지지 않는 등 중대한 하자가 발생함으로써, 효율적이고 신속한 시스템 개발이라는 이 사건 각 계약상 목적을 달성할 수 없게 되었다고 봄이 타당하다. 계약을 해제한다는 통지로 계약은 적법하게 해제되었다.

(5)   이 사건 시스템의 설계와 구축에 있어서 신속한 가동 속도를 현출하는 것은 이 사건 각 계약상 시스템을 공급하는 자로서 수행하여야 할 계약상 중요한 의무라고 봄이 상당하다.

(6)   업무 처리에 필요한 가동 속도는, 시스템을 사용하는 사용자들에게 기본적으로 요구되는 성능이다. 특히 발주 회사와 같이 패션 업종 회사들은 기획, 설계부터 제작, 재고 관리에 이르기까지 데이터를 효과적으로 정리하는 것이 필수적이고, 패션 디자인에 대한 작업지시서를 작성하는 데 대용량의 이미지 파일을 자주 사용하게 되므로, 이러한 업무를 수행하기 위해서는 해당 정보에 쉽고 빠르게 접근할 수 있도록 하는 것이 중요하다. 그렇다면 이 사건 각 계약상 시스템의 구동 속도가 어느 수준 이상이어야 한다는 점이 명시적으로 기재되어 있지 않더라도, 위와 같은 원고 회사의 업무 특성, 기존에 원고가 사용하던 PDM 시스템의 기능을 유지하면서 더 개선되고, 발전된 형태의 시스템을 도입하기 위하여 이 사건 시스템을 도입하기로 한 계약의 목적 등을 고려하여 보면, 이 사건 각 계약에서 요구되는 이 사건 시스템의 속도 기능은 적어도 원고가 기존에 사용하던 PDM 시스템을 사용할 당시의 가동 속도라고 보는 것이 양 당사자들의 의사에 부합한다.

(7)   이 사건 시스템에는 로딩속도 지연, 작동 중단 등 오류가 자주 발생하고, 과중한 부하가 걸릴 경우에는 속도가 현저하게 떨어져 정상적인 업무의 수행이 사회통념상 불가능할 정도에 이르는 하자가 존재한다고 봄이 타당하다.

(8)   직원들의 의견 - 직원들이 이 사건 시스템을 사용하면서 남긴 내부 회의록에 의하면, ‘잦은 오류 및 늦은 속도, 잦은 쿨타임으로 생산성이 저하되며 조작법이 불편함, 속도가 너무 느림, 업무를 진행할수록 계속적으로 나타나는 오류들에 대한 빠른 개선 필요, 시험 사용결과 프로그램 속도 원활하지 못한 부분도 있음, 시스템 불안정 및 작업의뢰서 검색까지 경로, 버퍼링이 김‘과 같은 의견이 개진되고 있다. 이 사건 시스템에서 통상 나타나는 객관적인 오류 내지 오작동의 중요한 징표라고 볼 수 있다.

첨부: 서울동부지방법원 2023. 4. 13. 선고 2020가합103489 판결

[​질문 또는 상담신청 입력하기]

1.    병원정보시스템 개발 실패, 계약해제 및 책임소재

(1)   개발계약상 해제사유: ‘개발회사의 귀책사유로 용역수행 기간까지 당해 용역을 완료하지 못하거나 완료할 가능성이 없다고 인정될 경우, 원고가 계획에 따른 용역수행 등 계약상 의무를 이행하지 않은 경우, 기타 계약 조건을 위반하고 그 위반으로 인하여 계약의 목적을 달성할 수 없다고 인정될 경우’ 계약을 해제할 수 있다.

(2)   용역계약서 상 실행계획서에서 정한 바에 따라해당 용역업무를 완료하지 못한 것으로 보이는 점, ② 용역계약 상의 용역업무를 수행하는 장소였던 병원에서 인력을 철수하여 용역업무의 진행중단되었으므로 용역계약 상의 목적인 용역업무의 완성은 달성하기 어려운 상태라고 할 것인 점

(3)   발주자 피고의 해제 의사표시에 의하여 그 의사표시가 원고에게 도달한 시점에 적법하게 해제되었다.

2.    시스템 개발 실패의 책임 소재 – 법원 개발자로 판단

개발자는 용역계약 상의 용역 의무를 이행하지 못한 것은 발주자 병원의 귀책사유에 의한 것이라는 취지로 항변한다.

(1)   용역계약 체결 후 발주자 병원에서 개발회사에 개발 범위에 대한 요구사항을 여러 번에 걸쳐 다수 전달하였던 것으로 보이나,

(2)   한편, 개발자는 IT 시스템을 구축하는 전문가로서 이 사건 용역계약 상 정하여진 용역업무를 수행함에 있어 피고의 요구사항을 듣고 이를 반영할 의무가 있다고 할 것인 점, 용역계약 상 결과물은 ‘분석, 설계, 구현, 시험’으로 이루어지는 과정을 통과하여야 하는데, 원고가 제출한 ‘업무요건정의서’ 내용에 비추어 원고는 피고가 요구하는 사항에 대하여 명확히 인지한 후 이를 분석하여 프로그램 정의를 명확하게 하였던 것으로는 보이지 않는 점, 원고가 작성한 ‘업무요건정의서’ 상의 기재 내용이 미흡하였던 이유로 원고가 최종적으로 목표로 하였던 시스템에 대한 설계 자체가 수행될 수 없었던 것으로 보이고, 실제로 용역계약을 완료함에 있어 필요한 설계도서가 확정되지 못하였던 것으로 보이는 점 등에 비추어 보면, 원고가 제출한 증거만으로는 원고가 이 사건 용역계약 상의 용역업무를 이행하지 못한 것에 대하여 발주자 병원(피고)에게 귀책사유가 있다는 점을 인정하기 부족하다.

3.    개발회사에서 기성고 62%에 상응하는 계약대금 주장 – 법원 불인정

용역계약은 병원의 환경에 적합한 업무용 응용프로그램을 개발하여 이를 병원에 구축하는 것을 주된 내용으로 하는 일종의 도급계약이다.

① 김정인은 최종 기성 비율을 61.14%로 산정하였으나, 이는 ‘이 사건 용역계약 체결 이후 원고와 피고가 입은 손실을 최소화한다는 차원에서 원고와 피고가 수행한 결과를 합리적으로 평가하여 기성고를 산정한 것’인 점,

② 한편으로 용역업무는 앞서 언급한 것과 같이 1단계 개발 부분에 속하는 ‘분석’ 업무가 완료되지 않았던 탓에 ‘설계’ 업무가 완성될 수 없었고, 그 결과 이 사건 용역계약 상 용역업무를 완성하는 데 필요한 설계도서가 마련되지 않았던 것으로 보이는 점,

③ 이러한 이유로 피고로서는 제3자에게 ‘원고가 만들어낸 결과물에 이어서 용역업무를 완성할 것’을 요구할 수는 없었던 것으로 보이는 점,

④ 감정인도 ‘쌍방이 합의한 설계도서가 없는 상태에서는 개발 기준이 확정되지 않은 상태이므로 현 상태 그대로 제3자가 업무를 완성할 수는 없다.’라고 감정하였는데, 위와 같은 취지에서 이와 같이 감정한 것으로 보이는 점,

⑤ 그렇다면 설령 원고가 이 사건 용역계약에 따른 용역업무를 일부 수행하여 결과물을 작성하였다 하더라도, 그 결과물을 피고가 이어받아 사용할 수 있었던 것으로 보기는 어렵고, 달리 원고가 만들어낸 결과물이 피고에게 이익이 되어 구체적인 기성 비율을 산정할 수 있는 정도에 이르렀다고 볼 만한 자료도 충분히 제출되었다고 보기는 어려운 점 등에 비추어 보면,

이 사건 용역계약 상 용역업무를 완성하지 못한 원고로서는 피고에게 기성 부분의 보수를 청구할 수 없다고 볼 것이다.

4.     발주자의 개발회사에 대한 지체상금 청구 – 법원 일부 인정

(1)   도급계약에서 미완성으로 계약해제 시 지체상금 조항에 따른 지체상금 인정 - 개발회사는 완성 불가에 따른 발주자에게 지체상금 지급 의무 있음

(2)   지체상금 계산: 지체상금의 종기는 도급인이 도급계약을 해제할 수 있었을 때부터 도급인이 다른 업자에게 맡겨 그 업무를 완성할 수 있었던 시점(대법원 2006. 4. 28. 선고 2004다39511 판결 등 참조)

(3)   다만, 법원은 계약상 산정된 지체상금의 30%만 인정

첨부: 대구지방법원 2022. 2. 10. 선고 2017가합207257 판결

[질문 또는 상담신청 입력하기]

1. 도급계약 vs 위임계약

통상 컴퓨터프로그램 등 소프트웨어를 개발하여 납품하는 계약은 도급계약으로 볼 수 있습니다. 도급계약은 당사자 일방이 일을 완성할 것을 약정하고 상대방이 그 일의 결과에 대하여 보수를 지급할 것을 약정함으로써 성립하는 계약입니다(민법 제664조). 즉, 도급은 일의 완성을 목적합니다. 특정 목적의 소프트웨어 프로그램 개발공급 계약에서 수급인 개발자의 급부의무는 도급인 발주자의 주문 사양에 맞추어 하자 없이 주문한 기능을 가진 프로그램을 개발하여 공급하는 것입니다.

판례도 “소프트웨어 개발·공급계약은 일종의 도급계약”이라고 하고, (발주자 – 도급인 vs 개발자 – 수급인 구도) 수급인은 원칙적으로 일을 완성하여야 보수를 청구할 수 있다고 판시하고 있습니다. 도급계약에서는 일의 완성 여부가 매우 중요한 핵심 사항입니다.

판결은 일단 완성되었다면, “발주자 도급인이 프로그램 내용에 대하여 불만을 표시하며 수급인의 수정 제의를 거부하면서 계약해제 통보를 하는 등 특별한 사정이 있다면 수급인은 당시까지의 보수를 청구할 수 있다”고 판시합니다.

반면, 컴퓨터프로그램의 납품에 중점이 있는 것이 아니고 전문가로서 개발업무를 수행하는 것 자체에 중점이 있는 경우라면 도급계약이 아니라 위임계약으로 볼 수도 있습니다. 위임계약의 대표적 예를 들면, 의사가 환자를 치료하고 대가를 받는 관계입니다.

2. 분쟁원인 - 프로그램 개발완성 여부

소프트웨어 프로그램 개발공급계약에서 완성여부에 대한 채무불이행 여부가 문제되는데, 수급인 개발자가 채무이행을 제대로 하였는지 여부는 당사자가 합의한 계약내용을 기준으로 판단될 것입니다.

그런데 소프트웨어 프로그램 개발공급계약은 실무상 합의내용을 구체적으로 명확하게 계약서에 반영하는 것이 상당히 어렵습니다. 개발대상 프로그램이 크고 복잡한 경우 그 요구조건, 사양, 내용, 시스템 등을 계약에 명확하게 반영하기 어렵습니다. 그 결과 계약내용에 대해 당사자 사이에 이해내용상 상당한 차이가 발생할 수도 있습니다. 그 결과 개발진행 후 일의 완성 여부에 대한 분쟁이 자주 발생하는 것입니다.

3. 프로그램개발의 완성 또는 미완성 판단기준

소프트웨어 개발납품 계약서에서 정한 기준에 따라 완성여부를 판단합니다. 계약서 문언에 따라 계약에 포함되어 있는 사양과 기능을 갖춘 제품의 개발, 그 이행 제공, 관련한 자료, 당시 관련 당사자들의 태도 등 제반 사정을 종합하여 판단합니다. 따라서 발주자와 개발자는 계약서에 프로그램의 목적과 기능을 구체적으로 특정하고, 정확하고 구체적으로 기재해야 하는 것이 바람직합니다. 통상 계약서에 첨부하는 ‘개발사항 명세서’에 관련 사항을 가능하면 상세하게 작성하여야 합니다.

소프트웨어 프로그램 개발 및 공급계약에서 일의 완성으로 보려면 계약상 예정된 최후의 공정까지 종료하였음과 함께 프로그램의 주요기능 부분이 약정된 대로 개발되어 사회통념상 일반적으로 요구되는 성능을 갖추고 있어야만 합니다. 또한 계약상 예정된 최후의 공정이 종료하였는지 여부는 개발자 수급인의 주관적인 주장이 아니라 개발 및 공급계약의 구체적 내용과 신의성실의 원칙에 비추어 객관적으로 판단해야 합니다.

개발자가 소프트웨어 개발의 일을 완성하고 이를 인도하면 발주자는 해당 소프트웨어 프로그램이 계약상 사양과 내용대로 완성되었는지 점검하여 수령하게 되는데, 법원은 제작물공급계약에서 목적물의 인도는 완성된 목적물에 대한 단순한 점유의 이전만을 의미하는 것이 아니라 도급인이 목적물을 검사한 후 그 목적물이 계약내용대로 완성되었음을 명시적 또는 묵시적으로 시인하는 것까지 포함한다고 봅니다.

그런데, 실무상 개발 납품한 프로그램이 계약상 요구사항을 모두 충족하였지만 발주자가 원하는 성능을 충분히 구현하지 못한다고 불만을 표시하면서 개발대금을 지급하지 않고 과도하게 보완을 계속 요구하는 경우가 있습니다. 이와 같은 하자 주장은, 법적으로 일의 완성과는 구별되는 다른 개념입니다. 하자가 있더라도 일이 완성되었다면 수급인은 도급인에게 보수의 지급을 청구할 수 있습니다.

하자여부도 일의 완성여부 판단, 그 완성도의 판단기준이 매우 중요합니다. 계약서에서 요구사항 각 항목을 특정하고, 목적하는 기능, 사용용도, 개발동기 등 배경사실을 기재하였거나 프로그램의 기능이 어떻게 구현되어야 하는지 등을 구체적으로 기재해 두었다면 완성여부 및 완성도를 판단하는데 큰 문제가 없을 것입니다.

발주자 도급인은 하자보수청구권을 가지므로 하자담보책임에 기한 항변을 행사하여 하자에 대한 보수 또는 그에 갈음하는 손해배상의 지금에 대한 대금의 지급을 거절할 수 있습니다. 그러나 하자를 이유로 대금 전부의 지급을 거절할 수는 없습니다.

정리하면, 발주한 소프트웨어 프로그램의 개발이 미완성인 때에는 대금지급을 거절할 수 있지만, 완성되었으나 하자가 있는 경우에는 발주자 도급인은 일의 완성을 요구하면서 대금지급을 거절할 수는 있습니다. 다만, 하자의 정도에 따라 대금감액 또는 손해배상을 청구할 수는 있습니다.

4. 완성된 소프트웨어 프로그램의 하자 관련 쟁점  

소프트웨어 개발 및 공급의 도급계약에 있어서의 하자는 완성된 일이 계약에서 정하거나 보증한 내용이 아니거나, 그 경제적 사용가치 또는 교환가치를 감소시키는 결함이 있거나, 또는 당사자가 미리 정한 사양 또는 기능을 가지지 못하는 등 결함을 말합니다. 그러나 하자의 정의는 모호하고 추상적이라 개별 사건마다 당사자간의 계약 내용을 검토하는 것이 중요합니다. 또한 계약상 합의된 사양과 내용과 함께 통상적인 용도에 적합한지 여부도 중요한 기준입니다.

납품 및 검수 후의 소프트웨어 버그에 대한 리포트를 받고 이를 즉시 보수하거나 도급인과 협의하여 상당한 조치를 취한 때에는 하자라고 보지 않을 것입니다. 그러나 도급인이 요구하는 구체적인 업무나 기능이 제대로 작동되지 않는 경우, 통신 및 인터넷과 연계된 컴퓨터 프로그램이 통신 및 네트워크와 연결하여서는 제대로 작동되지 않은 경우나, 컴퓨터 안에 보존된 다른 데이터 등을 잃어 버리는 경우 등은 하자에 해당합니다.

5. 최종 완성 전 개발 정도의 중간점검 및 계약변경시 입증자료 구비 필요 

컴퓨터 프로그램의 납품 후 계약에 따른 완성 여부를 다투거나 하자를 다투는 것보다 중간에 미리 점검하고 확인하는 것이 바람직합니다. 개발단계에 따라 단계별로, 또는 모듈별로 개발정도를 점검하거나 또는 기간에 따라 정기적으로 점검하는 것이 바람직합니다. 만약 당초 계약내용을 변경하거나 수정, 보완해야 한다면 중도에 추가 계약서를 작성하는 등 명시적 자료를 남기는 것이 좋습니다.

이때 게약사항의 수정, 변경으로 개발비용이 추가되는지 여부도 명확하게 결정해야 합니다. 그렇지 않으면 추가 비용의 부담에 관한 분쟁원인이 될 것입니다.

[질문 또는 상담신청 입력하기]

1.    사안의 개요

(1)   정부지원 MES 구축 사업 선정, MES 개발계약 체결  

(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%로 제한함이 타당하다고 봄이 타당하다.

첨부: 인천지방법원 부천지원 2021. 7. 15. 선고 2019가단10820 판결

[​질문 또는 상담신청 입력하기]