시스템개발 견적금액을 사후에 늘릴 수 있을까?

시스템개발 업무는 발주하는 위탁자와 수주하는 벤더 모두 많은 인력을 동원해 진행되기 때문에, 모두가 발 맞추며 프로젝트를 진행하는 것은 쉽지 않습니다. 계획성이 매우 중요한 업무이지만, 동시에 발주자인 위탁자가 적절한 정보를 간결히 정리해 벤더에게 전달할 수 있는가 한다면, 실제로는 그렇지 않습니다. 개발과정이 어느정도 진행된 단계에서, 사후에 사양변경이나 기능추가를 요구받는 경우, 사전 견적금액에 추가로 청구가 가능한지에 대한 부분은, 일을 위탁받은 측에서 매우 궁금한 부분일 것입니다.

이러한 권리는 법률상 어떤 경우에 인정되는 것인지, 그리고 추가개발 및 기능수정에 따른 보수금액은 어떻게 결정되는 것인지에 대해 본 기사에서 설명하겠습니다.

추가개발·기능수정이란 어떤 것을 의미하는가

시스템개발 프로젝트에서 일을 수탁할 경우의 계약형태는 일반적으로 도급계약이나 준위임 계약 등이 있습니다. 이러한 계약형태는 어떤 경우든, 일을 맡는 측이 해야 할 일(=의무)과 그에 따른 보수(=권리)가 한 쌍으로 계약에 명시되게 됩니다. 따라서, 그 보수액의 전제가 되는 업무에 포함되지 않는 업무가 나중에 추가되는 경우, 추가개발·기능수정로 분류됩니다. 반대로, 포함되는 경우는 처음의 사양대로(=기존계약의 범위 내의 것) 취급되게 됩니다.

참고로, 도급계약과 준위임 계약의 차이 등에 대해서는 별도의 기사에서 자세히 설명하고 있습니다.

그러나, 화면에 표시되는 폰트의 미세조정 등 모든 것을 미리 사양으로 정하지 않고, 이러한 내용을 모두 추가개발로 분류하는 경우, 원활한 상업거래를 심각하게 방해할 수도 있습니다. 따라서, 이러한 사양의 세부 사항에 관한 논의까지 고려하면, 실제로 일률적인 구분을 하는 것은 쉽지않습니다. 그러나 일반적인 지침을 제시한다면,

• 사양이 한 번 확정된 후, 추가기능을 지시받음
• 이미 프로그램의 구현이 끝난 후, 그 수정을 지시받음

와 같은 경우라면, 그 주장은 법적으로도 일정한 타당성이 예상될 가능성이 높다고 할 수 있습니다.

추가개발 및 기능수정이 논란의 중심이 된 판례

긍정례: 기본 설계사양을 사후에 변경한 사례

다음의 사례는 사후적으로 사양의 변경이 있었던 것입니다.

소프트웨어 개발은 ①요구 사항 정의, ②외부 설계, ③내부 설계, ④소스 프로그램 작성(프로그램 설계, 코딩), ⑤각종 테스트(단위 테스트, 조합 테스트, 시스템 테스트)의 개발 과정을 거쳐 진행되는 것이다. 초기 사양을 내부 설계 이후의 작업을 통해 실현하는 것이며, 이것이 본 사건 개발 위탁 계약에 기초한 보수 청구권과 대가 관계에 있는 업무의 범위로 해석된다. 사양 변경의 제안은 법적으로는, 위탁자에 의한 초기 계약에 기초한 업무 범위를 초과하는 새로운 업무위탁계약의 제안으로 해석되며, 이에 대해 수탁자가 추가 공사 대금을 제시하지 않고, 추가 대금의 합의 없이 추가 위탁에 관한 업무를 완료한 경우에는, 위탁자와 수탁자 사이에서 대금액의 정해진 새로운 계약이 체결된 것으로, 상당한 추가 개발비 지불 의무가 발생한다고 해석하는 것이 적절하다.

오사카 지방법원 헤이세이 14년(2002년) 8월 29일 판결

‘대가 관계’, ‘새로운 계약’ 등의 키워드를 기억해두면 이 판결을 더 깊게 이해하는 데 도움이 될 것입니다.

또한, 위의 판결에서는 또 하나의 매우 흥미로운 점이 제시되었습니다. 그것은 버튼의 배치나, 문자의 글꼴과 같은 매우 세부적인 부분의 미세 조정까지는 여기서 말하는 사양 변경에 해당하지 않는다는 것입니다. 해당 부분은 다음과 같습니다.

그러나, 소프트웨어 개발에서는 그 특성상, 외부 설계 단계에서 화면에 문자를 표시하는 글꼴이나 버튼의 배치 등의 세부 사항까지 결정되는 것이 아니며, 세부 사항에 대해서는, 사양 확정 후에도, 당사자 간의 논의에 의해 일정 수정이 가해지는 것이 일반적이다고 볼 때, 이러한 사양의 세부화 요구까지도 사양 변경으로 보는 것은 적절하지 않다고 말해야 한다.

오사카 지방법원 헤이세이 14년(2002년) 8월 29일 판결

판결문에서는 ‘사양의 세부화’라는 흥미로운 단어를 사용하였습니다.

• 이미 결정되어 있던 것을 나중에 뒤집은 경우
• 하면서 결정해도 좋은 것에 대해 일부러 결정하지 않고 진행한 경우

따라서, 법적처리도 달라져야 한다는 생각을 보여준 것으로 해석될 수 있습니다.

기타 긍정례

그 외에도, 추가개발·기능수정으로 인정된 사례에는,

• 초기계획보다 배송된 프로그램의 수가 약 2배로 증가한 사례(도쿄 지방법원 헤이세이 17년(2005년) 4월 22일 판결)
• 작업기간이 약 3배로 늘어난 사례(도쿄 지방법원 헤이세이 22년(2010년) 1월 22일 판결)

등이 있습니다. 이렇게 정리해보면, 작업기간의 연장 또한 넓은 의미의 추가개발로서, 일정한 법적보호를 받을 수 있도록하는 대용이 채택되고 있음을 알 수 있습니다.

‘추가개발에 관한 합의나 보수증가’와 ‘초기계약의 체결’은 별개의 문제

그런데, 이러한 문제에 대한 중요한 포인트는,

1. ‘처음에 2개의 기업 간에서 시스템개발에 관한 계약(초기 계약)이 공식적으로 체결되었는가’라는 단계
2. ‘한번 공식적으로 체결된 시스템개발에 대해, 추가개발에 관한 계약이(도) 추가로 체결되었는가’라는 단계

에서, 법원의 판단 기준은 다릅니다. 간단히 말하면, 법원은,

• 1에 대해서는 엄격한 경향이 있습니다(계약서가 없는 상황에서는 계약 체결을 쉽게 인정해주지 않습니다)
• 2에 대해서는 비교적 관대한 경향이 있습니다(추가 개발에 관한 계약서가 없어도, 보수 증가 등을 유연하게 인정해줍니다)

라고 말할 수 있습니다.

부정례: 법적으로 동일한 위탁내용에 포함되는 것으로 고려된 사례

한편, 보수증가가 인정되지 않은 판례도 있습니다. 아래에 인용한 판결문의 사건에서는, 시스템개발 계약에 대해, 한 번 업무위탁계약이 체결된 후에 업무의 내용이 변경되었기 때문에, 보수증가가 인정될 수 있는지가 논란이 되었습니다.

본 사건의 논점은, (1) 본 사건 계약에서 원고가 수탁한 업무의 내용은 무엇인가, (2) 우측 수탁 업무에 대해, 원고와 피고 사이에서 규모를 확대하고 대금을 증가시키는 합의가 이루어졌는가, (중략),라는 점에 있다.(중략)

우선, 본 사건 계약은 그 대금액을 원고의 수탁 업무(계약)에 대한 확정의 대가로 하는 계약으로 합의한 계약이며, 수탁 업무에 관한 스텝 수, 단가 등은 원고 내부에서 계약 대금을 계산하는 데 사용되는 내부 자료에 불과하며, 스텝 수의 증가 등의 사정은 계약 대금과는 전혀 관련이 없다.(중략)

앞서 인정한 바와 같이, 원고의 수탁 업무가 쇼와 62년(1987년) 2월 25일에 변경되어 시스템 관리, 계약 공사비 적산 및 유틸리티의 일부만이 제한되고 그 나머지는 피고가 담당하게 되었는지, 우측 변경 후의 원고의 업무는 초기 계약에 따른 개발 업무의 범위 내에 있는 것으로 변함이 없으며, 우측 업무에 관한 대가는 본 사건 계약 초기에 확정 대금으로 약정된 위탁 대금으로 모두 커버되는 것이다.

도쿄 지방법원 헤이세이 7년(1995년) 6월 12일 판결

상기 경우 벤더에게 수탁되는 업무의 내용이 변경되었더라도, 그 개발내용은 초기 계약내용의 범위 내에 포함되는 것으로 고려하고, 초기에 약속된 보수로 커버되어야 한다고 판단하였습니다.

결국, 보수액이 어떤 업무를 하기 위한 전제로 결정된 것인지를 고려하여, 그에 포함되지 않는 업무에 대해서는 추가보수청구를 인정해 나가는 입장이라고 볼 수 있습니다.

그리고, 보수액이 어떤 업무를 수행하는 것의 대가였는지는, 반드시 계약서만이 아니라 회의록 등도 증거로 판단될 것입니다.

추가개발 및 기능수정에 대한 보수결정방법

시스템개발 현장에서는 한 번 확정된 것처럼 보였던 사양이 나중에 변경되는 것은 흔한 일입니다. 이런 일이 발생할 때마다 새로운 계약서를 준비하고 계약업무를 진행하는 것은 현실적이지 않습니다. 추가 및 수정해야 할 사항에 대해 다시 그 사양내용을 확정하고, 한꺼번에 메모 등을 체결할 수 있는 경우는 물론이지만, 이런 절차를 진행하지 못한 채 프로젝트가 중단된 경우에는 어떻게 보수를 계산해야 할까요?

이런 경우 참고할 만한 조문으로는 아래에 인용한 ‘일본 상법 제512조'(상인이 그 영업범위 내에서 타인을 위해 행위를 했을 때, 적절한 보수를 청구할 수 있다)가 있습니다(밑줄 친 부분은 저자가 그은 것입니다).

일본 상법 제512조: 상인이 그 영업의 범위 내에서 타인을 위해 행위를 했을 때, 적절한 보수를 청구할 수 있다.

이 조문에서 ‘적절한 보수’라는 것이 구체적인 상황에 따라 결국 얼마가 되는지가 문제가 됩니다. 과거의 판례를 보면, 작업의 노동시간이나 분량, 또는 기간에 비례하여 그 비용을 부담해야 한다는 거이 채택되어 있는 것으로 보입니다. 이는 시스템개발 업무가 그 성격상 일종의 서비스업이며, 원가가 기본적으로 인건비인 것에 기인하는 것으로 보입니다.

따라서, 상법상 ‘적절한 보수’라는 표현의 추상성에 반해, 이런 맥락에서의 추가보수 금액의 시세를 추정하는 것은 그렇게 어려운 계산을 요구하지 않습니다. 아래에서 몇 가지 판례를 살펴보겠습니다.

사례 1: 노동시간 증가에 비례한 추가보수를 인정한 사례

본 사양 변경에 기초한 개발 노동시간은 위의 노동시간 총합인 257.5인/일로 보는 것이 적절하며, 이를 1인/일당의 개발 비용을 본 사건 개발위탁계약과 같은 32,500엔(제3조에서, 단가는 650,000엔[1인/월당]이며, 한 달의 근무일수를 20일로 하면, 1인/일당의 개발 비용은 32,500엔이 된다.)으로 환산하면, 본 사양 변경 요구에 기초한 추가 개발 비용은 8,368,750엔으로 하는 것이 적절하다.

오사카 지방법원 2002년(헤이세이 14년) 8월 29일 판결

‘1인/일당’이 키워드입니다. 추가 보수 계산 근거로 노동시간을 사용하고 있음을 나타냅니다.

사례 2: 프로그램 수에 비례한 추가 보수를 인정한 사례

본 사건에서 추가분을 포함한 적절한 보수 금액을 검토하면, 컴퓨터 시스템 개발의 원가 대부분이 기술자의 인건비이며, 그 인건비는 작성하는 프로그램의 분량에 대체로 비례한다는 점을 고려하면, 초기 계약 금액인 23,250,000엔을 2차 검수까지 완료한 206개의 프로그램 수로 나누고, 이 프로그램 1개당의 단가에 3차 검수를 거친 프로그램 수 414개를 곱한 금액 46,725,728엔(23,250,000÷206×414=46,725,728)을 적절하다고 인정한다.

도쿄 지방법원 2005년(헤이세이 17년) 4월 22일 판결

숫자가 많이 나오지만, 차분히 읽어보면 어려운 계산을 하고 있는 것이 아님을 알 수 있습니다. 초기 계약 내용을 기반으로 ‘프로그램 1개당 단가를 얼마로 보고 이야기를 했는가’를 확인한 후, ‘단가×수량’이라는 간단한 곱셈을 하고 있을 뿐입니다.

사례 3: 기간의 길이에 비례한 추가 보수를 인정한 사례

그리고, 제3조 계약에서 원고의 2005년(헤이세이 17년) 1월부터 3월까지의 3개월 기간 동안의 준위임으로서의 작업 대가로서, 60,000,000엔이 정해져 있는 곳에서, 같은 해 4월 이후의 작업에는 무상으로 수행하는 작업이 포함되어 있는 반면, 전년과 같이, 같은 해 3월까지의 기간에 비해 새 학기 시작으로 인해 수강 등록 등의 시스템이 작동되는 같은 해 4월 이후의 작업량이 증가할 것이 예상된다. 이러한 점들을 고려하면, 위의 3개월 동안의 작업 대가로서 정해진 60,000,000엔을 기초로, 원고의 2005년(헤이세이 17년) 4월부터 9월의 6개월 동안의 작업에 대한 보수는 1억 20,000,000엔으로 하는 것이 적절하다.

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

위 판결은 연장된 기간에 대해서도 간단한 비례계산으로 추가보수를 계산하고 있다는 점을 보여줍니다.

요약

위에서 언급한 여러 판례를 살펴보면, 프로그래머나 엔지니어의 추가보수에 대한 법적처리에는 일정한 법칙성과 공통점이 보이는 것 같습니다. 즉, 원칙적으로는 투입된 노동시간, (제공된 프로그램 등의) 형식적인 작업량, 근무 시간이나 기간 등 상대적으로 객관성이 높은 지표를 기반으로 가능한 한 단순하게 계산하려는 태도를 볼 수 있을 것입니다.

정확한 의미에서의 절차화나 완벽한 노동시간의 추정에 실패하여 추가개발이나 기능수정이 발생하는 경우를 고려한다면, 인력을 투입한 만큼, 혹은 수행한 작업의 형식적인 양만큼, 투입된 시간만큼 추가보수가 발생한다는 것은 다소 당연한 이야기로 보일 수 있습니다. 그러나, 수탁자 측의 입장에서 보면, 고객의 이익을 우선시하면서도 업무를 수행하려는 목표를 가지고 있더라도, 이러한 권리가 법적으로 인정될 가능성이 있다는 것은, 어떤 위기 관리 상의 이야기로서도 의미가 있어보입니다.