시스템 개발에서의 구 시스템으로부터의 이전에 따른 법률 문제

기업에서 새로운 IT 시스템을 만드는 것은 IT 엔지니어의 대표적인 업무 영역이지만, ‘새로운 시스템을 만든다’는 것은 ‘지금까지 사용되던 시스템을 폐기한다’는 과정이 동시에 포함되는 경우가 많습니다. 이 글에서는 새로운 시스템 개발이라는 프로젝트를 ‘기존 시스템의 폐기’라는 관점에서 재조명하고, 그에 따르는 다양한 법률 문제에 대해 설명하겠습니다.

새로운 시스템으로 이전한다는 것은 무엇을 의미하는가

IT 시스템의 수명은 영원하지 않다

기업에서 사용하는 IT 시스템이 한 번 만들어지면 영구적으로 사용할 수 있는 것인지에 대해 말하자면, 그렇지 않습니다. 또한, 오래된 것을 계속해서 소중히 사용하는 것이 반드시 좋은 것도 아닙니다. 기업마다, 또 시스템의 용도마다 당연히 차이는 있지만, 대략적인 기준으로, 하나의 시스템은 최대 약 10년 정도 사용한 후에는 새로운 것으로 교체하는 것이 좋다는 경영 판단이 내려지는 경향이 있습니다.

10년이라는 시간이 지나면, 시장에 유통되는 컴퓨터의 성능도 크게 변화하게 됩니다. 그렇게 되면 예를 들어, 10년 전에는 (사람들에게는 단순하고 우수한 설계이지만) 컴퓨터의 처리 속도 등의 제약으로 인해 구현이 현실적이지 않았던 프로그램도, 현재는 구현 가능해진 경우도 있을 수 있습니다. 또한, 한 번 만들어서 10년 동안 계속 사용해온 것이라면, 그 사이에 회사의 업무 흐름이나, 사내 규칙도 많이 변화했을 수 있습니다. 이러한 회사의 내외 경영 환경의 변화에 대응하기 위해 후속으로 구현된 코드는, 화면에서는 인식할 수 없을 정도로 복잡하고 복잡한 구조가 되어버릴 수 있습니다. 이렇게 되면 점차 위탁자가 추가로 원하는 기능이 있어도, 개발자 측에서는 더 이상 추가 구현이 불가능해지는 상황이 될 수도 있습니다.

오래된 시스템은 점차 IT 엔지니어에게 많은 ‘수동 작업’ (예를 들어, 개별 데이터를 추출하기 위한 쿼리를 발행하는 등의 운영 업무)을 발생시키게 될 수 있습니다. 시스템 자체도, 오래되면 불행하게도 업무를 ‘개인화’하게 됩니다. 너무 오래되어 개인적인 업무가 많아진 시스템 관련 업무에 대해, 추가적인 ‘시스템화’ 조치를 취하려고 할 때, 그곳에는 ‘기존 시스템에서 이전하기 위한 새로운 시스템 개발’이라는 프로젝트가 시작되게 됩니다.

신규 시스템 개발은 기존 시스템 폐기와 함께 진행된다

앞서 언급한 바와 같이, 모든 시스템 개발 프로젝트가 그런 것은 아니지만, 하나의 시스템 개발 프로젝트에는 기존 시스템에서의 전환 측면을 동시에 포함하는 경우가 많습니다. 시스템 자체는 특정 날짜를 기점으로 비연속적으로 전환되는 경우가 많을 것입니다.

그러나 일상 업무의 진행 자체는 과거에서 현재, 현재에서 미래로 이어져야 합니다. 과거의 데이터는 필요한 만큼 보관하면서, 현재의 업무 진행을 방해하지 않고, 더 나아가 미래를 향한 우수한 ‘시스템화’의 구상을 제시하는 등, 신규 시스템으로의 전환에는 다양한 과제가 수반하는 경우가 많습니다. 이러한 상황들이 복합적으로 결합되어, 신규 시스템의 개발과 기존 시스템의 운영 및 유지 보수 등의 업무가 복잡하게 연관되어, 분리할 수 없는 관계를 형성하는 경우도 있습니다.

새로운 시스템으로의 전환 단계란?

기존 시스템에서 새로운 시스템으로 전환할 때, 특히 중요한 것은 데이터를 적절하게 이전하는 것입니다. 데이터를 이전하는 단계는 일반적으로 다음과 같은 절차를 따라 진행되는 경우가 많습니다.

1. 기존 시스템이 보관하고 있는 데이터 중에서, 새로운 시스템으로 이전해야 할 것이 무엇인지를 명확히 합니다. 새로운 시스템의 화면에서 쉽게 검색할 수 있는 데이터가 무엇인지, 또한 화면에서 검색할 수 없어도 (감사 대응 등의 경우에) 필요에 따라 꺼낼 수 있도록 해야 하는 데이터가 무엇인지 등의 구분도 함께 필요합니다.
2. 1에서 식별한 데이터 중에서, 새로운 시스템에 가져올 데이터를 CSV 파일 등의 형식으로 출력합니다.
3. 2에서 추출한 데이터를 새로운 시스템에 가져옵니다.
4. 3에서 가져온 데이터가 새로운 시스템에서 반영되었는지 여부를 검증하고, 올바르게 이전되었는지 확인합니다. → 올바르게 이전되었는지의 검증 결과는, 화면의 표시 화면이나 출력물을 통해 증거 자료를 남기는 것이 일반적입니다(소위 테스트 과정).

새 시스템으로의 전환은 위탁자와 벤더의 역할 정리가 어렵다

앞서 언급한 데이터 이전 단계에서 종종 문제가 되는 것은, 위탁자 측이 그것을 어디까지 자사 내부의 문제로 보고 관리해야 하는지에 대한 문제입니다. 또한, 데이터 이전에 한정되지 않고, 시스템 개발 프로젝트 전반에 걸친 ‘위탁자의 협력 의무’에 대한 개요는 아래의 기사를 참조하십시오.

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

일반적으로 시스템 개발이라는 프로젝트에서는, 벤더가 시스템 개발을 위한 전문적인 노하우라는 측면에서 위탁자에게 우월한 경우가 많습니다(또는 오히려 그 점이 업무를 맡게 된 이유가 되는 경우가 많습니다). 그러나 반면에, 자사의 시스템의 ‘이상적인 모습’에 대해 논의하는 것은 대부분 위탁자 측에서만 할 수 있는 일입니다.

이러한 점을 고려하면, 앞서 언급한 절차 1, 4를 위탁자가 수행하는 역할 정리가 하나의 방법이 될 수 있습니다. 다른 말로 표현하면, 일련의 데이터 이전 과정에서, 이전해야 할 데이터의 ‘요구 사항 정의’, 요구 사항에 따라 데이터를 이전했는지 여부의 ‘검수’가 각각 위탁자의 협력 의무로 정리하는 방법이라고도 할 수 있습니다. 또는 다른 정리 방법으로, 위탁자 측에도 해당 구 시스템에 대한 풍부한 지식을 가진 사람이 있다면, 절차 2에 대해서도 위탁자 측의 담당으로 할 수도 있을 것입니다.

외주를 굳이 맡기지 않아도, 구 시스템에 대한 이야기는 회사 내에서 처리할 수 있다면, 새 시스템에 대한 이야기만을 벤더에게 외주하고 싶다는 생각으로 발주될 수도 있습니다. 이런 방식으로, 데이터 이전 작업에서는, 위탁자와 벤더 각각의 역할 정리가 때때로 모호해질 수 있습니다. 또한, 위탁자가 벤더에게 시스템 개발 관련 업무를 외주하는 경우, 일반적으로 벤더에게 어떤 역할이 기대되고, 어떤 법적 의무가 귀속되는지에 대한 일반적인 설명에 대해서는 아래의 기사도 함께 참조하십시오.

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

새 시스템으로의 전환과 관련된 과거 판례

새로운 시스템으로의 전환을 목표로 하는 시스템 개발 프로젝트에서 실제로 문제가 발생하여 소송이 진행된 사례가 있습니다. 아래에 인용한 판결문의 사례는 데이터 전환 과정에서 전환 작업에 실패하여 새 시스템에서 여러 데이터의 불일치와 버그가 발생하고, 납기일에도 지연이 발생한 경우입니다. 이러한 다양한 문제에 대해 벤더와 위탁자 측이 각각 프로젝트에 어떤 의무를 지고 있었는지가 논점이었습니다. 결론적으로 벤더 측이 원래 지녀야 할 주의 의무를 다음과 같이 판시하고, 벤더 측의 주의 의무 위반을 인정하였습니다.

피고는, 본 건 계약에 따른 데이터의 전환 업무로서, 본 건 기존 시스템의 데이터를 본 건 새 시스템에 단순히 전환하는 것에 그치지 않고, 전환된 데이터로 본 건 새 시스템을 가동하는 채무를 가지고 있었으며, 구체적으로는, 데이터 전환 업무를 시작하기 전에, 본 건 기존 시스템의 전환 대상이 되는 데이터를 조사·분석하여, 데이터의 성질이나 상태를 파악하고, 해당 데이터가 본 건 새 시스템에 전환된 후, 그 가동에 장애가 발생할지를 검토하고, 장애가 발생할 경우, 언제, 어떤 방법으로 해당 데이터를 수정할지 등에 대해 결정한 후, 데이터 전환 업무(전환 설계, 전환 도구 개발, 데이터 전환)에 착수하고, 최종적으로는, 본 건 기존 시스템에서 전환된 데이터로 본 건 새 시스템을 가동하는 채무를 부담하였다

는 것으로 인정하는 것이 적절하며, 본 건에서는, 데이터 전환에 있어서, 데이터 불일치를 수정·해결해야 할 의무를 지는 것이 맞다.

도쿄지방법원 헤이세이 28년(2016년) 11월 30일

이 사례는 절차 1과 절차 4를 위탁자 측이 맡고, 절차 2와 절차 3를 벤더 측이 맡는 역할 분배가 원래 이루어져 있었습니다. 즉, 기존 시스템에서 데이터 추출(절차 2)을 벤더 측이 한 번 맡았던 것입니다. 따라서 법원도, 데이터 추출을 포함하여, (시스템 개발 전문 업체로서) 벤더가 맡았다면, 그 데이터 추출 작업이 정말로 원활하게 진행될 수 있는지 등도 사전에 검토할 수 있어야 했다고 판단하였습니다.

그러나, 만약 절차 2(즉, 데이터 추출)를 위탁자 측의 업무로 사전에 역할 분배를 하고, 그 후에 추출 작업에 실패했다면 어떻게 될까요? 이 경우에 생각할 수 있는 것은, 위탁자가 데이터 추출이 원활하게 진행될 수 있는지에 대한 사전 조사를 게을리 한 탓에 납기일에 지연이 발생한 것으로, 이번에는 반대로 위탁자 측이 협력 의무 위반을 지적받게 될 가능성도 있을 것입니다.

또한, 이러한 판단은, 반드시 계약서만이 아니라, 시스템 개발의 진행에 따른 회의록 등도 증거로 사용됩니다. 회의록의 중요성에 대해서는 아래 기사에서 자세히 설명하고 있습니다.

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

요약

시스템 개발이라는 프로젝트는 위탁자 측과 벤더 측 모두가 상호간에 많은 의무를 지면서, 세심하게 커뮤니케이션을 하며 진행해야 하는 것입니다. 따라서 앞서 언급한 판례에서도, 전제 조건에 약간의 변동이 생기면, 책임 대상은 위탁자와 벤더 양측으로 쉽게 전환될 수 있습니다.

화면 측의 외관에서는 상상도 할 수 없을 정도로 방대한 데이터와 복잡한 구조를 가진 시스템일 가능성, 약간의 전제 차이로 최종적인 사법 판단의 방향이 크게 바뀔 수 있다는 점 등을 고려하면, 새로운 시스템의 개발 프로젝트의 위험 관리는 기존 시스템의 폐기와 함께 포괄적으로 접근하는 것이 중요하다고 할 수 있습니다.