PromptRecipe 로고PromptRecipe
메뉴

프롬프트 작성법

정규 표현식 생성과 패턴 설명을 위한 프롬프트 작성 가이드

AI에게 정확한 정규 표현식을 생성하고 패턴의 동작 원리까지 명확히 설명받는 프롬프트 작성법을 단계별 예시와 함께 알아봅니다.

소개

정규 표현식(Regex)은 이메일, 전화번호, URL, 날짜, 파일명처럼 일정한 규칙을 가진 텍스트를 찾고 검증하며 치환하는 데 쓰는 강력한 패턴 언어입니다. 하지만 대괄호, 소괄호, 수량자, 이스케이프 문자처럼 비슷해 보이는 기호가 많아 작은 실수도 큰 오작동으로 이어지기 쉽습니다. AI에게 정규 표현식을 요청할 때도 단순히 “이메일 정규식 만들어 줘”라고만 말하면, 사용하는 언어와 엔진의 차이, 허용 범위, 예외 조건이 빠진 범용 답변을 받을 가능성이 큽니다.

이 가이드는 AI를 정규식 생성기만이 아니라 검토자와 설명자로 활용하는 방법을 다룹니다. 목표는 복잡한 패턴을 무작정 외우는 것이 아니라 요구사항을 정확히 전달하고 결과를 테스트하며 필요한 수정 요청을 반복할 수 있는 프롬프트를 만드는 것입니다. 정규식의 품질은 패턴 자체보다 먼저 요구사항의 경계가 얼마나 분명한지에 달려 있습니다.

핵심 개념

정규식은 “형식”을 표현한다

정규식은 텍스트가 특정 형식을 따르는지 판별하거나 문서 안에서 원하는 조각을 찾아내는 데 적합합니다. 예를 들어 한국 휴대전화 번호를 찾는 경우 010으로 시작해야 하는지 하이픈은 선택 사항인지, 공백을 허용하는지 국제 표기 +82도 받을 것인지에 따라 전혀 다른 패턴이 필요합니다. 따라서 프롬프트에는 “무엇을 찾는가”뿐 아니라 “무엇을 절대 허용하지 않는가”도 포함해야 합니다.

특히 검증(validation)과 검색(search)을 구별해야 합니다. 전체 입력값이 형식과 정확히 일치해야 한다면 시작 앵커 ^와 끝 앵커 $가 필요할 수 있습니다. 반대로 긴 문장 속에서 여러 값을 찾아내려는 목적이라면 앵커가 오히려 방해가 됩니다. 전체 값 검증과 문서 내 검색은 같은 정규식 문제처럼 보여도 목표가 다릅니다.

정규식 엔진과 실행 환경

정규식 문법은 상당 부분 공통적이지만 JavaScript, Python, PCRE, .NET, Java, PostgreSQL처럼 엔진마다 지원 기능과 이스케이프 방식이 다릅니다. 예를 들어 룩비하인드(lookbehind)는 환경에 따라 지원 수준이 다르며, 문자열 리터럴 안에 정규식을 작성할 때는 백슬래시를 한 번 더 이스케이프해야 할 수 있습니다. AI에게는 반드시 대상 언어, 실행 위치, 정규식 표기 형태를 알려 주세요.

“JavaScript의 /.../ 리터럴로 쓸 것인지”, “Python의 raw string으로 쓸 것인지”, “HTML pattern 속성에 넣을 것인지”는 결과의 모양을 바꿉니다. 정규식 패턴과 프로그래밍 언어 문자열은 서로 다른 두 겹의 문법입니다.

탐욕성, 그룹, 경계의 이해

.* 같은 수량자는 매우 넓은 범위를 잡을 수 있습니다. 편리하지만 예상보다 많은 문자를 삼켜 버리는 탐욕적 매칭 문제를 만들기 쉽습니다. 캡처 그룹 (...)은 필요한 부분을 추출할 때 유용하고 비캡처 그룹 (?:...)은 구조만 묶고 결과 그룹 번호는 늘리지 않을 때 적합합니다. 단어 경계 \b, 문자 클래스 [A-Z], 부정 문자 클래스 [^0-9], 선택 사항 ?, 반복 범위 {2,5}도 요구사항을 정밀하게 표현하는 핵심 도구입니다.

AI에게 설명을 요청할 때는 패턴 전체의 의미만 묻지 말고 각 토큰이 소비하는 문자, 그룹의 역할, 실패하는 입력 사례까지 요청하는 편이 좋습니다. 그러면 복사해서 쓰는 패턴이 아니라 유지보수할 수 있는 패턴을 얻을 수 있습니다.

단계별 가이드

1단계: 자연어 요구사항을 체크리스트로 분해하기

먼저 원하는 입력 형식을 문장으로 적은 뒤, AI가 판단할 수 있는 조건으로 나눕니다. 예를 들어 “영문 소문자, 숫자, 하이픈만 사용하는 3~20자 사용자명”이라는 요구에는 허용 문자, 최소 길이, 최대 길이, 시작·끝 규칙, 금지 사례가 포함됩니다. 하이픈으로 시작하거나 끝나는 값을 막아야 한다면 그 조건도 별도로 기록해야 합니다.

좋은 요청에는 보통 다음 정보가 들어갑니다.

  • 사용 목적: 전체 검증, 텍스트 검색, 추출, 치환 중 무엇인지
  • 대상 엔진: JavaScript, Python, PCRE 등
  • 허용 형식: 문자 종류, 길이, 구분자, 공백 처리
  • 예외와 금지 형식: 반드시 실패해야 하는 사례
  • 원하는 결과물: 정규식, 코드 예제, 토큰별 해설, 테스트 표
성공 예시와 실패 예시를 함께 제공하면 AI의 해석 여지가 크게 줄어듭니다.

2단계: 제약 조건이 드러나는 프롬프트 작성하기

정규식을 생성해 달라는 요청은 한 번에 모든 것을 압축하려 하지 않는 편이 좋습니다. 먼저 형식 규칙을 명시하고 이어서 출력 형식을 제한합니다. 예를 들어 “JavaScript 기준으로 작성하고 정규식 리터럴과 각 구성 요소 해설, 통과·실패 테스트를 순서대로 제공해 줘”라고 요청하면 바로 활용 가능한 답변을 받기 쉽습니다.

다음 프롬프트 골격을 활용해 보세요.

당신은 [정규식 엔진] 전문가입니다.
목적은 [전체 검증/검색/추출/치환]입니다.
대상 형식은 다음 조건을 만족해야 합니다.
1. ...
2. ...
3. ...

반드시 통과해야 하는 예시: ...
반드시 실패해야 하는 예시: ...

정규식 1개를 제시하고 각 토큰의 역할을 한국어로 설명해 주세요.
가능하면 과도한 백트래킹 위험을 피하고 [언어] 코드 예제와 테스트 결과 표도 포함해 주세요.

이 골격에서 가장 중요한 부분은 “반드시 실패해야 하는 예시”입니다. 정규식은 통과 사례만 보고 만들면 너무 느슨한 패턴이 나오기 쉽습니다. 금지 입력은 정규식의 보안성과 정확도를 정의하는 명세입니다.

3단계: AI에게 패턴 후보와 설계 근거를 함께 요청하기

요구가 조금만 복잡해져도 하나의 정답만 요청하기보다 두세 가지 접근을 비교하게 하는 것이 좋습니다. 예를 들어 URL 검증은 완전한 표준 준수가 필요한지, 서비스 화면에서 가벼운 형식 확인만 필요한지에 따라 패턴 복잡도가 크게 달라집니다. AI에게 “실무용 간단 검증안과 엄격 검증안의 차이, 각 안의 한계”를 요청하면 목적에 맞게 선택할 수 있습니다.

이때 “가장 짧은 정규식”을 목표로 삼지 마세요. 짧은 패턴이 항상 읽기 쉽거나 안전한 것은 아닙니다. 특히 중첩된 반복과 모호한 선택지는 성능 문제를 일으킬 수 있습니다. 읽기 쉬우면서 테스트 가능한 패턴이 짧지만 불투명한 패턴보다 실무에서 더 가치 있습니다.

4단계: 테스트 케이스로 반례 확인하기

AI가 만든 정규식을 받으면 곧바로 운영 환경에 넣지 말고 통과·실패·경계 사례로 나누어 확인해야 합니다. 최소 길이보다 하나 짧은 값, 최대 길이보다 하나 긴 값, 허용되지 않은 유니코드 문자, 줄바꿈, 앞뒤 공백, 중복 구분자 등을 테스트하세요. 검색 목적이라면 문장 중간, 문장 끝, 다른 문자에 붙은 상황도 확인해야 합니다.

AI에게 다음처럼 후속 요청을 하면 검토 품질이 좋아집니다.

아래 정규식을 비판적으로 리뷰해 주세요.
특히 잘못 통과할 입력, 잘못 거부할 입력, 성능상 위험한 입력을 각각 3개 이상 제시하세요.
그 후 요구사항을 유지한 개선안을 제안하고 변경 이유를 설명해 주세요.

5단계: 설명을 문서화 가능한 형태로 변환하기

팀에 공유하거나 나중에 다시 수정할 정규식이라면, 패턴 옆에 자연어 명세와 예시를 남겨야 합니다. AI에게 토큰별 설명뿐 아니라 “이 정규식이 보장하는 것”과 “보장하지 않는 것”을 분리해 달라고 요청하세요. 예를 들어 이메일 정규식이 이메일 주소처럼 보이는 문자열을 확인할 수는 있어도 실제 도메인이 존재하는지 사용자가 소유한 주소인지는 검증하지 못한다는 한계를 명시해야 합니다.

실전 예시

예시 1: 사용자명 전체 검증

다음은 서비스 가입 폼의 사용자명을 검증하려는 상황입니다. 조건은 영문 소문자와 숫자, 단일 하이픈만 허용하고 길이는 3~20자이며 하이픈으로 시작하거나 끝날 수 없다는 것입니다.

JavaScript 정규식이 필요합니다. 가입 폼에서 사용자명 전체를 검증합니다.
영문 소문자와 숫자를 사용하고 단어 사이에만 하이픈 1개를 허용합니다.
길이는 3~20자이며 하이픈으로 시작하거나 끝나면 안 됩니다.
통과: mina, user-2026, a1-b2
실패: -mina, mina-, mi, user--name, MINA, min_a
정규식 리터럴, 토큰별 설명, test() 예제, 실패 원인을 포함해 답변해 주세요.

이 요청은 문자 범위와 길이뿐 아니라 연속 하이픈 금지까지 명확히 합니다. 결과를 받은 뒤에는 a--b, a-, -a, 21자 문자열처럼 경계값을 추가 검증하세요. 사용자가 한글 사용자명을 입력할 가능성이 있다면 요구사항에서 한글을 금지할지 허용할지도 명시해야 합니다.

예시 2: 로그에서 주문 번호 추출

주문 번호가 ORD-2026-000123 형식으로 로그 문장 안에 섞여 있다고 가정해 보겠습니다. 이 경우는 전체 검증이 아니라 추출이므로 ^$를 붙이면 안 됩니다. 또 연도는 2025 또는 2026만 허용하고 마지막 번호는 정확히 6자리여야 한다는 제약을 전달해야 합니다.

Python re 모듈로 서버 로그에서 주문 번호를 모두 추출할 정규식을 작성해 주세요.
형식은 ORD-연도-6자리숫자이며 연도는 2025 또는 2026만 허용합니다.
긴 식별자 ORD-2026-0001234의 일부가 잘못 매칭되지 않도록 경계를 고려해 주세요.
findall() 코드와 캡처 그룹 결과가 어떻게 반환되는지도 설명해 주세요.

이 프롬프트는 “부분 매칭 방지”라는 중요한 품질 기준을 포함합니다. AI가 단어 경계 또는 숫자 뒤를 확인하는 조건을 제안할 수 있으며 선택한 방식이 하이픈 같은 비단어 문자와 어떻게 상호작용하는지도 설명받아야 합니다.

예시 3: 개인정보 마스킹용 치환

정규식은 찾기뿐 아니라 치환에도 많이 사용됩니다. 이메일의 아이디 일부를 마스킹하려는 경우, 너무 단순한 패턴은 짧은 아이디에서 원본을 노출하거나 여러 이메일을 한꺼번에 잡을 수 있습니다. 따라서 캡처 그룹과 치환 규칙까지 함께 요청해야 합니다.

JavaScript에서 문장 속 이메일 주소를 마스킹하는 정규식과 replace 콜백을 작성해 주세요.
아이디가 4자 이상이면 앞 2자와 마지막 1자만 남기고, 3자 이하면 첫 글자만 남깁니다.
도메인은 유지합니다. 여러 이메일이 포함된 문장도 처리해야 합니다.
정규식만으로 처리하기 어려운 조건은 JavaScript 함수에서 처리하고 각 단계의 책임을 설명해 주세요.

이 사례의 핵심은 모든 규칙을 정규식 하나에 억지로 넣지 않는 것입니다. 정규식은 이메일 후보를 분리하고 길이에 따른 마스킹은 코드에서 처리하면 읽기와 유지보수가 훨씬 쉬워집니다. 정규식은 구조를 찾는 도구이고, 복잡한 업무 규칙은 일반 코드로 분리하는 편이 안전합니다.

프로 팁과 문제 해결

설명이 너무 일반적일 때

AI가 “이 패턴은 이메일을 검증합니다”처럼 피상적으로 답한다면 토큰 단위 설명을 강제하세요. “각 괄호 그룹이 무엇을 캡처하는지 ?가 어느 요소를 선택 사항으로 만드는지, 앵커를 제거하면 어떤 입력이 달라지는지”를 질문하면 훨씬 교육적인 답을 얻을 수 있습니다. 또한 정규식을 사람이 읽기 좋은 확장 모드로 재작성해 달라고 요청할 수도 있습니다. 단, 확장 모드 지원 여부는 엔진마다 다르므로 환경을 다시 확인해야 합니다.

이스케이프가 두 번 적용될 때

정규식을 코드 문자열로 전달하면 \d가 실제로는 \\d처럼 보여 혼란스러울 수 있습니다. 이는 정규식 문법과 문자열 문법이 동시에 적용되기 때문입니다. JavaScript 리터럴 /\d+/와 문자열 생성자 new RegExp('\\d+')는 작성 형태가 다릅니다. AI에게 “리터럴 버전과 문자열 버전을 나란히 보여 주고 차이를 설명해 달라”고 요청하면 실수를 줄일 수 있습니다.

성능이 느리거나 입력이 길 때

중첩된 수량자, 예를 들어 반복 그룹 안에 다시 넓은 반복을 넣는 패턴은 특정 실패 입력에서 백트래킹이 급격히 증가할 수 있습니다. 사용자가 입력하는 폼, 외부에서 받은 텍스트, 대량 로그처럼 신뢰하기 어려운 입력을 다룰 때는 특히 주의해야 합니다. AI에게 “이 패턴에 ReDoS 위험이 있는지 선형적으로 검증할 수 있는 구조로 바꿀 수 있는지”를 검토 요청하세요. 외부 입력에 쓰는 정규식은 정확성뿐 아니라 최악의 경우 성능까지 검토해야 합니다.

표준을 정규식 하나로 완벽히 검증하려 할 때

URL, 이메일, 날짜, HTML 같은 형식은 표준이 복잡합니다. 이메일의 실제 전달 가능성이나 URL의 네트워크 접근 가능성은 정규식만으로 판단할 수 없습니다. 날짜도 2026-02-31처럼 모양은 맞지만 존재하지 않는 값을 통과시킬 수 있습니다. 이런 경우에는 정규식으로 1차 형식을 걸러내고 언어의 날짜 파서나 전용 라이브러리로 2차 검증하는 설계를 AI에게 요청하세요.

결론

AI를 이용한 정규식 작성의 핵심은 “패턴을 만들어 달라”는 단문 요청이 아니라 목적과 경계, 실행 환경, 반례, 원하는 설명 형식을 함께 제공하는 데 있습니다. 전체 검증인지 검색인지 먼저 정하고 통과할 값과 실패할 값을 명시한 뒤, 엔진별 문법과 코드 이스케이프까지 지정하세요. 생성 후에는 경계값과 악의적인 긴 입력으로 검증하고 패턴이 보장하지 않는 범위도 문서화해야 합니다.

좋은 정규식은 복잡한 기호의 집합이 아니라 명확한 요구사항을 압축한 결과물입니다. AI에게 설계 근거와 반례를 요구하는 습관을 들이면, 더 정확하고 설명 가능한 패턴을 빠르게 만들 수 있습니다. 정규식 프롬프트의 최종 목표는 그럴듯한 한 줄이 아니라 검증 가능한 규칙입니다.

핵심 요약

  • 정규식 요청 전에 검증, 검색, 추출, 치환 중 목적을 먼저 구분합니다.
  • 대상 언어와 정규식 엔진, 리터럴 또는 문자열 표기 방식을 반드시 지정합니다.
  • 통과 예시와 실패 예시를 함께 제공해 허용 범위를 분명히 합니다.
  • AI에게 패턴뿐 아니라 토큰별 설명, 반례, 성능 위험, 테스트 코드까지 요청합니다.
  • 복잡한 업무 규칙과 실제 유효성 검사는 정규식 하나에 몰아넣지 말고 일반 코드 및 전용 검증 도구와 조합합니다.

자주 묻는 질문 (FAQ)

Q. 정규식 생성 프롬프트에 꼭 언어를 적어야 하나요?
네. JavaScript, Python, PCRE 등은 지원 문법과 이스케이프 방식이 달라 대상 환경을 적는 것이 좋습니다.
Q. 통과 예시만 제공해도 충분한가요?
아닙니다. 잘못 허용되면 안 되는 실패 예시를 함께 제시해야 패턴의 경계를 정확히 정할 수 있습니다.
Q. 이메일 주소는 정규식만으로 완전히 검증할 수 있나요?
아니요. 형식 점검은 가능하지만 실제 존재 여부와 수신 가능 여부는 별도 확인 절차가 필요합니다.