품질 저하 없이 AI API 비용을 70% 절감한 방법

몇 달 전, 저는 고객 지원 문의를 처리해야 하는 고객을 위한 챗봇을 구축하고 있었습니다. 요구 사항은 간단했습니다. 일반적인 질문에 답하고, 복잡한 문제는 에스컬레이션(escalate)하며, 지연 시간(latency)을 2초 미만으로 유지하는 것이었습니다. 저는 사용하기 쉬운 OpenAI의 API로 시작했지만, 일주일간의 테스트 후 청구 금액은 이미 세 자릿수로 치솟고 있었습니다. 그때 저는 단순히 돈을 더 쏟아붓는 것이 아니라, 더 스마트한 아키텍처(architecture)가 필요하다는 것을 깨달았습니다.

문제점: 모든 쿼리(query)에는 비용이 발생한다

저는 사용자들이 묻는 질문의 80%를 커버하는 약 200개의 일반적인 지원 질문 목록을 가지고 있었습니다. 하지만 저의 미숙한 구현 방식은 모든 사용자 메시지를 GPT-4로 전송했습니다. 프롬프트 캐싱(prompt caching)과 토큰(token) 감소를 적용했음에도 불구하고, 각 대화는 턴(turn)당 0.03~0.10달러의 비용을 발생시켰습니다. 이를 수백 명의 사용자로 곱하면 빠르게 지속 불가능한 수준이 되었습니다.

더 큰 문제는 지연 시간(latency)이었습니다. "영업 시간이 어떻게 되나요?"와 같은 간단한 질문에 대해서도 API로의 전체 왕복(round-trip)에 1~3초가 소요되었습니다. 사용자들은 회전하는 로딩 바가 아니라 즉각적인 답변을 기대했습니다.

시도했지만 실패했던 방법들

첫째, 더 저렴한 모델(GPT-3.5 Turbo)을 사용하는 것을 시도했습니다. 비용은 80% 감소했지만, 정확도가 떨어졌습니다. 모델이 지침을 환각(hallucinate)하거나 오래된 정보를 제공하는 경우가 빈번했습니다. 고객들의 불만이 이어졌습니다.

그 다음에는 정확한 키워드 매칭(keyword matching)을 사용하는 하드코딩된 FAQ를 구축했습니다. 빠르고 무료였지만, 오타, 유의어, 그리고 의역된 질문에는 대응하지 못했습니다. 유지보수도 악몽 같았습니다. 단 하나의 새로운 Q&A를 추가하더라도 기존 로직과 업데이트를 병합해야 했습니다.

또한 단순한 임베딩(embeddings) + 코사인 유사도(cosine similarity, 의미론적 검색)를 실험해 보기도 했습니다. 검색(retrieval)에는 괜찮았지만, 멀티턴(multi-turn) 대화나 "주문에 문제가 있어요"와 같은 모호한 쿼리를 처리할 수는 없었습니다. 사용자들에게는 여전히 LLM으로의 폴백(fallback)이 필요했습니다.

마침내 성공한 방법: 하이브리드 접근 방식

며칠 동안 논문과 GitHub 저장소(repos)를 읽은 끝에, 저는 많은 프로덕션 시스템(production systems)에서 사용하는 패턴에 도달했습니다. 바로 단순한 쿼리(queries)는 로컬 또는 경량 모델로 라우팅(route)하고, 꼭 필요한 경우에만 전체 클라우드 LLM으로 에스컬레이션(escalate)하는 방식입니다.

아키텍처는 다음과 같습니다:

규칙 기반 분류기 (Rule-based classifier) – 의도(intent)를 태깅하는 아주 작은 정규 표현식(regex) + 키워드 매퍼(keyword mapper)입니다 (예: "영업 시간", "환불", "배송 추적"). 정확히 일치하는 항목과 일반적인 패턴을 즉시 잡아냅니다.
소형 로컬 모델 폴백 (Small local model fallback) – 정확히 일치하지 않는 의도에 대해서는, Ollama를 통해 로컬에서 실행되는 작은 양자화 모델(quantized model, 예: Llama 3.2 1B 또는 Phi-3-mini)을 사용합니다. 이는 거의 제로에 가까운 비용과 1초 미만의 지연 시간(latency)으로 의역(paraphrases)과 오타를 처리합니다.
최후의 수단으로서의 클라우드 API (Cloud API as last resort) – 로컬 모델이 신뢰도(confidence)가 낮다고 표시하거나, 명시적으로 "복잡함"으로 태깅된 쿼리만 OpenAI/GPT-4로 전송됩니다.

코드: 하나로 합치기

다음은 라우터(router)의 단순화된 Python 버전입니다. 저는 이를 FastAPI 엔드포인트(endpoint)에서 사용합니다.

import re
import json
from typing import Optional
...

배운 점과 트레이드오프 (trade-offs)

비용 (Cost): 제 청구 금액이 주당 약 $200에서 약 $60로 줄었습니다. 쿼리의 대부분(약 70%)은 규칙 엔진(rule engine) 또는 로컬 모델이 처리합니다. 오직 10%만이 클라우드 API에 도달합니다. (나머지 20%는 여전히 비용이 발생하는 오분류(misclassifications)이지만, 이는 감내할 만한 수준입니다.)

지연 시간 (Latency): 규칙 기반 답변은 5ms입니다. 로컬 모델은 300~~500ms입니다. 클라우드는 1~~3초입니다. 대부분의 쿼리가 빠르기 때문에 사용자는 느린 경로를 거의 눈치채지 못합니다.

정확도 (Accuracy): 로컬 모델(Phi-3-mini)은 단순한 고객 지원 작업에 놀라울 정도로 뛰어나지만, 가끔 잘못된 정보(예: 실제로는 지원하지 않는데 "네, 비트코인을 받습니다"라고 답변하는 경우)를 제공합니다. 이를 완화하기 위해 답변 길이와 완곡한 표현(hedging words)을 기반으로 한 신뢰도 휴리스틱(confidence heuristic)을 추가했습니다. 완벽하지는 않지만, 오류를 약 10%에서 약 3%로 줄여줍니다.

유지보수 (Maintenance): 규칙 세트는 시간이 지남에 따라 늘어나지만, 플랫 파일(flat file) 형태라 편집하기 쉽습니다. 비즈니스가 변경되면(예: 신제품 출시) 로컬 모델은 주기적인 업데이트가 필요합니다. 클라우드 모델은 그대로 유지됩니다.

다음에 다시 한다면 다르게 할 점

더 나은 로깅 (Better logging): 처음부터 모든 경로에 계측 (instrumentation)을 해두었더라면 좋았을 것입니다. 지금은 어떤 의도 (intents)가 잘못 라우팅되었는지 확인하기 위해 지표 (metrics)를 사후에 추가해야 합니다.
컷오프 (cutoff) A/B 테스트: 저의 신뢰도 임계값 (confidence threshold) 0.7은 추측에 불과했습니다. 비용과 정확도 사이의 최적의 균형을 찾기 위해 무작위 대조 실험 (randomized trial)을 수행했어야 합니다.
조잡한 신뢰도 휴리스틱 (confidence heuristic) 대신 전용 분류 모델 (dedicated classification model) 사용: 저의 의도 (intents)에 맞춰 미세 조정 (fine-tuned)된 아주 작은 BERT 분류기 (예: distilbert-base-uncased)를 사용했다면 더 신뢰할 수 있으면서도 실행 비용은 여전히 저렴했을 것입니다.

이 접근 방식을 사용하지 말아야 할 때

쿼리가 깊은 추론 (deep reasoning)이나 다단계 논리 (multi-step logic)를 요구한다면, 로컬 모델은 실패할 것입니다. 시도하지 마세요.
트래픽이 매우 낮다면 (하루 100개 미만의 쿼리), 하이브리드 시스템을 구축하는 비용이 그만한 가치가 없을 수 있습니다. 그냥 클라우드 API를 사용하세요.
지연 시간 (latency)이 문제가 되지 않는다면 (예: 밤샘 배치 처리), 단순함이 승리합니다. 하나의 모델만 고수하세요.

마치며

저는 머신러닝 엔지니어가 아닙니다. 그저 비용을 지불해야 했던 평범한 백엔드 개발자일 뿐입니다. 이 접근 방식은 최고 수준의 LLM 품질을 유지하면서도 비용을 감당할 수 있는 수준으로 만들어 주었습니다. 혁명적인 것은 아닙니다. 그저 적절한 도구를 사용하는, 좋은 엔지니어링일 뿐입니다.

한 가지 더 말씀드리자면, 저는 결국 소규모 대여 GPU 인스턴스 (월 40달러 정도의 서버)에 로컬 모델을 호스팅했습니다. 트래픽에 따라 에지 디바이스 (edge device)나 노트북을 사용할 수도 있습니다. 핵심은 폴백 경로 (fallback path)를 최대한 가볍게 유지하는 것입니다.

여러분의 설정은 어떠신가요? 클라우드 API에 올인하고 계신가요, 아니면 비용을 낮추는 영리한 하이브리드 방식을 찾으셨나요? 여러분의 라우팅 전략에 대해 듣고 싶습니다.