수익화, 가격 책정(pricing) 및 “비용 ↔ 품질” 실험

1. 왜 지금 수익화를 고민해야 할까

이전 모듈의 핵심 질문은 “이게 정말 동작하나?”였습니다. 이제 다음 단계의 난도를 추가합니다: “그게 과연 수익이 나나?”입니다.

LLM 애플리케이션에서는 이것이 특히 아픕니다. 변동비(LLM 토큰, rerank 모델, 임베딩)가 여러분이 익숙한 “$20짜리 서버와 $15짜리 Postgres”를 대신해 신경을 잡아먹기 쉽습니다. 이를 무시하면 — 월말에 모기지급과 맞먹는 OpenAI 청구서를 받게 됩니다.

그래서 오늘은 세 가지 큰 주제입니다:

1. ChatGPT App, 특히 우리 GiftGenius에 어떤 수익화 모델이 있는가.
2. pricing ↔ cost_per_task를 어떻게 연결하여, 한 번에 $0.15가 드는 일을 “선물 추천 100회를 $1에” 같은 식으로 팔지 않게 할 것인가.
3. “비용 ↔ 품질” A/B 실험을 어떻게 설정할 것인가: 모델, 프롬프트, UX를 바꾸고, 몇 주 뒤 감(감각)이 아닌 데이터로 결정할 수 있도록 로깅을 어떻게 설계할 것인가.

동시에 다음 모듈의 LLM‑evals와 quality_score 주제를 부드럽게 예고하지만, 코드로 깊게 들어가진 않습니다.

2. ChatGPT App의 수익화 모델: B2C, B2B, 프리미엄(freemium)과 업셀

LLM의 마법을 제외하면, 여기의 수익화 모델은 일반적인 SaaS/모바일 앱에서 쓰는 것과 매우 비슷합니다. 다만 대화형 인터페이스에는 특이점이 있습니다. 사용자가 “어디까지 무료고 어디서부터 유료인지”를 잘 느끼지 못하는 경우가 많아, UX에서 이를 섬세하게 설계해야 합니다.

GiftGenius를 예로 주요 옵션을 살펴봅시다.

B2C: 일반 사용자와 선물

여기서 고객은 ChatGPT에 와서 “우주 팬에게 50달러로 선물 추천해줘”라고 요청하는 일반 사용자입니다. 여러분은 자체 상품을 판매하지 않고, 사용자에게 추천만 제공할 수 있습니다.

전형적인 B2C 모델:

1. 일회성 구매.
   사용자가 특정 시나리오에 대해 지불합니다. 예: 무료 3개 아이디어, 그 이후에는 한 명의 수취인을 위한 10개 추가 아이디어로 구성된 유료 “패키지”.
2. 구독.
   월별 이용료. GiftGenius에서는 “월 100회 추천까지” 또는 “자주 선물하는 사람을 위한 무제한 추천”일 수 있습니다.
3. 프리미엄(freemium, 무료/유료 티어).
   기본 시나리오는 무료(월 N회 추천, 기능 제한), 유료는 더 큰 한도, 더 강력한 모델, 추가 포맷, 히스토리를 제공합니다. ChatGPT App에서 가장 흔한 모델입니다. “ChatGPT 안에서는 기본 무료, 프리미엄 기능은 유료”.
4. 앱 내 업셀.
   사용자가 무료 기본 추천을 통해 괜찮은 결과를 본 뒤, “$X에 위시리스트/소셜 등을 반영한 심층 추천을 해줄까?” 또는 “바로 기프트 카드를 구매할래?”처럼 부드럽게 제안합니다.

B2B: 팀/회사 및 기업 선물

여기서는 HR, 마케팅 부서, 그리고 “직원/고객 선물을 담당하는 사람들”이 등장합니다.

전통적인 구성:

• 사용자별 라이선스(per seat).
  예: 10명용 “HR‑Team” 플랜. 각자 GiftGenius 접근 권한, 선물/예산 리포트 제공.
• 회사별 라이선스(per company).
  “최대 500명 직원, 월 고정 가격, 내부에서는 원하는 만큼 추천”.
• 추가 엔터프라이즈 기능.
  별도 어드민, HRIS/CRM 통합, 커스텀 리포트, SLA 등.

두 경우 모두 “한 번의 추천 비용”이 아니라 cost_per_user_per_month 또는 cost_per_tenant_per_month를 계산하고 라이선스 가격과 비교합니다.

GiftGenius에 어떤 모델을 택할까

이론에 파묻히지 않도록 간단한 출발점을 잡을 수 있습니다:

• B2C: 프리미엄(freemium).
  월 3회 추천 무료, 그 이후에는 $5/월 구독으로 무제한 추천과 프리미엄 모델 제공.
• B2B: 회사 단위.
  “HR‑팀” 요금제 $99/월, 직원 대상 최대 500건 추천, HR 시스템 연동 및 리포팅 포함.

이후 cost_per_task와 전환율에 대한 실제 데이터가 생기면 모두 조정할 수 있습니다. 사실 지금의 수치는 “대략” 잡은 값입니다. 그럴싸해 보이지만, 완료된 한 시나리오에 얼마가 드는지 아직 검증하지 않았습니다. 다음 섹션에서 이러한 요금제를 실제 원가—cost_per_task—에 연결하겠습니다.

3. 가격과 원가의 연결: cost_per_task란 무엇인가

이제 가장 중요한 주제로 넘어갑니다. GPT‑5 자선 재단이 되지 않으려면 어떻게 해야 할까요.

직관: 가격 ≥ cost_per_task × 마진

지난 주제에서 cost_per_task라는 개념을 이미 보았습니다. 이는 하나의 성공적인 시나리오에 드는 총비용입니다. “사용자가 추천을 시작”해서 “결과를 받는”(그리고 어쩌면 결제까지 하는) 지점까지를 포함합니다.

이에 포함되는 항목:

• LLM 비용(입출력 tokens × price_per_token, 필요하다면 rerank 모델, 임베딩 등 포함);
• 한 task당 인프라 비용 배분(서버, DB, 큐, MCP 게이트웨이 등) — 보통 집계 데이터로 계산;
• 선택적으로 — 거래 비용(Stripe 수수료, 부정 결제 방지) 등 “순매출” 이전 단계까지를 cost_per_task에 넣을 수 있습니다.

아이디어는 간단합니다. 시나리오 가격이나 구독료는 평균 시나리오 원가에 “마진 여유”를 곱한 값보다 높아야 합니다.

아주 단순화하면:

price_per_task >= cost_per_task * ( 1 + margin )

퍼센트 마진을 이 강의에 가득 채우지는 않겠습니다. 중요한 건 직관적인 규칙 자체입니다.

GiftGenius 예시

지난 강의에서 도입한 비용 로깅을 적용했고, 집계 리포트가 있다고 가정해 봅시다:

• 평균 cost_per_task(선물 추천 1건 완료) = 0.15 USD;
• 여기에는 이미 LLM 토큰(여러 번의 suggest_gifts 호출, rerank, 최종 요약)과 인프라 배분이 포함되어 있습니다.

그다음 시나리오를 봅니다:

• 무료 사용자가 추천을 받고, 가끔 $50짜리 기프트 카드를 구매합니다.
• 완료된 추천 중 구매 전환율이 5%라고 합시다.

풀 유닛 이코노믹스로 들어가진 않지만, 대략 가늠해 볼 수 있습니다. 100건의 추천 중:

• 비용은 100 × $0.15 = $15;
• 그중 5건이 $50에 체크아웃;
• 매출은 5 × $50 = $250.

겉보기엔 좋아 보입니다: 대략 ($250 – $15), 여기에 Stripe 수수료, 세금 등 여러 고통이 더해지죠. 하지만 너무 후한 구독(예: 선물 추천 100회를 $1에)으로 가면 손해를 보기 쉽다는 점이 중요합니다.

미니 코드 예시: TypeScript에서 cost_per_task 저장

워크플로우를 마무리하며 전체 cost를 알고 있는 MCP 도구가 있다고 가정합시다:

// 시나리오 최종 지표 타입
type TaskMetrics = {
  taskId: string;
  userId: string;
  costPerTaskUsd: number;
  modelName: string;
  completedAt: string;
};

// 지표 로깅용 예시 함수
async function logTaskMetrics(metrics: TaskMetrics) {
  console.log(JSON.stringify({ 
    level: "info",
    event: "workflow_completed",
    ...metrics,
  }));
}

// 추천 완료 핸들러의 어딘가에서:
await logTaskMetrics({
  taskId: context.taskId,
  userId: context.userId,
  costPerTaskUsd: context.costEstimateUsd, // 토큰에서 계산됨
  modelName: context.modelName,
  completedAt: new Date().toISOString(),
});

이런 로그는 나중에 대시보드에서 쉽게 집계하여 모델/사용자/시나리오별 cost_per_task 분포를 확인할 수 있습니다.

4. 가격 책정: cost_per_task를 실제 가격으로 변환하기

이제 cost_per_task가 있으니, 사용자에게 무엇에 대해 얼마나 받을지 결정해야 합니다.

B2C를 위한 간단한 규칙

B2C에서는 경험적으로 다음 규칙을 선택할 수 있습니다.

“LLM+인프라에 매출의 X% 이상은 쓰지 않는다.”

예를 들어, LLM 비용으로 매출의 20%보다 더 쓰고 싶지 않다고 정했다면:

• cost_per_task가 $0.15라면, 한 유료 시나리오의 최소 가격은 대략 $0.75여야 합니다. 0.15가 0.75의 약 20%가 되도록요.
• 구독을 판매한다면, 한 구독자에게 월 평균 몇 개의 평균적인 시나리오가 발생할지를 추정해 곱합니다.

처음에는 “감”으로 시작해도 전혀 문제없고, 실제 데이터가 생기면(스포일러: 바로 생기지 않습니다) 가격을 보정해 가면 됩니다.

B2B를 위한 간단한 규칙

B2B에서는 보통 다음을 봅니다:

• cost_per_user_per_month 또는 cost_per_tenant_per_month;
• 업체의 지불 의향(여러분이 해결하는 문제의 크기).

예컨대 HR 팀이 GiftGenius를 통해 연간 수만 달러 규모의 선물을 분배한다면, 월 $99 구독은 꽤 겸손해 보입니다. 설령 그 팀의 LLM 비용이 월 $10뿐이라 해도요. 핵심은 — cost_per_tenant가 $80인데 구독이 $50인 상황을 피해야 한다는 점입니다.

그리고, “우리는 AI니까 일단 다 무료로, 나중에 생각하자”라고 하면 그런 상황이 실제로 일어납니다.

서버의 작은 “가드” 함수

코드에서 간단한 “guard”를 두고, 가격을 정할 때 비용이 합리적인 범위를 벗어나지 않았는지 힌트를 줄 수 있습니다:

function checkPricingSafety(params: {
  avgCostPerTaskUsd: number;
  plannedPricePerTaskUsd: number;
  maxCostShare: number; // 예: 0.3 = 30%
}): boolean {
  const share = params.avgCostPerTaskUsd / params.plannedPricePerTaskUsd;
  return share <= params.maxCostShare;
}

// 예:
checkPricingSafety({
  avgCostPerTaskUsd: 0.15,
  plannedPricePerTaskUsd: 0.75,
  maxCostShare: 0.3,
}); // true — OK, 20% < 30%

이것이 재무 모델을 대체하진 못하지만, 특히 가격 실험을 할 때 빠른 sanity‑체크(상식 점검)를 제공합니다.

5. “모델/에이전트 vs 비용과 전환” 실험

이제 가장 흥미로운 주제, A/B 실험으로 넘어갑니다.

직관은 간단합니다:

• 변형 A — 비싼 모델/더 복잡한 워크플로우;
• 변형 B — 저렴한 모델/단순화된 워크플로우;
• 이것이 동시에 다음에 어떻게 영향을 주는지 알고자 합니다:
  • cost_per_task,
  • 결과 품질(사용자 체감, 그리고 향후 LLM 평가),
  • 비즈니스 지표(전환율, 매출).

무엇을 실험할 것인가

세 가지 주요 축이 있습니다:

1. 모델.
   예: GPT‑5 vs GPT‑5‑mini 또는 완전히 다른 라인업. 보통 비싼 모델은 품질과 cost_per_task가 높고, 저렴한 모델은 그 반대입니다.
2. 에이전트 로직/프롬프트.
   더 자세한 단계, 긴 프롬프트, 복잡한 추론은 더 좋은 품질을 주지만 더 비쌉니다. 미니멀한 로직은 더 싸고, 때로는 품질이 거의 비슷합니다.
3. UX 형식.
   수많은 필드와 힌트가 있는 긴 위저드 vs 빠른 인라인 모드. 모델이 같아도 토큰 수와 단계 수가 몇 배씩 차이날 수 있습니다.

이 모든 변형은 이미 적용할 수 있습니다. 중요한 건 실험으로 감싸고 로깅하는 것입니다.

실험에서 어떤 필드를 로깅할까

cost를 위해 로깅하던 필드(tokens, model, cost_estimate, user_id, request_id 등) 위에 실험용 필드를 추가합니다:

• experiment_id — 실험의 고유 식별자(예: "gift_model_ab_2025_11").
• variant — 해당 사용자에게 배정된 분기: "A", "B", "control", "treatment" 등.
• model_name 또는 agent_version — 나중에 어떤 구성인지 기억할 수 있도록.
• 시나리오 결과:
  • workflow_completed 여부;
  • checkout_success 여부;
  • 최종 cost_per_task.
• 옵션 — quality_score(이에 대해서는 뒤에서. LLM‑evals 모듈로 가는 다리입니다).

실험 이벤트의 JSON 로그 예시

전형적인 로그 이벤트는 다음과 같습니다:

{
  "level": "info",
  "timestamp": "2025-11-21T20:15:03.123Z",
  "event": "experiment_task_result",
  "experiment_id": "gift_model_ab_2025_11",
  "variant": "A",
  "user_id": "user_123",
  "task_id": "task_456",
  "model_name": "gpt-5.2",
  "workflow_completed": true,
  "checkout_success": false,
  "cost_per_task_usd": 0.18,
  "quality_score": null,
  "request_id": "req_abc",
  "trace_id": "trace_xyz"
}

이런 레코드는 어떤 분석 도구에서도 잘 집계됩니다. “variant A vs B를 cost/전환/매출로 비교” 같은 테이블을 만들 수 있습니다.

예제 코드: MCP 도구에서 실험 로깅

여러분의 MCP 서버가 이미 시나리오 비용(cost_per_task)을 계산했고, 사용자가 어떤 실험 분기에 있는지 알고 있다고 가정합시다:

type ExperimentContext = {
  experimentId: string;
  variant: "A" | "B";
};

async function logExperimentResult(params: {
  ctx: ExperimentContext;
  userId: string;
  taskId: string;
  modelName: string;
  costPerTaskUsd: number;
  workflowCompleted: boolean;
  checkoutSuccess: boolean;
}) {
  const event = {
    level: "info" as const,
    event: "experiment_task_result",
    timestamp: new Date().toISOString(),
    experiment_id: params.ctx.experimentId,
    variant: params.ctx.variant,
    user_id: params.userId,
    task_id: params.taskId,
    model_name: params.modelName,
    cost_per_task_usd: params.costPerTaskUsd,
    workflow_completed: params.workflowCompleted,
    checkout_success: params.checkoutSuccess,
  };

  console.log(JSON.stringify(event));
}

상위 레벨에서 사용자(user_id, tenant_id 또는 무작위)에 따라 어떤 변형으로 보낼지 결정하고, ExperimentContext를 워크플로우 핸들러로 전달합니다. 이 레벨에서 우리는 실험을 위해 무엇을 어떻게 로깅할지(필요한 필드와 기록 위치)를 고정했습니다. 이제 단순한 로그 묶음을 제품 가설과 가격 책정 의사결정으로 바꾸는 방법을 논의해 봅시다.

6. 이제 quality_score와 LLM‑evals를 조금

이 주제는 20번째 모듈에서 자세히 다루고, 지금은 아이디어만 공유하겠습니다. quality_score는 예를 들어 0~10 척도로 답변/해결의 품질을 평가한 값이며, 종종 별도의 “판사” 역할 LLM 모델이 수행합니다. LLM‑as‑judge에 대해서는 20번째 모듈에서 자세히 설명하겠습니다.

지금은 구현 세부사항은 필요하지 않습니다 — 다음 모듈의 주제이고 — 대신 개념을 이해하는 것이 중요합니다:

• 돈 외에도 품질을 측정하고 싶습니다.
• 사람 또는 두 번째 모델에게 “GiftGenius가 선물을 얼마나 잘 추천했는지 10점 만점으로 평가해 달라”고 요청할 수 있습니다.
• 그다음 quality_score가 다음과 어떻게 상관하는지 볼 수 있습니다:
  • 구매 전환;
  • 사용자 유지;
  • willingness‑to‑pay(지불 의향).

로그 관점에서는 또 하나의 필드일 뿐입니다:

type ExperimentResultEvent = {
  experiment_id: string;
  variant: string;
  user_id: string;
  task_id: string;
  cost_per_task_usd: number;
  quality_score?: number; // 0-10, undefined일 수 있음
};

오늘 강의는 여기까지입니다. LLM‑evals, 골든 케이스, “LLM‑as‑judge”의 세부사항은 코스 뒷부분에서 다룹니다. 지금은 이 점수가 나중에 실험에 어디에 연결되는지만 이해하면 충분합니다. 바로 quality_score가 “비용만 최적화”라는 고전적 실수를 막아줍니다. 이 점수를 통해 시나리오를 과도하게 저렴하게 만들고 품질을 잃기 시작했는지, 그리고 그와 함께 전환과 매출도 떨어지는지를 수치로 확인할 수 있습니다.

7. 가격 책정과 수익화에 실험을 활용하는 법

이제 실험을 단순 로깅이 아닌, 성공 지표와 수익화 영향이 명확한 비즈니스 가설로 정리합니다. experiment_id만 기록하는 것으로는 충분하지 않습니다. 제품 변경을 명확한 성공 지표가 있는 가설로 정리하는 것이 중요합니다.

가설 예시: 비싼 모델 vs 저렴한 모델

GiftGenius의 이런 실험을 상상해 봅시다:

• 변형 A — 비싼 모델(GPT‑5), 풍부한 추론, 긴 위저드.
• 변형 B — 저렴한 모델(GPT‑5‑mini), 조금 더 단순한 프롬프트와 더 짧은 대화.

가설: 모델을 저렴한 것으로 바꾸면 cost_per_task가 최소 50% 감소한다. 이때 사용자/LLM 평가(우리의 quality_score) 기준 품질 하락은 최대 5–10% 이내이며, 구매 전환은 떨어지지 않는다.

기술적으로 각 task에 대해 5.2절에서 본 것과 동일한 필드를 로깅합니다:

• experiment_id = "gift_model_ab_2025_11";
• variant = "A" 또는 "B";
• model_name;
• cost_per_task_usd;
• workflow_completed;
• checkout_success;
• quality_score(LLM‑evals가 준비되면).

일주일이나 이주 뒤 다음을 할 수 있습니다:

• 변형 A/B의 평균 cost_per_task를 비교;
• 체크아웃율(성공 결제 비율)을 비교;
• 평균 quality_score 비교(있다면).

B가 품질에서 거의 지지 않으면서 비용이 절반이라면, 다음 중 하나를 할 수 있습니다:

• B로 전환하여 마진을 높이기;
• 혹은 가격은 유지하되 사용자 구독 가격을 낮춰 성장 가속하기.

가설 예시: 고품질 업셀

또 다른 가설: 무료 3개 아이디어 이후 “선물 전체 리포트 + 카드 메시지 추천” 프리미엄 업셀을 $4.99에 보여주면, 구매 전환이 최소 2%p 상승한다. 이때 cost_per_task 증가는 최대 $0.05 이내.

여기서 실험은 모델보다는 UX와 제품 로직에 가깝습니다. 하지만 기술적으로는 동일합니다:

• variant에 따른 서로 다른 UX;
• 시나리오 단위 cost와 revenue 로깅;
• 업리프트 분석(새 로직이 돈을 얼마나 더 벌어주고 비용을 폭증시키지 않았는지).

예제 코드: 태스크 단위의 간단한 매출 기록

때로는 cost와 함께 시나리오의 매출도 기록하는 것이 유용합니다:

type RevenueEvent = {
  taskId: string;
  userId: string;
  experimentId?: string;
  variant?: string;
  revenueUsd: number;
  checkoutSuccess: boolean;
};

async function logRevenue(event: RevenueEvent) {
  console.log(JSON.stringify({
    level: "info",
    event: "task_revenue",
    timestamp: new Date().toISOString(),
    ...event,
  }));
}

그다음 task_revenue와 experiment_task_result를 taskId로 연결하면, 각 분기에 대해 다음을 계산할 수 있습니다:

• 평균 revenue_per_task;
• 평균 cost_per_task;
• 그리고 가장 단순한 ROI를 도출할 수 있습니다.

8. 실습: GiftGenius를 위한 A/B 실험

이론을 실전에 연결하기 위해, GiftGenius에서 “비싼 모델 vs 저렴한 모델” 실험이 어떻게 보일지를 단계별 실습 형태로 정리해 봅시다.

우리가 바꾸는 것

• 변형 A:
  • 모델 gpt-5;
  • 더 상세한 system 프롬프트와 에이전트 단계;
  • 아마 더 많은 중간 reasoning 호출.
• 변형 B:
  • 모델 gpt-5-mini;
  • 조금 더 간결한 프롬프트;
  • 보조 tool 호출을 줄이고, 단순화된 플로우.

사용자를 분기별로 배정하는 방법

가장 쉬운 방법 — user_id의 해시를 사용합니다:

function assignVariant(userId: string): "A" | "B" {
  const hash = Array.from(userId).reduce((acc, ch) => acc + ch.charCodeAt(0), 0);
  return hash % 2 === 0 ? "A" : "B";
}

이렇게 하면 비교적 균등하게 분배되고, 한 사용자는 항상 같은 분기에 배정됩니다.

무엇을 로깅하는가

추천 워크플로우가 완료될 때, 앞선 섹션(5.2, 7.1)에서 본 동일한 필드를 로깅하고 매출을 추가합니다:

• experiment_id = "gift_model_ab_2025_11";
• 위 함수로부터의 variant;
• 실제로 사용한 model_name;
• cost_per_task_usd, 토큰과 인프라의 총비용;
• workflow_completed(true/false);
• checkout_success(true/false);
• revenue_usd(0 또는 구매 금액).

옵션으로(코스의 조금 뒤에서) quality_score가 추가됩니다.

그리고 이 데이터는 로그/분석으로 흘러가 아래와 같은 표로 정리될 수 있습니다:

이 표만 보아도, B는 비용이 절반인데도 매출은 거의 동일하므로 B를 선택할 강력한 근거가 됩니다.

9. 시각적 다이어그램: “비용 ↔ 품질 ↔ 수익화” 루프

모든 것을 머릿속에 정리하기 위해, “데이터가 이곳저곳으로 흐르는” 작은 다이어그램을 그려봅시다:

flowchart TD
    U[ChatGPT의 사용자] --> A["ChatGPT App (GiftGenius)"]
    A --> E[실험 모듈
variant A/B 할당]
    E --> AG[에이전트 / MCP tools
서로 다른 모델]
    AG -->|LLM 호출| L[usage & cost 로그]
    AG -->|추천 결과| UI[위젯 / 채팅 응답]
    UI -->|행동: 클릭, 구매| BE[Commerce backend]

    L --> M[지표: cost_per_task,
cost_per_user]
    BE --> M
    M --> D[가격/실험 대시보드]

    subgraph "향후 모듈 20"
      J[LLM 판사
quality_score]
      J --> M
    end

지금 여러분은 이 다이어그램의 정확히 가운데에 있습니다. cost와 매출을 로깅할 수 있고, 그 위에 실험과 가격 책정을 더합니다. 다음 모듈에서는 저지 드레드(LLM‑sudya)가 등장합니다.

10. 수익화와 실험에서 흔한 실수

큰 그림이 머릿속에 있으면, 어디서 문제가 생기기 쉬운지 보기가 더 쉽습니다. 아래는 수익화와 비용 실험을 할 때 체크리스트처럼 옆에 두면 좋은 흔한 실수 목록입니다.

실수 №1: 품질을 잊고 비용에만 최적화한다.
흔한 시나리오: 더 저렴한 모델로 갈아타고 OpenAI 청구서가 줄어든 걸 보고 승리를 선언합니다. 그런데 한 달 뒤 사용자가 기프트 카드를 덜 사고, 재방문이 줄고, “엉뚱한 걸 추천했다”는 지원 문의가 느는 것을 보게 됩니다. quality_score나 최소한의 프록시 지표(아이디어 클릭, 저장, 전환)를 로깅하지 않으면 “싸지만 쓸모없는” 모드로 빠지기 쉽습니다.

실수 №2: 인프라/결제를 무시하고 LLM만으로 cost_per_task를 계산한다.
개발자가 토큰은 꼼꼼히 계산하면서 Redis, 큐, 외부 API, Stripe 수수료 등을 잊는 경우가 있습니다. 그 결과 cost_per_task가 과소 추정되고, 가격이 실제보다 더 편안해 보일 수 있습니다. 인프라는 보통 집계 데이터로 계산하지만, 그 비중을 시나리오 원가에 반드시 반영해야 합니다.

실수 №3: experiment_id와 variant 없이 모델/UX를 바꾼다.
“프롬프트를 좀 손봤는데, 아마 좋아진 듯” — 한 달 뒤에는 언제 바꿨고, 어떤 데이터에 근거했고, 무엇을 초래했는지 아무도 기억하지 못합니다. 로그에 명시적인 실험 표기(experiment_id, variant)와 특정 릴리스에 대한 연결이 없으면, 회고와 개선 효과 검증이 어렵습니다.

실수 №4: 너무 적은 데이터로, 너무 일찍 결론을 낸다.
실험을 이틀만 돌리고 결제 10건을 근거로 모델 B가 “훨씬 이득”이라고 결론 내리는 것은 전형적인 통계적 잡음의 함정입니다. 최소한 일주일(더 길수록 좋음)과 충분한 시나리오 수가 필요합니다. 평균과 전환을 비교할 수 있을 만큼은요. 이 강의는 통계로 깊이 들어가진 않지만, “이벤트 5개로 결론 내리지 말라”는 규칙은 명심하십시오.

실수 №5: 단순한 사고 규칙 없이 복잡한 가격 체계를 쓴다.
3단계 요금제, 다국 통화, 추천 코드 할인 등 복잡한 체계를 만들 수 있습니다. 하지만 “LLM 비용은 매출의 X%를 넘지 않는다” 또는 “시나리오 가격은 평균 cost_per_task의 3배 아래로 내려가지 않는다” 같은 단순한 제품 룰이 없다면, 마진을 잃고도 월말까지 눈치채지 못하기 쉽습니다.

실수 №6: 수익화를 마케팅과 성장과 분리해 본다.
수익화와 가격은 진공 속에 존재하지 않습니다. 구독이 비싸질수록 이탈이 늘고 전환이 낮아집니다. 가격을 낮출수록 비용 최적화 요구는 높아집니다. “지금 얼마 버는가”만 보고, 이걸 획득/활성화/유지 지표(다음 주제에서 다룹니다)와 연결하지 않는 것은 실수입니다. 가격 실험도 품질/비용 실험과 같은 형식으로 로깅하여 전체 그림을 볼 수 있어야 합니다.