이 글은 제가 개발·운영하는 Pattern Studio의 사용 안내입니다.
가입 폼의 이메일 검사나 글 주소용 슬러그 규칙을 만들 때, 검색이나 AI가 내놓은 정규식을 바로 붙이고 싶어집니다. 하지만 예제 하나가 통과하는 것과 제품의 입력 정책에 맞는 것은 다른 문제입니다.
혼자 개발할 때도 입력 규칙을 검토하는 과정은 필요합니다. Pattern Studio에서 폼 검증 패턴을 만든 뒤 Regex Lab에서 성공·실패 입력을 비교하고, 확인한 코드를 앱에 옮깁니다.
먼저 허용할 입력을 말로 정하기
예를 들어 ‘슬러그에 하이픈을 쓸 수 있다’만으로는 규칙이 충분하지 않습니다. 앞뒤 하이픈, 대문자, 밑줄, 최소 길이도 정해야 합니다. 생성된 템플릿은 이런 제품 정책을 대신 결정하지 않습니다. 패턴을 받기 전에 통과해야 할 값과 거절해야 할 값을 적어두세요.
폼 생성기로 시작하기
Pattern Studio의 Workflows에서 ‘폼 검증 패턴 생성기’를 엽니다. 지역과 필드 타입을 고르고 엄격 모드 옵션을 확인합니다. 처음에는 이메일을 선택하면 출력 구조를 이해하기 쉽습니다.
다음 단계에는 정규식 패턴, 샘플 입력, HTML 예시, JS 예시가 나옵니다. 각 결과를 따로 복사할 수 있고, ‘Regex Lab로 보내기’로 패턴과 예제를 이어서 살펴볼 수 있습니다. 폼 생성기에는 별도의 파일 다운로드 버튼 대신 복사와 전달 기능이 제공됩니다.
한 개의 성공 예제에서 멈추지 않기
이메일 패턴을 Regex Lab로 보냈다면 다음 입력을 줄바꿈으로 구분해 비교해봅니다.
hello@example.com
support@test.co.kr
not-an-email
user@domain이 예제의 목적은 기본 이메일 형식 규칙의 경계를 보는 것입니다. PASS는 실제 메일함의 존재나 발송 가능 여부를 뜻하지 않습니다. 별도로 요구하는 국제화 주소 정책이 있다면 그 예제도 검토해야 합니다.
분석 기준은 ‘분리된 값’과 ‘원본’을 구분합니다. 여러 줄에서 각 값을 판정하려는 작업인지, 긴 원문에서 일부 문자열을 찾는 작업인지에 따라 기대 결과가 달라집니다. 특히 ^와 $ 같은 앵커, g·m 같은 플래그를 바꿨다면 테스트 조건도 함께 확인하세요.
코드를 옮긴 뒤에도 실제 환경에서 확인하기
폼 생성기의 HTML 예시와 JS 예시는 적용을 위한 출발점입니다. Regex Lab의 코드 생성에서는 다른 언어용 예시도 확인할 수 있지만, 대상 언어의 정규식 문법과 실행 방식은 같지 않을 수 있습니다. 브라우저 결과를 그대로 서버 검증의 보증으로 삼지 마세요.
클라이언트 검증은 입력을 돕는 역할을 하고, 서버에서는 별도의 검증이 필요합니다. HTML pattern은 브라우저 폼의 검사 방식이 있고 JS의 test는 작성한 정규식에 따라 부분 일치를 허용할 수도 있으므로, 실제 폼과 서버 코드에서 같은 예제로 다시 시험하는 편이 좋습니다.
기술 참고: MDN의 HTML pattern 설명에 따르면 값 전체를 검사하며 v 플래그를 사용합니다. 문자 클래스의 하이픈 등은 이 문법에 맞게 이스케이프해야 합니다. JavaScript test 설명과 비교해, 생성 예시를 실제 적용 환경에서 점검하세요.
재현 가능한 검토 흐름 남기기
다시 쓸 패턴은 이름을 붙여 라이브러리에 저장할 수 있습니다. 이 저장은 해당 브라우저 기준이며 계정 간 동기화 기능으로 보기는 어렵습니다. 공유 링크는 패턴과 입력을 함께 전달하므로 합성 예제만 넣어 공유하세요.
폼 패턴을 만든 뒤 실패 예제도 함께 테스트해보세요. 허용하거나 거절할 입력을 설명하고, 같은 예제로 결과를 재현할 수 있어야 합니다.