이메일 주소에 대해 우리가 굳게 믿고 있는, 사실은 틀린 것들

이메일 검증, 다들 한 번쯤 틀려봤죠

회원가입 폼을 만들 때 "이메일 주소가 제대로 된 형식인지" 검사하는 코드, 한 번쯤은 짜보셨을 거예요. 그리고 십중팔구 인터넷에서 길고 무시무시하게 생긴 정규식(특정 문자 패턴을 검사하는 규칙) 하나를 복사해다 붙였을 거고요. 그런데 이메일 주소라는 게 우리가 생각하는 것보다 훨씬 더 이상하고 복잡한 녀석이라서, 그 검증 코드가 멀쩡한 사용자를 쫓아내고 있을 가능성이 꽤 높습니다.

오늘은 개발자들이 이메일에 대해 "당연히 이렇겠지" 하고 믿지만 실제로는 틀린 것들을 하나씩 풀어볼게요. 이건 오래전부터 "프로그래머가 이메일에 대해 믿는 거짓말들"이라는 주제로 계속 회자되는 클래식 주제이기도 해요.

우리가 잘못 알고 있는 것들

"점(.)이나 플러스(+)는 못 들어가겠지" — 들어갑니다. hong.gildong@example.com처럼 점이 들어간 주소는 너무 흔하고요, hong+shopping@gmail.com처럼 플러스 뒤에 태그를 붙이는 것도 완전히 합법이에요. 이게 뭐냐면, 지메일 같은 곳에서 +무언가를 붙여도 같은 받은편지함으로 도착하거든요. 그래서 사람들이 쇼핑몰마다 다른 태그를 붙여서 "어디서 내 메일이 새어나갔나"를 추적하는 데 써요. 그런데 검증 코드가 +를 막아버리면 이런 사용자들이 가입 자체를 못 합니다.

"대소문자는 똑같이 취급되겠지" — 반은 맞고 반은 틀려요. @ 뒤의 도메인 부분(example.com)은 대소문자를 구분하지 않습니다. 하지만 @ 앞의 로컬 파트는 규칙상 대소문자를 구분해도 되게 되어 있어요. 실제로 대부분의 메일 서버는 구분 안 하지만, 표준만 보면 Hong@과 hong@이 다른 사람일 수도 있다는 거죠. 그래서 안전하게는 사용자가 입력한 원본을 그대로 보관하되, 비교나 중복 체크는 소문자로 정규화하는 방식을 권합니다.

"한글이나 특수문자는 안 되겠지" — 됩니다. 국제화 이메일 주소(IDN/EAI) 표준 덕분에 홍길동@example.com 같은 유니코드 주소도 점점 현실이 되고 있어요. 따옴표로 감싸면 "매우 이상한 주소"@example.com처럼 공백이나 특수문자가 들어간 주소도 형식상으로는 유효하고요. 물론 실무에서 이런 극단적인 케이스까지 다 받아줄 필요는 없지만, "내 정규식이 모든 유효한 이메일을 안다"는 자신감은 버리는 게 맞아요.

"@는 딱 하나겠지" — 로컬 파트를 따옴표로 감싸면 그 안에 @가 또 들어갈 수도 있어요. 그래서 "마지막 @를 기준으로 자른다" 같은 단순 가정도 깨질 수 있습니다.

그래서 어떻게 검증해야 하냐면

핵심 결론은 의외로 단순해요. 이메일 형식을 정규식으로 빡빡하게 검증하려는 시도 자체를 내려놓는 것입니다. 업계에서 가장 널리 통하는 실용적 가이드는 이래요.

첫째, 형식 검사는 아주 느슨하게 하세요. "@가 하나라도 있고, 그 앞뒤로 글자가 있는가" 정도면 충분합니다. 그 이상으로 깐깐하게 막으면 진짜 사용자만 거를 위험이 커져요.

둘째, 진짜 유효성은 확인 메일을 보내서 검증하세요. 어차피 형식이 완벽해도 그 주소가 실제로 존재하는지, 본인 것인지는 정규식으로 알 수 없거든요. 가입 후 인증 링크를 보내는 게 형식 검증 100번보다 확실합니다.

한국 개발자에게는

국내 서비스도 글로벌 사용자를 받는 경우가 점점 늘고 있죠. + 태그를 막아둔 회원가입 폼, 도메인 길이를 짧게 제한해둔 입력 검증, 대소문자를 함부로 합쳐버리는 로직 — 이런 것들이 알게 모르게 가입 전환율을 깎아먹는 버그일 수 있어요. 특히 결제나 비밀번호 찾기처럼 이메일로 본인을 식별하는 흐름에서, 저장된 주소와 입력된 주소의 정규화 방식이 다르면 "분명히 가입했는데 계정을 못 찾는" 황당한 상황이 생기기도 합니다.

마무리

한 줄로 정리하면, 이메일은 정규식으로 완벽히 검증할 수 없으니, 형식은 느슨하게 받고 진짜 검증은 확인 메일로 하라는 거예요. 여러분 프로젝트의 회원가입 폼은 홍길동+태그@example.com 같은 주소를 무사히 통과시키나요? 한번 직접 넣어보면 의외의 발견이 있을지도 몰라요.