Payment & Credit Policy
이 문서는 Vivid AI의 초기 유료화 기준 결제 및 Credits 정책을 정의합니다. 현재 기준의 source of truth는 이 문서이며, 과거 VT, Vivid Token, Web3 단독 결제 중심 표현은 신규 UI와 결제 정책에서 사용하지 않습니다. 실제 구현 순서는 Billing Implementation Plan을 따릅니다.
1. Current Decision
초기 유료화는 국내 일반 결제를 먼저 구현합니다.
Primary payment: Toss Payments 같은 국내 일반 결제
Secondary payment: crypto 결제는 숨김 또는 후순위 옵션
Internal unit: Credits
크립토 결제는 기존 구현을 즉시 삭제하지 않고, feature flag 또는 admin/legacy 경로로 숨깁니다. 일반 사용자에게 노출되는 기본 결제 경험은 카드/간편결제 기반 Credits 구매입니다.
2. Naming Policy
서비스 내부 및 사용자-facing UI에서는 다음 명칭을 사용합니다.
| 용어 | 사용 여부 | 비고 |
|---|---|---|
Credits | 사용 | 기본 통화/사용권 단위 |
Vivid Credits | 필요 시 사용 | 브랜드 문맥에서만 보조 표현 |
VT | 신규 UI에서 사용하지 않음 | 기존 코드/DB migration 전까지 내부 호환 용도로만 허용 |
Vivid Token | 사용하지 않음 | 온체인 토큰 또는 투자성 자산처럼 보일 수 있음 |
Token | 사용하지 않음 | Credits와 혼동 방지 |
Credits는 온체인 토큰이 아니며, 양도/출금/환전 가능한 자산이 아니라 서비스 내부 생성 기능 이용권입니다.
3. Credit Types
Credits는 하나의 숫자 balance로만 관리하지 않고, 출처와 만료 정책을 분리합니다.
| Type | 지급 방식 | 만료/리셋 | 환불 기준 |
|---|---|---|---|
Monthly Credits | 월 구독 플랜 결제 시 지급 | 구독 기간 종료 또는 다음 갱신 시 리셋 | 구독 환불 정책에 따름 |
Top-up Credits | 단건 추가 결제 | 원칙적으로 소멸 없음 또는 장기 유효기간 | 미사용 유료분 기준 환불 검토 |
Bonus Credits | 이벤트, 쿠폰, 관리자 지급 | 짧은 유효기간 가능 | 환불 제외 |
Admin Credits | 운영자 수동 조정 | 사유별 지정 | 운영 로그 필수 |
초기 구현에서 DB를 단일 balance로 시작하더라도, ledger에는 반드시 credit type을 남겨야 합니다. 구독, top-up, 보너스가 섞이면 만료/환불/차감 순서를 나중에 복구하기 어렵습니다.
4. Subscription + Top-up Model
장기 정책은 정액제와 top-up을 병행합니다.
Monthly plan
-> 매월 정해진 Monthly Credits 지급
-> 기간 종료 또는 다음 결제 갱신 시 미사용 Monthly Credits는 이월하지 않음
Top-up
-> 구독 Credits가 부족한 사용자가 추가 구매
-> 사용하지 않은 top-up Credits는 구독 갱신과 무관하게 보존
예시 구조:
| Product | 결제 방식 | Credits 정책 | 가격 포지션 |
|---|---|---|---|
| Free | 무료 | 체험 Credits 소량 지급 가능 | 전환 유도 |
| Basic/Creator/Pro | 월 정기결제 | 매월 Monthly Credits 지급, 미사용분 이월 없음 | top-up보다 저렴한 장당 단가 |
| Top-up Small/Standard/Large | 단건 결제 | Top-up Credits 추가 지급 | 정액제 대비 약간 비싼 장당 단가 |
구현 순서는 top-up 단건 결제를 먼저 붙이고, DB와 ledger는 정기결제 확장을 고려해 설계합니다. Toss Payments 정기결제는 billing key, 갱신 실패, 해지, 재시도, 기간 관리가 필요하므로 초기 범위를 과도하게 키우지 않습니다.
5. Consumption Order
Credits 차감은 사용자가 납득할 수 있는 순서로 처리합니다.
- 가장 먼저 만료되는 Credits
- Monthly Credits
- Bonus Credits
- Top-up Credits
Top-up Credits는 사용자가 별도로 구매한 유료 잔액이므로 마지막에 차감하는 것을 기본값으로 둡니다. 단, Bonus Credits의 유효기간이 더 짧다면 만료일 우선 규칙을 적용합니다.
6. Persona Image Pricing Baseline
페르소나 이미지 생성은 초기 유료화의 기준 use case입니다.
현재 원가 가정:
Provider: GPT Image 2.0 기준
Output: 1024 x 1024 image
API cost: 50~60 KRW / image
Initial top-up target price: about 250 KRW / persona image
Monthly fixed server cost: 200,000~300,000 KRW
top-up 기준 250원 과금 시 단순 손익분기:
| 이미지 1장 과금 | API 비용 | 장당 공헌이익 | 월 서버비 20만원 기준 | 월 서버비 30만원 기준 |
|---|---|---|---|---|
| 250원 | 50원 | 200원 | 1,000장/월 | 1,500장/월 |
| 250원 | 60원 | 190원 | 1,053장/월 | 1,579장/월 |
운영 목표는 단순 손익분기보다 높게 잡습니다.
Conservative paid target:
2,000~3,000 persona images / month
이 목표에는 부가세, PG 수수료, 실패 재시도, 저장 비용, 무료 Credits, 이벤트 Credits, 운영 마진을 일부 흡수하기 위한 여유가 포함됩니다.
7. Price Unit Design
사용자가 받는 Credits 수가 너무 작게 느껴지지 않도록, 표시 단위는 이미지 1장보다 크게 설계합니다.
Persona image generation: 10 Credits / image
Top-up target unit price: about 25 KRW / Credit
Top-up target image price: about 250 KRW / image
초기 top-up 상품은 다음 가격으로 시작합니다.
| Product | 지급 Credits | 생성 가능 장수 | 가격 | 실질 장당 단가 |
|---|---|---|---|---|
| Top-up Small | 300 Credits | 30장 | 7,900원 | 약 263원 |
| Top-up Standard | 1,000 Credits | 100장 | 24,900원 | 약 249원 |
| Top-up Large | 2,500 Credits | 250장 | 59,900원 | 약 240원 |
향후 정액제는 top-up보다 명확히 유리한 장당 단가를 제공해야 합니다. 정액제 Credits는 구독 기간 내 사용하고, 미사용분은 다음 갱신 시 이월하지 않는 정책을 기본값으로 둡니다.
| Plan | Monthly Credits | 생성 가능 장수 | 월 가격 | 실질 장당 단가 |
|---|---|---|---|---|
| Basic | 500 Credits | 50장 | 9,900원 | 약 198원 |
| Creator | 1,500 Credits | 150장 | 27,900원 | 약 186원 |
| Pro | 3,500 Credits | 350장 | 59,900원 | 약 171원 |
가격 설계 원칙은 다음과 같습니다.
- 사용자는 원화 결제 금액과 지급 Credits를 명확히 봐야 합니다.
- 서버는
packageId기준으로 금액과 지급 Credits를 결정해야 합니다. - 프론트가 보낸
amount또는credits값을 신뢰하지 않습니다. - 생성 차감량은 provider 원가, 실패율, 저장 비용, 마진을 반영해 워크플로우별로 조정합니다.
- top-up은 정액제보다 편하지만 약간 비싼 선택지로 보여야 합니다.
- 정액제는 반복 결제 보상으로 top-up 대비 낮은 장당 단가를 제공합니다.
초기 결제 API는 다음 형태를 지향합니다.
POST /v1/billing/orders
body: { packageId }
Server:
- package lookup
- orderId 생성
- amount, currency, credits 결정
- Toss payment request data 반환
결제 승인/웹훅 처리 시에도 서버의 주문 원장 기준으로 검증합니다.
8. Ledger Requirements
Credits는 원장 기반으로 관리합니다.
필수 속성:
| Field | Purpose |
|---|---|
userId | 소유 사용자 |
type | MONTHLY, TOPUP, BONUS, ADMIN, USE, REFUND, EXPIRE 등 |
amount | 양수 지급, 음수 차감 |
balanceAfter | 감사/관리자 확인용 |
sourceId | payment order, subscription period, coupon, creation id 등 |
idempotencyKey | 중복 지급/중복 차감 방지 |
expiresAt | 만료가 있는 Credits에만 설정 |
metadata | provider usage, package id, workflow id 등 |
Top-up 결제 성공, 월 구독 갱신, 관리자 지급, 생성 차감, 실패 환불은 모두 ledger event로 남깁니다.
9. Payment Verification Rules
일반 결제 구현 시 결제 성공 화면보다 서버 검증이 우선입니다.
필수 검증:
orderId가 서버에서 생성된 주문인지 확인- 결제 승인 응답 또는 웹훅의
paymentKey저장 - 결제 금액이 서버 주문 금액과 일치하는지 확인
- 결제 상태가 승인 완료인지 확인
- 동일
paymentKey또는orderId로 Credits가 중복 지급되지 않도록 idempotency 적용 - Credits 지급과 payment history 저장을 하나의 transaction으로 처리
결제 완료 후 Credits 지급은 비동기 이벤트로 분리할 수 있지만, 사용자에게 성공을 보여주기 전에는 지급 결과를 확인할 수 있어야 합니다.
10. Open Decisions
아래 항목은 구현 전에 별도 확정이 필요합니다.
| 항목 | 현재 상태 |
|---|---|
| 정확한 top-up 패키지 가격 | 확정: 7,900원/300 Credits, 24,900원/1,000 Credits, 59,900원/2,500 Credits |
| 월 구독 플랜 이름과 월 지급 Credits | 초안 확정: Basic 500, Creator 1,500, Pro 3,500 Credits |
| 1024 persona image 1장당 차감 Credits | 확정: 10 Credits |
| Top-up Credits 유효기간 | 원칙적으로 없음 또는 장기 유효기간 |
| Monthly Credits 이월 | 이월 없음 |
| 환불/청약철회 세부 약관 | 법무/운영 정책 확정 필요 |
| 크립토 결제 재노출 여부 | 후순위 옵션 |
11. Implementation Notes
초기 리팩터링 기준:
- UI와 문서에서
VT를Credits로 교체합니다. - 기존
creditsbackend module은 유지하되, 결제 source와 credit type을 확장합니다. - 기존 crypto payment API는 일반 사용자 화면에서 숨기고, 신규 billing/payment API를 별도로 추가합니다.
- 기존
creditPackages의 하드코딩 패키지는 서버 기준 package API로 대체합니다. - 생성 비용 표시는
생성 -N Credits형태로 통일합니다.
상세 작업 순서, DB/API 초안, Toss Payments 연동 단계, 테스트 계획은 Billing Implementation Plan에 정리합니다.