토큰은 곧 비용입니다. 모델 라우팅, 캐시, 요약 압축을 어떤 순서로 붙였을 때 실제 청구액이 줄었는지 숫자로 남겼습니다.
이 글은 실제 운영 중인 사내 서비스의 6개월치 기록을 정리한 것입니다. 수치는 조직 상황에 따라 달라질 수 있습니다.
1. 문제 정의부터 다시 했습니다
처음 받은 요구사항은 "비용을 줄여 달라"는 한 줄이었습니다. 그대로 착수하면 결국 모델을 싼 것으로 바꾸는 선택밖에 남지 않습니다. 그래서 먼저 어떤 요청이 얼마를 쓰고 있는지 나누는 일부터 시작했습니다. 팀, 기능, 모델 세 축으로 태그를 붙이자 상위 다섯 개 기능이 전체 비용의 절반 이상을 쓰고 있다는 사실이 드러났습니다.
측정 없이 최적화하지 않기
게이트웨이에 요청·응답 토큰 수와 지연 시간을 남기는 데는 하루가 걸렸습니다. 그 하루로 이후 5주의 방향이 정해졌으니 가장 수익률이 높은 작업이었습니다.
- 요청 단위 태깅: 팀 / 기능 / 모델 / 프롬프트 버전
- 일 단위 집계와 주 단위 리포트 자동 발송
- 예산의 80%를 넘기면 슬랙 채널로 알림
2. 라우팅은 품질 기준을 먼저 정하고 붙였습니다
작은 모델로 내려보내는 일 자체는 어렵지 않습니다. 어려운 것은 "어디까지 내려보내도 괜찮은가"를 정하는 일이었습니다. 기능별로 30문항짜리 평가 세트를 만들고, 통과율이 기준선 아래로 떨어지면 자동으로 상위 모델로 되돌리는 장치를 함께 넣었습니다.
3. 캐시는 마지막에 붙였습니다
캐시를 먼저 붙이면 효과가 커 보이지만, 프롬프트가 자주 바뀌는 초기에는 적중률이 낮고 무효화 버그만 늘어납니다. 프롬프트 버전이 안정된 뒤에 붙이자 적중률이 눈에 띄게 올라갔습니다.
정리
비용 통제는 한 번의 큰 결정이 아니라 측정 → 분리 → 기준 수립 → 자동화의 반복이었습니다. 같은 고민을 하는 팀이 있다면 첫 주는 반드시 측정에만 쓰시길 권합니다.
댓글 3
이서연2026.09.11
게이트웨이 레이어에서 모델 라우팅을 먼저 붙인 순서가 특히 참고됐습니다. 캐시 적중률은 어느 정도까지 올라갔는지 궁금합니다.
김도현2026.09.11
저희도 비슷하게 도입했는데 요약 압축 단계에서 품질 이슈가 있었습니다. 평가 세트를 어떻게 구성하셨는지 공유해 주시면 좋겠습니다.
정태민2026.09.12
비용 대시보드 스크린샷이 인상적이네요. 팀 단위 예산 알림은 어떤 기준으로 잡으셨나요?
댓글은 운영팀 확인을 거쳐 게시됩니다.


