Hacker News가 Nikita Popov의 Regex 에세이를 되살리며, 중요한 분열을 다시 열었다

Hacker News가 14년 전 Nikita Popov의 에세이를 다시 끌어올리면서, 프로그래밍 업계의 축약 표현이 흔히 감추는 갈등이 재점화됐다. 이 글은 현대 regex 엔진이 형식적 정규 언어를 훨씬 넘어서는 언어를 인식할 수 있다고 주장한다. Hacker News의 반응은 그러한 추가적인 표현력의 대가에 집중했다.

Popov는 Stack Overflow에서 PHP 관련 질문에 자주 답하던 2012년 6월 15일에 이 에세이를 발표했다. 그가 겨냥한 것은 익숙한 금기였다. HTML은 정규 언어가 아니므로 정규 표현식으로 다룰 수 없다는 주장이다.

이 규칙은 여전히 유용하지만, Popov는 그 이론적 설명이 오해를 부를 수 있는 이유를 보여줬다. PCRE 패턴은 정규 표현식이라 불리는 수학적 대상에만 한정되지 않는다. 재귀, 역참조, 단언, 조건문, 서브루틴 호출은 일부 엔진에 훨씬 넓은 범위를 부여한다.

따라서 이번에 다시 불붙은 논쟁은 Popov가 영리한 패턴을 발견했는지에 관한 것이 아니다. 개발자가 regex라는 말로 무엇을 뜻하는지, 구현 선택에도 어떤 보장이 유지되는지, 그리고 언제 인식이 파싱의 부실한 대체물이 되는지를 다룬다.

Hacker News가 2012년 Regex 논쟁을 되살린 이유

그 핵심 구분이 일상적인 소프트웨어 용어에서 여전히 해결되지 않았기 때문에 에세이가 다시 돌아왔다.

Popov의 2012년 에세이는 개발자가 습관적으로 하나로 묶는 두 가지 의미를 분리하는 데서 시작한다. 형식적 정규 표현식은 정규 언어를 기술한다. 실제 운영 환경의 regex 엔진은 흔히 그 형식적 범주를 넘어서는 추가 연산자를 구현한다.

정규 언어는 유한한 상태로 인식할 수 있다. 즉, 매처는 입력 깊이에 연결된 무한한 스택을 필요로 하지 않는다. 일반적인 예로는 식별자, 단순한 숫자 형식, 고정된 토큰 패턴, 많은 검색 필터가 있다.

Perl-Compatible Regular Expressions의 약자인 PCRE는 이러한 그림을 바꾸는 구문을 추가한다. 하위 패턴은 자기 자신을 호출할 수 있어 매처가 중첩 구조를 따라가게 한다. 역참조는 뒤에 나오는 텍스트가 앞서 캡처한 텍스트와 같도록 요구할 수 있다.

이러한 기능 때문에 “regular expression”이라는 용어는 역사적으로는 익숙하지만 수학적으로는 부정확하다. 개발자는 대체로 regex를 패턴 언어의 통칭으로 사용한다. 형식 언어 전문가들은 이 용어를 유한 오토마타와 동등한 표현식에 한정할 수 있다.

이 구분은 8월 토론을 이끌었다. 한쪽은 이 에세이가 진정한 정규 표현식과 PCRE 특화 패턴 매칭을 혼동할 위험이 있다고 주장했다. 다른 쪽은 Popov가 더 넓은 프로그래머식 의미를 살피기 전에 바로 이 구분을 명시적으로 밝혔다고 답했다.

두 해석 모두 중요한 점을 짚는다. 에세이는 자신의 범위를 신중하게 명시하지만, 도발적인 제목은 서로 다른 엔진을 하나의 기술로 취급하게 만든다. 재귀를 사용하는 PCRE 패턴은 JavaScript, RE2, Rust, POSIX 또는 다른 구현체가 무엇을 받아들이는지에 대해 개발자에게 거의 알려주지 못한다.

토론은 이론을 넘어섰다. 댓글 작성자들은 가독성, 엔진 차이, 메모리 사용량, 백트래킹, 서비스 거부 노출, AI가 생성한 표현식을 제기했다. 이런 우려가 2012년 에세이가 여전히 현재의 문제처럼 느껴지는 이유를 설명한다.

현대 코드 어시스턴트는 유지보수자가 실행 방식을 이해하도록 보장하지 않은 채 복잡한 패턴을 만들어낼 수 있다. 또한 대상 엔진이 지원하지 않는 문법을 제안할 수도 있다. regex 생성에 더 쉽게 접근할 수 있게 되었다고 해서 적절한 매처를 선택할 필요가 사라지는 것은 아니다.

원문은 지나치게 단순화된 한계를 문제 삼는다는 점에서 여전히 가치가 있다. 다시 열린 토론은 빠져 있던 운영상의 질문을 제시한다. 그 추가 표현력에는 어떤 비용이 드는가?

PCRE Regex의 표현력은 정규 언어 밖의 기능에서 나온다

이 글의 핵심 결론은 regex라는 이름을 단 모든 시스템이 아니라 PCRE 스타일 엔진에 해당한다.

Popov는 언어를 생성하는 데 필요한 문법에 따라 형식 언어를 분류하는 촘스키 위계에서 출발한다. 정규 언어는 문맥 자유 언어 안에 있고, 문맥 자유 언어는 문맥 의존 언어 안에 있다.

전통적인 정규 표현식은 가장 작은 집단을 차지한다. 연결, 선택, 문자 클래스, 반복은 모든 정규 언어를 기술할 수 있다. 하지만 그것들만으로는 제한 없는 중첩 깊이를 기억하거나 임의의 캡처된 부분 문자열을 복제할 수 없다.

PCRE 재귀는 첫 번째 한계를 바꾼다. Popov는 재귀 그룹을 사용해 a 문자와 그 뒤를 잇는 b 문자의 개수가 같은 문자열을 인식한다. 이 언어는 문맥 자유 언어지만 정규 언어는 아니다.

그 메커니즘은 간결하다. 패턴은 a 하나를 소비하고, 주변 그룹을 재귀적으로 호출한 다음, b 하나를 소비한다. 더 깊은 각 호출은 중첩된 매치 주변에 대응하는 한 쌍을 추가한다.

현재 PCRE2 문서도 여전히 재귀 패턴 문법을 설명한다. 균형 잡힌 괄호를 직접적인 예로 든다. 한 그룹은 여는 괄호, 일반 내부 문자 또는 또 다른 그룹 호출, 그리고 닫는 괄호에 매치한다.

이는 의미 있는 기능이다. 전통적인 유한 상태 매칭은 미리 정한 중첩 한계만 지원할 수 있다. 재귀 매칭은 엔진의 리소스 한계와 동작 방식에 따라 입력의 중첩 깊이를 따라갈 수 있다.

이후 Popov는 문맥 자유 문법 규칙을 이름 있는 PCRE 하위 패턴으로 옮긴다. (?(DEFINE)...) 구문은 입력을 소비하지 않고 정의를 보관한다. 이름 있는 서브루틴 호출은 한 규칙이 다른 규칙을 호출하게 한다.

그의 확장 예제는 RFC 5322 이메일 문법의 일부를 이 표기법으로 번역한다. 그 결과는 확장 모드로 공백과 주석을 허용한 regex 리터럴 안에 문법을 내장한 것과 닮았다.

이는 에세이의 인상적인 주장을 뒷받침한다. PCRE 스타일 재귀는 호환되지 않는 좌재귀를 변환한 뒤 문맥 자유 언어를 인식할 수 있다. 그렇다고 모든 짧은 regex가 모든 문맥 자유 언어를 처리할 수 있다는 뜻은 아니다.

또한 이것이 매처를 완전한 파서로 만드는 것도 아니다. 인식은 입력이 한 언어에 속하는지 여부를 답한다. 파싱은 입력이 문법에 어떻게 맞는지 기록하는 구조화된 출력을 만든다.

HTML에서는 이 차이가 결정적이다. 매처는 잘 구성된 프래그먼트가 문법에 부합하는지 판단할 수 있다. 그러나 애플리케이션에는 보통 요소, 속성, 텍스트 노드, 오류 복구, 엔티티 처리, 문서 순회가 필요하다.

실제 HTML에는 또 다른 복잡성이 있다. 브라우저는 정해진 복구 동작을 통해 잘못된 문서를 처리한다. 이상화된 잘 구성된 언어를 매칭하는 것은 그 동작을 재현하지 못한다.

Popov도 두 한계를 모두 인정한다. 그는 일반적인 HTML 처리에는 DOM 라이브러리를 권장하고, regex는 제한된 상황에만 남겨둔다. 따라서 유명한 주장은 많은 재인용이 시사하는 것보다 더 좁다.

역참조는 고전적 정규 표현식을 넘어서는 또 다른 단계를 만든다. 역참조는 이전에 그룹이 캡처한 정확한 텍스트에 매치한다. 예를 들어 패턴 ^(.+)\1$는 동일한 두 절반으로 이루어진 문자열을 인식한다.

유한 오토마타는 일반적으로 임의의 첫 번째 절반을 기억하고 두 번째 절반과 비교할 수 없다. 엔진은 캡처된 내용을 보관하고 가능한 분할 지점을 탐색해야 한다. 이 추가 상태는 표현 범위와 계산 동작을 모두 바꾼다.

Popov는 재귀와 룩어라운드 단언을 결합해 적어도 일부 문맥 의존 언어를 인식한다. 룩어라운드는 그 위치에서 텍스트를 소비하지 않고 주변 텍스트를 검사한다.

그는 PCRE가 모든 문맥 의존 언어를 인식한다고 주장하는 데까지는 나아가지 않는다. 이러한 절제는 중요하다. 에세이는 의도적으로 폭넓은 제목을 사용하면서도, 입증한 구성과 아직 답하지 못한 질문을 구분한다.

형식적 Regex와 백트래킹 엔진은 서로 다른 약속을 최적화한다

핵심 갈등은 이론과 실무의 대립이 아니라, 예측 가능한 실행과 더 큰 패턴 언어의 대립이다.

정규 언어 구문으로 제한된 엔진은 오토마타를 통해 패턴을 실행할 수 있다. 하나의 경로를 선택하고 실패 뒤에 되돌아가는 대신, 각 입력 문자 뒤에 도달 가능한 상태 집합을 추적한다.

백트래킹 엔진은 대안을 깊이 우선 탐색처럼 따른다. 한 분기를 선택해 계속 진행하고, 이후 매칭이 실패하면 이전 결정으로 돌아간다. 이 접근법은 직관적인 의미론과 함께 캡처 및 고급 동작을 지원한다.

하지만 같은 작업을 반복할 수도 있다. 모호한 중첩 수량자는 같은 입력을 나누는 많은 방식을 만들어낼 수 있다. 거의 일치하는 접미사는 엔진이 실패를 보고하기 전에 그러한 조합을 탐색하도록 강제할 수 있다.

이 위험은 패턴이 재귀나 역참조를 사용할 때만 나타나지 않는다. 백트래킹 구현은 형식적으로 정규인 패턴에서도 과도한 시간을 소비할 수 있다. 문법 범주와 실행 전략은 관련되어 있지만 동일하지는 않다.

이 지점은 온라인 논쟁의 한 가지 과도한 단순화를 바로잡았다. 비정규 확장을 제거한다고 해서 모든 구현이 자동으로 선형 시간이 되는 것은 아니다. 엔진은 지수적인 경로 탐색을 피하는 알고리즘도 사용해야 한다.

Google의 선형 시간 엔진은 의도적인 선택을 한다. RE2는 입력 길이에 대해 점근적으로 선형인 매칭 시간을 보장하며, 구성 가능한 메모리 예산 안에서 동작한다.

RE2는 같은 보장을 유지하면서 이러한 구문을 지원하는 방법을 설계자들이 알지 못하기 때문에 역참조와 룩어라운드 단언을 제외한다. 재귀적 서브루틴 호출도 제외한다.

그 결과는 PCRE2보다 표현력이 낮지만, 신뢰할 수 없는 패턴을 받거나 신뢰할 수 없는 텍스트를 처리하는 서비스에서 더 예측 가능하다. 이 차이는 한 엔진이 다른 엔진을 보편적으로 대체한다는 증거가 아니라 아키텍처 결정이다.

PCRE2는 매치 제한, 깊이 제한, 대체 실행 경로, 신중한 패턴 구성 등 운영 시스템에서 활용할 수 있는 제어 수단을 제공한다. 이러한 수단은 노출을 줄이지만, 의도적인 구성과 테스트가 필요하다.

실용적인 선택은 누가 패턴과 입력을 제어하는지에 달려 있다. 제한된 레코드에 적용되는 개발자 소유 표현식은 공유 서비스에서 대규모 페이로드를 검사하는 사용자 제공 표현식과 다른 위험을 만든다.

필요한 출력도 중요하다. 검색 명령에는 Boolean 매치나 몇 개의 캡처만 필요할 수 있다. 컴파일러, 문서 처리기, 구성 리더에는 구조화된 결과와 유용한 실패 위치가 필요하다.

이 때문에 “regex로 매치할 수 있다”는 말은 엔지니어링 결정을 거의 끝내지 못한다. 기능은 가능성을 입증한다. 유지보수성, 리소스 한계, 진단 품질, 호환성을 입증하지는 않는다.

이런 틀로 보면 Hacker News의 이견은 더 명확해진다. Popov는 선택된 엔진이 무엇을 표현할 수 있는지 설명한다. 비판자들은 애플리케이션이 그 표현력에 의존할 때 어떤 보장을 포기하는지 묻는다.

이 두 입장은 서로 반대가 아니다. 같은 시스템의 서로 다른 계층을 다룬다. 중요한 실수는 단서 없이 한 계층의 주장을 다른 계층으로 옮기는 것이다.

HTML 문제는 인식의 실용적 한계를 드러낸다

언어를 매칭하는 일은 신뢰할 수 있는 문서 표현을 구축하는 일과 다르다.

regex 기반 HTML 처리에 대한 일반적인 경고는 여러 주장을 결합한다. HTML은 중첩되어 있고, 실제 문서는 잘못된 형식을 포함하며, 내장 언어는 토큰 경계를 복잡하게 만들고, 애플리케이션에는 대개 구조화된 출력이 필요하다.

이 가운데 형식 언어의 표현력과 직접 관련된 것은 첫 번째 주장뿐이다. PCRE 재귀는 중첩을 다룰 수 있다. 그러나 그 사실만으로 나머지 요구 사항까지 해결하는 것은 아니다.

애플리케이션이 링크를 추출한다고 가정해 보겠습니다. 하나의 템플릿이 생성한 통제된 마크업에서는 간단한 표현식이 작동할 수 있습니다. 하지만 따옴표로 감싼 속성 안에 >가 포함되거나 스크립트 텍스트가 태그와 비슷한 형태를 띠면 실패할 수 있습니다.

주석, 문자 참조, 네임스페이스, 선택적 태그, 브라우저의 복구 규칙은 더 많은 경우를 추가합니다. 새 조건이 추가될 때마다 패턴은 확장되지만, 그 결과물은 DOM보다 덜 구조화된 상태로 남습니다.

그렇다고 모든 HTML 정규식이 무책임하다는 뜻은 아닙니다. 입력 계약이 엄격하고 실패의 영향이 작다면, 범위가 좁은 표현식이 적절할 수 있습니다.

범위는 명시적이어야 합니다. “우리가 생성한 조각에서 알려진 마커를 찾기”는 범위가 한정된 텍스트 작업입니다. “브라우저처럼 임의의 웹 페이지를 해석하기”는 문서 처리 작업입니다.

파서는 각 구문 요소에 이름이 붙은 역할을 부여합니다. 소스 위치를 연결하고, 예상치 못한 토큰을 보고하며, 오류 후 복구하고, 이후 변환을 위한 트리를 제공할 수 있습니다.

대규모 정규식은 흔히 그러한 구분을 그룹과 제어 흐름 안에 압축합니다. 명명된 하위 패턴과 확장 서식이 도움이 되지만, 엔진은 여전히 네이티브 구문 트리가 아니라 일치 결과를 반환합니다.

요구사항이 바뀌면 유지보수 격차는 커집니다. 파서에서 다른 문법 규칙을 지원하는 일은 대체로 규칙을 추가하거나 수정하는 것으로 끝납니다. 긴밀하게 결합된 정규식에서는 그 변경이 다른 곳의 백트래킹과 캡처 동작까지 바꿀 수 있습니다.

따라서 테스트는 대표적인 유효 사례만 다뤄서는 안 됩니다. 팀에는 잘못된 입력, 유사하지만 일치하지 않는 입력, 대용량 입력, 중첩 입력, Unicode 사례, 그리고 비용이 큰 경로를 유발하도록 설계된 적대적 문자열이 필요합니다.

이 지점에서 문서는 장식이 아니라 운영상의 도구가 됩니다. 복잡한 표현식은 사용 엔진, 플래그, 허용되는 입력 계약, 예상 캡처, 크기 제한, 그리고 파서를 사용하지 않는 이유를 명시해야 합니다.

기술적 의사결정을 보존하는 팀은 이러한 제약을 검색 가능한 구현 기록과 함께 보관할 수 있습니다. 공유된 엔지니어링 지식 베이스는 미래의 유지보수자가 간결한 매칭 코드에 담긴 의도를 되살리는 데 도움이 됩니다.

핵심 판단은 경쟁하는 정체성으로서의 정규식 대 파서가 아닙니다. 작업에 인식, 추출, 변환, 복구 또는 완전한 해석이 필요한지의 문제입니다.

정규식은 토큰화, 제한된 규칙 아래의 검증, 검색, 로그 필터링, 소규모 추출에 여전히 탁월합니다. 문법 구조가 애플리케이션의 작업 데이터가 되는 순간에는 파서가 더 적합합니다.

Popov 자신의 결론도 그 경계를 따릅니다. 그는 절대적인 이론적 금지는 거부하면서도, 일반적인 HTML 처리에는 DOM 라이브러리를 사용하라는 실용적 권고를 유지합니다.

그러한 뉘앙스는 온라인에서 자주 사라집니다. “정규식으로 HTML을 파싱할 수 없다”는 말은 흔한 실패를 막아 주기 때문에 살아남습니다. “일부 정규식 엔진은 문맥 자유 구조를 인식할 수 있다”는 말도 근본적인 기능이 존재하기 때문에 여전히 사실입니다.

성숙한 엔지니어링 원칙은 두 진술을 모두 수용할 수 있습니다. 유용한 기본값을 정리로 혼동하지 말고, 이론적 구성을 프로덕션 설계와 혼동하지 말아야 합니다.

정규식 논쟁이 여전히 과소평가하는 것

추가적인 표현력은 성공적인 테스트 스위트만으로는 드러나지 않을 수 있는 보안 및 유지보수 의무를 만듭니다.

정규식 서비스 거부, 즉 ReDoS는 매처가 조작된 입력에 대해 대안을 탐색하는 데 과도한 시간을 소비할 때 발생합니다. 공격자는 많은 트래픽을 보내지 않고도 처리 용량을 소진시킬 수 있습니다.

ReDoS 가이드는 모호한 패턴이 적대적 문자열과 만나면 엔진의 실행 시간이 극단적으로 길어질 수 있다고 설명합니다. 위험은 대개 일치 실패 직전에서 나타납니다.

검증기는 첫 번째 분기가 성공하기 때문에 일반 입력을 빠르게 처리할 수 있습니다. 공격자는 여러 경로에 들어맞는 긴 접두사 뒤에 모든 경로를 무효화하는 문자 하나를 붙여 보낼 수 있습니다.

그러면 엔진은 이전 선택을 다시 검토해야 합니다. 중첩 반복, 겹치는 대안, 선택적 구성 요소는 탐색 공간을 증폭시킬 수 있습니다. 간결한 패턴도 코드 리뷰 중에는 이런 동작을 숨길 수 있습니다.

역참조는 또 다른 복잡성 차원을 더합니다. 그 표현력 한계에 관한 연구는 이를 많은 주류 엔진이 지원하는 중요한 확장으로 다룹니다. 그 동작은 일반적인 유한 상태 매칭으로 환원할 수 없습니다.

Popov의 에세이는 역참조 매칭이 NP-완전 사례를 도입한다고 언급합니다. 이는 일반 문제에 관한 진술이지, 모든 패턴이 느리게 실행된다는 예측은 아닙니다.

캡처와 역참조를 사용하는 많은 표현식은 일반 입력에서 빠르게 끝납니다. 복잡도 결과는 복잡도 이론의 주요 가정이 바뀌지 않는 한 모든 사례를 포괄하는 효율적인 일반 해법이 없음을 경고합니다.

재귀는 별도의 리소스 문제를 도입합니다. 깊게 중첩된 입력을 따르는 패턴은 엔진이 관리하는 깊이 또는 이에 상응하는 상태를 소모합니다. 구현체는 제한을 적용하며, 재귀와 백트래킹의 상호작용 방식도 서로 다릅니다.

엔진 버전도 중요합니다. PCRE2는 특정 상황에서 Perl과 더 가깝게 맞추기 위해 시간이 지나며 재귀 의미론을 변경했습니다. 한 버전에서 테스트한 패턴이 마이그레이션 후에는 다르게 동작할 수 있습니다.

따라서 Perl 호환으로 설명되는 엔진들 사이에서도 이식성은 제한적입니다. 문법 지원, Unicode 규칙, 캡처 값, 매칭 순서, 재귀 의미론이 달라질 수 있습니다.

AI가 생성한 정규식은 한때 복잡성을 제한했던 마찰을 생성이 줄여 주기 때문에 위험을 높입니다. 개발자는 문법 하나를 위한 단일 표현식을 요청하고 몇 초 안에 문법적으로 그럴듯한 결과를 받을 수 있습니다.

생성된 패턴은 잘못된 플레버를 겨냥할 수 있습니다. 프롬프트의 예시는 통과하면서도 잘못된 입력을 놓치거나, 과도한 리소스를 소비하거나, 예상치 못한 의미론의 캡처를 반환할 수 있습니다.

리뷰어는 생성된 정규식을 생성된 코드로 다뤄야 합니다. 엔진을 식별하고, 자명하지 않은 각 구문 요소를 이해하며, 적대적 테스트를 실행하고, 입력 및 실행 제한을 강제해야 합니다.

여기서 가독성은 미관의 문제가 아닙니다. 읽기 어려운 제어 흐름은 유지보수자가 겹치는 대안을 식별하거나 작은 편집이 재앙적 백트래킹을 만들었음을 알아차리지 못하게 합니다.

확장 모드는 이를 지원하는 엔진에서 공백과 주석을 제공합니다. 명명된 그룹은 변동하는 숫자 인덱스에 대한 의존을 줄입니다. 더 작게 구성한 패턴은 책임을 명확히 할 수 있습니다.

이러한 방식은 도움이 되지만, 구성은 엔진 문법을 따라야 합니다. 일부 호스트 언어는 정규식 컴파일러가 보기 전에 문자열을 보간하므로, 이스케이프와 संभाव한 인젝션의 계층이 하나 더 생깁니다.

신뢰할 수 없는 조각은 엔진에 맞는 이스케이프 없이 패턴에 삽입해서는 안 됩니다. 신뢰할 수 없는 사용자가 공유 서비스 내부의 백트래킹 매처에 무제한으로 접근하도록 해서도 안 됩니다.

회의적인 결론은 “고급 정규식을 절대 사용하지 말라”보다 더 좁습니다. 각 고급 구문 요소는 시스템의 예측 가능성 예산 일부를 사용한다는 것입니다.

개발자는 그 대가로 무엇을 얻는지 말할 수 있어야 합니다. 재귀는 범위가 제한된 중첩 구조를 간결하게 인식하게 해 줄 수 있습니다. 역참조는 그렇지 않으면 절차적 코드가 필요했을 동등성 제약을 강제할 수 있습니다.

이점이 작은 파서를 피하는 것뿐이라면, 그 선택은 정당화하기 더 어려워집니다. 파서는 대개 더 나은 오류 정보, 더 명확한 진화 경로, 그리고 다운스트림 코드가 직접 사용할 수 있는 출력을 제공합니다.

세 가지 신호가 이 교훈의 정착 여부를 결정할 것입니다

지속적인 결과는 엔진 선택, 생성 코드 리뷰, 그리고 팀이 예시만이 아니라 실패 동작을 테스트하는지에 달려 있습니다.

첫 번째 신호는 더 넓고 명시적인 엔진 선택입니다. 개발자는 정규식을 하나의 이식 가능한 언어로 취급하는 일을 멈추고, 패턴이 PCRE2, RE2, JavaScript, Java, .NET, Rust 또는 다른 구현체를 대상으로 하는지 문서화해야 합니다.

라이브러리와 플랫폼이 실행 보장을 명확히 드러낸다면, Hacker News 논쟁은 해결하기 쉬워집니다. 개발자는 과도하게 포괄적인 레이블을 두고 논쟁하는 대신, 정의된 엔진을 논의할 수 있습니다.

두 번째 신호는 코딩 어시스턴트가 정규식 요청을 처리하는 방식입니다. 유용한 시스템이라면 복잡한 표현식을 생성하기 전에 대상 플레버, 입력 범위, 신뢰할 수 있는 데이터에 대한 가정, 필요한 캡처를 물어야 합니다.

또한 지원되지 않는 구문 요소를 설명하고, 요청된 출력이 구조화되어 있다면 파서를 제안해야 합니다. 어시스턴트가 이런 검사 없이 조밀한 패턴을 계속 생성한다면 유지보수 및 보안 실패는 늘어날 것입니다.

세 번째 신호는 일상적인 적대적 테스트입니다. 팀은 성공적인 매칭, 늦은 실패, 긴 반복 입력, 깊은 중첩, Unicode 경계, 모호성을 극대화하도록 구성된 입력을 측정해야 합니다.

친화적인 예시 열 개를 통과한 패턴은 그 예시에 대해서만 정확성을 입증한 것입니다. 허용 가능한 최악의 경우 동작이나 프로덕션 제한과의 호환성을 입증한 것은 아닙니다.

이 신호들은 Popov의 더 넓은 교훈을 강화하는 동시에 적용 범위를 좁힙니다. 현대의 패턴 엔진은 이름이 암시하는 형식적 한계를 넘어설 수 있습니다. 이 사실은 이해할 가치가 있지만, 보편적인 설계 권고로 사용되어서는 안 됩니다.

되살아난 이 에세이는 양측 모두에 유용한 교정도 제공합니다. 형식 이론은 어떤 보장을 사용할 수 있는지 설명하기 때문에 중요합니다. 구현 세부사항은 배포된 엔진이 모두 그러한 보장을 유지하는 것은 아니기 때문에 중요합니다.

Hacker News 논쟁을 따라가는 개발자에게 다음 행동은 구체적입니다. 프로덕션에서 가장 복잡한 패턴 뒤의 엔진을 식별하고, 그 입력 계약을 문서화하며, 가장 느린 실패 사례를 테스트하십시오. 그런 다음 애플리케이션에 인식이 필요한지, 구조화된 파싱이 필요한지 물어보십시오.

패턴이 명확하고, 범위가 제한되며, 측정 가능하다면 유지하십시오. 정확성이 문서화되지 않은 플레버 동작이나 취약한 백트래킹에 의존한다면, 숨겨진 문법을 명시적인 파서로 교체하십시오.