프로덕션 외 LLM 지출
업데이트 September 1, 2026 · 최초 게시 September 1, 2026
LLM 지출 검토는 늘 프로덕션 트래픽에서 시작합니다. 대시보드가 있는 것이 그것뿐이기 때문입니다. 그러나 환경별로 나눠 보면, 청구액의 상당한 부분 — 흔히 퍼센트로 두 자릿수 — 가 고객에게 한 번도 닿지 않았다는 사실이 드러납니다.
이 비용은 네 곳에서 생기며, 서로 겹치면서 커집니다.
프로덕션 외 지출의 출처
CI. 평가 스위트를 실행하는 모든 풀 리퀘스트가 모델을 호출합니다. 활발한 저장소에서 200개 케이스로 이루어진 스위트는 하루에 수천 번의 호출이며, 대개 가장 성능이 높은 모델을 씁니다. 스위트를 작성한 사람이 프로덕션을 반영하길 원했기 때문입니다.
로컬 개발. 프롬프트를 다듬는 엔지니어는 시간당 수십 번 API를 호출합니다. 보통 공유 키를 쓰고, 누구의 반복 작업인지 알 수 있는 태그도 없습니다.
스테이징과 데모 인스턴스. 장기간 운영되고 트래픽은 적지만, 프로덕션과 동일하게 설정되어 있습니다. 즉 비싼 모델을 쓰고 캐싱도 없으며, 아무도 지켜보지 않는 소수의 요청을 처리합니다.
테스트 중의 재시도와 폭주 루프. 프로덕션에서는 안전하게 실패하는 에이전트 루프도 특정 분기에서 잘못 동작하면 토큰을 계속 소모합니다. 테스트 환경에는 이를 감지하는 장치가 보통 없습니다.
비용을 줄이기 전에 귀속부터 고치세요
가장 확실하게 비용을 회수하는 변경은 환경마다 별도의 API 키를 두는 것입니다. 반나절이면 끝나며, 설명되지 않던 항목 하나가 라벨이 붙은 네 개의 항목으로 바뀝니다. 모든 요청에 환경을 태그하고, CI라면 저장소와 워크플로도 태그하세요. 그렇지 않으면 아래의 모든 제안은 추측에 불과합니다.
이것이 보이기 시작하면 보통 세 가지가 바로 뒤따릅니다. 프로덕션 외에서는 더 작은 모델이 거의 항상 충분합니다. 평가 스위트에는 높은 성능보다 일관성이 필요하며, 대부분 더 저렴한 모델을 고정해도 신호가 손실되지 않습니다. 또한 프로덕션 외는 캐싱의 효과가 가장 큰 곳입니다. CI는 거의 같은 프롬프트를 하루 종일 반복하기 때문입니다. 그리고 프로덕션 외는 엄격한 지출 상한을 실제로 안전하게 설정할 수 있는 곳입니다. 상한에 걸린 테스트 환경은 빌드를 실패시키지만, 상한에 걸린 프로덕션 환경은 고객을 실패시킵니다.
원칙
모든 프로덕션 외 환경에 자체 키, 자체 예산, 자체 상한을 부여하세요. 그런 다음 환경 간 차이를 분기별 검토에서 뒤늦게 발견하는 것이 아니라, 의도적으로 관리하는 숫자로 다루세요.
관련 글
관련 글
이 내용을 현재 스택에 적용하고 싶으신가요? 공급업체 청구서, 게이트웨이 로그, 주요 워크플로를 가져오시면 비용 요인과 절감 경로를 정리해드립니다. 무료 감사 예약 →