시스템 개발 시, 도급계약을 체결할 때의 주의점은 무엇인가

IT 시스템을 개발하는 프로젝트에서 체결되는 계약은 주로, 도급계약과 준위탁 계약입니다. 위탁자에게나 벤더에게나, 각각의 계약 유형을 채택하는 것에는 장단점이 다양하나, 그 특성과 체결할 때의 주의점을 파악하는 것은 중요합니다. 본 글에서는, IT 시스템의 개발 업무에 있어서 도급계약에 대해 설명해 드리겠습니다.

시스템 개발과 도급계약

도급계약이란?

도급계약이 무엇인지 알아보려면, 먼저 가장 중요한 것은 직접적으로 법조문에서 도급계약의 성립 요건을 확인하는 것입니다.

제632조

도급은 당사자 한쪽이 일을 완성하는 것을 약속하고, 상대방이 그 일의 결과에 대해 그 보수를 지불하는 것을 약속함으로써 그 효력을 발생시킨다.

‘일의 완성’이 가장 중요한 키워드입니다. 도급계약의 대표적인 예는 건설이 필요한 건물의 건축입니다. 예를 들어, 일정 기한까지 주택이나 빌딩을 건설하는 것을 ‘일의 완성’으로 보고, 채무는 이행된 것으로 간주합니다. 반대로 건설이 진행되지 않아 납기가 지연된 경우에는 일정한 조건 하에서 이행 지연으로 채무 불이행 책임이 부과됩니다. 그러나 한 번 ‘일의 완성’이 인정되면, 채무 불이행 문제는 사라지고, 이후에는 하자 보증 책임 문제가 됩니다. 이런 의미에서도, ‘일의 완성’이라는 결과를 매우 중요시하는 것이 도급계약의 특징입니다. 무엇을 가지고 ‘일의 완성’이 인정되는지에 대해서는 아래의 기사에서 자세히 설명하고 있습니다.

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

도급계약은 건설뿐만 아니라, 큰 구상과 세밀한 계획성이 필요한 시스템 개발 프로젝트에도 자주 사용됩니다.

도급계약과 준위임 계약의 차이란?

또한, 도급계약이 ‘일의 “완성”‘이라는 결과 중심의 특성을 가진 계약 유형임을 알게 되면, 동시에 준위임 계약의 특성도 이해하게 됩니다. 이는 ‘완성’이라는 결과가 아니라, 과정 부분을 중요시하는 것입니다. 예를 들어, 결과가 어떻든 업무 처리 자체가 적절하게 진행되었다면 보수 청구가 가능하며(제648조 2항), 위임자의 책임으로 돌릴 수 없는 사유로 이행이 중도에 종료된 경우에는, 그 비율에 따라 보수를 청구할 수 있도록 정해져 있습니다(제648조 3항).

위임 계약과 준위임 계약의 비교에 대해서는 아래의 기사에서 자세히 설명하고 있습니다.

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

시스템 개발에서 도급계약이 선호되는 이유

시스템 개발 계약에서는 도급이 매우 많이 사용됩니다. 도급이 많이 사용되는 이유는, 일을 발주하는 위탁자 측과 수주하는 벤더 측 양쪽에게 일정한 이점이 있기 때문입니다.

먼저, 위탁자에게 도급으로 업무를 발주하는 이점은, 채무의 이행 요건이 ‘일의 완성’이라는 형태로 명확화하기 쉽다는 점입니다. 즉, (나중에 버그가 발견되거나 하여 하자 보증 책임 문제가 발생하는 것은 일단 무시하더라도) ‘완성’된 상태가 아니면, 보수 지불은 원칙적으로 하지 않아도 되는 명확성이 있습니다. 이는 예상보다 더 많은 작업 시간이 소요되거나, 작업 기간이 지연되는 등의 경우에, 지불해야 할 보수가 부풀어 오르는 위험을 감수하고 싶지 않은 위탁자에게 큰 매력이 될 수 있습니다. ‘완성’된 결과물과 동등한 교환으로, 정액의 보수를 지불하는 이런 구조는 예산 관리 측면에서도 큰 편의성이 있습니다.

반면, 일을 받는 벤더 측에게도, 도급으로 수주하는 것에는 일정한 이점이 있을 수 있습니다. 도급계약은, 잘 진행할 수 있다면, 준위임 계약보다 더 큰 이익률을 기대할 수 있기 때문입니다.

‘일의 완성’을 이행의 요건으로 하는 것이므로, 일을 받는 측에서도, ‘완성’까지의 과정에서, 상품의 원가(시스템 개발의 경우, 대부분이 인건비)에 얼마를 썼는지는 무시할 수 있습니다. 이런 식으로, 이익률을 높이고 싶은 벤더와, 예산 관리를 쉽게 하고 싶은 위탁자의 의도도 있어, 시스템 개발에서는 도급계약이 매우 선호되는 경향이 있습니다.

계약을 체결할 때 주의할 점

물론, 위탁자와 벤더 양측에서 볼 때 계약에는 이점이 있지만, 특히 벤더에게는 경솔한 계약 체결에는 위험도 동반됩니다. 무엇보다 ‘작업의 완성’이 채무 이행에 필요하다는 것은, 성과물이 완성되지 않으면 원칙적으로 채무 불이행 책임에서 면제되지 않는다는 것을 의미합니다. 벤더 측의 견적 오류 등으로 적자가 발생하더라도 여전히 납품을 위해 작업 시간을 할애해야 하는 등의 문제가 자주 발생하는 이유도 여기에 있습니다.

그렇다면, 계약 체결을 위해서는 계약서 상의 기재에서 어떤 점에 주의해야 할까요? 아래에서 하나씩 살펴봅시다.

시스템의 요구사항과 검수 합격의 조건을 사전에 명확히 하는 것

계약에서 중요한 것은, 물론 ‘작업의 완성’의 조건을 명확히 하는 것입니다. 일반적으로 여기서 말하는 ‘작업의 완성’의 요구사항은, 요구사항 정의 단계에 의한 합의 내용을 가리킵니다. 그러나 실무에서는 개발 과정이 진행됨에 따라 사후적으로 변경을 강요받는 경우도 있으므로, ‘작업의 완성’의 요구사항도 유동적일 수 있습니다. 이러한 점을 포함하여, 사양 변경 이력의 문서화에 노력하는 것이 중요하다고 생각됩니다. 아래의 기사에서는 법적 관점에서 본 시스템 개발 프로젝트의 변경 관리 방법을 설명하고 있습니다.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

또한, 이 주제와 관련하여, 위탁자 측이 실시하는 ‘검수의 합격’에 대해서도 사전에 합의를 해두는 것은 후속 문제 예방에 효과적입니다. 성과물을 납품하려 해도, 위탁자 측의 담당자를 찾을 수 없거나, 답장을 받지 못하는 등의 상황은 당연히 예상되는 것입니다. 검수의 합격 여부가 계속해서 명확하지 않은 상태로 방치되지 않도록, 검수에 대해서도 일정한 기한을 설정하는 것이 유익합니다. 이것이 바로 ‘추정 검수 조항’이라고 불리는 것인데, 이에 대해서는 아래의 기사에서 설명하고 있습니다.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

저작권의 이전 여부에 대해 사전에 합의를 두는 것

또 다른 문제가 되기 쉬운 것은 저작권의 이전에 관한 것입니다. 저작권은 ‘만든 사람’, 즉 시스템 개발이라면 벤더 측이 획득하는 것이 원칙이지만, 이전하거나 양도하는 것도 권리의 성질상 가능합니다. 따라서, 저작권을 위탁자에게 양도할 것인지 여부도 사전에 합의를 해두면, 사후에 문제가 되는 것을 방지할 수 있습니다. 저작권의 소유나 이전에 관해서는, 아래의 기사에서 자세히 설명하고 있습니다.

https://monolith.law/corporate/copyright-for-the-program-source-code[ja]

기타 주의사항

또한, 고의적으로 준위임적인 요소를 포함하지 않고, 계약으로서 계약을 체결하고 싶다면,

• 보수를 작업 시간과 무관하게 하는 것
• 계약서의 제목에 ‘계약’이라고 명시하는 것
• 결함 보증 책임의 조항을 명시하는 것
• 보수의 지급이 결과나 성과에 대한 동등한 교환인 것

등의 점을 유의해두는 것이 좋습니다.

그러나, 계약서의 제목에 ‘계약’이라고 적어두면, 무엇이든 계약이 된다는 등의 경솔한 생각을 가지는 것은 금물입니다. 실무에서는 다른 회사의 계약서 템플릿이, 그 기재 내용이 계약인지 준위임인지에 대한 점을 무시한 채 계속해서 사용되는 경우가 있습니다. 만약 소송 등으로 복잡해진 경우에는, 제목의 문구 등의 표면적인 요소보다는, 계약서의 기재 사항의 전반적인 내용이나, 그동안의 상업 관행 등, 더 실질적인 사항이 중요시됩니다. 이 점에도 주의를 기울여야 할 것입니다.

요약

위에서 언급한 사항들을 고려하면, 도급계약에 의한 업무 처리가 쉬워집니다. 또한, ‘위탁’이라는 단어는 도급계약이든 준위임 계약이든 양쪽에서 모두 사용되는 용어입니다. 그리고 ‘업무 위탁’이라는 용어는 당사자 간에 준위임 계약이라는 의도가 있을 때 일반적으로 사용됩니다. 이러한 세부적인 용어 차이를 포함하여 주의를 기울이는 것이 좋을 것입니다.