백엔드와 AI 애플리케이션 개발을 하는 동료들이라면 아마 이런 순간을 겪어봤을 것이다. 월말에 클라우드 청구서를 열어보니 대규모 모델 API 지출이 예산의 3배다. 공격을 받은 것도 아니고, 비즈니스가 폭증한 것도 아닌데, 온라인 대화 서비스가 조용히 돈을 태워버린 것이다. 이 글에서는 엔지니어링 관점에서 돈이 어디로 새는지, 그리고 기술적 수단으로 어떻게 막을 수 있는지 분석해본다.
함정 1: 컨텍스트 윈도우의 무절제한 팽창
멀티턴 대화에서 가장 쉽게 간과되는 비용 원인은 이전 메시지 전체를 되돌려 보내는 것이다. 고객 서비스 시나리오를 가정해보자. 매 턴 평균 800 토큰 컨텍스트라면, 사용자가 20번째 턴까지 대화했을 때 단일 요청의 입력은 거의 16000 토큰에 달한다. GPT-4o 입력 $2.5/1M 토큰으로 계산하면 단일 요청 입력 비용은 약 $0.04, 하루 5만 번 호출이면 $2000이다. 진짜 치명적인 것은, 이 16000 토큰 중 70%가 세 턴 전에 이미 무관해진 잡담일 수 있다는 점이다.
최적화 방향은 슬라이딩 윈도우 + 요약 압축이다. 최근 N턴의 원문은 유지하고, 더 이전 대화는 경량 모델로 200 토큰 이내의 요약으로 압축한다. 우리 프로젝트에서는 윈도우를 '전체'에서 '최근 6턴 + 요약'으로 바꾸면서 단일 입력 토큰이 12000에서 3500 정도로 줄었고, 입력 비용은 곧바로 70% 삭감됐다. 주의할 점은 요약 자체도 저렴한 모델로 돌려야 한다는 것이다. 플래그십 모델로 요약하면 절약이 안 된다.
함정 2: 플래그십 모델로 허드렛일 시키기
가장 흔하고도 가장 억울한 낭비다. 의도 분류, 감정 판단, 콘텐츠 요약, 형식 변환 같은 작업은 DeepSeek-V3나 Qwen-Max로도 95% 이상의 정확도를 낼 수 있는데, 많은 팀이 편하려고 전부 Claude 4 Sonnet이나 GPT-4o로 돌린다. 가격 차이는 얼마나 날까? 플래그십 모델의 입력 단가는 경량 모델의 10~20배에 달한다.
모델 계층형 호출의 핵심은 라우팅이다. 작업이 들어오면 자동으로 복잡도를 판단해서, 분류는 경량 모델로, 복잡한 추론만 플래그십으로 보낸다. SiCore TokenWorks는 작업별로 최적 모델을 자동 선택하도록 지원하며, 우리 프로젝트에서 사용해본 결과 분류 작업을 경량 모델로 전환한 후 비용이 확실히 줄었다. 이런 AI API 집계 플랫폼의 가치는 각 모델마다 별도의 SDK와 Key를 유지보수할 필요 없이, 하나의 OpenAI 호환 인터페이스로 전환할 수 있다는 점이다. 아래는 최소 변경 예시다.
from openai import OpenAI
client = OpenAI(
api_key="your-token8341-key",
base_url="https://api.token8341.com/v1" # 한 줄만 바꾸면 OpenAI SDK 호환
)
# 경량 작업은 저렴한 모델로
resp = client.chat.completions.create(
model="deepseek-v3",
messages=[{"role": "user", "content": "이 댓글의 감정을 판단해줘: 배송은 빠른데 포장이 파손됨"}],
max_tokens=16
)
print(resp.choices[0].message.content)라우팅 전략은 우선 규칙 기반으로 시작할 수 있다. 작업 유형에 태그를 붙여서 분류/요약/추출은 경량으로, 코드 생성/복잡한 추론은 플래그십으로 보낸다. 한동안 운영한 뒤 각 모델의 실제 적중률을 통계 내서 조정하라. 처음부터 복잡한 시맨틱 라우팅을 도입하지 마라. 유지보수 비용이 절약한 돈보다 더 클 수 있다.
함정 3: 통제 불능의 재시도 메커니즘
타임아웃 재시도는 보이지 않는 증폭기다. 많은 SDK가 기본적으로 2~3회 재시도하는데, 타임아웃 임계값을 너무 짧게(예: 10초) 설정했는데 실제 P99 지연이 25초라면, 대량의 요청이 타임아웃 후 재시도되어 한 번의 호출이 세 번이 된다. 더 나쁜 것은 재시도 요청 자체도 동시성을 차지해서 속도 제한을 유발할 수 있고, 속도 제한이 다시 재시도를 유발해 설원(雪崩)을 형성한다는 점이다.
우리도 한 번 겪었다. 어떤 인터페이스의 P99 지연이 28초인데 타임아웃을 15초로, 재시도를 3회로 설정해서 실제 호출량이 비즈니스量的 2.4배였다. 이후 타임아웃 임계값을 P99에서 30% 상향 설정하고, 재시도는 지수 백오프에 최대 1회로 변경해서 호출량이 1.1배로 떨어졌다. 또한 재시도는 오류 유형을 구분해야 한다. 429와 5xx만 재시도하고, 400 파라미터 오류는 만 번 재시도해도 소용없다.
함정 4: 사용량 집계와 알림 부재
가장 근본적인 문제다. 많은 팀이 프로젝트나 Key 단위로 대략적으로 통계 내지만, 구체적으로 어떤 기능, 어떤 사용자, 어떤 Prompt가 돈을 태우는지는 모른다. 청구서가 나와서야 특정 테스트 환경의 Key가 꺼지지 않았다거나, 특정 사용자의 초장문 세션이 예산을 다 써버린 것을 발견한다.
방법은 차원별로 태그를 붙이는 것이다. 매 호출에 team, feature, user_id 세 가지 태그를 달아 로그나 시계열 DB에 적재한다. AI API 게이트웨이를 통합 진입점으로 사용하는 장점이 바로 여기에 있다. 모든 호출이 한 계층의 프록시를 거치면서 태그와 사용량 집계가 게이트웨이 측에서 완료되므로, 각 비즈니스 주체의 코드를 수정할 필요가 없다. 알림 임계값은 두 단계로 설정할 것을 권한다. 일일 사용량이 예산의 60%에 도달하면 경고, 85%에 도달하면 다운그레이드(예: 비핵심 기능을 자동으로 경량 모델로 전환)를 트리거한다.
비용 비교와 선정 참고
위 네 가지를 실행에 옮긴 후, 우리는 세 가지 접속 방식을 비교했다. 공식 직접 연결 단일 모델, 자체 구축 라우팅, 집계 플랫폼. 공식 직접 연결은 가장 간편하지만 모델 계층화를 할 수 없어 비용이 경직된다. 자체 구축 라우팅은 유연하지만 여러 Key, 여러 SDK, 여러 과금 로직을 유지보수해야 해서 두 사람-달이 기본이다. 집계 플랫폼은 모델 전환과 사용량 집계에 기성 능력을 갖추고 있어 사용량 기반 과금으로 비용이 더 우수하다. 선정 시 세 가지를 중점적으로 봐야 한다. OpenAI SDK 호환 여부(마이그레이션 비용), 국산 모델 전면 지원 여부(규정 준수와 비용), 사용량 집계 인터페이스 보유 여부(관측 가능성).
비용 최적화는 일회성이 아니라 지속적인 관측과 조정의 과정이다. 먼저 사용량 집계를 구축해서 돈이 어디에 쓰이는지 명확히 파악한 다음, 컨텍스트, 모델 계층화, 재시도 전략을 항목별로 최적화하라. 순서를 바꾸지 마라. 그렇지 않으면 한참 최적화했는데 정작 큰 비중을 차지하는 부분이 아닐 수 있다.
작성자: 천징싱
발행일: 2026년 10월 3일