모델 품질은 유지하면서 LLM 비용을 절감한 방법
Source: Dev.to
문제 개요
프로덕션 환경에서 AI 시스템을 가장 빠르게 망가뜨리는 방법 중 하나는 제어되지 않은 토큰 증가입니다. 대부분의 데모는 작은 프롬프트를 깨끗한 데이터셋에 실행하기 때문에 이 문제를 무시합니다. 하지만 실제 기업 시스템은 그렇지 않습니다. 여러 통합이 동시에 실행되면 토큰 사용량이 대부분 팀이 예상하는 것보다 빠르게 증가합니다.
증상
- 정확한 응답에도 불구하고 프롬프트 크기가 증가
- 데이터에 잡음 (중복된 대화 기록, 겹치는 검색 청크, 불필요한 메타데이터, 오래된 실행 추적, 반복되는 시스템 지시문, 임시 도구 출력)
- 응답 품질은 거의 변하지 않는데 비용이 상승
이 문제들은 여러 기업 파이프라인이 동시에 가동되면서 나타났습니다. Slack 수집, 이메일 동기화, CRM 업데이트, 회의 전사, 내부 티켓 시스템, 지식베이스 동기화 작업 등이 동일한 운영 AI 레이어에 입력되었습니다.
아키텍처 변경
전처리 레이어
프롬프트 조합 전에 전처리 단계를 도입했습니다. 이제 모든 검색 결과는 다음 과정을 거칩니다:
- 의미 기반 중복 제거
- 겹침 제거
- 메타데이터 정리
- 토큰 예산 관리
- 컨텍스트 우선순위 지정
이 덕분에 프로덕션 워크로드 전반에서 프롬프트 크기가 즉시 감소했으며, 출력 품질은 거의 동일하게 유지되었습니다.
메모리 분리
대부분의 AI 시스템은 모든 상태를 하나로 섞어 놓습니다 (채팅 기록, 도구 출력, 실행 로그, 재시도 추적, 검색 데이터, 감사 메타데이터). 모델이 추론에 필요한 것은 이 전체가 아니므로 메모리를 두 계층으로 나누었습니다:
- 운영 메모리 – 재시도, 실행 추적, 감사 로그, 시스템 메타데이터 등 인프라 상태를 저장
- 추론 메모리 – 추론에 필요한 정보만 저장
이 분리를 통해 컨텍스트 오염이 줄어들었고, 인프라 관련 내용이 모델 추론에 섞이지 않아 디버깅이 쉬워졌습니다.
프롬프트 최적화
큰 프롬프트는 생산적이라고 느껴지지만 실제로는 그렇지 않은 경우가 많습니다. 시간이 지나면서 시스템 프롬프트가 서로 다른 표현으로 동일한 지시를 반복해 토큰 수만 늘리고 신뢰성을 높이지 않는 것을 발견했습니다.
프롬프트 로직을 더 추가하기보다 제어를 인프라 로직으로 옮겼습니다:
- 구조화된 검증 레이어
- 스키마 강제 적용
- 라우팅 제약
- 도구 권한 경계
- 결정론적 실행 규칙
그 결과 프롬프트는 작아졌고 동작은 더 예측 가능해졌으며, 운영 제어가 모델에서 인프라로 이동했습니다.
관측 가능성
토큰 관측이 없으면 비용 문제는 몇 주 동안 보이지 않습니다. 이제 우리는 다음을 추적합니다:
- 테넌트별 토큰 사용량
- 통합별 토큰 사용량
- 검색 확장 비율
- 평균 컨텍스트 성장률
- 배포 후 비정상적인 비용 급증
예를 들어, 한 배포에서 직렬화기가 전체 API 페이로드를 대화 상태에 삽입하면서 토큰 사용량이 세 배가 되었습니다. 시스템은 동작했지만 관측이 없었다면 큰 청구 증가가 발생한 뒤에야 문제를 알 수 있었을 것입니다.
결론
대부분의 기업 AI 비용 문제는 모델 문제가 아니라 아키텍처 문제입니다. 비용이 많이 드는 부분은 보통 추론 자체가 아니라:
- 부실한 메모리 설계
- 제어되지 않은 검색
- 중복된 컨텍스트
- 과도한 프롬프트
- 약한 운영 경계
낭비를 줄이는 것이 모델을 계속 바꾸는 것보다 더 중요합니다. 우리는 품질을 낮추지도, 공급자를 바꾸지도 않았습니다. 모델 주변 인프라를 개선함으로써 시스템의 경제성을 어느 프롬프트 최적화보다 크게 바꿨습니다.