외국인 고객 데이터를 처리할 때 생기는 문제

Executive Summary

외국인 고객 데이터에서 반복되는 문제는 "값이 없다"가 아니라 "값이 여러 개다"입니다. 한 사람에게 여권 표기, 외국인등록증 표기, 통장 예금주 표기, 본인이 평소 쓰는 표기가 동시에 존재하고, 이 표기들이 시스템마다 다르게 저장되거든요. 그리고 대조가 필요한 순간 — 본인확인, 정산, 증빙 발급 — 에 불일치가 한꺼번에 드러납니다.

이름: 하나의 사람, 여러 개의 표기

이 네 가지가 일치할 거라고 가정한 시스템은 정산 단계에서 멈춥니다. 실무에서는 "이름이 달라 송금이 반려되었습니다"라는 형태로 나타나는데요. 이때 담당자가 개별로 확인 연락을 돌리게 됩니다. 참여자가 수십 명이면 감당되지만, 수백 명이면 운영이 무너지죠.

설계 기준: 어떤 표기를 정본으로 삼을지 먼저 정하고, 나머지는 별칭(alias)으로 함께 저장합니다. 대조는 정본끼리만 수행하고, 화면 표시는 사용자가 고른 표기를 씁니다.

식별자: 전화번호를 키로 쓰면 계정이 끊깁니다

외국인 사용자의 국내 번호는 체류 상태와 통신사 계약에 따라 바뀝니다. 출국 후 재입국, 유학생의 학기 단위 계약, 선불 요금제 전환 과정에서 번호가 사라지는 일이 흔하거든요. 전화번호를 유일 식별자로 삼은 서비스는 이 시점에 사용자의 이력을 잃습니다.

반대로 이메일은 상대적으로 안정적이지만, 국가별로 선호하는 메일 서비스가 다르고 일부는 스팸 정책 때문에 알림이 도달하지 않습니다. 식별자는 내부 ID 로 두고, 연락 수단은 복수로 확보한 뒤 도달 여부를 따로 기록하는 구조가 안전합니다.

체류자격: 필요한 만큼만, 분리해서

체류자격은 서비스 이용 가능 여부를 결정하는 정보인 동시에 민감한 개인정보입니다. 채용·금융·교육처럼 자격 확인이 필수인 영역이 아니라면 수집하지 않는 편이 낫고, 수집한다면 수집 목적과 보관 기간, 접근 권한을 다른 회원 정보와 분리해 관리해야 합니다.

실무적으로 더 중요한 건 체류자격이 변한다는 점인데요. 가입 시점의 값을 고정값으로 저장하면, 몇 달 뒤 잘못된 판단의 근거가 됩니다. 확인 시점을 함께 기록하고 만료를 관리해야 하죠.