핵심 요약
입력 검증 정규식의 핵심은 "완벽하게"가 아니라 실용적으로다. 이메일을 RFC 5322 완벽 준수로 잡으려다 정상 주소를 막는 것보다, 느슨하게 형식만 확인하고 실제 확인은 인증 메일로 하는 게 낫다. 자주 쓰는 검증 패턴을 정리한다.
1. 이메일 — 느슨하게가 정답
^[^\s@]+@[^\s@]+\.[^\s@]+$"@ 앞뒤에 공백 아닌 게 있고, 뒤에 점과 도메인이 있다" 정도면 충분하다. 진짜 유효성은 인증 메일 발송으로 확인한다.
2. URL
^https?:\/\/[^\s/$.?#].[^\s]*$http/https로 시작하는지만 본다. 더 엄격히 하면 정상 URL을 막기 쉽다. 브라우저 환경이면 new URL(str)의 예외로 검증하는 게 더 견고하다.
3. 비밀번호 강도 — 전방탐색 활용
// 8자 이상, 영문·숫자·특수문자 각 1개 이상
^(?=.*[A-Za-z])(?=.*\d)(?=.*[^A-Za-z0-9]).{8,}$(?=...)는 "그 위치 뒤에 이런 게 있다"만 확인하고 커서를 안 옮기는 전방탐색이다. 조건을 AND로 겹칠 때 쓴다.
4. 날짜·전화번호
| 대상 | 패턴 |
|---|---|
| YYYY-MM-DD | ^\d{4}-(0[1-9]|1[0-2])-(0[1-9]|[12]\d|3[01])$ |
| 휴대폰 | ^01[016-9]-?\d{3,4}-?\d{4}$ |
| 사업자번호 | ^\d{3}-\d{2}-\d{5}$ |
날짜는 정규식으로 월·일 범위까지는 잡되, 2월 30일 같은 실제 유효성은 날짜 라이브러리로 확인한다.
5. 함정
- 정규식으로 "완벽한 이메일 검증"은 불가능에 가깝다 — 느슨하게 + 인증 메일
- 사용자 입력을 서버에서 반드시 다시 검증(프론트 검증은 우회 가능)
- 복잡한 전방탐색 남발은 유지보수를 해친다 — 조건이 많으면 코드로 나눠 검증
자주 묻는 질문
이메일 정규식은 왜 느슨하게 쓰나요?
RFC를 완벽히 따르는 정규식은 수백 자에 달하고, 그래도 a@b.co.kr 같은 정상 주소를 실수로 막기 쉽습니다. 형식만 가볍게 확인하고 실제 존재 여부는 인증 메일로 검증하는 게 현업 표준입니다.
전방탐색 (?=...)이 정확히 뭘 하나요?
"현재 위치 뒤에 이 패턴이 존재하는가"만 검사하고 매칭 위치는 그대로 둡니다. 덕분에 "영문도 있고 숫자도 있고 특수문자도 있다"처럼 순서와 무관한 여러 조건을 한 정규식에 AND로 겹칠 수 있습니다.
프론트에서 검증했으면 서버 검증은 생략해도 되나요?
절대 안 됩니다. 프론트 검증은 UX용이고, 공격자는 API를 직접 호출해 우회합니다. 보안·데이터 정합성은 서버 검증이 최종 방어선입니다.
댓글 0