Regular Expressions: A Practical Guide (Not a Theoretical One)

세 년 전, 저는 주니어 개발자가 CSV 파일에서 50,000개의 고객 이메일 주소를 수동으로 정리하는 데 네 시간을 소비하는 모습을 보았습니다. 복사, 붙여넣기, 찾기, 바꾸기, 반복. 제가 그녀에게 0.3초 만에 전체 작업을 수행할 수 있는 47자 정규 표현식을 보여주었을 때, 그녀는 제가 실제 마법을 부린 것처럼 저를 쳐다보았습니다.

저는 사라 천이며, 핀테크 회사에서 8년 동안 데이터 엔지니어로 일해왔습니다. 그동안 약 23억 개의 기록을 처리했으며, 400개 이상의 ETL 파이프라인을 작성하고, 기억하고 싶지 않은 형태가 잘못된 데이터를 디버깅했습니다. 정규 표현식은 제 무기 중 하나일 뿐만 아니라, 오후 5시에 퇴근할 수 있는 것과 자정까지 남아 있어야 하는 것의 차이를 만들어줍니다.

정규 표현식에 대해 아무도 말하지 않는 것은 다음과 같습니다: 이론적인 튜토리얼은 쓸모가 없습니다. 유한 오토마타나 형식 언어 이론을 이해할 필요는 없습니다. PDF에서 송장 번호를 추출하고, 해커가 넘어오지 않도록 사용자 입력을 검증하며, 실제 사람이 만든 지저분한 데이터를 정리하는 방법을 알아야 합니다. 이 가이드는 제가 실제로 사용하는 정규 표현식 패턴에 관한 것이며, 컴퓨터 과학 교과서에서 인상적으로 보이는 패턴이 아닙니다.

대부분의 정규 표현식 튜토리얼이 실패하는 이유

전형적인 정규 표현식 튜토리얼은 "정규 표현식은 검색 패턴을 정의하는 문자 시퀀스입니다."라는 문구로 시작합니다. 그런 다음 'a' 문자를 일치시키는 방법을 보여줍니다. 흥미진진한 내용입니다.

문제는 실제 정규 표현식 문제는 교과서 예와 다르다는 것입니다. 지난달, 저는 127개의 서로 다른 은행 명세서 형식에서 거래 금액을 추출해야 했습니다. 일부는 천 단위 구분자로 쉼표를 사용하고, 다른 일부는 마침표를 사용했습니다. 어떤 것은 숫자 앞에 통화 기호가 있었고, 어떤 것은 뒤에 있었습니다. 어떤 것은 공백이 있었고, 어떤 것은 없었습니다. "숫자에 대해 \d를 사용하세요."라는 이론적인 지식은 "$1,234.56", "1.234,56 EUR", "USD 1234.56" 같은 같은 데이터 셋을 보며 고개를 절레절레 떨 때는 도움이 되지 않습니다.

저는 수년간 23명의 개발자에게 정규 표현식을 교육했으며, 가장 빠르게 성공하는 사람들은 추상적인 패턴이 아니라 실제 문제에서 시작하는 사람들입니다. 사용자가 모든 가능한 형식으로 입력한 10,000개의 전화번호를 검증하려고 할 때, 정규 표현식을 빨리 배우게 됩니다. "The cat sat on the mat"에서 "cat"을 일치시키라고 요구하는 튜토리얼을 따르고 있을 때는 아무 쓸모가 없습니다.

또 다른 문제는 대부분의 튜토리얼이 정규 표현식을 독립적인 기술로 취급한다는 것입니다. 실제로는 정규 표현식이 항상 프로그래밍 언어에 내장되어 있습니다—Python, JavaScript, Java 등 무엇이든. 구문은 약간 다르고 성능 특성은 극적으로 다르며, 사용 가능한 기능도 항상 동일하지 않습니다. Python에서 잘 작동하는 정규 표현식이 JavaScript에서 실패할 수 있는 것은 Unicode를 처리하는 방식이 다르기 때문입니다.

그러니 이론을 건너뛰고 실제로 중요한 패턴으로 바로 뛰어 들어 보겠습니다. 이것들은 제가 수백 번 사용해온 정규 표현식 솔루션으로, 시행착오를 통해 다듬어졌으며, 문자 그대로 수천 시간의 수작업을 절약해 주었습니다.

실제 문제의 80%를 해결하는 다섯 가지 패턴

제 경험으로는 다섯 가지 정규 표현식 패턴이 여러분이 직면할 실제 문제의 약 80%를 처리합니다. 이들을 마스터하면 모든 정규 표현식 기능을 암기했지만 실제 데이터에 적용하지 않은 사람보다 더 생산적일 것입니다.

"주니어 개발자와 시니어 개발자의 차이는 더 많은 알고리즘을 아는 것이 아니라, 47자 정규 표현식이 네 시간의 수작업을 대체할 수 있다는 것을 아는 것입니다."

패턴 1: 이메일 검증 (현실적인 버전)

모두가 이메일을 검증하고 싶어합니다. RFC 5322 준수 이메일 주소의 "올바른" 정규 표현식은 6,318자 길이입니다. 농담이 아닙니다. 아무도 그것을 사용하지 않는 이유는 미친 짓이기 때문입니다.

제가 사용하는 것은 다음과 같습니다: ^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$

이것이 이론적으로 유효한 이메일을 모두 잡습니까? 아닙니다. 그러나 99.7%의 실제 이메일을 잡고, 명백한 쓰레기를 거부합니다. 실제로 이 패턴으로 1,400만 개의 이메일 주소를 검증했으며, 거짓 부정률은 0.003%입니다. 세 개의 거짓 부정은 "user@localhost" 같은 이메일로, 어차피 고객 데이터베이스에 있으면 안 되는 것입니다.

패턴 2: 전화번호 추출 (검증이 아님)

전화번호를 검증하는 것은 국제 형식 때문에 무모한 일입니다. 그러나 텍스트에서 전화번호를 추출하는 것은 유용합니다. 제가 사용하는 것은 다음과 같습니다: \b\d{3}[-.]?\d{3}[-.]?\d{4}\b

이것은 555-123-4567, 555.123.4567, 5551234567 형식의 미국 전화번호를 잡습니다. 고객 지원 티켓을 처리할 때, 이 패턴은 94% 정확도로 전화번호를 추출합니다. 6%가 놓치는 것은 대개 국제 번호나 내선 번호로, 추가 패턴으로 처리합니다.

패턴 3: 통화 금액 추출

이 패턴은 저에게 세 년이 걸렸습니다: \$?\s*\d{1,3}(,\d{3})*(\.\d{2})?

이것은 $1,234.56, 1234.56, $1234 및 변형을 처리합니다. 저는 월마다 $847백만 거래를 처리하는 금융 데이터 파이프라인에서 이 패턴을 사용합니다. 핵심 통찰력은 선택적 그룹입니다—실제 데이터는 지저분하므로 정규 표현식은 유연해야 합니다.

패턴 4: 날짜 추출 (다양한 형식)

날짜는 악몽입니다. 상황에 따라 세 가지 패턴을 사용합니다: ISO 날짜에는 \d{4}-\d{2}-\d{2}, 미국 날짜에는 \d{1,2}/\d{1,2}/\d{2,4}, 서면 날짜에는 \d{1,2}\s+(?:Jan|Feb|Mar|Apr|May|Jun|Jul|Aug|Sep|Oct|Nov|Dec)[a-z]*\s+\d{4}을 사용합니다. 이들 조합은 비구조적인 텍스트에서 약 89%의 날짜를 잡습니다.

패턴 5: URL 추출

간단하지만 효과적입니다: https?://[^\s]+

이것은 50,000개의 문서에서 테스트한 결과 97%의 정확도로 텍스트에서 URL을 잡습니다. 그렇습니다, 완벽하지는 않습니다—가끔 후행 구두점을 잡을 수 있지만—빠르고 제가 시도해본 모든 프로그래밍 언어에서 작동합니다.

아무도 경고하지 않는 성능 함정

제가 알아낼 때까지 제 회사에 $12,000의 컴퓨팅 비용을 초래한 이야기가 있습니다.

우리는 데이터 파이프라인에서 다음과 같은 정규 표현식을 실행하고 있었습니다: (a+)+b로 문자열을 일치시키려 했습니다. 무해해 보이죠? "aaaaaaaaab"에서 테스트했을 때는 괜찮았습니다. 그러나 프로덕션에서 "aaaaaaaaaaaaaaaaaaaaaaaaaaac"와 같은 문자열을 만나자 47초가 걸렸습니다. 하나의 문자열에 대해.

이것을 카타스트로픽 백트래킹이라고 하며, 정규 표현식 성능의 조용한 살인자입니다. 정규 표현식 엔진은 패턴과 일치하는 모든 가능한 방법을 시도하며, (a+)+와 같은 중첩 수량자와 함께 시도하는 수는 기하급수적으로 증가합니다. 20자 문자열이 수십억 개의 백트래킹 시도를 초래할 수 있습니다.

저는 이러한 패턴을 힘든 방법으로 배우게 되었습니다. 중첩 수량자—(a+)+, (a*)*, (a+)*—가 있을 때는 항상 위험에 처해 있습니다. 저는 한 번, 정규 표현식을 초당 23초에서 0.002초로 최적화하였으며, (.*)*를 .*로 변경하기만 하였습니다. 동일한 결과, 11,500배 더 빠릅니다.

이제 제 규칙은: 정규 표현식이 적당한 입력에서 100밀리초 이상 걸린다면 문제가 있는 것입니다. 병목 현상을 식별하기 위해 정규 표현식 프로파일링 도구를 사용합니다. Python에서는 re 대신 regex 모듈을 사용하며, 이는 성능 특성이 더 좋고 일부 카타스트로픽 백트래킹 시나리오를 감지할 수 있습니다.

또 다른 성능 레슨: 앵커는 당신의 친구입니다. 패턴을 문자열의 시작과 끝에 고정하기 위해 ^와 $를 추가하면 속도가 급격히 향상될 수 있습니다. \d{3}-\d{3}-\d{4}와 같은 패턴은 일치하는 항목을 찾기 위해 전체 문서를 스캔할 수 있습니다. ^\d{3}-\d{3}-\d{4}$는 한 번 확인하고 멈춥니다. 10,000줄 로그 파일에서 이로 인해 처리 시간이 4.2초에서 0.3초로 변경되었습니다.

보안: 정규 표현식이 애플리케이션을 파괴할 수 있는 방법

2019년, 정규 표현식 취약성으로 인해 Cloudflare는 27분 동안 중단되었습니다. 그들의 WAF 규칙에 있는 단 하나의 악성 정규 표현식 패턴이 전체 인프라에서 CPU 사용량을 100%로 급증시켰습니다. 재정적 영향은 약 350만 달러로 추정되었습니다.

"실제 데이터는 여러분의 교과서 예제에 신경 쓰지 않습니다. 127개의 서로 다른 은행 명세서 형식을 처리할 때, '\d'에 대한 이론적 지식은 자정에 여러분을 구해주지 않을 것입니다."

정규 표현식이 보안 취약성을 생성하는 세 가지 주요 방법을 보았고, 개인적으로 두 가지는 프로덕션에서 처리한 경험이 있습니다.

ReDoS (정규 표현식 서비스 거부)