Ari.dev

2025.12 - 2026.04

할인 바우처 노출 조건을 스키마로 정리

발급 건마다 개별 분기로 쌓이던 바우처 노출 조건을 조건 키 11종의 선언적 스키마와 단일 필터로 통합했다.

역할
영역 담당 (바우처 노출 정책 / 결제 화면)
  • Next.js
  • TypeScript
  • Zustand
  • React Query

호텔·숙박 도메인 SaaS 기업의 멤버십 서비스에서, 결제 화면의 할인 바우처 노출 로직을 담당했다.

문제

바우처는 백오피스에서 발급되지만, 결제 화면에서 어떤 바우처를 보여줄지는 프론트가 판단한다.

마케팅이 새 바우처를 만들 때마다 조건이 하나씩 붙었다. 특정 지역 전용, 30만 원 이상 결제, 임직원 상품 제외, 특정 패키지 한정, 체크아웃 날짜 제한, 특정 회원 등급만. 그때마다 분기를 새로 쓰는 방식이라 조건이 코드 곳곳에 흩어졌다.

결과적으로 "지금 어떤 바우처가 어떤 조건에서 노출되는가"를 한곳에서 답할 수 없는 상태가 됐다. 개발 환경과 운영 환경의 바우처 ID까지 달라서 확인이 더 어려웠고, 조건을 확인하려면 매번 코드를 열어야 했다.

해결

반복되는 조건이 사실 몇 종류 안 된다는 걸 확인하고, 조건을 선언적 스키마로 뽑았다. 바우처마다 로직을 쓰는 대신 값만 채우게 했다.

조건 키의미
minPrice최소 결제 금액
allowedHotelIds / requiredHotelId / excludedHotelIds사용 가능 업장 허용·단일 지정·제외
excludedTags상품 태그 기반 제외 (임직원 상품 등)
checkoutDateLimit지정일 이후 체크아웃 시 비노출
requiredProdType객실 전용 / 패키지 전용
회원 등급 조건특정 등급 회원에게만 노출
requiredProdId (환경별 변형 포함)특정 상품 한정, 개발·운영 환경 분기

조건 키는 11종이고, 판정은 단일 진입점 하나로 모았다. 환경별 분기는 스키마 안에서 처리해서 호출부가 환경을 알 필요가 없게 했다.

그리고 스키마와 등록된 바우처 전체를 이슈 트래커에 표로 남겼다. 코드를 열지 않아도 운영이 조건을 확인할 수 있게 하는 게 목적이었다.

효과

  • 신규 바우처는 코드 분기 추가 없이 설정 한 벌 추가만으로 노출된다
  • 조건이 한 파일에 모여 있어 "이 바우처가 왜 안 보이는가"를 코드 한 곳에서 추적할 수 있다
  • 운영이 조건표를 직접 보고 확인해, 노출 조건 문의가 개발로 넘어오기 전에 정리된다

범위

바우처의 발급과 정책 원천은 백오피스(서버) 설정이다. 프론트가 맡은 범위는 결제 화면에서의 노출·사용 가능 여부 판정까지다. 정책을 프론트가 정의한 것이 아니라, 이미 정해진 정책을 화면에 일관되게 반영할 구조를 만든 작업이다.