글로벌 팀과 로컬 팀은 컷오버를 어떻게 나눠 준비했나
Nike Korea Platform Migration은 한 팀이 단독으로 수행한 프로젝트가 아니다. 미국에 위치한 글로벌 팀이 대상 플랫폼을 소유하고, 한국의 로컬 팀이 소스 데이터와 로컬 운영을 소유한다. 이 두 팀이 16-17시간의 시간대 차이(KST vs PST), 다른 언어, 다른 개발 도구, 다른 업무 문화 속에서 하나의 컷오버를 성공시켜야 했다.
이 글은 글로벌 팀과 로컬 팀이 컷오버 준비를 어떻게 분담했는지, 협업의 어려움은 무엇이었는지, 시간대 차이를 어떻게 극복했는지를 기록한다. 기술적 실행 못지않게, 대규모 마이그레이션에서의 조직 간 협업과 커뮤니케이션이 성공의 핵심 요소였다는 것을 보여주고자 한다.
시차가 큰 협업에서는 “좋은 설계”보다 “공통 상태표현과 실행 로그”가 컷오버 성공률에 더 직접적으로 작용했다.
글로벌 팀(US-based)은 글로벌 플랫폼의 소유자다. 플랫폼의 아키텍처, API, 데이터 스키마, 배포 파이프라인을 관리한다. 한국 마이그레이션을 위해 플랫폼이 한국의 요건(결제, 법적 요건, 한글 지원 등)을 지원하도록 확장해야 하며, 마이그레이션된 데이터를 받아들일 준비를 해야 한다.
로컬 팀(Korea)은 Breeze 시스템의 소유자다. 소스 데이터의 구조를 알고 있고, 로컬 운영(CS, 물류, 결제)을 담당한다. 데이터 추출과 변환 스크립트를 작성하고, 로컬 환경에서의 테스트를 수행한다. 컷오버 당일에는 Breeze 시스템의 종료와 글로벌 플랫폼으로의 트래픽 전환을 실행한다.
두 팀 사이의 시간대 차이는 16-17시간이다(한국 KST 기준 오후 4시가 미국 PST 기준 자정). 실질적인 업무 시간 겹침(overlap)은 하루에 2-3시간에 불과했고, 이 짧은 겹침 시간에 의사결정, 기술 논의, 이슈 해결을 모두 수행해야 했다.
역할 분담: 누가 무엇을 책임지는가
| 영역 | 글로벌 팀 | 로컬 팀 |
|---|---|---|
| 플랫폼 준비 | 한국 시장 요건 반영(결제/언어/법적 요건) | 로컬 운영 영향 검증 |
| 데이터 경로 | 수신 API/파이프라인 제공 | 추출/변환 스크립트 작성 |
| 브리지/식별자 | 글로벌 계정 모델 제공 | 글로벌 계정 연결 키 매칭, BLOHA 운영 |
| 컷오버 실행 | DNS/라우팅/글로벌 모니터링 | Breeze freeze, 최종 배치, 로컬 검증 |
시간대 차이의 극복
16-17시간의 시간대 차이는 단순한 불편이 아니라, 의사결정 속도를 근본적으로 제한하는 구조적 문제다. 한국 팀이 오전에 발견한 이슈를 미국 팀에 전달하면, 미국 팀이 확인하는 것은 한국 시간 다음 날 아침이다. 한 번의 왕복(round-trip)에 24시간이 걸린다. 긴급한 이슈에서 이 지연은 치명적이다.
이를 완화하기 위해 아래 운영 루프를 고정했다.
겹치는 시간대에 의사결정 집중
한국 오후~미국 아침의 짧은 overlap 시간에 핵심 의사결정을 몰아서 처리했다.
비동기 로그를 표준화
Slack/Confluence에 상태·이슈·다음 액션을 같은 템플릿으로 남겨 출근 즉시 이어서 실행할 수 있게 했다.
컷오버 기간 확장 근무/교대 운영
직전 기간과 당일에는 양쪽 팀 모두 확장 근무를 운영해 의사결정 지연을 줄였다.
커뮤니케이션 채널과 도구
글로벌 팀과 로컬 팀이 사용하는 도구가 달랐다. 글로벌 팀은 Jira, Confluence, Slack의 글로벌 인스턴스를 사용하고, 로컬 팀은 일부 로컬 도구를 사용하는 경우가 있었다. 프로젝트 추적, 문서 공유, 실시간 소통이 각각 다른 도구에서 이루어지면 정보가 분산된다.
이를 해결하기 위해 마이그레이션 전용 Slack 채널을 개설하고, Confluence에 공유 위키 공간을 만들어 양쪽 팀이 동일한 정보에 접근할 수 있도록 했다. 기술 명세서(specification)는 영어로 작성하되, 로컬 팀 내부 논의는 한국어로 진행하고 결론만 영어로 공유 채널에 올리는 방식을 취했다.
컷오버 당일의 조율
컷오버 당일은 양쪽 팀이 실시간으로 소통하며 단계별로 작업을 실행해야 하는 날이다. 2022년 10월 4일(한국 시간) 컷오버는 한국의 저트래픽 시간과 미국 팀의 가용 시간을 함께 고려해 운영되었고, 양쪽 모두 실시간 대응이 가능한 구간에서 진행됐다.
실제 운영은 사전에 합의된 야간 일정과 교대 체계로 진행됐고, 모두가 한 번에 끝내기보다 계획된 교대 방식으로 워룸을 유지했다. 교대에 맞춰 출근 시간도 조정했고, 일부는 다음날 늦은 오전까지 최종 안정화 확인을 마친 뒤에야 작업을 종료했다.
컷오버 체크리스트(runbook)는 아래처럼 단계별 책임과 승인 조건을 명시했다.
Breeze 신규 주문 중단 (로컬 팀)
트래픽 경계를 고정하고 추가 데이터 변동을 멈춘다.
최종 배치 마이그레이션 실행 (로컬 팀)
사전 정의한 배치 순서로 잔여 데이터 이관을 완료한다.
정합성 검증 (로컬 + 글로벌 팀)
주요 지표와 샘플 시나리오를 교차 검증한다.
DNS 전환 (글로벌 팀)
전환 승인 후 라우팅을 글로벌 플랫폼으로 이동한다.
모니터링/고(go) 확인 (양쪽 팀)
각 단계 완료 때마다 go/no-go를 선언하고 다음 단계로 진행한다.
글로벌 전환은 단순한 데이터 이동이 아니라 경계와 책임을 다시 정의하는 작업이었다는 점이 이 시리즈의 중심에 있다. 다음 글에서는 2022 - 컷오버 전 상품 정합성, Clickstream, 이메일 바운스 대응을 통해 이 흐름을 계속 좁혀 본다.
협업 아키텍처의 장단점
글로벌-로컬 분업의 장점은 각 팀의 전문성을 살릴 수 있다는 점이다. 로컬 팀은 도메인과 운영 맥락을 빠르게 판단하고, 글로벌 팀은 플랫폼 표준과 전환 절차를 안정적으로 맞춘다. 이 조합이 맞아야 컷오버 같은 고위험 작업을 짧은 시간 안에 실행할 수 있다.
반면 분업 구조는 커뮤니케이션 비용이 높다. 같은 사실을 서로 다른 문맥으로 이해하면 의사결정이 지연되기 쉽다. 그래서 실행 단계에서는 도구보다 “공통 용어, 공통 상태표현, 공통 체크리스트”를 먼저 맞추는 것이 실제 성패를 가른다.
협업 운영 체크포인트
- 단계별 책임자와 승인자를
RACI형태로 사전 확정한다. - 상태 표현을
Ready / Running / Hold / Rollback으로 통일한다. - 시차 협업을 고려해 텍스트 로그를 실시간 회의와 병행한다.
글로벌-로컬 분업 비교
| 모델 | 장점 | 한계 |
|---|---|---|
| 기능 분업형 | 전문성 집중 | 경계 충돌 시 지연 가능 |
| 단계 공동 책임형 | 상황 공유 용이 | 조율 비용 증가 |