프로덕션 LLM 서비스를 운영하면서 가장 먼저 깨달은 건, 비용 문제는 모델 성능이 아니라 호출 패턴에서 터진다는 점이었다. 모델을 바꾸거나 프롬프트를 쥐어짜기 전에, 요청 자체를 들여다봐야 한다.
비싼 모델한테 잡일을 시키고 있었다
서비스를 론칭했을 때는 모든 요청을 GPT-4급 모델로 보냈다. 당연하다고 생각했다. 답변 품질이 곧 서비스 품질이니까. 그런데 3개월쯤 운영하고 나서 로그를 까보니 충격적인 숫자가 나왔다.
전체 요청의 약 80%가 "날씨 알려줘", "이거 요약해줘", "이메일 초안 써줘" 같은 단순 작업이었다. Haiku급 경량 모델로도 충분히 처리 가능한 수준. 나머지 20%만이 복잡한 추론이나 멀티스텝 분석을 요구하는 요청이었다.
월 청구서로 환산하면? 전체 예산의 80%를 사실상 과잉 스펙 모델에 태우고 있었던 거다. 이건 기술 문제가 아니라 설계 문제였다.
라우팅: 분류기 하나로 60%가 날아갔다
해결의 첫 단추는 의외로 단순했다. 요청이 들어오면 경량 분류기로 복잡도를 먼저 판단하고, 적절한 티어의 모델로 보내는 구조다.
def route_request(query: str) -> str:
complexity = classify_complexity(query)
if complexity == "simple":
return "haiku"
elif complexity == "medium":
return "sonnet"
else:
return "opus"코드 자체는 별 거 없다. 문제는 분류기의 정확도였다. 처음에 키워드 매칭으로 대충 만들었더니 오분류율이 15%나 됐다. "이 계약서 리스크 분석해줘"가 단순 질의로 빠지는 식. 계약서라는 단어만 보고 정형 업무로 판단해버린 거다.
결국 2주 동안 로그에서 샘플 3천 건을 뽑아 레이블링하고, 경량 BERT 기반 분류기를 파인튜닝했다. 오분류율이 3% 아래로 떨어졌고, 그제서야 라우팅이 제대로 동작하기 시작했다. 이것만으로 비용이 약 60% 줄었다. 트래픽 대부분이 저비용 모델로 빠지니까 산술적으로 당연한 결과다.
한 가지 교훈이 있다면 — 분류기를 만드는 건 하루면 되는데, 분류 기준을 정의하는 데 일주일이 걸렸다. "medium이랑 hard의 경계가 뭔데?"라는 질문에 팀원 다섯 명이 다섯 가지 답을 내놓는다. 기준이 명확하지 않으면 분류기 성능도 들쭉날쭉이다.
시맨틱 캐싱으로 반복 호출 잡기
라우팅 다음 타겟은 반복 요청이었다. 로그를 뜯어보니 의미적으로 동일한 질문이 하루에 수천 건씩 들어오고 있었다. "환불 정책이 어떻게 되나요?"와 "환불 어떻게 해요?"는 글자는 다르지만 원하는 답은 같다.
시맨틱 캐싱을 붙였다. 요청을 임베딩 벡터로 변환하고, 기존 캐시 항목과의 코사인 유사도가 임계값 이상이면 저장된 응답을 그대로 반환하는 구조다.
여기서 삽질 하나. 처음에 임계값을 0.90으로 잡았더니 "영수증 재발행 요청"과 "세금계산서 발행 방법"이 같은 캐시를 타는 사고가 났다. 임베딩 공간에서 두 문장이 꽤 가깝게 찍힌 거다. 0.95로 올리니까 이런 오탐이 사라졌고, 캐시 적중률은 여전히 30% 이상을 유지했다.
캐싱으로 추가 15% 절감. 라우팅과 합산하면 누적 약 70%.
배칭: 급하지 않은 건 모아서
마지막은 배치 처리다. 리포트 생성, 대량 분류, 야간 로그 분석처럼 실시간 응답이 필요 없는 작업들을 큐에 넣고 한꺼번에 돌렸다. OpenAI Batch API 기준으로 50% 할인이 적용되고, 응답은 24시간 이내 보장이라 비동기 작업에는 안성맞춤이다. 전체 워크로드의 약 25%가 이 범주에 해당했고, 추가로 7~10% 절감 효과가 나왔다.
숫자로 보면 이렇다
| 최적화 단계 | 개별 절감 | 누적 |
|---|---|---|
| 모델 라우팅 | ~60% | 60% |
| 시맨틱 캐싱 | ~15% | 70% |
| 배치 처리 | ~7-10% | 77% |
모델을 교체하거나 프롬프트를 극단적으로 압축한 게 아니다. 요청을 적절한 곳으로 보내고, 같은 질문에 같은 답을 반복 생성하지 않고, 급하지 않은 건 모아서 처리한 것뿐이다.
그런데 솔직히 말하면, 이 작업에서 기술 구현보다 오래 걸린 게 있다. 팀 내 합의다. PM은 전부 최고 모델을 원하고, 인프라팀은 비용을 깎고 싶어 하고, QA는 품질 저하를 걱정한다. 결국 A/B 테스트를 2주 돌려서 "경량 모델로 라우팅해도 사용자 만족도 점수에 유의미한 차이가 없다"는 데이터를 내밀고 나서야 합의가 됐다. 기술보다 설득이 어려운 건 여기서도 마찬가지였다.