아자일 개발에 관련된 법률 및 계약 문제란 무엇인가?

시스템 개발을 진행하는 방법론이 존재합니다. 가장 고전적이면서 일반적인 것은 워터폴(Waterfall) 모델이며, 많은 시스템 개발 관련 법률 서적들도 이 모델을 전제로 논의되고 있습니다. 본 글에서는, 서적 등에서 정보를 얻기 어려운 애자일(Agile) 개발 모델을 기반으로 한 시스템 개발에 있어서 어떠한 법률적 문제가 있는지에 대해 설명하겠습니다.

아자일 개발 모델과 법률

시스템 개발에서의 모델이란?

시스템 개발 프로젝트에는, 그 진행 상황을 전체적으로 파악하기 위한 틀로서, 개발 모델이라는 것이 있습니다. 이 중 대표적인 것은 소위 ‘워터폴 모델’일 것입니다. 즉, 강의 ‘상류’에서 ‘하류’까지 한 번에 내려가는 물과 같이, 요구사항 정의, 설계, 구현, 테스트 등의 각 과정을 한 번에 완수하는 것입니다. 가능한 한 과정의 되돌림이나 중복 작업을 줄이는 것을 목표로 하며, 계획적으로 업무를 진행하는 데 적합한 방법입니다.

반면, 아자일 개발 모델에서는, 작은 프로그램을 구현하고 테스트하는 것을 반복합니다. 이렇게 작은 프로그램을 구현하고 테스트하는 반복 작업을 통해, 점차 큰 시스템을 만들어 나가는 것입니다. 이러한 시스템 개발 모델에 대한 더 자세한 설명과, 두 개발 모델의 장단점 비교에 대해서는 아래의 기사에서 더 자세히 다루고 있습니다.

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

아자일 개발 모델의 특징

아자일 개발 모델에 의한 개발의 큰 장점은, 속도감을 가지고 실제 작업에 들어갈 수 있다는 점에 있습니다. 요구사항의 정의나 설계서의 작성과 같은 ‘상류 과정’의 업무와, 프로그램의 구현 업무가 분리되어 있지 않기 때문에, 기능의 추가·수정, 사양 변경 등에 대한 대응도 포함하여, 유연하게 조정을 진행하는 데 적합합니다. 법적으로 보면, 아자일 개발 모델을 성공으로 이끌기 위해 특히 중요한 점은, 문서 관리와 변경 관리를 어떻게 수행하는가입니다. 아자일 개발 모델에서는, 워터폴 모델만큼 역할이나 담당이 명확하게 구분되어 있지 않습니다. 또한, ‘관리’보다는 실행·착수에 이르는 ‘속도’를 중시하는 방법이므로, 각종 설계서·사양서·회의록의 미비가 쉽게 발생할 수 있습니다.

더욱이 변경 관리라는 점에 관련하여 말하면, 아자일 개발 모델은 변경에 대한 대응이 원활하기 때문에, 결재자에게 승인 과정을 건너뛰고, 현장 수준에서 사양 변경 요청에 응답하다 보면 프로젝트가 화재가 발생하는 상황이 될 위험도 있습니다. 이럴 경우, ‘변경에 대한 대응이 원활하다’는 개발 모델의 장점이, 그 자체가 프로젝트의 화재 위험으로 변할 수 있습니다.

아자일 개발에서의 문서 관리와 변경 관리 방법

문서 관리의 중요성

아자일 개발 모델에 기반한 개발 프로젝트에서 법적으로 우려되는 점은, 구두 기반의 대화가 쌓여 문서의 부족을 초래하는 것입니다. 이에 대해, 시스템 개발 프로젝트에서 왜 문서 관리가 중요한지에 대한 설명은 아래의 기사에서 자세히 다루고 있습니다.

https://monolith.law/corporate/the-minutes-in-system-development[ja]

해당 기사에서는, 분쟁의 사전 예방(즉, ‘예방 법률’)과 분쟁이 발생했을 때의 증거 보존(즉, ‘위기 관리’)이라는 두 가지 관점에서 시스템 개발 프로젝트에서의 문서 관리의 중요성을 설명하고 있습니다.

연락 협의회 설치가 문서 관리에 유효

아자일 개발 모델을 채택하는 경우, 워터폴 모델과 달리 사전에 명확한 계획이 준비되어 있지 않습니다. 따라서, 계획과 실적의 차이를 단순히 관리하는 것이 아니라, 현장에 맡기면 금전적으로나 시간적으로 비용이 부풀어버리는 우려가 있습니다.

그래서, 책임자가 프로젝트의 원활한 진행을 위해 정기적인 연락 협의회를 개최하는 조치가 유효합니다. 개발 규모가 작은 경우에는, 정기적인 연락 협의회를 개최하는 것보다는, 책임자들이 차례로 모일 수 있는 때에 모이는 방식이 선호되는 경향이 있습니다. 그러나, 아자일 개발 모델의 경우는 특히 시기적절한 문제를 회의에서 다루지 못하는 위험이 커질 수 있습니다. 따라서, 정기적인 연락 협의회의 개최는 계약서 등에도 포함시켜 두는 것이 안전하다고 할 수 있습니다. 규정 방식으로는, 경제산업성 모델 계약서에서 다음과 같이 제시되고 있습니다.

(연락 협의회의 설치)

제 12 조 甲 및 乙은, 본 사업이 종료될 때까지의 기간, 그 진행 상황, 리스크의 관리 및 보고, 甲乙 양측에 의한 공동 작업 및 각자의 분담 작업의 실시 상황, 시스템 사양서에 포함해야 할 내용의 확인, 문제점의 협의 및 해결 그 외 본 사업이 원활하게 진행될 수 있도록 필요한 사항을 협의하기 위해, 연락 협의회를 개최할 것으로 한다. 단, (중략).

2. 연락 협의회는, 원칙적으로, 개별 계약에서 정한 빈도로 정기적으로 개최하며, 그 외에도, 甲 또는 乙이 필요하다고 인정하는 경우에는 언제든지 개최한다.

3. 연락 협의회에는, 甲乙 양측의 책임자, 주임 담당자 및 책임자가 적절하다고 인정하는 자가 참석한다. 또한, 甲 및 乙은, 연락 협의회에서의 협의에 필요한 자의 참석을 상대방에게 요구할 수 있으며, 상대방은 합리적인 이유가 있는 경우를 제외하고, 이에 응해야 한다.

4. 乙은, 연락 협의회에서, 별도로 甲乙 간에 합의한 양식에 따른 진행 관리 보고서를 작성하여 제출하고, 해당 진행 관리 보고서에 기초하여 진행 상황을 확인하며, 지연 사항의 유무, 지연 사항이 있는 경우 그 이유와 대응책, 본 장에서 정한 추진 체제의 변경(인원의 교체, 증감, 재위탁처의 변경 등)의 필요성, 보안 대책의 이행 상황, 개별 계약의 변경을 필요로 하는 사유의 유무, 개별 계약의 변경을 필요로 하는 사유가 있는 경우 그 내용 등의 사항을 필요에 따라 협의하고, 결정된 사항, 계속 검토되는 사항 및 계속 검토 사항이 있는 경우 검토 일정 및 검토를 수행하는 당사자 등을 확인한다. 

(이하, 제5항, 제6항, 제7항은 생략.)

연락 협의회라는 회의의 존재에, 계약 조항에서도 일정한 정당성을 부여하고, 그 외 임시로 개최되는 회의와는 다른 의미를 부여하고 있는 것이 가장 큰 포인트입니다.

연락 협의회를 변경 관리에 활용하는 방향

또한, 아자일 개발에서는, 양 당사자가 초기에 합의한 사항이 사후에 변경되는 것이 전제 사항이 됩니다. 따라서, 사후적인 사양 변경 상황을 어떻게 관리할 것인지도 매우 중요해집니다.

이때, 연락 협의회가 정기적으로 개최되고 있다면, 변경 관리 방법도 매우 원활해집니다. 예를 들어, 변경 협의는 연락 협의회에서 진행하도록 하고, 한쪽에서 변경 협의 요청이 있을 경우에, 상대방에게 그 협의에 응하는 의무를 계약에 포함시키는 것입니다.(아래에 경제산업성 모델 계약의 규정을 발췌합니다.)

(변경 관리 절차)

제 37 조 甲 또는 乙은, 상대방으로부터 (중략)에 기초한 변경 제안서를 수령한 경우, 해당 수령일로부터 ○일 이내에, 다음 사항을 기재한 문서(이하 ‘변경 관리서’라 한다.)를 상대방에게 제출하고, 甲 및 乙은, 제 12 조에서 정한 연락 협의회에서 해당 변경의 가능성에 대해 협의할 것으로 한다.(이하, 기재 사항에 대해서는 생략)

위 규정의 포인트는, 다음과 같이 정리할 수 있습니다.

• 변경 요청을 받아들이는 방법을 ‘변경 제안서’라는 형식으로 일원화하고 있는 점
  
• 제안서를 수령하고, 그에 대해 협의할 때까지의 날짜에 기한을 설정하고 있는 점 → ‘◯일 이내’라는 표기가 아니더라도, ‘즉시’ 등의 언어로 대체할 수 있습니다.
  
• 변경의 가능성에 대해 협의하는 장소를 ‘연락 협의회’라는 회의로 일원화하고 있는 점
  

즉, 구두 기반으로 ‘변경 요청을 했다, 하지 않았다’, ‘변경의 가능성에 대해 응답했다, 하지 않았다’라는 인식의 차이를 일으키지 않도록, 절차의 방법을 명확하게 하고 있는 것입니다.

성실의무와 신의원칙에 대한 이해가 요구된다

지금까지 ‘연락협의회’, ‘변경협의’ 등에 관한 계약조항의 모델을 소개해 왔습니다. 그러나, 이들의 본질적 이해를 위해 중요한 것은 ‘성실의무’, ‘신의원칙’ 등의 사항입니다. 원래 애자일 개발 모델은 발주자와 수주자의 신뢰 관계 없이는 진행이 어려워질 수 있습니다. 왜냐하면, 실제 작업에 착수하는 속도를 중시하고, 착수에 이르는 절차는 최소한으로 제한되는 것이 일반적이기 때문입니다. 따라서, 상대방에게 ‘성실의무’를 부과하는 조항을 포함하는 것도 실무에서 많아지게 됩니다.

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

이는, 처음부터 신뢰 관계를 기반으로 진행해온 협상에 대해, 갑작스럽게 ‘계약 변경에 응할지 여부는, 전적으로 제안을 받는 측의 자유이며, 강제로 응할 의무는 없다’ 등과 같이, 형식적인 법률론으로 상대를 배신하는 방식을 방지하는 것입니다. 시스템 개발뿐만 아니라, 사인간의 거래에 관련된 법률의 원칙을 반영한 것입니다.

민법 제1조 2항

권리의 행사 및 의무의 이행은, 신의에 따라 성실하게 이행해야 한다.

법은 반드시 형식적인 ‘계약서의 기재 내용’이나 ‘조문의 문장’만을 중시하는 것은 아닙니다. 특히 상대방이 있는 거래라면, 실질적인 ‘신의’와 ‘성실성’을 포함시키면서 유연하게 사용해야 하는 것입니다. 또한, 법적으로 부과되는 ‘의무’라는 것이 반드시 ‘계약’이라는 절차를 기반으로 하는 것이 아닌 점에 대해서는, 아래의 기사에서도 자세히 설명하고 있습니다.

https://monolith.law/corporate/system-development-unlawful-responsibility[ja]

요약

애자일 개발 모델에 기반한 시스템 개발 프로젝트에서는 업무 절차나 관리 체계가 무계획적으로 부실해지는 위험을 이해하는 것이 물론 중요합니다. 그러나 그것만이 아니라, ‘신의 원칙’ 등에 근거한 법의 본래 가진 유연한 특성도 이해하고, 그것을 실무에 활용하는 태도 또한 중요하다고 생각됩니다.