계약형 시스템 개발에서 계약서의 주요 확인 포인트란?

경제산업성은 ‘정보 시스템의 신뢰성 향상에 관한 가이드라인’에서 IT 시스템 개발 계약에 대한 모델 조항을 제시하고 있습니다. 인터넷의 보급 등으로 인해 정보 시스템의 장애로 인한 업무·서비스의 중단이나 기능 저하의 사회적 영향은 점점 심각해지고 있으며, 시스템의 신뢰성·안전성 향상이 절실한 과제가 되고 있습니다. 한편, IT 시스템 개발이라는 계약 유형은 거래 내용이 불명확해지기 쉬운데, 이를 명확하게 하고, 역할 분담과 책임 관계를 명확히 하는 것이 이 조항의 목표입니다. 이 글에서는 IT 시스템 개발 업무에서 수임형 계약을 체결하는 경우의 계약서 체크 포인트에 대해, 경제산업성 모델 계약의 조항을 인용하면서 설명하겠습니다.

시스템 개발과 도급계약

도급계약이란

도급계약은 민법상 다음과 같이 규정되어 있습니다.

제632조
도급은, 계약 당사자 중 한 쪽이 특정 작업을 완성할 것을 약속하고, 다른 쪽이 그 작업의 결과에 대해 보수를 지불할 것을 약속함으로써 그 효력이 발생한다.

도급계약에서는, 조문상 ‘작업을 완성할 것을 약속’하는 것이 요건이 됩니다. 예를 들어, 기일까지 특정 시스템을 만드는 것을 계약의 목적으로 했을 경우, 벤더 측의 채무는 ‘기일까지 시스템을 완성하는 것’이 됩니다. 만약 약속한 기일까지 시스템을 완성하지 못했다면, 이행 지연으로 인한 채무 불이행 책임을 부과받을 수 있습니다. 그러나, 기일까지 시스템을 완성하여 인도한 후에 불량이 발견된 경우에는, 앞서 언급한 벤더 측의 채무는 이미 이행되었으므로, 채무 불이행은 문제가 되지 않고, 이후에는 하자 보증 책임의 문제가 됩니다. 시스템 개발에서, 어떤 경우에 ‘작업의 완성’이 인정되는지에 대해서는, 아래의 기사에서 자세히 설명하고 있습니다.

https://monolith.law/corporate/completion-of-work-in-system-development[ja]

위임 계약과의 차이점

도급계약에서는, 벤더는 작업 완성 의무를 부담하므로, 인도한 성과물에 하자가 있을 경우에는, 하자 보증 책임을 부담하게 됩니다. 이에 반해, 위임 계약에서는 작업 완성 의무가 없으므로, 도급계약과 같은 하자 보증 책임을 부담하지 않습니다. 그러나, 업무 처리 과정에서 선량한 관리 의무가 인정되는 경우에는, 별도로 손해 배상 등의 채무 불이행 책임을 부담할 수 있습니다. 어떤 책임이 시스템 개발 계약에서 문제가 되는지에 대해서는, 아래의 기사에서 자세히 설명하고 있습니다.

https://monolith.law/corporate/responsibility-system-development[ja]

위탁형 모델 조항 및 체크포인트

요구사항 정의 작성 지원 업무

요구사항 정의란, 위탁자가 구축하려는 시스템의 요구 사양을 정리하는 작업입니다. 요구사항 정의 과정에서는 시스템 구축의 방향성을 검토하고, 어떤 시스템을 구축할지 결정하는 작업이며, 결과물이 구체적으로 예상되지 않는 상황에서, 일본 경제산업성의 모델 계약은 준위임형으로 규정하고 있습니다. 자세한 내용은 아래의 기사에서 설명하고 있습니다.

https://monolith.law/corporate/system-development-contract-check-quasi-mandate[ja]

외부 설계서 작성 업무

（외부 설계서 작성 업무의 실시）
제○조 乙은 제○조에서 정한 개별 계약을 체결한 후, 본 업무로서 제〇조의 규정에 따라 확정된 요구 사항 정의서를 기반으로, 본 소프트웨어의 외부 설계서 작성 업무를 수행한다.

2. 외부 설계서 작성 업무를 실시할 때, 乙은 甲에게 필요한 협력을 요청할 수 있으며, 甲은 乙로부터 협력을 요청받은 경우 적시에 이에 응할 것이다.

외부 설계서 작성은 화면, 양식 등 인터페이스에 관련된 부분의 사용을 계획하는 업무입니다. 외부 설계서에는 원칙적으로, 그를 기반으로 벤더가 프로그램을 개발할 수 있는 정보가 모두 기재되어 있어야 합니다. 외부 설계서는 양식 사용을 상세화한 내용을 포함하고 있지만, 요구 사양을 변경할 수 있는 것은 업무 내용을 결정하는 위탁자 측입니다. 그러나, 외부 설계서 작성 업무의 전 단계의 성과인 요구 사항 정의서가 위탁자의 요구를 명확하게 정의하고 있고, 벤더가 완성시킬 작업 내용이 명확하게 되어 있는 경우에는, 외부 설계서의 작성에 대해, 수주형으로 벤더가 주체가 되어 계약을 체결할 수 있습니다.

제1항은, 본 공정이 수주형임을 고려하여, 벤더가 업무 수행의 주체임을 규정하고 있습니다. 그러나, 수주형 계약이라 하더라도, 외부 설계는 위탁자의 업무 내용의 확정에 관련된 부분이 크기 때문에, 위탁자의 적극적 참여가 요구됩니다. 따라서, 제2항은, 벤더는 위탁자에게 시스템 사양의 검토·결정에 필요한 협력을 요청할 수 있고, 위탁자는 적시에 이에 응할 것이라고 하여, 시스템 사양의 검토는 벤더와 위탁자의 공동 작업임을 명확하게 하고 있습니다.

（외부 설계서 작성 업무에 관한 개별 계약의 체결）
제○조 甲 및 乙은, 외부 설계서 작성 업무에 대해, 제〇조 제〇항에 기재된 거래 조건을 협의하여 결정하고, 외부 설계서 작성 업무에 관한 개별 계약을 체결한다.

외부 설계서 작성 업무의 범위 등에 대해서는, 이전 조항에서 정한 거래 조건에 따라, 개별 계약으로 결정하게 됩니다.

（외부 설계 검토회）
제○조 乙은, 외부 설계서 작성을 위해 필요한 사항의 명확화 또는 내용의 확인 등을 위해, 필요하다고 인정되는 빈도로, 외부 설계서 작성에 대해 제〇조에서 정한 연락 협의회(이하 이 절에서는 ‘외부 설계 검토회’라 한다.)를 개최하고, 甲은 이에 참가할 것이다.

2. 甲도, 외부 설계서 작성을 위해 필요하다고 인정할 때는, 甲이 외부 설계 검토회를 개최할 수 있으며, 乙은 이에 참가할 것이다.

3. 외부 설계 검토회에서의 검토 등에 의해, 甲이 요구 사항 정의서의 내용을 변경하려는 경우에, 작업 기간, 위탁료 등 개별 계약의 조건을 변경해야 하는 경우가 발생하면, 제33조(본 계약 및 개별 계약 내용의 변경)의 절차에 따를 것이다.

화면·양식 등의 인터페이스를 결정하는 외부 설계서 작성을 위해서는, 위탁자와 벤더의 협동 작업이 필수적입니다. 본 공정이 수주형이므로, 제1항에서는, 검토회의 주최는 벤더이며, 위탁자가 이에 참가하는 형태로 규정하고 있습니다. 외부 설계서 작성을 위해 필요한 사항의 명확화 또는 내용의 확인 등은 모두 외부 설계 검토회에서 이루어지며, 벤더 및 위탁자는 검토회에서의 검토 결과에 구속됩니다.

제2항은, 위탁자도 외부 설계서 작성 업무의 실시를 위해 필요한 경우에, 외부 설계 검토회를 개최할 수 있음을 규정하고 있습니다.
제3항은, 검토 등에 의해, 위탁자가 요구 사항 정의서의 내용을 변경하는 경우, 개별 계약에서 정한 작업 기간, 위탁료 등에 영향을 미칠 가능성이 있으므로, 다른 조항에서 정한 본 계약 및 개별 계약의 내용 변경 방법을 따르도록 하고 있습니다.

（외부 설계서의 납품）
제○조 乙은 개별 계약에서 정한 기일까지, 외부 설계서 및 외부 설계서 검수 요청서(겸 납품서)를 甲에게 납품한다.

본 공정이 수주형이므로, 벤더는 외부 설계서 등을 성과물로서 납품하게 됩니다.

（외부 설계서의 승인 및 확정）
제○조 甲은, 개별 계약에서 정한 기간(이하 ‘외부 설계서의 검사 기간’이라 한다.) 내에 외부 설계서가, 제〇조의 규정에 따라 확정된 요구 사항 정의서 및 제○조에서 정한 외부 설계 검토회의 결정 사항에 부합하는지, 그리고 논리적 오류가 없는지 검사할 것이며, 부합하고 논리적인 오류가 없음을 승인한 증거로서 甲과 乙의 책임자가 외부 설계서 승인서에 서명 및 날인할 것이다. 단, 검사 결과, 외부 설계서가, 제○조의 규정에 따라 확정된 요구 사항 정의서 및 외부 설계 검토회의 결정 사항에 부합하지 않는 부분 또는 논리적 오류가 발견된 경우, 乙은, 협의하여 정한 기한 내에 수정본을 작성하여 甲에게 제시하고, 甲은 다시 위의 검사, 승인 절차를 거칠 것이다.

2. 외부 설계서의 검사 기간 내에 甲이 문서로 구체적인 이유를 명시하여 이의를 제기하지 않는 경우에는, 甲은 외부 설계서의 검사 기간의 만료를 기점으로, 외부 설계서를 승인한 것으로 간주된다.

3. 앞의 2항에 따른 甲의 승인으로, 외부 설계서는 확정된 것으로 한다.

외부 설계 공정에서는, 이후의 내부 설계서 작성 등을 실시하기 위해 필요한 요구 사항을 확정합니다만, 요구 사항의 확정이 모호한 상태에서는, 이후의 개발에서 문제가 발생할 가능성이 있습니다. 본 조는, 이후의 개발 작업의 전제가 되는 외부 설계서를 위탁자가 검사하고, 위탁자의 승인으로 확정하는 절차를 규정하고 있습니다.

제1항은, 위탁자가, 다른 조항에서 확정된 요구 사항 정의서 및 외부 설계 검토회의 검토 결과와의 부합성 및 논리적 오류가 없는지를 검사하는 것을 규정하고 있습니다. 외부 설계서의 승인을 위한 검사에서 수정이 필요하다고 판단되는 경우도 있으며, 동 항 단서는 이 경우의 절차를 규정하고 있습니다.
제2항은, 승인의 서명 및 날인이 완료되지 않더라도 일정 기간 내에 위탁자로부터 이의가 제기되지 않으면, 위탁자에 의한 승인이 이루어진 것으로 간주하는 규정입니다. 위탁자의 승인 여부가 모호한 상태에서 내부 설계에 들어가는 것은, 나중에 문제를 일으킬 수 있으므로, 이러한 문제를 방지하려는 것이 본 항의 의도입니다.

그리고 제3항은, 위탁자의 승인으로 외부 설계서가 확정된다는 것을 정하고 있습니다.

（하자 보증 책임）
제○조 이전 조의 확정 후, 외부 설계서에 대해 요구 사항 정의서 및 제○조에서 정한 외부 설계 검토회의 결정 사항과의 불일치 또는 논리적 오류(이하 이 조에서는 ‘하자’라 한다.)가 발견된 경우, 甲은 乙에게 해당 하자의 수정을 요청할 수 있고, 乙은, 해당 하자를 수정할 것이다. 단, 乙이 이러한 수정 책임을 부담하는 것은, 이전 조의 확정 후 ○개월 이내에 甲으로부터 요청이 있었던 경우에 한정한다.

2. 전항에도 불구하고, 하자가 경미하고, 외부 설계서의 수정에 과분한 비용을 요구하는 경우, 乙은 전항에서 정한 수정 책임을 부담하지 않는다.

3. 제1항의 규정은, 하자가 甲이 제공한 자료 등 또는 甲의 지시에 의해 발생한 경우에는 적용되지 않는다. 단, 乙이 그 자료 등 또는 지시가 부적절하다는 것을 알면서 알리지 않았던 경우에는 이에 한하지 않는다.

본 조는, 외부 설계서에 관한 하자 보증 책임에 대해 규정하고 있습니다. 하자 보증 기간은, 정보 시스템의 규모나 대가 등을 고려하여, 당사자 간의 협의에 따라, 상당하다고 판단되는 기간을 정하게 됩니다.

제1항은, 외부 설계서와 요구 사항 정의서 및 외부 설계 검토회의 결정 사항과의 불일치 또는 외부 설계서의 논리적 오류를 하자로 규정하고 있습니다.

제2항에서는, 하자가 경미하더라도, 납품물의 수정에 과분한 비용을 요구하는 경우에 무상 수정을 벤더에게 요구하는 것은 가혹하므로, 민법 634조 제1항 단서에 준해, 벤더의 보호를 도모하고 있습니다.

제3항은, 민법 제636조 단서에 준해, 하자가 위탁자의 지시나 제공한 자료 등에 기인하는 경우에는, 벤더가 그 자료 등 또는 지시가 부적절하다는 것을 알면서 지적하지 않은 경우에는, 보증 책임을 면제하지 않는 것으로 규정하고 있습니다.

또한, 하자보증 책임은 임의로 정할 수 있는 규정이기 때문에, 이러한 규정을 설정하지 않았다면 민법의 일반 원칙에 따라 처리됩니다. 2020년 4월부터 시행되는 개정 민법의 영향을 크게 받고 있어, 개정 민법이 시행된 후에는 이전과 다르게 취급되는 분야가 될 것입니다. 자세한 내용은 아래의 기사에서 설명하고 있습니다.

https://monolith.law/corporate/defect-warranty-liability[ja]

소프트웨어 개발 업무

（소프트웨어 개발 업무의 실시）
제〇조 乙은, 제 25 조에서 정한 개별 계약을 체결한 후, 본 업무로서 이전 각 절에 따라 확정된 시스템 사양서에 기초하여, 내부 설계부터 시스템 테스트까지의 소프트웨어 개발 업무를 수행한다.

2.소프트웨어 개발 업무를 실시할 때, 乙은 甲에게 필요한 협력을 요청할 수 있으며, 甲은 乙로부터 협력을 요청받은 경우에는 적시에 이에 응해야 한다.

이하에서는 소프트웨어 개발을 벤더가 도급형으로 수행하는 경우의 조항에 대해 규정하고 있습니다. 시스템 내부 설계 과정에서는, 이전 단계까지의 작업으로 개발 대상이나 사양이 정의되어 있는 것이 일반적이므로, 경제산업성의 모델 계약에서는 도급형으로 규정하고 있습니다.

（소프트웨어 개발 업무에 관한 개별 계약의 체결）
제〇조 甲 및 乙은, 해당 소프트웨어 개발 업무에 대해, 제〇조 제〇항에서 기술한 거래 조건을 협의하여 결정하고, 소프트웨어 개발 업무에 관한 개별 계약을 체결한다

소프트웨어 개발 업무의 범위 등에 대해서는, 이전에 정한 거래 조건에 따라, 개별 계약으로 결정하게 됩니다.

（납품물의 납품）
제〇조 乙은 甲에게, 개별 계약에서 정한 기일까지, 개별 계약에서 정한 납품물을 검수 요청서(겸 납품서)와 함께 납품한다.
2.甲은, 납품이 있었던 경우, 다음 조의 검사 사양서에 따라, 제〇조(본 건 소프트웨어의 검수)의 규정에 따라 검사를 실시한다.
3.乙은, 납품물의 납품에 있어서, 甲에게 필요한 협력을 요청할 수 있으며, 甲은 乙로부터 협력을 요청받은 경우에는, 즉시 이에 응해야 한다.
4.납품물의 소멸, 파손 등의 위험 부담은, 납품 전에 대해서는 乙이, 납품 후에 대해서는 甲이, 각각 이를 부담한다.

본 공정이 도급형이므로, 완성된 소프트웨어 등을 검사의 대상이 되는 성과물로서 납품하게 됩니다. 제1항은, 납품물을 검수 요청서(겸 납품서)와 함께 납품하는 것을 규정하고 있습니다.

제2항은, 위탁자에 의한 검사의 실시에 대해 규정하고 있습니다.
제3항은, 개별 계약에서 정한 납품 장소로의 납품에 대해서는, 위탁자의 협력이 필요한 경우(위탁자의 사무실로 이동하여 납품하는 경우, 위탁자의 실 운영 환경에서 작동 가능한 상태로 납품하는 경우 등)도 있을 수 있으므로, 위탁자의 협력 의무를 규정하고 있습니다.
제4항은, 납품물에 발생한 소멸·파손의 위험 부담에 관한 조항으로, 물리적인 지배의 이전에 따라 위험 부담의 이전 시기를 구분하고 있습니다.

（본 건 소프트웨어의 검수）
제〇조 납품물 중 본 건 소프트웨어에 대해서는, 甲은, 개별 계약에서 정한 기간(이하 ‘검사 기간’이라 한다.) 내에 이전 조의 검사 사양서에 따라 검사하고, 시스템 사양서와 본 건 소프트웨어가 일치하는지 여부를 점검해야 한다.

2.甲은, 본 건 소프트웨어가 이전 항의 검사에 적합한 경우, 검사 합격서에 서명 및 날인한 후, 乙에게 제공해야 한다. 또한, 甲은, 본 건 소프트웨어가 이전 항의 검사에 합격하지 않은 경우, 乙에게 불합격이 된 구체적인 이유를 명시한 문서를 신속하게 제공하고, 수정 또는 보완을 요구해야 하며, 불합격 이유가 인정될 때에는, 乙은, 협의하여 정한 기한 내에 무상으로 수정하여 甲에게 납품하고, 甲은 필요한 범위에서, 이전 항에서 정한 검사를 다시 실시해야 한다.

3.검사 합격서가 제공되지 않은 경우에도, 검사 기간 내에 甲이 문서로 구체적인 이유를 명시하여 이의를 제기하지 않은 경우에는, 본 건 소프트웨어는, 본 조에서 정한 검사에 합격한 것으로 간주된다.

4.본 조에서 정한 검사 합격을 통해, 본 건 소프트웨어의 검수 완료로 한다.

본 공정이 도급형이므로, 본 조에서는 납품된 소프트웨어에 대한 검수를 실시하는 절차에 대해 규정하고 있습니다.

제1항은, 본 건 소프트웨어에 대해, 검사 기간 내에 검사 사양서에 따라 검사하고, 시스템 사양서와 본 건 소프트웨어가 일치하는지를 점검하는 것을 규정하고 있습니다.
제2항은, 본 건 소프트웨어가 시스템 사양서에 적합하지 않은 것이 판명된 경우, 벤더는 이를 수정하여 수정본을 위탁자에게 납품하는 것을 의무화하고 있습니다.
제3항은, 가정 검사 합격에 관한 규정을 정함으로써, 위탁자의 사정으로 인해 검수가 연기되는 것을 방지하는 것입니다.
제4항은, 검사 합격을 통해 본 건 소프트웨어의 검수 완료를 명시하고 있습니다.

（하자 보증 책임）
제〇조 이전 조의 검사 완료 후, 납품물에 대해 시스템 사양서와의 불일치(버그 포함. 이하 본 조에서 ‘하자’라 한다.)가 발견된 경우, 甲은 乙에게 해당 하자의 수정을 요구할 수 있으며, 乙은, 해당 하자를 수정해야 한다. 단, 乙이 이러한 수정 책임을 부담하는 것은, 이전 조의 검수 완료 후 ○개월 이내에 甲으로부터 요구된 경우에 한정한다.
2.전항에도 불구하고, 하자가 경미하고, 납품물의 수정에 과분한 비용이 드는 경우, 乙은 전항에서 정한 수정 책임을 부담하지 않는다.
3.제1항의 규정은, 하자가 甲이 제공한 자료 등 또는 甲의 지시에 의해 발생한 경우에는 적용되지 않는다. 단, 乙이 그 자료 등 또는 지시가 부적절하다는 것을 알면서 알리지 않았을 때에는 이에 해당하지 않는다. 　

본 공정이 도급형이므로, 본 조는 납품물에 대한 하자 보증 책임에 대해 규정하고 있습니다. 이행이 이루어지지 않았다(작업이 완료되지 않았다)는 상황에서의 채무 불이행 책임과, 이행이 일단 완료되었다(작업이 완료되었다)는 후의 상황에서의 하자 보증 책임의 경계는 실무상 판단이 어려운 부분이 있습니다. 시스템 개발에 대해 시스템을 완성시켰다고 인정될 수 있는지 여부는, 작업이 원래의 도급계약에서 예정하고 있던 마지막 공정까지 끝냈는지 여부를 기준으로 해야 한다는 판례(도쿄지방법원 헤이세이 14년 4월 22일)가 있습니다. 소프트웨어를 예정되어 있던 마지막 공정까지 끝내고 납품 및 검사 합격 후, 하자가 발견된 경우에는, 원칙적으로 하자 보증 책임이 적용되게 됩니다.

제1항은, 소프트웨어 개발 업무에서 발생한 ‘시스템 사양서와의 불일치’를 하자로 합니다. 외부 설계 단계에서 발생한 기능 부족 등에 대해서는, 본 조가 아니라, 외부 설계 단계에서의 하자 보증 책임 등의 규정에 의해 책임의 소재가 결정됩니다. 하자 보증 기간은, 정보 시스템의 규모나 대가 등을 고려하여, 당사자 간의 협의에 의해, 상당하다고 판단되는 기간을 정하게 됩니다.

제2항에서는, 하자가 경미하더라도, 납품물의 수정에 과분한 비용이 드는 경우에 무상으로의 수정을 벤더에게 요구하는 것은 가혹하므로, 민법 제634조 제1항 단서에 준하는 규정을 설정하고 있습니다.

제3항은, 민법 제636조 단서에 준해, 하자가 위탁자의 지시나 제공한 자료 등에 기인하는 경우에는 벤더는 보증 책임을 부담하지 않지만, 벤더가 그 자료 등 또는 위탁자의 지시가 부적절하다는 것을 알면서 지적하지 않은 경우에는 보증 책임을 면할 수 없다는 규정입니다.

어떤 경우에 하자가 인정되는지, 인정된 경우의 구체적인 책임의 내용에 대해서는 아래 기사에서 자세히 설명하고 있습니다.

https://monolith.law/corporate/defect-warranty-liability[ja]

소프트웨어 운영 준비 및 이전 지원 업무

시스템의 수용 및 도입 단계에서는 위탁자가 주도적으로 진행하는 것이 일반적이므로, 일본 경제산업성의 모델 계약에서는 위탁자가 주체가 되고, 벤더가 이를 지원하는 형태의 준위임형으로 규정하고 있습니다.

계약의 성격 결정

계약의 성격을 결정하기 위해서는, 계약의 전체를 고려하여 그 목적이 ‘완성된 결과물을 제공하는’ 것인지, 벤더가 ‘합리적으로 업무를 수행하는’ 것인지를 검토해야 합니다. 완성해야 할 목표물의 내용이 어느 정도 구체적으로 확정되고 그에 따라 프로젝트가 진행되었는지 여부가 대략적인 기준이 됩니다. 구체적으로 어떤 점에 주목해야 하는지에 대해서는 아래의 기사에서 자세히 설명하고 있습니다.

https://monolith.law/corporate/contract-and-timeandmaterialcontract[ja]