검수 후 시스템결함이 발견된 경우의 대응책은?

시스템개발은 일반적으로 요구사항 정의단계에서 결정된 내용에 따라 프로그램을 구현하며, 최종적으로 위탁자와 벤도 모두의 확인 후, 검수합격을 통해 종료됩니다.

그러나 실제로는 테스트과정 및 검수합격 시점에서 발견하지 못한 버그나 결함이 후속 운영단계 등에서 드러나는 경우가 충분히 발생할 수 있습니다. 한번 납품을 수학한 경우, 법적으로 어떤 요구를 할 수 있는지에 대해 알아보겠습니다.

검수합격 후나 테스트과정 후에도 버그가 있는 것은 이상하지 않다

기술적인 관점에서 벤더측의 각종 테스트과정 완료 및 위탁자측의 검수합격 후에도 다양한 버그나 결함이 발견되는 것은 결코 드문일이 아닙니다. 위탁자는 검수과정에서 주로 화면상에서 확인할 수 있는 입출력을 체크합니다. 그러나, IT 시스템은 위탁자측에서 확인할 수 있는 화면상의 내용외에도, 배후의 데이터베이스 및 각종 계산·제어를 담당하는 프로그램 부분에서 복잡하고 세밀한 구조를 가지고 있는 경우가 많습니다. 따라서, 위탁자의 화면상 입출력체크만으로 조사할 수 있는 부분에는 한계가 있습니다. 따라서, 체크를 통해 그 후의 운영단계에서 발생할 수 있는 모든 결함가능성을 포괄적으로 검증하는 것은 비현실적입니다.

위와 같은 상황은 개발업무를 담당하는 벤더측에서도 동의하는 내용입니다. 예를 들어, 구현된 프로그램의 내용에 대해, 버그나 결함이 없는지 확인하는 것을 ‘테스트과정’이라고 합니다. 그러나, 테스트과정에서 정말 모든 버그나 결함 가능성을 검증할 수 있는지를 판단한다면, 반드시 그렇지는 않습니다. 개발한 시스템이 실제업무에서 활용되지 시작한 이후에, 벤더측에서 예상치 못한 조작이 이루어지거나, 혹은 대량의 데이터가 실제로 등록되거나, 여러 위탁자가 동시접속을 시작하는 등의 상황에서도 문제없이 작동하는 시스템을 구축하기 위해서는 우수한 기술력이 요구됩니다.

검수나 테스트 등의 단계에서 모든 버그나 결함을 발견하는 것은 비현실적이며, 실제 사용시작 후 다양한 문제가 발견되는 경우가 많다는 것이 IT 시스템의 특징이라는 점에 대한 이해가 필요합니다.

일반적으로 채무 자체는 이행완료로 취급받습니다

그렇다면 실제로 이러한 문제가 발생한 경우는 어떤식으로 대처해야 할까요? 법적순서에 따라 정리해 보겠습니다.

먼저, 사후적으로도 다양한 버그나 결함이 발견된 경우, 위탁자측에서는 지금까지 업무를 의뢰해 온 벤더에게 어떤한 책임을 추궁하고 싶을 것입니다. 그러나, 일반적으로 이미 납품이 완료되고, 검수까지 합격한 상태라면 채무불이행에 기반한 책임추궁은 어려운 경우가 많습니다.

원래 시스템개발에 관한 계약은, 특별한 합의가 마련되어 있지 않는 한, 프로그램 구현에 관한 규정은 ‘일본민법상의 도급계약’의 규정이 적용되는 것입니다.

그리고 도급계약에서는 ‘작업의 완성’이 채무이행의 요건이 됩니다.

과거판례에서 도급계약의 ‘작업의 완성’은 시스템개발의 맥락에서는 개발과정의 전 과정의 종료를 의미합니다. 또한, 개발과정이 전부 종료된 후의 버그·결함 등의 문제는 도급계약에 있어서의 하자보증책임의 문제로 이어진다고 설명합니다.

결론적으로, 한 번 납품을 수락하고, 검수합격이 완료되었다면, 채무자체는 이미 이행되었다는 전제가 생깁니다. 그 후에는 품질보증문제, 즉 하자보증책임의 추궁가능성이 문제가 되는 것이 일반적입니다.

결함보증책임에 근거한 책임추궁의 방향성

그렇다면, 결함보증책임에 기초하여 벤더에게 대응을 요구하는 경우, 어떤 것을 어떤 순서로 검토해야 할까요? 아래에서 확인해봅시다.

먼저 버그나 결함의 중대성·심각성의 정도를 확인

버그나 결함이 사후에 발견되고, 이것이 법률상의 ‘결함’으로서 어떤 보장을 요구하는 경우, 버그나 결함의 심각성이 문제가 됩니다. 법률상의 결함문제는 원래

1. 버그나 결함이라고 할 수 있는 것이지만 경미한 것에 불과하고, 법률상의 ‘결함’이라고 할 수 없는 경우
2. 법률상의 ‘결함’에 해당하지만, 계약의 목적달성 자체는 가능한 경우
3. 법률상의 ‘결함’에 해당하고, 또한 계약의 목적달성 자체도 불가능한 경우

의 3가지 패턴으로 나뉩니다. 결함보증책임에 근거한 책임추궁의 가능성을 나누는 것이 1과 2의 경계이며, 결함보증책임에 근거하여 계약해지를 할 수 있는지를 나누는 것이 2와 3의 경계가 됩니다.

제634조

1. 작업의 목적물에 결함이 있는 경우, 주문자는 계약자에게 적당한 기간을 정하여, 그 결함의 수리를 요구할 수 있다. 단, 결함이 중요하지 않은 경우, 그 수리에 과분한 비용이 드는 경우에는 이에 해당하지 않는다.

2. 주문자는 결함의 수리 대신, 또는 그 수리와 함께, 손해배상의 요구를 할 수 있다. 이 경우에는, 제533조의 규정을 준용한다

제635조

작업의 목적물에 결함이 있고, 그 때문에 계약목적을 달성할 수 없는 경우에, 주문자는 계약해지를 할 수 있다. 단, 건물 등의 토지의 공작물 등은 이에 해당하지 않는다.

또한, 이러한 ‘결함’의 단계적인 구분에 대해서는, 아래의 기사에서 자세히 설명하고 있습니다.

다음으로 벤더에게 요구사항을 명확히 한다

또한, 다음으로 상대방에서 무엇을 요구해야 하는지를 명확히 해야합니다. 만약 계약해지를 원하는 경우, 결함을 입증하는 것으로는 충분하지 않고, 그것이 ‘계약목적을 달성할 수 없다’고 할 수 있는 정도의 내용이어야 합니다. 여기서 ‘목적’의 판단에 있어서는 시스템개발 프로젝트 시작 당시에 이루어진 회의의 의사록이나, 사양서의 기재사항 등이 중요한 단서가 됩니다. 검수합격 후에도 버그나 결함이 사후적으로 발견되는 경우도 있을 수 있으므로, 개발 프로젝트가 종료된 후에도 각종 문서의 보관은 철저히 이루어져야합니다.

또한, 해지 외에도 결함보증책임의 내용으로서 요구할 수 있는 것에는 손해배상청구나 결함수리청구 등이 있습니다.

기타 유의사항

계약해지 등의 법률행위 시의 방법에 주의

만약 하자보증책임의 내용으로 계약해지를 진행하는 경우, 해지를 위한 법률적 절차와 방법에 대한 지식도 함께 알아두어야합니다.

분쟁보다는 협상을 통한 해결이 바람직

또한, 이러한 일련의 법률론은 반드시 법정분쟁이 발생했을 때만 의미를 가지는 것이 아닙니다. 법정분쟁 해결은 양 당사자에게 매우 부담스러운 일입니다. 오히려, 법정에 오르기 전 단계의 협상단계에서도 크게 활용해야 할 지식입니다.

버그나 결함과 및 기능부족은 구분해서 생각

구현된 기능이나 사양에 버그나 결함이 있는 경우와, 기존에 필요한 기능이 부족한 경우는 논의점이 달라집니다. 만약 필요한 기능이 전부 갖추어지지 않은 경우라면, 원칙적으로 위탁계약에서의 ‘작업완료’를 인정받지 못하고, 따라서 채무이행을 인정받지 못할 가능성도 있습니다.

또한, 필요한 기능이나 사양이 갖추어지지 않았다 하더라도, 이것이 요구사항 정의단계에서 위탁자측이 적잘한 정보를 제공하지 않는 결과인 경우, 계약내용의 일부로 보는 것 자체가 부적절하다고 평가될 경우도 있습니다.

요약

프로젝트중에 발생한 문제는 프로젝트 진행중, 혹은 운영단계 등의 사후에 발견될 수 있습니다. 모든 과정을 무사히 마치더라고 반드시 안심할 수 있는 것이 아닙니다. 이러한 특성은 ‘하자보증책임’ 제도에 잘 반영되어 있다고 보입니다. 시스템개발 프로젝트 종료후의 사항까지 고려한 문서관리를 철저히 실시하고, 이러한 일련의 흐름을 파악해 두는 것이 중요합니다.