제7부 제품·서비스(Product/Service)

7.5 비용·유닛 이코노믹스·가격 설계

전통 SaaS를 운용해 본 사람이 LLM 제품을 처음 세우면 대개 같은 자리에서 넘어진다. 가입자가 늘고, 리텐션이 좋고, 대시보드의 지표가 전부 초록불인데, 청구서가 매출보다 빠르게 오른다. 소프트웨어 회사의 상식 — 사용자를 한 명 더 받는 데 드는 한계비용은 사실상 0이고, 그래서 매출총이익률이 80~90%대이며, 규모가 커질수록 마진이 좋아진다 — 이 LLM 서비스에서는 깨진다. 사용자가 한 번 더 대화를 보낼 때마다 실제 현금이 나간다. 토큰이 청구되고, GPU 시간이 소모된다. 대화가 길어지면 그 비용은 대화 길이의 제곱으로 자란다. 헤비 유저 한 명이 정액 요금의 열 배를 쓰고도 요금은 그대로다. 이 장은 그 현금 유출을 산식으로 세우고, 어디서 곱셈으로 손실되는지 다루고, 어떤 수단으로 막는지, 그리고 그 위에 어떤 가격을 매겨야 마진이 유지되는지를 다룬다.

가장 먼저 깨야 할 통념은 "토큰 단가가 계속 싸지니 비용은 신경 안 써도 된다"는 것이다. 단가는 실제로 내려간다. 그런데 사용량은 그보다 빠르게 는다 — 컨텍스트 창이 커지고, 추론 모델이 답 전에 더 오래 생각하고, 에이전트가 한 작업에 수십 번 모델을 호출하고, 멀티턴 대화 이력이 매 턴 전부 재전송된다. 비용은 단가가 아니라 단가 × 사용량이고, 지난 몇 년간 사용량 쪽이 단가 하락을 압도해 왔다. 이 장의 관심은 거의 전부 사용량 쪽이다.

이 장에 나오는 구체적인 달러 숫자 — 모델 단가, 캐시 배수, GPU 시간당 요금 — 는 개략 규모를 보여 주기 위한 개략 예시다. 벤더마다, 모델마다, 시점마다 다르고 수시로 개정된다. Claude/Anthropic의 정확한 단가·프롬프트 캐시 스펙은 claude-api와 공식 문서를, 다른 벤더와 GPU 클라우드 요금은 각 공식 가격표를 출처로 확인해야 한다. 이 장의 무게는 특정 숫자가 아니라 산식과 그것이 가리키는 방향에 있다.

7.5.1 요청 하나의 비용과 입력·출력의 비대칭

LLM 서비스 비용의 최소 단위는 토큰이다. 대부분의 매니지드 API는 입력 토큰 수와 출력 토큰 수를 따로 세어, 각각에 다른 단가를 곱한다. 요청 하나의 비용은

$$C_{\text{req}} = \frac{n_{\text{in}}\,p_{\text{in}} + n_{\text{out}}\,p_{\text{out}}}{10^{6}}$$

로, 단가 $p$ 는 백만 토큰당 달러다. 이 식에서 초보가 놓치는 것은 $p_{\text{in}}$ 과 $p_{\text{out}}$ 이 같지 않다는 사실이다. 출력 토큰이 입력 토큰보다 훨씬 비용이 크다. 벤더·모델에 따라 대략 3배에서 5배다. 어떤 프런티어 모델이 입력 백만 토큰당 5달러, 출력 백만 토큰당 25달러라면 출력이 정확히 5배다. 이 비대칭은 벤더의 자의적 가격 정책이 아니라 추론의 물리에서 곧장 나온다.

5.1에서 한 요청이 성격이 정반대인 두 국면으로 나뉜다는 것을 보았다. 입력 토큰을 처리하는 프리필은 프롬프트 전체를 한 번의 순전파에 병렬로 투입한다. GPU에 크고 통통한 행렬곱이 흘러 텐서 코어가 바쁘게 실행되고, 연산 바운드라 하드웨어를 효율적으로 쓴다. 토큰 하나를 처리하는 데 드는 실효 GPU 시간이 짧으니 저렴하게 매길 수 있다. 반면 출력 토큰을 만드는 디코드는 토큰을 하나씩 직렬로 생성한다. 매 스텝 모델 가중치 전체와 KV 캐시를 메모리에서 읽어야 하는데 그걸로 고작 토큰 하나를 뽑고 버린다. 대역폭 바운드라 GPU가 대부분 유휴 상태다. 토큰 하나를 만드는 데 드는 실효 GPU 시간이 길으니 높게 매길 수밖에 없다.

즉 벤더가 매기는 입력·출력 단가의 비대칭은 그들의 서빙 비용 구조를 그대로 옮긴 것이다. 여기서 실무적으로 가장 중요한 따름결론이 나온다. 비용을 줄이려 할 때 출력 토큰을 한 개 줄이는 것이 입력 토큰을 한 개 줄이는 것보다 서너 배 이득이다. 그래서 "짧고 정확하게 답하라"는 지시, max_tokens 상한, 장황한 서론·재확인의 제거가 토큰당 효과가 가장 큰 수단에 속한다. 반대로 "입력을 아끼자"는 직관만 따르면 비용이 큰 쪽을 놓친다 — 프롬프트를 몇백 토큰 다듬는 것보다 응답을 절반으로 줄이는 편이 대개 더 크게 절감된다.

7.5.2 무상태 재전송과 대화 비용의 제곱 성장

요청 하나의 비용은 위 식으로 끝이다. 그런데 챗은 요청 하나로 끝나지 않는다. 멀티턴 대화가 어떻게 과금되는지를 정확히 보지 않으면 예산이 자릿수로 빗나간다.

핵심은 LLM API가 무상태라는 점이다. 서버는 대화를 기억하지 않는다. 지난 턴에 무슨 말이 오갔는지 API 쪽에는 남아 있지 않으므로, 매 턴 클라이언트가 지금까지의 전체 대화 이력을 다시 입력으로 보낸다. 대화가 길어질수록 입력 토큰이 매 턴 누적된다. 시스템 프롬프트를 $S$, $t$번째 사용자 발화를 $u_t$, $t$번째 응답을 $a_t$ 라 하면, 턴 $t$ 의 입력은 지금까지 오간 모든 것에 이번 발화를 더한 것이다.

$$\text{턴 } t \text{ 의 입력 토큰} = S + \sum_{k<t}(u_k + a_k) + u_t$$

$T$턴 대화 전체의 입력 토큰을 합하면

$$\sum_{t=1}^{T}\Big[S + u_t + \sum_{k<t}(u_k + a_k)\Big] = T S + \sum_{t=1}^{T} u_t + \sum_{t=1}^{T}\sum_{k<t}(u_k + a_k)$$

이 된다. 발화·응답 길이가 대략 균일하다고($u_t = u$, $a_t = a$) 두면 마지막 이중합이 간결해진다. 턴 $t$ 는 이전 $t-1$개 턴의 발화·응답을 다시 실으므로 $\sum_{t=1}^{T}(t-1) = \tfrac{T(T-1)}{2}$ 이고,

$$\text{입력 토큰 총합} = \underbrace{T S}_{\text{시스템 반복}} + \underbrace{T u}_{\text{사용자 발화}} + \underbrace{(u+a)\frac{T(T-1)}{2}}_{\text{이력 재전송}}$$

출력 토큰 총합은 $T a$ 로 턴 수에 선형이다. 대화 비용은 이 둘에 각각 단가를 곱한 것이다.

$$C_{\text{conv}} = \Big[T S + T u + (u+a)\tfrac{T(T-1)}{2}\Big] p_{\text{in}} + T a\, p_{\text{out}}$$

이 식에서 주목할 것은 재전송 항이다. $T$ 가 커지면 $\tfrac{T(T-1)}{2} \approx \tfrac{T^2}{2}$ 이므로 대화 입력 비용은 턴 수에 대해 제곱으로 자란다. 왜 이런 일이 벌어지는지가 결정적이다. $t$번째 응답으로 (비용이 큰 출력 단가로) 생성한 토큰은, 그 뒤 모든 턴에서 다시 (입력 단가로) 청구된다. 출력이 한 번 나오고, 그 뒤로 계속 입력으로 재청구되는 것이다. 응답이 길수록 이후 모든 턴의 입력이 부하가 커지니, 출력의 비용은 그 자리에서 끝나지 않고 대화의 남은 길이에 곱해져 되돌아온다. 긴 대화·긴 컨텍스트가 청구서를 조용히 폭증시키는 근본 이유가 여기 있다.

이 제곱 성장이 앞 절의 통념 — "토큰 싸지니 걱정 없다" — 을 붕괴시키는 첫 번째 메커니즘이다. 단가가 절반이 되어도 사용자가 대화를 두 배 길게 이어 가면(요즘 제품이 정확히 그렇게 유도한다) 재전송 항이 네 배가 되어 총비용이 오른다. 이 꼬리를 꺾는 것이 프리픽스 캐시(5.6)와 대화 이력의 요약·컴팩션(7.1)이다. 둘 다 "이미 오간 이력을 매 턴 정가로 다시 처리하지 않는" 방법이라는 점에서 같은 병을 겨냥한다.

7.5.3 워크스루 — 단발 요청과 10턴 대화

식만 보면 미끄러진다. 개략 단가를 넣어 끝까지 계산해 개략을 파악하자. 아래 단가는 전부 설명용 예시다.

단발 요청 하나. 입력이 시스템 프롬프트 500 토큰에 사용자 발화 500 토큰을 더한 1,000 토큰, 출력이 500 토큰이라 하자. 입력 단가 $p_{\text{in}} = \$3/\text{1M}$, 출력 단가 $p_{\text{out}} = \$15/\text{1M}$ 이면

$$C = \frac{1{,}000 \times 3 + 500 \times 15}{10^{6}} = \frac{3{,}000 + 7{,}500}{10^{6}} = \$0.0105 \approx \$0.01/\text{요청}$$

입력 토큰이 출력의 두 배인데도 비용은 출력 쪽이 더 크다 — 입력 몫 \$0.003, 출력 몫 \$0.0075. 앞 절의 단가 비대칭이 숫자로 드러난다. 요청 하나가 대략 1센트라는 이 규모를, 아래에서 대화와 월 단위로 키워 보자.

10턴 대화 하나. 시스템 프롬프트 $S = 500$, 매 턴 사용자 발화 $u = 100$, 응답 $a = 300$, $T = 10$턴이라 하자. 입력 토큰 총합은 7.5.2의 식으로

$$T S + T u + (u+a)\tfrac{T(T-1)}{2} = 5{,}000 + 1{,}000 + 400 \times 45 = 6{,}000 + 18{,}000 = 24{,}000$$

이고, 출력 토큰 총합은 $T a = 3{,}000$ 이다. 비용은

$$C_{\text{conv}} = \frac{24{,}000 \times 3 + 3{,}000 \times 15}{10^{6}} = \frac{72{,}000 + 45{,}000}{10^{6}} = \$0.117 \approx \$0.12/\text{대화}$$

여기서 읽어야 할 것은 총액이 아니라 구성이다. 입력 24,000 토큰 중 18,000 토큰, 즉 75%가 이력 재전송이다. 이 대화에서 사용자가 실제로 "새로" 입력한 것은 발화 1,000 토큰뿐이고 모델이 새로 생성한 것은 3,000 토큰뿐인데, 무상태 재전송이 입력을 여섯 배로 부풀렸다. 대화를 20턴으로 늘리면 재전송 항이 $400 \times 190 = 76{,}000$ 으로 증가해 — 턴 수는 두 배인데 재전송은 네 배 넘게 — 대화 비용이 세 배 이상이 된다. 이것이 "대화가 길수록 재전송 꼬리가 지배한다"의 산술이다.

7.5.4 비용 동인은 더해지지 않고 곱해진다

지금까지는 순진한 단발 챗의 비용이었다. 실서비스의 비용이 예산을 넘기는 이유는 동인들이 서로 곱해지기 때문이다. 각 동인이 독립적으로 몇 배씩 붙으니, 하나만 방심해도 청구서 금액이 자릿수로 증가한다.

모델 크기·티어. 큰 모델은 토큰 단가가 몇 배 비용이 크다 — 프런티어 모델이 소형 모델의 5배에서 20배일 수 있다. 같은 작업이라도 어느 티어에 할당하느냐로 비용이 자릿수로 갈린다. 다만 단가만 보면 함정에 빠진다. 큰 모델이 한 번에 맞히는 일을 작은 모델이 세 번 재시도하고 결국 큰 모델로 에스컬레이션한다면, 작은 모델을 쓴 총비용이 오히려 더 클 수 있다. 봐야 할 것은 토큰 단가가 아니라 작업 완수당 비용이다.

입력 컨텍스트 길이. 입력 토큰은 시스템 프롬프트, RAG로 삽입한 문서, few-shot 예시, 그리고 앞 절의 대화 이력으로 채워진다. 컨텍스트를 늘리면 입력 과금이 토큰 수에 선형으로 붙고, 게다가 프리필 어텐션이 길이 제곱으로 늘어 TTFT까지 나빠진다. "컨텍스트 창이 1M이니 관련 있어 보이는 건 다 넣자"는 접근은 넣는 것 자체가 매 요청 과금이라는 점에서 비용이 크다. 검색을 정밀하게 해 실제 필요한 청크만 넣는 것이 품질과 비용을 동시에 산다(6.4).

출력 길이. 출력은 단가가 비용이 크므로 가장 비용 민감한 축이다. 장황한 응답, 불필요한 서론과 재확인, 구조화되지 않은 장문은 그대로 현금이다. 출력 상한과 간결 지시가 직접적인 절감 수단이고, 앞서 봤듯 토큰당 효과가 가장 크다.

재시도·검증 반복. 실서비스는 한 번에 끝나지 않는다. JSON 파싱이 실패해 재요청하고, 가드레일이 거부해 재생성하고, 애매한 답을 스스로 검증하며 다시 부른다. 이 반복은 요청 수를 배수로 늘린다. 재시도율이 $r$ 이면 성공까지의 기대 요청 수는 $1/(1-r)$ 배다. $r = 0.3$ 이면 약 1.43배, $r = 0.5$ 이면 정확히 2배 — 조용히 비용이 두 배가 될 수 있다. 재시도는 대개 프롬프트·스키마·가드레일의 문제라, 원인을 고치는 것이 곧 비용 절감이다.

에이전트 루프. 에이전트(6.6)는 관찰·행동·반성을 여러 번 반복한다. 각 스텝이 한 번의 LLM 호출이고, 매 스텝 전체 이력에 도구 결과까지 더해 다시 입력으로 넣는다 — 앞 절의 제곱 성장이 여기서도 작동하고, 도구가 출력하는 긴 결과(검색 결과, 파일 내용, 로그)가 이력에 쌓여 더 빠르게 부푼다. 스텝 10개 규모의 에이전트 작업 하나가 단발 챗의 수십 배 토큰을 쓸 수 있다. 멀티에이전트(6.7)는 에이전트 수만큼 또 곱해진다. 에이전트는 강력하지만 비용 곱셈기이며, 스텝 상한과 이력 압축 없이 풀어놓으면 작업 하나가 예산을 소진한다.

추론 모델의 긴 사고. 추론 모델(3.7)은 답을 내기 전에 사고사슬을 길게 생성해 test-time compute를 산다. 이 사고 토큰은 대부분 출력 토큰으로 과금된다 — 비용이 큰 쪽이다. 어려운 문제 하나에 수천에서 수만 사고 토큰을 쓸 수 있어, 같은 질문이라도 추론 모델은 일반 모델의 몇 배에서 수십 배 출력 비용을 낸다. 정답률은 오르지만 무비용이 아니다. "이 요청이 정말 깊은 추론을 요구하는가"를 라우팅으로 걸러, 추론 모델은 그럴 자격이 있는 요청에만 보내야 한다.

이 곱셈 구조가 "토큰 싸지니 걱정 없다"를 붕괴시키는 두 번째 메커니즘이다. 단가가 절반이 되어도, 제품이 단발 챗에서 에이전트로 진화하면서 스텝 수·컨텍스트·출력이 각각 몇 배씩 붙으면 총비용은 오른다. 단가 하락은 한 축의 선형 개선이고, 사용량 증가는 여러 축의 곱셈이다.

7.5.5 워크스루 — 월 사용자당 비용과 마진의 꼬리

이제 요청·대화 단위 비용을 사용자·월 단위로 높여 사업의 언어로 옮겨 보자. 앞의 10턴 대화 비용 \$0.12를 출발점으로 삼는다.

평균 사용자가 월 30회 대화한다면 추론 원가만 $30 \times \$0.12 = \$3.6/\text{월}$ 이다. 여기에 두 가지가 더 붙는다. 하나는 재시도 — 앞 절의 배수를 보수적으로 1.3배라 하자. 다른 하나는 추론 자체가 아닌 부대 인프라 — 임베딩·검색(6.2), 게이트웨이·로깅·관측성(7.2, 7.6), 안전·모더레이션 호출(7.3) — 로, 대략 추론 원가의 20%를 더한다고 보자. 그러면 사용자당 실효 원가는

$$3.6 \times 1.3 \times 1.2 \approx \$5.6/\text{월}$$

이다. 이 서비스를 월 \$20 구독으로 판다면 평균 사용자의 매출총이익률은 $(20 - 5.6)/20 \approx 72\%$ — 건강하다. 여기까지만 보면 사업은 잘 운영되는 것처럼 보인다.

문제는 평균이 거짓말을 한다는 데 있다. 사용량 분포는 대개 두터운 꼬리를 가진다. 상위 몇 %의 헤비 유저가 전체 토큰의 절반 이상을 쓴다. 월 300회 대화하는 헤비 유저 한 명의 원가는 $300 \times \$0.12 \times 1.3 \times 1.2 \approx \$56/\text{월}$ 로, \$20 매출을 크게 넘겨 명백한 적자다. 정액·무제한 요금에서는 이 사용자를 막을 장치가 없고, 원가에 상한이 없으니 헤비 유저 몇 명이 평균 사용자 수십 명의 이익 전체를 잠식한다. 그래서 LLM 서비스의 유닛 이코노믹스는 평균이 아니라 분포로, 특히 상위 사용량 구간이 마진을 어디까지 잠식하는지로 봐야 한다. SaaS에서는 헤비 유저가 오히려 반가운 신호(제품 애착·업셀 기회)였지만, 한계비용이 0이 아닌 세계에서는 상한 없는 헤비 유저가 곧 손실이다. 이 사실이 뒤에서 볼 마진 보호 장치(7.5.11)를 필수로 만든다.

7.5.6 비용을 낮추는 수단들 — 절감 크기와 트레이드오프

비용을 줄이는 수단은 여럿이고, 각각 겨냥하는 축·절감 크기·트레이드오프가 다르다. 하나로 다 해결되지 않으니 워크로드에 맞춰 조합한다. 아래 절감폭은 워크로드에 크게 의존하는 개략값이다.

수단은 크게 두 층으로 갈린다. 애플리케이션 층 — 캐시, 라우팅, 캐스케이드, 프롬프트 압축, 출력 제한 — 은 남의 API를 쓰든 자체 서빙이든 내 코드로 통제할 수 있다. 서빙 층 — 양자화(5.2), 연속 배칭·PagedAttention(5.3) — 은 자체 서빙일 때만 내 손에 있다. API를 쓰면 서빙 층 최적화는 벤더가 하고, 나는 그 결과인 단가를 받을 뿐이다. 그래서 API 사용자에게 실질적인 수단은 거의 전부 애플리케이션 층에 있다.

각 수단이 겨냥하는 축이 다르다는 점이 중요하다. 캐시는 입력만, 출력 제한은 출력만, 라우팅은 티어만 변경한다. 그래서 하나로 부족하고 조합해야 한다 — 출력이 지배적인 워크로드(리포트 생성·추론 모델)에서 캐시만 켜면 총절감이 실망스럽고, 반대로 반복 프리픽스가 큰 워크로드(같은 문서에 여러 질문)에서 출력 제한만으로는 입력 낭비를 못 검출한다.

워터폴의 숫자를 그대로 믿으면 안 된다. 각 절감폭은 곱셈적이고 워크로드에 의존한다. 캐시는 프리픽스가 실제로 재사용될 때만, 라우팅은 난이도 분포가 넓어 쉬운 요청이 많을 때만, 자체 서빙은 GPU 활용률이 높을 때만 이득이다. 이론은 어느 수단을 적용할지 방향을 주고, 실제 절감 값은 자기 트래픽에서 A/B로 측정해야 나온다. 특히 순서가 값에 영향을 준다 — 라우팅으로 이미 절반을 소형 모델에 보낸 뒤 캐시를 켜면, 캐시가 절감할 절대 금액은 라우팅 전보다 작다.

7.5.7 워크스루 — 프리픽스 캐시 적용 전후의 달러 회계

프리픽스 캐시는 애플리케이션 층에서 가장 큰 절감을 내는 수단 중 하나지만, "입력만 아낀다"는 한계 때문에 총절감률은 언제나 입력 절감률보다 낮다. 이것을 달러로 끝까지 계산하면 그 한계가 눈에 드러난다.

같은 문서에 여러 질문을 하는 Q&A 서비스(6.3)를 생각하자. 공유 프리픽스 $P = 10{,}000$ 토큰(시스템 프롬프트에 few-shot에 긴 문서), 요청별 질문 $Q = 200$ 토큰, 응답 $O = 500$ 토큰, 그리고 같은 프리픽스로 들어오는 요청이 캐시 유효시간 안에 $N = 100$ 개라 하자. 단가는 입력 정가 \$3/1M, 출력 \$15/1M, 그리고 캐시는 쓰기가 정가의 1.25배($\$3.75/\text{1M}$), 읽기가 정가의 0.1배($\$0.30/\text{1M}$)라 두자(이 배수는 벤더마다 다르다).

캐시 없이는 매 요청이 프리픽스와 질문을 정가로 처리하고 출력을 낸다.

$$C_{\text{no}} = N \times \frac{(P + Q)\times 3 + O \times 15}{10^{6}} = 100 \times \frac{10{,}200 \times 3 + 500 \times 15}{10^{6}} = 100 \times 0.0381 = \$3.81$$

프리픽스 캐시를 켜면 첫 요청(콜드)만 프리픽스를 쓰기 단가로 캐시에 적재하고, 나머지는 읽기 단가로 재사용한다.

$$\text{요청 1(콜드)}: \frac{10{,}000 \times 3.75 + 200 \times 3 + 500 \times 15}{10^{6}} = \frac{37{,}500 + 600 + 7{,}500}{10^{6}} = \$0.0456$$

$$\text{요청 2~100(웜, 99개)}: 99 \times \frac{10{,}000 \times 0.30 + 200 \times 3 + 500 \times 15}{10^{6}} = 99 \times 0.0111 = \$1.0989$$

합계는 \$1.14다. 결과를 갈라 읽자.

입력은 87% 줄었는데 총비용은 70%만 줄었다. 차이는 순전히 출력 때문이다. 출력 \$0.75는 캐시가 손대지 못하고 그대로 남는다 — 캐시는 프리필의 KV를 재사용할 뿐 디코드를 대신 해 주지 않는다. 여기서 실무 규칙이 하나 나온다. 출력이 길수록 캐시의 총절감률은 낮아진다. 위 예에서 출력을 500이 아니라 5,000 토큰으로 바꾸면 출력 몫이 열 배가 되어 총비용 대비 비중이 커지고, 캐시로 입력을 아무리 아껴도 총절감률은 30%대로 주저앉는다. 리포트 생성이나 추론 모델처럼 출력이 지배적인 워크로드는 캐시만으로 부족하고, 출력 제한과 모델 라우팅을 반드시 병행해야 한다.

캐시를 켜는 것 자체에도 손익분기가 있다. 쓰기 프리미엄 1.25배는 프리픽스가 최소 두 번 이상 재사용돼야 회수된다. 위 계산은 프리픽스가 100번 재사용된다는 전제 위에 서 있다. 프리픽스가 매 요청 다르거나 재사용이 거의 없으면 캐시를 켜는 것이 오히려 불리하다 — 쓰기만 하고 읽지 못하기 때문이다. 켜기 전에 "이 프리픽스가 실제로 재사용되는가"를 usage의 캐시 읽기 토큰 수로 확인해야 하고, 캐시 유효시간(TTL) 안에 재사용이 몰리도록 요청을 배치·라우팅하는 것이 캐시 히트율을 좌우한다.

7.5.8 유닛 이코노믹스 — COGS·매출총이익·한계비용

개별 요청 비용을 넘어 "이 사업이 남는가"를 보는 것이 유닛 이코노믹스다. 핵심 지표는 매출총이익률이다.

$$\text{GM} = \frac{\text{ARPU} - \text{COGS}}{\text{ARPU}}$$

여기서 COGS(매출원가)는 서비스를 제공하는 데 드는 변동비다 — 추론 토큰 비용 또는 GPU 시간, 검색·임베딩, 게이트웨이·로깅·관측성, 안전·모더레이션 호출. 연구개발·인건비·마케팅은 COGS가 아니라 영업비용이다. 유닛 이코노믹스가 묻는 것은 "사용자를 한 명 더 받으면 그 한계에서 남는가"이고, 이 질문에는 변동비만 들어간다.

전통 SaaS와의 차이는 한 문장으로 요약된다. 소프트웨어 복제 비용이 사실상 0인 SaaS는 매출총이익률이 80~90%대이고 규모가 커질수록 좋아진다. LLM 서비스는 사용자가 쓸 때마다 토큰·GPU 현금이 나가므로 매출총이익률이 낮고, 결정적으로 사용량에 민감하다. 이 차이가 두 가지 실무적 귀결을 낳는다. 첫째, 앞서 봤듯 평균이 아니라 분포로 봐야 한다 — 평균 사용자가 흑자여도 헤비 유저가 적자면 상위 몇 %가 이익을 다 잠식한다. 둘째, 정액 요금에서 사용량이 무제한이면 사용자당 원가에 상한이 없다. 한 사용자가 마음껏 쓰면 원가가 매출을 넘긴다. SaaS의 직관 — "가입만 시키면 나머지는 거의 공짜" — 을 그대로 들여오면 성장할수록 적자가 깊어진다. 마진 보호가 선택이 아니라 구조적 필수인 이유가 여기 있다.

7.5.9 활용률이 자체 서빙 단가를 지배한다

자체 서빙(5.4, 5.5)으로 넘어가면 토큰 단가가 API처럼 고정된 상수가 아니라 활용률에 좌우되는 변수가 된다. GPU 시간당 요금을 $g$, 이 GPU가 최대로 낼 수 있는 처리량을 $\tau$(토큰/시간, 연속 배칭이 정하는 값), 실제 활용률을 $U \in (0, 1]$ 이라 하면 실효 토큰당 원가는

$$p_{\text{self}} = \frac{g}{\tau \times U}$$

이다. 이 식의 핵심은 분모의 $U$ 다. 활용률이 낮으면 토큰당 원가가 반비례로 치솟는다. GPU를 빌려 놓고 50%만 채워 쓰면 토큰 단가가 두 배, 20%만 쓰면 다섯 배, 10%면 열 배다 — 유휴 GPU에도 시간당 요금이 똑같이 나가기 때문이다. 자체 서빙의 유닛 이코노믹스는 결국 "GPU를 얼마나 꽉 채워 굴리느냐"에 사활이 걸린다.

숫자를 넣어 보자. $g = \$2/\text{hr}$, $\tau = 7.2\text{M tok/hr}$ 인 GPU를 완전히 채워 쓰면($U = 1.0$)

$$p_{\text{self}} = \frac{2}{7.2 \times 10^{6}} \approx \$0.28/\text{1M}$$

로, 웬만한 API 단가를 크게 밑돈다. 그런데 트래픽이 불균일해 평균 활용률이 20%로 떨어지면

$$p_{\text{self}} = \frac{2}{7.2 \times 10^{6} \times 0.2} \approx \$1.4/\text{1M}$$

로 다섯 배가 된다. 같은 하드웨어가 활용률 하나로 단가가 다섯 배 벌어지는 것이다. 활용률을 높이는 두 축이 곧 서빙 최적화다 — 연속 배칭(5.3)으로 배치를 키워 $\tau$ 를 높이고, 오토스케일(5.5)로 유휴 GPU를 줄여 $U$ 를 높인다. 이 둘이 곧 단가 인하다. 자체 서빙의 근본 난점도 여기서 나온다. 트래픽에 피크와 오프피크의 차이가 크면, 피크에 맞춰 프로비저닝한 GPU가 오프피크에 유휴 상태가 되어 평균 $U$ 가 떨어진다. 그래서 스파이크가 심한 소비자 트래픽은 자체 서빙의 활용률을 붕괴시키기 쉽고, 예측 가능한 배치성 트래픽이 자체 서빙에 유리하다. 이 값을 API 단가와 견주는 것이 다음 절의 손익분기다.

7.5.10 자체 서빙 vs API — 손익분기 볼륨

"직접 서빙할까, API를 쓸까"는 build vs buy(9.1)의 핵심 갈림이고, 그 판단의 큰 몫이 비용 손익분기다. 비용만으로 결정하라는 것이 아니라 — 품질·통제·데이터·인력도 함께 봐야 한다 — 비용 축의 산식을 정확히 세우자는 것이다.

API는 고정비가 0이고 토큰당 정가 $p_{\text{api}}$ 를 낸다. 비용은 볼륨 $V$ 에 선형이고 원점을 지난다 — 쓰는 만큼만 낸다. 자체 서빙은 고정비 $F$ 가 크고(GPU 프로비저닝·엔지니어링·MLOps·안정화) 한계 토큰당 원가 $p_{\text{self}}$ 가 낮다(단 앞 절대로 활용률에 의존). 비용은 대략 $F + V \times p_{\text{self}}$ 다. 두 선이 만나는 손익분기 볼륨보다 많이 쓰면 자체 서빙이 저렴하고, 적게 쓰면 API가 저렴하다.

거칠게, 자체 서빙 월 고정비 $F$, 블렌디드 API 단가 $p_{\text{api}}$, 자체 한계 단가 $p_{\text{self}}$ 라면 손익분기 볼륨은 두 비용선이 같아지는 지점이다.

$$F + V^{*} p_{\text{self}} = V^{*} p_{\text{api}} \;\Rightarrow\; V^{*} = \frac{F}{p_{\text{api}} - p_{\text{self}}}$$

숫자를 넣어 개략을 파악하자. 월 고정비 $F = \$40{,}000$(GPU 임대에 MLOps 인력 일부를 상각), 입력·출력을 섞은 블렌디드 API 단가 $p_{\text{api}} = \$6/\text{1M}$, 활용률을 확보한 자체 한계 단가 $p_{\text{self}} = \$0.5/\text{1M}$ 이라 하면

$$V^{*} = \frac{40{,}000}{(6 - 0.5)/10^{6}} = \frac{40{,}000}{5.5 \times 10^{-6}} \approx 7.3 \times 10^{9}\ \text{tok/월}$$

즉 월 약 73억 토큰을 넘겨야 자체 서빙이 API보다 저렴해진다. 이 볼륨이 얼마나 큰지 개략을 파악하려면 앞의 사용자당 원가로 되돌려 보면 된다 — 10턴 대화 하나가 입력·출력 합쳐 대략 27,000 토큰이니, 73억 토큰은 월 27만 회 대화 규모다. 볼륨이 이보다 작으면 고정비 $F$ 를 회수할 트래픽이 없어 API가 압도적으로 저렴하고 빠르다. 스타트업 초기나 프로토타입에서는 GPU를 하루 몇 시간만 쓰고 나머지는 유휴 상태로 두어 활용률이 매우 낮아, 자체 서빙 단가가 API보다 오히려 비용이 커지기까지 한다.

이 식에는 함정이 하나 숨어 있다. 고정비 $F$ 에 GPU 임대료만 넣으면 손익분기를 과소평가한다. 실제 $F$ 는 MLOps 인력, 온콜, 안정화(2.6), 안전·업데이트, 그리고 자체 서빙을 유지하는 엔지니어링 시간을 포함하며, 이것들이 손익분기를 오른쪽으로 크게 민다. "GPU 요금만 계산하면 자체가 싼데"가 바로 그 함정이다. 대부분의 팀에게 초기엔 API가 옳다 — 볼륨이 불확실하고 인력이 부족할 때 자체 서빙의 고정비·활용률 위험이 너무 크다. 볼륨이 크고 예측 가능해지고, 활용률을 확보할 수 있고, 데이터 프라이버시·커스터마이즈·단가가 전략적으로 중요해질 때 자체 서빙으로, 또는 하이브리드 — 대량의 정형 작업만 자체 서빙하고 스파이크성 롱테일은 API — 로 넘어가는 것이 흔한 경로다. 최종 판단은 비용만이 아니라 통제·데이터·인력·속도를 함께 놓는 9.1의 몫이다.

7.5.11 가격 설계 — 무엇을 어떻게 파나

비용을 알았으면 가격을 설계한다. 좋은 가격은 세 가지를 동시에 노린다. 마진을 지키고(원가 폭주를 막고), 가치와 정렬하고(많이 얻는 사용자가 많이 내고), 예측 가능하게(사용자와 회사 모두 청구서를 미리 알 수 있게) 하는 것이다. 이 셋은 자주 상충한다 — 원가에 완전히 연동하면 마진은 안전하지만 사용자가 청구서를 예측하지 못하고, 완전 정액이면 예측은 쉽지만 마진이 무방비다.

토큰당 과금은 개발자 대상 API 플랫폼(7.2)의 표준이다. 원가에 직접 연동되니 마진이 가장 안전하지만, 사용자는 이번 달 청구서가 얼마일지 예측하기 어렵다. 좌석당은 기업 협업 도구에 흔하다. 예측 가능하지만, 한 좌석이 얼마나 쓰는지 상한이 없으면 헤비 유저에 마진이 붕괴한다 — 좌석당에도 좌석별 쿼터가 필요하다. 구독 무제한은 소비자 챗 제품에 매력적이지만 원가에 상한이 없어 마진 리스크가 가장 크다. 7.5.5의 헤비 유저가 정확히 이 모델을 겨눈다. 반드시 소프트 쿼터와 모델 다운시프트를 뒤에 추가해야 한다. 사용량·크레딧은 원가와 잘 정렬되고 마진이 안전하지만, "쓸 때마다 잔액이 줄어든다"는 심리적 마찰이 채택을 낮출 수 있다. 티어와 하이브리드가 실무의 흔한 답이다 — 낮은 티어는 정액에 엄격한 한도, 높은 티어는 넉넉한 한도에 초과분 과금. 예측성과 마진 안전성을 비교 평가하는 절충이다.

어떤 모델을 고를지는 누구에게 파느냐가 정한다. 개발자·API 플랫폼이면 토큰당에 마크업이 자연스럽다 — 원가 연동으로 마진이 안전하다. 소비자 챗 제품이면 티어·구독이되, 상위 티어에도 소프트 쿼터와 다운시프트로 마진을 지키고 "무제한"을 광고할 때는 뒤에 반드시 상한을 둔다. 기업 협업 도구면 좌석당에 좌석별 쿼터를 붙이고, 대량 사용은 초과 과금 하이브리드로 받는다. 어느 경우든 비용 구조가 가격 구조를 규정한다 — 원가가 사용량에 비례하고 상한이 없다는 이 장의 산식이, 왜 순수 정액·무제한이 위험한지를 설명한다.

7.5.12 마진 보호 — 원가 폭주를 막는 장치

정액·무제한 계열은 반드시 원가 상한 장치를 뒤에 추가한다. 이 장치들의 존재 이유가 곧 이 장의 산식이다 — 원가는 사용량에 비례하고 상한이 없다.

비용 상한은 사용자·조직당 월 토큰(또는 원가) 한도다. 초과하면 차단하거나 초과분을 과금한다. 쿼터와 rate limit(7.2)은 분·일 단위 요청·토큰 한도로, 자동화나 봇이 만드는 폭주를 물리적으로 막는다. 모델 다운시프트는 사용자가 한도에 근접하면 저렴한 모델로 자동 강등하는 것으로(라우팅, 5.6), 서비스를 끊지 않으면서 원가를 누른다. 출력·컨텍스트 상한은 요청당 max_tokens와 최대 컨텍스트를 제품 차원에서 제한해, 앞서 본 가장 비용이 큰 축인 출력을 원천에서 제한한다. 사용량 티어라면 잔여 크레딧을 보여 주고 소진 시 업그레이드를 유도하는 UX로 원가와 지불의사를 정렬한다.

이 장치들은 가격 모델과 짝이어야 하고, 무엇보다 투명해야 한다. "무제한"을 광고하면서 뒤에서 조용히 스로틀링하면 신뢰가 깨진다 — 사용자는 자기 요청이 왜 느려지거나 품질이 떨어졌는지 모른 채 배신감만 느낀다. 한도를 명시적으로 공지하고, 초과 시 요청을 끊는 대신 저품질로라도 응답을 이어 가는 우아한 저하(graceful degradation)로 대응하는 것이 원칙이다. 사용자에게 "당신은 한도에 가까워지고 있고, 지금부터는 빠른 소형 모델로 답한다"고 알리는 편이, 아무 설명 없이 느려지는 것보다 낫다.

7.5.13 무료 티어 — 실제 현금이 유출되는 곳

무료 티어는 성장의 수단이지만, LLM에서는 무료 사용자 한 명이 실제 현금 유출이다. SaaS의 무료 티어는 서버 자원이 거의 무비용이라 사실상 마케팅 비용이 0에 가까웠지만, 여기서는 무료 사용자가 보내는 매 요청이 토큰·GPU 비용을 낭비한다. 그래서 무료 티어를 SaaS처럼 무심코 열면 밑 빠진 독이 된다.

남용 벡터는 세 갈래다. 첫째는 자동화·봇·스크래핑이다 — 무료 API 키로 대량 호출해 남의 인프라로 자기 파이프라인을 실행하거나, 모델 출력을 대량 수집해 자기 모델을 증류해(3.9) 간다. 대응은 이메일·전화 인증, IP·디바이스 단위 rate limit, 그리고 이상 사용 탐지(7.6)다. 둘째는 다중 계정(Sybil)이다 — 무료 한도를 계정을 갈아 우회한다. 결제 수단·신원 확인 게이트와 디바이스 핑거프린팅으로 막는다. 셋째는 헤비 무료 유저다 — 소수가 무료 한도 끝까지 써 무료 서빙 원가를 지배한다. 이 셋 모두에 대한 근본 방어는 같다. 무료 티어는 엄격한 저한도에 가장 저렴한 모델(소형 모델·양자화)로만 서빙하고, 고비용 기능 — 추론 모델, 에이전트, 긴 컨텍스트 — 은 유료 전용으로 둔다.

무료 티어의 손익은 결국 "무료 사용자의 유료 전환율 × 전환 후 생애가치 대 무료 서빙 원가"로 판가름 난다. 전환이 약하고 무료 원가가 크면 무료 티어는 순수한 손실이다. 그래서 무료 티어를 열 때는 원가 상한(저한도·저가 모델)을 처음부터 설계에 반영하고, 전환 지표를 함께 계측해(7.6, 8.1) 무료 원가가 전환 가치로 회수되는지를 상시 확인해야 한다.

이 장의 모든 판단의 최종 근거는 자기 워크로드의 측정이다 — 입력 대 출력 비율, 대화 길이 분포, 프리픽스 재사용율, 요청 난이도 분포, 자체 서빙이면 활용률. 산식과 방향은 이 장이 주지만, 구체 단가와 GPU 요금은 시점·벤더에 따라 수시로 바뀌므로 claude-api와 각 벤더 공식 가격표를 출처로 확인해 자기 숫자를 대입해야 한다. 비용을 한 번 계산하고 끝내는 것이 아니라 지속적으로 감시하고 개선하는 운영 순환은 관측성(7.6)과 데이터 플라이휠(8.1)로 이어진다.