눈물 없이 AI API 비용을 절감하는 개발자 가이드

지난 3월 월요일 아침, 우리 팀의 LLM (Large Language Model) 결제 대시보드를 열었다가 커피를 뿜을 뻔했습니다. 한 달 만에 11,400달러를 지출했기 때문입니다. 분기 초에 예상했던 금액의 세 배였습니다. 저는 백엔드 엔지니어이지 재무 담당자는 아니지만, 그래프의 그 선이 좋은 방향으로 향하고 있지 않다는 것만큼은 누구나 알 수 있었습니다.

그 후 3주 동안 집요한 비용 절감 작업과 몇 차례의 내부 RFC (Request for Comments) (언제나 그렇듯 RFC 9457이 등장했습니다)가 이어졌고, 우리가 거의 1년 동안 AI 통합을 아주 비싼 방식으로 해왔다는 사실을 깨달았습니다. 참고로 (fwiw), 원인은 평소와 다름없었습니다. 저항이 가장 적은 경로라는 이유로 모든 것에 GPT-4o를 기본값으로 설정해 두었고, 더 저렴한 모델들이 똑같이 업무를 수행할 수 있는지 측정해보려는 시도조차 아무도 하지 않았던 것입니다.

그 11,400달러의 청구서는 다음 달 말까지 1,830달러로 떨어졌습니다. 정확히 어떻게 했는지 그 방법을 공개합니다.

모델 품질에 대해 스스로에게 해온 거짓말

전술을 설명하기 전에 짚고 넘어가야 할 것이 있습니다. 지난 1~2년 동안 프로덕션 환경에 AI 기능을 배포해 왔다면, 여러분은 아마 "거대 모델이 항상 더 좋다"라는 직관을 갖게 되었을 것입니다. 프로토타입을 만들고 MVP (Minimum Viable Product)를 출시할 때는 유용한 휴리스틱 (Heuristic)일 수 있습니다. 하지만 규모가 커지면 이는 값비싼 거짓말이 됩니다.

저는 이를 경험적으로 테스트했습니다. 우리 프로덕션 트래픽에서 추출한 2,000개의 대표 프롬프트를 GPT-4o와 일련의 저렴한 대안 모델들에 모두 실행해 보았습니다. 분류 (Classification), 요약 (Summarization), 단순 채팅, FAQ 응답, 심지어 대부분의 코드 생성에 이르기까지 대다수의 작업에서 품질 차이는 인간의 선호도 오차 범위 내에 있었습니다. 즉, 블라인드 테스트에서 아무도 차이를 느낄 수 없는 요청이 85~95%에 달했다는 뜻입니다.

거대 모델이 정말로 중요한 나머지 5~15%의 경우는 어떻게 할까요? 바로 그 지점에서 계층적 라우팅 (Tiered Routing)이 등장합니다. 하지만 그전에, 가장 큰 성과를 거둔 전략부터 이야기해 보겠습니다.

전략 1: "안녕"이라고 말하기 위해 100만 토큰당 10달러짜리 모델을 사용하지 마세요

가장 쉽고 빠르게 얻을 수 있는 성과이자, 우리에게 가장 많은 비용을 절감해 준 것은 바로 작업에 적합한 모델을 선택하는 것이었습니다. 당연한 소리처럼 들릴 수도 있습니다. 하지만 숫자를 자세히 들여다보면 거의 부끄러울 정도로 당연한 사실입니다.

우리가 실제로 적용한 사례는 다음과 같으며, 이는 업계 전반에서 제가 목격하는 흐름과 대략적으로 일치합니다:

유스케이스 (Use Case)	기존 사용 모델	현재 사용 모델	절감액
단순 채팅 (Simple chat)	GPT-4o ($10/M out)	DeepSeek V4 Flash ($0.25/M out)	97.5%
...

정교한 라우팅 (Routing)이나 캐싱 (Caching) 같은 복잡한 기술 없이, 단순히 이 방식만 전면적으로 적용했을 뿐인데도 우리의 지출은 $11,400에서 약 $2,900로 줄어들었습니다. 이것만으로도 75%의 비용 절감이 이루어졌습니다. 제 개인적인 의견으로는, 만약 이 글에서 다른 것은 아무것도 하지 않더라도 이것만큼은 꼭 실행하시길 권합니다.

현재 우리 서비스에 적용된 라우팅 로직은 다음과 같습니다:

import httpx
import os

...

global-apis.com/v1 베이스 URL (base URL)에 주목하세요. 우리는 모든 요청을 하나의 제공업체(Provider)를 통해 라우팅합니다. 이렇게 하면 다섯 군데의 서로 다른 벤더(Vendor)와 계약을 다시 협상할 필요 없이 모델을 교체할 수 있습니다. 내부적으로는 단순히 OpenAI 호환 엔드포인트 (OpenAI-compatible endpoint)이므로, 코드는 OpenAI를 직접 대상으로 작성할 때와 동일하게 보입니다.

전략 2: 계층형 라우팅 (Tiered Routing) — "저렴한 모델 시도, 실패 시 에스컬레이션" 패턴

모델 선택을 통해 대부분의 성과를 거둔 후, 그다음으로 큰 승부수는 계층형 라우터 (Tiered router)였습니다. 아이디어는 간단합니다. 모든 요청을 작동할 가능성이 있는 가장 저렴한 모델로 보내고, 저렴한 품질 검사 (Quality check)를 수행한 뒤, 저렴한 모델이 실패했을 경우에만 더 비싼 모델로 에스컬레이션 (Escalate)하는 것입니다.

몇 번의 반복 과정을 거쳐 제가 최종적으로 도출한 패턴은 다음과 같습니다:

def smart_generate(prompt: str, budget_tier: str = "auto") -> str:
    """
    Tier 1: Qwen3-8B ($0.01/M)가 트래픽의 약 80%를 처리
...

네, 품질 검사 자체에도 비용이 듭니다. 네, 지연 시간 (Latency)도 추가됩니다. 하지만 답변을 채점하기 위해 $0.01/M를 사용하는 것은, "가게 문 언제 열어요?" 같은 질문에 $2.50/M짜리 추론 (Reasoning) 호출을 낭비하는 것에 비하면 여전히 터무니없이 저렴합니다.

저희는 이를 고객 지원 챗봇에 배포했고, 월 $420였던 청구액이 $28로 떨어지는 것을 목격했습니다. 오타가 아닙니다. 비결은 들어오는 쿼리의 85%가 매우 단순한 FAQ 스타일의 질문이었고, 이는 Qwen3-8B가 거의 공짜에 가까운 비용으로 완벽하게 처리할 수 있다는 점이었습니다.

전략 3: 공격적으로 캐싱하고, 신중하게 무효화하기

캐싱(Caching)은 세 번째 지지대이며, 대부분의 팀이 가장 투자를 적게 하는 부분입니다. 제 생각에 그 이유는 "LLM을 위한 응답 캐싱 (response caching for LLMs)"이라는 개념이 지적으로 의심스럽게 들리기 때문입니다. '모든 요청은 고유할 것이고, 창의적인 출력물은 캐싱할 수 없으며, 이것이 큰 도움이 되지 않을 것'이라고 생각하니까요.

하지만 실제 트래픽 패턴을 살펴보면, 요청의 30~50%가 이미 처리했던 요청과 거의 중복된다는 사실을 발견하게 됩니다. FAQ 쿼리, 문서 조회, 표준적인 상용구(Boilerplate) 등이 이에 해당합니다. "비밀번호 재설정해 주세요.", "영업시간이 어떻게 되나요?"와 같이 하나의 정형화된 답변(Canonical answer)이 존재하는 것들 말이죠.

제가 작성한 캐시 레이어는 다음과 같습니다. 복잡한 Redis 없이, 시작 단계에서는 단순히 인메모리 딕셔너리(in-memory dict)를 사용했습니다:

import hashlib
import json
import time
...

저희의 경우, FAQ 비중이 높은 엔드포인트에서 이 방식의 적중률이 50~80%에 달했습니다. 1시간의 TTL(Time-To-Live)을 시작점으로 잡았는데, 문서 조회용으로는 24시간으로 늘렸고, 채팅 대화용으로는 5분으로 설정했습니다. 여러분의 실제 데이터 신선도 허용 범위(Staleness tolerance)에 맞춰 조정하세요.

만약 멀티 인스턴스(Multi-instance) 환경을 운영 중이라면, 딕셔너리를 Redis로 교체하면 됩니다. 패턴은 변하지 않습니다.

전략 4: 전송 전 프롬프트(Prompt)를 압축하기

이것은 아무도 이야기하지 않는 부분이며, 제가 가장 기묘한 비용 절감 효과를 발견한 지점이기도 합니다. 우리 대부분은 프롬프트 길이를 비용 변수가 아닌 품질 변수로 생각합니다. 하지만 모든 입력 토큰(Input token)은 비용이 청구됩니다. 하루에 10,000번 전송되는 2,000토큰짜리 시스템 프롬프트(System prompt)는 _실제 돈_입니다.

기술적 방법: 긴 컨텍스트(Context)를 먼저 저렴한 모델에 통과시켜 압축된 버전을 얻은 다음, 그 압축된 버전을 전송하는 것입니다. 약간의 뉘앙스는 손실될 수 있지만, 특정 정보를 추출하기 위해 더 강력한 모델에 컨텍스트를 제공하는 종류의 작업에서는 대개 모든 단어가 필요하지 않습니다.

def compress_prompt(text: str, target_ratio: float = 0.5) -> str:
    """더 강력한 모델로 보내기 전에 긴 프롬프트 (prompt)를 축소합니다."""

...

이를 구체적인 숫자로 보여드리겠습니다. 2,000 토큰 (token) 프롬프트를 400 토큰으로 압축하면 DeepSeek V4 Flash 사용 시 요청당 0.024달러를 절약할 수 있습니다. 사소해 보일 수 있습니다. 하지만 이를 하루 10,000건의 요청으로 곱해 보십시오. 단 *하나의 프롬프트 템플릿 (prompt template)*만으로 하루에 240달러, 즉 연간 87,600달러를 절약하게 됩니다. 제가 감사를 실시했을 때, 이와 유사하게 비대해진 프롬프트 템플릿이 세네 개 더 있었습니다. 절감액은 복리로 쌓였습니다.

요청당 15~30%의 감소는 실질적이며, 이는 다른 모든 절감 요소 위에 중첩되어 적용됩니다.

전략 5: 공격적인 배치 (Batch) 처리

마지막으로 다루고 싶은 기술은 배치 (batching)입니다. 작업들이 독립적일 때 여러 요청을 하나의 API 호출로 결합하는 방식입니다. 이는 야간 보고서 생성, 대량 분류 (bulk classification), 로그 분석 (log analysis)과 같은 오프라인/비동기 (async) 워크로드에 특히 효과적입니다.

이 방식의 이점은 시스템 프롬프트 (system prompt)와 공유되는 모든 컨텍스트 (context)가 N번이 아닌 단 한 번만 과금된다는 사실에서 옵니다. 만약 500 토큰의 시스템 프롬프트가 있고 50개의 질문을 하나의 호출로 배치 처리한다면, 해당 오버헤드 (overhead)를 50으로 나눈 셈이 됩니다.

def batch_classify(questions: list[str], categories: list[str]) -> list[str]:
    """N번의 호출 대신 한 번의 API 호출로 많은 항목을 분류합니다."""

...

우리는 배치 ETL 파이프라인 (ETL pipelines)에서 10~20%의 비용 감소를 얻었습니다. 극적인 수치는 아니지만, 공짜 돈은 언제나 환영입니다.

결합된 효과

동일한 워크로드에 대해 다섯 가지 전략을 모두 적용하기 전과 후의 월간 청구서가 어떻게 변했는지 보여드리겠습니다:

지표	적용 전	적용 후
월간 지출	$11,400	$1,830
...	...	...

지연 시간 (latency) 개선은 기분 좋은 놀라움이었습니다. 모든 것을 느린...