이메일 정규식의 함정: 왜 완벽한 패턴은 없는가

사용자로부터 이메일 주소를 입력받을 때 정규식(Regex)은 필수적인 도구입니다. 하지만 "완벽한 이메일 정규식"을 찾으려 할수록 코드는 복잡해지고, 정작 유효한 사용자의 이메일을 거부하는 부작용이 생기곤 합니다.

1) 왜 이메일 정규식은 복잡한가

이메일 주소의 표준 규격은 RFC 5322(및 관련 표준들)에 정의되어 있습니다. 이 표준을 100% 충족하는 정규식은 수백 줄에 달할 정도로 거대하며, 현실적으로 코드에 그대로 붙여넣기 어렵습니다.

표준에서 허용하지만 우리가 흔히 무시하는 것:
- user+filter@example.com (플러스 태깅)
- user.name@sub.example.com (다중 서브도메인)
- "very.common.non-standard"@example.com (따옴표가 포함된 로컬 파트)
- .museum, .travel 같은 신규 GTLD (4글자 이상의 도메인 확장자)

많은 개발자가 범용적으로 사용하는 패턴들이 다음과 같은 문제를 일으킵니다.

도메인 확장자를 2~3글자로 제한: \.[a-z]{2,3}$ 처럼 작성하면 .info, .online, .center 같은 최신 도메인을 사용하는 유효한 이메일을 차단하게 됩니다.
특수문자 차단: +, -, _는 이메일 로컬 파트에서 매우 흔하게 쓰입니다. 이를 허용하지 않으면 많은 개발자 사용자층을 잃을 수 있습니다.
대소문자 구분: 표준상 도메인 파트는 대소문자를 구분하지 않지만, 정규식에서 [a-z]만 허용하고 i 플래그를 빼먹으면 대문자가 포함된 도메인을 걸러내지 못합니다.

정규식으로 모든 것을 완벽하게 검증하려 하지 마세요. 정규식의 역할은 **"오타로 인한 명백한 잘못된 형식"**을 걸러내는 것으로 충분합니다.

정규식은 형식(Format)만 확인합니다. 해당 이메일 주소가 실제로 존재하는지, 사용자가 소유하고 있는지는 알 수 없습니다.

사용자 경험(UX) 관점에서 가장 나쁜 것은 **"내 이메일이 분명히 맞는데도 사이트가 틀렸다고 우기는 상황"**입니다. 정규식은 가급적 너그럽게 유지하고, 실제 유효성은 인증 메일을 통해 확인하는 것이 현대적인 웹 개발의 정석입니다.

다양한 패턴을 테스트해 보고 싶다면 Regex Tester에서 실제 이메일 샘플을 넣고 실험해 보세요.