토큰 기반 요금제 설계 — AI SaaS의 과금 모델

문제: AI 비용은 변동적이다

동화 3장면과 20장면의 AI API 비용은 7배 차이가 난다. “월 N권”으로 요금제를 설계하면 1권의 정의가 모호해진다. 사용자도 서비스도 손해를 본다.

토큰 기반 과금으로 이 문제를 풀었다.

토큰 단위 설계

AI 실사용 토큰과의 관계

Storida 토큰 = AI API 실사용 토큰 ÷ 10

AI API가 소비하는 토큰을 10으로 나눈 값이다. 10으로 나누면 사용자가 다루기 편한 숫자가 된다.

장면당 소모 토큰

이 수치를 바탕으로 역산하면:

요금제 플랜 구성

설계 원칙

1. Start 플랜 = 체험: 2,500 토큰으로 3장면 3권(750 × 3 = 2,250) + 여유. 3장면 고정으로 과도한 토큰 소모 방지
2. Basic = 입문 유료: 10장면까지 허용, 6권 분량. 커스텀 캐릭터 개방
3. Standard = 주력: 20장면, PDF 다운로드, POD 신청 가능
4. Artist = 프로: 30장면, 커스텀 작문 스타일 개방

토큰 관리 정책

이월 없음

매월 구독 갱신 시 구독 토큰 잔액이 초기화된다. 미사용 토큰은 소멸한다.

구독 갱신 시 보유 토큰을 플랜의 월간 토큰으로 초기화하고, 다음 갱신일을 기록한다.

이월을 허용하면 토큰이 축적된다. 한꺼번에 소진되면 AI 비용이 급증한다. 월간 사용량을 예측 가능하게 유지하기 위해 이월을 차단했다.

단건 구매 토큰 — 영구 유효

구독 토큰이 부족할 때 추가로 구매하는 단건 토큰은 만료 없이 영구 유효하다.

사용자 테이블에는 두 종류의 토큰 잔액이 존재한다. 구독 토큰(매월 초기화)과 단건 구매 토큰(영구 유효)이다.

차감 순서

생성 시 단건 구매 토큰을 먼저 차감하고, 부족분은 구독 토큰에서 차감한다.

단건 구매 토큰을 먼저 소진한다. “돈을 주고 산 토큰이 먼저 사용된다”는 사용자 기대에 맞다. 구독 토큰은 어차피 매월 초기화된다. 단건 토큰을 아끼는 편이 사용자에게 유리하다.

DB 스키마

credit_logs — 모든 변동 추적

크레딧 이력은 모든 충전과 사용을 추적한다. 각 변동마다 유형(충전/사용), 출처, 변동량, 변동 후 잔액 스냅샷을 기록한다. 생성된 콘텐츠나 구매 건에 대한 참조도 선택적으로 포함된다.

설계 결정: 잔액 스냅샷

balance_after와 addon_balance_after 필드는 변동 시점의 잔액 스냅샷이다. 이렇게 설계한 이유:

1. 시계열 잔액 조회: 특정 시점의 잔액을 DB 한 번 조회로 확인 가능
2. 불일치 감지: balance_after의 연속성으로 토큰 누락/이중 차감을 감지 가능
3. 감사(audit): CS 문의 시 정확한 토큰 변동 이력 제공

비즈니스 로직: 생성 가능 여부 검증

// 검증 로직
// 1. 필요 토큰 = 장면당 토큰(250) × 장면 수
// 2. 보유 토큰 = 구독 잔여 + 추가 구매
// 3. 부족하면 부족량과 함께 에러 반환

부족 시 클라이언트에 부족량(shortfall)을 반환하여, 단건 구매 유도 팝업에서 정확한 필요 토큰 수를 표시한다.

토큰 선차감 전략

토큰은 생성 요청 시 즉시 차감한다. 생성 완료 후 차감하면, 요청과 완료 사이(2~4분)에 다른 요청이 같은 토큰을 사용하는 이중 소진 문제가 발생한다.

요청 시: 토큰 차감 → Job 등록 → 즉시 응답
생성 실패 시: 토큰 환불 (credit_logs에 refund 기록)

이 방식의 트레이드오프는 생성 실패 시 환불 로직이 필요하다는 점이지만, 이중 소진 방지가 더 중요하다.

결론

3장면은 750 토큰, 10장면은 2,500 토큰. 단순한 공식이 사용자의 비용 예측을 돕고, 서비스의 수익성을 보장한다.

다음 글은 Cloudflare R2 스토리지 마이그레이션과 Scheduler 모듈화 리팩토링을 다룬다.