Regex greedy vs lazy 차이: 왜 너무 많이 매칭될까
정규식을 작성할 때 .*가 생각보다 너무 많이 잡히는 경험은 흔합니다. 이 문제의 핵심은 greedy와 lazy 동작 차이입니다. 정규식 엔진은 기본적으로 가능한 한 많이 먹으려는 탐욕적(greedy) 동작을 하기 때문에, 의도보다 넓은 범위를 매칭할 수 있습니다.
1) greedy란 무엇인가
.* 같은 패턴은 가능한 한 긴 범위를 먼저 잡으려 합니다. 예를 들어 <div>one</div><div>two</div>에 <div>.*</div>를 적용하면 첫 <div>부터 마지막 </div>까지 한 번에 잡아버릴 수 있습니다. 이것이 greedy 동작입니다.
2) lazy란 무엇인가
반대로 .*?처럼 물음표를 붙이면 가능한 한 짧게 매칭하려고 시도합니다. 같은 예제에서 <div>.*?</div>는 첫 번째 </div>까지만 잡으려 합니다. 그래서 의도한 최소 범위를 찾고 싶을 때 lazy 수량자가 도움이 됩니다.
3) 왜 중요한가
문제는 단순히 결과가 많이 잡히는 것만이 아닙니다. 탐욕적인 패턴은 입력이 길어질수록 백트래킹 비용이 커져서 성능 문제를 유발할 수 있습니다. 특히 사용자 입력이나 긴 로그 텍스트를 대상으로 쓰는 정규식에서는 lazy 여부와 문자 클래스 제한이 매우 중요합니다.
4) 예제로 보는 차이
텍스트:
[id:100][id:200][id:300]
패턴 \\[id:.*\\]는 첫 [부터 마지막 ]까지 한 번에 잡을 수 있습니다.
패턴 \\[id:.*?\\]는 각 블록을 더 짧게 매칭합니다.
의도한 결과가 “블록 하나씩”이라면 두 번째가 더 적합합니다.
5) lazy가 항상 정답은 아니다
lazy를 붙였다고 해서 모든 문제가 해결되는 것은 아닙니다. 여전히 범위가 넓으면 성능이 안 좋을 수 있고, 입력 구조가 명확하다면 .*?보다 더 구체적인 문자 클래스를 쓰는 편이 안전합니다. 예를 들어 [^\\]]+처럼 닫는 괄호 전까지만 허용하는 방식이 더 예측 가능합니다.
6) 실무에서 자주 보는 실수
- HTML 비슷한 문자열을
.*로 파싱하려 함 - 로그 전체를 한 번에 잡는 패턴 사용
- lazy와 greedy 차이를 모르고 캡처 범위가 이상하다고만 생각
- 성능 문제를 패턴 구조보다 엔진 문제로 오해
이런 문제는 작은 샘플에서 안 보이다가 운영 데이터에서 커지는 경우가 많습니다.
7) 더 안전한 대안
가능하면 .* 자체를 먼저 의심하는 습관이 좋습니다. 예를 들어 태그 안 텍스트를 찾고 싶다면 .*?도 한 방법이지만, 실제로는 태그 닫힘을 제외한 문자만 허용하는 식으로 더 좁히는 편이 좋습니다. 입력 구조가 명확할수록 구체적인 문자 클래스가 성능과 정확도 모두에서 유리합니다.
8) 백트래킹이 왜 문제인가
정규식 엔진은 패턴이 맞지 않을 때 가능한 조합을 되돌아가며 다시 시도합니다. 이 과정이 많아지면 특정 입력에서 매우 느려질 수 있습니다. 특히 (.*)+처럼 중첩된 탐욕 패턴은 작은 테스트에서는 멀쩡해 보여도 긴 문자열에서 급격히 느려질 수 있습니다. 그래서 lazy 여부뿐 아니라 패턴 구조 자체를 단순하게 유지하는 것이 중요합니다.
9) 디버깅 순서
- 현재 패턴이 greedy인지 확인
- lazy 수량자(
*?,+?) 적용 시 결과 비교 - 가능하면 문자 클래스로 범위를 제한
- 긴 입력에서 성능 문제까지 같이 확인
10) 체크리스트
.*를 정말 써야 하는가- 최소 범위 매칭이 목적이라면 lazy가 더 적합한가
- 닫는 구분자나 허용 문자 클래스로 좁힐 수 있는가
- 긴 입력에서도 백트래킹이 과하지 않은가
11) 관련 도구
Regex Tester에 greedy와 lazy 패턴을 각각 넣고 결과를 비교해 보면 차이가 바로 드러납니다. 단순 매칭 결과뿐 아니라, 패턴을 더 구체적으로 줄일 수 있는지도 함께 보는 것이 좋습니다.