주문 이관 배치, 성능 테스트, 정합성 검증은 어떻게 준비했나

점진적 주문 이관 전략이 결정되면, 다음 질문은 ‘어떻게 실행할 것인가’다. 이 글은 마이그레이션 배치의 구현, 프로덕션 규모 데이터에 대한 성능 테스트, 그리고 변환된 데이터의 정합성을 어떻게 검증했는지를 기록한다. 전략이 아무리 좋아도 실행이 부실하면 마이그레이션은 실패한다.

특히 정합성 검증은 마이그레이션의 성패를 가르는 핵심 활동이다. 수백만 건의 데이터를 변환한 후, 원본과 결과가 ‘같은지’를 어떻게 확인할 것인가? 행 수만 맞으면 되는 것이 아니다. 각 필드의 값이 정확히 매핑되었는지, 특수 문자(한글 포함)가 깨지지 않았는지, 금액 합계가 일치하는지를 다층적으로 검증해야 한다.

마이그레이션 배치는 Breeze 관계형 DB에서 데이터를 추출(Extract)하고, 글로벌 플랫폼의 스키마에 맞게 변환(Transform)하여, 글로벌 시스템에 적재(Load)하는 ETL 프로세스다. 이 프로세스의 신뢰성은 전체 마이그레이션의 신뢰성과 직결된다. 변환 로직에 버그가 있으면 수백만 건의 데이터가 잘못 변환되고, 성능이 부족하면 컷오버 일정에 맞추지 못한다.

프로덕션 규모의 데이터에 대한 성능 테스트도 필수적이었다. 개발 환경에서 100건의 테스트 데이터로 잘 동작하는 배치가, 프로덕션의 수백만 건에서는 메모리 부족, 네트워크 타임아웃, DB 커넥션 풀 고갈 등의 문제를 일으킬 수 있다. 실제 규모에 가까운 데이터로 테스트해야 이런 문제를 사전에 발견할 수 있다.

준비 절차

ETL 배치 구현

추출(Extract) 단계: Breeze 관계형 DB에서 대상 주문을 조회한다. 조회 범위는 주문 상태와 날짜에 따라 결정된다. 대량 조회 구간에서는 DB 부하를 낮추기 위해 조회 단위를 분할하고, 배치 크기를 조정해 읽기 부하를 제어했다.

변환(Transform) 단계: 추출된 Breeze 주문 데이터를 글로벌 스키마로 매핑한다. 이 단계가 가장 복잡하다. 주문 헤더, 주문 라인, 결제 정보, 배송 정보를 각각 매핑하고, 관계(FK)를 재구성해야 한다. 한국 특유 필드(현금영수증, 세금계산서 등)는 글로벌 스키마의 확장 필드(custom attributes)에 저장하거나, 별도의 보조 저장소에 보관했다.

적재(Load) 단계: 변환된 데이터를 글로벌 플랫폼의 주문 시스템에 넣는다. 이 단계에서는 글로벌 시스템의 API를 통해 데이터를 삽입하거나, 직접 데이터베이스에 적재하는 방식이 사용된다. API 방식은 비즈니스 로직 검증이 포함되므로 안전하지만 느리고, 직접 DB 적재는 빠르지만 데이터 무결성 검증을 별도로 수행해야 한다.

성능 테스트

성능 테스트의 목표는 컷오버 일정 내에 모든 대상 주문을 처리할 수 있는지를 확인하는 것이다. 예를 들어 컷오버 전 2주 동안 완전 종료 주문을 배치로 처리해야 한다면, 하루에 처리해야 할 양이 정해진다. 이 처리량(throughput)을 프로덕션 규모 데이터로 달성할 수 있는지를 테스트한다.

성능 병목은 주로 다음 지점에서 발생한다: 관계형 DB의 대량 조회 쿼리 성능, 변환 로직의 CPU/메모리 사용량, 글로벌 시스템 API의 처리 속도와 속도 제한(rate limiting), 네트워크 대역폭(특히 한국 → 미국 데이터 전송 시). 각 병목에 대한 최적화 — 쿼리 튜닝, 배치 크기 조정, 병렬 처리 수 조정 — 를 반복적으로 수행했다.

정합성 검증: 다층 접근

정합성 검증은 세 수준에서 수행되었다. 첫째, 행 수준(row count): 원본에서 추출한 주문 수와 대상 시스템에 적재된 주문 수가 일치하는지 확인한다. 가장 기본적이지만 필수적인 검증이다. 누락이나 중복을 즉시 감지할 수 있다.

둘째, 필드 수준(field mapping): 샘플 주문을 추출하여 원본과 변환 결과의 각 필드를 비교한다. 주문 금액, 상품명(한글 깨짐 여부), 날짜(시간대 변환 정확성), 상태 코드(매핑 정확성) 등을 하나하나 확인한다. 전수 검사는 비현실적이므로, 통계적 샘플링 또는 엣지 케이스 중심 샘플링을 병행한다.

셋째, 비즈니스 규칙 수준: 주문 금액의 합계가 원본과 일치하는지, 특정 기간의 주문 건수가 일치하는지, 상태별 분포가 유사한지 등 집계(aggregation) 기반 검증이다. 이 수준의 검증은 개별 필드 오류를 잡지는 못하지만, 체계적인 매핑 오류(예: 특정 상태의 주문이 모두 누락)를 감지할 수 있다.

엣지 케이스 처리

정합성 검증 과정에서 발견된 엣지 케이스들이 있다. null 필드 처리 — Breeze에서 특정 필드가 null인 주문이 글로벌 스키마에서는 해당 필드가 필수(NOT NULL)인 경우. 특수 문자 — 상품명이나 배송 주소에 포함된 특수 문자(반각/전각, 이모지 등)가 변환 과정에서 깨지는 경우. Unicode — 한글 인코딩(EUC-KR vs UTF-8) 변환의 정확성.

이런 엣지 케이스들은 소수의 주문에서만 발생하지만, 해당 주문의 고객에게는 심각한 문제다. 자신의 주문 내역에서 상품명이 깨져 보이거나, 배송지 주소가 올바르지 않으면 고객 신뢰를 잃는다. 엣지 케이스를 사전에 식별하고 처리 로직을 구현하는 것이 정합성 검증의 핵심이다.

글로벌 전환은 단순한 데이터 이동이 아니라 경계와 책임을 다시 정의하는 작업이었다는 점이 이 시리즈의 중심에 있다. 다음 글에서는 2021 - 글로벌 팀과 로컬 팀은 컷오버를 어떻게 나눠 준비했나를 통해 이 흐름을 계속 좁혀 본다.

기술 선택의 장단점과 운영 트레이드오프

이 글에서 핵심 기술 선택은 대량 처리 성능과 정합성 보장의 균형이었다. 배치 크기를 크게 잡으면 처리량은 올라가지만 실패 시 재처리 범위가 커지고, 너무 작게 잡으면 안정성은 좋아져도 컷오버 일정 내 처리량을 맞추기 어렵다. 그래서 실행 단위를 세분화하고, 각 단위마다 검증 가능한 경계를 유지하는 접근이 필요했다.

또한 정합성 검증은 구현 비용이 높지만 운영 비용을 크게 줄인다. 배포 전에 오류를 잡기 위한 검증 비용을 선투자하면, 컷오버 이후 고객 영향과 수동 보정 비용을 낮출 수 있다. 전환기 프로젝트에서는 성능 최적화 그 자체보다, “실패했을 때 어디까지 안전하게 되돌릴 수 있는가”가 더 중요한 품질 기준이었다.

참고 자료

• Spring Batch Reference 
• AWS Prescriptive Guidance - Data Migration 
• Google SRE Book - Monitoring Distributed Systems 

배치 준비 체크포인트

• 배치 크기별 처리시간과 실패율을 사전 테스트로 측정했다.
• 재처리 경계를 명확히 하기 위해 배치 실행 단위를 고정했다.
• 정합성 검증은 건수 비교 + 금액 합계 + 샘플 레코드 대조로 다층 확인했다.

성능-안정성 트레이드오프