원탭 생성과 건당 결제 — 구독 모델에서 단건 결제로

동화책은 매달 만들지 않는다

월 구독 모델에는 전제가 있다. 사용자가 매달 반복적으로 서비스를 쓴다는 것. AI 동화 생성은 이 전제에 맞지 않았다. 생일, 기념일, 특별한 순간에만 만든다. 연 2~3회.

구독에서 건당 결제로 전환했다. 동시에, 생성의 진입장벽을 낮추기 위해 원탭 모드를 설계했다.

원탭 “오늘의 동화” — 이름 하나로 시작

기존 생성 플로우는 설정 항목이 많았다. 스타일, 프롬프트, 캐릭터, 장면 수, 글자 수. UX 간편화로 핵심 3개로 줄였지만, 더 극단적인 경로가 필요했다. 이름만 입력하면 끝나는 모드.

원탭 모드의 설계 원칙은 하나. 사용자가 결정하지 않는 것은 서버가 결정한다.

사용자 입력: 아이 이름 (1개)
서버 결정:
  - 상황 → 템플릿 풀에서 랜덤 선택
  - 작문 스타일 → 랜덤 선택
  - 그림 스타일 → 랜덤 선택
  - 장면 수: 3 (고정)
  - 장면당 글자 수: 150 (고정)

상황 템플릿은 시스템 설정 테이블에 JSON 배열로 저장한다. 코드 배포 없이 관리자가 추가·수정할 수 있다. 템플릿에는 `` 플레이스홀더가 들어간다. 서버가 치환한 뒤 기존 생성 파이프라인에 그대로 전달한다.

프론트엔드 변경은 최소화한다. 기존 생성 API에 mode 파라미터 하나를 추가한다. mode: 'quick'이면 서버가 나머지를 채운다. 클라이언트는 이름만 보내면 된다.

생성 페이지 상단:
┌──────────────────────────────────────┐
│ "오늘 밤, 아이에게 이야기를 들려주세요" │
│                                      │
│ [아이 이름 입력]  [오늘의 동화 ▶]     │
│                                      │
│ ↓ 아래로 스크롤하면 상세 설정         │
└──────────────────────────────────────┘

상세 설정은 그대로 유지한다. 원탭 모드는 진입점이지, 기존 기능의 대체가 아니다.

건당 결제 — 빌링키가 아닌 단건 승인

기존 구독 결제는 빌링키 방식이다. 카드를 등록하면 매월 자동 청구된다. 건당 결제는 다르다. 매번 사용자가 결제를 승인한다. 1회성이다.

토스페이먼츠 기준, 두 방식의 차이는 명확하다.

기존 구독 결제에서 사용하던 토스 API 호출 로직을 공통 유틸로 추출했다. 빌링키 발급, 빌링키 결제, 단건 승인, 결제 취소를 하나의 클라이언트 클래스에 모은다. 구독 서비스와 토큰 구매 서비스가 동일한 클라이언트를 공유한다.

토큰 상품 설계

건당 결제의 단위는 “토큰 상품”이다. 상품 테이블을 두고, 관리자가 가격과 토큰 수량을 설정한다.

예시 상품 구성:

상품 목록은 공개 API로 제공한다. 인증 없이 조회 가능해야 한다. 비로그인 사용자도 가격을 먼저 확인할 수 있어야 하기 때문이다.

결제 흐름

결제는 3단계로 나뉜다.

1단계 — Checkout: 사용자가 상품을 선택하면 서버에 주문을 생성한다. 서버는 주문 ID, 금액, 결제 클라이언트 키를 반환한다.

2단계 — 결제 위젯: 토스 결제 위젯이 화면에 표시된다. 사용자가 카드 정보를 입력하고 결제를 승인한다. 성공 시 paymentKey가 반환된다.

3단계 — Confirm: 클라이언트가 paymentKey를 서버로 전송한다. 서버가 토스 승인 API를 호출한다. 성공하면 토큰이 즉시 반영된다.

사용자 → 상품 선택 → POST checkout → orderId 수신
       → 토스 위젯 결제 → paymentKey 수신
       → POST confirm → 토큰 충전 완료

기존 토큰 시스템의 addon_tokens 필드를 재사용한다. 토큰 히스토리에 source: 'addon_purchase'로 기록한다. 구독 토큰과 별도로 관리되므로 차감 순서도 기존 로직(애드온 먼저 → 구독 토큰)을 따른다.

기존 코드 재사용 전략

신규 기능이지만 새로운 패턴은 없다.

• 결제: 토스 클라이언트를 공통 유틸로 추출. 구독/건당 모두 동일 클라이언트.
• 토큰: addon_tokens와 token_history를 그대로 사용. 새 테이블은 상품 목록 1개만.
• 생성: mode 파라미터 추가. 나머지 파이프라인 변경 없음.
• 결제 위젯: 구독 결제에서 이미 사용 중인 토스 SDK를 재사용.

아키텍처 변경 없이 기존 패턴을 따라 기능을 추가하는 것이 원칙이다.

결론

동화책 생성의 빈도는 구독 모델과 맞지 않는다. 건당 결제가 사용자의 행동 패턴에 맞다. 원탭 모드는 “설정 피로”를 없앤다. 이 둘이 합쳐지면 진입장벽이 최소가 된다. 이름 입력 → 결제 → 동화 완성. 세 단계.