LLM API 비용 예산 설계: 토큰 단가보다 업무 1건 원가를 계산하는 법

월말 청구서가 예상보다 두 배 늘었는데 어느 기능 때문인지 모르는 상황이 자주 생깁니다. 공급자 대시보드에는 모델별 토큰이 보이지만 “고객 문의 한 건을 해결하는 데 얼마가 들었나”라는 질문에는 바로 답하기 어렵습니다.

토큰 단가는 계산의 재료일 뿐이다. 예산을 운영하려면 요청, 기능, 고객 또는 팀, 재시도와 최종 업무 결과를 같은 식별자로 묶어야 합니다. 모델을 싼 것으로 바꿔도 실패와 재요청이 늘면 업무 원가는 오를 수 있습니다.

청구액, 요청 비용, 업무 원가를 구분한다

세 숫자는 같은 듯 보이지만 쓰임이 다릅니다.

구분	답하는 질문	주된 용도
청구액	이번 기간에 공급자에게 얼마를 내는가	회계 대조, 전체 예산
요청 비용	API 호출 한 번에 얼마가 들었는가	모델·프롬프트 최적화
업무 원가	유효한 결과 한 건을 만드는 데 얼마가 들었는가	제품 가격, 기능 존속 판단

OpenAI는 조직 사용량과 비용을 조회하는 API를 제공하며, 비용 자료는 청구서와 대조하는 기준으로 쓸 수 있습니다. OpenAI Usage API 가격은 별도 공식 가격표에서 현재 값을 확인해야 합니다. OpenAI API 가격표

Anthropic도 Usage & Cost Admin API를 제공합니다. 공식 문서는 사용량 자료가 일반적으로 수 분 안에 나타나며 비용 보고서는 일 단위로 집계된다고 설명합니다. 실시간 차단 장치와 월 청구 대조를 같은 자료 하나에 맡기면 안 되는 이유입니다. Anthropic Usage and Cost API

요청마다 남길 비용 관측 필드

API 키 하나를 서비스 전체가 공유하면 공급자 청구액은 알아도 비용 주인을 찾기 어렵습니다. 모델 호출 전에 내부 cost_context를 만들고 응답의 사용량과 합칩니다.

{
  "request_id": "req_01J...",
  "feature": "support_reply_draft",
  "work_unit_id": "ticket_8421",
  "team": "customer_success",
  "tenant_tier": "business",
  "provider": "provider_a",
  "model_id": "resolved-model-version",
  "input_tokens": 0,
  "cached_input_tokens": 0,
  "output_tokens": 0,
  "tool_calls": 0,
  "retry_count": 0,
  "latency_ms": 0,
  "outcome": "accepted"
}

프롬프트 원문이나 개인정보는 비용 계산에 필요하지 않습니다. 식별자는 내부 티켓과 연결하되 비용 로그만 읽는 사람이 원문을 볼 수 없게 분리합니다. 생성형 AI 로그의 민감정보 기준은 생성형 AI 관측성·프라이버시 가이드에서 이어집니다.

Gemini API 응답은 입력, 출력, 생각, 캐시와 도구 사용 등 토큰 범주를 구분한 사용량 메타데이터를 제공합니다. 입력 전 토큰 수를 세는 방법도 공식 문서에 나와 있습니다. Gemini API 토큰 이해하기

공급자마다 범주 이름과 과금 규칙이 다르므로 내부 필드와 원본 필드를 둘 다 보관하세요. 내부 필드는 비교에 쓰고 원본은 청구 오차를 조사할 때 필요합니다.

요청 비용 계산식은 가격표와 분리한다

가격을 애플리케이션 코드에 박아 두면 공급자가 단가나 캐시 규칙을 바꿀 때 과거 보고서까지 흔들립니다. 가격표를 날짜가 있는 별도 테이블로 관리합니다.

request_cost =
  non_cached_input_tokens × input_unit_price
  + cached_input_tokens × cached_input_unit_price
  + output_tokens × output_unit_price
  + tool_or_storage_charges

work_unit_cost =
  sum(request_cost for the same work_unit_id)
  + allocated_non_model_cost

가격 테이블에는 provider, model_id, price_type, currency, unit_size, effective_from, effective_to, source_url을 둡니다. 보고서를 다시 계산할 때 호출 당시 유효했던 가격을 적용해야 합니다.

Anthropic의 토큰 계산 API는 요청 전에 토큰을 추정할 수 있지만 실제 사용량과 조금 다를 수 있다고 명시합니다. 사전 계산은 한도 확인에, 응답 사용량은 사후 원가에 쓰는 식으로 역할을 나눕니다. Anthropic 토큰 계산

업무 단위를 먼저 정해야 숫자가 쓸모 있어진다

FinOps Foundation은 AI 비용을 토큰 단위에서 멈추지 말고 업무 가치와 연결된 단위 경제성으로 확장하라고 설명합니다. 상담 지원, 에이전트 행동, 처리된 사례처럼 조직이 실제로 세는 단위를 고르는 방식입니다. FinOps Unit Economics

좋은 업무 단위는 다음 조건을 만족합니다.

사용자가 인식하는 결과와 가깝다.
성공과 실패를 구분할 수 있다.
팀·기능·고객군별로 집계할 수 있다.
모델을 바꿔도 같은 정의를 유지한다.

예를 들어 고객 지원 기능이라면 LLM 호출 1회보다 담당자가 승인한 답변 초안 1건이 낫습니다. 문서 추출은 처리한 페이지와 검수 통과 문서를 함께 볼 수 있습니다. 코딩 에이전트라면 에이전트 세션만 세지 말고 테스트를 통과해 병합된 변경과 구분해야 한다.

단위 원가 표 예시

기능	업무 단위	포함 비용	품질 짝지표
문의 답변	승인된 답변 1건	생성, 검색, 재시도	수정률, 해결률
문서 요약	검수 통과 문서 1건	파싱, 저장, 생성	누락률, 반려율
RAG 검색	근거가 확인된 답변 1건	임베딩, 검색, 생성	인용 정확도
업무 에이전트	완료된 작업 1건	계획, 도구 호출, 복구	실패·되돌림 비율

품질 짝지표가 없으면 비용 절감이 실패를 숨길 수 있습니다. RAG의 인용과 근거 평가는 RAG 품질 평가 가이드, 모델 변경 회귀 시험은 LLM 회귀 평가 가이드를 참고하세요.

비용이 새는 지점은 출력 토큰 밖에도 있다

긴 입력이 매번 반복된다

시스템 지침, 도구 명세, 검색 문서가 요청마다 붙으면 입력 비용이 누적됩니다. 지침을 무작정 줄이기보다 중복 문맥, 검색 상위 문서 수, 필요 없는 필드를 먼저 제거합니다. 공급자가 지원하는 캐시도 비용과 만료 조건을 따로 확인해야 합니다.

에이전트가 같은 실패를 반복한다

재시도 횟수만 세면 부족합니다. 모델 재호출, 도구 재실행, 시간 초과 뒤 중복 실행을 구분합니다. 같은 work_unit_id에서 비용이 계속 늘면 최대 단계 수와 사람 전환 조건을 적용합니다.

실패 호출이 업무 결과에서 사라진다

최종 성공 한 건만 기록하면 그 전에 실패한 네 번의 호출이 보이지 않습니다. 요청은 모두 남기고 업무 결과에서 묶어야 실제 단위 원가가 나옵니다.

개발·평가 트래픽이 운영비에 섞인다

환경, 실험 이름, 평가 실행 ID를 비용 태그에 넣습니다. 회귀 평가 비용은 필요하지만 고객 기능의 마진과 같은 표에 섞으면 판단이 흐려집니다.

예산 경보는 세 단계로 나눈다

월 예산 80% 알림 하나만 두면 원인을 찾을 시간이 부족합니다.

요청 전 경계: 예상 입력 토큰, 최대 출력, 남은 일일 한도로 비정상 호출을 막습니다.
운영 경계: 시간당 비용, 업무 1건 원가, 재시도 비율이 평소 범위를 벗어나면 알립니다.
회계 경계: 내부 합계와 공급자 비용 보고서, 청구서를 일·월 단위로 대조합니다.

요청 전 예상치는 정확한 청구액이 아니라 안전장치다. 공급자 보고서가 늦게 들어올 수 있으므로 내부 사용량 계측이 실시간 경보를 맡고, 공식 비용 자료는 정산과 오차 확인을 맡습니다.

경보에는 숫자만 보내지 말고 feature, model_id, team, retry_count, 직전 배포 버전을 붙입니다. 담당자가 바로 행동할 수 없는 알림은 다음 달에도 같은 문제를 반복하게 만든다.

비용을 줄일 때 지켜야 할 순서

비싼 모델을 싼 모델로 바꾸는 일부터 시작하지 않습니다.

중복 요청, 무한 재시도와 쓰지 않는 기능을 제거합니다.
검색 문서와 도구 결과에서 불필요한 문맥을 줄입니다.
출력 길이와 구조를 업무에 맞게 제한합니다.
동일한 품질 평가 세트로 작은 모델과 캐시를 비교합니다.
낮은 위험의 요청부터 라우팅을 바꾸고 회귀를 감시합니다.

이 순서면 비용 절감과 품질 저하를 구분하기 쉽습니다. 공급자의 최신 가격과 무료 구간은 자주 바뀔 수 있으니 이 글에 숫자를 고정하지 않았습니다. 예산표를 갱신하는 날 각 공급자의 공식 가격표와 계약서를 다시 확인하세요. Gemini의 과금 계정과 무료·유료 계층 설명은 Gemini API 결제 문서에서 확인할 수 있습니다.

처음에는 대시보드보다 한 기능의 비용 장부가 낫습니다. 요청 ID와 업무 단위를 연결하고, 일주일치 실패 호출까지 포함해 원가를 계산해 보세요. 그 숫자에 품질 지표를 붙일 수 있을 때 모델 라우팅과 예산 자동화를 시작하면 됩니다.