쇼핑몰 주문을 ERP로 넘기는 연계 작업에서 이메일이 같은 고객코드를 찾아 붙이면 구현은 간단해집니다. 그러나 주소가 바뀌면 기존 고객을 찾지 못하고, 같은 주소가 여러 기록에 있으면 다른 고객의 주문으로 연결될 수 있습니다. 아래는 특정 회사의 사고 사례가 아닌 설명용 업무 장면을 바탕으로, 이메일을 어디까지 연결 근거로 쓸지 정리한 내용입니다.
같은 이메일과 같은 고객 사이의 간격
ERP 고객코드는 개인 구매자뿐 아니라 법인 거래처나 청구 대상을 나타낼 수 있습니다. 쇼핑몰 회원번호는 로그인 계정의 식별자일 수 있으므로, 먼저 두 시스템에서 ‘고객’이 뜻하는 대상을 확인해야 합니다. 여러 구매 담당자가 한 법인 고객코드에 연결되는 구조라면 다대일 관계 자체는 오류가 아닙니다.
대표메일을 여러 담당자가 함께 쓰거나 이메일 중복을 허용하는 시스템에서는 주소 하나로 계정을 구별하기 어렵습니다. 같은 사람이 쇼핑몰의 연락처만 변경한 경우에는 두 시스템의 주소가 달라도 기존 연결을 유지해야 할 수 있습니다. 반대로 이전 주소가 다른 사람에게 재할당되면, 문자열이 같다는 이유로 과거 고객의 거래내역을 연결해서는 안 됩니다.
OpenID Connect Core 1.0의 5.7절은 이메일의 변경·재사용 가능성을 설명하며 고유 사용자 식별자로 사용하지 않도록 규정합니다. 이는 인증 표준의 규칙이며 모든 ERP에 직접 적용되는 사양은 아닙니다. 다만 변경 가능한 연락처와 지속적으로 사용할 식별자를 나눠야 한다는 설계 근거가 됩니다.
이메일 조회 결과를 연결 후보로 다루는 기준
연계 배치에서 이메일을 검색 조건으로 사용하더라도, 조회 결과를 곧바로 확정 매핑으로 저장하는 단계는 분리하는 편이 안전합니다. 다음 표는 자동 연결 여부를 검토하기 위한 제안이며 특정 ERP의 기본 동작을 설명한 것은 아닙니다.
| 조회·확인 상태 | 판단과 후속 처리 |
|---|---|
| 기존에 확인된 매핑 존재 | 해당 연결을 우선 사용하고 현재 이메일 차이는 별도 확인 |
| 이메일이 같고 양쪽 후보가 하나씩 존재 | 연결 후보로 보관하고 기존 고객과의 관계를 입증할 근거 확인 |
| 한쪽이라도 같은 이메일의 후보가 여럿 존재 | 첫 행을 임의 선택하지 않고 검토 대상으로 분리 |
| 이메일이 다르거나 누락 | 신규 고객으로 단정하지 않고 기존 식별자·연결 이력 확인 |
| 기존 매핑과 새 이메일 후보가 충돌 | 기존 연결을 덮어쓰지 않고 변경 사유와 승인 여부 확인 |
후보가 하나씩만 조회된다는 사실도 두 기록이 같은 고객이라는 증명은 아닙니다. 현재 데이터의 중복이 없다는 뜻에 그치므로, 고객이 양쪽 계정에 접근할 권한이 있는지 또는 업무 담당자가 확인한 거래처 관계가 있는지 함께 봐야 합니다. 이름이나 전화번호 하나를 이메일 대신 사용해도 이 확인을 생략할 수는 없습니다.
이메일 인증도 판단 범위를 구분해야 합니다. OpenID Connect의 email_verified 정의는 인증 시점에 사용자가 해당 주소를 통제했는지 확인했다는 의미입니다. 과거 ERP 거래의 당사자이거나 법인 고객의 모든 거래를 볼 권한이 있다는 뜻까지 포함하지 않습니다.
이메일 변경과 분리해 보관할 매핑 기록
확인된 관계는 이메일로 매번 다시 찾는 대신 별도의 매핑 테이블에 보관하는 방식을 검토할 수 있습니다. 매핑 테이블은 서로 다른 시스템의 식별자 사이 관계를 저장하는 데이터 목록입니다. ERP 고객코드와 쇼핑몰 회원번호 외에 회사·사이트 등 식별자의 유효 범위, 확인 근거, 처리자, 확인 시점, 현재 상태를 함께 남깁니다.
고객코드나 회원번호가 수정되거나 탈퇴 후 재사용되는지도 확인해야 합니다. 각 시스템이 제공하는 지속 식별자를 선택하고, 재사용 가능성이 있으면 생성 이력이나 유효기간으로 이전 연결과 구별합니다. 이메일 변경은 연락처 갱신으로 처리하되, 연결 변경은 별도 확인 절차를 거치도록 나눕니다.
소셜 로그인을 쓰는 쇼핑몰이라면 로그인 식별자와 ERP 고객 식별자의 역할도 구분합니다. Google의 OpenID Connect 문서는 사용자 식별에 이메일 대신 sub를 사용하도록 안내합니다. 이 값은 해당 Google 계정을 구분하는 근거이며, 그 자체로 ERP 고객코드와의 관계를 증명하지는 않습니다.
다대일 연결이 필요한 업무에서는 회원별 접근 범위도 따로 정합니다. 한 법인 고객코드에 연결됐다는 이유로 다른 담당자의 주문·청구 정보를 모두 보여주면 안 되는 경우가 있기 때문입니다. 데이터 연결에 성공했다는 결과와 거래정보 열람 권한이 적절하다는 판단은 별도로 확인합니다.
적용 전 대조할 연결 결과와 거래정보 범위
운영 데이터에 반영하기 전에는 이메일 변경, 공유 주소, 후보 없음, 중복 후보, 기존 연결 충돌을 시험 항목으로 잡습니다. 각 항목에서 후보·확정·보류 상태와 실제 주문의 귀속 고객이 의도대로 남는지 확인합니다. 조인 결과의 행 수가 늘었다면 같은 이메일 때문에 주문 한 건이 여러 고객과 결합됐는지도 살펴야 합니다.
계정 연결이 로그인이나 주문내역 조회까지 영향을 준다면 단순 정산용 데이터 대조보다 확인 강도를 높입니다. Auth0의 계정 연결 주의사항도 연결 전에 양쪽 계정의 인증을 요청하도록 권고합니다. 로그인 기능이 없는 ERP 고객은 그 인증 절차를 그대로 쓸 수 없으므로, 담당자가 확인할 고객 관계와 승인 근거를 업무에 맞게 정해야 합니다.
결론
이메일은 기존 고객을 찾는 단서로 활용하되, 확인된 고객 관계를 계속 유지하는 기준으로 삼기에는 변경·중복·재사용 문제가 있습니다. 연계 담당자는 먼저 고객코드의 의미와 식별자 재사용 정책을 확인하고, 후보 조회 결과와 확정 매핑을 나눠 관리해야 합니다. 첫 적용에서는 자동 연결률보다 잘못 연결된 거래와 보류 사유를 확인할 수 있는 기록을 우선 준비하는 편이 타당합니다.