왜 주문 데이터는 한 번에 전부 옮길 수 없었나

대규모 데이터 마이그레이션에서 가장 위험한 접근은 ‘빅뱅(Big-Bang)’ 마이그레이션이다 — 모든 데이터를 한 번에, 한 순간에 옮기는 것. 이 글은 Nike의 주문 데이터가 왜 한 번에 전부 옮길 수 없었는지, 빅뱅 접근이 왜 불가능했고 어떤 대안을 선택했는지를 기록한다.

빅뱅(Big-Bang) 마이그레이션은 한 시점에 전체 데이터를 일괄 전환하는 방식이다.

주의: 대규모 주문 데이터에서 빅뱅 전환은 검증 누락 시 복구 범위를 통제하기 어렵다.

수천만 규모 사용자의 수천만 건 주문, 서로 다른 데이터 스키마, 멈출 수 없는 라이브 운영 — 이 조건들이 결합되면 ‘한 번에 전부’라는 선택지는 사실상 사라진다. 실패 시 롤백이 불가능하고, 데이터 정합성 검증에 시간이 부족하며, 전환 기간 동안 발생하는 새 주문의 처리가 불가능해지기 때문이다.

Breeze(관계형 DB 기반)와 글로벌 플랫폼의 주문 데이터 스키마는 근본적으로 달랐다. 테이블 구조, 컬럼명, 데이터 타입, 관계(relationship)가 모두 다르다. 주문 하나를 변환하려면 여러 테이블에서 데이터를 조합하고, 새 스키마에 맞게 재구성해야 한다. 이 변환 로직의 복잡도가 ‘한 번에 전부’를 어렵게 만드는 첫 번째 요인이다.

두 번째 요인은 라이브 운영이다. 마이그레이션 기간 동안에도 Nike.com은 정상 운영되어야 한다. 고객은 계속 주문하고, 반품하고, 배송을 추적한다. 빅뱅 마이그레이션은 일정 시간 동안 시스템을 중단(downtime)해야 하는데, 전자상거래에서 수 시간의 중단은 매출 손실과 고객 신뢰 저하를 의미한다.

세 번째 요인은 롤백의 불가능성이다. 수백만 건의 데이터를 새 시스템에 넣은 후 문제가 발견되면, 이미 새 시스템에서 발생한 트랜잭션(컷오버 이후 새 주문)과 마이그레이션된 데이터가 뒤섞여서 깨끗한 롤백이 불가능해진다.

스키마 차이의 규모

Breeze의 주문 데이터는 관계형 데이터베이스에 정규화된 형태로 저장되어 있었다. 주문 헤더, 주문 라인, 결제 정보, 배송 정보, 반품 정보 등이 각각 별도의 테이블에 저장되고 외래 키로 연결된다. 글로벌 플랫폼의 주문 구조는 이와 다른 설계를 따르고 있어서, 단순한 컬럼 매핑으로는 해결되지 않았다.

예를 들어 Breeze에서는 주문과 결제가 1:N 관계(하나의 주문에 여러 결제 수단)로 되어 있지만, 글로벌 플랫폼에서는 이 관계의 구조가 다를 수 있다. 또한 한국 특유의 데이터 — 현금영수증 번호, 세금계산서 정보, PG사 거래 ID — 는 글로벌 스키마에 대응하는 필드가 없어서 별도로 처리해야 했다.

빅뱅 마이그레이션의 위험

빅뱅 접근의 가장 큰 위험은 ‘전부 아니면 전무(all-or-nothing)‘라는 점이다. 수백만 건 중 99%가 성공하고 1%가 실패해도, 그 1%가 어떤 주문인지 파악하고 수작업으로 보정하는 것은 비현실적이다. 특히 매핑 실패(mapping failure)가 특정 패턴의 주문에서 집중적으로 발생할 수 있다 — 예를 들어 특정 시기에 사용된 결제 수단이나, 특정 프로모션 코드가 적용된 주문에서.

데이터 변환 중 손상(corruption)의 위험도 있다. 문자 인코딩(한글 처리), 날짜/시간대 변환(KST vs UTC), 금액 단위(원화의 소수점 없음 vs 글로벌의 소수점 포함) 등에서 미묘한 변환 오류가 발생할 수 있다. 이런 오류는 대량 데이터에서는 샘플 검증으로 발견하기 어렵다.

점진적 접근의 필요성

결론적으로 점진적(incremental) 마이그레이션이 유일한 현실적 대안이었다. 먼저 완료된(closed) 주문을 배치로 변환하고, 정합성을 검증한 후, 활성(active) 주문을 컷오버 직전에 처리하는 단계적 접근이다. 각 단계의 결과를 검증하고, 문제가 발견되면 해당 단계만 재실행할 수 있다.

점진적 접근은 시간이 더 걸리지만, 리스크를 관리할 수 있다. 첫 번째 배치에서 변환 로직의 문제를 발견하면 로직을 수정하고 다음 배치에 적용할 수 있다. 빅뱅에서는 이런 학습 루프가 불가능하다. 또한 점진적 접근은 컷오버 시점의 부하를 줄여준다 — 이미 대부분의 이력 주문이 처리된 상태에서, 컷오버 시점에는 활성 주문만 처리하면 된다.

핵심 기술 스택과 운영 선택

데이터 정합성 검증의 중요성

어떤 접근을 선택하든, 변환된 데이터의 정합성을 검증하는 과정이 필수적이다. 원본 데이터와 변환된 데이터를 비교하여 누락, 중복, 변형이 없는지 확인해야 한다. 이 검증은 행 수준(row count), 필드 수준(field mapping), 비즈니스 규칙 수준(주문 금액 합계, 결제 금액 합계 일치)에서 수행되어야 한다.

점진적 접근에서는 각 배치마다 검증을 수행할 수 있으므로, 문제의 범위를 해당 배치로 한정할 수 있다. 빅뱅에서는 전체 데이터에 대한 검증을 컷오버 전에 완료해야 하는데, 수백만 건의 전체 비교는 시간적으로 거의 불가능하다.

글로벌 전환은 단순한 데이터 이동이 아니라 경계와 책임을 다시 정의하는 작업이었다는 점이 이 시리즈의 중심에 있다. 다음 글에서는 2021 - 반품 기간과 운영 상태를 고려한 점진적 주문 이관 전략를 통해 이 흐름을 계속 좁혀 본다.

빅뱅 vs 점진 이관의 기술적 비교

빅뱅 이관은 구조가 단순해 보이지만, 실패 시 복구 범위가 매우 크다. 반대로 점진 이관은 구현과 운영 복잡도가 늘어나지만, 장애 범위를 작게 유지하고 단계별 검증을 적용하기 쉽다. 대규모 주문 데이터를 다루는 상황에서는 후자의 장점이 더 컸다.

또한 점진 이관은 성능 튜닝과 정합성 검증을 반복적으로 학습할 수 있다는 이점이 있다. 한 번에 끝내는 방식은 학습 기회를 주지 않지만, 단계형 접근은 다음 구간의 품질을 매번 개선할 수 있다. 전환기 운영에서는 이 반복 학습이 일정 안정성으로 직결됐다.

기술 체크포인트

• 이관 단위는 사용자군/기간/상태 기준으로 분할해 실패 범위를 제한했다.
• 배치 실행 전후에 건수/금액/상태코드를 비교해 정합성 검증을 수행했다.
• 재실행 가능한 idempotent 설계를 유지해 부분 실패 시 재처리 비용을 줄였다.

idempotent는 같은 작업을 여러 번 실행해도 결과가 달라지지 않게 만드는 특성이다.

접근 방식 비교