AI로 쿠폰 기능 만들 때 정해야 할 7가지 정책 결정

01핵심 개요

02핵심 내용 구조

• 실화 사례: 배달 플랫폼이 신규 가입자에게 15,000원 쿠폰 지급 → 탈퇴 후 재가입 반복으로 최소주문 16,000원 매장에서 치킨 1,000원 사태. 해킹이 아니라 "재가입 시 신규 쿠폰 재지급 여부" 정책 공백이 원인
• 두 번 만들기: 한 줄 프롬프트("주문할 때 쿠폰 코드 입력하면 할인") vs 실서비스 수준 프롬프트 비교 시연
• 쿠폰의 기술 정의: 정액 할인(5,000원)과 정률 할인(10%) 두 종류, 정률에는 최대 할인 금액 안전장치 필수
• 서버 검증 원칙: 할인 금액은 화면(브라우저 조작 가능)이 아니라 반드시 서버에서 재계산 — 결제가 있는 모든 기능의 원칙
• 7가지 결정: 한 줄 프롬프트로도 동작은 하지만 돈이 새는 빈틈이 남음

03기술적 맥락

• 정률 할인의 함정: 100만 원 주문에 10% 쿠폰이면 10만 원 할인 → "최대 할인 금액" 한도 없이는 마진 붕괴
• 동시성(트랜잭션) 문제: 마지막 1장 수량한정 쿠폰을 두 사람이 동시 클릭 시 둘 다 "1장 남음" 확인 후 둘 다 발급 → 100장 한정인데 102장 발급 사고. 해결책은 DB가 수량을 잠그는 트랜잭션. 레일즈 등 프레임워크에 내장되어 있으나 "동시 요청에도 수량 정확히"를 프롬프트로 요구해야 챙겨짐
• 풀스택 프레임워크의 이점: 루비 온 레일즈는 서버 검증·트랜잭션이 기본 내장. SQLite 3로 외부 DB(슈퍼베이스 등)·과금 없이 코드 레벨 완결, 파일 복사만으로 백업. 프론트 기반 서비스는 서버 검증 로직을 빠뜨리기 쉬워 프롬프트 보강이 더 필요

04전략적 의미

• 정책 공백 = 운영 비용: 환불 시 쿠폰 처리 등을 코드로 안 정하면 CS가 수동 처리 → 결정을 미룬 비용이 운영에서 나감
• 기능은 서로 연결: 회원 탈퇴를 소프트 딜리트로 설계하고 재가입 정책을 정해두면 쿠폰의 부정사용(치킨 사태)을 막아줌. 각각 완성해도 접점의 빈틈으로 돈이 샘
• AI를 기획 파트너로: "정하지 않은 정책은 먼저 질문해 줘" 한 줄이 잠재 손실을 하나씩 막아줌. 돈이 걸린 기능일수록 질문의 가치가 큼

05핵심 워크플로우 / 7가지 결정

06활용 시나리오

• 신규 유치 이벤트: 가입 자동 발급 쿠폰 설계 시 최소 주문 금액을 쿠폰 금액 대비 충분히 높게(치킨 사태 방지) + 재가입 재지급 차단 정책을 회원 소프트 딜리트와 연동
• 정률 프로모션 운영: 10% 쿠폰에 최대 할인 3,000원 한도 설정 → 32,000원 주문 시 3,200원이 아닌 3,000원만 적용되도록 서버 검증
• 수량 한정 선착순 쿠폰: "동시 요청에도 수량 정확히" 트랜잭션 요구를 프롬프트에 명시해 100장 한정이 초과 발급되지 않도록 방어
• 외주·인수인계형 제작: 루비 온 레일즈 + SQLite 3 풀스택으로 외부 서비스·과금 없이 완결, 고객이 프롬프트만으로 유지보수 가능하게 구성

07현황 및 전망

• 실서비스 수준 프롬프트는 어려운 기술 용어 없이 정책 항목(정액/정률·최소주문·최대한도·1인당 횟수·환불 복원 조건)만 나열하면 됨 — "운영해 본 사람의 목록"
• AI는 실제 질문(전체 발급 수량 상한, 소수점 처리는 올림, 비활성화 시 기존 보유자 유효기간까지 사용 등)을 되물으며 기획 파트너로 작동
• 쿠폰은 1회성 "초대장", 포인트는 잔액 누적 "지갑"으로 적립률·소멸·현금성 이슈가 얹혀 난이도가 한 단계 위 → 보통 쿠폰부터 시작 권장
• 채널은 회원가입·쿠폰에 이어 서비스 필수 정책들을 순차 연재 예정

08용어 사전