기존 주문을 글로벌 계정으로 조회하기 위한 식별자 연결

Nike Korea Platform Migration · Series 2 - 글로벌 마이그레이션 준비4 / 10Backend

글로벌 계정 식별자를 기존 주문 이력과 연결해, 플랫폼 전환 후에도 같은 고객의 주문을 조회하도록 한 구조를 설명합니다.

주문 데이터를 옮기는 것만으로는 고객이 과거 주문을 볼 수 없었습니다. 기존 Breeze의 계정과 글로벌 플랫폼의 계정은 서로 다른 시스템에서 관리됐기 때문입니다. 새 플랫폼에 로그인한 사용자가 기존 주문의 누구에 해당하는지 연결해야 했습니다.

이 글에서는 그 연결에 사용한 식별자를 글로벌 계정 연결 키라고 부릅니다.

글로벌 계정과 기존 주문 이력 연결

사용자가 글로벌 플랫폼으로 이관되고 글로벌 멤버 데이터에 식별자가 생성되면, 그 값을 BLOHA의 기존 주문 이력 매핑 정보와 연결했습니다.

이후 글로벌 플랫폼에서 해당 식별자로 주문 조회를 요청하면 BLOHA가 연결된 기존 주문 이력을 찾아 응답하는 방식이었습니다. 글로벌 계정 식별자와 기존 계정·주문의 관계를 유지해야 전환 전 주문도 같은 고객의 이력으로 조회할 수 있었습니다.

이 구조를 단순한 이메일 검색으로 설명하면 실제 역할을 놓치기 쉽습니다. 글로벌 플랫폼의 요청에서 사용하는 식별자와 기존 시스템이 주문을 연결한 계정 키는 다릅니다. 둘 사이의 연결 정보를 찾아 주문 조회에 사용하는 과정이 필요했습니다.

연락처와 로그인 정보는 바뀔 수 있습니다. 조회 요청마다 이메일이나 전화번호가 같다는 이유로 계정을 연결하기보다, 확정된 계정 관계를 기준으로 기존 주문을 찾아야 했습니다.

매핑이 없으면 과거 주문이 보이지 않습니다. 반대로 다른 계정과 잘못 연결하면 다른 고객의 주문을 응답할 수 있습니다. 두 상황은 원인과 대응이 다르므로 구분해서 봐야 했습니다.

확인할 때는 글로벌 계정 연결 키가 존재하는지, 그 키가 어떤 기존 계정에 연결됐는지, 실제 주문 조회가 그 관계를 사용하는지 순서대로 따라가야 합니다. 주문 데이터가 있다는 사실만으로는 고객 화면에 올바르게 노출된다고 판단할 수 없습니다.

계정 연결은 주문 이관과 별개로 끝낼 수 있는 작업이 아니었습니다. 계정 매핑이 맞아도 조회 API가 다른 식별자를 사용하면 기존 주문을 찾지 못합니다. 반대로 조회 결과를 만들 때 계정 범위를 잘못 적용하면 데이터가 엉뚱하게 섞일 수 있습니다.

그래서 글로벌 플랫폼의 요청부터 BLOHA의 매핑 조회, 기존 주문 응답까지 이어서 확인해야 했습니다. 새 시스템으로 전환한 뒤에도 기존 주문을 조회하기 위해 필요한 연결이었습니다.

다음 글에서는 이 조회 연동을 포함해 BLOHA가 마이그레이션에서 맡은 역할을 설명합니다.