컷오버 직후 무엇부터 안정화해야 했나

컷오버가 완료되면 끝이 아니다. DNS가 전환되고 사용자 트래픽이 글로벌 플랫폼으로 흐르기 시작하는 순간부터 안정화(stabilization)가 시작된다. 컷오버 직후의 안정화는 ‘문제가 발생하면 고치는’ 수동적 대응이 아니라, ‘무엇을 먼저 확인하고, 어떤 순서로 안정화할 것인가’라는 우선순위의 문제다.

이 글은 컷오버 직후 첫 24시간, 첫 1주, 첫 1개월 동안 실제로 어떤 항목을 어떤 순서로 안정화했는지를 기록한다. 모든 것을 동시에 확인할 수는 없으므로, 우선순위를 정하는 기준과 그 판단의 근거를 남긴다.

대규모 마이그레이션 후 안정화 경험은 흔하지 않다. 평상시의 운영과는 다른, 마이그레이션 특유의 안정화 과제들이 있고, 이를 기록해두는 것이 미래의 유사 프로젝트에 도움이 될 것이다.

컷오버 직후의 상황은 독특하다. 모든 것이 새로운 플랫폼에서 동작하지만, 아직 대규모 실제 트래픽으로 검증되지 않은 상태다. 스테이징과 부하 테스트에서는 문제가 없었지만, 실제 사용자의 다양한 행동 패턴, 엣지 케이스, 한국 특유의 요구사항(결제 PG, 주소체계 등)에서 예상치 못한 문제가 나타날 수 있다.

또한 Breeze에서 글로벌 플랫폼으로 전환되면서 CS(Customer Service) 팀의 운영 도구도 바뀌었다. CS 에이전트들이 새로운 도구에 익숙하지 않은 상태에서 고객 문의를 처리해야 했고, 이는 운영 효율 저하로 이어질 수 있었다.

컷오버 후 가장 가까운 The Draw 또는 SNKRS 이벤트가 언제인지도 중요했다. 이벤트 전까지 안정화를 완료하지 못하면, 고트래픽 상황에서 아직 안정화되지 않은 시스템이 부하를 받게 되는 최악의 시나리오가 발생할 수 있었다.

안정화 우선 실행 순서

최우선: 결제 플로우 검증 — 고객이 실제로 구매할 수 있는가?

컷오버 직후 가장 먼저 확인한 것은 결제(payment) 플로우였다. 커머스 플랫폼의 존재 이유는 상품을 판매하는 것이므로, 고객이 상품을 장바구니에 담고 결제를 완료할 수 있는지가 최우선이었다. 결제가 안 되면 매출이 0이 되는 것이다.

한국의 결제 환경은 복잡하다. 신용카드, 무통장 입금, 카카오페이, 네이버페이 등 다양한 결제 수단이 있고, 각 PG(Payment Gateway)와의 연동이 정상적으로 동작하는지를 확인해야 했다. 글로벌 플랫폼에서 한국 PG와의 연동은 로컬라이제이션(localization)이 필요한 영역이었다. 실제 테스트 결제를 수행하여 end-to-end 플로우가 동작하는지를 확인했다.

주문 이력 조회 — BLOHA를 통한 과거 주문 확인

두 번째 우선순위는 주문 이력(order history) 조회였다. 기존 Breeze에서 주문한 내역을 글로벌 플랫폼에서도 확인할 수 있어야 했다. BLOHA(Buy/Launch Order History Adapter 또는 유사한 컴포넌트)가 Breeze의 주문 데이터를 글로벌 플랫폼에서 조회할 수 있게 해주는 어댑터 역할을 했다.

고객이 ‘내 주문 내역이 사라졌다’고 느끼면 즉시 CS 문의가 폭주한다. 과거 주문 데이터가 정상적으로 표시되는지, 주문 상세(상품명, 결제 금액, 배송 상태 등)가 정확한지를 확인했다. 데이터 마이그레이션 시 변환된 데이터가 UI에서 올바르게 렌더링되는지도 검증 대상이었다.

CS 도구 — 에이전트가 주문을 조회하고 처리할 수 있는가?

세 번째는 CS(Customer Service) 도구의 정상 동작 여부였다. CS 에이전트가 고객의 주문을 조회하고, 환불/교환을 처리하고, 고객 정보를 확인할 수 있어야 했다. 컷오버 후 CS 도구가 글로벌 플랫폼의 것으로 바뀌었으므로, 에이전트들의 학습 곡선도 고려해야 했다.

CS 도구가 동작하지 않으면 고객 문의를 처리할 수 없고, 이는 고객 불만의 누적으로 이어진다. 특히 컷오버 직후에는 평소보다 많은 고객 문의가 예상되므로(서비스 변경에 대한 질문, 데이터 누락 신고 등), CS 도구의 안정화가 더욱 중요했다.

성능과 에러율 — 응답시간은 허용 범위인가?

네 번째는 성능(performance)과 에러율(error rate) 모니터링이었다. 글로벌 플랫폼의 인프라가 한국 사용자의 트래픽 패턴을 잘 처리하는지, 응답시간이 사용자 경험상 허용 가능한 수준인지를 확인했다. 특히 상품 목록 페이지(PLP), 상품 상세 페이지(PDP), 장바구니, 결제 페이지 등 주요 경로의 성능을 집중 모니터링했다.

에러율 스파이크도 경계 대상이었다. 컷오버 직후 일시적인 에러 증가는 예상했지만, 지속적인 에러율 상승은 시스템 문제를 의미한다. 5xx 에러, 타임아웃, 특정 API의 반복적 실패 등을 모니터링하고, 이상이 감지되면 즉시 원인을 분석하여 대응했다.

The Draw/SNKRS 이벤트 대비

다섯 번째는 다가오는 The Draw 또는 SNKRS 이벤트에 대한 대비였다. 컷오버 후 가장 가까운 고트래픽 이벤트가 언제인지 파악하고, 그 전까지 시스템이 안정화되어야 했다. The Draw는 짧은 시간에 수만 명이 동시 접속하므로, 평상시에는 드러나지 않는 성능 문제가 폭발적으로 나타날 수 있다.

이벤트 전에 부하 테스트를 추가로 실행하고, 인프라 스케일링이 적절한지 확인하며, 이벤트 당일의 운영 계획(모니터링 담당자, 에스컬레이션 경로 등)을 수립했다. 컷오버 직후의 첫 고트래픽 이벤트를 성공적으로 넘기는 것이 안정화의 중요한 마일스톤이었다.

첫 24시간, 첫 주, 첫 달의 차이

안정화의 시간 프레임에 따라 관심사가 달라졌다. 첫 24시간은 치명적 문제(결제 불가, 서비스 다운, 데이터 누락)의 발견과 대응에 집중했다. 첫 주에는 일상적 운영의 안정성(배치 작업 정상 실행, 재고 동기화, 이메일 발송 등)을 확인했다. 첫 달에는 장기적 관점의 문제(성능 추이, 리소스 사용량 추이, 사용자 피드백 종합)를 분석했다.

시간이 지나면서 ‘이것이 문제인가, 아니면 원래 이런 것인가’를 판단하는 것도 중요했다. 새로운 플랫폼의 동작이 이전 플랫폼과 다를 때, 그것이 버그인지 의도된 차이인지를 구분해야 했다. 이 판단에는 Breeze의 동작을 아는 한국 팀의 지식이 필수적이었다.

컷오버는 단일 이벤트가 아니라 사전 확인, 당일 실행, 직후 안정화가 이어지는 운영 시퀀스라는 점이 핵심이다.

안정화 단계의 기술적 트레이드오프

직후 안정화에서 가장 어려운 선택은 “빠른 완화”와 “정확한 원인 분석”의 균형이었다. 즉시 완화는 사용자 영향을 줄이지만, 원인을 충분히 남기지 않으면 같은 문제가 반복된다. 그래서 완화 조치와 관측 로그 확보를 동시에 수행하는 운영 기준이 필요했다.

또한 첫 24시간/첫 주/첫 달을 분리해 보는 방식은 모니터링 비용을 늘리지만, 문제 성격을 시간 축으로 나눠 해석할 수 있다는 장점이 있다. 이 관점이 있어야 단기 이상과 구조적 이슈를 구분할 수 있었다.

안정화 우선순위 매트릭스

직후 안정화 체크포인트

• 완화 조치와 동시에 근거 로그를 남겨 재발 분석 가능성을 확보한다.
• 기존 플랫폼과 동작 차이는 버그/의도 차이를 분리해 기록한다.
• 단기 핫픽스와 중기 구조 개선 항목을 분리해 백로그화한다.