시스템 개발 프로젝트의 '화재'와 관련된 법률은 무엇인가

시스템 개발이라는 프로젝트는 하루아침에 이루어질 수 있는 것이 아니며, 많은 사람들과 조직, 엄청난 자금, 그리고 장기간의 개발 기간 등 많은 리소스를 투입해야만 가능한 일입니다. 본 글에서는 시스템 개발 프로젝트에서 ‘화재’라는 현상이 법적 틀에서 어떻게 정리될 수 있는지를 설명하고, 해결책의 지침을 정리해 나갈 것입니다.

프로젝트는 왜 ‘화재’가 발생하는가

하나의 IT 시스템은, 그것이 비록 특별히 대규모 프로젝트가 아니더라도, 대량으로 생성된 프로그램 파일과 소스 코드의 적층이 있어야만 제대로 기능합니다. 화면 측에서 본 조작감만으로는 도저히 상상할 수 없을 정도로(또는 오히려, 화면 측에서 본 조작감이 단순하고 간결한 IT 시스템일수록), 세밀하고 정교한 제작을 하고 있는 경우가 많습니다.

• 납기일만 먼저 결정되고, 사양과 요구사항은 모호한 상태로 시간이 지나버린 경우
• 회사 내부 정치 문제에만 멤버들이 집중하고 있어, 인간관계 스트레스로 중간에 탈퇴하는 멤버가 많은 경우
• PM을 비롯한 관리 계층에서 협상력이 부족하며, 멤버에게 적절한 보고, 연락, 상담을 요구하지 않는 경우

등, 구체적인 화재 발생 이유는 프로젝트마다 다양할 것입니다. 그러나 법적으로 보면, 프로젝트의 화재 발생 이유는 몇 가지 유형으로 비교적 단순하게 정리할 수 있습니다.

화재 유형 1: 프로젝트가 중간에 중단되는 경우

시스템 개발 진행 과정에서, 중간에 중단되는 이유의 전형적인 예로 위탁자 측과 벤더 측의 커뮤니케이션 부재를 들 수 있습니다. 원래 시스템 개발이라는 프로젝트는 벤더 측의 전문적인 기술력과 조직력이 필요한 것은 물론, 최종적으로 해당 시스템을 사용하는 위탁자 측의 협력이 있어야만 이루어질 수 있습니다.

따라서, 하나의 프로젝트에 대해, 양측이 어떤 역할을 맡을 것인지에 대한 정리가 모호한 상태에서 프로젝트가 진행되고, 어떤 종류의 ‘업무의 떠넘기기’ 같은 것이 발생하면, 그 원활한 진행이 방해받게 됩니다. 위탁자 측의 의무, 벤더 측의 의무, 각각에 대한 법적 고찰에 대해서는 아래의 기사를 참고하시기 바랍니다.

https://monolith.law/corporate/project-management-duties[ja]

https://monolith.law/corporate/user-obligatory-cooporation[ja]

각자가 부담하는 책임이 어떤 것인지에 대한 자세한 내용은 위의 기사를 확인하시면 되지만, 여기서의 핵심은 하나의 시스템 개발 프로젝트에서도 위탁자와 벤더 각각이 일정한 책임을 부담하고 있다는 점입니다. 대략적인 구분으로는, 요구사항 정의, 화면 등의 외관에 관한 설계(즉, 기본 설계), 검수 등, 위탁자 측의 협력 없이는 완료되지 않는 부분에 대해서는, 과거의 판례와 사례가 위탁자 측의 협력 의무를 인정하고 있습니다.

반면에 벤더 측도, 위와 같은 점에서 위탁자 측의 협력을 받은 상태에서(그리고 동시에, 위와 같은 협력을 요구하는 커뮤니케이션 노력을 한 상태에서), 프로젝트의 원활한 진행과 그 방해 요인의 발견 및 제거에 대한 포괄적인 의무를 부담하고 있습니다.

이러한 생각을 바탕으로, 내부 시스템으로서, 위탁자가 내부에서 거버넌스를 효과적으로 적용하는 의무와, 벤더가 외부 전문가로서 전문성과 기술력을 발휘하여 업무를 수행하는 의무를 양측이 보여주고, 모든 분쟁을 공정하게 다루려는 태도를 법원이 보여주고 있습니다.

또한, 이러한 ‘중단’이 발생하기 쉬운 곳은 검수 단계입니다. 검수에 대해서는 아래 기사에서 자세히 설명하고 있습니다.

https://monolith.law/corporate/estimated-inspection-of-system-development[ja]

이러한 경우에, 한번 분쟁이 발생하면, 그곳에서는 과거 프로젝트의 추이, 회의의 진행 내용 등, 객관적으로 확인 가능한 증거가 중요시되는 경우가 많습니다. 따라서 그곳에서는, 사전에 기록되어 온 문서가 큰 의미를 가지게 됩니다. 자신의 입장을 불리하게 하지 않기 위해서도, 문서 관리의 철저함이 중요합니다. 시스템 개발에서의 문서 관리의 중요성에 대한 관점에서는, 아래의 기사에서 자세한 설명을 하고 있습니다.

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

화재 유형 2: 위탁자 측의 개인적인 사정으로 해지하는 경우

또한 프로젝트 중간에 위탁자 측의 요구로 중단이 결정되는 경우도 있습니다. 예를 들어, 해외 기지를 포함하여 인사 관리를 일괄적으로 수행하는 IT 시스템을 구축하기 시작했는데, 기업의 해외 진출이라는 판로 확장 전략 자체가 철회되었다고 가정해봅시다. 이런 경우에는, 이미 시작한 그 시스템의 개발은 더 이상 위탁자에게 필요하지 않을 수도 있습니다.

기본적으로, 기업에서 사용되는 IT 시스템이 어떻게 구축되어야 하는지에 대한 문제는, 그 전제로서 ‘해당 기업에 어떤 업무가 있는지’라는 문제와 분리할 수 없는 것입니다. 따라서, 조직 체계나 사업부 재편의 큰 변화, 전략의 근본적인 재검토 등의 영향을 받아 필요한 (또는 불필요한) 시스템의 요구사항이 사후에 변경되는 것은 실제로 가능한 일입니다.

이러한 상황으로 인해, 중간에 프로젝트가 중단되는 경우에도 다양한 법률 문제가 발생합니다. 이 경우 일반적으로, 위탁자의 개인적인 사정이므로, 완성도에 따른 보수 청구 등, 공급자 측에도 일정한 법적 권리가 인정됩니다. 어떤 계약 유형이 채택되었는지에 따라, 근거가 되는 조항에는 차이가 있지만, 그 내용은 다음과 같이 정리됩니다.

・도급계약의 경우: 일본 민법 641조
일본 민법 641조
→도급인이 작업을 완료하지 않는 동안, 주문자는 언제든지 손해를 배상하고 계약을 해지할 수 있다.
・준위탁 계약의 경우: 일본 민법 648조 3항 (상황에 따라, 일본 민법 651조에 따른 손해배상 청구도 가능)
일본 민법 648조
→위탁이 수임자의 책임으로 돌릴 수 없는 사유로 이행 중간에 종료되었을 때, 수임자는 이미 이행한 비율에 따라 보수를 청구할 수 있다.
일본 민법 651조
→1. 위탁은 각 당사자가 언제든지 그 해지를 할 수 있다.
→2. 당사자 중 한쪽이 상대방에게 불리한 시기에 위탁을 해지했을 때, 그 당사자 중 한쪽은 상대방의 손해를 배상해야 한다. 그러나, 어쩔 수 없는 사유가 있었을 때는, 이에 한하지 않는다.

화재 유형 3: 제공된 시스템의 결함이 나중에 발견된 경우

위탁자 측에서는 시스템의 완성도를 화면 측의 조작감에서 파악하는 경우가 많지만, 일을 받는 측에서 보면 데이터베이스의 설계나, 모든 조작 방법을 고려한 테스트 항목을 도출하는 것이 오히려 복잡합니다.

즉, 처음 사용하기 시작했을 때는 문제없이 작동하는 것처럼 보였던 시스템이라도,

• 등록되는 데이터의 양이 증가함에 따라 처리 속도가 느려지기 시작했다
• 매일의 기본 업무에서는 문제없이 작동하는 것처럼 보였던 시스템도, 몇 개월 혹은 몇 년에 한 번 발생하는 특수한 작업에서 버그가 발생하는 것을 알게 되었다
• 표면적으로는, 결과 출력이 정확하게 이루어지는 것처럼 보이지만, 실제로는 로직이 맞지 않았다(예를 들어, 위탁자 측에서 ‘1+1’이라는 입력에 대해 정확하게 ‘2’가 출력되고 있어도, 정확한 계산 처리가 이루어지고 있다고는 할 수 없습니다. 어떤 계산식을 입력하더라도 ‘2’라는 출력을 반환하는 등, 로직의 오류는 대부분 화면 조작만으로는 발견하기 어렵습니다. 이런 의미에서 테스트 과정에도 어느 정도의 ‘기술력’이 요구됩니다.)

등과 같은 문제가 실제로 발생할 수 있습니다. 이러한 사건을 강제로 법적 관점에서 분석하면, 벤더 측의 프로젝트 관리 의무 위반, 즉 민법상의 불완전 이행 문제가 될 가능성이 있습니다.

이 경우, 계약상 특별한 규정이 없는 경우에는, 일반적으로 도급계약에 관한 규정이 적용됩니다.

그 경우에 고려해야 할 포인트는 다음과 같이 정리됩니다.

https://monolith.law/corporate/defect-warranty-liability[ja]

이와 같이 정리됩니다.

요약

각각의 시스템 개발 프로젝트는 다양하게, 그리고 복잡하게 진행될 것입니다. 그러나 법률적인 측면에서의 프로젝트 ‘화재’라는 이야기가 나온다면, 이 글에서 제시한 프레임워크가 한 가지 지표가 될 것입니다. 시스템 개발과 관련된 법률 문제는 확실히 매우 다양한 주제를 포함하고 있습니다.

그러나 시스템 개발이라는 업무가 구조적인 사고력을 요구하는 것과 마찬가지로, 그에 따르는 위험 관리 역시 전체적인 분야의 전체 이미지를 잃지 않음으로써, 더욱 건설적으로 수행할 수 있게 될 것입니다.