주문 이관 배치의 성능과 데이터 검증

주문 이관 대상을 정한 다음에는 실제로 데이터를 옮길 배치와 검증 과정이 필요했습니다. 기존 Breeze의 주문을 새 플랫폼에서 사용할 수 있는 구조로 바꿔야 했고, 정해진 일정 안에 처리를 끝낼 수 있는지도 확인해야 했습니다.

배치가 끝났다는 실행 결과와 주문 데이터가 맞게 옮겨졌다는 판단은 구분했습니다. 오류 없이 적재됐어도 상품이나 결제 정보의 연결이 잘못될 수 있기 때문입니다.

추출·변환·적재 단계 구분

배치는 기존 DB에서 대상 주문을 읽고, 새 구조에 맞게 변환하고, 대상 시스템에 반영하는 과정으로 나눠 볼 수 있습니다. 단계마다 확인할 문제가 달랐습니다.

추출에서는 어떤 상태와 기간의 주문을 가져오는지가 중요했습니다. 변환에서는 주문에 속한 상품과 결제·배송 정보의 관계를 유지해야 했습니다. 적재 이후에는 원래 주문과 같은 의미로 조회되고 처리되는지 확인해야 했습니다.

성능을 볼 때도 전체 시간만 확인하면 원인을 좁히기 어려웠습니다. 읽는 데 오래 걸리는지, 변환 중 자원을 많이 쓰는지, 대상 시스템의 응답을 기다리는지 구분해야 조정할 지점을 찾을 수 있습니다.

처리량과 재실행 범위

성능 테스트는 이관 일정 안에 대상 주문을 처리할 수 있는지 확인하기 위한 작업이었습니다. 적은 데이터로 정상 동작하는 것과 많은 주문을 처리하는 데 필요한 시간은 따로 확인해야 했습니다.

한 번에 처리하는 범위를 늘리면 호출 횟수를 줄일 수 있지만, 메모리나 대상 시스템에 부담이 커질 수 있습니다. 실패했을 때 다시 확인할 범위도 넓어집니다. 배치 크기와 병렬 처리 수는 실행 시간뿐 아니라 실패 이후의 처리까지 함께 고려할 항목이었습니다.

건수와 금액 비교

기본 검증은 원본에서 이관 대상으로 잡은 주문과 실제 적재된 주문의 건수를 비교하는 것이었습니다. 전체 DB의 건수를 그대로 비교하면 제외 조건이 섞일 수 있어 같은 대상을 기준으로 봐야 했습니다.

건수만 같아도 충분하지는 않았습니다. 누락과 중복이 동시에 생기면 총건수가 같을 수 있습니다. 주문 식별자의 누락·중복 여부와 금액 합계, 상태별 분포를 함께 확인해야 하는 이유입니다.

주문 단위의 데이터 확인

집계 결과와 함께 개별 주문도 확인했습니다. 상품명과 금액, 주문 시각, 상태 코드가 변환 후에도 의도한 값인지 보는 과정이었습니다.

이관 검증에서는 배치의 실행 결과와 함께 개별 주문의 상품·금액·시각·상태를 확인했습니다. 예외 데이터도 적재만 성공시키기 위해 기본값으로 덮기보다, 변환 뒤 같은 주문으로 해석할 수 있는지를 봤습니다.

이 단계의 준비가 당일 최종 이관까지 끝났다는 뜻은 아닙니다. 준비한 배치와 검증 기준을 바탕으로, 전환 일정에 맞춰 남은 주문을 옮기고 결과를 확인하는 작업이 이어졌습니다.

다음 글에서는 이런 준비를 글로벌 팀과 로컬 팀이 나눠 진행한 과정을 정리합니다.