한 달 동안 고객지원 에이전트의 총이익률이 약 60%인 줄 알았다가 실제로 적자로 전환된 경험

이 요약은 AI가 원문을 분석해 생성했습니다. 정확한 내용은 원문 기준으로 확인하세요.

TL;DR

작성자는 평균 대화당 토큰 지표만 보고 서비스의 총이익률이 약 60%라고 판단했으나 일부 엔터프라이즈 고객이 실제로 도입되면서 마진이 음수로 전환되어 근본 원인을 조사했다는 경험을 공유했다. 조사 결과 일부 고객이 툴 호출, 벡터 DB 쿼리, 웹 검색, TTS 등 비-LLM 호출을 빈번히 발생시키고 타임아웃·레이트리밋으로 재시도가 발생하며 긴 컨텍스트를 반복 전송해 토큰 비용이 비선형으로 증가한 점이 확인되었다. 작성자는 이러한 손실을 막기 위해 비용을 모델별이 아닌 고객별로 귀속하고 비-LLM 호출과 재시도를 비용으로 집계하며 고객별 기간 예산 상한을 두어 과다 사용 시 경량 모델로 우회시키는 실무적 대책을 제안했다. 이 접근은 평균 지표로 보이지 않는 꼬리 사용자를 발견하고 즉각적인 비용 통제를 가능하게 했으며 관련 데이터를 기반으로 요금제와 라우팅 정책을 재설계할 근거를 제공했다.

실용적 조언

비용을 고객 단위로 귀속시키면 소수 과다 사용 고객이 전체 손익에 미치는 영향을 즉시 식별할 수 있다. 고객별로 토큰 사용량, 툴 호출, 벡터 쿼리, TTS 호출 및 재시도를 집계하여 데이터베이스에 저장하면 꼬리 사용자 탐지가 가능해진다. 이 데이터를 기반으로 예산 경고와 자동 라우팅 규칙을 설정하면 비용 누수를 사전에 차단할 수 있다.
비-LLM 호출 항목을 비용 모델에 포함시키면 전체 청구 구조의 30~40%를 놓치지 않을 수 있다. 툴 호출과 외부 쿼리는 각 호출마다 별도의 API 비용과 지연을 수반하므로 호출 단위 로깅과 비용 매핑이 필요하다. 이 정보를 활용하면 요금제 설계와 내부 캐싱·효율화 우선순위를 정할 수 있다.
재시도를 비용으로 처리하면 실패와 네트워크 문제로 인한 숨은 비용을 제거할 수 있다. 실패 로그에 재시도 횟수와 원인(타임아웃·레이트리밋·응답 오류)을 함께 기록하면 문제 구간을 찾아 더 낮은 수준의 재시도나 회피 전략을 적용할 수 있다. 재시도 비용을 포함한 고객별 보고서를 정기적으로 확인하면 SLA 개선 포인트가 드러난다.
고객별 예산 상한을 설정하고 초과 시 자동으로 경량 모델로 라우팅하거나 기능을 축소하는 방식이 비용 통제에 현실적인 대안이었다. 과다 사용 상위 소수에게만 품질 저하를 적용하면 전체 매출 손실을 방지하면서 비용을 관리할 수 있다. 이 전략은 요금제 구조를 재설계할 시간을 벌어주며 장기적으로는 보다 정교한 계층형 요금 모델 도입으로 연결된다.

섹션별 상세

평균값에 의존하면 분포의 꼬리가 숨겨지는 문제가 발생했다는 것이 작성자의 핵심 문제였다. 계정 전체의 '평균 대화당 토큰' 지표는 정확했지만 일부 고객이 비정상적으로 많은 호출과 긴 컨텍스트를 발생시키면서 고객 단위로 보면 비용이 크게 증폭되었다. 실제 사례로 몇몇 엔터프라이즈 계정 도입 이후에 전체 마진이 음수로 바뀌었으며 이 현상은 평균 지표만으로는 탐지되지 않았다. 따라서 비용을 모델별이 아니라 고객별로 귀속시키는 방식이 필요하다는 결론이 도출되었다.

에이전트 제품에서는 LLM 호출 외에도 여러 비-LLM 비용 항목이 실질적 비중을 차지한다는 점이 문제로 제기되었다. 구체적으로 툴 호출, 벡터 DB 쿼리, 웹 검색, TTS 등이 반복될 때 각 호출마다 별도 비용이 발생하며 작성자는 이러한 항목이 전체 청구액의 30~40%를 차지하는 경우를 관찰했다. 이 항목들은 모델 호출 대시보드의 '토큰당 비용'으로 드러나지 않기 때문에 통상 추적되지 않으며, 추적을 추가해야만 실제 비용 구조를 파악할 수 있다. 결과적으로 비-LLM 호출을 비용 집계에 포함시키지 않으면 손익 계산이 허구가 된다.

타임아웃과 레이트리미트로 인한 재시도는 각 논리적 단계의 비용을 수배로 늘리는 원인으로 확인되었다. 실패가 발생하면 시스템이 재시도를 수행하면서 동일한 호출이 2~3회 청구되는 일이 빈번했고, 작성자는 한 단계가 실제로 2~3배 비용을 초래한 사례를 보고했다. 많은 회답 시스템이 성공한 호출만 로깅하면 재시도 비용이 회계에서 누락되므로 재시도도 비용으로 인식해야만 실제 마진 계산이 정확해진다. 따라서 재시도 로그와 실패 케이스를 비용 집계 데이터에 포함하는 것이 필수적이다.

고객별 예산 상한을 설정하고 과다 사용자를 경량 모델 또는 서비스 저하로 우회시키는 전략이 비용 통제에 효과적이라는 결론이 도출되었다. 작성자는 가장 무거운 상위 2% 사용자에게는 더 작은 모델을 적용하거나 서비스 품질을 점진적으로 낮추는 방식이 무제한 비용을 떠안는 것보다 저렴하다고 경험적으로 판단했다. 이 방식은 즉각적인 비용 억제를 가능하게 하며 장기적으로는 요금제 설계와 SLA 조정의 근거 데이터를 제공한다. 따라서 단순한 요금 정책 변경보다 고객 단위의 예산과 라우팅 규칙을 먼저 도입해야 한다.

용어 해설

벡터 DB(Vector DB): — 임베딩을 벡터로 저장하고 유사도 검색을 통해 문맥을 반환하는 저장소다. 사용자는 쿼리 임베딩과 저장된 벡터 간 거리 계산으로 관련 문서를 검색하며 이 과정에서 외부 API 호출과 I/O 비용이 발생한다. 에이전트 제품에서는 검색 빈도가 높아지면 전체 비용에서 상당 비중을 차지하는 요소로 작용한다.
토큰 기반 과금(Token Pricing): — 입력과 출력의 토큰 수를 기준으로 모델 호출 비용을 계산하는 과금 방식이다. 긴 컨텍스트를 반복 전송할수록 토큰 비용이 비선형으로 증가하며 대화형 에이전트에서는 히스토리 재전송으로 비용이 빠르게 쌓인다. 고객별 대화 길이 분포가 불균형하면 평균 단가로는 진짜 비용 구조를 파악할 수 없다.
툴 호출(Tool Call): — 에이전트가 외부 기능(검색, 데이터베이스 조회, TTS 등)을 실행하기 위해 발생시키는 API 요청이다. 각 호출은 별도 비용과 지연, 실패 가능성을 동반하며 호출 빈도와 실패율에 따라 전체 비용 구조가 크게 달라진다. 에이전트 아키텍처에서는 툴 호출을 추적하지 않으면 모델 비용 외의 누수를 놓치게 된다.

언급된 도구

Pylva중립링크

agent 제품을 위한 비용 추적 및 청구 솔루션