AI 앱을 출시하기 전 LLM API 비용을 추정하는 방법

대부분의 AI 앱 프로토타입은 저렴해 보입니다. 그러다 실제 운영(Production) 단계에 들어서면 상황이 달라집니다. 개발자가 20개의 프롬프트(Prompt)로 LLM 기능을 테스트하고 몇 개의 좋은 응답을 얻으면, 비용이 관리 가능한 수준이라고 가정합니다. 하지만 운영 비용은 단 하나의 프롬프트에 기반하지 않습니다. 운영 비용은 다음 요소들에 기반합니다:

• 입력 토큰 (Input tokens)
• 출력 토큰 (Output tokens)
• 사용자당 요청 수 (Requests per user)
• 일일 사용자 수 (Users per day)
• 재시도율 (Retry rate)
• 도구 호출 (Tool calls)
• 프롬프트 캐싱 (Prompt caching)
• 대화 기록 (Conversation history)
• 모델 선택 (Model choice)

이 지점에서 많은 팀이 놀라게 됩니다. 실수는 단순합니다. 전체 운영 워크플로우 (Production workflow)의 비용을 추정하는 대신, 단일 API 호출의 비용만을 추정한다는 것입니다.

기본적인 LLM 비용 공식
가장 단순한 수준에서 LLM 비용은 다음과 같습니다:

입력 비용 (Input cost) = 입력 토큰 × 입력 가격
출력 비용 (Output cost) = 출력 토큰 × 출력 가격
총 비용 (Total cost) = 입력 비용 + 출력 비용

하지만 실제 애플리케이션은 그렇게 단순한 경우가 거의 없습니다. 채팅 애플리케이션에는 다음과 같은 것들이 포함될 수 있습니다:

• 시스템 프롬프트 (System prompt)
• 사용자 메시지 (User message)
• 대화 기록 (Conversation history)
• 검색된 컨텍스트 (Retrieved context)
• 도구 스키마 (Tool schemas)
• 중간 추론 단계 (Intermediate reasoning steps)
• 최종 응답 (Final response)

따라서 실제 토큰 예산은 다음과 같은 형태를 띱니다:

총 입력 토큰 (Total input tokens) = 시스템 프롬프트 토큰 + 사용자 프롬프트 토큰 + 대화 기록 토큰 + 검색된 컨텍스트 토큰 + 도구 스키마 토큰 + 중간 단계 토큰

그리고 출력 토큰 (Output tokens)에는 다음이 포함될 수 있습니다:

• 어시스턴트 응답 (Assistant response)
• 도구 호출 인자 (Tool call arguments)
• 중간 응답 (Intermediate responses)
• 요약 (Summaries)
• 구조화된 JSON 출력 (Structured JSON outputs)

이것이 바로 비용이 예상보다 빠르게 증가하는 이유입니다.

예시: 간단한 AI 어시스턴트
우리가 내부용 AI 어시스턴트를 구축한다고 가정해 보겠습니다. 각 요청은 다음을 사용합니다:

• 요청당 입력 토큰: 3,000
• 요청당 출력 토큰: 800
• 일일 요청 수: 10,000

일일 토큰 규모:

• 일일 입력 토큰 = 3,000 × 10,000 = 30,000,000
• 일일 출력 토큰 = 800 × 10,000 = 8,000,000

월간 토큰 규모:

• 월간 입력 토큰 = 900,000,000
• 월간 출력 토큰 = 240,000,000

이제 이를 제공업체의 모델 가격에 곱해 보십시오. 이 지점에서 아키텍처 결정 (Architecture decisions)이 중요해지기 시작합니다. 더 큰 모델이 더 나은 결과를 제공할 수 있지만, 작업량이 대량(High-volume)인 경우 비용 차이가 매우 커질 수 있습니다.

분류(Classification), 라우팅(Routing), 추출(Extraction) 또는 요약(Summarization) 작업에는 더 작은 모델로도 충분할 수 있습니다.

숨겨진 비용: 출력 토큰 (Output tokens)
개발자들은 종종 입력 토큰 (Input tokens)에만 집중합니다. 그것은 실수입니다. 많은 LLM 제공업체(LLM providers)의 경우 출력 토큰은 일반적으로 입력 토큰보다 더 비쌉니다. 또한, 장황한 응답은 지연 시간 (Latency)과 비용을 증가시킵니다. 예를 들어, 다음과 같은 출력 스타일은:

{ "answer" : "..." , "reasoning" : "..." , "sources" : [ ... ], "confidence" : "..." , "follow_up_questions" : [ ... ] }

유용할 수는 있지만, 다음과 같은 방식보다 더 많은 비용이 듭니다:

{ "answer" : "..." , "sources" : [ ... ] }

구조화된 출력 (Structured output)은 훌륭하지만, 모든 필드에는 비용이 따릅니다. 프로덕션 시스템 (Production systems)에서 응답 설계는 곧 아키텍처입니다.

RAG는 비용 계산을 더 어렵게 만듭니다
검색 증강 생성 (RAG, Retrieval-Augmented Generation) 시스템에서는 모든 요청에 검색된 청크 (Chunks)가 포함될 수 있습니다. 예시:

시스템 프롬프트 (System prompt): 800 토큰
사용자 질문 (User question): 100 토큰
검색된 청크 (Retrieved chunks): 5개 청크 × 700 토큰 = 3,500 토큰
대화 기록 (Conversation history): 1,500 토큰
출력 여유분 (Output reserve): 800 토큰
총 요청 크기: 800 + 100 + 3,500 + 1,500 = 5,900 입력 토큰

RAG 시스템은 단순히 벡터 데이터베이스 (Vector database)의 문제가 아닙니다. 그것은 또한 토큰 예산 편성 (Token budgeting)의 문제입니다.

에이전트 워크플로우 (Agentic workflows)는 비용을 배가시킵니다
에이전트 AI (Agentic AI)는 비용 추정을 훨씬 더 중요하게 만듭니다. 단순한 채팅 요청은 한 번의 LLM 호출 (LLM call)일 수 있습니다. 하지만 에이전트 작업은 다음과 같은 과정을 포함할 수 있습니다:

1. 의도 분류 (Intent classification)
2. 계획 (Planning)
3. 도구 선택 (Tool selection)
4. 도구 실행 (Tool execution)
5. 관찰 (Observation)
6. 재시도 또는 수정 (Retry or correction)
7. 최종 답변 생성 (Final answer generation)

이는 사용자 요청 하나가 5~10번의 LLM 호출이 될 수 있음을 의미합니다. 만약 각 단계에서 서로 다른 프롬프트, 컨텍스트 (Context), 출력을 사용한다면, 실제 비용은 다음과 같습니다:

사용자 작업당 비용 = 계획 비용 + 도구 선택 비용 + 도구 호출 인자 생성 비용 + 관찰 요약 비용 + 재시도 비용 + 최종 답변 비용

이것이 에이전트에게 "API 호출당 비용"이 잘못된 지표인 이유입니다. 더 나은 지표는 "완료된 작업당 비용 (Cost per completed task)"입니다.

프롬프트 캐싱 (Prompt caching)은 경제성을 바꿀 수 있습니다
사용 중인 제공업체가 프롬프트 캐싱을 지원한다면, 반복되는 프롬프트 섹션은 더 저렴해질 수 있습니다.

캐싱 (Caching)에 적합한 대상: 시스템 프롬프트 (System prompts), 정책 지침 (Policy instructions), 도구 정의 (Tool definitions), 스키마 설명 (Schema descriptions), 정적 비즈니스 규칙 (Static business rules), 크고 재사용 가능한 컨텍스트 블록 (Large reusable context blocks). 하지만 캐싱은 반복되는 부분이 안정적일 때만 도움이 됩니다. 캐싱에 부적합한 대상: 사용자별 데이터 (User-specific data), 빈번하게 변경되는 검색된 청크 (Frequently changing retrieved chunks), 동적 대화 기록 (Dynamic conversation history), 실시간 도구 출력 (Real-time tool outputs). 따라서 비용을 추정할 때는 입력을 다음과 같이 분리하십시오: 캐싱 가능한 토큰 (Cacheable tokens), 캐싱 불가능한 토큰 (Non-cacheable tokens). 이렇게 하면 더 현실적인 추정치를 얻을 수 있습니다.

아키텍트가 프로덕션(Production) 전에 추정해야 할 사항
LLM 기능을 출시하기 전에 최소한 다음 수치들을 추정하십시오:

• 요청당 평균 입력 토큰 (Average input tokens per request)
• 요청당 평균 출력 토큰 (Average output tokens per request)
• 일일 활성 사용자당 요청 수 (Requests per active user per day)
• 예상 일일 활성 사용자 수 (Expected daily active users)
• 재시도율 (Retry rate)
• 캐시 히트 비율 (Cache hit percentage)
• 워크플로당 LLM 호출 횟수 (Number of LLM calls per workflow)
• 피크 트래픽 배수 (Peak traffic multiplier)
• 월간 토큰 볼륨 (Monthly token volume)
• 사용자당 비용 (Cost per user)
• 비즈니스 트랜잭션당 비용 (Cost per business transaction)

엔터프라이즈 시스템의 경우, 다음 사항도 함께 추정하십시오:

• 유스케이스별 비용 (Cost by use case)
• 부서별 비용 (Cost by department)
• 모델별 비용 (Cost by model)
• 워크플로 단계별 비용 (Cost by workflow step)
• 실패한 요청당 비용 (Cost by failed request)
• 캐싱 적용 시와 미적용 시의 비용 (Cost with and without caching)
  이는 나중에 예상치 못한 상황이 발생하는 것을 방지해 줍니다.

실제 예시
다음과 같다고 가정해 봅시다:

• 일일 활성 사용자 (Daily active users): 2,000명

• 사용자당 일일 요청 수 (Requests per user per day): 15회

• 요청당 입력 토큰 (Input tokens per request): 4,000개

• 요청당 출력 토큰 (Output tokens per request): 700개

• 워크플로당 LLM 호출 횟수 (LLM calls per workflow): 2회

• 재시도율 (Retry rate): 10%

• 총 일일 워크플로 (Total daily workflows): 2,000 × 15 = 30,000 workflows/day

• 워크플로당 2회의 LLM 호출 포함 시: 30,000 × 2 = 60,000 LLM calls/day

• 10%의 재시도율 포함 시: 60,000 × 1.10 = 66,000 effective calls/day

• 일일 입력 토큰 (Daily input tokens): 66,000 × 4,000 = 264,000,000 input tokens/day

• 일일 출력 토큰 (Daily output tokens): 66,000 × 700 = 46,200,000 output tokens/day

• 월간 추정치 (Monthly estimate):

  • 월간 입력 토큰 (Input tokens/month) = 79.2억 개
  • 월간 출력 토큰 (Output tokens/month) = 13.86억 개

이제 아키텍처에 대한 논의가 달라집니다. 이것은 더 이상

다음 작업에는 더 작거나 저렴한 모델을 사용하세요:

• 분류 (classification)
• 라우팅 (routing)
• 메타데이터 추출 (metadata extraction)
• 요약 (summarization)
• 가드레일 체크 (guardrail checks)
• 형식 검증 (format validation)
  추론 품질 (reasoning quality)이 중요한 경우에만 더 큰 모델을 사용하세요.

불필요한 컨텍스트 (context) 줄이기
더 많은 컨텍스트가 항상 더 좋은 것은 아닙니다. RAG (Retrieval-Augmented Generation) 시스템에서 5개면 충분한 상황에 15개의 청크 (chunks)를 보내는 것은 비용을 증가시키고 답변 품질을 저하시킬 수 있습니다.
제어 항목: 청크 개수, 청크 크기, 대화 기록 (conversation history), 도구 스키마 (tool schema) 크기, 메타데이터 상세도 (metadata verbosity)

안정적인 프롬프트 섹션 캐싱 (Cache)
동일한 시스템 프롬프트 (system prompt), 정책 텍스트, 또는 도구 정의 (tool definitions)가 요청 전반에 걸쳐 재사용된다면, 캐싱을 통해 비용을 줄일 수 있습니다. 재사용 가능한 안정적인 섹션을 포함하도록 프롬프트를 설계하세요.

긴 대화 요약하기
매번 전체 대화를 보내는 대신, 압축된 메모리 요약본을 유지하세요.
예시:

• 전체 대화 기록: 12,000 토큰 (tokens)
• 압축된 요약: 1,200 토큰 (tokens)
  이 차이는 규모가 커질수록 중요해집니다.

호출당 비용이 아닌 워크플로 (workflow)당 비용 측정하기
단일 사용자 작업이 여러 번의 모델 호출을 트리거할 수 있습니다.
다음 항목을 추적하세요:

• 채팅 응답당 비용 (cost per chat response)
• 처리된 문서당 비용 (cost per document processed)
• 해결된 지원 티켓당 비용 (cost per support ticket resolved)
• 생성된 SQL 답변당 비용 (cost per SQL answer generated)
• 완료된 에이전트 작업당 비용 (cost per agent task completed)
  비즈니스 수준의 비용이 API 수준의 비용보다 더 유용합니다.

진정한 교훈
LLM 비용 추정은 단순한 재무 업무가 아닙니다. 그것은 아키텍처 (architecture) 업무입니다.
비용은 다음 요소에 따라 달라집니다:

• 모델 선택 (model choice)
• 프롬프트 설계 (prompt design)
• 컨텍스트 크기 (context size)
• RAG 전략 (RAG strategy)
• 에이전트 루프 설계 (agent loop design)
• 도구 스키마 크기 (tool schema size)
• 재시도 처리 (retry handling)
• 캐싱 전략 (caching strategy)
• 출력 형식 (output format)
  이는 개발자와 아키텍트가 청구서가 도착한 후가 아니라, 배포하기 전에 비용을 추정해야 함을 의미합니다.

이를 위해 무료 계산기를 만들었습니다:
👉 LLM Inference Cost Calculator
다음 항목을 추정하는 데 도움이 됩니다:

• 일일 비용 (daily cost)
• 월간 비용 (monthly cost)
• 사용자당 비용 (cost per user)
• 워크플로당 비용 (cost per workflow)
• 토큰 볼륨 (token volume)
• 프롬프트 캐싱의 영향 (prompt caching impact)
• 멀티 모델 비교 (multi-model comparison)

더 광범위한 계산기 허브도 여기서 확인하실 수 있습니다:
👉 SuperML AI Calculators

마지막 생각
AI 아키텍처의 미래는 단지 최고의 모델을 선택하는 것에 관한 것이 아닐 것입니다. 그것은 적절한 단계에서, 적절한 컨텍스트와 함께, 적절한 비용으로, 적절한 모델을 선택하는 것에 관한 것이 될 것입니다.

그것이 바로 데모(Demo)와 프로덕션(Production) AI 시스템의 차이입니다. LLM 추론 비용 계산기 — 프로덕션 LLM API 비용 추정 | SuperML — SuperML.dev OpenAI, Anthropic, Google, Mistral, 그리고 Meta 모델 전반에 걸친 일일 및 월간 LLM 추론 비용을 추정합니다. 프롬프트 캐싱 (Prompt caching), 사용자당 비용 (Cost-per-user), 토큰 소모율 (Token burn-down), 그리고 다중 모델 비교 (Multi-model comparison) 기능을 포함합니다. superml.dev