한국 플랫폼 글로벌 전환은 왜 필요했나

2022년 10월 4일, Nike의 전자상거래 플랫폼이 로컬 Breeze 시스템에서 글로벌 Nike 플랫폼으로 전환되었다. 이 글은 그 전환이 왜 필요했는지, 어떤 비즈니스 동인과 기술적 한계가 결합되어 ‘한국도 글로벌 플랫폼으로 가야 한다’는 결론에 이르게 되었는지를 기록한다. 컷오버 당일의 기술적 실행이 아니라, 그 이전에 축적된 구조적 문제와 전략적 판단의 맥락을 남기고자 한다.

Nike는 글로벌 전환이 가장 늦은 국가 중 하나였다. 일본, 중국을 포함한 아시아 국가들이 이미 글로벌 플랫폼으로 이전한 상황에서 한국이 마지막까지 로컬 플랫폼을 유지한 데에는 이유가 있었다. 한국 전자상거래의 법적 요건, 결제 시스템의 특수성, 그리고 이미 안정적으로 운영되고 있던 Breeze 플랫폼의 관성까지 — 전환을 미루는 합리적 근거가 존재했다.

그러나 ‘로컬 플랫폼을 유지하는 비용’이 ‘글로벌 플랫폼으로 전환하는 비용’을 넘어서는 시점이 왔고, 이 글은 그 교차점이 어떻게 형성되었는지를 탐색한다.

전환 결정의 축

Nike의 전자상거래 플랫폼 Breeze는 Java/Spring 기반의 로컬 시스템이었다. 관계형 데이터베이스 기반으로 구축되었고, 한국 시장의 특수한 요건(PG사 연동, 본인인증, 전자상거래법 준수)에 맞춰 최적화되어 있었다. 약 10년간 한국 Nike.com과 SNKRS 서비스를 안정적으로 운영해온 플랫폼이었다.

문제는 글로벌 Nike가 완전히 다른 기술 스택의 현대적 플랫폼을 운영하고 있었다는 점이다. 글로벌 플랫폼은 마이크로서비스 아키텍처, 통합 아이덴티티 시스템(Nike+/SNKRS 통합 계정), 글로벌 상품 카탈로그, 표준화된 결제 게이트웨이를 갖추고 있었다. 두 개의 독립된 플랫폼을 동시에 유지하는 것은 이중 비용 — 개발, 운영, 보안 패치, 기능 출시 모두 두 배의 노력이 필요했다.

Nike의 글로벌 전략은 ‘One Platform’이었다. 전 세계 모든 국가가 하나의 플랫폼에서 운영되면, 새로운 기능을 한 번 개발하여 모든 국가에 동시 배포할 수 있다. 로컬 플랫폼이 남아 있으면 해당 국가는 글로벌 기능 출시에서 항상 뒤처지고, 글로벌 팀은 로컬 호환성까지 고려해야 하는 부담을 안게 된다.

의사결정 흐름

Breeze의 구조와 한계

Breeze는 한국 시장에 특화된 모놀리식 아키텍처였다. 상품 관리, 주문 처리, 결제, 회원 관리가 하나의 애플리케이션 안에서 동작했다. 단일 관계형 데이터베이스에 핵심 데이터가 저장되었고, 한국의 PG사(이니시스, KCP 등)와 직접 연동하는 결제 모듈을 갖추고 있었다. 이 구조는 한국 시장에서 안정적으로 동작했지만, 글로벌 기능(글로벌 상품 카탈로그, 통합 프로모션 등)을 추가하기 어려웠다.

기술적 한계도 누적되고 있었다. Spring 프레임워크의 구 버전에 의존하고 있었고, 보안 패치 적용이 점점 어려워졌다. 모놀리식 구조로 인해 하나의 변경이 전체 시스템에 영향을 줄 수 있었고, 배포 주기가 길었다. 글로벌 팀이 새로운 마이크로서비스를 주 단위로 배포하는 동안, Breeze는 월 1-2회의 정기 배포로 운영되었다.

이중 플랫폼의 비용

두 개의 플랫폼을 운영하는 비용은 단순히 서버 비용의 합이 아니었다. 개발팀이 두 플랫폼의 기술 스택을 모두 알아야 했고, 새로운 기능을 양쪽에 각각 구현해야 했다. 글로벌 프로모션 캠페인이 진행될 때 한국만 다른 구현을 해야 하는 경우가 빈번했다. QA 역시 두 플랫폼에서 각각 수행해야 했다.

아이덴티티(계정) 시스템의 분리도 큰 문제였다. Breeze의 회원 계정과 글로벌 Nike 계정은 별개의 시스템이었다. 한국 사용자는 Nike.com과 SNKRS에서 다른 계정을 사용하는 상황이 발생할 수 있었고, 글로벌 Nike+ 멤버십 혜택을 한국 사용자에게 일관되게 제공하기 어려웠다. 통합 아이덴티티 없이는 글로벌 멤버십 전략의 한국 적용이 불가능했다.

글로벌 전략: One Platform

Nike의 ‘One Platform’ 전략은 단순한 기술 통합이 아니라 비즈니스 전략이었다. 전 세계 소비자에게 동일한 디지털 경험을 제공하고, 멤버십 혜택을 국경 없이 확장하며, 데이터 기반 의사결정을 글로벌 단위로 수행하려면 하나의 플랫폼이 필요했다. 한국이 별도 플랫폼을 유지하는 한, 한국 시장의 데이터는 글로벌 분석에 포함되지 않고, 한국 소비자는 글로벌 경험에서 소외된다.

전환 결정은 2021년 즈음에 확정되었고, 약 1년간의 준비 기간을 거쳐 2022년 10월 4일 컷오버가 실행되었다. 이 결정에는 글로벌 경영진의 전략적 판단과 한국 로컬팀의 기술적 평가가 모두 반영되었다. ‘할 수 있는가’보다 ‘하지 않으면 어떻게 되는가’가 더 강력한 동인이었다.

한국 시장의 특수성

글로벌 전환이 늦어진 이유 중 하나는 한국 전자상거래의 법적, 기술적 특수성이었다. 한국 전자상거래법은 주문 데이터를 5년간 보관할 것을 요구한다. 결제 시스템은 한국 PG사와 직접 연동해야 하며, 본인인증(휴대폰 인증, 아이핀 등)이 필수적이었다. 이런 요건들은 글로벌 플랫폼에 이미 구현되어 있지 않았으므로, 전환 전에 글로벌 플랫폼이 한국 요건을 지원하도록 확장하거나, 별도의 어댑터를 만들어야 했다.

특히 주문 데이터 5년 보관 요건은 마이그레이션의 가장 큰 기술적 도전 중 하나가 되었다. 약 천만 명의 사용자와 수년간 축적된 주문 데이터를 어떻게 처리할 것인가 — 이 문제는 이후 BLOHA(Breeze Legacy Order History API) 탄생으로 이어진다.

글로벌 전환은 단순한 데이터 이동이 아니라 경계와 책임을 다시 정의하는 작업이었다는 점이 이 시리즈의 중심에 있다. 다음 글에서는 2021 - 주문 마이그레이션에서 가장 먼저 정의해야 했던 데이터 경계를 통해 이 흐름을 계속 좁혀 본다.

전환의 전략적 트레이드오프

이 전환은 단순히 “로컬이 낡았고 글로벌이 최신”이라는 구도가 아니었다. 로컬 플랫폼의 장점도 분명했다. 프로모션이든 기능이든 한국 비즈니스에 필요한 변경이 생기면 로컬 팀이 직접 구현해 빠르게 반영할 수 있었고, 운영 맥락에 맞춘 커스터마이징 여지도 상대적으로 컸다.

반대로 글로벌 플랫폼으로 오면 표준화된 구조를 따라야 하므로 로컬 전용 커스터마이징 폭은 줄어든다. 이 부분은 기술팀만의 결정이 아니라 로컬 비즈니스와도 함께 합의해야 하는 영역이었다. 즉 “로컬 민첩성 일부를 포기하고 글로벌 정렬을 선택할 것인가”가 핵심 트레이드오프였다.

대신 글로벌 플랫폼의 이점도 컸다. 데이터를 글로벌 기준으로 함께 보고, 국가 간 공통 지표 위에서 성과를 해석하며, 마케팅 전략도 더 넓은 관점에서 설계할 수 있다. 로컬 최적화의 속도는 줄어들 수 있지만, 지표 일관성과 글로벌 운영 효율을 얻는 선택이었다는 점이 중요했다.

플랫폼 전환 판단 기준

• 기능 추가 속도보다 장기 운영 유지비와 중복 개발 비용을 우선 비교했다.
• 로컬 커스터마이징 가치는 유지하되, 글로벌 표준과 충돌하는 항목은 축소했다.
• 전환 후 지표 일관성(국가 간 비교 가능성)을 핵심 의사결정 기준으로 삼았다.

로컬 vs 글로벌 트레이드오프