기존 계정과 글로벌 계정을 공유 식별자로 연결해야 했던 이유

플랫폼 마이그레이션에서 주문 데이터를 옮기는 것만큼 중요한 것은 ‘이 주문이 누구의 것인지’를 새 시스템에서도 식별할 수 있게 하는 것이다. Breeze의 사용자 계정과 글로벌 Nike 계정은 별개의 시스템이었고, 두 계정을 연결하는 키가 필요했다. 이 글에서는 이를 글로벌 계정 연결 키로 부른다.

글로벌 계정 연결 키는 Breeze 로컬 계정과 글로벌 Nike 계정을 연결하는 브릿지 역할을 한다. 이 연결이 없으면 사용자는 글로벌 플랫폼에 로그인해도 자신의 과거 주문 내역을 볼 수 없다. 수천만 규모의 사용자 계정을 매칭하는 이 작업은, 단순한 이메일 매칭으로 해결되지 않는 복잡한 엣지 케이스들을 포함하고 있었다.

Breeze에서 사용자는 이메일, 전화번호, 또는 소셜 로그인으로 계정을 만들었다. 글로벌 Nike 플랫폼에서도 사용자는 이메일 기반으로 계정을 만든다. 문제는 같은 사람이라도 두 시스템에서 다른 이메일을 사용했을 수 있다는 것이다. 또한 Breeze 계정은 있지만 글로벌 Nike 계정은 없는 사용자, 반대로 글로벌 Nike 계정은 있지만 Breeze에서 구매한 적이 없는 사용자도 있다.

글로벌 계정 연결 키는 이 두 세계를 연결하는 통합 식별자다. 사용자가 글로벌 플랫폼으로 마이그레이션되어 글로벌 멤버 데이터에 키가 생성되면, 이 키를 BLOHA의 Breeze 주문 이력 매핑 정보에 연결해 같은 사용자로 인식하게 했다. 이후 글로벌에서 이 키로 주문 조회를 요청하면, BLOHA를 통해 해당 사용자의 과거 주문 이력을 함께 응답할 수 있다. 이 매핑이 정확하지 않으면 다른 사람의 주문 이력이 보이거나, 자신의 주문 이력이 보이지 않는 심각한 문제가 발생한다.

계정 매칭의 기본 원리

계정 매칭의 가장 기본적인 방법은 이메일 주소다. Breeze 계정의 이메일과 글로벌 Nike 계정의 이메일이 같으면 같은 사람으로 간주한다. 전화번호도 보조 매칭 키로 사용할 수 있다. 이 방법으로 대다수의 사용자를 매칭할 수 있었지만, 문제는 매칭되지 않는 케이스들이었다.

이메일이 다른 경우: 사용자가 Breeze에서는 개인 이메일을, 글로벌 Nike에서는 회사 이메일을 사용했을 수 있다. 전화번호도 변경되었을 수 있다. 이런 경우 자동 매칭이 불가능하고, 사용자가 직접 계정을 연결하는 절차가 필요했다.

매칭 전략 한눈에 보기

엣지 케이스들

계정 매칭에서 발견된 주요 엣지 케이스들이 있다. 첫째, 휴면 계정(dormant accounts): Breeze에 오래전 가입했지만 수년간 사용하지 않은 계정. 이 계정의 이메일이 유효하지 않을 수 있고(도메인 폐쇄 등), 전화번호도 변경되었을 수 있다. 주문 이력이 있으므로 계정 자체는 유지해야 하지만, 매칭할 글로벌 계정이 없을 수 있다.

둘째, 동일 이메일 다른 사용자: 가족이 같은 이메일로 Breeze와 글로벌 Nike에 각각 계정을 만든 경우. 이메일이 같다고 해서 반드시 같은 사람은 아니다. 셋째, 병합된 계정(merged accounts): Breeze에서 중복 계정을 병합한 이력이 있는 경우, 병합된 계정의 글로벌 계정 연결 키 처리가 복잡해진다.

넷째, 글로벌 계정은 있지만 한국 Breeze 계정이 없는 사용자: 해외에서 Nike 계정을 만들고 한국에 온 사용자. 이 경우 매칭할 Breeze 데이터가 없으므로 글로벌 계정 연결 키 기반 과거 이력 연결 자체가 불필요하지만, 글로벌 플랫폼 전환 후 이 사용자가 한국에서 주문하면 정상적으로 처리되어야 한다.

공유 식별자 생성과 할당 프로세스

글로벌 계정 연결 키는 글로벌 계정 생성 이후 Breeze 계정과의 매핑 레코드를 만들 때 할당된다. 자동 매칭(이메일/전화번호 일치)이 가능한 계정은 배치 프로세스로 연결하고, 자동 매칭이 불가능한 계정은 사용자가 글로벌 플랫폼에 처음 로그인할 때 수동으로 연결하는 흐름을 제공했다.

수동 연결 흐름은 사용자 경험과 보안 사이의 균형이 필요했다.

데이터 무결성과 보안

글로벌 계정 연결 키 매핑은 매우 민감한 데이터다. 잘못된 매핑은 다른 사용자의 주문 이력이 보이는 것 — 개인정보 침해 — 을 의미한다. 따라서 매핑 정확성의 검증이 필수적이었다. 자동 매칭된 결과를 샘플링하여 수작업으로 검증하고, 의심스러운 케이스(예: 한 글로벌 계정에 여러 Breeze 계정이 매칭된 경우)는 별도로 리뷰했다.

보안 관점에서도 글로벌 계정 연결 키 매핑 데이터는 철저히 보호되어야 했다. 이 데이터가 유출되면 사용자의 두 플랫폼 계정 간 연결 관계가 노출되기 때문이다. 접근 권한을 최소화하고, 매핑 데이터의 전송과 저장에 암호화를 적용했다.

글로벌 전환은 단순한 데이터 이동이 아니라 경계와 책임을 다시 정의하는 작업이었다는 점이 이 시리즈의 중심에 있다. 다음 글에서는 2021 - BLOHA는 왜 필요했고 마이그레이션에서 어떤 역할을 했나를 통해 이 흐름을 계속 좁혀 본다.

기술 선택의 핵심과 한계

공유 식별자를 중심에 두면 계정 연결의 일관성을 확보할 수 있고, 주문 조회·반품·CS 도구까지 같은 키로 연동할 수 있다. 이 방식의 장점은 시스템이 달라도 동일한 사용자 맥락을 유지할 수 있다는 점이다.

반면 매핑 데이터의 정확도와 보안 요구가 매우 높아진다. 잘못된 연결은 다른 사용자 데이터 노출로 이어질 수 있어 검증·감사·권한 통제를 함께 설계해야 한다. 즉 식별자 통합은 단순 데이터 모델링이 아니라 보안 아키텍처 결정이기도 했다.

기술 체크포인트

• 매핑 키는 단일 진실 원천(SSOT)으로 운영해 중복 연결을 차단했다.
• 고위험 케이스(다중 계정 매핑)는 자동 승인 없이 검토 큐로 분리했다.
• 매핑 테이블 접근은 최소 권한 + 감사 로그로 통제했다.

식별자 연계 설계 비교