AI 운영비가 전월 대비 크게 오르면 팀 대부분은 곧바로 예산 증액을 검토한다. 그런데 이 논의에서 빠지는 질문이 있다. 비용이 오른 이유가 실제 사용 증가인지, 아니면 최적화되지 않은 토큰 소비 패턴인지다.
두 경우의 대응은 전혀 다르다. 사용자가 늘고 기능 사용이 늘었다면 예산을 늘리는 것이 맞다. 그런데 원인이 불필요하게 긴 컨텍스트, 반복되는 에러 재처리, 캐시 없이 같은 요청을 매번 처리하는 구조라면, 예산을 늘려도 같은 문제가 더 큰 규모로 되풀이된다. 이 구분 없이 예산 숫자만 조정하면 다음 분기에 같은 논의가 돌아온다.
비용을 실제로 움직이는 드라이버 네 가지
AI 토큰 비용은 단일 변수로 움직이지 않는다. 청구 금액을 키우는 요인은 크게 네 가지다.
모델 선택. 고성능 모델과 경량 모델의 단가 차이는 수 배에 달한다. 많은 팀이 개발 초기에 정확도를 이유로 고성능 모델을 선택하고, 운영 단계에서도 그 선택을 그대로 유지한다. 그러나 분류, 요약, 구조화된 데이터 추출처럼 반복성이 높고 형식이 단순한 작업은 경량 모델로도 충분한 경우가 많다. 어떤 작업에 어떤 모델을 쓰는지 목록화되어 있지 않다면, 비용 최적화 논의는 여기서 시작한다.
컨텍스트 길이. 토큰 과금은 프롬프트와 응답을 합산해 이루어진다. 멀티턴 대화나 문서 기반 작업에서는 대화 이력 전체나 문서 원문이 매 요청마다 컨텍스트에 포함되기 쉽다. 대화가 길어질수록, 참조 문서가 클수록 단건 비용은 선형 이상으로 오른다. 이 구조를 통제하지 않으면 사용량이 늘 때 비용이 그 이상으로 튄다.
에러 재처리. API 오류, 타임아웃, 응답 형식 불일치로 인한 재시도는 토큰을 두 번 이상 소비한다. 파이프라인이 정교하지 않을 때 에러율이 조금만 높아져도 전체 토큰 사용량에서 재처리가 차지하는 비중이 생각보다 커진다. 이 비중을 별도 지표로 추적하는 팀은 드물다.
캐싱 효율. 동일하거나 거의 동일한 요청이 반복될 때 캐시를 활용하면 토큰 소비 없이 응답을 돌려줄 수 있다. 시스템 프롬프트나 RAG 컨텍스트가 요청마다 조금씩 달라지거나 캐싱 레이어 자체가 없다면, 반복 비용이 그대로 누적된다.
원인을 진단하는 순서
예산 논의 전에 원인부터 분리해야 한다. 진단 없이 예산만 조정하면 문제의 위치를 모른 채 숫자만 바뀐다.
1단계: 사용량 증가와 단건 비용 증가를 분리한다. 총 토큰 소비가 늘었다면, 요청 건수가 늘었는지 건당 토큰이 늘었는지부터 확인한다. 건수 증가는 실제 사용 성장일 가능성이 높다. 건당 증가라면 컨텍스트 길이, 에러 재처리, 모델 변경 여부를 차례로 살핀다.
2단계: 워크로드 유형별로 토큰 소비를 나눈다. 단순 분류 요청과 복잡한 생성 요청이 같은 서비스 안에 섞여 있는 경우, 총합만 보면 어디서 비용이 오르는지 파악하기 어렵다. 워크로드 유형별로 단가와 볼륨을 따로 집계해야 원인이 보인다.
3단계: 에러율과 재처리 비율을 별도 지표로 집계한다. 성공한 요청과 재처리된 요청을 구분하지 않으면 실질 낭비 규모를 알 수 없다. 대부분의 LLM API는 성공·실패를 구분한 로그를 제공하거나 추출할 수 있다. 처음부터 모니터링 대시보드에 포함시키지 않으면 나중에 역추적하는 데 시간이 걸린다.
4단계: 캐싱이 적용 가능한 요청 유형을 파악한다. 전체 요청 중 시스템 프롬프트나 참조 컨텍스트가 고정되거나 반복되는 비율을 추정한다. 이 비율이 높다면 캐싱 레이어 추가만으로도 비용을 줄일 여지가 있다. 단, 실제 캐시 적중률을 측정하지 않으면 효과를 확인할 수 없으므로, 구현 전에 반복 요청 비율을 먼저 추정하고 임계값 이상일 때 투자를 결정하는 것이 합리적이다.
상황별로 먼저 손댈 곳이 다르다
어느 드라이버부터 최적화할지는 서비스 구조에 따라 달라진다.
사용량이 예측 가능하고 워크로드 유형이 단순한 경우, 모델 교체가 가장 빠른 효과를 낸다. 작업 유형별로 경량 모델 적용 가능성을 실험하되, 품질 기준을 실험 전에 정의해두지 않으면 결과 판단이 주관적으로 흐른다. 응답 정확도, 포맷 준수율처럼 측정 가능한 지표를 먼저 정하고 A/B 비교나 오프라인 평가로 차이를 수치화하는 순서가 필요하다.
멀티턴 대화나 문서 기반 작업이 주된 경우, 컨텍스트 관리가 핵심이다. 대화 이력을 얼마나 유지할지, 참조 문서를 전문 포함할지 요약해 포함할지, 청킹 전략을 어떻게 설정할지가 단건 비용에 직접 영향을 준다. 이 결정은 엔지니어링 팀과 제품 팀이 함께 내려야 한다. 엔지니어링 팀에만 맡기면 비즈니스 품질 기준이 빠지고, 제품 팀에만 두면 구현 가능성이 검토되지 않는다.
에러율이 높거나 파이프라인이 복잡하게 연결된 경우, 재처리 비용부터 잡는다. 에러 유형을 분류하고 각각의 처리 방식을 명시적으로 정의하는 것이 먼저다. 재시도 횟수를 제한하고 폴백 로직을 구체화하면 비용뿐 아니라 시스템 안정성에도 영향을 준다.
같거나 비슷한 요청이 반복되는 서비스 구조라면, 캐싱 레이어 투자가 가장 높은 효과를 낼 가능성이 있다. 프롬프트 캐싱과 응답 캐싱 중 어디에 적용할지는 서비스 구조에 따라 다르며, 반복 요청 비율이 일정 수준을 넘을 때만 투자 대비 효과가 나온다.
예산을 다시 설계하기 전에 먼저 정해야 할 세 가지
비용 드라이버를 파악했다고 해서 바로 예산 숫자를 정할 수 있는 것은 아니다. 조직이 먼저 합의해야 할 것들이 있다.
첫째, 워크로드 유형별로 허용 가능한 단건 비용 상한을 정한다. 전체 예산 한도보다 단건 상한이 있어야 기능 설계 단계에서 비용 판단이 가능하다. 상한 없이 총액만 관리하면 어느 기능에서 비용이 오르는지 뒤늦게 알게 된다.
둘째, 비용 증가를 허용하는 조건을 명시한다. 사용자 수 증가, 신규 기능 출시, 특정 이벤트 기간처럼 예산 초과가 허용되는 상황을 사전에 정의해두면, 실제 초과 발생 시 원인 판단이 훨씬 빠르다. 이 기준이 없으면 초과할 때마다 같은 논의를 처음부터 다시 시작하게 된다.
셋째, 어떤 지표가 임계값을 넘었을 때 예산을 재검토할지 정한다. 총액이 기준을 초과하면 자동으로 리뷰가 시작되는 구조가 없으면, 비용 문제가 알려지는 시점이 대개 이미 늦다.
세 가지 기준 없이 숫자만 잡으면 다음 분기에 같은 논의가 돌아온다.
지금 당장 시작할 수 있는 첫 단계는 지난 한 달 치 토큰 사용 로그를 워크로드 유형별로 나눠보는 것이다. 분류 자체가 안 되어 있다면, 그 사실이 현재 가장 먼저 해결해야 할 지점이다.
