시스템을 다시 만들지 고쳐 쓸지

운영 중인 시스템을 개선할 때 전면 재구축은 가장 명확한 선택처럼 보입니다. 하지만 기존 코드 안에는 데이터 관계와 외부 연동 방식이 쌓여 있습니다. 예외를 처리해 온 운영자의 지식도 함께 남아 있습니다. 재구축의 핵심은 새 기술을 고르는 일이 아닙니다. 기존 시스템이 품고 있던 지식을 빠뜨리지 않고 옮기는 일입니다.

현재 시스템이 알고 있는 것을 적습니다

화면과 업무 규칙을 따로 봅니다. 데이터 구조부터 외부 연동과 배포 방식까지 나눠 확인합니다. 운영자가 장애를 알아채고 처리하는 방법도 자산에 포함합니다.

문서가 없다면 실제 흐름을 따라가며 기록합니다. 누가 어떤 기능을 쓰는지 확인합니다. 실패했을 때 무엇이 멈추는지도 살펴봅니다. 운영 지식이 누구에게 있는지 함께 적습니다.

바꿔야 하는 이유를 분리합니다

오래된 기술이라는 이유만으로 교체하지 않습니다. 보안 업데이트가 끝났는지 확인합니다. 작은 변경이 전체 배포를 요구하는지와 테스트 경계를 만들 수 있는지도 봅니다.

반대로 새 기술을 썼더라도 변경이 어려울 수 있습니다. 특정 공급자에 지나치게 묶였거나 운영 지식이 한 사람에게만 있다면 위험은 여전히 큽니다.

구성요소마다 다른 선택을 합니다

안정적으로 쓰이며 변경이 드문 부분은 유지합니다. 필요한 기능이지만 직접 바꾸기 어렵다면 명확한 인터페이스로 감쌉니다. 장애와 변경 비용이 큰 부분은 교체합니다. 현재 쓰임이 사라진 기능은 폐기합니다.

이 선택은 시스템 전체에 한 번에 적용하지 않습니다. 화면과 데이터 및 연동마다 다른 결정을 내릴 수 있습니다.

데이터의 기준과 이동 상태를 정합니다

데이터를 옮길 때는 원본과 대상 중 어느 쪽을 기준으로 볼지 먼저 정합니다. 두 시스템이 함께 쓰이는 동안 변경을 어떻게 맞출지도 필요합니다. 실패한 항목을 다시 찾을 수 있는 기록도 남깁니다.

건수만 같다고 이전이 끝난 것은 아닙니다. 핵심 관계와 금액을 대조하고 상태별 합계를 비교합니다. 표본 원문과 실패 목록도 함께 확인합니다.

두 시스템이 함께 있는 기간을 설계합니다

전환 과정에서는 기존 시스템과 새 시스템이 일정 기간 함께 작동할 수 있습니다. 어떤 사용자가 어느 시스템을 쓰는지 분명해야 합니다. 같은 데이터가 두 곳에서 바뀔 수 있다면 충돌을 다루는 규칙도 필요합니다.

기존 시스템에서 묵시적으로 처리하던 예외마다 새 흐름의 담당자와 처리 방법을 정합니다. 로그와 알림뿐 아니라 운영 도구도 핵심 기능과 같은 시점에 준비합니다.

전환과 되돌림 조건을 미리 씁니다

사용자군이나 기능이나 데이터 종류를 기준으로 전환 단위를 나눕니다. 각 단위에는 시작 조건과 확인할 신호가 필요합니다. 중단할 상황과 이전 상태로 돌아가는 방법도 배포 전에 적습니다.

되돌림은 막연한 비상계획이 아닙니다. 어느 시점의 코드와 데이터를 기준으로 복구할지 정합니다. 전환 뒤 생긴 변경을 어떻게 처리할지도 함께 정합니다.

새 시스템을 맡을 수 있는 상태로 마칩니다

전환이 끝났다는 판단에는 운영자의 준비도 포함됩니다. 상태 확인 방법과 장애 대응 경로를 인계합니다. 변경 절차도 함께 전달합니다. 남은 제약과 아직 옮기지 않은 기능도 숨기지 않습니다.

무엇을 남겼고 왜 바꿨는지 설명할 수 있어야 다음 변경도 이어갈 수 있습니다.