Regex 빠르게 설계하는 실무 흐름
정규식은 강력하지만 과하게 복잡해지면 유지보수가 어려워집니다. 실무에서는 "최소 규칙으로 정확히 매칭"하는 전략이 중요합니다. 한 번에 완벽한 패턴을 만들려 하기보다, 입력 샘플을 기준으로 조금씩 강화하는 방식이 훨씬 안전합니다.
1) 먼저 입력 샘플을 모으기
- 정상 케이스 3~5개
- 실패해야 하는 케이스 3~5개
- 경계값(빈 문자열, 아주 긴 문자열, 공백 포함 등)
- 실제 서비스 로그에서 나온 예시를 우선 사용
2) 규칙을 단계적으로 쌓기
- 가장 단순한 형태부터 매칭
- 예외 케이스를 추가하며 점진 강화
- 불필요한 그룹/백트래킹 제거
예시: 주문번호 ORD-2026-000123만 매칭하려면
^ORD-\d{4}-\d{6}$
3) 플래그 활용
g: 전체에서 반복 매칭i: 대소문자 무시m: 여러 줄 모드s: 줄바꿈 포함 매칭이 필요한 경우 사용
4) 성능 주의
.*같은 탐욕 패턴은 과도한 백트래킹을 유발할 수 있습니다.- 가능한 경우 구체적인 문자 클래스를 사용하세요.
- 입력 길이가 긴 경우 최악의 성능을 가정하고 테스트하세요.
5) 바로 써보기
Regex Tester에서 패턴/플래그/텍스트를 나눠 입력하고 결과를 바로 확인하세요.
6) 디버깅 팁
- 캡처 그룹을 최소화하고 필요할 때만 사용
- 정규식에 주석이 없다면 단계적으로 나누어 테스트
- 입력이 너무 길면 부분 문자열로 축소
실제 장애는 "매칭이 안 된다"보다 "가끔 매우 느리다" 형태로 자주 나타납니다. 사용자 입력을 그대로 받는 검증 패턴에서는 ReDoS 가능성도 고려해야 합니다. 로그인, 회원가입, 검색처럼 공개 입력을 받는 곳일수록 복잡한 패턴은 보수적으로 다루는 편이 좋습니다.
7) 실무 예시
이메일, 주문번호, 파일명 같은 값은 RFC 전체를 완벽히 구현하기보다 서비스에서 허용할 규칙을 먼저 정의하는 편이 좋습니다. 예를 들어 주문번호가 ORD-2026-000123 형식으로만 들어온다면 그 형식만 정확히 매칭하면 됩니다. 범용성을 과하게 추구하면 패턴은 복잡해지고 유지 보수는 어려워집니다.
8) 체크리스트
- 패턴이 과도하게 복잡하지 않은가?
- 플래그(g/i/m)가 의도대로 설정되었는가?
- 최악의 입력에서도 성능 문제가 없는가?
- 허용할 형식을 문서화했는가?
9) 추가 예시
- 이메일 검증은 과도하게 복잡해지지 않게 단순화합니다.
- 로그 파싱은 작은 캡처 그룹으로 시작합니다.
- 사용자 입력 검증은 가능한 서버 측 스키마 검증과 함께 사용합니다.