쿠폰 로직의 함정: 카트를 망가뜨리지 않는 스택 규칙

프로모 로직이 자주 깨지는 이유

프로모는 실전 결제 흐름에 넣기 전엔 간단해 보입니다. 하지만 카트는 계속 변하고, 할인 규칙은 종종 일회성 규칙으로 작성됩니다. 바로 그 간극에서 대부분의 쿠폰 로직 함정이 발생합니다.

문제의 핵심은 단 하나의 새 규칙이 모든 합계에 영향을 줄 수 있다는 점입니다. “세일 상품 제외 10%”를 추가하면 ‘세일’의 의미, 언제 확인할지, 그리고 10%가 어느 금액에 적용되는지를 결정해야 합니다. 다른 프로모가 같은 상품을 건드리면 적용 순서가 중요해지고, 순서에 따라 가격이 달라집니다.

많은 팀이 수학(계산)과 비즈니스 규칙을 섞어 둡니다. 예를 들어 “할인은 소계로 캡(capped)”이라는 빠른 수정이 코드 곳곳에 복사되면, 곧 카트 페이지, 체크아웃, 인보이스, 이메일 등 어디서 계산하느냐에 따라 답이 달라집니다.

시스템이 가격을 재계산하는 순간들이 특히 위험합니다:

• 카트 업데이트: 수량 변경, 아이템 삭제, 배송 방법 변경
• 결제 후 편집: 주소 변경, 부분 취소, 상품 대체
• 환불 및 반품: 아이템별 비례 배분, 세금 조정, 스토어 크레딧
• 다중 통화나 세금 모드 변경: 순가격 대 총가격, 세금 포함 합계

작은 예: 쇼핑객이 번들을 담고 “$100 이상 $20 할인” 코드를 적용한 뒤 아이템 하나를 제거합니다. 코드가 이전 소계를 "기억"하고 있다면 $85 카트에 $20 할인을 적용하거나 아이템 라인이 음수가 될 수 있습니다.

이 글을 다 읽으면 가장 흔한 프로모 실패(중복 할인, 화면 간 불일치, 음수 합계, 제외된 아이템에 적용되는 할인, 실제 결제와 맞지 않는 환불)를 예방할 수 있습니다.

명확한 스택 규칙과 우선순위 규칙으로 시작하세요

대부분의 쿠폰 로직 함정은 단 한 문장이 빠져 있기 때문에 시작됩니다: 어떤 할인들이 함께 적용될 수 있고, 어떤 순서로 적용되는가. 스택 규칙을 평이한 언어로 설명할 수 없다면 카트는 결국 이상한 동작을 합니다.

스택 규칙은 간단한 예/아니오 문장으로 정의하세요. 예: “주문당 수동 쿠폰 1개만 허용. 쿠폰이 자동 프로모를 차단한다고 명시하지 않는 한 자동 프로모는 여전히 적용될 수 있다.” 이 한 줄이 중복 할인으로 이어지는 임의 조합을 막아 줍니다.

초기에 아이템 수준 할인과 주문 수준 할인을 분리하세요. 아이템 수준 규칙은 특정 상품의 가격을 바꾸고(예: 신발 20% 할인), 주문 수준 규칙은 총합을 바꿉니다(예: 카트 $10 할인). 구조 없이 섞어 쓰면 상품 페이지, 카트, 체크아웃 간에 합계가 어긋납니다.

코드를 작성하기 전에 “최선의 혜택”이 무엇인지 정하세요. 많은 팀이 “최대 절감”을 선택하지만, 이는 가격 하한을 깨뜨릴 수 있습니다. “원가 이하로 할인하지 않음”이나 “배송을 음수로 만들지 않음” 같은 규칙도 필요할 수 있습니다. 엔진이 추측하지 않도록 명확한 우승 규칙 하나를 고르세요.

간단한 우선순위 순서는 충돌을 예측 가능하게 만듭니다:

• 자동 프로모 먼저(카탈로그나 시즌 규칙)
• 수동 쿠폰(고객이 입력한 것) 다음
• 스토어 크레딧이나 기프트 카드 마지막(지불수단, 할인이 아님)
• 세금과 배송은 할인 적용 후 재계산

예: 카트에 모든 품목에 자동 10% 프로모와 고객이 입력한 $100 이상 주문 시 $15 할인 쿠폰이 있다면, 우선순위가 자동 프로모 먼저라면 $100 기준을 사전 할인 소계로 할지, 할인 후 소계로 할지 명확히 할 수 있습니다. 적어 두고 모든 곳에서 일관되게 유지하세요.

이 선택들을 문서화하면 쿠폰 스택 규칙은 숨겨진 동작이 아닌 테스트 가능한 규칙이 됩니다. 이것이 쿠폰 로직 함정을 피하는 가장 빠른 방법입니다.

할인을 단순하고 명시적인 데이터로 모델링하세요

많은 쿠폰 로직 함정은 할인 규칙이 체크아웃 코드 곳곳의 if-else로 흩어져 있을 때 시작됩니다. 더 안전한 접근은 모든 프로모를 타입, 적용 범위, 한도 같은 명확한 데이터로 취급하는 것입니다. 그러면 카트 계산은 작고 예측 가능한 평가기로 바뀝니다.

먼저 마케팅 문구가 아닌 할인 타입에 이름을 붙이세요. 대부분의 프로모는 몇 가지 형태에 들어맞습니다: 비율 할인, 고정 금액 할인, 무료 아이템(또는 X개 구매 시 Y개 무료), 무료 배송. 프로모를 이런 타입으로 표현하면 테스트하기 어려운 특수 사례를 피할 수 있습니다.

다음으로 스코프(적용 대상)를 명확히 하세요. 같은 퍼센트 할인도 대상에 따라 매우 다르게 동작합니다. 전체 주문, 카테고리, 특정 상품, 한 라인 아이템, 또는 배송에 적용되는지 정의하세요. 스코프가 불명확하면 잘못된 소계에 할인이 적용되거나 중복 할인이 발생합니다.

제약은 코드 주석이 아니라 필드로 캡처하세요. 흔한 제약은 최소 구매액, 첫 주문 전용, 기간 범위 등입니다. 또한 세일 가격과의 동작(세일 위에 중첩, 원가에 적용, 세일 제외)도 기록하세요.

간결한 규칙 스키마 예시는 다음을 포함할 수 있습니다:

• type (percent, fixed, free_item, free_shipping)
• scope (order, category, product, item, shipping)
• constraints (min_spend, first_order, start_at, end_at)
• floors (min_total = 0, min_item_price, optional min_margin)
• rounding policy (per item vs per order)

마지막으로 엔진이 항상 존중해야 할 가격 하한을 추가하세요: 총합은 절대 0 미만이 되지 않게 하고, 비즈니스가 필요하면 아이템 가격은 원가 이하로 내려가지 않도록 합니다. 이를 빌트인으로 하면 음수 합계나 ‘고객에게 돈을 주는’ 엉뚱한 상황을 막을 수 있습니다.

Koder.ai에서 할인 엔진을 프로토타입한다면, 플래닝 모드에서 이러한 필드를 가시화해 평가기가 더 많은 프로모를 추가해도 단순하고 테스트 가능하게 유지되도록 하세요.

단계별: 프로모를 안전하게 평가하는 방법

대부분의 쿠폰 로직 함정은 적격성 검사와 계산이 뒤섞일 때 시작됩니다. 더 안전한 패턴은 두 단계로 분리하는 것입니다: 먼저 적용될 수 있는 것(eligibility)을 결정하고, 그다음 금액을 계산합니다. 이 분리는 규칙을 읽기 쉽게 하고 음수 합계 같은 나쁜 상태를 예방하기 쉽게 만듭니다.

결정적 평가 순서

UI나 API에서 프로모가 들어오는 순서와 상관없이 항상 같은 순서를 사용하세요. 결정성은 “왜 이 카트가 바뀌었나?”라는 질문에 답을 줄 수 있게 합니다.

잘 작동하는 간단한 흐름:

• Validate 입력 검사: 프로모 코드 형식, 날짜 범위, 고객 범위, 통화, 가격이 음수인지 여부 등
• Select eligible promos: 자격 여부만 판정(금액은 아직 없음). 후보 목록을 만듭니다.
• Resolve stacking and priority: 스택 규칙 적용(예: 주문 수준 프로모 한 개만 허용)과 동률일 경우 우선순위 결정(우선순위, 최대 가치, 안정적 ID 순)
• Apply calculations: 일관된 기준(세전 vs 세후, 배송 포함 여부)과 반올림 규칙으로 할인 계산
• Summarize totals: 라인 합계에서 주문 총합을 재계산한 뒤 0으로 캡, 최대 할인 한도 적용

분해 내역과 감사 추적을 기록하세요

프로모를 적용할 때 단일 "할인 총액"만 저장하지 마세요. 라인별 및 주문별 분해 내역을 유지해 합계를 대조하고 설명할 수 있게 하세요.

최소한 다음을 기록하세요:

• 어떤 규칙이나 프로모가 적용되었는지(ID와 버전) 및 그 우선순위
• 왜 적용되었는지(예: “category=shoes”, “cart subtotal >= 50” 같은 적격성 사실)
• 무엇을 변경했는지(영향받은 라인 ID, 기준 금액, 할인 금액, 반올림)
• 무엇을 차단했는지(예: “차단된 항목: 이미 아이템 수준 할인 존재”)

예: 카트에 두 개의 아이템이 있고 하나는 이미 세일 중이라면, 1단계에서 해당 쿠폰은 정가 아이템에만 적격으로 표시됩니다. 2단계에서 해당 라인에 10%만 적용하고 세일 라인은 변경하지 않으며, 라인 분해에서 주문 합계를 재계산해 중복 할인 사고를 방지합니다.

스파게티 코드가 되지 않도록 제외 규칙을 인코딩하세요

많은 쿠폰 로직 함정은 제외 규칙이 “if 코드가 X면 Y 건너뛰기” 같은 특수 분기 안에 숨겨질 때 시작됩니다. 한 프로모에 대해서는 작동하지만 다음 프로모가 추가되면 깨집니다.

더 안전한 패턴은 단일 평가 흐름을 유지하고 제외를 계산 전에 프로모 조합을 거부할 수 있는 일련의 검사로 만드는 것입니다. 이렇게 하면 할인이 부분적으로만 적용되는 일이 없습니다.

제외를 분기 대신 데이터로 처리하세요

행동을 하드코딩하는 대신 각 프로모에 작은 명시적 "호환성 프로필"을 부여하세요. 예: 프로모 유형(쿠폰 vs 자동 세일), 스코프(아이템, 배송, 주문), 조합 규칙 등.

다음을 지원하세요:

• “결합 불가” 목록(denylist): 프로모 A가 프로모 B를 차단
• “결합 허용” 목록(allowlist): 프로모 A가 이름이 지정된 세트와만 스택 가능
• “자동 세일 차단” 또는 “다른 쿠폰 불허” 같은 규칙 플래그

핵심은 엔진이 모든 프로모에 대해 같은 질문을 하고, 그 후 집합이 유효한지 결정하게 하는 것입니다.

충돌을 명시적으로 처리하세요(자동 세일 포함)

자동 세일은 종종 먼저 적용되고, 그 뒤 쿠폰이 들어와 조용히 덮어쓰는 일이 발생합니다. 미리 어떤 동작을 할지 결정하세요:

• 쿠폰이 세일 위에 중첩된다
• 쿠폰은 세일이 아닌 항목에만 적용된다
• 세일이 존재하면 쿠폰이 거부된다

프로모마다 하나를 선택하고 이를 계산 경로가 아닌 검사로 인코딩하세요.

서로 대칭적이어야 하는 충돌(예: “WELCOME10은 FREESHIP과 결합 불가”)이라면 양쪽 방향 모두 차단되도록 명시적으로 인코딩하세요. 비대칭인 경우 의도적이고 가시적으로 만드세요.

예: 사이트 전체 15% 자동 세일이 진행 중이고 고객이 정가 품목에만 적용되는 20% 쿠폰을 입력했다면, 쿠폰은 계산 전에 세일 품목을 거부하도록 검사화해야 하지, 먼저 할인하고 나중에 수치를 고치려 해서는 안 됩니다.

Koder.ai 같은 플랫폼에서 할인 규칙을 빌드하면 이 검사들을 별도의 테스트 가능한 레이어로 유지해 수학 로직을 다시 쓰지 않고 규칙을 변경할 수 있습니다.

합계 불일치를 일으키는 엣지 케이스

대부분의 쿠폰 분쟁은 헤드라인 할인 자체가 아니라 동일한 카트를 두 가지 약간 다른 방식으로 계산했을 때 발생합니다. 고객은 카트에서 하나의 숫자를 보고 체크아웃에서 다른 숫자를 보게 됩니다.

작업 순서를 고정하는 것부터 시작하세요. 아이템 수준 할인이 주문 수준 할인보다 먼저 발생하는지, 배송은 어디에 들어가는지 문서화하세요. 일반적인 규칙은: 아이템 할인 먼저, 남은 소계에 주문 할인 적용, 마지막으로 배송 할인입니다. 무엇을 선택하든 합계를 표시하는 모든 곳에서 동일한 순서를 사용하세요.

세금은 다음 함정입니다. 가격에 세금이 포함되어 있으면 할인은 세금 부분도 줄입니다. 세금이 별도로 계산되는 모델이면 할인 후에 세금을 계산합니다. 흐름의 다른 부분에서 이 모델을 섞어 쓰면 두 계산이 모두 올바르더라도 세금 기반이 달라 불일치가 발생하는 고전적 함정입니다.

반올림 문제는 작아 보이지만 큰 고객 지원 이슈를 만듭니다. 라인별 반올림(각 SKU에 할인 후 반올림)인지 주문 수준에서만 반올림할지 결정하고 통화 소수 자릿수에 맞춰 고수하세요. 퍼센트 쿠폰은 저가 품목이 많을수록 라인 반올림과 주문 반올림 간에 센트 단위 차이가 날 수 있습니다.

명시적으로 처리할 가치가 있는 엣지 케이스는 다음과 같습니다:

• 환불과 부분 환불: 할인을 아이템별로 비례 배분해 환불이 실제 지불액을 초과하지 않도록 함
• 쿠폰 적용 후 카트 편집: 아이템 추가/삭제 시 적격성 및 상한 재평가
• 배송 변경: 주소나 방법 변경은 과세 금액과 배송 할인 적격성에 영향
• 수량 변경: 동일 아이템 수량 증가로 임계값(예: 최소 구매액, X개 구매 시 Y개 무료) 초과 가능
• 과세 대상 혼합: 일부 품목은 비과세일 수 있지만 쿠폰 적용 대상일 수 있음

구체적 예: 주문 쿠폰 10%와 $50 이상 무료 배송이 함께 있다면 쿠폰을 먼저 적용하면 할인된 소계가 $50 미만이 되어 무료 배송 자격을 잃을 수 있습니다. 하나의 해석을 선택하고 카트, 체크아웃, 환불에서 일관되게 인코딩하세요.

흔한 프로모 버그와 발생 원인

대부분의 쿠폰 로직 함정은 카트가 둘 이상의 경로로 평가될 때 드러납니다. 어떤 프로모는 한 곳에서 라인 아이템 수준으로 적용되고 다른 곳에서 주문 수준으로 또 적용되어 둘 다 개별적으로는 “정상”으로 보일 수 있습니다.

자주 발생하는 버그와 그 원인은 다음과 같습니다:

• 동일 아이템에 중복 할인 적용: 동일한 프로모가 아이템 가격에서 한 번 적용되고 주문 합계 계산 시 다시 적용됨. 종종 두 서비스가 모두 친절하게 할인을 적용하기 때문에 발생합니다.
• 음수 총합 또는 음수 라인 아이템: 고정 금액 할인이 적격 금액을 초과하도록 허용되어(예: $12 대상 소계에 $20 할인) 0 미만이 되는 경우
• 이미 할인된 가격에 퍼센트 할인 적용: 규칙은 “정가의 10%”였지만 코드가 현재 가격을 사용해 이미 줄어든 가격에 10%를 적용함
• 최소 구매액을 잘못된 소계로 검사: 규칙이 사전 할인 소계를 검사하는데 비즈니스는 할인 후 소계로 기대함(또는 그 반대)
• 제외된 아이템에도 쿠폰 적용: 적격성 판정이 상품 태그에 의존하는데 태그가 누락되거나 일관성이 없어 미확인 항목이 적격으로 처리됨

구체적 예: 카트에 적격 아이템과 제외된 아이템이 하나씩 있을 때, 엔진이 퍼센트 프로모의 적격 소계를 올바르게 계산했지만 이후 고정 할인액을 전체 주문 합계에서 빼면 제외된 아이템에 사실상 할인이 적용됩니다.

가장 안전한 패턴은 각 프로모를 명시적 "적격 금액"으로 계산하고 경계가 있는 조정값(절대 0 미만이 되지 않음)을 반환하며 무엇을 건드렸는지 명확한 추적을 남기는 것입니다. Koder.ai 같은 도구로 할인 엔진을 생성하면 테스트가 정확히 어떤 라인이 적격이었고 어떤 소계를 사용했는지 단언할 수 있도록 추적 데이터를 출력하게 하세요.

올바른 테스트 스위트로 규칙을 테스트 가능하게 만드세요

대부분의 쿠폰 로직 함정은 테스트가 최종 합계만 확인하기 때문에 드러납니다. 좋은 테스트 스위트는 적격성(이 프로모가 적용되어야 하는가?)과 계산(얼마가 차감되어야 하는가?)을 모두 확인하고, 시간이 지나도 비교할 수 있는 읽기 쉬운 분해 내역을 포함합니다.

작게부터 실제 시나리오까지 테스트를 구축하세요

먼저 한 규칙을 격리한 단위 테스트로 시작하세요. 입력을 작게 유지한 다음 전체 카트 시나리오로 확장하세요.

• 적격성 단위 테스트: 고객 유형, 날짜, 상품 태그, 최소 구매액에서 프로모가 적용되는가?
• 계산 단위 테스트: 주어진 적격 소계에 대해 반올림과 통화 규칙이 일치하는가?
• 시나리오 테스트: 혼합 상품, 수량, 배송, 세금, 경쟁 프로모 몇 개를 포함
• “카트 변경” 테스트: 적용 후 가격이 업데이트되거나 아이템이 제거되거나 수량이 변경된 경우
• 분해 내역 스냅샷 테스트: 최종 합계만이 아니라 라인별 할인 할당을 예상값으로 저장

커버리지가 생기면 몇 가지 “항상 참” 검사를 추가하세요. 이는 당신이 손수 쓰지 못한 이상한 경우를 잡아냅니다.

• 총합은 절대 0.00 미만이 되지 않는다.
• 할인이 총합을 증가시키지 않는다.
• 적용된 할인은 그 적격 기반보다 클 수 없다.
• 적격성이 없는 아이템을 제거해도 할인이 커지면 안 된다.

작은 카트 예시

다음을 가정하세요: $40 셔츠(적격)와 $30 기프트 카드(제외), 배송비 $7. 프로모는 “의류 20% 할인(최대 $15)”과 “$50 이상 주문 시 $10 할인(퍼센트 할인과 스택 불가)”입니다.

시나리오 테스트는 어떤 프로모가 우선하는지(우선순위), 기프트 카드가 제외되는지, 정확한 할당(셔츠의 20% = $8, 배송은 영향 없음, 최종 합계 정확)을 단언해야 합니다. 그 분해 내역을 골든 스냅샷으로 저장해 리팩터링 후에 어떤 프로모가 적용되는지, 제외 항목에 할인이 가는지 조용히 바뀌는 일을 방지하세요.

출시 전 빠른 체크리스트

새 프로모를 배포하기 전, 고객이 즉시 알아차리는 실패(이상한 합계, 혼란스러운 메시지, 맞지 않는 환불)를 잡아내는 최종 점검을 하세요. 이 체크들은 대부분의 쿠폰 로직 함정을 잡아줍니다. 또한 규칙이 모든 카트에서 동일하게 동작하도록 강제합니다.

이 검사들을 소수의 “문제가 자주 발생하는” 카트(한 개 아이템, 다수 아이템, 혼합 세율, 배송, 대량 수량 라인)에서 실행하세요. 카트를 저장해 가격 코드 변경 시마다 다시 돌릴 수 있게 하세요.

대부분의 실패를 잡는 다섯 가지 검사

• 총합에 대한 가드레일: 최종 주문 총합과 각 라인 순가격은 절대 0 미만이 되어서는 안 됩니다. 할인이 적용 가능한 금액을 초과하면 캡하고 캡된 금액을 기록하세요.
• 설명 가능한 수학: 쇼핑객에게 보이는 할인 분해(프로모별, 라인별, 배송별)가 최종 결제 금액과 정확히 합쳐져야 합니다. 한 문장으로 설명할 수 없다면 규칙이 모호한 것입니다.
• 하나의 스택 정책, 놀람 없음: 무엇이 스택 가능한지(쿠폰과 자동 프로모, 퍼센트와 고정, 배송 할인과 아이템 할인) 결정하고 검증하세요. 우선순위 순서를 명확히 하고 지원팀의 설명과 일치하는지 확인하세요.
• 반올림 일관성: 반올림 규칙(per-line vs per-order, 반올림 방식)을 선택하고 문서화한 뒤 $0.99 같은 가격, 수량 3, 혼합 퍼센트 할인으로 테스트하세요.
• 환불과 반품이 정확함: 부분 반품은 할인, 세금, 배송의 올바른 비율을 환불해야 합니다. “3개 중 1개 반품”, “먼저 할인된 아이템을 반품”, “프로모 만료 후 환불”을 테스트하세요.

Koder.ai 같은 생성기를 사용해 할인 규칙을 빌드한다면, 규칙 정의와 함께 이 케이스들을 자동화 테스트로 추가하세요. 목표는 간단합니다: 미래의 어떤 프로모도 고객 카트에서 실패하기보다 테스트에서 빠르게 실패하도록 만드는 것.

규칙 검증을 위한 현실적인 스택 시나리오

다음은 복잡해 보이지 않으면서도 대부분의 쿠폰 로직 함정을 드러내는 작은 카트입니다.

시스템에 다음 규칙을 정확히 이렇게 적어두었다고 가정하세요:

• 자동 프로모는 먼저 적용되며, 아이템 수준으로 정가 적격 품목에만 적용
• 쿠폰은 주문 수준, $15 할인, 적격 상품 최소 $100 필요
• “적격 상품”은 세일 상품, 배송, 세금 제외
• 쿠폰 할인은 이전 프로모 후의 적격 소계를 초과할 수 없음(캡)
• 세금은 할인 후에 계산(할인된 상품과 배송에 대해 계산)

카트와 프로모

카트:

프로모:

• Promo 1: eligible items에 자동 10% 주말 세일
• Promo 2: 쿠폰 $15 할인, 적격 상품 $100 이상 필요, 세일 상품 제외

워크스루와 최종 분해

1. 쿠폰 최소 금액 확인: 세전 적격 상품은 $60 + $40 = $100이므로 쿠폰 적용 가능.

2. Promo 1 적용(적격 품목 10%): $100 x 10% = $10 할인. 적격 소계는 $90이 됨.

3. Promo 2 적용($15 할인): 캡은 $90이므로 전체 $15 적용 가능. 새로운 적격 소계는 $75.

합계:

• 상품: 적격 $75 + 세일 상품 $30 = $105
• 배송: $8
• 세금(8%): (105 + 8) x 0.08 = $9.04
• 최종 합계: $105 + $8 + $9.04 = $122.04

이제 한 가지를 바꿔 봅시다: 고객이 Item B($40)를 제거합니다. 적격 상품은 $60이 되어 $15 쿠폰의 최소 금액 조건을 만족하지 못합니다. 자동 10% 프로모만 남아 Item A는 $54가 되고, 상품 합계는 $54 + $30 = $84, 최종 합계는 $99.36이 됩니다. 이런 "작은 편집"이 적격성과 순서가 명확하지 않으면 카트를 망가뜨리기 쉽습니다.

다음 단계: 프로모를 안전하게 배포하고 유지보수 가능하게 만들기

쿠폰 로직 함정을 피하는 가장 빠른 방법은 프로모를 "체크아웃의 수학 일부"가 아니라 제품 규칙처럼 다루는 것입니다. 배포 전에 팀 누구나 읽고 동의할 수 있는 짧은 명세를 작성하세요.

네 가지를 평이한 언어로 포함하세요:

• 스택 규칙(무엇이 결합 가능한지, 무엇이 불가능한지)
• 우선순위(두 개가 같은 항목을 타깃할 때 누가 우선인지)
• 제외(카테고리, 브랜드, 세일 품목, 구독, 기프트 카드)
• 하한과 캡(최소 소계, 최대 할인, “절대 $0 미만 아님”)

출시 후에는 합계를 에러처럼 관찰하세요. 할인 버그는 정상 주문처럼 보이다가 재무팀이 발견합니다.

비정상적인 패턴을 감지하는 모니터링을 설정하세요. 예: 거의 0원인 주문, 음수 합계, 소계보다 큰 할인, “100% 할인” 카트 급증 등. 알림은 체크아웃 오류가 가는 곳으로 라우팅하고 프로모를 안전하게 비활성화하는 짧은 플레이북을 유지하세요.

회귀 없이 새 프로모를 추가하려면 반복 가능한 워크플로를 사용하세요: 먼저 명세를 업데이트하고, 규칙을 데이터로 인코딩하고(분기 코드가 아니라), 몇 가지 일반 카트와 한두 가지 골치 아픈 엣지 케이스에 대한 테스트를 추가한 뒤 병합 전에 전체 할인 테스트 스위트를 실행하세요.

더 빠르게 구현하고 반복하려면 Koder.ai의 플래닝 모드에서 프로모 엔진 흐름을 프로토타입하고 스냅샷과 롤백을 사용해 테스트를 정제하세요. 이렇게 하면 알려진 정상 상태를 잃지 않고 규칙 변경을 빠르게 시도할 수 있습니다.