시스템 개발의 사양서에 없는 기능은 법률상 어디까지 구현해야 하는가?

기업에서 사용되는 IT 시스템을 개발하는 프로젝트는 원칙적으로 미리 정의된 사양에 따라 제작됩니다. 그러나 한편으로, 벤더가 시스템 개발 전문가로서 개발 업무를 전담하고 있다는 점을 고려하면, 사양에 기술된 것만을 기계적으로 구현하는 것이 위탁자 측의 기대치를 충족시키는 것은 아닐 수도 있습니다. 본 글에서는 ‘사양서에는 기재되어 있지 않지만, 개발 목적에 비추어 구현이 필요한 프로그램’에 대해, 그것을 구현하는 의무를 어디까지 지어야 하는지에 대해 설명하겠습니다.

명세서에 없는 것의 구현에 따른 법률 문제

벤더의 업무에는 재량이 요구된다

시스템 개발이라는 프로젝트와 관련된 계약이나, 그에 따르는 다양한 법률 문제의 큰 특징 중 하나는, 일을 받는 벤더가 큰 재량을 가지고 있다는 것입니다.

관련 기사: 시스템 개발에서의 프로젝트 관리 의무란[ja]

그러나, 여기서 말하는 ‘재량’이란, 시스템 개발 과정 전체에 대해 반드시 말할 수 있는 것은 아닙니다. 각 과정을 세분화하고, 세부적인 작업에 대한 세분화를 진행한 후에는, 단순한 작업에 가까운 일이 많아질 수도 있습니다. 그러나, 일반적으로 이러한 문제의 세분화 이전, 즉 상류 과정의 업무일수록, 큰 재량 없이는 업무 수행이 어려워집니다. 상류 과정일수록 계약 유형으로 준위임이 잘 맞는 이유도 이러한 점에 있습니다.

관련 기사: 시스템 개발에서의 도급계약과 준위임 계약의 구분과 차이[ja]

재량은, 엄격한 개발 과정에서도 발휘해야 하는 것

그러나, 시스템을 개발하는 벤더에게 큰 재량이 있다고 해도, ‘무작정’ 클라이언트의 요구를 받아들이는 것은, 후속 과정에 큰 피해를 입힙니다. 하나의 IT 시스템은, 세부적인 부품의 모임으로 이루어져 있기 때문에, 겉보기에는 사소한 변경에 불과하더라도, 개발자 측에서는 큰 작업 시간의 변경이 필요한 경우가 있습니다. 또한, 시스템 개발의 명세 변경에 관한 문제에 대해, 변경 상황의 관리 방법을 법률적인 관점에서 설명한 기사는 아래와 같습니다. 아래 기사는 변경 관리 방법에 대해 설명한 것이지만, 기술자 입장에서 명세의 변경이 얼마나 업무에 큰 영향을 미치는지도 함께 논의하고 있습니다.

관련 기사: 법률적 관점에서 본, 시스템 개발에서의 변경 관리 방법[ja]

명세에 얽매이지 않고, 전문가로서 해야 할 것은 무엇인가

시스템 개발 프로젝트를 원활하게 진행하기 위해서는, 개발의 요구사항을 미리 정의하고, 그에 따라 계획적으로 진행하는 것이 중요합니다. 한편, 미리 정의된 요구사항에 따라, 단지 말한 것만 수행한다면, 시스템 개발의 전문가로서 충분히 역할을 수행하지 못하는 상황도 있습니다. 이러한 딜레마 속에서, ‘명세서에는 나타나 있지 않지만, 구현해야 할 것은 무엇인가’라는 문제가 드러나게 됩니다.

법적 의무는 ‘사양서나 계약서의 ‘취지’에 따라 결정된다

구현해야 할 내용은 계약서나 사양서에 기재되어 있지 않더라도, 여전히 그들의 계약서나 사양서의 기재 사항의 ‘취지’, 즉 ‘어떤 의미나 의도를 가지고 그런 결정이 이루어졌는가’라는 점에서 결정되게 됩니다. 아래에서 몇 가지 판례와 함께 살펴보겠습니다.

기재가 없음으로 인해 구현 의무가 부정된 판례

아래에 인용한 판례에서는, 벤더가 개발한 시스템이 가동 테스트까지 진행된 상황에서, 필요한 기능이 부족하다며 계약 해지를 요구하고 분쟁이 발생했습니다. 위탁자가 부족하다고 주장한 것은 ‘데이터의 자동 업데이트 기능’이었고, 이것이 본 사례의 시스템의 주요 판매 포인트라는 주장이 제기되었지만, 법원은 이 구현 의무를 인정하지 않았습니다.

위의 인정과 같이, 본 사례의 계약서 및 기본 설계서와 상세 설계서에는, ③기능이 본 사례의 시스템 개발 대상임을 나타내는 기재가 없다.

원고는, ③기능이 피고에 대한 원고의 본 사례의 시스템의 주요 판매 포인트였다는 주장을 하고, 해당 기능의 필요성을 강조하지만, 그 주장이 사실이라면, 그 내용이 본 사례의 계약서 등에 명시되어야 할 것이며, 그런 기재가 없음에도 불구하고, 해당 기능의 개발이 합의되었다고 보기 어렵다.

도쿄지방법원 헤이세이 21년(2009년) 2월 18일

해당 판결은 확실히 단순히 결론만을 뽑아내면, “설계서에 기재가 없으니, 없는 것은 만들지 않아도 된다”라고 말할 수 있습니다. 그러나 더 정확히 말하면, 설계서에 기재가 있는지 없는지와 같은 형식적인 사실이 아니라, 그 설계서·계약서의 기재의 ‘취지’를 고려한 판단이 이루어진 것이라고 말할 수 있습니다. 즉, “설계서나 계약서에 기재되지 않은 이유를 고려하면, 역시 그 기재에 대응하는 합의도 없었다고 생각하는 것이 타당하다”라는 것입니다.

계약서나 사양서에 기재되지 않았음에도 구현 의무를 인정한 판례

한편, 계약서나 사양서에 기재되지 않았다 하더라도, 구현 의무를 인정해야 한다는 판례도 있습니다. 아래에 인용한 판례는 약물 복용 이력을 관리하기 위한 시스템 개발에 관한 것으로, 기존 시스템에서 새 시스템으로 데이터 이전을 할 수 없어 새 시스템을 활용하지 못하고, 위탁자 측이 계약 해지를 행한 사례입니다. 그러나 벤더 측은 데이터 이전은 업무 범위 밖이라고 주장하며 분쟁이 발생했습니다.

새 시스템의 개발에는 종종 기존 시스템의 폐기와 데이터 이전 등의 작업이 동반됩니다. 이러한 업무의 중요성과 그에 따른 법률 문제에 대해서는 아래의 기사에서도 자세히 설명하고 있습니다.

관련 기사: 시스템 개발에서의 기존 시스템에서의 이전에 따른 법률 문제[ja]

기존 시스템에는 이미 5만 명이 넘는 환자 데이터가 저장되어 있었고, 원고는 이러한 데이터를 활용하여 업무 효율성을 추구하고 있었다는 점에서, 환자 데이터를 기존 시스템에서 본건 시스템으로 이전할 수 없게 되면, 약국에서의 조제 업무에 장애가 발생하는 것은 명백하다고 할 수 있으며, 원고 대표자도 당연히 그 사실을 인식하고 있었을 것이라고 생각된다. 그리고, 본건 계약 체결 전에, 원고 대표자가 피고 대표자에게 데이터 이전 가능 여부에 대해 질문한 사실 자체는 피고 대표자도 인정하고 있는 바(중략), 원고 대표자는 5만 명이 넘는 환자 데이터를 손으로 입력해야 하는 가능성이 높다는 사실을 인식하면서도, 감히 본건 시스템 도입을 결정했다고는 결코 생각하기 어렵다. 또한, 위의 (1)이에 따르면, 피고는 기존 시스템의 약물 이력 데이터를 본건 시스템으로 이전할 수 없었기 때문에, 그 데이터를 종이에 인쇄하여 PDF 파일로 가져오는 등의 처리를 하고 있었는데, 본건 계약에서 데이터 이전이 전제되지 않았음에도 불구하고, 피고가 서비스로서 이런 번거로운 작업을 수행했다고는 결코 생각하기 어렵다고 할 것이다.

도쿄지방법원 판결 헤이세이 22년(2010년) 11월 18일

여기서도 중요한 것은 계약의 목적과 계약서의 기재 내용의 ‘취지’라고 할 수 있습니다. 만약 데이터 이전을 업무 범위 밖으로 인식한 상태에서 양 당사자가 계약을 체결했다면, 위탁자와 벤더 모두 비합리적인 의도를 가지고 계약을 체결한 것이라는 점을 법원이 지적한 것입니다. 즉, 위탁자는 방대한 양의 수작업을 수락하게 되었고, 벤더도 앞으로 위탁자의 업무에 장애를 초래하게 될 것을 알면서 프로젝트에 참여했다는 것으로, 매우 비합리적인 상황이라는 것입니다.

두 판결에서 알 수 있는 것은

데이터 이전에 대해 계약서나 사양서에 기재되어 있지 않더라도 구현의 의무가 긍정되었던 배경에는, 하나로는 ‘데이터’라는 화면 상의 외관에 나타나지 않는 사항에 대한 이야기였던 것이 관련이 있었다고 생각됩니다. 앞서 언급한 ‘필수 기능의 결여’는 원래 시스템의 화면·외관에 직접적으로 나타나는 것입니다. 따라서, 시스템 개발에 문외한이라 할지라도, 사양서의 기재 누락을 발견하는 것은 그리 어렵지 않습니다. 반면 데이터 이전의 문제는, 시스템 개발에 문외한에게는 그 과정의 중요성이나, 업무의 난이도나 작업 시간 등을 인식하기 어렵다는 특성이 있습니다. 그러므로, 벤더 측이 전문성을 가지고 원활하게 진행해야 할 사항으로 취급되기 쉬웠던 상황도 있었다고 생각됩니다.

이렇게 생각하면, 사양서나 계약서의 기재 누락은 위탁자의 ‘협력 의무’와도 밀접하게 관련된 문제라고 할 수 있습니다. 즉, 위탁자가 계약 체결·사양서 작성을 위해, 정말로 ‘협력 의무’를 이행해 왔는지에 대한 문제입니다. 시스템 개발 프로젝트에서 위탁자가 이행해야 할 법적 의무에 대한 전반적인 설명은 아래의 기사에서 자세히 다루고 있습니다.

관련 기사: 시스템 개발의 발주자인 위탁자 측이 부담하는 협력 의무란[ja]

위의 기사도 함께 확인하면, 화면·필수 기능의 세부 사항 등과 같은 위탁자 측의 협력 요청이 큰 영역과, 데이터 이전의 검토 누락에서는 이야기가 크게 다르다는 것을 자연스럽게 이해할 수 있을 것입니다.

명세서에 없는 개발에 대한 보수는 어떻게 생각해야 할까?

또한 이 글의 주제와 관련하여 궁금한 점은, 명세서에 없는 것을 만들었을 경우에, 추가된 보수 청구가 법적으로 인정되는지에 대한 점이 아닐까요. 보수의 추가 가능 여부와, 가능한 경우의 견적 금액 계산 방법 등에 대해서는, 아래의 글에서 자세히 설명하고 있습니다.

관련 글: 시스템 개발의 견적 금액의 사후 증액은 가능한가[ja]

위의 글에서는, 보수와 대가 관계에 있던 업무 범위를 초과하는 업무가 있었는지 여부가 중요하다는 것을 설명하고 있습니다. 즉, 이 글과의 관계에서 말하자면, 초기의 명세에 포함되지 않은 것의 개발(이 글에서 말하자면, 부정 예의 경우)에, 벤더가 응답했다면, 그곳에는 추가의 보수 청구를 인정할 수 있다는 것입니다.

요약

시스템 개발에서 벤더가 수행해야 할 역할은 한 면에서는 계약서나 사양서의 내용에 따라 결정됩니다. 그러나 전문가로서 높은 신뢰를 바탕으로 업무를 맡게 된 점을 고려하면, 그 실체는 형식에 의해 결정되는 것이 아님을 알 수 있습니다. 그러나 그 내부를 이해하는 데 있어서도, 법률이 큰 역할을 하는 점을 이해해야 할 것입니다.