AI API 및 LLM 기반 제품을 위한 가격 책정 설계 방법

AI API 가격 책정은 순서대로 다음의 6가지 결정 사항으로 요약됩니다: 무엇을 측정할 것인가(meter), 어떤 기본 단위(primitive)에 비용을 부과할 것인가, 단위당 얼마를 부과할 것인가, 티어(tiers)를 어떻게 구성할 것인가, 하드 캡(hard cap) 또는 소프트 캡(soft cap) 중 무엇을 선택할 것인가, 그리고 크레딧 지갑(credit wallet)이 어떻게 작동할 것인가입니다. 이 가이드는 실제 예시와 달러 금액을 통해 각 항목을 살펴봅니다. 마지막에는 자신의 가격 책정을 진단하기 위해 붙여넣을 수 있는 Claude 프롬프트가 포함되어 있습니다.

제가 이 블로그 포스트를 쓰는 이유는 한 창업자와 대화를 나누던 중 그가 보여준 가격 페이지 때문이었습니다. 그 페이지에는 "1k 토큰당 $0.02"라고 적혀 있었습니다... 고객이 인보이스(invoice)에서 무엇을 보게 되는지 물었을 때... 저는 그 답변이 마음에 들지 않았습니다. 그래서 이 글은 향후 18개월 동안의 손익계산서(P&L)를 괴롭히게 될 결정을 앞둔 창업자, PM(Product Manager), 그리고 수익화(monetization) 책임자들을 위해 작성되었습니다.

AI 가격 책정 플랜의 구조

전통적인 API 가격 책정에서 **플랜(plan)**은 구독 티어(Free, Pro, Scale)를 의미합니다.

각 플랜 내부에는 이를 구성하는 단계(phases)(14일간의 트라이얼, 그 후의 기본 단계)가 있습니다.

각 단계 내부에는 측정 단위(meter)를 가격 및 권한(entitlement)과 연결하는 **요금표(rate cards)**가 있습니다. 트라이얼 기간 동안에는 "상시(evergreen)" 단계보다 더 많은 기능을 제공받을 수도 있습니다.

AI 가격 책정은 이 구조에 세 가지 변주를 추가합니다.

측정 단위(meter)는 더 이상 단순한 "요청(requests)"이 아닙니다. 그것은 토큰(tokens, 입력 및 출력), 크레딧(credits, 추상화된 단위), 또는 결과물(outcomes, 완료된 작업, 해결된 티켓, 생성된 문서)입니다.

요금표(rate card)는 고객에게 보여지는 하나의 가격 아래에 있는 여러 모델 비용을 처리해야 합니다.

권한(entitlement)은 카운터(counter)가 아니라 지갑(wallet)입니다. 크레딧은 축적되고, 만료되며, 이월(roll over)되고, 여러 기능에 걸쳐 소비됩니다.

또한, AI 가격 책정은 더 자주 변하기 때문에 기존의 SaaS(Software as a Service)보다 단계(phases)가 더 중요합니다. 모델 제공업체가 가격을 인하하거나, 귀사가 새로운 크레딧 요율을 출시하거나, 고객이 트라이얼(trial) 기간을 연장하는 등의 모든 상황은 단순히 계약 수정이 아니라 하나의 '상전이(phase transition)'를 일으킵니다.

이로 인해 순차적으로 내려야 할 6가지 결정 사항이 생깁니다.

1단계: 미터링(metering)할 항목 선택하기

미터(meter)는 귀사가 측정하는 대상입니다. 이를 잘못 선택하면 향후 2년 동안 청구서가 공정한지를 두고 고객과 싸워야 할 수도 있습니다.

AI 제품의 경우, 네 가지 미터가 주를 이룹니다:

입력 + 출력 토큰 (Input + output tokens) (OpenAI, Anthropic, Mistral)
크레딧 (Credits) (Cursor, Notion AI, Linear AI)
결과물 (Outcomes) (해결된 대화당 $0.99를 부과하는 Intercom Fin)
컴퓨팅 시간 (Compute time)

미터는 고객이 인지하는 가치(customer-perceived value)와 귀사의 매출원가(cost of goods)라는 두 가지 요소와 동시에 상관관계가 있어야 합니다. 멀티 모델(multi-model) 제품에서 요청당 고정 요금(flat per-request meter) 방식을 사용하면, 고객이 5만 토큰 규모의 프롬프트를 보내는 순간 (이미 낮은) 매출 총이익률(gross margin)에 큰 타격을 줄 것입니다.

💡 확정해야 할 결정 사항: 정확한 정의를 포함한 미터의 종류.

이를 명확히 기록하세요 - "1 토큰 = GPT-5.5 스타일 토큰 1개, 입력 + 출력 합산". 제 경험상 모호한 정의는 고객 분쟁의 원인이 되며, 이는 아주 쉽게 피할 수 있는 문제입니다.

2단계: 가격 책정 기본 단위(pricing primitive) 선택하기

내부적으로 별도의 계산을 수행하더라도, 고객에게 노출되는 단위(customer-facing unit)를 사용할 것을 권장합니다.

기본 단위 (Primitive)	과금 대상	효과적인 경우	사용하지 말아야 할 경우
토큰 (Token)	1k당 요율로 적용되는 입력 + 출력 토큰	직접적인 API 제품, 기술적 구매자, OpenAI 스타일의 리셀러	멀티 모델 사용, 출력량이 크게 변동하는 경우, 비기술적 구매자
...

가격 변경 과정에서 성공적으로 안착하는 대부분의 제품은 결국 이 세 가지를 동시에 운영하게 됩니다.

예를 들어, API의 헤비 유저(power users)에게는 토큰당 과금(per-token)을 적용하고, 패키지 제품에는 크레딧(credits)을 사용하며, 엔터프라이즈 계약에는 그 위에 결과 기반 가격 책정(outcome pricing)을 추가하는 방식이 있습니다.

Agentforce는 대화(conversation)당 비용을 청구하고, Fin은 결과 기반(outcome-based)으로 운영되지만, Cursor는 크레딧(credits)을 사용하고 OpenAI는 토큰(tokens)을 사용합니다. 모두 유효한 방식이지만, 비즈니스 모델에 따라 크게 달라집니다.

따라서 다시 강조하자면, 결과(outcomes)를 정의할 수 있다면 결과 기반을 최우선으로, 유연성을 위해서는 크레딧을 두 번째로, 피할 수 없는 경우에만 마지막으로 토큰을 고려하십시오.

💡 결정 사항: 어떤 기본 단위(primitive)를 송장에 표시할 것인가.

3단계: 비용을 계산하고 가격을 설정하십시오

참고하기 좋은 예시를 들어보겠습니다. 귀하의 제품이 사용자 요청당 한 번의 Claude Opus 4.8 호출을 수행한다고 가정합니다. Anthropic은 입력 토큰 100만 개당 $5, 출력 토큰 100만 개당 $25를 청구합니다.

평균 요청이 1k의 입력 토큰과 500개의 출력 토큰을 사용한다면, 요청당 비용은 $0.005 + $0.0125 = $0.0175가 됩니다.

이 비용을 바탕으로 고려할 수 있는 세 가지 가격 책정 접근 방식은 다음과 같습니다:

원가 가산 방식 (Cost-plus markup): 요청당 $0.035를 청구합니다. 매출 총이익률(gross margin)은 50%입니다. 예측 가능하고 방어 가능하지만 지루한 방식입니다. API 리셀러(reseller) 카테고리에서는 작동하지만, 비용 프로필이 다른 두 번째 모델을 추가하는 순간 무너집니다.
가치 기반 방식 (Value-based): 고객에게 생성된 문서의 가치가 $1라면, 고객은 그만큼을 지불할 용의가 있습니다. $0.50를 청구하면 매출 총이익률은 약 96.5%가 됩니다. 경쟁사가 가격을 낮추면 위험할 수 있지만, 해자(moat)를 가지고 있다면 매우 탁월합니다. (전형적인 Salesforce의 전략입니다. 다만 AI 시대에는 해자가 얇아졌기 때문에 양상이 달라졌습니다.)
크레딧 기반 추상화 (Credit-based abstraction): 크레딧을

참고: Opus 4.7은 이전 Opus 모델과 비교하여 동일한 입력 텍스트에 대해 최대 35% 더 많은 토큰을 사용할 수 있는 새로운 토크나이저 (tokenizer)를 도입했습니다. 동일한 프롬프트와 동일한 모델 제품군이라도 35% 더 큰 청구 금액이 발생할 수 있습니다. 만약 귀하의 가격 책정이 토큰당 (per-token) 방식이라면, 쉽게 전가할 수 없는 가격 인상을 그대로 떠안게 되지만, 크레딧당 (per-credit) 방식이라면 내부적으로 크레딧 대비 토큰 비율을 조정함으로써 고객이 아무것도 눈치채지 못하게 할 수 있습니다. [크레딧을 아키텍처로 사용하기, 다시 한번].

저에게 있어 실질적인 규칙은, 고객의 월간 청구 금액을 ±20% 이내로 예측할 수 없다면 귀하의 가격 책정이 비용과 너무 밀접하게 결합되어 있다는 것입니다. 통제된 비율을 가진 크레딧 방식은 이를 어느 정도 해결해 주지만, 비용 가산 방식의 토큰당 (cost-plus per-token) 방식은 확실히 해결하지 못합니다.

💡 고정할 결정 사항: 단위당 가격 (선택한 어떤 기본 단위든 상관없음) 및 목표 매출 총이익률 (gross margin).

4단계: 티어 구조 구축하기

대부분의 AI 제품은 4~5개의 티어 (tier)로 구성됩니다. 숫차보다 구조가 더 중요합니다. 숫자는 바꿀 수 있지만, 구조(shape)는 쉽게 바꿀 수 없습니다.

고려할 수 있는 시작점은 다음과 같습니다:

티어 (Tier)	월 가격	포함 사항	제한 유형	적합한 대상
Sandbox	$0	월 100 크레딧	하드 캡 (Hard cap)	평가 중인 개발자, 데모
...

저는 무료 티어에는 하드 캡 (hard cap, 남용으로부터 이익률 보호)을 적용하거나, 유료 티어에는 초과 사용료가 발생하는 소프트 캡 (soft cap, 고객이 확장할 수 있도록 허용)을 적용하고, 최상위 티어에는 약정 기반 (commit-based) 방식을 적용하는 것을 선호합니다.

주의할 점은, 무료 티어는 일반적으로 고객 획득 비용 (acquisition cost)이라는 것입니다. 따라서 남용 경계선을 고려하여 가격을 책정하십시오. 100 크레딧은 개발자가 "Hello World"를 실행하는 데 충분하지만, 10,000 크레딧은 취미 활동가가 귀하의 비용으로 실제 결과물을 만드는 데 충분할 수 있습니다. 이를 미리 계획하고 있다면 괜찮지만, 남용의 경계선은 가입자당 비용이 고객 획득 비용 (CAC)에 실질적인 타격을 주기 시작하는 지점입니다.

또한 초과 사용량 (Overage)에 대해 포함된 요율의 2~3배를 부과하는 것이 표준이라는 점도 주목할 만합니다. 3배보다 높게 책정하면 고객이 내부적으로 사용량을 엄격하게 제한 (Hard-cap)하게 되어, 결과적으로 귀사의 확장 매출 (Expansion revenue)을 억제하고 제품을 망칠 수 있습니다 (고객에게 강탈하는 듯한 느낌을 주기 때문입니다). 1.5배보다 낮게 책정하면 헤비 유저 (Power users)에 의해 마진이 확실히 유출됩니다.

💡 확정해야 할 결정 사항: 티어(Tier) 수, 티어별 포함 사용량, 티어별 가격, 티어별 초과 사용 요율.

5단계: 하드 캡 (Hard cap) vs 소프트 캡 (Soft cap) 결정

하드 리미트 (Hard limits)는 권한이 소진되었을 때 요청을 차단합니다. 고객은 에러를 받게 되며 (HTTP 429를 고려하세요!), 업그레이드를 하거나 기간이 갱신될 때까지 중단됩니다.

소프트 리미트 (Soft limits)는 권한을 초과하여 사용을 계속할 수 있게 하며, 기간 경계 시점에 초과 사용량을 청구합니다.

하드 리미트를 사용하는 경우:

무료 티어 및 트라이얼 (Trials)
고객이 초과 사용 약관에 동의하지 않은 모든 경우
개발자 샌드박스 (Sandboxes) 및 테스트 환경

소프트 리미트를 사용하는 경우:

계약서에 초과 사용 약관이 포함된 유료 티어
차단될 경우 운영 시스템 (Production system)이 중단될 수 있는 모든 경우
사용량을 극대화하고 신용 한도 (Credit lines)를 보유한 스케일 및 엔터프라이즈 (Enterprise) 고객

제가 흔히 보는 실수 중 하나는 "고객을 놀라게 하거나 앱이 작동을 멈추게 하고 싶지 않다"는 이유로 유료 티어에 하드 리미트를 설정하는 것입니다. 이는 숭고한 의도이지만, 월말에 엄청나게 큰 청구서를 받는 것 또한 좋지 않습니다. 관대한 지출 알림 (Spend alert)을 동반한 소프트 리미트가 정답입니다.

💡 확정해야 할 결정 사항: 티어별 하드 또는 소프트 적용 여부, 소프트 적용 시 초과 사용 가격, 알림 임계값 (권한의 50%, 80%, 100%).

6단계: 크레딧 지갑 (Credit wallet) 설계

만약 귀사의 기본 단위 (Primitive)가 크레딧 (Step 2)이라면, 지갑은 전체 가격 책정 경험 그 자체입니다. 네 가지 결정 사항을 잘못 내린다면 고객이 귀사를 참아줄 수는 있어도 결코 신뢰하지는 않을 것입니다.

만료 (Expiry)

크레딧이 만료됩니까? 월말 만료는 가혹하며, 연말 만료는 관대합니다. 계약 종료 시 만료는 엔터프라이즈의 기본 설정입니다.

만료 기간이 없다는 것은 재무제표상 꽤 심각한 부채(Liability)를 생성합니다. 따라서 "크레딧은 절대 만료되지 않습니다"를 마케팅 문구로 출시하기 전에 반드시 CFO(최고재무책임자)와 상의하십시오.

이월 (Rollover)

기간 경계에서 사용하지 않은 크레딧은 어떻게 됩니까? 전체 이월(Full rollover)이 사용자에게 가장 친화적이지만, 일부는 부분 이월(Partial rollover)을 시행하기도 합니다.

이월이 전혀 되지 않는 것은 최악입니다. 고객들은 결국 이를 알아차리고 불만을 갖게 될 것입니다.

충전 (Top-ups)

고객이 주기 중간에 더 많은 크레딧을 구매할 수 있습니까?

동일한 가격으로 제공합니까, 아니면 프리미엄 가격을 적용합니까?

셀프 서비스(Self-serve)입니까, 아니면 영업 지원(Sales-assist) 방식입니까?

충전은 고객 만족도가 결정되는 지점입니다. 이 과정에서의 마찰(Friction)은 "제품은 정말 좋지만 결제 방식이 짜증 난다"라는 반응을 일으키는 가장 큰 원인입니다.

다중 미터 상환 (Multi-meter redemption)

하나의 크레딧 풀(Credit pool)을 여러 기능(채팅, 검색, 생성)에 걸쳐 사용할 수 있습니까? 아니면 각 기능마다 별도의 풀을 가집니까?

단일 풀(Single pool)이 더 친화적이고 간편하지만, 다중 풀(Multi-pool)은 ASC 606 규정에 따른 수익 인식(Revenue-recognition)이 더 용이합니다. 결국 고객의 요구에 따라 단일 풀을 사용하게 될 것입니다.

💡 확정해야 할 결정 사항: 만료 정책, 이월 정책, 충전 흐름, 단일 풀 vs 다중 풀.

모델 가격 하락에 대비한 계획

Anthropic은 Opus의 가격을 1M 토큰당 입력 $15 / 출력 $75(Opus 4.1)에서 $5 / $25(Opus 4.5 및 이후 버전)로 낮췄습니다. 라인업 중 가장 프리미엄 모델의 가격을 3배나 인하한 것입니다.

OpenAI는 매 분기 유사한 행보를 보이며... 네, 맞습니다. 이를 예측하여 계획을 세우기는 매우 어렵습니다.

만약 고정 마진을 붙여 토큰당 가격(Per-token pricing)을 책정했다면, 귀사의 매출 총이익률(Gross margin)은 방금 3배가 되었습니다. 손익계산서(P&L)에는 좋지만, 이제 청구 금액이 너무 높다고 느끼게 될 고객에게는 좋지 않습니다.

60일 이내에 가격 재협상 요청이 들어오거나, 자동으로 가격을 재조정하는 벤더로 고객이 이탈할 것을 예상해야 합니다.

만약 크레딧 기반(Credit-based)으로 가격을 책정했다면, 선택권이 있습니다. 크레딧 비율을 유지하여 마진을 확보하십시오. 또는 비율을 낮추어 절감액을 고객에게 전달하십시오. 혹은 재균형(Rebalance)을 맞추십시오. 구형 모델의 비율은 낮추고, 신형 모델의 비율은 유지하는 방식입니다.

결과 기반(Outcome-based)으로 가격을 책정했다면, 거의 눈치채지 못할 것입니다. Opus 4.7을 사용하든 Haiku 4.5를 사용하든 고객은 해결 건당 0.99달러를 지불합니다. 마진(Margin)은 자동으로 복리로 쌓입니다. (결과 기반 가격 책정이 왜 가장 지속 가능한 형태인지, 그리고 왜 출시 첫날 구현하기 가장 어려운지에 대한 이유입니다.)

여러분이 반드시 알아야 할 인프라 질문은, '여러분의 빌링 시스템(Billing system)이 이전 인보이스(Invoice)를 다시 작성하지 않고도 주기 중간에 크레딧 요율(Credit rate)을 변경할 수 있는가?'입니다. 만약 그렇지 않다면, 모든 모델의 가격 인하는 하나의 프로젝트이자 마이그레이션(Migration) 작업이 되며, 이는 실제로 큰 타격을 줄 수 있습니다.

Claude를 사용하여 가격 책정 진단하기

이 프롬프트를 Claude(또는 성능이 뛰어난 다른 모델)에 복사하십시오. 이 프롬프트는 여러분과 함께 탐색(Discovery)을 수행하고 티어 테이블(Tier table)과 그 근거를 반환합니다. 모델이 가격 지점(Price points)을 정확하게 맞추지는 못할 것입니다. 그것은 여러분의 판단과 데이터의 영역입니다. 하지만 모델은 구조(Shape)를 정확하게 잡아내며, 60일간의 설계 작업을 절약해 줍니다.