[TroubleShooting] 공백때문에 예약이 실패한다고? - 정규표현식 검증 불일치 이슈 해결기

📍 공백때문에 예약이 실패한다고? - 정규표현식 검증 불일치 이슈 해결기

문제 상황

특정 상품을 예약하기위해 해당 아이템을 선택하여 예약결제페이지에서 예약폼을 모두 채우고 예약하기 버튼을 누르면 예약생성요청에 실패하는 현상이 있었다. CS 로그를 확인해보니 공통적으로 LASTNAME 필드에 공백을 포함하면 예약에 실패한다는 의견이 많았다.

 

DataDog 에러 로그를 살펴본 결과, 백엔드에서 LASTNAME 필드 검증 시 /[\\S]{1,128}/ 정규표현식에 통과하지 못하면서 요청이 거절되고 있었다.

대안 분석

1. 공급사에 정규표현식 수정 요청

• 장점: 사내 개발 리소스를 사용하지 않아도 된다. (버티컬 작업을 필요로하지 않음. )
• 단점: 공급사에서 즉각 대응해줄 보장이 없고 “다른 판매처에도 영향이 간다”는 이유로 협의가 지연될 가능성이 높다. 또한 수정 전까지 해당 상품을 판매 중단해야 하므로 매출 손실이 발생한다.

2. 프론트엔드에서 매핑 테이블로 대응

• 장점: 내부 리소스로 신속히 대응 가능하다.
• 단점: 서버에 의존성이 있는 정규표현식 로직 일부를 프론트로 가져오므로 코드 일관성이 깨질 수 있다.

그런데 왜 이런 문제가 생겼을까?

2번 방법을 선택하기 전에, 원인을 명확히 파악하고 싶었다.

 

DB를 조회해보니, 전체 예약 결제 페이지 접근자 중 약 4%가 해당 정규표현식을 사용하는 상품을 예약하고 있었다. 적지 않은 비율이었고

 

이슈의 핵심은 “프론트에서는 통과하는데 백엔드에서는 실패한다”는 점이었다. 프론트에서도 같은 정규식을 사용하고 있음에도 결과가 달랐던 이유를 추적해보니

 

👉 자바스크립트의 RegExp.test 메서드는 부분 매칭(partial match) 방식을 사용한다는 점을 확인했다.

 

즉, 문자열 전체가 아니라 일부분만 일치해도 true를 반환한다. 예를 들어 YEONG WOO라는 문자열은 중간에 공백이 있지만, 앞부분 YEONG이 /[\S]{1,128}/ 조건을 만족하므로 통과된다.

 

반면 백엔드(Kotlin)의 regex.matches()는 문자열 전체 일치(full match) 를 검사한다. 결국 동일한 정규식이 프론트에서는 통과하고, 백엔드에서는 실패하는 불일치가 발생한 것이다.

그래서 어떻게 해결했어?

자바스크립트에서 문자열 전체를 검증하려면 정규식 양 끝에 앵커(^, $) 를 추가해야 한다.
따라서 프론트엔드에서는 아래처럼 정규식 매핑 테이블을 만들어 불완전한 패턴을 교정했다.

/** 불완전한 정규식 패턴을 올바른 형식으로 매핑하는 테이블 */
export const REGEX_NORMALIZATION_MAP: Record<string, string> = {
  '/[\\S]{1,128}/': '/^[\\S]{1,128}$/',
}

 

참고: 현재 DB상에서는 {1,128}만 존재하지만, 추후 다른 숫자 범위가 추가될 가능성을 고려해
\d 패턴을 활용하는 확장도 검토 중이다.

결론

작업 규모 자체는 크지 않았지만, 이슈 발견 → 원인 분석 → 대안 비교 → 해결의 흐름을 직접 경험한 의미 있는 케이스였다. 특히, “같은 정규식이 언어별로 다르게 동작할 수 있다”는 점을 다시금 깨달았고, 프론트엔드에서 서버 로직을 일부 이식할 때는 언어 간 차이를 반드시 고려해야 한다는 교훈을 얻었다.