국경을 넘는 주소 시나리오에서 가장 먼저 정할 것은 어느 국가를 기준으로 삼을지입니다. 주문 하나에 결제 국가, 배송 국가, 등록 국가가 함께 등장하기 때문입니다. 기준을 정하지 않으면 화면마다, 검증마다 다른 나라의 규칙이 섞입니다.
한 주문 안에 국가 차원은 몇 개나 있나요?
적어도 네 가지가 등장할 수 있습니다. 결제 수단을 발급한 국가, 물건을 받을 국가, 사업자가 등록된 국가, 그리고 구매자의 신원을 확인한 국가입니다. 국내 주문에서는 이 넷이 같은 값이라 하나로 보이지만, 국경을 넘는 순간 각각 다른 값이 됩니다.
이 네 차원은 서로 다른 근거에서 관리됩니다. 결제 국가는 결제 수단과 금융 제도에, 배송 국가는 물류와 통관에, 등록 국가는 사업자 정보에 묶여 있습니다. 하나의 국가 항목으로 합치면 어느 차원을 바꿀 때 나머지까지 함께 바뀝니다.
그래서 주문 데이터에는 국가 항목이 여러 개 있고, 각 항목에는 이름을 붙여 두는 편이 좋습니다. 이름이 없는 국가 항목은 나중에 어느 쪽을 가리키는지 아무도 확신하지 못합니다.
결제 국가와 배송 국가가 다르면 어느 쪽을 기준으로 삼나요?
정답은 하나가 아니라, 무엇을 확인하려는지에 따라 달라집니다. 주소의 형식과 필수 항목은 배송 국가를 따르는 것이 자연스럽습니다. 물건이 도착할 곳의 우편 체계와 행정 구역 이름을 써야 실제로 배달되기 때문입니다.
결제 관련 규칙은 결제 국가를 따릅니다. 세금과 통화, 결제 수단의 조건은 돈이 오가는 쪽의 제도에 묶여 있습니다. 이 둘을 한 기준으로 처리하면 한쪽은 반드시 틀립니다.
그래서 기준을 검증 규칙 안에 숨기지 말고, 어느 차원을 기준으로 삼는지 명시하는 편이 안전합니다. 같은 주소 필드라도 어떤 맥락에서 검사하느냐에 따라 기준 국가가 달라질 수 있다는 사실을 규칙 자체가 담고 있어야 합니다.
전화번호와 통화, 시간대는 왜 따로 봐야 하나요?
이 세 가지는 주소 국가를 따라가지 않는 대표적인 값입니다. 전화번호는 배송 국가가 아니라 사용자가 실제로 연락받는 곳의 국가에 묶이고, 통화는 결제 국가에 묶입니다. 시간대는 둘 중 어느 쪽과도 다를 수 있습니다.
이 불일치는 예외가 아니라 정상적인 상태입니다. 국경을 넘어 일하는 사람, 여러 국가에서 활동하는 사업자, 이동 중인 사용자에게서 흔히 나타납니다. 이 조합을 오류로 처리하면 정상 사용자를 막게 됩니다.
전화 접두어와 지역 매칭에서 다루듯 전화와 지역의 관계는 그 자체로 별도의 주제입니다. 이 글에서는 이 값들이 주소 국가와 어긋날 수 있다는 사실만 확인하고 넘어갑니다.
이런 불일치를 확인하려면 조합을 만드는 편이 좋습니다. 주소 국가와 전화 국가가 같은 경우, 다른 경우, 둘 중 하나가 비어 있는 경우를 나눠 두면 각각의 처리 방식이 드러납니다.
긴 국가 이름과 긴 주소는 어디를 망가뜨리나요?
국경을 넘는 주문에서는 긴 값들이 같은 화면에 모이는 일이 잦습니다. 가장 긴 국가 이름과 가장 긴 주소 줄이 한 화면에 오면, 평소에는 문제없던 자리가 한꺼번에 드러납니다.
망가지는 자리는 보통 세 곳입니다. 주소 라벨과 미리보기처럼 너비가 정해진 영역, 표의 열, 그리고 인쇄물의 고정된 칸입니다. 이 자리들은 국내 주문만 확인하면 늘 여유가 있어 보입니다.
확인하는 방법은 단순합니다. 가장 긴 값을 넣고 화면과 인쇄물을 한 번 그려 보는 것입니다. 이때 값이 잘리는지, 줄바꿈이 되는지, 아니면 옆 칸을 밀어내는지가 드러납니다.
배송 불가와 형식 오류는 왜 나눠 알려야 하나요?
배송 불가는 우리가 그 나라로 보내지 않는다는 뜻이고, 형식 오류는 입력한 값의 모양이 규칙과 맞지 않는다는 뜻입니다. 원인이 다르고, 사용자가 할 수 있는 일도 다릅니다. 하나는 다른 배송지를 고르는 일이고, 다른 하나는 주소를 고치는 일입니다.
두 가지를 한 문구로 처리하면 사용자는 주소를 아무리 고쳐도 통과하지 못합니다. 자기 주소가 틀렸다고 믿고 여러 번 다시 입력하다가 결국 이탈합니다. 문구를 나누는 것만으로 해결되는 문제입니다.
또 하나 구분해야 할 것은 아직 지원하지 않는 것과 영영 지원하지 않는 것입니다. 앞의 경우에는 언제 열릴지에 대한 안내가 필요하고, 뒤의 경우에는 다른 방법을 알려 주어야 합니다. 이 구분은 데이터가 아니라 안내의 문제입니다.
작은 지역으로 배송하는 경우에는 이 문제가 더 자주 생깁니다. 목록에 없는 지역을 사용자가 직접 입력하는 상황은 작은 지역과 특수 코드에서 다룹니다. 국가와 언어를 섞어 처리할 때 생기는 문제는 국가와 언어의 차이에서 이어집니다.
주소를 어느 언어로 보여 줘야 하나요?
국경을 넘는 주문에서는 주소를 두 가지 방식으로 보여 줄 필요가 생깁니다. 사용자가 입력한 형태와, 실제로 배달에 쓰이는 형태입니다. 둘은 다를 수 있고, 둘 다 필요합니다.
사용자에게는 자기가 입력한 표기를 그대로 보여 주는 편이 좋습니다. 갑자기 다른 문자로 바뀌면 자기가 적은 주소가 맞는지 확인할 수 없습니다. 반면 배송 라벨에는 그 지역에서 읽히는 표기가 필요합니다.
이때 한쪽을 다른 쪽으로 덮어쓰면 안 됩니다. 원본을 남기고 표시용 값을 따로 만듭니다. 원본이 사라지면 나중에 사용자가 문의했을 때 무엇을 입력했는지 확인할 수 없습니다.
개발자를 위한 메모: 기준 국가를 명시적 인자로 넘겨라
- 검증 함수가 어느 국가를 기준으로 하는지 인자로 받게 합니다. 규칙 안에 국가를 고정하면 국내와 국경 주문에 다른 규칙을 쓸 수 없습니다.
- 국가 차원마다 이름을 붙여 저장합니다. 결제 국가와 배송 국가가 같은 값이어도 각각 남겨야 나중에 바뀐 이유를 추적할 수 있습니다.
- 불일치를 오류가 아니라 상태로 다룹니다. 값이 다르다는 사실만 기록하고, 막을지 말지는 업무 규칙이 정하게 합니다.
- 안내 문구를 원인별로 나눕니다. 배송 불가와 형식 오류, 일시적 제한을 각각 다른 문구로 두면 사용자가 다음 행동을 알 수 있습니다.
- 긴 값을 시험 입력으로 고정해 둡니다. 화면을 새로 만들 때마다 같은 값으로 한 번 그려 보는 것이 가장 값싼 확인입니다.
다음 단계
지금 주문 화면에 국가 항목이 몇 개인지, 각각 무엇을 뜻하는지 적어 보세요. 이름을 붙일 수 없는 항목이 있다면 그 항목은 기준을 갖지 못한 것입니다. 국내와 국경 주문의 화면을 나눠 확인하려면 국가와 지역 디렉터리에서 여러 국가의 값 길이를 먼저 비교해 보는 편이 좋습니다.
이 글의 주문 예시와 국가 조합은 검증 기준을 설명하려고 지어낸 합성 데이터이며, 실제 거래 정보나 실제 배송 조건을 담고 있지 않습니다.