1. SW 개발납품 도급계약에서 개발범위, 납품기준, 완성여부
컴퓨터프로그램 소프트웨어의 개발납품 계약은 도급계약으로, 개발자(수급자)가 프로그램개발을 완성하여 납품하면 발주자가 그 보수, 용역대금을 지급하는 계약입니다. 개발자가 완성하여 납품하는 기준, 발주자가 요구하는 개발요구사항, 개발자의 개발범위를 명확하게 정하는 것이 매우 중요합니다. SW 개발공급계약서에서 프로그램의 목적과 기능을 구체적으로 특정하고, 해당 분야를 이해하는 개발자, 전문가의 검토를 거쳐 개발요구사항 및 개발범위를 기능별, 항목별로 구체적으로 정리하는 것이 바람직하고, 독립된 별지로 정리하여 첨부하면 분쟁을 예방할 수 있습니다. 원칙적으로 수급인 개발자는 개발완성을 입증할 책임 있고, 완성해야 보수(개발대금)을 청구할 수 있습니다.
프로그램개발의 완성 또는 미완성 판단기준: 소프트웨어 개발납품 계약서에서 정한 기준,예를 들어 개발요구사항 명세서, 개발범위 등에 따라 완성여부를 판단합니다. 계약서 문언에 따라 계약에 포함되어 있는 사양과 기능을 갖춘 제품의 개발, 그 이행 제공, 관련한 자료, 당시 관련 당사자들의 태도 등 제반 사정을 종합하여 판단합니다.
2. 개발납품 완료 후 하자보수 vs 미완성의 구별
소프트웨어 개발공급계약에서 미완성에 대해서는 대금지급거절, 채무불이행으로 인한 계약해제 또는 계약해지가 문제되지만, 완성, 납품 후에는 발주자는 용약대금지급 의무가 있고 다만 개발자에 대한 하자보수요구가 문제됩니다.
소프트웨어 프로그램 개발 및 공급계약에서 일의 완성으로 보려면 계약상 예정된 최후의 공정까지 종료하였음과 함께 프로그램의 주요기능 부분이 약정된 대로 개발되어 사회통념상 일반적으로 요구되는 성능을 갖추고 있어야만 합니다. 또한 계약상 예정된 최후의 공정이 종료하였는지 여부는 개발자 수급인의 주관적인 주장이 아니라 개발 및 공급계약의 구체적 내용과 신의성실의 원칙에 비추어 객관적으로 판단해야 합니다.
개발자가 소프트웨어 개발의 일을 완성하고 이를 인도하면 발주자는 해당 소프트웨어 프로그램이 계약상 사양과 내용대로 완성되었는지 점검하여 수령하게 되는데, 법원은 제작물공급계약에서 목적물의 인도는 완성된 목적물에 대한 단순한 점유의 이전만을 의미하는 것이 아니라 도급인이 목적물을 검사한 후 그 목적물이 계약내용대로 완성되었음을 명시적 또는 묵시적으로 시인하는 것까지 포함한다고 봅니다.
그런데, 실무상 개발 납품한 프로그램이 계약상 요구사항을 모두 충족하였지만 발주자가 원하는 성능을 충분히 구현하지 못한다고 불만을 표시하면서 개발대금을 지급하지 않고 과도하게 보완을 계속 요구하는 경우가 있습니다. 이와 같은 하자 주장은, 법적으로 일의 완성과는 구별되는 다른 개념입니다. 하자가 있더라도 일이 완성되었다면 수급인은 도급인에게 보수의 지급을 청구할 수 있습니다.
하자여부도 일의 완성여부 판단, 그 완성도의 판단기준이 매우 중요합니다. 계약서에서 요구사항 각 항목을 특정하고, 목적하는 기능, 사용용도, 개발동기 등 배경사실을 기재하였거나 프로그램의 기능이 어떻게 구현되어야 하는지 등을 구체적으로 기재해 두었다면 완성여부 및 완성도를 판단하는데 큰 문제가 없을 것입니다.
발주자 도급인은 하자보수청구권을 가지므로 하자담보책임에 기한 항변을 행사하여 하자에 대한 보수 또는 그에 갈음하는 손해배상의 지금에 대한 대금의 지급을 거절할 수 있습니다. 그러나 하자를 이유로 대금 전부의 지급을 거절할 수는 없습니다.
정리하면, 발주한 소프트웨어 프로그램의 개발이 미완성인 때에는 대금지급을 거절할 수 있지만, 완성되었으나 하자가 있는 경우에는 발주자 도급인은 일의 완성을 요구하면서 대금지급을 거절할 수는 있습니다. 다만, 하자의 정도에 따라 대금감액 또는 손해배상을 청구할 수는 있습니다.
3. 소프트웨어 프로그램의 완성, 납품 후 하자보수 또는 추가 개발계약
소프트웨어 개발 및 공급의 도급계약에 있어서의 하자는 완성된 일이 계약에서 정하거나 보증한 내용이 아니거나, 그 경제적 사용가치 또는 교환가치를 감소시키는 결함이 있거나, 또는 당사자가 미리 정한 사양 또는 기능을 가지지 못하는 등 결함을 말합니다. 그러나 하자의 정의는 모호하고 추상적이라 개별 사건마다 당사자간의 계약 내용을 검토하는 것이 중요합니다. 또한 계약상 합의된 사양과 내용과 함께 통상적인 용도에 적합한지 여부도 중요한 기준입니다.
납품 및 검수 후의 소프트웨어 버그에 대한 리포트를 받고 이를 즉시 보수하거나 도급인과 협의하여 상당한 조치를 취한 때에는 하자라고 보지 않을 것입니다. 그러나 도급인이 요구하는 구체적인 업무나 기능이 제대로 작동되지 않는 경우, 통신 및 인터넷과 연계된 컴퓨터 프로그램이 통신 및 네트워크와 연결하여서는 제대로 작동되지 않은 경우나, 컴퓨터 안에 보존된 다른 데이터 등을 잃어 버리는 경우 등은 하자에 해당합니다.
최초의 개발범위를 벗어난 추가 개발요구사항이 있는 경우 계약범위를 변경하는 추가 합의서를 첨부하거나 별도의 추가 개발계약을 체결할 수 있습니다. 추가 개발사항을 명시적으로 정리한 변경계약서 또는 추가 계약서가 없다면 기존 계약범위 내인지 추가 개발인지 여부가 불명확하여 분쟁의 소지가 있습니다. 추가 개발서를 별도 서면으로 작성하면, 추가개발에 대하여 상호 진지하게 고민하게 될 것이고, 그 추가 개발사항에 대한 분쟁도 줄어들 수 있습니다. 이때 추가 개발사항으로 개발비용이 추가되는지 여부도 명확하게 결정해야 합니다. 그렇지 않으면 추가 비용의 부담에 관한 분쟁원인이 될 것입니다.
4. 완성 전 중간점검, 중도해지, 계약변경 시 입증자료
컴퓨터 프로그램의 납품 후 계약에 따른 완성 여부를 다투거나 하자를 다투는 것보다 중간에 미리 점검하고 확인하는 것이 바람직합니다. 개발단계에 따라 단계별로, 또는 모듈별로 개발정도를 점검하거나 또는 기간에 따라 정기적으로 점검하는 것이 바람직합니다. 만약 당초 계약내용을 변경하거나 수정, 보완해야 한다면 중도에 추가 계약서를 작성하는 등 명시적 자료를 남기는 것이 좋습니다.
개발공급계약서에 개발진도 점검, 검수, 중도 계약해지에 대한 조건 등을 명확하게 규정하는 것이 좋습니다. 중간단계 완성여부, 점검, 검수기준을 정해두고, 기준 미충족 시 중도 해지조건까지 정해두지 않으면 상호간 자기 주장만 하고 진행되지 않는 난관에 봉착합니다. 어떤 경우에 계약해제 또는 해지를 할 수 있는지, 그 경우 어떻게 정산을 할지 명확하게 정리하는 것이 바람직합니다.
5. 개발 결과물의 납품 방식 및 저작권 귀속 사항
개발결과물을 어떤 방식으로 납품할 것인지, 그 결과물의 저작권 귀속에 대해 명확하게 정해 두어야 합니다. 통상 사용하는 SW 소유권 뿐만 아니라 그 저작권, 사용권을 갖는다는 점을 명확하게 정리하는 것이 필요합니다. 특히 당해 계약의 산출물인지 아니면 기존에 보유하고 있던 솔루션까지 포함한 것인지 등 명확하지 않으면 분쟁의 소지가 있습니다.
[질문 또는 상담신청 입력하기]
