27장. 가격 정책과 수익화 포인트

매출은 앞문으로 들어오지만, 원가는 옆문으로 샌다. LLM 서비스에서는 이 말이 특히 더 아프게 맞는다. 일반적인 SaaS는 사용자가 늘어나도 소프트웨어 복제 비용이 거의 0에 가깝다. 반면 LLM 서비스는 요청이 늘어날수록 실제 추론 비용이 함께 올라간다. 사용자가 많이 쓰면 기쁜 동시에 겁도 난다. 축하 메시지와 비용 경고 메일이 같은 날 올 수도 있다.

그래서 LLM 서비스의 가격 정책은 단순히 얼마를 받을지 정하는 일이 아니다. 어떤 사용자는 환영하고, 어떤 사용 패턴은 제어하고, 어디서 이익을 남길지를 설계하는 일에 가깝다. 특히 중요한 점은 하나다. LLM 서비스는 매출보다 먼저 원가 구조를 이해해야 살아남는다. 토큰 비용은 프로덕션 환경에서 가장 큰 변동비가 되기 쉽고, 출력 토큰은 입력 토큰보다 보통 훨씬 비싸다.¹

이 장에서는 토큰 비용 구조를 바탕으로 요금제를 어떻게 짜야 하는지, 사용량 제한은 왜 필요한지, 어떤 업셀링이 건강한지, 그리고 마진을 어떻게 설계해야 하는지 실무 관점에서 차근차근 살펴본다.

가격표보다 먼저 원가표를 보라

처음 LLM 기능을 붙일 때 많은 팀이 이렇게 생각한다. 일단 월 19달러, 49달러, 99달러 플랜을 만들어 두고, 사용자가 늘면 나중에 조정하자. 하지만 이 방식은 아주 위험하다. 왜냐하면 LLM 서비스의 원가는 사용량에 따라 크게 흔들리기 때문이다.

같은 채팅 기능처럼 보여도 실제 비용은 완전히 다를 수 있다. 시스템 프롬프트가 긴지, 검색 문서를 몇 개 붙이는지, 출력 길이를 얼마나 허용하는지, 고급 모델을 얼마나 자주 쓰는지에 따라 요청당 비용이 몇 배에서 몇십 배까지 달라진다. 겉으로는 비슷한 질문 하나인데, 뒤에서는 다른 경제학이 돌아가는 셈이다.

예를 들어 입력 500토큰, 출력 1,500토큰짜리 요청을 고급 모델 가격표에 대입하면 100만 건 처리 비용이 수만 달러 규모가 될 수 있다. 같은 구조라도 더 저렴한 모델이나 하이브리드 라우팅을 쓰면 비용은 큰 폭으로 내려간다.² 이 차이는 단순한 최적화 문제가 아니다. 제품이 남는 사업인지, 바쁠수록 적자 나는 사업인지 가르는 선이다.

즉 가격 정책의 출발점은 경쟁사 가격표가 아니라, 내 서비스의 요청 한 건이 실제로 얼마를 먹는지 계산하는 것이다.

LLM 서비스 원가는 무엇으로 이루어지는가

많은 팀이 원가를 모델 API 호출 비용 하나로만 생각한다. 하지만 실제 청구서를 열어 보면 그보다 조금 더 복잡하다. LLM 서비스의 변동원가는 보통 다음 항목이 합쳐져 만들어진다.³

• 모델 추론 비용: 입력 토큰과 출력 토큰 비용

• 임베딩 비용: 문서 인덱싱과 질의 임베딩 비용

• 검색·저장 비용: 벡터 DB, 파일 저장소, 인덱스 유지 비용

• 실패 비용: 재시도, 타임아웃, 잘못된 라우팅, 과도한 컨텍스트로 인한 낭비

• 운영 부가비용: 관측, 프록시, 큐, 워커, 후처리 파이프라인

여기서 특히 자주 놓치는 것이 두 가지다.

첫째는 출력 비용이다. 많은 서비스가 입력 길이만 줄이려 애쓰지만, 실제 청구서는 장황한 출력에서 더 크게 새는 경우가 많다. 모델은 읽는 것보다 생성하는 데 더 많은 계산을 쓰기 때문에, 출력 단가가 입력보다 3배에서 5배 이상 비싼 경우가 흔하다.¹

둘째는 문맥 낭비다. RAG를 붙였다고 해서 문서를 많이 넣는 것이 좋은 게 아니다. 검색 품질이 낮아 매번 긴 문서 조각을 5개, 7개, 10개씩 넣으면, 정답과 상관없는 문맥까지 모두 비용으로 바뀐다. 이럴 때 청구서는 AI가 똑똑해서가 아니라 검색이 둔해서 커진다.

요청 1건당 원가를 계산하는 법

실무에서 가장 먼저 만들어야 할 숫자는 요청당 원가다. 계산식은 생각보다 단순하다.

요청당 추론 원가 = (입력 토큰 × 입력 단가 + 출력 토큰 × 출력 단가) ÷ 1,000,000

여기에 필요하면 임베딩, 검색, 저장, 후처리 비용을 더하면 된다.

예를 들어 회의록 요약 서비스가 있다고 해 보자. 평균 입력이 3,000토큰이고 출력이 500토큰이라고 하자. 저가형 모델이 입력 100만 토큰당 0.15달러, 출력 100만 토큰당 0.60달러 수준이라면 요청당 추론 원가는 0.00075달러 정도다. 얼핏 거의 공짜처럼 보인다.

그런데 같은 요청을 입력 2.50달러, 출력 10달러 수준의 고급 모델로 전부 돌리면 이야기가 달라진다. 요청당 원가는 약 0.0125달러가 된다. 둘 다 같은 기능처럼 보이지만 비용 차이는 16배가 넘는다. 이 차이는 월 10만 건에서는 75달러와 1,250달러의 차이로, 월 100만 건에서는 훨씬 더 큰 차이로 벌어진다.²

여기서 중요한 교훈은 단순하다. 모델 선택은 품질 결정이면서 동시에 가격 정책 결정이다. 제품팀이 모델을 바꾸는 순간, 재무팀은 사실상 새 요금제를 떠안게 된다.

또 하나 꼭 봐야 할 숫자가 있다. 바로 입력 대비 출력 비율이다. 요약 서비스처럼 긴 입력과 짧은 출력이 나오는 작업은 상대적으로 예측 가능하다. 반면 글쓰기, 상담 답변, 에이전트형 워크플로처럼 출력이 길어지는 작업은 원가가 빠르게 튄다. 그래서 출력 상한, 응답 스타일, 구조화된 응답 형식은 품질 제어 수단이면서 동시에 원가 제어 수단이다.

토큰을 그대로 팔지 말고 고객 가치로 번역하라

사용자는 보통 토큰을 사고 싶어 하지 않는다. 사용자는 회의 정리 시간 절약, 고객지원 처리 속도 향상, 제안서 작성 자동화, 사내 문서 검색 같은 결과를 사고 싶어 한다.

그래서 좋은 가격 정책은 내부적으로는 토큰을 관리하되, 외부적으로는 고객이 이해하는 단위로 번역된다. 예를 들어 다음과 같은 방식이 흔하다.

핵심은 하나다. 토큰은 내부 회계 단위이고, 고객에게 보여 주는 가격 단위는 제품 가치 단위여야 한다.

예를 들어 회의록 서비스라면 월 1,000만 토큰보다 월 200개 회의 업로드가 이해하기 쉽다. 고객지원 코파일럿이라면 월 3,000만 토큰보다 상담사 10명까지 사용 가능이 더 직관적이다. 문서 처리 API라면 반대로 문서당, 페이지당, 요청당 과금이 더 맞을 수 있다.

즉 가격을 정할 때는 토큰 계산기를 바로 고객 앞에 들이밀기보다, 토큰을 고객이 일상적으로 느끼는 작업량으로 번역하는 감각이 필요하다.

사용량 제한은 인색함이 아니라 생존 장치다

LLM 제품에서 사용량 제한은 보기 싫은 장식처럼 느껴질 수 있다. 하지만 실제로는 서비스 생존 장치에 가깝다. 공급자들이 메시지 수, 분당 요청 수, 분당 토큰 수, 티어별 한도를 두는 이유도 결국 같다. GPU는 비싸고, 사용량은 들쑥날쑥하며, 일부 헤비 유저는 구독료보다 훨씬 큰 비용을 만들어 내기 때문이다.⁴

이 논리는 여러분의 제품에도 그대로 적용된다. 월 29달러 플랜에서 사실상 무제한 업로드, 긴 문맥, 대량 배치, 고급 모델, 자동화 실행까지 모두 허용하면 처음에는 사용자가 좋아할지 몰라도, 어느 순간 가장 열심히 쓰는 고객이 가장 손해 보는 고객이 된다. 많이 써서 고마운 고객이 아니라, 많이 써서 적자를 만드는 고객이 되는 것이다.

그래서 실전에서는 사용량 제한을 세 단계로 설계하는 편이 좋다.

• 소프트 제한: 80%, 95% 구간에서 경고하고 사용 현황을 보여 준다

• 하드 제한: 플랜 포함량을 넘으면 추가 구매나 상위 플랜 업그레이드를 요구한다

• 기능 제한: 파일 크기, 컨텍스트 길이, 동시 작업 수, 자동화 실행 수를 플랜별로 나눈다

이때 중요한 것은 제한을 숨기지 않는 것이다. 사용자는 제한 그 자체보다, 갑자기 막히는 경험에 더 크게 화를 낸다. 남은 사용량, 초과 요금, 다음 티어 혜택을 투명하게 보여 주면 제한은 불친절함이 아니라 관리 기능이 된다.

한마디로 말해, LLM 서비스에서 무제한은 가장 비싼 약속이다.

평균 사용자만 보면 반드시 사고가 난다

LLM 서비스 원가를 설계할 때 가장 흔한 실수는 평균만 보는 것이다. 평균적으로 사용자당 월 5달러쯤 나오겠지, 라는 계산은 거의 반드시 틀린다. 이유는 사용량이 스파이크 형태로 튀기 때문이다.

평소에는 조용하던 고객도 어느 날 PDF 5,000개를 한꺼번에 올릴 수 있다. 한 팀이 신규 온보딩을 하면서 전 사내 문서를 인덱싱할 수도 있다. 마케팅 팀이 캠페인 문안을 대량 생성하면서 하루치 예산을 오후 한 시간에 태울 수도 있다. 이런 순간은 평균값 밖에서 발생한다.⁵

그래서 고객별, 워크스페이스별, 기능별 원가 추적이 꼭 필요하다. 최소한 다음 질문에는 바로 답할 수 있어야 한다.

• 어느 고객이 이번 달 비용을 가장 많이 만들었는가

• 어떤 기능이 가장 비싼가

• 어떤 모델 라우팅이 마진을 깎고 있는가

• 어떤 요청 패턴이 비정상적으로 긴 출력이나 과도한 검색 문맥을 만들고 있는가

이 정보를 모르면 가격 정책은 숫자가 아니라 감에 기대게 된다. 감으로 만든 가격은 대체로 바쁠 때 무너진다.

특히 B2B에서는 테넌트 단위 원가 추적이 중요하다. 전체 비용은 흑자인데 특정 대형 고객 하나만 크게 적자일 수 있기 때문이다. 이런 경우는 사용량 상한, 별도 계약, 전용 크레딧 풀, 배치 전용 플랜으로 분리해야 한다. 그렇지 않으면 좋은 고객을 많이 유치할수록 손해가 커지는 이상한 사업이 된다.

업셀링 포인트는 더 많은 토큰이 아니라 더 큰 결과여야 한다

업셀링을 설계할 때도 함정이 있다. 가장 쉬운 업셀은 고급 모델을 더 많이 쓰게 만드는 것이다. 하지만 이것은 종종 매출과 함께 원가도 같이 올린다. 매출은 늘었는데 마진은 별로 좋아지지 않는 업셀이다.

더 건강한 업셀은 고객에게 더 큰 결과를 주되, 원가 증가는 상대적으로 작거나 통제 가능한 항목에서 나온다. 예를 들어 다음과 같은 업셀 포인트는 실무에서 자주 잘 작동한다.

• 더 큰 파일 크기와 더 긴 문맥 처리

• 팀 협업 기능, 템플릿, 히스토리, 공유 워크스페이스

• 외부 시스템 연동과 승인 워크플로

• 배치 처리, 예약 실행, 대량 업로드

• 감사 로그, 권한 관리, SSO, SLA 같은 운영 기능

• 고급 모델 보장, 빠른 응답 우선순위, 높은 한도

이 중에서 원가 구조를 보면 차이가 있다. 고급 모델 보장은 변동원가를 크게 올릴 수 있다. 반면 협업, 승인 흐름, 감사 로그, 템플릿, 관리자 기능은 제품 가치 대비 추가 추론비가 크지 않은 경우가 많다. 즉 후자는 대체로 더 건강한 고마진 업셀이다.

그래서 업셀링을 설계할 때는 이런 질문을 함께 던져야 한다. 이 기능은 고객이 더 큰 문제를 풀게 만드는가, 아니면 단순히 더 비싼 모델을 더 오래 태우게 만드는가. 전자는 제품 가치고, 후자는 원가 확대일 때가 많다.

마진은 어떻게 설계해야 하는가

이제 가장 중요한 질문으로 가 보자. 얼마를 받아야 남는가.

여기서 좋은 출발점은 목표 원가율을 먼저 정하는 것이다. 예를 들어 어떤 플랜에서 월 변동원가를 매출의 25% 안에 묶고 싶다고 해 보자. 그렇다면 계산은 간단하다.

필요 월요금 = 예상 월변동원가 ÷ 허용 원가율

예상 월변동원가가 계정당 8달러이고 허용 원가율이 25%라면, 최소 월요금은 32달러가 되어야 한다. 여기에 고정비 회수, 세일즈 비용, 환불, 할인, 예비 버퍼까지 생각하면 실제 가격은 그보다 더 올라갈 수 있다.

이때 월변동원가는 반드시 평균 한 줄로 끝내면 안 된다. 최소한 p50 사용자, p95 사용자, 최악의 남용 시나리오를 따로 봐야 한다. p50만 보고 가격을 정하면 p95가 마진을 다 먹는다. 특히 LLM 서비스에서는 이 문제가 자주 벌어진다.

실무적으로는 다음 순서가 유용하다.

첫째, 요청 유형을 나눈다. 요약, 검색, 채팅, 자동화 실행, 문서 인덱싱은 원가 구조가 다르다.

둘째, 각 유형의 입력 토큰, 출력 토큰, 검색 청크 수, 평균 재시도율을 측정한다.

셋째, 고객 세그먼트별 사용 패턴을 나눈다. 라이트 유저와 헤비 유저를 한 평균으로 섞지 않는다.

넷째, 플랜마다 허용 모델과 기능 범위를 다르게 둔다. 가장 싼 플랜이 가장 비싼 기능을 마음껏 쓰게 해서는 안 된다.

다섯째, 월말 청구서를 보기 전에 일간 손익을 본다. LLM 비용은 월말에 놀라기엔 너무 빠르게 커진다.

여기서 큰 도움이 되는 것이 라우팅 전략이다. 실제로 많은 팀이 80~95%의 일반 요청은 저가 모델에 보내고, 복잡하거나 위험한 일부만 상위 모델로 승격시키는 방식을 쓴다. 이런 구조는 전체 품질을 크게 해치지 않으면서도 비용을 60~80% 수준까지 줄이는 데 도움이 된다.⁶

이 말은 곧, 좋은 가격 정책은 영업팀만의 일이 아니라 모델 라우팅과 제품 설계까지 포함한 시스템 설계라는 뜻이다.

비용을 줄이는 기능이 곧 가격 경쟁력이 된다

마진 설계를 이야기할 때 종종 잊는 사실이 하나 있다. 비용 최적화는 재무팀의 뒷정리가 아니라 제품 경쟁력 그 자체라는 점이다.

예를 들어 비실시간 작업을 배치 처리로 돌릴 수 있다면 실시간 API보다 더 낮은 비용 구조를 만들 수 있다. 반복되는 긴 시스템 프롬프트를 캐시할 수 있다면 같은 품질을 더 싸게 제공할 수 있다. 검색 청크 수를 5개에서 3개로 줄여도 품질이 유지된다면, 그것은 단순한 엔지니어링 최적화가 아니라 가격 인하 여력을 만드는 일이다. 실제로 배치 API는 실시간 대비 큰 할인 폭을 제공하는 경우가 많고, 프롬프트 캐싱은 반복되는 입력 구간의 비용을 크게 낮출 수 있다.⁷

이런 최적화가 중요한 이유는 단순하다. 원가가 낮아지면 세 가지 선택지가 생긴다.

• 같은 가격을 유지하고 마진을 높일 수 있다

• 가격을 낮춰 경쟁력을 확보할 수 있다

• 더 좋은 모델을 일부 구간에만 써서 체감 품질을 높일 수 있다

즉 비용 최적화는 허리띠 졸라매기가 아니라, 가격 전략의 선택권을 사는 일이다.

실전용 요금제 뼈대는 이렇게 잡는 편이 안전하다

초기 LLM SaaS라면 대개 다음 같은 구조가 비교적 안전하다.

무료 플랜은 체험용으로 둔다. 결과 품질을 보여 주되, 긴 문맥, 대량 업로드, 자동화 실행은 막는다. 여기서는 전환이 목적이지 수익이 목적이 아니다.

프로 플랜은 개인이나 소규모 팀의 반복 사용 구간이다. 월정액에 적당한 포함량을 넣고, 초과 사용은 제한하거나 소액 크레딧으로 처리한다. 여기서는 가격 이해도와 체감 가치가 중요하다.

팀 플랜은 좌석 + 공유 사용량 구조가 잘 맞는다. 개인별 잔량보다 팀 전체의 생산성을 사는 경우가 많기 때문이다. 이 구간부터 템플릿, 공유 폴더, 히스토리, 관리자 기능, 감사 로그가 강한 업셀 포인트가 된다.

엔터프라이즈는 사실상 별도 상품이다. 여기서는 토큰 가격보다 보안, 한도, SLA, 데이터 정책, 전용 라우팅, 지원 체계가 더 중요하다. 종종 커밋 금액과 사용량 상한을 함께 묶는 방식이 안정적이다.

핵심은 모든 플랜을 같은 모델, 같은 한도, 같은 기능으로 넓게 열어 두지 않는 것이다. 플랜 차이는 단순히 숫자 차이가 아니라 원가 구조 차이가 되어야 한다.

돈 되는 가격 정책의 감각

마지막으로 감각적인 원칙 몇 가지를 정리해 보자.

첫째, 가격은 경쟁사보다 조금 싸게 정하는 게임이 아니다. 내 원가 구조를 견딜 수 있는가가 먼저다.

둘째, 토큰은 내부 계산의 기준이지 외부 가치의 언어가 아니다. 고객은 작업 완료, 시간 절약, 위험 감소에 돈을 낸다.

셋째, 무제한은 거의 언제나 위험하다. 특히 긴 문맥, 대량 파일, 자동화 실행, 고급 모델을 함께 묶은 무제한은 더 위험하다.

넷째, 좋은 업셀은 더 많은 토큰 소비가 아니라 더 큰 업무 결과와 더 강한 운영 통제를 판다.

다섯째, 마진은 가격표가 아니라 라우팅, 출력 길이, 검색 품질, 캐싱, 배치 처리에서 결정된다.

결국 LLM 서비스의 가격 정책은 한 줄로 요약할 수 있다.

고객에게는 결과 단위로 팔고, 내부적으로는 토큰 단위로 통제하라.

이 원칙이 잡히면 요금제도 덜 흔들리고, 업셀링도 덜 무리해지며, 무엇보다 바쁠수록 더 건강한 사업이 된다. 반대로 이 원칙이 없으면 사용자가 늘수록 서버는 분주해지고, 팀은 기뻐해야 할 성장 곡선을 보며 식은땀을 흘리게 된다.

LLM 서비스는 멋진 데모만으로는 오래 못 간다. 결국 살아남는 팀은 모델을 잘 부르는 팀이 아니라, 원가를 이해한 상태에서 제품과 가격을 함께 설계한 팀이다.

참고

¹LLM Token Pricing Comparison 2026와 핵심 비용 원리 정리

²LLM API Pricing Comparison Table 2026

³LLM 비용의 숨은 항목과 실제 계산 요소 설명

⁴Why LLM Providers Are Capping Usage

⁵Why AI Agencies are flying blind and how to fix your LLM margins

⁶LLM API Pricing Comparison 2026 Complete Guide for SaaS Developers

⁷Batch 할인과 프롬프트 캐싱이 비용에 미치는 영향