Nike Korea Platform Migration

Nike Korea Platform Migration은 로컬 커머스 플랫폼을 운영하던 조직이 글로벌 플랫폼으로 넘어가며 겪었던 구조적 전환을 정리한 시리즈입니다. 운영 적응에서 시작해 데이터 경계 정의, 주문 이관, 컷오버, 직후 안정화, 분석 연계, 운영 안정성과 보안까지 하나의 긴 흐름으로 이어집니다.

이 전환이 특히 중요했던 이유는 단순한 시스템 교체가 아니라 운영 방식 자체를 다시 배우는 과정에 가까웠기 때문입니다. 기존 서비스의 제약을 이해해야 했고, 동시에 글로벌 표준 구조에 맞춰 데이터와 업무를 재정렬해야 했습니다. 그래서 마이그레이션은 기술 작업만이 아니라 운영, 협업, 의사결정이 함께 움직이는 프로젝트였습니다.

이 페이지는 시리즈 허브입니다. 전체 글 목록과 분리해서, Nike Korea Platform Migration 관련 글만 순서대로 따라갈 수 있게 4개 시리즈로 묶어 정리합니다.

Series 1. 입사 직후 운영과 적응

1. 입사 직후 내가 맡은 일은 신규 개발이 아니라 nike.com/kr 운영이었다
2. 글로벌 마이그레이션이 예정된 상태에서 왜 큰 피처를 만들지 않았나
3. 운영 중인 커머스 사이트를 맡으며 먼저 파악해야 했던 시스템 경계
4. Log4j(CVE-2021-44228) 긴급 패치
5. Breeze 정기 배포 체계
6. Consent Journey
7. Solr 이중화 문제

Series 2. 글로벌 마이그레이션 준비

1. 한국 플랫폼 글로벌 전환은 왜 필요했나
2. 주문 마이그레이션에서 가장 먼저 정의해야 했던 데이터 경계
3. 왜 주문 데이터는 한 번에 전부 옮길 수 없었나
4. 반품 기간과 운영 상태를 고려한 점진적 주문 이관 전략
5. 기존 계정과 글로벌 계정을 공유 식별자로 연결해야 했던 이유
6. BLOHA는 왜 필요했고 마이그레이션에서 어떤 역할을 했나
7. 글로벌 로그인 이후에도 과거 주문 조회를 유지하는 구조
8. CS 조회, 반품, 배송 상태 동기화는 왜 같이 풀어야 했나
9. 주문 이관 배치, 성능 테스트, 정합성 검증은 어떻게 준비했나
10. 글로벌 팀과 로컬 팀은 컷오버를 어떻게 나눠 준비했나
11. 컷오버 전 상품 정합성, Clickstream, 이메일 바운스 대응
12. 런칭 데이터와 공유 식별자의 글로벌 분석 연계

Series 3. 컷오버와 직후 안정화

1. 2022년 10월 4일 컷오버 직전 무엇을 체크했나
2. 컷오버 당일 최종 남은 데이터를 어떻게 이관했나
3. 컷오버 직후 무엇부터 안정화해야 했나

Series 4. 운영 안정성과 보안

1. ISMS 대응은 실제 개발 조직의 일을 어떻게 바꾸는가
2. DR Plan과 실운영 DR 훈련은 무엇을 검증해야 하나
3. 취약점 점검과 pen test 대응은 왜 상시 체계여야 하나
4. 장애 감지와 알림 체계는 어떤 신호부터 잡아야 실무에 도움이 되나
5. 외부 장애가 내부 서비스로 전파되지 않게 막는 방법
6. 운영 비용 최적화는 왜 인프라 절감보다 구조 문제에 가깝나