LLM API 비용 계산법: 입력·출력·캐시 토큰으로 월 예산 잡기

LLM API 비용은 “요청 1건당 얼마”로 계산하면 거의 틀린다. 같은 요청 1건이라도 입력 문서가 2천 토큰인지 5만 토큰인지, 답변이 200토큰인지 4천 토큰인지, 캐시가 맞았는지에 따라 금액이 달라진다. 개발자가 먼저 만들어야 하는 것은 멋진 대시보드가 아니라 팀 전체가 공유할 수 있는 단순한 계산식이다.

이 글은 “LLM API 비용 계산”, “AI API 월 비용”, “토큰 비용 계산법”을 찾는 개발자를 위한 실무 가이드다. 엑셀, SQL, 로그 파이프라인 어디에든 옮길 수 있도록 입력·출력·캐시·재시도 기준으로 정리한다.

기본 공식부터 고정한다

가장 단순한 월 비용 공식은 다음과 같다.

월 비용 = 입력 토큰 비용 + 출력 토큰 비용 + 캐시 쓰기 비용 + 재시도 비용 - 캐시 절감액

벤더마다 항목 이름이 다르지만 개념은 비슷하다. 입력 토큰은 모델이 읽는 텍스트, 출력 토큰은 모델이 생성하는 텍스트다. 캐시 쓰기는 반복 prefix를 저장할 때 드는 비용이고, 캐시 히트는 이미 처리된 prefix를 더 낮은 단가로 읽는 경우다. 일부 모델은 자동 캐싱만 있고, 일부 모델은 명시적 breakpoint를 지원한다. 따라서 계산식은 벤더별로 약간 달라져야 한다.

예산을 잡을 때는 “평균 요청”을 믿으면 안 된다. 평균은 긴 문서 몇 개에 쉽게 왜곡된다. p50, p90, p99 입력 토큰과 출력 토큰을 함께 봐야 한다. 고객 100명이 짧은 질문을 하고 고객 1명이 200페이지 PDF를 올리는 서비스라면 평균값은 운영 리스크를 숨긴다.

요청 유형을 먼저 나눠야 한다

모든 요청을 한 바구니에 넣으면 비용 절감 포인트가 보이지 않는다. 최소한 다음처럼 나눈다.

• chat: 일반 대화, 고객 지원, FAQ 응답
• summarize: 문서 요약, 회의록 요약, 리포트 요약
• extract: JSON 추출, 표 추출, 필드 정규화
• classify: 카테고리 분류, 라우팅, 감정 분석
• agent: 도구 호출, 코드 수정, 멀티스텝 작업
• batch: 야간 대량 처리, 비동기 리포트 생성

각 유형은 토큰 패턴이 다르다. classify는 출력이 짧고 입력도 비교적 짧다. summarize는 입력이 길고 출력은 정책에 따라 달라진다. agent는 입력과 출력이 모두 크고 재시도도 많다. 비용을 낮추려면 유형별로 다른 정책을 둬야 한다.

예를 들어 classify는 저렴한 모델과 짧은 max output으로 충분할 수 있다. summarize는 문서 chunking과 캐시가 중요하다. agent는 컨텍스트 압축, 도구 결과 필터링, 실패 시 중단 조건이 중요하다. 한 가지 모델 정책으로 모든 기능을 운영하면 비용이 새는 지점을 놓친다.

로그 스키마 예시

비용 계산용 로그는 복잡할 필요가 없다. 아래 필드만 있어도 월 예산의 80%는 잡을 수 있다.

이 로그를 남기면 SQL 한 번으로 기능별 원가를 볼 수 있다. 중요한 것은 토큰 합계를 프론트엔드 이벤트처럼 샘플링하지 않는 것이다. 비용 계산용 로그는 누락되면 바로 돈이 새는 로그다. 개인정보가 들어가지 않도록 프롬프트 원문 대신 토큰 수와 해시만 저장하는 방식도 가능하다.

월 예산을 계산하는 순서

첫째, 최근 7일 데이터를 기준으로 기능별 일평균 토큰을 계산한다. 아직 출시 전이라면 베타 사용자 1030명으로 샘플을 만든다. 둘째, 일평균을 30으로 곱해 월간 기본 사용량을 만든다. 셋째, 성장률과 피크 계수를 더한다. 출시 직후나 마케팅 캠페인 기간에는 평소보다 25배 트래픽이 올 수 있다.

넷째, 출력 길이 상한을 반영한다. max output을 8,000으로 열어둔 기능과 1,200으로 제한한 기능은 최악의 비용이 다르다. 다섯째, 재시도율을 더한다. JSON 파싱 실패로 3% 재시도가 발생하면 비용도 대략 3% 늘어난다. 여섯째, 캐시 절감액은 보수적으로 잡는다. 아직 히트율을 측정하지 않았다면 0%로 계산하는 편이 안전하다.

예산표에는 낙관, 기준, 비관 시나리오를 만든다. 기준 시나리오는 현재 p50p90 사용량, 비관 시나리오는 p95p99 사용량과 재시도 증가를 반영한다. 이 작업을 해두면 가격 변경이나 모델 교체가 발생했을 때 표의 단가만 바꿔 다시 계산할 수 있다.

비용을 줄이는 가장 빠른 방법

가장 빠른 방법은 출력 길이를 줄이는 것이다. 출력 단가가 높은 모델에서는 특히 효과가 크다. “상세히 설명해줘” 대신 “결론 3개, 근거 3개, 다음 액션 3개로 답하라”처럼 구조를 제한하면 품질도 좋아진다. 긴 설명이 필요한 화면과 짧은 답이 필요한 화면을 구분해야 한다.

두 번째는 입력을 줄이는 것이다. RAG를 쓴다면 검색 결과를 무조건 많이 넣지 말고, 점수·중복·최신성 기준으로 잘라야 한다. 문서 전체를 넣기 전에 제목, 섹션 요약, 관련 문단만 넣는 구조를 검토한다. 코드 리뷰에서는 전체 diff가 아니라 변경 파일과 실패 테스트 로그를 우선 넣는다.

세 번째는 캐시를 설계하는 것이다. OpenAI 문서는 정적인 지시문과 예시를 프롬프트 앞에 두고, 사용자별 변수는 뒤에 두라고 안내한다. Anthropic 문서는 자동 caching과 명시적 breakpoint를 제공한다. 캐시는 기능이 아니라 프롬프트 구조의 결과다. 고정 prefix가 흔들리면 히트율도 흔들린다.

고객별 원가를 보지 않으면 가격 정책을 못 만든다

B2B 서비스에서 AI 기능을 제공한다면 고객별 원가가 필수다. 전체 비용은 괜찮아 보여도 특정 고객 하나가 긴 문서를 반복 처리해 손실을 만들 수 있다. tenant_id별 비용을 보면 무료 플랜, 스타터 플랜, 엔터프라이즈 플랜의 제한을 합리적으로 설계할 수 있다.

예를 들어 무료 플랜은 월 50회, 문서당 2만 토큰, 짧은 모델만 허용할 수 있다. 유료 플랜은 더 긴 문서와 고급 모델을 제공하되 월별 토큰 한도를 둔다. 엔터프라이즈는 고객별 계약에 따라 별도 한도와 초과 과금을 둔다. 이 정책은 개발팀 로그 없이는 만들 수 없다.

실행 체크리스트

• 요청 유형을 chat, summarize, extract, classify, agent, batch로 나눈다.
• 요청마다 입력 토큰, 출력 토큰, 캐시 쓰기, 캐시 히트, 재시도 횟수를 저장한다.
• 평균뿐 아니라 p50, p90, p99 토큰 사용량을 본다.
• 월 예산은 낙관·기준·비관 3개 시나리오로 만든다.
• 출력 길이 상한과 RAG 검색 결과 개수를 기능별로 제한한다.
• 캐시 절감액은 실제 히트율을 측정하기 전까지 0%로 계산한다.
• 고객별 원가를 보고 플랜별 AI 사용 제한을 설계한다.
• 모델 가격표가 바뀌면 단가만 갈아 끼울 수 있도록 계산식을 문서화한다.