AI 글쓰기 도우미를 운영하는 한 창업자가 자신의 "소프트웨어 비용"이 월 $40,000라고 말한 적이 있다. 이 수치를 뜯어보니 그중 $34,000은 OpenAI와 Anthropic의 API 요금이었고, 이 금액은 그의 매출원가(COGS)에는 전혀 포함되어 있지 않았다. 이 비용은 월 $19짜리 프로젝트 관리 도구 바로 옆에서 일반적인 "소프트웨어 및 구독" 항목에 잡혀 있었다. 그가 보고한 매출총이익률은 91%였다. 하지만 추론 비용을 제자리로 옮기고 나자 실제 매출총이익률은 58%였다.
이는 단순한 회계상의 기술적 문제가 아니다. 소프트웨어처럼 보이는 사업과 공장처럼 작동하는 사업의 차이다 — 후자는 판매되는 모든 단위가 실질적이고 변동하는 투입물을 소비한다. GPT-5, Claude, Gemini 또는 그 어떤 호스팅형 모델 위에 제품을 구축하고 있다면, LLM 요금은 간접비가 아니다. 그것은 매출원가이며, 이를 다르게 취급한다는 것은 실제로 얼마를 벌고 있는지 모른다는 뜻이다.
이 실수가 이렇게 쉽게 일어나는 이유
전통적인 SaaS는 한 세대의 창업자들에게 소프트웨어 비용을 고정비로 생각하도록 훈련시켰다. 호스팅 비용을 내고, CRM 비용을 내고, Slack 비용을 낸다 — 그리고 이 요금들 중 어느 것도 한 고객이 제품을 얼마나 사용하는지에 따라 함께 움직이지 않는다. 그래서 OpenAI로부터 첫 API 청구서가 도착하면, 이를 같은 심리적 범주 — "사업을 운영하기 위해 지불하는 도구들" — 에 분류하는 것이 자연스럽게 느껴진다.
문제는 LLM API 요금이 SaaS 구독처럼 작동하지 않는다는 점이다. 그것은 원자재처럼 작동한다. 고객이 프롬프트를 보낼 때마다 토큰을 소비하고, 모든 토큰에는 가격이 매겨져 있다. 하루에 50번 요청하는 고객을 응대하는 데는 하루에 2번 요청하는 고객보다 의미 있게 더 많은 비용이 든다. 이것이 매출원가의 교과서적 정의다: 사용량과 무관하게 그저 사업을 유지하기 위해 지불하는 비용과 달리, 특정 고객에게 제품을 전달하는 것과 직접적으로 비례해 늘어나는 비용이다.
업계 데이터는 이 문제가 얼마나 중대해졌는지를 뒷받침한다. ICONIQ의 2026년 1월 State of AI 보고서에 따르면, 스케일링 단계의 AI B2B 기업에서 추론 비용은 현재 평균적으로 총매출의 23%를 차지하며, 이들 기업의 84%는 AI 인프라 비용으로 직접 귀결되는 6퍼센트포인트 이상의 매출총이익률 잠식을 보고했다. 이는 "기타 운영비"에 흡수해버릴 수 있는 반올림 오차 수준이 아니다. 이는 흔히 사업에서 가장 큰 단일 비용 요인이며, 그에 걸맞게 취급되어야 한다.
COGS와 OpEx의 경계를 올바르게 긋기
COGS와 운영비를 구분하는 규칙은 투입물이 창고 가득한 부품이 아니라 모델 API라고 해서 달라지지 않는다: 유료 고객에게 제품을 전달하는 데 드는 비용은 COGS에 속하고, 제품을 만드는 데 드는 비용은 OpEx 아래의 R&D에 속한다. 이를 AI 래퍼에 적용하면 다음과 같이 나뉜다:
COGS에 속하는 것:
- 프로덕션 추론 비용 — 채팅 완성, 임베딩 호출, 분류 작업, 에이전트 툴콜 루프 등 라이브 제품이 유료 고객을 대신해 수행하는 모든 API 호출
- 모델 호스팅 / GPU 컴퓨팅 — 호스팅형 API를 호출하는 대신 자체 또는 임대 인프라에서 오픈 웨이트 모델을 구동하는 경우, 고객 요청을 처리하는 데 귀속되는 컴퓨팅 시간
- 추론을 지원하는 인프라 — 프로덕션 요청을 처리하기 위해 존재하는 벡터 데이터베이스 쿼리, 임베딩 파이프라인 실행, 오케스트레이션 오버헤드
- AI 특화 지원 비용 — 고객을 위해 모델 출력 문제를 분류·해결하는 것이 업무인 지원 엔지니어의 비용은 일반 SG&A 비용이 아니라 제품 전달 비용이다
OpEx(대개 R&D)에 속하는 것:
- 개발 및 테스트 추론 — 엔지니어가 기능을 반복 개발하거나, 회귀 버그를 디버깅하거나, 새 모델 버전을 평가하면서 보내는 모든 프롬프트
- 파인튜닝 및 평가 실행 — 모델을 만들거나 개선하는 것은 전달이 아니라 R&D다
- 내부 AI 도구 — 팀의 ChatGPT Enterprise 시트나 GitHub Copilot 라이선스는 고객 응대 비용이 아니라 생산성 비용이다
이러한 구분을 가능하게 하는 실무적 조치는 단순하지만 필수적이다: 첫날부터 프로덕션과 개발 트래픽에 별도의 API 키 또는 청구 프로젝트를 사용하라. 엔지니어들이 제품이 프로덕션에서 사용하는 것과 동일한 키로 프롬프트를 테스트하고 있다면, 나중에 청구서를 정확히 배분할 방법이 없고, 매달 실제 마진을 과대평가하거나 과소평가하게 될 것이다.
AI 제품의 "진짜" 매출총이익률은 어떤 모습인가
이러한 구분을 마치고 나면, 결과로 나오는 수치가 익숙한 것과는 다르게 보일 것을 예상해야 한다. 전통적인 SaaS 기업들은 거의 당연하다는 듯 70–80%의 매출총이익률을 목표로 삼는다. AI 네이티브 제품은 같은 방식으로 그 수준에 도달하지 못한다. Bessemer Venture Partners의 2026년 2월 가격 책정 플레이북은 일반적인 AI 제품의 매출총이익률을 50–60%로 제시하는데, 이는 전통적 SaaS의 80–90% 범위보다 훨씬 낮다. ICONIQ의 데이터는 업계 평균 AI 제품 매출총이익률이 상승하고 있음을 보여주지만, 2024년 41%, 2025년 45%에서 2026년 52%로 오르는 데 그쳤다.
이를 면밀히 관리해온 운영자들 사이에서 나온 유용한 경험칙이 있다: 지속 가능하고 확장 가능한 비즈니스 모델을 원한다면 LLM 비용을 전체 COGS의 대략 20% 미만으로 유지하라. 이 임계값을 넘으면, 마진 압박은 성장할수록 완화되기는커녕 오히려 가속화되는 경향이 있는데, 이는 더 큰 고객일수록 제품을 덜 쓰는 게 아니라 더 많이 쓰기 때문이다. 코딩 어시스턴트나 문서 처리 에이전트 같은 일부 AI 집약적 카테고리는 LLM 비용 비율이 COGS의 30–40%에 달하면서도 여전히 유지 가능한데, 이는 그 현실을 어쩌다 떠안은 것이 아니라 의도적으로 그에 맞춰 가격을 책정했기 때문일 뿐이다.
실제로 중요한 수치는 회사 전체를 평균한 매출총이익률이 아니라 고객당 비용이다. AI 기능을 많이 쓰는 고객은 동일한 구독 등급의 가벼운 사용자보다 원시 추론 비용만으로 50배에서 100배 더 많은 비용이 들 수 있다. 이를 추적하지 않는다면, 어느 고객이 수익성이 있고 어느 고객을 매달 조용히 보조해주고 있는지 알 수 없다. 처음 열 명의 고객에게는 문제없어 보이던 정액제 요금제도, 그중 한 명이 워크플로를 프로덕션에 투입해 요청량을 20배로 늘리는 순간 손실을 내기 시작할 수 있다.
요청당 비용 모델 구축하기
시작하는 데 정교한 도구가 필요한 것은 아니다 — 모든 요청에서 올바른 수치를 기록하는 규율이 필요할 뿐이다. 핵심 공식은 간단하다:
request_cost = (input_tokens / 1,000,000) × input_price_per_million
+ (output_tokens / 1,000,000) × output_price_per_million출력 토큰은 단위당 입력 토큰보다 보통 2–5배 더 비싼데, 이는 생성이 프롬프트를 읽는 것보다 컴퓨팅 집약적이기 때문이다 — 그래서 입력과 출력을 분리하지 않고 총 토큰만 추적하는 요청 비용 모델은 긴 완성문이 있는 요청의 가격을 체계적으로 잘못 책정하게 된다. 2026년 중반 가격을 기준으로 한 작동 예시를 보자: 입력 토큰 2,000개와 500토큰 분량의 답변으로 구성된 요청을 주류 중간급 모델(대략 백만 토큰당 입력 $3 / 출력 $15)에 보내면 비용은 약 $0.0135다. 같은 형태의 요청을 한 달에 50,000번 실행하면 이 단일 기능 하나만으로 약 $675의 추론 비용이 발생하는데, 이는 다섯 자리 숫자의 "클라우드 비용" 항목에 묻혀 있으면 보이지 않지만, 그 비용을 발생시킨 기능과 고객 세그먼트에 태깅하는 순간 매우 뚜렷하게 드러난다.
이를 실행 가능하게 만들려면:
- 비용뿐 아니라 모든 요청의 토큰 수를 기록하라 — 대부분의 모델 제공업체는 API 응답 자체에 입력/출력 토큰 수를 반환하므로, 이는 새로운 데이터 소스가 아니라 로깅 방식의 변경일 뿐이다.
- 각 요청에 고객 ID와 기능 식별자를 태깅하라. 그러면 월별뿐 아니라 계정별, 제품 영역별로 비용을 집계할 수 있다.
- 청구 기간별 고객당 비용을 계산하고 그 고객이 지불하는 금액과 비교하라. 이 수치가 바로 가격 등급이 평균 마진이 아니라 실제 전달 비용과 맞는지를 말해준다.
- 품질이 허용하는 경우 더 저렴한 모델로 라우팅하라. 모든 요청이 가장 성능이 뛰어난(그리고 가장 비싼) 모델을 필요로 하는 것은 아니다 — 분류, 추출, 단순 포맷팅 작업은 흔히 더 작고 저렴한 모델로도 충분한 성능을 낸다. 모델 라우팅은 공급업체 가격과 달리 여러분이 온전히 통제할 수 있는 몇 안 되는 마진 지렛대 중 하나다.
방금 찾아낸 마진을 지키는 가격 책정
추론이 COGS로 올바르게 분류되고 나면, 가격에 관한 논의 자체가 달라진다. 운영자들이 흔히 사용하는 기준점은 단위 토큰 비용의 대략 3–5배를 청구하는 것으로, $0.30짜리 작업을 $1.00 이상으로 책정하는 식이다 — 이 배수가 마법 같은 숫자여서가 아니라, 사용량 변동, 모델 가격 변동성, 그리고 원시 추론에 딸려오는 지원 및 인프라 비용을 흡수할 여지를 남겨주기 때문이다.
사용량 기반 과금은 AI 기업들이 가격과 COGS를 함께 움직이게 만드는 표준적인 방식이 되었다: 토큰당, 요청당, 또는 완료된 작업당 과금하면, 매출은 사용량이 급증할 때 정액 구독이 그렇듯 비용과 따로 노는 대신 비용을 유발하는 것과 동일한 변수에 맞춰 확장된다. 완전한 사용량 기반 가격 책정으로 전환할 준비가 아직 안 되어 있다면, 최소한 최소 약정에 초과분을 더하는 요금제 구조를 만들어, 일반적인 사용량을 훌쩍 넘어선 고객이 그달 남은 기간 조용히 손실 유발 고객이 되지 않도록 하라.
코드만큼 감사 가능한 비용 구조를 유지하라
이것은 선택적인 회계상의 위생 관리가 아니다 — 비즈니스 모델이 작동한다는 것을 아는 것과, 투자자 측 심사역이 여러분이 6개월 전에 만들었어야 할 고객별 비용 모델을 실사 통화 중에 대신 만들어내면서 작동하지 않는다는 사실을 뒤늦게 알게 되는 것 사이의 차이다. 그런 대화를 피하는 창업자는 OpenAI 청구서가 도저히 무시할 수 없을 만큼 커질 때까지 기다리는 사람이 아니라, 첫 API 호출부터 추론 비용을 고객과 기능에 태깅해온 사람이다.
Beancount.io는 평문 텍스트 기반의 버전 관리되는 회계 시스템을 제공하여, 추론 지출을 올바른 계정에 태깅하고, 프로덕션과 개발 API 사용량을 분리하며, 매달 실제 COGS를 매출과 대조하는 작업을 간단하게 만들어준다 — 블랙박스식 분류도, 벤더 종속도 없다. 무료로 시작하기를 통해 왜 개발자와 AI 네이티브 창업자들이 평문 텍스트 회계로 전환하고 있는지 확인해보라.