시스템 개발을 발주하는 위탁자 측이 부담하는 협력 의무란?

시스템 개발 작업은 개발되는 시스템이 대규모일수록 많은 인력과 작업 시간이 필요한 것입니다. 따라서 개발을 맡는 벤더 측뿐만 아니라, 시스템 개발을 의뢰하는 위탁자 측에도 일정한 협력 의무가 부과됩니다.

이는 일반적인 발주-수주 관계와는 다릅니다. 예를 들어 IT 시스템이 아닌 주문 제작 슈트를 슈트점에 의뢰하는 경우, 발주자인 고객(위탁자) 측은 특별히 ‘의무’를 부담하지 않습니다. ‘의무’를 부담하는 것은 오직 수주자인 슈트점(벤더) 측입니다. 많은 인력과 작업 시간이 필요한 IT 시스템이기 때문에, 위탁자도 벤더에 ‘협력’할 필요가 있는 구조입니다.

본 글에서는 벤더에게만 맡길 수 없는 시스템 개발에 대해, 발주자 측에 어떤 법적 의무가 있는지에 대해 설명하겠습니다.

자체 시스템이기 때문에 모든 것을 ‘완전히 맡기기’만으로는 해결되지 않습니다

하나의 시스템 개발 프로젝트라도, 그곳에는 많은 사람과 조직이 관여하는 경우가 많습니다. 코딩 기술에 능숙한 엔지니어나 프로그래머는 물론, 그런 인력의 결과물을 하나의 성과로 집약시키기 위해서는 프로젝트 매니저의 역할도 중요합니다.

그러나, 벤더 측이 아무리 높은 기술력과 조직력을 가지고 있어도, 벤더 측만의 힘으로 시스템 개발이 완성되는 것은 아닙니다. 예를 들어, 그 회사 내부에서만 사용되는 회사 전용 용어나, 그 회사에 고유한 업무 지식 등에 대해서는, 벤더 측만의 일방적인 노력으로는 알 수 없습니다. 대규모 시스템의 개발일수록, 일반적인 경향으로, 그 시스템이 활용되는 회사 자체도 많은 사람과 업무를 가진 대기업일 경우가 많습니다. 시스템 개발 프로젝트를 성공으로 이끌기 위해서는, 사실 컴퓨터 작업 이전에, 이런 비즈니스 로직의 정리가 큰 비중을 차지하는 경우가 많습니다.

따라서, 위탁자 측도 “나는 IT 기술 전문가가 아니기 때문에”라는 이유로 수동적이 되는 것이 아니라, 오히려 적극적으로 정보 제공을 통해 프로젝트의 진행이 원활하게 이루어질 수 있습니다. 이런 의미에서, 시스템 개발 프로젝트에서 위탁자 측이 맡고 있는 역할은 실제로 결코 작은 것이 아닙니다.

판례를 바탕으로 한 위탁자 측의 협력 의무란?

그렇다면 구체적으로, 시스템 개발 프로젝트에서 위탁자 측이 부담하고 있는 협력 의무란 어떤 것일까요? 이에 대한 답은 과거의 판례에서 많은 힌트를 찾을 수 있습니다.

재판에서는, 벤더 측(피고)의 납기 지연에 대해, 위탁자(원고)의 의사결정 지연 등이 있었기 때문에, 위탁자의 개발에 대한 협력 의무의 유무가 논점이 되었습니다. 이에 대해 법원은 위탁자 측의 협력 의무 위반을 인정하고, 벤더 측의 채무 불이행 책임을 부인했습니다.(계약 해지에 대해서는 인정되었지만, 이 역시 60%의 과실 상쇄가 인정되었습니다.)

본 사건의 전산 시스템 개발 계약은, 맞춤형 시스템 개발 계약이며, 이러한 맞춤형 시스템 개발 계약에서는, 수탁자(벤더)만으로는 시스템을 완성할 수 없으며, 위탁자(위탁자)가 개발 과정에서, 내부의 의견 조정을 정확하게 수행하여 견해를 통일한 후, 어떤 기능을 요구하는지를 명확하게 수탁자에게 전달하고, 수탁자와 함께, 요구하는 기능에 대해 검토하여, 최종적으로 기능을 결정하고, 또한, 화면이나 양식을 결정하고, 성과물의 검수를 하는 등의 역할을 분담하는 것이 필요하다.

도쿄지방법원 헤이세이 16년(2004년) 3월 10일 판결

이 판결은 시스템 개발 자체가 위탁자 측과의 공동 작업임을 명시하는 것뿐만 아니라, “구체적으로 어떤 점에서 협동해야 하는가”에 대해 명시하고 있는 점이 매우 의미심장하다고 생각됩니다.

시도 삼아 위 판결문의 문장을, 시스템 개발의 IT 용어로 번역해 보겠습니다.

이런 식으로 정리할 수 있습니다. 이들은 모두, IT 시스템에 대한 전문성이 얼마나 고도하든, 위탁자의 협력 없이 단독으로 이루어질 수 있는 것이 아닙니다. 요구하는 기능이나, 화면 레이아웃이 어떤 것인지는 기본적으로 위탁자가 명확하게 해야 할 것이며, 또한 요구한 대로의 것이 실현되었는지 여부도 위탁자만이 확인할 수 있기 때문입니다.

또한, 벤더에 프로젝트 관리 의무가 부과되고 있는 것과 마찬가지로, 위탁자에게도 협력 의무가 부과되고 있기 때문에, 위탁자가 위와 같은 과정에서 협력 의무 위반을 저지르면, 반대로 벤더로부터 위탁자에게 채무 불이행이나 불법 행위에 기초한 손해배상 청구를 받게 될 가능성도 있다고 생각됩니다.

사후의 사양 변경 요청은 어떻게 해석되는가

또한, 시스템 개발 프로젝트가 위탁자와 벤더의 공동 작업이라는 전제 하에, 여기서 더 발전적인 논의로 이야기가 진행됩니다. 그것은 “위탁자가 사후에 기능의 추가나 수정을 요청하고, 그로 인해 납기를 지키는 것이 어려워진 경우, 과연 누구의 책임이 될 것인가”라는 문제입니다.

시스템 개발은 일반적으로, 요구사항 정의에서 시작하여, 기본 설계·상세 설계·제작(프로그램 구현)·테스트 등의 순서로, 가능한 한 되돌림이 발생하지 않도록 진행하는 것을 목표로 합니다(일반적으로 워터폴 모델이라고 불립니다). 그러나 어떤 이유로 인해, 이전 공정에 미비한 점이 발견되면, 공정에 되돌림이 발생하는 것도 실제로 자주 일어나는 일입니다.

이러한 사례에서, 납기에 맞추지 못한 경우 어떻게 생각할까요? 과거의 판례를 해석하면, 추가 작업이 발생한 시점에 따라 결론에 차이가 있을 것으로 보입니다.

추가 작업이 외부 설계 등의 사양의 명확화보다 앞선 경우

앞서 언급한 판례는, 기본 설계 중(프로그램 구현 단계보다 앞서)에 위탁자로부터 받은 추가 개발의 요청에 대해, 그러한 요구를 제기하는 것 자체가 특히 협력 의무 위반에 해당하지 않는다는 점을 동시에 나타냈습니다.

위탁자가 벤더에게, 기본 설계 작업 중에 구축할 시스템에 대한 다양한 요구를 하는 것은, 본 사례와 같은 시스템 개발의 공정에서는 당연한 것이며, 게다가, 전문적 지식이 없는 원고 위탁자에게서, 해당 요구가 추가의 위탁료나 납품 기한의 연장 등을 필요로 하는 것인지, 작업 공정에 장애를 초래하는 것인지 등을, 정확하게 판단하는 것은 어려움이 있었으므로, 원고 위탁자에게서, 추가의 위탁료나 납품 기한의 연장 등을 초래하는 요구를 자제해야 했다는 등의 주장은 할 수 없다. 오히려, 원고 위탁자가 추가의 위탁료나 납품 기한의 연장 등을 필요로 하는 요구를 한 경우, 프로젝트 관리 의무를 부담하는 피고에게서, 원고 위탁자에게 그 사실을 전하고, 요구의 철회나 납품 기한의 연장 등에 대한 협의를 요구하거나, 개발 작업에 장애가 발생하지 않도록 해야 했다는 주장이 가능하다.

도쿄지방법원 헤이세이 16년(2004년) 3월 10일 판결

해당 판결에서는, 위탁자 측에도 일정한 협력 의무가 있다는 것을 인정하면서, 결코 위탁자 자신이 시스템 개발의 전문가가 아닌 점을 고려해야 한다는 점이 나타났습니다. 즉, 발주하는 위탁자는 시스템 개발의 전문가가 아니기 때문에, 개발할 시스템의 내용이 명확해지는 기간 동안은, (경우에 따라서는 발주하는 것에도 익숙하지 않아) 조금씩 주문을 내는 것도 이상하지 않으며, 더욱이 그 주문 내용이 납기 등의 재검토를 요구하는 경우에 “그것을 스스로 알아차리는 것이 당연하다”는 것은 너무하다는 이야기라고 생각할 수 있습니다.

그러나, 여기서 벤더 측에 부과되는 의무는, 결국 납기의 연장 등을 요구하거나(또는, 납기를 변경할 수 없다면, 추가 요구 자체를 철회하도록 제안하거나)하는 등의 커뮤니케이션 노력을 가리키는 것으로 생각됩니다. 따라서, 위탁자의 요구를 모두 받아들인 후에, 원래의 기한에 맞춰 납품하는 것까지 모두 의무로 포함하고 있다는 의미는 아니라고 생각되므로, 이 점에는 주의가 필요합니다.

추가 작업이 제작이나 테스트 공정의 사양 확정 이후인 경우

위의 판결 내용을 반대로 해석하면, 사양을 이미 확정한 경우의 추가 개발이라면 어떤 결론이었을지 동시에 어느 정도 예측할 수 있습니다. 그 경우에는, 이러한 요구가 통과하기 어려울 것입니다. 확실히, 위탁자 측과 벤더 측에서, 개발 업무에 대한 이해도가 크게 차이가 나는 점은, 사양 확정 전이든 후든 변하는 것은 아닙니다.

그러나, 사양이 확정된 후에 주문 내용을 변경하거나 추가하는 것은, 작업의 재시작을 강요하는 가능성이 높습니다. 이러한 경우에까지 발생한 납기 지연에 대해, “고객이니까 이것저것 요구하는 것은 당연하다”고 변호하는 것은 어려운 경우가 많을 것입니다. 더욱이, 많은 사양 변경이나 기능 추가가 사후에 발생하는 상황은, 원래 사전에 이미 완료되어 있어야 했던 기본 설계 등의 상류 공정에서도 위탁자 측의 협력 의무 위반이 있었는지 의문을 제기하는 것입니다.

이러한 점에서, 사양이 한 번 확정된 후에 실시한 사양 변경에 대해서는, 그것이 원인의 납기 지연을 벤더 측의 책임으로 보는 것은 현실적이지 않다고 생각됩니다. 앞서 언급한 판결문에서는, 그러한 의미도 동시에 해석하는 것이 타당하다고 볼 수 있습니다.

또한, 이러한 판단은, 계약서뿐만 아니라, 시스템 개발의 진행에 맞춘 회의록 등도 증거로 사용되는 경향이 있습니다. 회의록에 대해서는 아래 기사에서 자세히 설명하고 있습니다.

관련 기사: 법적 관점에서 본 시스템 개발에서의 회의록 남기는 방법은

요약: 요구사항 정의는 위탁자 측의 프로세스라는 것을 잊지 않는 것이 중요

요구사항 정의는 벤더 측의 기술력을 보여주는 한편, 원래는 위탁자 측의 업무라는 것을 인식하고 있어야 합니다. 그것이 자사에서 사용하는 시스템이라면, 외부 전문가의 도움을 받아 만들더라도, 기본적으로 자사의 거버넌스가 적용되어야 하며, 법적으로는 그렇게 생각됩니다.

위탁자 측이 개발 과정에 협력적이지 않은 경우, 프로젝트가 실패하더라도, 법원은 위탁자 측에도 엄격한 견해를 제시할 가능성이 크다는 점을, 먼저 인식하고 있어야 할 것입니다.