결론부터 말하자. 고객센터 챗봇이 돈을 태우는 이유는 십중팔구 모델 단가가 비싸서가 아니라 호출 방식에 문제가 있기 때문이다. 우리 내부의 일일 활성 사용자 수천 명 규모의 애프터서비스 Q&A 봇이 출시 첫 달에 청구서가 예산의 세 배까지 치솟았다. 원인을 추적해 보니 모델 단가는 1원도 변하지 않았고, 전부 호출 구조상의 보이지 않는 비용이었다. 이 글에서는 회고 과정을 정리해 보겠다. 대규모 언어 모델 API 비용 최적화에 관심이 있다면 자신의 청구서와 하나씩 대조해 보길 바란다.
청구서 이상은 어떤 모습인가
이상의 특징은 "총액이 높다"가 아니라 "구조가 이상하다"이다. 일별 호출 상세를 뽑아보니 세 가지 이상한 점이 발견됐다. 호출량이 가장 높은 날들에 단일 요청의 평균 token 수가 올라가고 있었다. 재시도 횟수 비중이 거의 20%에 달했다. 같은 사용자 질문인데 짧으면 몇백 token, 길면 만 단위 token으로 분산이 극심했다. 이 세 가지가 겹치면 문제가 모델 쪽이 아니라 우리 자신의 호출 체인에 있다는 것을 거의 특정할 수 있다.
네 가지 보이지 않는 비용, 하나같이 더 은밀하다
첫째, 플래그십 모델이 허드렛일을 한다. 우리는 처음에 편하려고 모든 요청을 일괄 플래그십 모델로 보냈다. 하지만 고객센터 시나리오에서는 70% 이상이 "주문 어디쯤 왔어요", "반품 어떻게 해요" 같은 의도 인식과 고정 응대 답변이라, 이런 작업은 소형 모델로 충분하고 비용 차이는 한 자릿수 배수다. 플래그십 모델에게 "영업시간 몇 시예요"를 답하게 하는 것은 트럭으로 배달 음식을 보내는 것과 같다.
둘째, 컨텍스트가 무절제하게 팽창한다. 멀티턴 대화에서 우리는 과거 메시지를 전부 다시 넣었다. 사용자가 열 번째 턴까지 대화하면 과거 기록만으로 대부분의 token을 차지했다. 더 골치 아픈 것은 많은 과거 기록이 현재 질문과 전혀 관련이 없이 그저 따라다닐 뿐이라는 점이다. 컨텍스트가 길수록 똑똑해지는 게 아니라, 일정 길이를 넘으면 정확도 향상은 제한적인데 비용은 선형으로 상승한다.
셋째, 재시도 폭풍. 우리는 단순한 실패 재시도를 설정했지만 백오프와 서킷 브레이커를 넣지 않았다. 업스트림에서 간헐적 타임아웃이 발생할 때 같은 요청 묶음이 반복해서 밀려 들어갔고, 한 번 실패하면 재시도, 재시도가 또 실패하면 또 재시도했다. 청구서에서 이 부분 호출은 전부 헛돈이었고, 사용자 쪽에서 보이는 것은 여전히 오류였다.
넷째, 스트리밍과 비스트리밍의 중복 과금. 이게 가장 놓치기 쉽다. 우리는 어떤 체인에서는 완전한 결과를 받아 후처리를 하려고 비스트리밍으로 한 번 호출하고, 프런트엔드에서는 타이프라이터 효과를 위해 스트리밍으로 다시 한 번 호출했다. 같은 질문에 두 번 돈을 낸 것이다. 나중에 스트리밍 수신, 로컬 조립으로 통일하고 나서야 이 중복 비용이 사라졌다.
계층형 라우팅은 어떻게 구현하는가
발상은 복잡하지 않다. 작업 난이도에 따라 분류하는 것이다. 의도 인식, 슬롯 추출, 고정 응대 답변 같은 것은 경량 모델로 보내고, 진짜 추론과 다단계 판단, 감정 케어가 필요한 복잡한 대화만 플래그십 모델에 맡긴다. 중간에 모델 게이트웨이 계층을 두고 판단하게 하여, 요청이 들어오면 먼저 분류기를 통과하고 작업 태그를 붙인 뒤 어느 모델로 라우팅할지 결정한다.
우리는 작업별로 자동으로 최적 모델을 선택하는 이 로직을 사용했고, SiCore TokenWorks의 멀티 모델 라우팅에서 한 차례 비교를 돌려본 결과, 단순 작업을 경량 모델로 전환한 뒤 전체 비용이 뚜렷하게 내려갔고 응답도 더 빨라졌다. 여기서 핵심은 "어떤 모델을 쓰는가"가 아니라 "어떤 작업에 어떤 모델을 배정하는가"라는 매핑 테이블을 지속적으로 조정하는 것이다. 출시 초기에는 경험에 따라 배정했고, 2주 운영 후 실제 적중률에 따라 다시 한 번 재보정했는데, 결과가 감으로 배정한 것보다 훨씬 좋았다. 멀티 모델 통합 연동의 장점도 이때 드러나는데, 라우팅 전략을 바꿔도 비즈니스 코드를 고칠 필요 없이 게이트웨이 계층에서 조정하면 된다.
최적화 전후 청구서 비교
구체적인 숫자는 밝히지 않고 비율로 말하겠다. 총 호출량은 변하지 않았다. 사용자 수가 변하지 않았기 때문이다. 총비용은 약 60% 줄었고, 그중 플래그십 모델 호출 비중은 거의 100%에서 30% 정도로 떨어졌으며 나머지는 경량 모델로 분산됐다. 재시도 관련 호출은 거의 20%에서 한 자릿수 퍼센트로 눌렀다. 단일 요청의 평균 token 수는 약 40% 줄었는데 주로 컨텍스트 절단 덕분이다. 스트리밍 중복 과금 부분은 바로 0이 됐다. 전체적으로 계산하면 예산 세 배 초과에서 예산 내로 돌아오고도 여유가 남았다.
모니터링과 알림은 어떻게 구성하는가
아낀 돈을 지키는 것은 자각이 아니라 모니터링에 달려 있다. 우리는 네 가지 알림을 구성했다. 단일 요청 token 수가 임계값을 초과하면 발동하여 컨텍스트 폭주를 방지한다. 재시도율이 설정 비율을 넘으면 발동하여 재시도 폭풍을 방지한다. 플래그십 모델 호출 비중이 비정상적으로 높아지면 발동하여 라우팅이 실패했을 가능성을 알린다. 일일 비용의 전일 대비 상승폭이 임계값을 넘으면 발동한다. 이 네 가지는 복잡하게 만들 필요 없이 일 단위 집계, 기준선 초과 알림이면 충분하다. Token 과금 모델에서는 비용이 실시간으로 누적되므로, 월말에 청구서를 보고 나서 최적화하면 돈은 이미 나간 뒤다.
한 문장으로 요약하면: 고객센터 챗봇의 비용 대부분은 호출 구조에 있고 모델 단가에 있지 않다. 계층형 라우팅, 컨텍스트 절단, 재시도 제어, 스트리밍 통일 이 네 가지를 탄탄하게 해두면 청구서는 자연히 내려간다. 한 걸음 더 나아가, 만약 당신의 시나리오에 RAG 검색이 있다면 벡터 저장소의 검색 결과 개수도 같은思路로 한 번 점검해 볼 가치가 있다.