사용자가 입력한 문자열 하나가 Python 워커를 멈출 수 있다면, 정규식은 더 이상 "편한 문자열 도구"가 아닙니다. 검색창, 검증 로직, 로그 필터, 사용자 정의 룰처럼 외부 입력이 정규식과 만나는 지점은 서비스 가용성의 공격면이 됩니다.
최근 Simon Willison은 Ville Laurikari의 TRE 정규식 엔진을 Python에서 호출하는 실험적 ctypes 바인딩을 만들고, ReDoS에 취약한 패턴을 대상으로 Python 표준 re와 비교했습니다. 핵심 관찰은 명확합니다. TRE는 악성 패턴과 1,000만 문자 입력에서도 선형에 가까운 동작을 보인 반면, Python re는 작은 입력에서도 백트래킹 때문에 급격히 느려질 수 있었습니다.1
정규식 엔진은 문법 선택이 아니라 위협 모델이다
ReDoS의 본질은 "정규식이 느리다"가 아닙니다. 특정 패턴이 특정 입력을 만났을 때, 엔진이 가능한 경로를 과도하게 되짚는다는 점입니다. 중첩 반복, 애매한 분기, 실패 직전까지 오래 끌고 가는 입력이 결합하면 CPU 시간을 예측하기 어려워집니다.
Python의 re는 기본 제공이고 충분히 강력합니다. match, search, findall, 그룹, 재참조, 전방 탐색 같은 기능은 대부분의 업무 코드에서 익숙하게 쓰입니다.2 문제는 이 익숙함이 운영 리스크를 가린다는 데 있습니다.
반대로 TRE의 장점은 "더 빠른 평균 속도"라기보다 "최악의 경우를 덜 망가뜨리는 구조"에 가깝습니다. 백트래킹을 지원하지 않는 설계는 많은 ReDoS 패턴을 애초에 다른 방식으로 처리하게 만듭니다. 그래서 TRE는 re의 대체재라기보다, 고위험 경로에서 "이 정규식을 안전하게 실행해도 되는가"를 판단하게 해주는 도구에 가깝습니다.
안전한 엔진은 드롭인 교체를 뜻하지 않는다
여기서 흔한 오해가 생깁니다. "TRE가 ReDoS에 강하다면 re를 전부 바꾸면 되지 않나?" 현실은 그렇게 단순하지 않습니다.
확인된 것은 실험적 바인딩이 악성 정규식 벤치마크에서 좋은 최악 성능을 보였다는 점입니다. 아직 성숙한 Python 패키지, 넓은 플랫폼 배포, Python re와의 완전한 문법 호환성이 확인된 것은 아닙니다. 해당 바인딩도 연구와 데모 성격이 강하며, ctypes 기반이라는 점은 배포와 메모리 경계, 에러 처리까지 검토해야 한다는 뜻입니다.1
또한 백트래킹 엔진이 제공하는 일부 표현력은 비백트래킹 엔진에서 제한될 수 있습니다. 예를 들어 재참조나 복잡한 lookaround에 기대는 패턴은 그대로 옮기기 어렵거나 의미가 달라질 수 있습니다. 즉, TRE로 옮길 수 있는 정규식과 다시 써야 하는 정규식, 격리해서 실행해야 하는 정규식을 구분해야 합니다.
실무적으로는 이렇게 보는 편이 안전합니다.
내부에서 고정한 단순 검증 정규식: Python
re로도 대체로 충분외부 입력이 매우 길 수 있는 경로: 길이 제한과 타임아웃 우선
사용자가 패턴까지 제공하는 기능: 샌드박스, 별도 프로세스, 비백트래킹 엔진 검토
장애 시 서비스 전체를 묶는 동기 처리 경로: TRE나 RE2류 엔진 후보 검토
Python 팀을 위한 정규식 트리아지 절차
정규식 보안은 "위험한 패턴을 외우는 일"만으로 해결되지 않습니다. 팀 단위의 절차가 필요합니다.
먼저 코드베이스에서 정규식 호출 지점을 모읍니다. API 파라미터 검증, 검색 필터, 로그 파서, 데이터 적재 파이프라인, 관리자용 룰 설정 기능을 우선 봐야 합니다. 그다음 입력과 패턴 중 무엇이 사용자 통제하에 있는지 표시합니다. 문자열만 외부 입력인지, 정규식 패턴 자체도 외부에서 오는지에 따라 위험도는 크게 달라집니다.
둘째, 알려진 악성 케이스를 테스트에 넣습니다. 서비스에서 실제로 쓰는 패턴에 대해 정상 입력만 벤치마크하지 말고, 실패하는 긴 입력과 경계값 입력을 함께 넣어야 합니다. 정규식 성능은 "대부분 빠르다"가 아니라 "실패할 때 얼마나 버티는가"가 중요합니다.
셋째, 고위험 경로에는 방어선을 겹칩니다. 입력 길이 제한, 실행 시간 제한, 워커 격리, 별도 프로세스 실행, 큐 기반 비동기 처리 같은 장치가 필요합니다. 그리고 일부 패턴은 TRE 같은 비백트래킹 엔진으로 옮길 수 있는지 검토합니다. 이때 목표는 전면 교체가 아니라, 장애 반경이 큰 정규식을 줄이는 것입니다.
앞으로 봐야 할 변화는 "더 안전한 기본값"이다
TRE Python binding 데모의 가치는 새 라이브러리 출시 소식보다 큽니다. Python 서비스에서 정규식 엔진을 선택 가능한 운영 요소로 봐야 한다는 신호이기 때문입니다.
앞으로 중요한 변화는 세 가지입니다. 첫째, TRE나 유사 엔진을 Python에서 안정적으로 쓰는 패키징이 나오는가. 둘째, re와의 문법 차이를 자동 점검하거나 CI에서 위험 패턴을 잡는 도구가 성숙하는가. 셋째, 팀들이 정규식 성능을 미스터리가 아니라 테스트 가능한 품질 속성으로 다루는가.
지금 당장 TRE를 운영 표준으로 삼을 필요는 없습니다. 하지만 외부 입력을 정규식에 태우는 Python 백엔드, 로그 검색 제품, 사용자 정의 필터 기능을 가진 SaaS라면 이번 데모를 경고등으로 받아들여야 합니다. 판단 기준은 간단합니다. "이 정규식이 실패할 때도 예측 가능한 시간 안에 끝나는가?" 그 답을 모른다면, 이미 검토 대상입니다.
참고
1TRE Python binding -- ReDoS robustness demo
2[Python] re 모듈, 정규 표현식(정규식) 개념과 완전 정복하기(regex cheat sheet) SQL, HIVE, PySpark에서의 regex
이 노트는 보도·비평·교육·연구 목적으로 작성되었습니다. 저작권 문의가 있으시면 에서 알려주세요.