데이터 마이그레이션의 함정: 시스템 전환이 첫날 이전에 실패하는 이유

귀사는 6개월 전에 새로운 ERP 계약서에 서명하셨습니다. 데모는 인상적이었고, 벤더는 대응이 빨랐으며, 경영진은 한 방향으로 정렬되어 있었습니다. 그러나 가동(go-live) 이후 3주가 지난 지금, 회계팀은 여전히 모든 청구서를 이전 시스템과 대조 확인하고 있고, 창고 관리자는 재고 수량을 신뢰하지 못하며, 영업부의 누군가는 실제 고객 잔액을 추적하기 위해 조용히 별도의 섀도 스프레드시트(shadow spreadsheet)를 다시 만들어 두었습니다. 소프트웨어는 작동합니다. 그러나 데이터는 그렇지 않습니다. 그 간극 — 즉, 단순히 돌아가는 시스템과 구성원이 신뢰하는 시스템 사이의 간극 — 은 거의 항상 데이터 마이그레이션의 실패이며, 이는 모든 업무 시스템 전환에서 가장 과소평가되는 단일 위험입니다.

대부분의 리더십 팀은 데이터 마이그레이션을 구축 일정 어딘가에서 처리되는 기술적 체크박스 항목으로 취급합니다. 그러나 실제로는 새 시스템이 진실의 원천(source of truth)이 될 것인지, 아니면 가장 값비싼 문서 보관함이 될 것인지를 조용히 결정하는 단계입니다.

데이터 마이그레이션이 IT 과제가 아니라 비즈니스 과제인 이유

데이터 마이그레이션이 IT 팀이나 벤더의 업무라는 통념이 존재합니다. 이전 시스템에서 내보내기(export)하고 새 시스템으로 가져오기(import)하면 주말 안에 끝난다는 것입니다. 문제가 시작되는 지점이 바로 이 프레이밍(framing)입니다. 이전 시스템에는 단순히 데이터만 담겨 있는 것이 아니라, 15년치의 임시 방편, 문서화되지 않은 규칙, 그리고 빈 필드·커스텀 플래그·자유 텍스트 메모의 형태로 인코딩되어 오래 근속한 세 명의 직원만 해독할 수 있는 부족지(tribal knowledge)가 들어 있습니다.

단순한 내보내기·가져오기 방식으로 그 맥락이 벗겨져 나가면, 새 시스템은 행(row)을 물려받되 의미는 잃게 됩니다. 체크박스와 코멘트 필드의 조합을 통해 "VIP 순-60일 결제 조건, B 창고에서 출하, USD로 청구"를 나타내던 고객 레코드는 평범한 연락처 카드로 변합니다. 데이터는 기술적으로 남아 있습니다. 그러나 비즈니스 로직은 사라졌습니다. 그런 이유로 데이터 마이그레이션은 IT 기능에만 위임할 것이 아니라, 운영 및 재무 리더가 직접 소유해야 합니다.

업무 시스템 전환을 무너뜨리는 다섯 가지 함정

저희가 겪어 본 여러 프로젝트에서 동일한 실패 패턴이 놀랄 만큼 일관되게 반복됩니다. 이를 조기에 인식하는 것이 통제된 마이그레이션과 1년간 이어지는 가동 이후 뒷정리를 가르는 차이가 됩니다.

함정 1: 이전 데이터베이스를 진실의 원천으로 취급하는 것. 레거시 시스템에는 중복, 고아 레코드, 그리고 새 환경으로 절대 넘어가서는 안 되는 비활성 엔티티가 축적됩니다. 모든 것을 마이그레이션한다면, 10년치의 잡동사니를 앞으로 계속 짊어지는 비용을 치르는 셈입니다. 더 나쁜 것은, 가동 첫날부터 리포트를 오염시킨다는 점입니다. 올바른 자세는 유용한 것은 마이그레이션하고, 그렇지 않은 것은 아카이브하며, 판단은 비즈니스 측에 강제하는 것입니다.

함정 2: 데이터 정제(cleansing)를 과소평가하는 것. 정제는 재무팀이 주말에 처리할 수 있는 스프레드시트 작업이 아닙니다. 같은 공급사 이름의 세 가지 변형을 통합하고, 전화번호와 세금 코드를 정규화하며, 카탈로그 전반에 걸쳐 제품 SKU를 조정하는 일은 판단이 많이 필요한 느린 작업입니다. 팀은 실제로 몇 주가 걸릴 일에 며칠을 잡는 경우가 흔하고, 이 오산은 가동일을 밀거나 더러운 데이터 위에서 출범을 강행하도록 만듭니다.

함정 3: 이력 데이터의 깊이 문제를 무시하는 것. 실제로 새 시스템에 몇 년치의 트랜잭션 이력이 필요한지 자문해 보십시오. 많은 조직은 반사적으로 "전부"라고 답한 뒤, 마이그레이션 소요 시간이 세 배로 늘어나고 새 시스템이 그 무게에 눌려 느려지는 것을 발견합니다. 대부분의 기업은 1~3년치를 라이브(live)로 유지하고, 그 이전은 읽기 전용 아카이브에 보존하는 것으로 충분합니다. 이 결정 하나만으로도 마이그레이션 노력을 절반으로 줄일 수 있습니다.

함정 4: 예행 연습(dry run)을 건너뛰는 것. 실제 새 시스템을 대상으로, 실제 사용자가 실제 마감을 처리하려 하는 상태에서, 프로덕션 규모의 데이터로 단 한 번의 처음부터 끝까지의 리허설을 수행하는 것 — 이 항목은 협상 불가입니다. 일정을 이유로 이를 생략한 팀은, 대개 조정 오류, 매핑 누락, 성능 문제를 실제 컷오버(cutover) 중에 발견하며, 그때는 이미 수정할 시간이 없습니다.

함정 5: 조정(reconciliation) 계획이 없는 것. 마이그레이션 이후 누군가는 시산표가 일치함을, 재고 수량이 맞아 떨어짐을, 미결 주문(open orders)이 라인별로 조정됨을 증명할 수 있어야 합니다. 컷오버 전에 재무 및 운영이 서명한 문서화된 조정 프레임워크가 없다면, 새 시스템의 첫 분기를 어느 숫자를 믿을 것인지 논쟁하는 데 소비하게 됩니다.

짧은 사례: 두 번 마이그레이션한 소매업체

저희와 협력한 지역 소매 체인은 저희를 찾아오기 전에 이미 한 차례 시스템 마이그레이션을 시도한 상태였습니다. 잘 알려진 벤더가 진행한 첫 번째 시도는 마이그레이션을 일회성 컷오버로 취급했습니다. 즉, 금요일 밤에 레거시 POS 및 회계 시스템에서 내보내고, 새 플랫폼으로 가져온 뒤, 월요일에 매장을 여는 방식이었습니다. 화요일이 되자 매장 관리자들은 재고 수량을 신뢰할 수 없었습니다. 첫 달이 끝날 무렵, 재무는 기초 잔액이 레거시 기말 잔액과 맞지 않아 회계 기간을 마감할 수 없었습니다. 프로젝트는 롤백되었습니다.

두 번째 시도에서는 순서가 바뀌었습니다. 컷오버 3개월 전, 재무·운영·IT 합동 팀이 데이터 딕셔너리(data dictionary)를 구축하여 레거시 시스템의 모든 필드와 그 도착지 — 또는 명시적으로 제외되는 사유 — 를 문서화했습니다. 프로덕션 규모의 데이터로 두 번의 전체 예행 연습이 수행되었고, 각 회차의 조정 보고서는 CFO가 직접 검토했습니다. 2년보다 오래된 이력 트랜잭션은 라이브 시스템이 아니라 읽기 전용 아카이브로 옮겨졌습니다. 최종 컷오버는 별 사건 없이 지나갔는데, 이는 성공적인 마이그레이션이 마땅히 느껴져야 할 모습 그대로입니다.

리더를 위한 실무 로드맵

귀사의 조직이 향후 12개월 안에 시스템 전환을 앞두고 있다면, 다음의 순서는 성공 확률을 크게 높입니다.

첫째, IT가 아닌 비즈니스 측에서 데이터 오너(data owner)를 임명하십시오. 대개 범위와 품질에 대한 최종 결정 권한을 지닌 재무 또는 운영 리더가 적합합니다. 둘째, 구축 계약을 체결하기 전에 레거시 시스템에 대한 데이터 감사(audit)를 발주하여 실제 정제 노력의 규모를 파악하십시오. 셋째, 마이그레이션 범위를 명시적으로 정의하십시오. 어떤 엔티티를, 어느 이력 깊이까지, 어떤 필드를 포함할 것이며 무엇을 의도적으로 제외할 것인지를 정하십시오. 넷째, 정제에 현실적인 시간을 배정하십시오. 대개 전체 마이그레이션 노력의 30~50%에 해당합니다. 다섯째, 프로덕션 규모의 데이터에 대한 전체 예행 연습을 최소 한 차례 이상 의무화하십시오. 여섯째, 컷오버 이후가 아니라 그 이전에 조정 프레임워크와 사인오프(sign-off) 기준에 합의하십시오.

이 단계들 중 어느 것도 기술적으로 이국적인(exotic) 항목은 없습니다. 이들은 거버넌스 결정입니다. 그리고 리더십 수준에서 누군가가 이를 관철하지 않는 한, 실제로 이행되는 경우는 거의 없습니다.

솔직한 결론

새로운 업무 시스템은 나쁜 데이터로부터 귀사를 구해 주지 않습니다. 오히려 그것을 드러내고, 증폭시키며, 경영진이 읽는 모든 리포트와 대시보드로 흘려보낼 것입니다. 현대의 구축 프로젝트에서 기술이 병목인 경우는 드뭅니다. 병목은 데이터에 대한 규율입니다. 마이그레이션을 오너, 범위, 리허설, 조정 계획을 갖춘 비즈니스 프로그램으로 취급하는 리더는 대개 깔끔하게 가동에 진입합니다. 이를 주말 컷오버로 취급하는 이들은 대개 이후 1년을 자기 회사 숫자에 대한 신뢰를 재건하는 데 소비합니다.

시스템 전환을 계획 중이며 이러한 함정을 가까이서 지켜보고 그 주변을 어떻게 설계해야 하는지 아는 파트너를 찾고 계신다면, MerkTechs 팀이 귀사의 구체적인 상황을 함께 논의해 드릴 수 있습니다. 목표는 더 큰 프로젝트가 아니라, 더 조용한 가동입니다.