SimpleWebUtils
ENKO

문서 작업 가이드

실제 여러 줄 텍스트에서 JavaScript 정규식 테스트하기

여러 줄 로그와 복사 문서에서 g·m·s 차이를 구분하고 캡처 범위와 긴 near-match 비용까지 확인하며 JavaScript 정규식을 재현합니다.

작성 및 검수 게시일: 검토일:

이 작업 흐름을 검증한 방법

“복사한 로그에서 ERROR와 WARN 필드 추출” 확인에는 가이드 원본 데이터와 Worker Timeout과 캡처 범위를 제공하는 JavaScript 정규식 테스터의 “최소 플래그 기준선 만들기” 절차를 사용했습니다. 출력은 문서 결과와 일치해야 했습니다. 기록 전 경계 증거는 “단순화한 한 줄만 테스트하기”, “multiline 앵커 문제를 g로 해결하기” 항목별로 검토했습니다.

gm 패턴은 전체 일치 2개, 번호 capture 6개, 이름 capture 4개와 0길이 일치 0개를 반환했고 ERROR·WARN은 포함하되 INFO는 제외했습니다.

Worker Timeout과 캡처 범위를 제공하는 JavaScript 정규식 테스터 열기

문제 상황

짧은 한 줄에서 성공한 패턴도 로그, PDF, 코드 뷰어, 터미널, 이슈에서 복사한 텍스트에서는 누락하거나 과도하게 일치할 수 있습니다. 줄 번호와 들여쓰기가 앵커를 밀고, g를 m으로 오해하며, s가 없으면 점이 줄바꿈에서 멈춥니다. 모호한 수량자 분기는 긴 실패 접미어에서만 매우 느려질 수도 있습니다. 신뢰할 수 있는 검토는 실제 블록을 보존하고 플래그를 하나씩 바꾸며 정확한 캡처·UTF-16 범위와 의도한 일치·현실적인 실패를 모두 확인합니다.

이럴 때 사용하세요

  • 한 줄에서는 동작하는 JavaScript 패턴이 붙여넣은 여러 줄 블록을 놓치거나 과도하게 잡을 때
  • ^와 $가 전체 문자열과 각 줄 중 어디를 대상으로 해야 하는지 결정할 때
  • 점이 줄바꿈에서 멈춰야 하는지 의도적으로 넘어가야 하는지 검증할 때
  • 복사한 로그·코드·PDF 텍스트에 줄 번호, 빈 줄, 들여쓰기, Unicode 문자가 있을 때
  • 추출이나 치환에 쓸 패턴을 긴 near-match로 먼저 성능 점검할 때

단계

  1. 1단계

    실패한 원본 블록 보존

    원본 사본을 남기고 실제로 실패한 전체 텍스트를 줄바꿈, 빈 줄, 들여쓰기, 접두사, 마지막 줄까지 그대로 붙여넣습니다. 정확한 동작을 기록하기 전에는 텍스트를 정리하지 않습니다.

  2. 2단계

    패턴 표현 형식 확인

    현재 값이 raw 패턴 본문인지, /literal/flags인지, 따옴표로 감싼 JavaScript·JSON 문자열인지 구분합니다. 테스터에는 슬래시 구분자와 소스 코드 따옴표를 뺀 패턴 본문을 넣으므로 이스케이프 층을 먼저 정규화합니다.

  3. 3단계

    최소 플래그 기준선 만들기

    대상 런타임에 필요한 플래그만 켭니다. 반복 일치는 g로 확인하고, ^와 $는 m을 끄고 켜서 비교합니다. 점이 줄바꿈까지 포함해야 할 때만 s를 사용하고 프로덕션 식이 Unicode 의미를 사용하면 u도 동일하게 설정합니다.

  4. 4단계

    실행 후 정확한 증거 확인

    Worker 테스트를 실행해 전체 일치 하이라이트, 0길이 표시, 번호·이름 캡처를 모두 검토합니다. 각 [start, end) 값을 UTF-16 코드 단위 범위로 보고 코드 검증에서는 text.slice(start, end)로 같은 구간을 재현합니다.

  5. 5단계

    복사 과정의 노이즈를 별도 분류

    줄 번호나 빈 줄이 원본 UI가 만든 노이즈라면 먼저 영향부터 기록합니다. 그다음 사본을 줄 번호 제거 또는 빈 줄 제거 도구로 정리하고 같은 패턴을 다시 실행해, 입력 계약 변경을 숨기지 않습니다.

  6. 6단계

    실패 입력과 near-match 테스트

    구두점, 누락된 구분자, 예상 밖 Unicode, 빈 필드, 거의 일치하는 긴 접두사·접미어를 추가합니다. 1초 Worker timeout은 식을 단순화해야 한다는 경고이며, 우연히 성공할 때까지 반복 실행할 결과가 아닙니다.

  7. 7단계

    추출·치환을 실제 맥락에서 검증

    일치와 캡처가 안정되면 폐기 가능한 샘플에서 텍스트 찾기·바꾸기를 실행하거나 대상 JavaScript 런타임에서 식을 호출합니다. 출력과 프로젝트 테스트를 확인하고 패턴 본문, 플래그, 대표 입력, 범위, timeout 결과를 변경 기록에 남깁니다.

예시

복사한 로그에서 ERROR와 WARN 필드 추출

입력

패턴: ^(?<level>ERROR|WARN)\s+\[(?<service>[^\]]+)\]\s+(.+)$
플래그: gm
텍스트:
ERROR [billing] Payment failed for order 1042
INFO [api] Request completed
WARN [search] Slow query detected

출력

전체 일치 2개, 번호 캡처 6개, 이름 캡처 4개, 0길이 일치 0개입니다. ERROR와 WARN은 포함되고 INFO는 제외됩니다. UTF-16 범위를 확인한 뒤 잘못된 형식과 긴 near-match 줄을 추가해 파서 투입 전에 다시 검증합니다.

흔한 실수

단순화한 한 줄만 테스트하기

한 줄 샘플은 앵커, 줄바꿈, 빈 줄, 반복 일치, 긴 실패 동작을 숨깁니다. 실제 여러 줄 블록을 사용하고 최소 재현 입력은 두 번째 fixture로 보관하세요.

multiline 앵커 문제를 g로 해결하기

g는 다음 일치를 계속 반환할 뿐 ^와 $를 바꾸지 않습니다. 줄 경계는 m, 점의 줄바꿈 통과는 s를 각각 검토해야 합니다.

실패 기록 전에 줄 번호 지우기

소스 접두사 때문에 앵커가 실패할 수 있습니다. 정확한 결과를 먼저 남긴 뒤 사본을 정리해 변환 단계를 명시적으로 유지하세요.

오프셋을 grapheme 위치로 읽기

JavaScript 범위는 UTF-16 코드 단위를 셉니다. 이모지와 결합 시퀀스 때문에 보이는 문자 수와 일치·캡처 오프셋이 달라질 수 있습니다.

Worker timeout 무시하기

timeout은 현재 입력이 1초 검토 예산을 넘었다는 뜻입니다. 모호성을 줄이고 수량자를 제한하거나 파서·안전한 엔진을 검토한 뒤 신뢰할 수 없는 프로덕션 입력에 사용하세요.

자주 묻는 질문

g와 m은 어떻게 다른가요?

g는 반복 exec 호출이 뒤의 일치를 반환하게 하고, m은 ^와 $가 문자열 내부의 줄 경계에도 일치하게 합니다. 여러 줄 추출에서 둘 다 필요할 수 있지만 해결하는 문제는 다릅니다.

s 플래그는 언제 필요한가요?

점이 줄바꿈까지 포함해야 할 때만 사용합니다. ^와 $에는 영향을 주지 않으며, 넓은 dot-all보다 명시적으로 제한한 문자 클래스가 검토하기 쉬울 수 있습니다.

복사한 줄 번호는 제거해야 하나요?

실제 입력이 아니라 소스 화면이 붙인 노이즈일 때만 제거합니다. 먼저 정리 전 결과를 기록하고 별도 변환으로 정리 과정을 테스트하세요.

이모지가 있으면 인덱스가 달라지는 이유는 무엇인가요?

JavaScript는 UTF-16 코드 단위 오프셋을 반환합니다. astral 이모지는 보통 코드 단위 두 개를 차지하고, 렌더링된 grapheme 하나가 여러 코드 포인트와 코드 단위로 이뤄질 수 있습니다.

1초 Worker 제한을 통과하면 안전한 정규식인가요?

아닙니다. 이 페이지의 응답성을 지키고 명백히 비싼 사례를 드러낼 뿐입니다. 프로덕션 안전성은 입력 분포, 런타임, 동시성, 패턴 구조, 더 엄격한 자원 제한에 달려 있습니다.

프로덕션 정규식 변경에 어떤 증거를 남겨야 하나요?

정확한 패턴 본문·플래그, 허용·거부 fixture, 일치·캡처 범위, Unicode 사례, 긴 near-match, timeout 동작, 추출·치환 출력, 대상 런타임 테스트를 남기되 민감한 원문은 불필요하게 보관하지 마세요.