가입 폼에 주소를 넣는 칸 하나를 만드는 데도 생각할 것이 많습니다. 너무 좁게 막으면 실제 사용자의 주소를 거절하고, 너무 넓게 열면 뒤에서 문제가 생깁니다. 이 글은 주소 형식의 규칙과 그 규칙이 실제 서비스에서 어떻게 다뤄지는지를 살펴봅니다.
이메일 주소는 어떻게 두 부분으로 나뉘나요?
주소는 마지막 골뱅이 기호를 기준으로 왼쪽과 오른쪽으로 나뉩니다. 왼쪽은 편지함 이름이고 오른쪽은 영역 이름입니다. 나눌 때 기준이 되는 것은 첫 번째 골뱅이가 아니라 마지막 골뱅이입니다. 왼쪽에 골뱅이가 들어갈 수 있는 형식도 있으므로, 첫 번째에서 자르면 주소를 잘못 해석합니다.
오른쪽 영역 이름은 점으로 나뉜 여러 조각으로 이뤄지고, 각 조각은 글자와 숫자와 붙임표로 시작하고 끝날 수 있습니다. 영역 이름은 대소문자를 구분하지 않으므로 저장할 때는 소문자로 맞춰 두는 편이 안전합니다. 반면 왼쪽 편지함 이름은 구분하는 것이 원칙이지만, 실제로는 구분하지 않고 처리하는 서비스가 많습니다. 이 차이를 모르고 저장하면 같은 사람이 두 계정으로 들어옵니다.
무엇이 길이를 제한하나요?
제한은 여러 층에서 각각 다르게 걸립니다. 형식 규칙 자체가 두는 상한이 있고, 그 위에 실제 전달 경로가 두는 상한이 따로 있습니다. 형식이 허용하는 최대치를 그대로 받아들이는 서비스는 드물고, 실무에서는 그보다 훨씬 짧은 길이를 기준으로 삼는 경우가 많습니다.
조각마다의 상한과 전체 길이의 상한이 따로 있다는 점도 중요합니다. 조각이 아무리 짧아도 전체가 길면 거절되고, 전체가 짧아도 한 조각이 길면 역시 거절됩니다. 두 상한을 모두 확인해야 하는 이유입니다.
편지함 이름 쪽도 상한이 있습니다. 아주 긴 이름을 허용하는 서비스가 있지만, 그런 주소를 받아 두면 다른 시스템으로 옮길 때 잘려 나가는 일이 생깁니다.
길이 문제는 입력 화면에서 가장 먼저 드러납니다. 칸의 최대 길이를 짧게 잡아 두면, 규칙상 통과해야 할 주소가 애초에 입력되지 못합니다. 반대로 화면에서만 막고 요청 처리에서 확인하지 않으면, 화면을 거치지 않은 요청은 그대로 통과합니다. 두 곳의 기준이 다르면 어느 쪽이 맞는지 알 수 없는 문의가 들어옵니다.
저장 공간의 크기도 기준이 됩니다. 데이터베이스 칸의 길이를 짧게 잡아 두면, 상한 안에 들어오는 주소도 저장 단계에서 잘리거나 거절됩니다. 나중에 칸을 늘리는 일은 이미 쌓인 자료 때문에 생각보다 번거로우므로, 처음 정할 때 여유를 두는 편이 낫습니다.
표준이 허용해도 왜 거절되나요?
표준은 받아들여야 할 최소 범위를 정할 뿐, 모든 형식을 다 받으라고 요구하지는 않습니다. 그래서 표준에 맞는 주소도 특정 서비스의 가입 폼에서는 거절될 수 있습니다. 사용자 입장에서는 이유를 알 수 없는 거절입니다.
거절되는 흔한 자리는 따옴표로 묶인 이름, 드물게 쓰이는 특수 문자, 연속된 점, 붙임표로 시작하는 조각입니다. 이런 형식을 실제로 쓰는 사람은 많지 않지만, 그 사람에게는 유일한 주소입니다. 반대로 지나치게 넓게 받으면 나중에 발송 단계에서 조용히 실패합니다.
그래서 검증을 두 단계로 나누는 편이 좋습니다. 입력 단계에서는 명백한 오타만 걸러 내고, 실제로 편지를 보내는 단계에서 도달 가능 여부를 확인합니다. 형식만으로 도달 가능성을 판단할 수는 없기 때문입니다.
대소문자와 국제화 주소는 어떻게 다루나요?
영역 이름은 비교할 때 소문자로 맞춥니다. 편지함 이름은 원칙적으로 구분하지만 실제로는 그렇지 않은 서비스가 많으므로, 우리가 새로 저장하는 값은 입력 그대로 두되 비교할 때는 양쪽을 같은 규칙으로 맞춥니다.
국제화 주소는 영역 이름에 라틴 문자 이외의 문자가 들어가는 주소입니다. 이 형식은 저장할 때 별도 표기로 바꾸는 규칙이 있어서, 사람이 보는 모습과 컴퓨터가 다루는 모습이 다릅니다. 화면에는 사람이 읽는 모습으로 보여 주고, 저장과 비교는 바뀐 표기로 하는 것이 원칙입니다. 이 변환을 빠뜨리면 같은 주소가 두 벌로 저장됩니다.
우리 도구에서 길이 한계를 시험하는 방법
임시 메일에서 주소를 하나 만들고, 만들어진 주소의 길이와 조각 구성을 직접 세어 보세요. 그다음 가입 폼에 그대로 넣어 보고, 같은 주소를 대소문자를 바꿔 다시 넣어 봅니다. 두 번째 입력이 새 계정으로 처리되면 그 폼은 대소문자 비교 규칙이 빠져 있는 것입니다.
여기서 만드는 주소는 형식 확인과 수신 시험만을 위한 것이며, 실제 사람의 신원을 나타내지 않습니다.
여러 지역을 대상으로 한다면 국가별 주소 형식에 나오는 표기 차이도 함께 확인해 보세요. 지역에 따라 우편 표기와 결합되는 방식이 달라서, 하나의 규칙으로 모두 덮으려 하면 어딘가에서 어긋납니다.
개발자를 위한 메모: 검증 규칙을 정할 때
- 정규식 하나로 모든 것을 해결하려 하지 않습니다. 마지막 골뱅이를 찾고, 좌우를 따로 검사하고, 길이를 따로 확인하는 편이 읽기도 고치기도 쉽습니다.
- 길이 검사는 입력받은 문자열이 아니라 바뀐 표기를 기준으로 합니다. 사람이 보는 길이와 저장되는 길이가 다를 수 있습니다.
- 공백을 먼저 다듬습니다. 앞뒤 공백과 줄바꿈이 섞여 들어오는 경우가 생각보다 많습니다.
- 거절 문구는 한 곳에서 만듭니다. 화면과 요청 처리 양쪽에서 각자 문구를 만들면 서로 달라집니다.
- 너무 긴 입력은 잘라서 저장하지 않습니다. 잘린 주소는 도달할 수 없는 주소가 되고, 나중에 원인을 찾기 어렵습니다.
- 형식 검사가 통과했다고 발송까지 성공했다고 보지 않습니다. 두 단계는 다른 문제입니다. 다음 단계의 점검 항목은 트랜잭션 메일 체크리스트에 정리해 두었습니다.
다음 단계
우리 가입 폼이 어떤 형식을 거절하는지 시험 데이터 목록을 만들어 보세요. 통과해야 할 주소와 거절해야 할 주소를 나란히 두고 돌려 보면, 지금 규칙이 너무 좁은지 너무 넓은지가 한눈에 드러납니다. 그 뒤에 임시 메일에서 만든 주소로 실제 발송까지 한 번 확인해 보시길 권합니다.