이메일 검증의 합리적인 출발점

현실적인 기본 패턴

RFC 5322 문법을 폭넓게 구현한 이메일 정규식은 중첩 주석, 따옴표로 감싼 문자열, 도메인 리터럴 같은 드문 형식까지 다루느라 매우 길어져. 비 ASCII 국제화 이메일 주소는 EAI 규격인 RFC 6530과 RFC 6531 계열까지 살펴야 해. 이런 검증기를 직접 다시 만들기보다 다음처럼 서비스의 허용 범위에 맞는 기본 패턴에서 시작해.

^[\w.+-]+@[\w-]+\.[\w.-]+$

왼쪽부터 읽으면 다음과 같아.

[\w.+-]+ — 단어 문자, 점, 더하기 기호, 하이픈으로 된 로컬 부분
@ — 글자 그대로의 @
[\w-]+ — 점을 제외한 도메인 레이블
\. — 글자 그대로의 점
[\w.-]+ — 점과 하이픈을 허용한 나머지 도메인 부분

이 패턴이 잡아내는 오류

@나 점 뒤의 도메인이 빠진 경우, 주소에 공백이 든 경우처럼 명백하게 이메일 모양이 아닌 입력을 걸러 내. 서비스가 실제로 허용하려는 주소 예시를 테스트 집합으로 삼아 범위를 조정해.

이 패턴만으로는 해결할 수 없는 것

따옴표로 감싼 로컬 부분인 "hello world"@example.com처럼 드물지만 규격상 가능한 주소
user@[192.168.1.1] 같은 IP 리터럴 도메인
유저@한국.kr 같은 국제화 주소
주소가 실제로 존재하고 메일을 받을 수 있는지 여부

주소가 실제로 작동하는지는 확인 메일을 보내야 알 수 있어. 정규식은 문자열의 모양을 검사할 뿐 전달 가능성을 증명하지 않아.

브라우저에서는 기본 기능도 활용해

웹 폼이라면 <input type="email" required>로 브라우저의 기본 이메일 검증을 먼저 사용할 수 있어. 서버에서도 서비스 정책에 맞게 다시 검증하고, 최종 확인은 메일 발송으로 해.

Code

이메일 검증·python

import re

EMAIL = re.compile(r'^[\w.+-]+@[\w-]+\.[\w.-]+$')

# 허용할 예시
bool(EMAIL.fullmatch('hi@example.com'))            # True
bool(EMAIL.fullmatch('hi+tag@example.co.kr'))      # True
bool(EMAIL.fullmatch('user.name@sub.domain.org'))  # True

# 거부할 예시
bool(EMAIL.fullmatch('no-at-sign'))       # False
bool(EMAIL.fullmatch('@no-local'))        # False
bool(EMAIL.fullmatch('hi@example'))       # False — 점 뒤 도메인이 없음
bool(EMAIL.fullmatch('hi @example.com'))  # False — 공백이 있음

# 본문에서 이메일 후보 찾기 — 전체 문자열 앵커 없음
EMAIL_FIND = re.compile(r'[\w.+-]+@[\w-]+\.[\w.-]+')
re.findall(EMAIL_FIND, 'reach me at hi@pippa.dev or admin@cwk.io')
# ['hi@pippa.dev', 'admin@cwk.io']

Exercise

코드베이스의 이메일 검증기를 찾아 이 기본 패턴과 비교해 봐. 더 복잡한 부분이 서비스에서 실제로 허용하거나 거부해야 하는 사례를 다루는지 테스트로 확인해. 근거가 없는 복잡성은 줄이고, 전달 가능성 확인은 메일 발송 단계에 맡겨.