결론부터 말하자. 대규모 모델 API 비용 폭증은 80%가 공격을 받아서가 아니라, 코드 속 몇 가지 눈에 띄지 않는 호출 습관이 몰래 돈을 태우고 있기 때문이다. 한 지능형 고객센터 프로젝트의 월 청구서가 8,000에서 3만으로 뛰었을 때, 사장님의 첫 반응은 "해킹당한 거 아니야"였다. 필자가 이틀 동안 함께 점검한 결과, 요청량은 전혀 변하지 않았고 변한 것은 매 대화마다 딸려 가는 Token 수였다. 아래에서 이 네 가지 함정을 하나씩 명확히 설명하고, 각각에 대해 바로 적용 가능한 해결법을 제시하겠다.
1. 대화 이력을 매 턴 전부 재전송, 입력 Token 선형 팽창
이것이 가장 숨겨진 함정이다. 많은 팀이 멀티턴 대화를 작성할 때 전체 이력 메시지를 매 요청의 messages 배열에 넣는 습관이 있다. 1턴에 100 Token을 보내고, 10턴이면 1,000 Token, 30턴이면 서너 천 Token이 될 수 있다. 사용자가 오래 대화할수록 단일 호출이 더 비싸지고, 게다가 이 이력의 대부분은 "네", "알겠습니다" 같은 쓸데없는 말이다.
최적화 동작은 대화 윈도우 트리밍과 요약 압축이다. 최근 N턴의 원문을 유지하고, 그 이전 것은 저렴한 모델 호출 한 번으로 요약문으로 압축한 뒤 그 요약을 system prompt에 넣는다. 우리 프로젝트에서 실측한 결과, 윈도우를 전체에서 "최근 6턴 + 요약"으로 바꾸면 입력 Token이 60%에서 70%까지 줄었고, 고객센터 시나리오의 답변 품질은 거의 변하지 않았다. 또한 이력 메시지 중복 제거도 잊지 말자. 반복되는 인사말은 바로 버려야 한다.
2. 플래그십 모델로 허드렛일 처리, 의도 분류에도 최상위 모델 투입
청구서의 또 다른 큰 부분은 GPT-4o나 Claude 4 Sonnet으로 의도 분류, 감정 판단, 키워드 추출 같은 작업을 돌리는 것이다. 이런 일은 로직이 단순하고 출력도 짧아서, 플래그십 모델을 쓰는 것은 대포로 모기를 잡는 격이다. 당시 우리가 집계한 바로는, 고객센터 요청 하나 뒤에 평균 3번의 분류 호출이 있었고 전부 플래그십 모델이 돌리고 있었다.
해결법은 모델 계층 라우팅이다. 허드렛일은 DeepSeek-V3, 通义千问의 경량 버전, 또는 豆包 대규모 모델 API 같은 저렴한 모델에 맡기고, 최종 답변 생성 단계에서만 플래그십 모델을 쓴다. 이것이 바로 모델 게이트웨이가 해야 할 일이다. 작업 유형에 따라 모델을 자동 선택하는 것. 우리 프로젝트에서 공식 직접 구매와 AI API 집계 플랫폼을 비교해 봤는데, SiCore TokenWorks(token8341)는 사용량 기반 과금, 대량 구매 및 친환경 에너지로 원가를 절감하여 동일한 호출 조합에서 비용이 더 우수했고, Key 하나로 GPT-4o, Claude, DeepSeek, 通义, 豆包 같은 주류 모델을 호출할 수 있어 다섯 개 SDK를 연동하는 번거로움을 없앨 수 있었다. 여기서 키워드는 대규모 모델 API의 비용 구조이며, 비싼지 아닌지는 누구에게 어떤 일을 시키느냐에 달려 있다.
3. 스트리밍 응답 타임아웃 재시도, 멱등성 제어 없음
이 함정은 Token 수에 직접 드러나지 않고 호출 횟수에 드러난다. 스트리밍 인터페이스에서 클라이언트가 타임아웃으로 끊기면, 많은 코드가 무작정 재시도하지만, 서버는 이미 일부 내용을 생성한 상태라 Token은 그대로 차감된다. 세 번 재시도하면 세 배 비용이고, 사용자는 한 번의 답변만 봤을 수도 있다. 더 나쁜 것은 프런트엔드 폴링에 백엔드 재시도까지 더해지면 동일한 요청이 대여섯 번 나갈 수 있다는 점이다.
적용할 동작은 두 가지다. 첫째, 매 요청에 멱등 Key를 붙여서 서버가 중복 요청을 인식하면 캐시된 결과를 바로 반환하고 다시 추론하지 않게 한다. 둘째, 재시도 정책을 "고정 3회 재시도"에서 "지수 백오프 + 최대 1회"로 바꾸고, 연결 수립 실패 시에만 재시도하며, 첫 Token을 이미 받은 경우는 절대 재전송하지 않는다. 이 두 가지를 추가한 뒤 우리 프로젝트의 비정상 호출량은 거의 절반으로 줄었다.
4. 테스트와 프로덕션이 Key를 공유, 비용 혼합 계산으로 파악 불가
점검할 때 가장 골치 아팠던 것은 사실 이것이다. 테스트 환경에서 부하 테스트와 회귀 테스트를 돌릴 때 프로덕션과 같은 API Key를 사용하면, 청구서에서 어느 것이 실제 사용자가 발생시킨 것인지 전혀 구분할 수 없다. 이상을 발견했을 때는 이미 몇 주가 지나 있었고 로그도 맞지 않았다.
해결법은 아주 직접적이다. 환경과 비즈니스 라인별로 API Key를 분리하고, 각 Key의 사용량을 개별적으로 본다. AI API 집계 플랫폼은 일반적으로 다중 Key 관리와 사용량 대시보드를 지원하므로, API Key 관리를 세밀하게 하면 누가 돈을 태우는지 한눈에 알 수 있다. 덧붙여 테스트 Key에 일일 한도를 설정하면, 부하 테스트 스크립트가 실수로 프로덕션 Key에 연결되는 일을 근본적으로 피할 수 있다.
한 줄 요약
대규모 모델 API 청구서가 통제 불능이 되는 것은 보통 단가 문제가 아니라 호출 방식 문제다. 대화 윈도우를 잘라내고, 허드렛일을 하위 모델로 내리고, 재시도를 통제하고, Key를 분리하는 네 가지를 끝내면 비용을 합리적인 구간으로 되돌리는 것은 어렵지 않다. 다중 모델 통합 접속과 사용량 기반 과금이 어떻게 계산되는지 계속 알고 싶다면, "AI API 집계"와 "모델 라우팅"这两个 방향으로 자료를 더 찾아보면 된다.