2022년 10월 4일 컷오버 직전 무엇을 체크했나

2022년 10월 4일, Nike의 커머스 플랫폼이 Breeze에서 글로벌 플랫폼으로 전환되는 컷오버가 예정되어 있었다. 이 전환은 수개월간의 준비를 거친 것이었고, 컷오버 당일은 그 모든 준비의 결정적 순간이었다. 이 글은 컷오버 전날과 당일 아침, 실제로 무엇을 점검했는지를 기록한다. 계획서에 적힌 체크리스트가 아니라, 현장에서 실제로 확인한 항목들의 기록이다.

컷오버는 되돌리기 어렵다. DNS가 전환되고 사용자 트래픽이 글로벌 플랫폼으로 흐르기 시작하면, 문제가 발생해도 즉시 롤백하는 것이 간단하지 않다. 그렇기 때문에 컷오버 전 최종 점검은 단순한 형식이 아니라, Go/No-Go 결정을 내리기 위한 실질적 근거였다.

이 경험을 기록하는 이유는, 대규모 플랫폼 마이그레이션에서 컷오버 전야에 실제로 무엇을 확인해야 하는지를 구체적으로 남기기 위해서다. 미래에 비슷한 마이그레이션을 수행할 누군가에게 참고가 되기를 바란다.

Nike의 Breeze 플랫폼은 한국 시장을 위해 자체 구축된 커머스 시스템이었다. Nike의 글로벌 전략은 각국의 로컬 플랫폼을 하나의 글로벌 플랫폼으로 통합하는 것이었고, 한국도 이 통합 대상이었다. 글로벌 플랫폼으로의 전환은 단순한 서버 교체가 아니라, 사용자 데이터, 주문 이력, 결제 시스템, 검색, CS 도구 등 커머스의 모든 영역을 새로운 플랫폼으로 옮기는 작업이었다.

컷오버 날짜인 10월 4일은 한국 시간 기준이었고, 글로벌 팀과의 시차(미국 서부 기준 약 16시간)를 고려하여 양쪽 팀이 모두 가용한 시간대에 작업을 진행해야 했다. 이 시차 조율 자체가 추가적인 복잡성이었다.

컷오버의 핵심은 DNS 전환이었다. nike.com/ko 또는 관련 도메인의 DNS를 Breeze 인프라에서 글로벌 플랫폼 인프라로 변경하면, 사용자 트래픽이 새로운 플랫폼으로 흐르기 시작한다. DNS 전파(propagation)에는 시간이 걸리므로, 전환 후 일정 시간 동안 일부 사용자는 구 플랫폼에, 일부는 신 플랫폼에 접속하는 혼재 상태가 발생할 수 있었다.

컷오버 전야 실행 순서

Go/No-Go 게이트 요약

데이터 마이그레이션 완료 상태 확인

컷오버 전 가장 중요한 확인 항목은 데이터 마이그레이션의 완료 상태였다. 사용자 계정 데이터, 주문 이력, 상품 데이터, 재고 데이터 등이 글로벌 플랫폼에 정확하게 이관되었는지를 확인해야 했다. 배치(batch) 마이그레이션으로 대부분의 데이터는 이미 옮겨진 상태였지만, 마지막 배치 이후 새로 생성된 데이터(주문, 회원가입 등)는 아직 이관되지 않은 상태였다.

데이터 건수 대조(reconciliation)가 핵심이었다. Breeze 쪽의 총 레코드 수와 글로벌 플랫폼 쪽의 총 레코드 수를 비교하여 누락이 없는지 확인했다. 100% 일치는 어렵더라도, 차이가 있는 경우 그 원인을 파악할 수 있어야 했다. 예를 들어, 특정 기간의 주문이 누락되었다면 해당 배치의 재실행이 필요했다.

DNS 전환 준비와 SSL 인증서

DNS 전환은 컷오버의 물리적 전환점이었다. DNS 레코드가 글로벌 플랫폼의 엔드포인트를 가리키도록 변경되면, 사용자 트래픽이 새 플랫폼으로 흐르기 시작한다. DNS 변경 자체는 간단하지만, 변경 전에 확인해야 할 것들이 있었다.

SSL 인증서가 글로벌 플랫폼에 올바르게 설정되어 있는지 확인했다. 인증서가 만료되었거나 도메인이 불일치하면 사용자 브라우저에 보안 경고가 표시되고, 이는 즉시 비즈니스 영향으로 이어진다. CDN(Content Delivery Network) 캐시 설정도 확인했다. 구 플랫폼의 콘텐츠가 CDN에 캐시되어 있으면 DNS 전환 후에도 사용자에게 구 콘텐츠가 보일 수 있으므로, 캐시 무효화(invalidation) 계획을 수립했다.

모니터링 대시보드와 알림 설정

컷오버 후 문제를 빠르게 감지하기 위한 모니터링 대시보드를 사전에 구성했다. 주요 모니터링 항목은: HTTP 응답 코드 분포(특히 5xx 비율), 응답 시간(P50, P95, P99), 주문 처리 성공률, 로그인 성공률, 결제 성공률 등이었다. 이 대시보드들이 글로벌 플랫폼 쪽에서 정상적으로 데이터를 수집하고 있는지를 컷오버 전에 확인해야 했다.

알림(alert) 설정도 중요했다. 컷오버 후 5xx 에러가 급증하거나 응답 시간이 임계치를 넘으면 즉시 알림이 와야 했다. 알림 채널은 Slack이 주로 사용되었고, 담당자에게 직접 알림이 가도록 설정했다. 모니터링 없이 컷오버를 하는 것은 눈을 감고 고속도로를 건너는 것과 같다.

롤백 계획 검증

컷오버가 실패할 경우의 롤백 계획도 사전에 검증했다. 롤백의 핵심은 DNS를 다시 Breeze 인프라로 되돌리는 것이었다. 하지만 DNS 롤백만으로는 충분하지 않다. 컷오버 후 글로벌 플랫폼에서 처리된 주문이나 데이터 변경이 있다면, 롤백 시 이 데이터를 어떻게 처리할지도 결정해야 했다.

완벽한 롤백은 불가능에 가까웠다. 컷오버 후 신규 주문이 글로벌 플랫폼에서 처리되면, 롤백 시 이 주문 데이터가 Breeze에는 없게 된다. 그래서 롤백 결정은 가능한 한 빨리 내려야 했고, 롤백 결정의 기준(예: 주문 실패율 X% 이상이 Y분 이상 지속)을 사전에 정의했다.

커뮤니케이션 채널과 War Room

컷오버 당일에는 Slack에 전용 war room 채널을 개설하여 모든 관련 팀(한국 개발팀, 글로벌 플랫폼팀, QA, CS, 비즈니스)이 실시간으로 상황을 공유했다. 컷오버 시작 전에 각 팀의 담당자가 채널에 모여 준비 상태를 확인했다.

이해관계자(stakeholder) 알림도 준비했다. 컷오버 시작 시, 진행 중, 완료 시 각각 알림을 보낼 대상과 내용을 미리 정해두었다. 문제가 발생할 경우 에스컬레이션 경로도 사전에 정의했다. 누가 어떤 문제를 담당하고, 결정 권한이 누구에게 있는지를 명확히 해두지 않으면 긴급 상황에서 시간이 낭비된다.

Go/No-Go 결정

컷오버 전날 저녁, 또는 당일 아침에 최종 Go/No-Go 결정을 내렸다. 모든 체크리스트 항목이 통과해야 Go였다. 하나라도 블로커가 있으면 No-Go로 컷오버를 연기하는 것이 원칙이었다. 이 결정은 기술팀뿐 아니라 비즈니스 쪽의 동의도 필요했다.

컷오버 전날 밤의 분위기는 독특했다. 수개월간 준비해온 모든 것이 내일 한 번의 DNS 전환으로 현실이 되는 순간이었다. 긴장과 기대가 공존했다. 체크리스트를 다시 한 번 확인하고, 가능한 모든 시나리오를 머릿속으로 시뮬레이션했다. 무엇이 잘못될 수 있을까? 그때 우리는 무엇을 할 수 있을까?

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

사전 점검 아키텍처의 의미

사전 점검은 체크리스트 소비가 아니라 위험을 단계별로 축소하는 아키텍처 작업이었다. 인증서, 모니터링, 롤백 경로, 커뮤니케이션 채널을 함께 점검해야 컷오버 당일에 기술 이슈와 운영 이슈를 분리해 대응할 수 있다.

장점은 문제를 사전에 격리할 수 있다는 점이고, 단점은 준비 단계에서 투입 시간이 크다는 점이다. 그러나 컷오버처럼 실패 비용이 큰 이벤트에서는 준비 시간이 가장 저렴한 보험이었다.

Go/No-Go 기술 체크리스트

• 인증서, DNS, 네트워크 경로의 유효기간/해결 경로를 사전 점검한다.
• 핵심 API SLI(에러율/지연시간) 기준선을 확보하고 컷오버 기준값을 합의한다.
• 롤백 경로를 단계별로 문서화하고 실행 책임자를 지정한다.
• 커뮤니케이션 채널의 단일 상태 표현(진행/보류/중단)을 사전에 통일한다.

SLI(Service Level Indicator)는 사용자 관점 품질 지표(예: 에러율, 응답지연)를 의미한다.