업무 시스템 교체: 언제 두 시스템을 함께 운영하는 것이 도움이 될까요?

교체 기간에 기존 업무 시스템을 계속 사용할 수 있으면 결과를 비교하거나 업무를 관리 가능한 단계로 옮기는 데 도움이 됩니다. 이 기간을 승인하기 전에 구체적인 목적, 기준이 되는 기록의 위치, 차이를 조사할 담당자, 종료에 합의한 조건을 정해야 합니다.

CEO, 운영 책임자 또는 재무 책임자에게 이 결정은 정확한 기록을 유지하고 일상 업무를 완료하는 방식에 관한 문제입니다. “두 시스템을 모두 운영하겠다”는 말만으로는 해결되지 않은 사안이 많습니다. 계획에는 각 시스템의 역할, 직원이 사용할 시스템, 임시 운영에 드는 비용이 담겨야 합니다.

두 시스템을 함께 운영한다는 말의 세 가지 의미

결과 비교. 한 시스템은 실제 업무 처리를 계속하고, 교체 대상 시스템은 비교할 결과를 계산합니다. 가상의 회계 시스템 교체 사례라면 기존 시스템이 청구서를 발행하는 동안, 정해진 같은 기간과 입력값으로 보고서를 비교할 수 있습니다. 계산 결과를 비교하는 과정에서 청구서를 중복 발행하거나 결제, 주문 또는 이메일을 중복 처리하지 않도록 해야 합니다.

어떤 차이가 중요한지, 누가 조사할지 합의해야 합니다. 합계가 같아도 개별 기록, 반올림 규칙 또는 처리 시점이 다를 수 있습니다. 데이터 복사에 성공해도 직원이 수정과 예외 처리를 포함한 필수 업무 흐름을 완료할 수 있는지는 별도로 확인해야 합니다.

책임을 단계적으로 이전. 범위를 정한 기능이나 고객 그룹은 새 시스템으로 옮기고, 나머지 업무는 기존 시스템에 남겨 둡니다. 각 단계에서 직원이 변경 사항을 어디에 입력하는지, 보고서가 어느 기록을 기준으로 하는지 명확한 지침이 필요합니다. 두 애플리케이션을 모두 사용할 수 있다고 해서 모든 기록에 대해 두 시스템이 모두 권한을 갖는 것은 아닙니다.

Microsoft의 Strangler Fig 가이드는 기능을 점진적으로 옮기고 최종적으로 기존 시스템을 제거하는 방법을 설명합니다. 전 과정에서 종속성과 공유 데이터를 살펴야 합니다. 사업 책임자는 각 단계를 운영하고 확인할 수 있도록 책임을 충분히 명확하게 나눌 수 있는지 판단해야 합니다.

의도적으로 두 시스템에 기록. 소프트웨어를 설계해 변경 사항을 두 곳에 기록합니다. 한 번의 쓰기는 성공하고 다른 쓰기는 실패했을 때 어떻게 처리할지 정해야 합니다. 누군가 차이를 감지하고, 어느 기록을 기준으로 삼을지 결정한 뒤 누락된 작업을 완료하거나 수정해야 합니다.

Ed Murray가 2020년에 작성한 AWS 마이그레이션 롤백 실무 설명은 이중 쓰기와 단계적 되돌리기에 필요한 조율을 보여 줍니다. 이는 작성 시점이 명시된 기술 사례이며, 그대로 적용할 수 있는 구현 계획은 아닙니다. 수동으로 중복 입력하거나 동기화를 약속하는 것만으로는 이러한 책임이 정해지지 않습니다.

리허설을 마친 단일 전환과 비교하기

단계적 전환은 한 번에 바뀌는 업무 범위를 줄일 수 있습니다. 그러나 두 운영 환경을 유지하면 지원, 교육, 대사, 임시 연동 업무가 늘어납니다. 교체 결정을 내릴 때 이러한 비용과 임시 연결을 제거하는 비용을 함께 고려해야 합니다.

Ian Cartwright, Rob Horn, James Lewis는 2022년 글 Transitional Architecture에서 임시 연결 구조와 최종 제거 과정을 설명합니다. 이들의 경험은 임시 연결이 유용한 목적을 수행할 수 있지만 별도의 예산과 종료 계획도 필요하다는 점을 보여 줍니다.

시스템이 작거나, 책임을 나누기 어렵거나, 적절한 연동 지점이 없거나, 긴급한 폐기 기한으로 장기간 병행 운영이 불가능하다면 리허설을 마친 단일 전환도 비교할 만합니다. Microsoft도 점진적 교체가 적합하지 않은 조건을 비슷하게 제시합니다. 이런 조건이 단일 전환을 자동으로 안전하게 만들지는 않습니다. 준비, 운영 점검, 의사결정 권한을 특히 명확히 해야 합니다.

제안된 전환을 리허설한 근거와 계속 진행하거나 중단할 때 적용할 합의된 조건을 요청하세요. 계속 수행해야 하는 실제 업무를 기준으로 두 방안을 비교하세요. 어느 방식에도 보편적으로 적용되는 기간이나 승인 기준은 없습니다.

새 거래가 되돌리기 판단을 바꿉니다

직원이 새 시스템에 유효한 업무 기록을 입력한 뒤 기존 애플리케이션을 다시 열면, 새 기록이 새 시스템에 남을 수 있습니다. 주문이 이미 배송, 결제 또는 메시지 발송으로 이어졌다면 데이터베이스를 복원해도 후속 작업을 취소할 수 없습니다.

AWS 전환 가이드는 새 데이터가 생기기 전의 되돌리기와 새 거래로 인해 기존 데이터베이스가 오래된 상태일 수 있는 이후의 되돌리기를 구분합니다. 기존 시스템으로 되돌리는 방안을 승인하기 전에 새 기록과 그에 따른 후속 작업을 어떻게 처리할지 구체적인 방안을 요구해야 합니다. 백업만으로는 업무를 일관된 상태로 재개할 수 있다는 근거가 되지 않습니다.

요청할 의사결정 기록

업무 운영 담당자가 다음 질문에 답할 수 있도록 간결한 기록을 남겨야 합니다.

• 목적과 범위: 어떤 업무를 비교하거나 이전하는가? 두 시스템을 유지하는 목적은 무엇인가?
• 기준이 되는 기록: 각 단계에서 변경 사항을 어디에 입력하는가? 관련 보고서와 작업은 어떤 기록을 기준으로 하는가?
• 대사: 누가 차이를 조사하고 어떻게 기록하는가? 이견이 있는 결과는 누가 해결하는가?
• 승인: 다음 단계로 넘어가려면 어떤 근거가 필요한가? 어떤 경우에 멈추는가? 진행 또는 중단은 누가 결정하는가?
• 되돌리기: 기존 시스템으로 업무를 돌릴 경우 새 거래와 완료된 후속 작업을 어떻게 처리하는가?
• 종료: 폐기를 승인할 근거는 무엇인가? 임시 연결은 누가 제거하는가? 적용되는 요건에 따라 계속 접근할 수 있어야 하는 기록은 무엇인가?

병행 운영의 목적과 운영 책임이 비용을 정당화하고 실행 가능한 종료 계획이 있을 때 승인하세요. 시스템 교체를 검토 중이라면 현재 시스템, 계속되어야 하는 업무, 변경에 따르는 제약을 당사의 레거시 시스템 교체 서비스에서 논의할 수 있습니다.