하나. 하청 비교 위임장
일반적으로 컴퓨터 프로그램과 같은 소프트웨어의 개발 및 제공에 대한 계약 하청로 볼 수 있습니다. 하도급은 일방이 일을 하기로 하고 상대방이 그 일의 결과에 대하여 대가를 받기로 하는 계약입니다.
(민법664기사). 다시 말해서, 계약의 목적은 일을 끝내는 것입니다.
. 특정 목적을 위해 체결된 소프트웨어 프로그램 개발 및 공급 계약에서 개발자의 의무는 계약자의 주문 사양에 따라 정해진 기능을 갖춘 결함 없는 프로그램을 개발하여 제공하는 것입니다.
.
판례 “소프트웨어 개발·공급계약은 하청계약의 일종입니다.
“설명하다(소유자 – 계약자 비교 개발자 – 수신자 구성) 받는 사람은 원칙적으로 충분히보상을 청구할 수 있습니다내가 판단한다. 하도급에서 일을 끝내다매우 중요한 핵심 포인트입니다.
심판 완료되면“발주자 또는 시공자가 계획의 내용에 대하여 불만을 표시하고 계약해지를 통지함과 동시에 시공자의 변경제안을 거부하는 등 특별한 사정이 있는 경우 시공자는 그 전에 보상을 청구할 수 있다.
“내가 판단한다.
반면에, 컴퓨터 프로그램의 전달에 중점을 두지 않고 전문가로서 작업을 개발하는 데 중점을 둔 경우 하도급이 아닌 위탁 계약으로 간주될 수 있습니다.
. 위임장의 대표적인 예는, 의사가 환자를 치료하고 돈을 받는 관계입니다.
.
2. 논란의 원인 – 프로그램 개발이 완료되었습니까?
소프트웨어 프로그램 개발 및 공급 계약에서 계약 위반 문제가 있습니다.
, 시행사와 시공사가 의무를 제대로 이행했는지 여부는 양 당사자가 합의한 계약 내용에 따라 판단한다.
.
그러나 소프트웨어 프로그램 개발 및 공급 계약에 관한 한 계약 내용이 구체적이고 명확하게 실무에 반영되기 어렵다.
. 개발된 프로그램이 방대하고 복잡할 때의 요구사항, 사양, 세부 사항, 제도 등을 계약서에 명확히 반영하기 어려움. 따라서 계약 내용에 대한 양 당사자의 이해에는 상당한 차이가 있을 수 있습니다.
. 그러다 보니 개발 과정이 끝나면 작품의 완성도에 대한 논란이 자주 일어난다.
.
삼. 프로그램 개발 완료 여부를 판단하는 기준
소프트웨어 개발 및 제공 계약서에 명시된 기준완료 판단 기준. 계약에 따라 계약에 명시된 사양 및 기능으로 제품 개발, 구현 제공, 관련 데이터, 당시 모든 당사자의 태도를 포함한 전반적인 상황에 따라 결정을 내릴 것입니다.
. 따라서 소유자와 개발자는 계약서에 프로그램의 목적과 기능을 명시해야 하며,, 정확하고 구체적이고 싶다. 보통 계약서에 첨부 ‘개발 성명서‘최대한 자세하게 작성해야 합니다.
.
소프트웨어 프로그램 개발 및 공급 계약은 계약에 명시된 최종 프로세스를 완료해야 하며 프로그램의 주요 기능 부분은 계약에 따라 개발되고 일반적으로 사회 규범에서 요구하는 성능을 갖추어야 합니다.
. 또한 계약에 명시된 최종 프로세스의 완료 여부는 개발 및 공급 계약의 구체적인 내용과 신의 성실의 원칙에 따라 객관적으로 판단되어야 하며 개발자의 주관적인 가정에 근거할 수 없습니다.
.
개발자가 소프트웨어 개발 작업을 완료하여 납품하면 고객은 소프트웨어 프로그램이 계약의 사양 및 내용대로 완성되어 수령되었는지 확인합니다.
, 법원은 생산·공급계약에서 목적물을 인도하는 것은 단순히 목적물의 소유권을 이전하는 것일 뿐만 아니라 목적물이 합의된 대로 완료되었음을 명시적 또는 묵시적으로 합의한 것이라고 봤다.
대상 개체 검사 후 계약자.보다.
하지만, 실제로는 개발 및 납품 계획이 계약서에 명시된 모든 요구 사항을 충족하지만 발주자가 기대 성능을 완전히 구현하지 못한 것에 대해 불만을 표명하고 초과 보완을 계속 요구하며 개발 비용을 지불하지 않는 경우가 많습니다.
.. 이와 같은 진술은, 법적으로 작업 완료와는 다른 개념입니다.
. 공사 준공 등 하자가 있더라도 도급인은 도급인에게 보수를 청구할 수 있다.
.
결함은 또한 작업 완료 여부를 결정합니다.
, 완벽함을 판단하는 기준은 매우 중요합니다.
. 계약서의 모든 요구 사항을 명확히 합니다.
, 필요한 기능, 사용 목적, 개발 엔진과 같은 배경 사실이나 프로그램의 기능이 어떻게 구현되어야 하는지에 대해 자세히 설명하면 프로그램이 완전하고 완전한지 여부를 판단하는 데 큰 문제가 없을 것입니다.
.
계약자는 결함을 수리할 권리가 있으므로 보증 책임을 근거로 결함 수리 비용 또는 대신 손해 배상을 거부하는 방어를 행사할 수 있습니다.
. 단, 하자를 이유로 전액 지급을 거부할 수 없습니다.
.
요컨대, 주문한 소프트웨어 프로그램의 개발이 불완전한 경우 결제가 거부될 수 있습니다.
, 공사가 완료되었으나 하자가 있는 경우 발주자 또는 수급인은 공사의 준공을 요구하면서 대금지급을 거부할 수 있다.
. 하지만, 하자의 정도에 따라 가격 인하 또는 손해 배상을 청구할 수 있습니다.
.
4. 완성된 소프트웨어 프로그램의 결함과 관련된 문제
소프트웨어 개발 및 공급 계약에 결함이 있지만 계약서에 명시되거나 보장되지 않은 결함이 있는 경우, 경제적 사용가치나 교환가치를 감소시키는 결함이 있는 경우, 또는 당사자가 미리 정한 사양이나 기능 등의 결함이 없는 경우. 그러나 결함의 정의가 모호하고 추상적이므로 당사자 간의 계약 내용을 사례별로 검토하는 것이 중요합니다.
. 계약서에서 합의한 사양과 내용이 정상적인 사용에 적합한지 여부도 중요한 기준입니다.
.
소프트웨어 출고 및 검수 후 오류신고를 받고 즉시 수리하거나 계약자와 협의하여 중대한 조치를 취한 경우에는 하자로 보지 않습니다.
. 다만, 계약자가 요청한 특정 직무 또는 기능이 수행되지 않는 경우, 통신 및 인터넷에 연결된 컴퓨터 프로그램이 통신 및 네트워크에 연결된 상태에서 정상적으로 동작하지 않는 경우, 컴퓨터 등에 저장된 다른 데이터의 손실은 결함으로 간주됩니다.
.
5. 개발단계의 준공 전 중간점검 및 계약변경 증빙서류 작성
컴퓨터 프로그램이 전달된 후에는 계약대로 된 것인지, 하자가 있는지 따지는 것보다 미리 확인하는 것이 좋다.
. 개발 단계에 따라 단계별로, 또는 모듈별 또는 주기별로 개발 수준을 정기적으로 확인하고 싶을 수도 있습니다.
. 원래 계약서의 내용은 변경 또는 수정될 수 있습니다.
, 보완이 필요한 경우 중간에 추가 계약서를 작성하는 등 명확한 자료를 남겨두는 것이 좋습니다.
.
이때 계약서 수정, 또한 변경으로 인해 개발 비용이 증가하는지 여부를 명확하게 결정해야 합니다.
. 그렇지 않으면 추가 비용 부담에 대한 논란의 원인이 될 것입니다.
.
