해외 주소 입력 폼: 회사명과 상세 주소를 끝까지 보존하는 설계

해외 배송 주소 폼은 도착 국가를 먼저 정하고, 지원하는 목적지에 맞는 입력란을 보여 주어야 합니다. 검색으로 주소를 찾지 못해도 직접 입력할 수 있어야 하며, 다음 단계로 넘어가기 전에 주소 전체를 확인할 수 있어야 합니다. 건물 검색에 성공했더라도 회사명, 층, 호수처럼 실제 배송에 필요한 정보가 빠져 있을 수 있기 때문입니다.

서비스가 어떤 정보를 받아야 하는지는 필드 요구사항을 정하는 폼 디자인 흐름에서 먼저 정할 수 있습니다. 주소 폼에서는 한 가지 질문이 더 필요합니다. 검색 제공업체가 모르는 정보까지 포함해, 고객이 목적지를 정확히 설명할 수 있나요?

입력란을 배치하기 전에 도착 국가부터 정하기

사용자의 현재 위치, 인터페이스 언어, 배송 목적지는 서로 다른 정보입니다. 런던에서 영어 화면을 사용하는 사람이 베를린의 스튜디오로 샘플을 보낼 수도 있습니다. 계정에 저장된 국가를 초깃값으로 활용할 수는 있지만, 실제 도착 국가는 화면에 보이고 쉽게 바꿀 수 있어야 합니다.

영국과 독일로 샘플 꾸러미를 배송하는 가상의 원단 공급업체를 생각해 보겠습니다. Lea는 베를린의 Common Thread Studio에 보낼 샘플을 주문합니다. 그런데 계정의 저장 국가는 영국입니다. 폼이 처음부터 영국 우편번호를 요구하면 Lea는 자신의 주소가 왜 맞지 않는지부터 알아내야 합니다. 국가에 따라 달라지는 입력란 앞에 ‘배송 국가’를 놓아 먼저 주소의 기준을 바로잡게 하세요.

이 단계에서 실제 배송 가능 지역도 알려 주세요. ‘이 국가로는 배송하지 않습니다’는 서비스 범위의 제한이고, ‘이 지역에서는 주소 검색을 사용할 수 없습니다’는 검색 기능의 제한입니다. 필요한 다음 행동이 다릅니다. 직접 입력은 두 번째 문제를 해결할 수 있지만, 첫 번째 제한까지 우회할 수 있는 것처럼 보여서는 안 됩니다.

HTML 자동완성 명세는 국가마다 행정구역 단계가 다름을 설명하고, 국가에 맞게 입력란과 순서를 조정하도록 안내합니다. 그렇다고 이 명세가 서비스의 지원 국가 목록이나 배송업체의 요구사항까지 정해 주지는 않습니다. 주소를 실제로 사용하는 운영·개발 담당자와 그 조건을 먼저 합의해야 합니다.

제출한 주소의 사용 방식에 맞게 입력 구조 정하기

배송업체 연동에 우편번호와 도시 값이 각각 필요하다면, 큰 텍스트 영역 하나로 받는 방식은 이후에 주소를 다시 나누는 문제를 만듭니다. 반대로 사람이 서신을 보내기 위해 주소 전체를 읽기만 한다면, 모든 줄을 고정된 구성요소로 잘게 나눌 필요가 없을 수 있습니다.

GOV.UK 주소 패턴도 이 차이를 구분합니다. 주소의 각 부분을 따로 사용해야 할 때는 여러 입력란이 유용하고, 따로 사용할 필요가 없다면 다양한 형식을 담는 텍스트 영역이 적합할 수 있습니다. 영국 주소 검색 안내에는 검색에서 누락된 주소와 해외 주소를 직접 입력하는 경로도 포함됩니다. 영국용 입력란을 모든 시장에 그대로 복사하기보다, 이런 선택의 근거를 서비스에 적용하세요.

샘플 공급업체에는 국가별 구성요소를 나누되 상세 주소를 더 적을 수 있는 폼을 사용합니다. 검색, 브라우저 자동완성, 직접 입력 중 어느 방식으로 채웠든 고객이 최종 값을 수정할 수 있어야 합니다. 직접 입력 화면에서만 회사명이나 호수가 빠지는 식으로 기능을 줄이지 마세요.

도로명 입력란에 담기지 않는 정보까지 수용하기

W3C의 국제 주소 형식 안내를 보면 건물 번호, 도로명, 도시, 주를 전 세계 공통 필수 항목으로 볼 수 없는 이유를 알 수 있습니다. 건물을 이름으로 식별하기도 하고, 하나의 구성요소가 여러 줄에 걸치기도 하며, 쓰는 순서도 다릅니다. 짧은 입력 마스크만으로 이런 차이를 해결할 수는 없습니다.

베를린 예제에서 Lea는 도로명과 도시 외에 ‘Common Thread Studio’와 ‘Hinterhof, 2. Etage’를 남겨야 합니다. 두 번째 문구는 안뜰과 층에 관한 정보이며, 수취인이 제공한 원래 표현을 유지해야 합니다. 예제의 도로명 주소는 ‘Beispielstraße 18’, 우편번호와 도시는 ‘10115 Berlin’입니다.

지원하는 지역에 맞는 설명과 함께 선택 사항인 상세 주소 입력란을 눈에 보이게 두세요. 설명 없는 ‘주소 2’보다 ‘동·호수, 층 등 상세 주소’처럼 용도를 드러내는 라벨이 이해하기 쉽습니다. 회사명을 자주 적어야 한다면 도로명 입력란에 억지로 넣게 하지 말고, 회사명이라는 별도 위치를 알아볼 수 있게 만드세요.

필수 여부는 선택한 국가와 배송 서비스가 실제로 요구하는 정보에 따라야 합니다. 처음 지원한 국가에서 필요했다는 이유만으로 모든 국가에 주나 우편번호를 요구해서는 안 됩니다. 반대로 빨간 오류를 없애려고 배송에 꼭 필요한 항목을 선택 사항으로 바꾸어서도 안 됩니다. 폼의 요구사항과 배송 조건 사이의 불일치를 해결해야 합니다.

검색 결과를 완성된 주소가 아닌 입력의 출발점으로 쓰기

Lea가 예제 도로명을 검색하고 일치하는 건물을 선택하면 주소 상세 화면으로 이동합니다. 이때 전달할 의미는 ‘찾은 정보를 확인하고 부족한 내용을 추가하거나 수정하세요’입니다. 주소를 확인할 기회 없이 곧바로 결제 단계로 넘어가서는 안 됩니다.

선택한 국가를 계속 표시하고, 검색 결과의 구성요소는 알맞은 입력란에 넣으세요. 스튜디오와 층 정보도 수정할 수 있어야 합니다. 결과를 선택하기 전에 Lea가 층을 입력했다면, 검색 제공업체가 호수 정보를 주지 않았다는 이유로 빈 값으로 덮어쓰지 마세요. 응답에 정보가 없다는 사실은 고객이 입력한 내용을 지우라는 뜻이 아닙니다.

선택한 결과와 기존 내용이 충돌하는 경우도 있습니다. 폼에는 ‘Hinterhof, 2. Etage’가 있는데 새 검색 결과가 앞쪽 건물을 가리킨다고 해 보겠습니다. 영향을 받는 주소 부분 옆에 차이를 보여 주고 Lea가 해결하게 하세요. 서로 다른 주소 조각을 자동으로 합치면, 그럴듯해 보이지만 아무도 선택하지 않은 주소가 만들어질 수 있습니다.

설계에서는 고객이 입력한 정보와 검색이 제안한 정보를 구분해야 합니다. 이 구분은 사용자의 결정에 영향을 주기 전까지 구현 메모로 남겨도 됩니다. 화면에 제공업체의 내부 ID나 신뢰도 점수를 노출할 필요는 없습니다. 대신 건물이 바뀌었는지, 호수가 빠졌는지, 우편번호가 달라졌는지처럼 사용자가 판단해야 할 결과를 보여 주세요.

검색 결과가 없거나 검색이 멈춰도 직접 입력으로 이어 주기

검색이 실패하기 전부터 검색 영역 옆에 ‘주소 직접 입력’을 제공하세요. 자기 주소가 검색되지 않는다는 사실을 아는 고객이 일부러 실패한 검색을 한 번 거쳐야만 폼을 사용할 수 있어서는 안 됩니다.

세 가지 결과를 구분해 안내하세요. 검색은 끝났지만 일치하는 주소가 없으면 ‘주소를 찾지 못했습니다. 검색어를 확인하거나 직접 입력해 주세요’라고 말할 수 있습니다. 요청 자체가 실패했다면 ‘주소 검색을 사용할 수 없습니다. 다시 시도하거나 직접 입력해 주세요’가 맞습니다. 배송 불가 국가에는 앞서 정한 별도의 서비스 범위 안내가 필요합니다.

직접 입력으로 전환할 때는 선택한 국가와 이미 확인한 주소 구성요소를 보존하세요. 자유롭게 적은 검색어를 안전하게 나눌 수 없다면 참고할 수 있도록 그대로 보여 주고, 모든 검색어를 도로명이라고 추측하지 마세요. Lea가 입력한 우편번호가 어느새 회사명 입력란에 들어가 있어서는 안 됩니다.

직접 입력한 주소도 검색으로 채운 주소와 같은 최종 확인 단계에 도달해야 합니다. 이 공급업체의 예제 규칙은 배송업체가 지원하는 목적지라면 완성된 직접 입력 주소로 계속 진행할 수 있다는 것입니다. 실제 운영상 별도의 검증이 반드시 필요하다면 남은 확인 사항과 해결 경로를 설명하세요. ‘계속’ 버튼을 영원히 비활성화해 두는 것만으로는 Lea가 작업을 마칠 방법을 알 수 없습니다.

국가를 바꿀 때 어떤 입력을 보존할지 정하기

이번에는 Lea가 스튜디오와 층 정보를 입력한 뒤에야 국가가 영국으로 되어 있음을 발견했다고 해 보겠습니다. 독일로 바꾸면 해당 국가에 맞는 라벨과 필수 조건이 갱신되어야 합니다. 지금까지 입력한 내용을 조용히 지우거나, 숨겨진 영국 검색 결과를 새 목적지에도 유효한 값처럼 남겨서는 안 됩니다.

수취인과 회사명처럼 분명히 계속 사용할 수 있는 정보는 유지하고, 이전 검색 결과는 새 국가에서 아직 확인되지 않은 상태로 바꾸세요. 재검토가 필요한 주소 항목을 표시합니다. 사라지는 입력란의 기존 텍스트는 현재 폼 작업 안에서 복구할 수 있게 보관하되, 새 주소에서 유효하고 눈에 보이는 위치가 정해지기 전에는 제출되는 목적지에 포함하지 않습니다.

‘국가를 독일로 변경했습니다. 아래 주소 정보를 확인해 주세요’처럼 짧게 안내할 수 있습니다. 변경 때문에 실제로 입력 내용을 교체해야 한다면 적용 전에 무엇이 사라지는지 설명하고 되돌릴 방법을 제공하세요. 영향이 없는 국가 변경마다 확인 창을 띄울 필요는 없습니다. 실제 손실이나 중요한 의미 변화가 있을 때만 작업을 중단시키는 확인을 사용하세요.

브라우저 자동완성에도 같은 원칙이 적용됩니다. 저장된 주소의 국가가 폼 구조를 바꿀 수 있습니다. 구현 순서는 도착 국가를 먼저 정한 다음, 그 국가에 종속된 입력란을 검증하는 방식이어야 합니다. 관련 없는 오류를 잠깐 표시한 뒤 입력란을 다시 배치하는 흐름을 피하세요.

실제로 사용할 주소 전체를 보여 주기

최종 확인 영역에는 수취인, 회사, 층이나 호수, 도로명, 도시, 해당 국가에서 사용하는 우편번호, 국가가 알맞은 순서로 보여야 합니다. 이제 Lea는 ‘Hinterhof, 2. Etage’가 남아 있는지 확인할 수 있습니다. 도로명 옆의 초록색 체크 표시만으로는 알 수 없던 정보입니다.

주소 검증이 수정을 제안한다면 입력한 주소와 제안 주소를 함께 보여 주고, 의미 있는 차이를 텍스트로 설명하세요. 고객이 직접 수정하거나 적절한 제안을 받아들일 수 있어야 합니다. Google Address Validation 안내는 수정이 필요한 경우와 확인이 필요한 경우를 구분합니다. 이런 신호는 해당 제공업체의 응답을 제품의 판단에 활용하기 위한 근거입니다.

형식 수정 제안이 배송 가능성을 보증하지는 않습니다. 따라서 이 공급업체의 확인 화면은 ‘주소 정보 확인’과 선택한 배송 서비스의 이용 가능 여부를 구분합니다. 주소가 바뀌면 그 주소에 따라 달라지는 배송 옵션이나 요금도 다시 확인하고, 주문을 확정하기 전에 변경 내용을 보여 주세요.

Pixso에서 누락된 층 정보를 따라가는 흐름 만들기

Pixso에서 Lea의 사례를 중심으로 작은 배송 주소 프로젝트를 만드세요. 재사용 가능한 입력 필드와 Auto Layout으로 주소 영역을 구성하고, 층 정보가 없는 건물 검색 결과, 직접 입력을 마친 상태, 국가 변경 후 재검토 상태, 최종 배송 주소 미리보기 프레임을 만듭니다. Pixso의 프로토타이핑 흐름에서는 프레임 연결, 프로토타입 검토와 댓글을 활용할 수 있습니다.

직접 입력 동작을 주소 완성 경로에 연결하고, 국가 변경 동작은 재검토 상태에 연결하세요. 모든 프레임에서 스튜디오와 층 정보가 동일하게 유지되어야 합니다. 국가 변경 프레임 옆에는 어떤 숨겨진 값을 제출에서 제외해야 하는지 설계 메모를 남기세요. 주소 처리 규칙은 지금 설계하는 애플리케이션의 규칙이며, 프로토타입은 그 결과가 화면에서 어떻게 드러나는지 논의하는 데 쓰입니다.

검토자에게 구체적인 과제를 주세요. 저장 국가가 잘못되어 있고 주소 검색도 사용할 수 없는 상태에서, 안뜰과 층 정보를 포함해 스튜디오로 샘플을 보내게 합니다. 어디에서 국가를 바꾸려고 하는지, 최종 라벨을 보고 목적지를 설명할 수 있는지 관찰하세요. 혼란이 생긴 상태 옆에 댓글로 피드백을 기록합니다.

Pixso에서 배송 주소 입력 흐름을 설계해 보세요.