법적 관점에서 본, 시스템 개발에서의 변경 관리 방법은 무엇인가

시스템 개발 프로젝트에서는 위탁자가 사전에 설명한 내용이 작업이 진행되는 과정에서 나중에 변경되는 경우가 종종 있습니다. 따라서, 작업을 수행하는 벤더로서도, 한 번 체결한 계약에 대해서도 나중에 계약내용의 변경에 대응해야 할 필요가 생기는 경우가 있습니다.

본 글에서는 예상대로 진행되지 않는 시스템 개발 프로젝트에 대해 법적관점에서, 사후에 이루어지는 ‘변경’이라는 현상을 어떻게 다루어야 하는지에 대해 설명하고 있습니다.

시스템 개발 프로젝트는 왜 ‘변경’이 이루어지는가

시스템 개발은 벤더와 위탁자의 공동 작업

시스템 개발은 일반적으로 기획·제안 단계를 거쳐, 개발 요구사항이 정의되고 계약이 체결됩니다. 그리고 계약이 체결된 이후에는 다양한 설계를 거쳐, 설계대로 구현이 이루어지는 과정을 마치고, 마지막으로 테스트를 진행하여 종료하는 흐름을 따르는 것이 일반적입니다. 그리고 전체과정에서, 일을 맡는 벤더가 시스템 개발 전문가로서 광법위한 의무를 지는 것은 물론이지만, 위탁자측에도 일정 협력의무가 부과됩니다. 만들어야 할 시스템이 가져야 할 기능의 세부사항(=요구사항 정의)이나, 화면 측의 외관이나 조작감(=기본 설계), 그리고 요구사항에 맞는 것이 만들어졌는지 확인(=테스트 또는 검수) 등의 과정에서 특히, 위탁자 측의 협력이 중요해집니다.

협력의무는 있지만, 위탁자는 종종 변경을 요구한다

하지만 시스템 개발 전문가가 아닌 위탁자가 항상 계획성을 가지고, 시스템 개발에 필요한 정보를 항상 충분히 포괄적으로 벤더에게 전달할 수 있을지라면, 그렇지 않습니다. 실제로는, 세밀하고 정밀한 작업이기 때문에, 어떤 사실이 후속 과정에서 결정적인 의미를 가질 수 있는지 등은 위탁자에게도 예측할 수 없는 경우가 많습니다. 따라서 아이러니하게도, 중요한 사실일수록 나중에 조금씩 나오는 상황이 될 수도 있습니다. 이러한 상황으로 인해, 실제 프로젝트에서는 ‘상류 과정에서 하류 과정까지 일관성’이 이상적이지만, 사후에 다양한 변경이 이루어질 수 있다는 가정하에, ‘변경관리’를 어떻게 할 것인지가 중요해지는 것입니다.

변경관리서란?

변경관리서가 사용되는 상황

변경관리서란, 위탁자가 벤더에게 사전에 설명한 내용에서 사양변경이나 기능추가를 요청할 때 사용하는 문서를 말합니다. 앞서 언급한 바와 같이, 요구사항 정의나 기본설계 등의 단계에서, 위탁자도 벤더의 업무에 대해 협력하는 의무를 지지만, 그 후의 과정에서 나중에 다른 요구를 제기하는 것은 실제로 발생할 수 있는 일입니다.

변경관리서가 필요한 상황의 예로는

• 요구사항정의나 기본설계에 누락된 부분이 있어, 사후 기능추가를 요청하는 경우
• 개발중간에 사업방향 등이 재검토되어, 사양변경이 필요한 경우

등이 있을 수 있습니다.

또한, 기능추가나 사양변경과 같은 주제와 관련해, 일을 받는 측에서 가장 궁금한 점음, 견적금액의 변경이 법적으로 인정되는지 여부일 것입니다.

이런 사후적인 견적증액을 진행할 때, 그 내용의 견적의 타당성을 추정하는 근거가 되는 것이 변경관리서입니다. 추후 증액된 견적을 기반으로 청구시, 살대방과 문제를 일으키지 않기위해(또한 문제가 발생했을 때 자신의 주장에 설득력을 부여하기 위해), 변경관리서 작성이 중요합니다.

변경관리서의 기재사항

그렇다면, 법적으로 변경관리서에 기재해야 할 사항은 어떤 것들이 있을까요? 변경관리서를 이용하여, 사양변경·기능 추가에 응하는 계약구조는 이미 일반적으로 널리 인식되고 있는 것입니다. 따라서, 경제산업성 모델계약 등, 관청이 제시하는 계약조항의 틀을 확인함으로써, 어떤 사항을 기록으로 남겨야 하는지 대체로 알 수 있게 됩니다.

(변경 관리 절차)
제 37 조 甲 또는 乙은, 상대방으로부터 제 34 조(시스템 사양서 등의 변경), 제 35 조(중간 자료의 위탁자에 의한 승인), 제 36 조(미확정 사항의 처리)에 기초한 변경 제안서를 수령한 경우, 해당 수령일로부터 ○일 이내에, 다음의 사항을 기재한 문서(이하 ‘변경관리서’라 한다.)를 상대방에게 제출하고, 甲 및 乙은, 제 12 조에서 정한 연락 협의회에서 해당 변경의 가능 여부에 대해 협의할 것이다.
① 변경의 명칭
② 제안의 책임자
③ 연월일
④ 변경의 이유
⑤ 변경에 관한 사양을 포함한 변경의 상세 사항
⑥ 변경을 위해 비용이 필요한 경우 그 금액
⑦ 검토 기간을 포함한 변경 작업의 스케줄
⑧ 그 외 변경이 본 계약 및 개별 계약의 조건(작업 기간 또는 납기, 위탁료, 계약 조항 등)에 미치는 영향

직접 조항을 읽고, 기재가 권장되는 항목을 확인하면, 더 이상의 설명은 필요 없을 것입니다. 나중에 ‘말했다·말하지 않았다’의 문제를 일으키지 않기 위해서는, 상세하고 구체적으로 변경의 경과를 기록해야 한다는 것입니다.

이런 기재 사항을 명시한 후, 벤더와 위탁자 양측의 책임자·결재자의 서명 또는 도장 등이 세트가 되면, 만일 법정에 오르게 되는 일이 있더라도, 증거로서 계약서와 동등한 의미를 가지게 됩니다.

변경관리에 대해 알아두면 좋은 것들

변경관리는 대개 이슈관리와 함께 진행되어야 합니다

변경관리서의 작성이유는 변경이력을 관리함으로써 프로젝트를 성공적으로 이끌어가는 것(또는 성공적으로 이끌어가지 못했을 경우, 부당한 책임추궁을 피하는 것)에 있습니다. 이러한 목표를 달성하기 위해 실무에서는 변경관리서의 작성이 이슈관리목록의 작성 및 업데이트와 함께 이루어지는 경우가 많습니다. 즉, 변경이력을 변경관리표에서 관리하면, 그 합의된 변경항목은 추후 진행해야 할 이슈로서 이슈관리 목록의 항목에 포함됩니다.

변경협의 방법에 대한 규정도 함께 설정하는 것이 좋습니다

변경경관리 방법뿐 아니라, 변경에 대한 협의밥법에 대해서도 함께 규정을 설정해두면, 변경대응이 원활하게 진행될 것으로 기대할 수 있습니다. 이 점은 특히 애자일 개발 등, 사후에 다양한 변경이 이루어지는 것이 전제되어 있는 개발 방법을 채택하는 경우에는 특히 중요한 점일 것입니다. 실무에서도, 변경 관리에 대한 협의 요청이 있을 경우, 상대방이 언제까지 협의에 응해야 하는지 등을 규정하는 예는 많이 볼 수 있습니다.

변경 협의와 성실 의무

양 당사자가 한 번 합의한 계약에 대해, 사후에 그것을 변경하는 경우, 그것은 새로운 계약을 체결하는 것이라고도 할 수 있습니다. 계약이 당사자의 자유 의지에 기초하는 것이라면, 원칙적으로는, 벤더가 변경 계약에 응할 의무는 없다고 할 수 있습니다. 그러나, 이러한 권리 측면이 과도하게 강조되면, 현실적으로 시스템 개발 프로젝트가 원활하게 진행되지 않게 될 것이라는 우려가 있을 수도 있습니다.

그래서 실무에서는 계약서 내에 ‘변경에 대한 협의에 성실하게 응할 의무’에 대해 명시되어 있는 경우가 많으며, 벤더가 변경에 성실하게 응하지 않을 경우에는 손해배상 청구 등이 가능하도록 하는 기재가 있는 예도 있습니다.

기재 예로는, 예를 들면 다음과 같은 문장입니다(아래에는 조문의 기재 예를 게시하였습니다. 독립 행정 법인 정보 처리 촉진 기구 공식 작성의 “ff기본/개별 계약 모델의 기본 계약서안”에서 인용하였습니다).

제4조 3항 변경 협의에서는, 변경의 대상, 변경의 가능성, 변경에 따른 대금·납기에 대한 영향 등을 검토하고, 변경을 실시할지에 대해 양 당사자 모두 성실하게 협의한다.

변경 방법에 대한 규정

앞서 언급한 바와 같이, 변경을 실시할 때는, 매번 변경에 관한 협의를 개최하는 것이 법적으로는 ‘안전’합니다. 그러나, 소규모 프로젝트라면, 굳이 변경에 관한 협의 방법까지 정해두지 않아도 될 경우도 있을 것입니다. 그런 경우에는, 협의에 대한 규정을 두는 대신, 협의 없이도 변경 관리서에 위탁자·벤더 각각의 책임자의 서명·도장을 하여, 처음으로 변경이 이루어지는 방식을 취할 수 있습니다. 구두로만 합의하여 쉽게 변경할 수 있게 하면, 변경이 이루어졌는지 여부가 애매해지는 경향이 있어, 나중에 큰 문제가 될 수 있으므로, 문서 관리는 철저히 해야 합니다.

그러나, 매번 변경 관리를 위해 별도의 문서를 준비하는 것조차 부담스럽고, 임기응변적인 대응을 더 중요시하고 싶을 수도 있습니다. 그런 경우에는, 회의록 중에 변경 관련 사항을 문서화해두는 방식을 취할 수도 있습니다.

요약

자주 사양 변경이 이루어지는 현장에서는 확실히, 여러가지 문제나 갈등의 위험이 동반되기 쉽습니다. 그러나, 이러한 유연성이 요구되는 현장에서 단지 깐깐하게 ‘관리의 중요성’을 강조하는 것만으로는, 현실적인 대책을 마련하는 것이 어려울 수 있습니다.

비즈니스에서 요구되는 속도감과, 만일의 사태에 대비하는 것을 어떻게 양립시킬 것인지에 대한 문제는, 회사의 상황이나 프로젝트의 내용에 따라 최적의 해결책이 다를 수 있습니다. 이 글의 내용을 참고하면서도, 회사별, 프로젝트별로 적절한 방법을 각자 찾아가는 태도가 중요하다고 생각됩니다.