컷오버 당일 최종 남은 데이터를 어떻게 이관했나

대규모 플랫폼 마이그레이션에서 가장 까다로운 기술적 도전 중 하나는 컷오버 당일의 델타(delta) 데이터 이관이다. 사전에 배치로 대부분의 데이터를 옮겨놓았더라도, 마지막 배치 실행 이후부터 컷오버 순간까지 Breeze에서 발생한 데이터(신규 주문, 회원가입, 결제 등)는 별도로 이관해야 한다. 이 시간 창(time window)은 짧지만, 이 기간의 데이터가 누락되면 고객에게 직접적인 영향을 미친다.

이 글은 컷오버 당일 실제로 어떤 순서로 델타 데이터를 이관했는지, Breeze의 쓰기를 언제 멈추고 글로벌 플랫폼으로 전환했는지, 그리고 그 사이에 발생할 수 있는 데이터 불일치를 어떻게 방지했는지를 기록한다.

이 경험은 라이브 서비스의 무중단 마이그레이션이 왜 어려운지, 그리고 유지보수 윈도우(maintenance window)가 왜 필요한지를 구체적으로 보여주는 사례이기도 하다.

Breeze에서 글로벌 플랫폼으로의 데이터 마이그레이션은 크게 두 단계로 나뉘었다. 첫 번째는 사전 배치 마이그레이션으로, 컷오버 전 며칠에서 몇 주에 걸쳐 대량의 역사적 데이터(주문 이력, 사용자 프로필, 상품 데이터 등)를 글로벌 플랫폼으로 옮기는 작업이다. 두 번째가 컷오버 당일의 델타 마이그레이션으로, 마지막 배치와 컷오버 사이에 발생한 증분 데이터를 이관하는 작업이다.

델타 마이그레이션이 어려운 이유는 시간 압박이다. 사전 배치는 며칠에 걸쳐 실행할 수 있지만, 델타 마이그레이션은 유지보수 윈도우(서비스 중단 시간) 안에 완료해야 한다. 유지보수 윈도우가 길면 고객 불편이 커지고, 짧으면 데이터 이관이 미완료될 위험이 있다.

또한 델타 이관 중에는 Breeze에서 새로운 트랜잭션이 발생하면 안 된다. 이관 중에 새 주문이 들어오면 그 주문은 Breeze에만 존재하고 글로벌 플랫폼에는 누락된다. 그래서 Breeze의 쓰기(write)를 먼저 중단하고, 읽기(read) 전용 상태에서 델타 데이터를 추출하여 이관해야 했다.

당일 실행 타임라인

유지보수 윈도우와 서비스 중단 안내

컷오버를 위해 유지보수 윈도우를 설정했다. 이 시간 동안 nike.com/ko는 유지보수 페이지를 표시하고, 사용자의 주문이나 회원가입 등의 트랜잭션을 받지 않았다. 유지보수 윈도우의 길이는 몇 시간 수준이었을 것이다. 정확한 시간은 확인이 필요하지만, 새벽 시간대를 활용하여 고객 영향을 최소화했다.

유지보수 공지는 사전에 웹사이트와 앱에 배너로 안내되었고, CS팀에도 고객 문의 대응 가이드가 공유되었다. ‘왜 서비스가 안 되나요’라는 문의에 대한 표준 답변과 서비스 재개 예정 시각을 준비해두었다.

Stop Writes on Breeze

유지보수 윈도우가 시작되면 가장 먼저 Breeze의 쓰기를 중단했다. 이는 모든 트랜잭션 API(주문 생성, 회원가입, 결제 처리 등)를 비활성화하는 것을 의미한다. 읽기 API는 유지할 수도, 함께 중단할 수도 있었는데, 델타 마이그레이션 중에는 전체 서비스를 유지보수 모드로 전환하는 것이 안전했다.

쓰기 중단 시점을 명확히 기록하는 것이 중요했다. 이 시점 이후의 타임스탬프를 가진 데이터가 Breeze에 존재하면 안 되므로, 쓰기 중단이 실제로 완료되었는지 확인하고 그 타임스탬프를 기록했다. 이 타임스탬프가 델타 마이그레이션의 기준점이 된다.

델타 데이터 추출과 이관

쓰기가 중단된 후, 마지막 배치 마이그레이션 이후부터 쓰기 중단 시점까지의 데이터를 추출했다. 이 델타 데이터에는 해당 기간 동안의 신규 주문, 주문 상태 변경, 새로운 회원가입, 프로필 업데이트 등이 포함된다.

델타 데이터의 규모는 마지막 배치를 언제 실행했느냐에 따라 달라진다. 마지막 배치를 컷오버 직전에 실행했다면 델타가 작고, 며칠 전에 실행했다면 델타가 크다. 델타 규모를 최소화하기 위해 컷오버 직전에 한 번 더 배치를 실행하는 전략을 사용했을 것이다.

실제 운영 순서

데이터 건수 검증 (Reconciliation)

델타 이관이 완료되면 데이터 건수를 검증했다. Breeze의 총 레코드 수와 글로벌 플랫폼의 총 레코드 수를 비교하여 누락이 없는지 확인했다. 이 과정을 reconciliation이라 부른다. 주문 수, 사용자 수, 상품 수 등 주요 엔티티별로 건수를 대조했다.

100% 일치가 이상적이지만, 현실에서는 소수의 차이가 발생할 수 있다. 차이가 있을 때 중요한 것은 그 원인을 파악하는 것이다. 변환 규칙에 의해 의도적으로 제외된 데이터인지, 마이그레이션 오류로 누락된 데이터인지를 구분해야 했다. 의도적 제외라면 그 근거를 기록하고, 오류 누락이라면 수동으로 보정해야 했다.

DNS 전환과 트래픽 확인

데이터 검증이 완료되면 DNS를 글로벌 플랫폼으로 전환했다. DNS 변경 후 전파까지 시간이 걸리므로, 전파 상태를 모니터링하면서 글로벌 플랫폼으로 트래픽이 유입되기 시작하는 것을 확인했다. 첫 번째 실제 사용자 요청이 글로벌 플랫폼에 도달하는 순간이 사실상의 전환 완료 시점이었다.

트래픽이 유입되기 시작하면 집중 모니터링 모드에 들어갔다. 에러율, 응답시간, 주요 기능(로그인, 상품 조회, 장바구니, 결제)의 정상 동작 여부를 실시간으로 확인했다. 이 시점에서 심각한 문제가 발견되면 롤백을 결정해야 했고, 경미한 문제라면 핫픽스로 대응했다.

글로벌 팀과의 시차 조율

Nike의 글로벌 플랫폼팀은 미국에 있었고, 한국과 약 16시간(서부 기준)의 시차가 있었다. 컷오버는 양쪽 팀이 모두 가용한 시간대를 기준으로 운영했고, 한국의 저트래픽 시간과 미국의 업무 시간이 겹치는 구간을 활용해 실시간 의사결정을 맞췄다.

실행 당일 작업은 사전 계획된 야간 일정으로 진행됐고, 글로벌/로컬 팀이 교대로 모니터링과 검증을 맡으며 워룸을 유지했다. 교대 운영에 맞춰 출근 시간도 조정했고, 일부 인원은 다음날 늦은 오전까지 최종 안정화 확인을 이어갈 정도로 긴 호흡의 작업이었다.

시차가 있는 글로벌 협업에서 가장 중요한 것은 커뮤니케이션의 명확성이다. 실시간 음성/화상 회의를 유지하면서 작업을 진행하되, 모든 중요 결정과 상태 변경은 Slack에 텍스트로도 기록하여 추적 가능하게 했다. 누군가 잠시 자리를 비워도 채널을 읽으면 현재 상황을 파악할 수 있어야 했다.

컷오버는 단일 이벤트가 아니라 사전 확인, 당일 실행, 직후 안정화가 이어지는 운영 시퀀스라는 점이 핵심이다. 다음 글에서는 2022-10 - 컷오버 직후 무엇부터 안정화해야 했나를 통해 이 흐름을 계속 좁혀 본다.

컷오버 당일 아키텍처 운영 포인트

당일 이관에서 핵심은 기술 구현보다 실행 순서였다. 데이터 검증, DNS 전환, 트래픽 관찰, 롤백 판단이 순차적으로 이어져야 했고, 각 단계는 다음 단계의 전제 조건을 명확히 만족해야 했다. 이 구조가 없으면 기술적으로 맞는 작업도 운영적으로는 실패할 수 있다.

또한 컷오버는 “성공/실패”의 이분법보다 “어디까지 안전하게 전진했는가”를 계속 평가하는 과정이었다. 그래서 모니터링 지표와 커뮤니케이션 채널을 같은 흐름으로 묶어 두는 것이 중요했고, 이 체계가 직후 안정화 단계로 자연스럽게 연결됐다.

컷오버 실행 체크리스트

• 신규 주문 유입 차단과 최종 배치 종료 상태를 먼저 확인한다.
• 최종 이관 데이터의 건수/합계/샘플 조회를 기준값과 비교한다.
• DNS 전환 전후 핵심 경로(로그인/주문조회/CS조회)를 시나리오로 검증한다.
• 이상 징후 발생 시 되돌릴 단계와 승인 체계를 즉시 실행한다.

당일 운영 트레이드오프