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

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

1.    개발계약서의 주요 조항

제8조(계약의 해지, 피해보상) 1. 본 계약의 당사자 중 어느 일방이 본 계약서상의 의무 불이행이 있거나, 기타 불성실등으로 인하여 본 계약의 지속이 어려울 경우 귀책사유가 없는 당사자는 2주 전에 사전 통보로 상대방에 대한 그 시정을 촉구할 수 있으며 본 계약 기간 내에 적정한 조치가 없을 경우 당사자 간의 합의 하에 본 계약의 일부 또는 전부를 해지할 수 있다.

3. 발주자 피고의 귀책사유로 인해 계약이 해지될 경우 피고는 계약금액과 기 지급대금의 금액을 정산하여 해지일로부터 30일 이내에 원고에게 지급하며, 개발자 원고의 귀책사유로 인한 계약이 해지될 경우 피고의 피해액을 법적으로 산정하여 원고는 그 피해액을 피고에게 지급한다.

제9조(중간 보고/ 완료 검수)

2. 프로젝트 중간보고는 BPR 컨설팅 이후 분석 및 설계 자료 제출과 함께 진행하는 것으로 한다. 또한, 피고는 구축 단계에서 원고가 판단할 수 없는 사항 및 의사결정에 대해서 신속한 지원을 하여야 한다. 원고는 이에 따른 지체에 대한 부분이 지속적으로 발생할 경우 서면으로 최종요청 후 이행되지 않은 사항은 책임지지 않는 것으로 한다.

3. 추가 개발 사항에 대해서는 업무 분석 단계에서 요청된 사항에 대해서 진행을 하고 공수 내에서 추가 요청 사항을 검토하는 것으로 한다.

4. 프로젝트 완료 시 원고는 완료보고서를 피고에게 제출하며, 피고의 책임자는 이 완료보고서와 시스템 구축 제안서 그리고 합의된 개선대책서를 토대로 검수하고, 검수확인서를 피고가 원고에게 전달함으로써 통합 시스템 구축이 완료된 것으로 한다.

5. 피고는 원고의 검수 요청 접수일로부터 30일 이내에 검수확인서를 작성하여 원고에게 전달하여야 하며, 동 기일이 경과한 경우에는 검수 완료된 것으로 한다. 단, 완료보고서 검토 시 피고로부터 이의가 제기되었을 경우에는 원고는 즉각적으로 보완하여 검수를 재요청하여야 한다.

2.    개발자의 착수보고 및 이후 중간보고 불발

개발자는 발주자에게 과업 범위, 추진 전략, 사후 관리방안에 관한 자료(이하 ‘착수보고자료’라 한다)를 제출하였다. 착수보고자료에는 이 사건 프로젝트를 10개월에 걸쳐 착수/계획 – 분석 – 설계- 통합 – 전개 단계 순서로 진행하는데, 5. 30. 이전 분석을 완료하고, 설계 단계는 6월 말 중간보고를 하며, 최종 완료보고는 2월 말에 하는 것으로 기재되어 있다.

착수보고자료에서 과업범위와 관련한 컨설팅 수행 방안으로 “① 기존 시스템과 협의를 통해 업무 분장안을 도출하여 신규시스템 표준안에 요구사항/GAP을 반영하는 최적화된 통합시스템 구현, ② 조직별(법인별/회사별/부서별) 조직도 재설계, 직군별(영업/관리/회계 부서 등) 실적 기준 설정, 개인별 편의 기능 반영을 통한 프로세스 표준/최적화, ③ 업무 설정 기능과 입력 간소화 기능, 개인화된 메뉴 설정 기능 등의 시스템 기반의 컨설팅을 통해서 업무의 단축을 통한 효율성 증대, ④ 종이 없는 사무 환경 구축을 위한 다양한 업무 기능의 GW기반의 시스템 결제 기능 구현, ⑤ 표준 업무 흐름의 정의, 시스템 도움말 기능 정의, 사용자 매뉴얼 작성을 통한 개인의 역량 증대”를 제시하였고, 컨설팅 수행을 통한 산출물로 ① 현업 업무 인터뷰 분석서, ② AS-IS Process Map, ③ GAP 분석서, ④ 업무별 TO-BE Prosess Map을 적시하였다. 그 밖에 착수보고자료에는 세부 항목별로 제안요청 수용사항, 각 분야별 ERP 구축방안, 유지보수방안에 관하여 세부사항이 기재되어 있다.

원고와 피고는 1차 중간보고와 관련한 산출물의 제출을 두고 보완과 재요청 등을 거듭하였고, 원고의 1차 중도금 지급 요청에도 피고는 이 사건 계약에 따른 검수보고 승인이 이루어지지 않았다는 이유로 이를 지급하지 않았다. 개발사에 일방적으로 원고 측에 잘못이 있다고 미루는 등 피고의 잘못으로 이 사건 프로젝트의 진행이 어렵다는 이유로, 이 사건 계약 제8조 제1항, 제3항을 근거로 이 사건 계약의 해지를 통보하였다.

3.    중간보고 불발 및 계약파탄의 책임소재 – 법원 개발자 책임 인정

근본적으로 개발자 원고가 분석 및 설계 단계에서 피고에게 피고의 요구사항을 정리하는 데 필요한 구체적인 자료를 미리 제공하지 않았을 뿐만 아니라, 설계 확정 활동을 명확히 하지 않았기 때문으로 보인다.

원고와 피고가 TO-BE Process 확정 과정에서 지속적인 수정사항이 발생하고, 산출물에 오류가 발생하며, 일부 기능에 대한 요구사항 확정 미흡이 발생한 것은 원, 피고가 분석 단계에서 요구사항 확정을 완료하지 않았기 때문으로 보인다.

이 사건 프로젝트의 기술적이고 전문적인 부분을 담당하는 자는 원고이고, 원고가 이 사건 프로젝트에 대한 보다 상세한 지식을 보유하고 있으므로, 분석 및 설계 업무가 제대로 완료될 수 있도록 피고에게 필요한 정보를 구체적으로 요청하고, 그에 필요한 구체적인 일정을 제시하는 것 역시 원고의 업무에 해당한다. 피고는 원고가 요구하는 자료를 원고에게 제공하였고, 원고의 협조요청에도 전반적으로 응한 것으로 보이는바, 그럼에도 불구하고 1차 중간보고 시까지 설계업무가 완료되지 않은 것은 이 사건 프로젝트를 주도적으로 진행할 의무가 있는 원고의 잘못 때문인 것으로 봄이 타당하다.

4.    개발자의 ERP 패키지 대금 및 기성고 주장 – 법원 불인정

ERP 패키지에 관한 기술을 보유한 제3의 업체가 있다면 원고가 수행한 부분에 이어 이 사건 프로젝트를 계속할 수 있을 것이나, 그렇지 않은 경우 원고가 수행한 부분을 그대로 이어서 이 사건 프로젝트를 진행하는 것이 불가능하다.

이 사건 프로젝트에 사용된 ERP 패키지의 지식을 보유한 제3의 업체가 존재하지 않아 피고로서는 이 사건 프로젝트 전부를 폐기하여야 한다.

다만, 원고가 이 사건 프로젝트를 수행하는 과정에서 작성한 자료들 중 일부는 향후 피고가 동일한 업무를 진행하면서 기술적인 영역 외에서 일부 활용이 가능할 수 있을 것으로 보이는 점, 피고 역시 이 사건 프로젝트의 전체 일정에 관한 원고의 입장을 고려하지 않고 일방적으로 피고 측의 요구사항만을 앞세우거나 요청사항을 추가하는 등으로 일정 지연을 초래한 측면이 있고, 원고와의 원만한 협의를 통해 이 사건 계약을 지속하기 위한 노력을 다하지는 않은 것으로 보이는 점 등 이 사건 변론에 나타난 여러 사정을 참작하면, 공평의 원칙상 원고의 손해배상책임을 50%로 제한한다.

첨부: 서울남부지방법원 2021. 12. 10. 선고 2018가합100848 판결

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

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 판결

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

어떤 저작물이 다른 저작물의 저작권을 침해하였다고 인정하기 위해서는 침해 저작물이 피침해 저작물에 의거하여 작성된 것이라는 점과 양자 사이에 실질적 유사성이 있음이 입증되어야 합니다.

저작권의 보호 대상은 학문과 예술에 관하여 사람의 정신적 노력에 의하여 얻어진 사상 또는 감정을 말, 문자, 음, 색 등에 의하여 구체적으로 외부에 표현한 창작적인 표현형식이고, 표현되어 있는 내용 즉 아이디어나 이론 등의 사상 및 감정 그 자체는 설사 그것이 독창성, 신규성이 있다 하더라도 원칙적으로 저작권의 보호 대상이 되지 않는 것이므로,

저작권의 침해 여부를 가리기 위하여 두 저작물 사이에 실질적인 유사성이 있는가의 여부를 판단함에 있어서도 창작적인 표현형식에 해당하는 것만을 가지고 대비하여야 한다(대법원 2009. 5. 28. 선고 2007다354 판결, 대법원 2000. 10. 24. 선고 99다10813 판결 등 참조).

저작권 침해 여부를 가리기 위하여 두 저작물 사이에 실질적 유사성이 있는지 여부를 판단함에 있어서 창작적인 표현형식에 해당하는 것만을 가지고 대비해 보아야 하고, 표현형식이 아닌 사상이나 감정 그 자체에 독창성, 신규성이 있는지 등을 고려하여서는 안된다(대법원 99다10813 판결, 대법원 2009도291 판결 등 참조).

다른 사람의 저작물을 무단 복제하면 복제권을 침해하는 것이고 이 경우 저작물을 원형 그대로 복제하지 아니하고 다소의 수정·증감이나 변경을 가하더라도 새로운 창작성을 인정할 수 없는 정도이면 단순한 복제에 해당한다(대법원 2010. 2. 11. 선고 2007다63409 판결, 대법원 1989. 10. 24. 선고 89다카12824 판결 등 참조).

반면에 어떤 저작물이 기존의 저작물을 다소 이용하였더라도 기존의 저작물과 실질적인 유사성이 없는 별개의 독립적인 새로운 저작물이 되었다면, 이는 창작으로서 기존의 저작물의 저작권을 침해한 것이 아니다(대법원 2010. 2. 11. 선고 2007다63409 판결 참조).

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

1. 도급계약 vs 위임계약

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. 미완료 상황에서 계약해제 및 책임분쟁 – 명시적 계약조항에도 불구하고 미완성 부분만 실효, 불리한 계약조항 제한해석: 서울중앙지방법원 2017. 5. 16. 선고 2015가합582641 판결

사안의 개요

(1) 발주회사 조선회사 스마트용접 시스템 구축 사업 계약체결, 복수 사업장에서 단계적으로 진행 중 계약내용대로 완료하지 못한 상태에서 중단됨

(2) 중단 사유 – 발주회사 ERP 시스템교체, 새로운 시스템과 연동 테스트 등 문제, 조선업계 불황으로 발주회사 구조조정, 담당직원 퇴직 등으로 업무장애 발생, 사실상 사업추진 불가능 상황에 도달함

계약조항

“합의한 기한 내에 발주회사가 요구하는 품질의 물품이 공급되지 않을 시 발주회사는 즉시 계약을 해제할 수 있으며, 계약해제 시 개발, 납품회사는 원상 회복 및 손해배상의 의무를 진다.”

쟁점 – 미완료 도중 계약 종료 시 계약의 실효 범위, 대금지급의무 및 그 범위

판결요지

피고 개발회사가 계약에서 정한 일부 스마트 용접기를 공급하지 못한 것은 사실이나, 이미 구현된 부분만으로도 원고 발주회사에 이익이 되었다고 할 것인 바,

발주회사가 계약에서 정한 바에 따라 해제권을 행사하더라도 공급하지 않은 부분에 대하여만 실효된다고 봄이 타당하다.”

2. 웹디자인 개발용역계약, 발주회사와 개인 프리랜서 개발자 사이 분쟁, 결과물 납품 후 검수 시 완성도 미흡으로 인수거절 통지 – 발주회사에서 채무불이행 계약해제 및 계약금 등 지급한 개발비 반환청구 – 일부 인정, 일부 불인정: 서울중앙지방법원 2018. 11. 1. 선고 2017가단5073071 판결

개발결과물 검수 및 실패 통지

내용증명 우편으로 “피고들이 제출한 용역결과물에 대해 검수한 결과 계약 목적을 달성할 수 없는 상태로 판명되었고, 피고들이 향후에도 계약을 이행할 의사나 능력도 없는 것으로 판단되어 계약을 해제하므로 이에 따른 원상회복으로 피고들이 수령한 계약금을 반환하고 개발 지연에 따른 손해배상의무를 이행하지 않을 경우 민 • 형사상 조치를 취하겠다”는 취지의 통지(이하 ‘이 사건 통지’라 한다)를 하였다.

추가 개발요구 사항 – 법원 수정계약의 내용으로 인정

이 사건 개발계획의 범위는 위와 같이 “이 사건 최소 개발항목 뿐만 아니라 이 사건 추가 개발항목도 모두 포함하여 이 사건 개발일정표상에 기재된 전체의 기능들이 개발 및 구현되어 통상적인 의미의 상업적 서비스가 가능한 정도의 완성도를 가지는 결과물을 제출하는 것”이라고 보아야 하므로

이 사건 수정계약상 정하여진 피고의 업무범위 내지 개발범위를 확정함에 있어 단순히 피고들이 주장하는 ‘Pivotal Tracker’에 입력된 부분에만 한정되는 것으로는 볼 수 없다(피고들이 주장하는 위 ‘Pivotal Tracker’에 입력된 부분은 이 사건 최소 개발항목과 대부분 일치한다).

나아가 이 사건 개발일정표 전체 항목(즉, 이 사건 최소 및 추가 개발항목)을 포함시키되, 보충적으로 이 사건 수정계약서의 해당사이트에 연결(링크)되어 파일 형태로 첨부된 서비스기획서(이하 ‘이 사건 기획서’라 한다)의 내용도 참조해야만 이러한 개발용역의 내용과 범위를 비로소 올바르게 확적할 수 있다고 보아야 한다.

추가 개발요구 사항과 개발실패 책임소재 – 법원 수정계약상 연장된 기한으로 해결, 최종족으로 개발자의 귀책사유

피고는 이 사건 수정계약의 이행이 그동안 지연된 이유에 대해 원고가 지속적으로 기획과 디자인을 변경하거나 업데이트를 함으로써 피고들의 작업 일정도 2017. 3. 7.의 시한을 맞추지 못한 채 지연될 수밖에 없었다는 취지로 주장하나,

우선 앞서 본 바와 같이 이 사건 기획서도 피고들의 업무 범위에 포함되어 있고, 나아가 이 사건 수정계약 체결 단계에서부터 소프트웨어 개발 작업의 특성상 이러한 기획의 변경이나 수정은 어느 정도 예정되어 있었던 것으로 보아야 하며, 피고 B도 이러한 분야의 전문가로서 이러한 사정을 이해하고 있었던 것으로 보인다.

또한, 이 사건 개발일정표에서도 디자인 결과물이 2017. 1. 21.까지 나오지 못하는 경우에는 그 디자인이 적용된 기능들을 완성하는데 차질이 있을 수 있다는 점을 당사자들이 감안해 주기로 합의한 것도 바로 이러한 사정들 때문인 것으로 보이고,

이러한 이유들로 인하여 향후 만일 개발 작업이 어떤 사유로든 지연되는 경우에는 2017. 3. 7. 계약 종료 전에 계약연장을 통해서라도 이 사건 수정계약상의 개발계획을 완료하기로 약정한 사실도 있으므로, 피고들이 주장하는 위와 같은 원고 측 지연사유는 이 사건 수정계약 위반 사유가 될 수 없고, 또 피고 B의 채무불이행을 정당화할 수 있는 사유도 될 수 없다고 보아야 한다.

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