만들기 전에 AI 기능의 비용을 추정하는 방법

방어 가능한 추정치란 실제로 어떤 모습인가

"이 AI 기능, 비용이 얼마나 들까요?"라는 질문에는 보통 어깨를 으쓱하거나 그냥 대충 던진 숫자로 답하기 마련이다. 둘 다 첫 청구서 앞에서 무너진다. 여기서의 목표는 그 어깨 으쓱을, 재무 담당자가 받아들일 만한 한 문장으로 바꾸는 것이다. "예상 트래픽에서 월 약 $1,500 정도이고, 현실적인 하한은 $1,050 근처, 상한은 $2,100 정도이며, 가장 큰 레버는 출력 길이입니다." 이건 범위와 단위 비용, 그리고 이름이 붙은 레버다 — 거짓 정밀함이 아니다.

이 한 문장은 하루 오후면 만들어낼 수 있다. 달러로 생각하기를 멈추고 토큰으로 생각하기 시작하는 순간, 작업은 기계적이 된다. 모든 API 요금은 두 개의 토큰 수에 각각의 토큰당 단가를 곱한 뒤, 요청 볼륨만큼 합산하고, 거기에 캐싱·배치, 그리고 청구서에 찍히기 전까지는 아무도 기억하지 못하는 오버헤드를 반영한 것이다.

글 전체에서 하나의 구체적인 예시를 처음부터 끝까지 끌고 간다: 월 300,000건의 요청을 처리하는 고객 지원 어시스턴트를 Claude Haiku 4.5 기준으로 평가한다. 숫자는 실제 값(2026-05-27 검증)이고 계산 과정도 전부 보여주므로, 여러분의 버킷으로 바꿔 넣고 그대로 다시 돌려볼 수 있다.

1단계 — 하나의 요청을 네 개의 토큰 버킷으로 쪼개기

LLM 호출 한 번은 하나의 텍스트 덩어리가 아니다. 비용 측면에서, 그리고 나중에 당길 수 있는 레버 측면에서 매우 다르게 동작하는 네 개의 별도 버킷이다. 각각을 글자 수나 단어 수가 아니라 토큰 단위로 추정하라. 우리가 돈을 내는 대상이 바로 토큰이기 때문이다.

이 수치들을 추측하지 말고 측정하라. 대표적인 시스템 프롬프트와 실제 검색된 컨텍스트를 AI 토큰 카운터에 붙여넣고 실제 숫자를 확인하라. 추측은 추정 오차의 가장 큰 단일 원인이며, 수백만 건의 호출에 걸쳐 복리처럼 불어난다. 다만 한 가지 주의점: 토크나이저는 모델마다 다르다. Claude는 영어를 GPT 토큰 수의 약 0.8배로 인코딩하므로, 한 모델 기준으로 측정한 프롬프트는 다른 모델에서는 근사치일 뿐이다 — 이유는 토큰 카운팅에 대한 오해를 참고하라.

지원 어시스턴트 예시에서는 요청당 다음 버킷을 사용한다: 시스템 프롬프트 + 툴 스키마 1,500 토큰, 검색된 지식 베이스 청크 2,500 토큰, 사용자 메시지 200 토큰, 생성된 답변 350 토큰.

• 시스템 프롬프트 + 툴 스키마 — 지시문, 페르소나, 포맷 규칙, 그리고 노출하는 모든 툴의 JSON 스키마. 매 호출마다 전송되며 으레 과소평가된다. 장황한 툴 정의 몇 개만으로도 요청당 입력 토큰이 1,000~2,000개씩 조용히 늘어날 수 있다.
• 검색 / 컨텍스트 토큰 — RAG 청크, 대화 이력, 붙여넣은 문서. 검색 기반 기능에서는 보통 가장 크고 변동이 심한 입력 버킷이다.
• 사용자 입력 — 실제 질문이나 메시지. 작고 변동적이다.
• 예상 출력 — 모델이 생성하는 분량. 가장 정확히 잡아야 하는 숫자다. 출력은 입력보다 5~6배 비싸게 책정되기 때문이다.

2단계 — 볼륨을 곱하되, 입력과 출력은 따로 떼어 두기

볼륨은 요청당 토큰 수를 월 단위 숫자로 바꿔주는 곱셈 계수다. 월 요청 수는 실제 신호에서 추정하라: 현재 티켓 볼륨, 일일 활성 사용자 수 × 세션 수, 또는 기존의 유사한 엔드포인트에서 가져온 API 호출 수. 정말로 아무 신호도 없다면 점 추정치를 지어내지 말고 범위로 묶어라 — 낮은 볼륨과 높은 볼륨을 함께 들고 가라.

타협 불가능한 규칙: 입력 토큰과 출력 토큰을 두 개의 별도 스트림으로 모델링하라. 둘은 단가가 다르고(2026년 모든 모델에서 출력은 입력의 5~6배), 반응하는 레버도 다르다. 뭉뚱그린 단가는 어느 버킷이 지배적인지를 가려버리고, 결국 엉뚱한 곳을 최적화하게 만든다.

월 300,000건 요청의 지원 어시스턴트: 요청당 입력은 1,500 + 2,500 + 200 = 4,200 토큰, 출력은 350 토큰이다. 한 달 동안 이는 4,200 × 300,000 = 1,260M 입력 토큰, 350 × 300,000 = 105M 출력 토큰이다. 입력 스트림이 토큰 볼륨으로는 12배나 크다는 점에 주목하라 — 그런데 다음 단계에서 보듯, 단가가 다르기 때문에 입력이 비용을 자동으로 지배하지는 않는다.

3단계 — 실제 2026년 모델의 단가를 적용하기 (베이스라인)

이제 후보 모델과 그 실제 토큰당 단가를 붙인다. 표에서 가장 싼 모델이 아니라, 여러분의 데이터에서 품질 기준을 통과하는 모델을 고르라 — 그런 다음 더 저렴한 등급도 그 기준을 통과하는지 별도로 확인하라. Haiku 4.5는 트래픽이 많은 지원 어시스턴트의 방어 가능한 기본값이다: 입력 100만 토큰당 $1.00 / 출력 100만 토큰당 $5.00로, 프런티어 가격보다 훨씬 낮으면서도 근거 기반의 툴 사용 지원 답변을 잘 처리한다. 이 등급의 품질이 여러분 데이터에서 애매하다면, 같은 계산이 Sonnet 4.6($3.00/$15.00)에도 그대로 적용된다. 추정하되, 가정하지 마라.

우선 각 스트림을 표준(비캐시·비배치) 단가로 계산하라 — 이것이 어떤 최적화도 적용하기 전의 정직한 베이스라인이다.

• 입력: 1,260M ÷ 1M × $1.00 = $1,260
• 출력: 105M ÷ 1M × $5.00 = $525
• 베이스라인 월 합계: $1,785

베이스라인을 꼼꼼히 들여다보기

이 $1,785 베이스라인은 가격표가 알려주지 못하는 것을 벌써 가르쳐준다. 출력은 토큰 볼륨의 8%에 불과하지만 비용의 29%($1,785 중 $525)를 차지한다. 그리고 입력 스트림 안에서, 1,500 토큰짜리 시스템+툴 프리픽스는 매 호출마다 동일하다 — 이것만으로 1,500 × 300,000 = 450M 토큰, 즉 월 $450가 똑같은 바이트에 대해 반복해서 지불된다. 이 반복되는 프리픽스가 가장 명백한 첫 번째 타깃이며, 프롬프트 캐싱이 정확히 노리는 지점이다.

최적화에 들어가기 전에, 베이스라인을 "자릿수가 틀렸다" 냄새 테스트로 점검하라. 이 워크로드의 봉투 뒷면 계산이 $50나 $50,000으로 나왔다면, 토큰 수나 볼륨이 10배 어긋났음을 알 수 있다. 근거 기반 지원 답변 30만 건에 $1,785은 그럴듯하다 — 레버를 당기기 전 기준으로 요청당 약 0.6센트다. 이제 이걸 끌어내리자.

4단계 — 두 개의 큰 레버를 순서대로 당기기

실제로 돈을 움직이는 레버는 두 개다: 먼저 프롬프트 캐싱, 그다음 워크로드가 비동기를 견딜 수 있는 경우의 Batch API. 이 순서로 적용하는 이유는, 캐싱은 거의 항상 쓸 수 있는 반면 배치는 실시간 응답이 필요 없을 때만 쓸 수 있기 때문이다.

프롬프트 캐싱은 재사용되는 프리픽스를 노린다. Anthropic 캐싱은 일회성 쓰기 프리미엄(Haiku: 쓰기 100만 토큰당 $1.25)을 부과한 뒤, 캐시된 읽기는 100만 토큰당 $0.10에 제공한다 — 표준 입력 단가 $1.00 대비 10배 할인, 즉 캐시 가능한 부분에 대해 약 90% 절감이다. OpenAI와 Gemini는 쓰기 수수료 없이 캐시 읽기를 자동으로 적용한다. 메커니즘은 다르지만 원리는 동일하다(프롬프트 캐싱 ROI 참고). 지원 어시스턴트에서는 1,500 토큰짜리 시스템+툴 프리픽스를 캐시하고, 변동 버킷은 표준 단가로 둔다.

캐싱은 베이스라인을 $1,785에서 $1,380으로 — 월 약 $405, 즉 23% 떨어뜨리며, 이 절감의 거의 전부가 반복 프리픽스에서 나온다. 캐시 쓰기 요금과 TTL 갱신은 약간의 오버헤드를 더하는데, 이 정도 트래픽에서는 수십 달러 규모다. 이를 0이라고 가장하지 않고 5단계의 버퍼에 녹여 넣는다.

Batch API는 최대 약 24시간의 지연을 견딜 수 있는 작업에 대해 입력과 출력 모두 50% 할인을 준다(Batch API가 동작하는 방식 참고). 실시간 지원 어시스턴트는 동기적이므로 배치가 적용되지 않는다 — 정직한 추정이라면 그렇게 말한다. 하지만 이 기능의 배치 적용 가능한 사촌격 작업(야간 티켓 요약, 태그 백필, 평가 실행)은 배치 단가로 책정해야 한다: 동일한 30만 건 요청 형태를 전부 배치로 돌리면 1,260M × $0.50 + 105M × $2.50 = $892.50, 정확히 베이스라인의 절반이다.

• 캐시된 프리픽스: 1,500 × 300,000 = 450M ÷ 1M × $0.10 = $45 ($450에서 감소)
• 변동 입력 (2,500 + 200 = 2,700 토큰): 810M ÷ 1M × $1.00 = $810
• 출력 (변동 없음, 실시간): $525
• 캐시 적용 실시간 합계: $1,380

5단계 — 사람들이 빼먹는 버퍼 더하기

최적화된 $1,380도 여전히 과소 추정이다. 운영 환경에는 깔끔한 스프레드시트가 생략하는 오버헤드가 있기 때문이다. 숫자가 슬그머니 낮아지지 않도록 이를 명시적으로 더하라.

예상 케이스에는 재시도용으로 약 3%, 캐시 쓰기 오버헤드와 TTL 변동용으로 약 $80를 $1,380 위에 더하는데, 이는 반올림하면 대략 월 $1,500으로 계획 숫자가 된다. 스파이크 마진은 예상 케이스가 아니라 범위의 상한에 들어간다 — 일상적인 숫자를 부풀리고 싶지는 않지만, 상한이 나쁜 한 달을 흡수해주기를 바라는 것이다.

• 매 호출의 시스템 + 툴 스키마 토큰 — 여기서는 이미 1번 버킷에 넣었으니 계산에 포함되어 있지만, 이것이 가장 흔한 누락이다. "사용자의 질문과 답변"만으로 가격을 매겼다면 프리픽스 전체만큼 입력을 적게 잡은 것이다. 여러분의 계산에 들어가 있는지 다시 확인하라.
• 재시도와 실패 — 타임아웃, 5xx, 툴 호출 재실행은 토큰을 다시 소비한다. 건강한 통합이라면 2~3%의 재시도율이 일반적이니 예산에 반영하라. 불안정한 툴은 이 수치를 훨씬 높일 수 있으니 모니터링에서 주시하라.
• 스파이크 마진 — 트래픽은 들쭉날쭉하다. 출시, 언론 노출, 또는 월요일 아침 지원 폭주는 하루를 평균의 2~3배로 밀어 올릴 수 있다. 15~30%의 스파이크 마진을 들고 가야 바쁜 한 달이 예측을 무너뜨리지 않는다.

6단계 — 범위, 단위 비용, 그리고 의사결정으로 전환하기

단일 숫자는 거짓 확신을 부른다. 추정치를 하한 / 예상 / 상한으로 표현하고, 진행 여부(go/no-go)를 명확하게 만드는 요청당 단위 비용을 도출하라. 범위는 임의의 ±퍼센트가 아니라 정직한 시나리오 변동에서 만들어라: 하한은 더 짧은 답변, 더 적은 검색 청크, 따뜻한 캐시를 가정하고, 상한은 더 긴 출력(약 450 토큰), 더 많은 컨텍스트, 높아진 재시도, 그리고 스파이크 마진의 발동을 가정한다.

의사결정을 방어 가능하게 만드는 것은 단위 비용이다. 해결된 지원 상호작용 한 건당 반 센트는 사람이 응대하는 비용에 비해 압도적으로 낮으므로, 이는 명백한 go다. 단위 비용이 그것이 수행하는 행위의 가치에 근접하기라도 한다면, 월 총액과 무관하게 no-go 신호다.

마지막으로, 가장 먼저 최적화할 단 하나의 가장 큰 레버에 이름을 붙여라 — 여기서는 출력 비용(최적화된 합계 중 $525, 캐싱이 건드리지 못한 부분)이다. 이는 출력 토큰 줄이기(더 빡빡한 응답 포맷, max-token 상한, 구조화된 출력)를 추가 입력 튜닝보다 우선되는, 가장 레버리지가 큰 다음 수로 가리킨다. 만약 여러분의 기능이 그 대신 검색 위주라면, 레버는 컨텍스트 크기일 수 있다 — RAG 비용 아키텍처를 참고하라.

• 하한: 월 약 $1,050
• 예상: 월 약 $1,500
• 상한: 월 약 $2,100
• 단위 비용 (예상): $1,500 ÷ 300,000 = 요청당 $0.005 — 응대된 티켓 한 건당 반 센트

7단계 — 파일럿과 모니터링으로 루프를 닫기

스프레드시트 추정치는 가설이다. 예측 전체를 걸기 전에 저렴하게 검증하라. 작은 실트래픽 파일럿을 돌려라 — 운영 요청의 1~5%(또는 수천 건의 호출)를 실제 모델로 미러링하고 실제 입력 토큰, 출력 토큰, 재시도, 캐시 적중률을 로깅하라. 측정된 요청당 토큰 수를 여러분의 버킷과 비교하라. 출력이 가정한 350 토큰이 아니라 450 토큰으로 나오고 있다면, 그것이 청구서에서 30% 깜짝 폭탄이 된 후가 아니라 그 전에 격차를 찾아낸 것이다.

추정치에서 가장 자주 어긋나는 두 숫자는 출력 길이(모델은 예상보다 수다스럽다)와 캐시 적중률(드물거나 폭발적인 트래픽은 캐시를 차갑게 유지해서, 읽기 이득은 못 얻으면서 쓰기 값만 낸다)이다. 둘 다 파일럿에서 직접 측정 가능하고 둘 다 고칠 수 있다. 여기서의 빗나감은 실패한 추정이 아니다 — 보정이 필요했던 변수를 표면으로 끌어올린, 설계대로 작동하는 추정이다.

일단 라이브가 되면, 추정치는 지켜볼 때에만 예산이 된다. 일별·요청별 지출을 추적하고, 예상 단위 비용에서 벗어나는 드리프트에 알람을 걸며, 프롬프트·검색 깊이·모델이 바뀔 때마다 — 어느 하나라도 모든 버킷을 조용히 바꾸므로 — 이 계산 전체를 다시 돌려라. 이를 LLM 비용 모니터링으로 구성하고, 더 저렴한 모델이 유혹할 때는 추측하지 말고 마이그레이션 시뮬레이터로 먼저 전환 비용을 매겨보라.

자주 묻는 질문

관련 글