🧱 Nike Korea Platform Migration

Nike 로컬 커머스 플랫폼에서 글로벌 플랫폼으로 넘어가는 과정 전체를 시리즈로 묶었습니다. 운영 적응, 데이터 경계 정의, 주문 이관, 컷오버, 안정화, 분석 연계, 운영 안정성과 보안까지 이어집니다.

이 허브는 시리즈 글을 순서대로 따라갈 수 있게 정리한 페이지입니다. 현재는 Confluence Writing 단계를 기준으로 MDX 초안을 생성해 둔 상태이며, 이후 Reviewing 단계에서 제목과 구조가 조금 더 다듬어질 수 있습니다.

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. 운영 비용 최적화는 왜 인프라 절감보다 구조 문제에 가깝나