API 비용을 절감하기 위해 간단한 AI 프록시를 구축했습니다 — 제가 배운 점들

몇 달 전, 저의 OpenAI API 청구 금액이 한 달 만에 30달러라는 적당한 수준에서 150달러 이상으로 갑자기 급증했습니다. 저는 딱히 엄청난 일을 하고 있었던 것도 아니었습니다. 그저 내부 문서에 대한 질문에 답변하는 작은 Slack 봇을 실행하고 있었을 뿐입니다. 하지만 반복되는 프롬프트 (prompts), 실패한 재시도 (retries), 그리고 저 자신의 디버깅 쿼리 (debugging queries) 사이에서 토큰 (tokens)이 빠르게 쌓였습니다.

저는 먼저 뻔한 해결책들을 시도해 보았습니다. 클라이언트 측 캐싱 (client-side caching)을 추가하고, gpt-4에서 gpt-3.5-turbo로 전환하며, 심지어 저 자신에게 수동으로 속도 제한 (rate limits)을 거는 등의 방법이었습니다. 하지만 그 어떤 것도 지속되지 않았습니다. 사용자가 동일한 질문을 하더라도 표현을 약간씩 바꾸면 정확한 프롬프트를 캐싱하는 방식은 작동하지 않았습니다. 그리고 속도 제한은 봇을 느릿느릿하게 만들 뿐이었습니다.

그래서 저는 가벼운 AI 프록시 (AI proxy)를 구축했습니다. 제 앱과 LLM 제공업체 사이의 얇은 미들웨어 (middleware) 계층입니다. 화려하지는 않았지만, 그것은 즉각적으로 비용 누수를 막아주었습니다. 제가 무엇을 했는지, 그 과정에서 무엇을 망가뜨렸는지, 그리고 다음에 한다면 무엇을 다르게 할 것인지에 대한 솔직한 이야기를 들려드리겠습니다.

제가 시도했던 것들 (그리고 효과가 없었던 것들)

클라이언트 측 캐싱 (Client-side caching)

저는 메모리 내의 간단한 딕셔너리 (dictionary)로 시작했습니다: (prompt, model)을 키 (key)로, 응답 (response)을 값 (value)으로 저장하는 방식입니다. 정적인 FAQ 봇의 경우 아주 잘 작동합니다. 하지만 컨텍스트 (context)가 포함된 대화 스레드 (conversation threads)의 경우, 프롬프트는 결코 동일하지 않습니다. 사용자는 "환불 정책이 무엇인가요?"라고 물은 다음 "반품은 어떻게 되나요?"라고 묻습니다. 의도는 같지만 표현이 다릅니다. 매번 캐시 미스 (cache miss)가 발생합니다.

앱 측면에서의 속도 제한 (Rate limiting on the app side)

요청 사이에 time.sleep(0.5)를 추가했습니다. 이는 동시 접속 사용자가 없을 때까지는 작동하지만, 사용자가 동시에 접속하면 앱 전체가 차단됩니다. 세마포어 (semaphore) 기반의 스로틀링 (throttling)도 시도해 보았지만, 이는 Slack 봇을 반응이 없는 것처럼 느껴지게 만들었습니다. 사용자들은 답변을 받기 위해 5초를 기다리는 것을 싫어합니다.

모델 전환 (Switching models)

gpt-3.5-turbo로 낮추면 토큰당 비용은 절감되지만, 품질이 눈에 띄게 떨어졌습니다. 내부 문서용으로는 용인할 수 있는 수준이었지만, 고객 대상 답변용으로는 받아들일 수 없었습니다. 저에게는 더 스마트한 접근 방식이 필요했습니다.

결국 효과가 있었던 것: 캐싱, 속도 제한, 그리고 토큰 버퍼 (token buffer)를 갖춘 프록시

저는 FastAPI를 사용하여 작은 Python 서버를 작성했습니다 (Flask를 사용해도 무방합니다). 이 서버는 제 애플리케이션과 OpenAI API 사이에 위치합니다. 모든 요청은 프록시(proxy)를 거치게 되며, 프록시는 다음 세 가지 작업을 수행합니다:

1. 응답 캐싱 (Caches responses) — 단순히 정확히 일치하는 경우만 캐싱하는 것이 아닙니다. 저는 빠른 임베딩 (embedding)을 계산하고 (text-embedding-3-small 사용), 코사인 유사도 (cosine similarity)를 사용하여 최근 쿼리와 비교합니다. 유사도가 0.95 이상이면 캐싱된 응답을 제공합니다.
2. 사용자별 속도 제한 (Rate-limits per user) — Redis를 기반으로 하는 토큰 버킷 (token bucket) 알고리즘을 사용하여, 모든 사용자를 차단하지 않으면서도 급격한 트래픽 증가 (bursts)를 완만하게 조절합니다.
3. 재시도 버퍼링 (Buffers retries) — OpenAI가 429 또는 503 오류를 반환할 때, 프록시는 즉시 실패하는 대신 지수 백오프 (exponential backoff)를 사용하여 재시도합니다.

다음은 프록시의 핵심 코드입니다 (간결함을 위해 에러 핸들링은 생략했습니다):

# app.py — 단순화된 프록시
from fastapi import FastAPI, HTTPException
from pydantic import BaseModel
...

네, 받아들여야 할 내용이 많습니다. 하지만 핵심적인 통찰은 다음과 같습니다: 프록시는 단순히 캐싱만 하는 것이 아니라, 의미적 유사성 (semantic similarity)을 이해한다는 것입니다. 이것이 결국 제 비용을 70% 절감해 준 비결이었습니다.

트레이드오프 (Trade-offs) 및 한계점

솔직히 말씀드리면, 이것이 공짜 점심(free lunch)은 아닙니다.

• 임베딩 호출(Embedding calls)은 지연 시간(latency)을 추가합니다. 이제 각 요청은 LLM(Large Language Model)에 도달하기 전, 임베딩을 얻기 위해 추가적인 API 호출을 수행합니다. 평균적으로 약 200ms가 추가됩니다. 저의 Slack 봇에게는 괜찮은 수준이지만, 실시간 채팅의 경우에는 너무 느릴 수 있습니다. 로컬 임베딩 모델(local embedding model)을 사용할 수도 있지만, 이는 더 높은 복잡성을 요구합니다.
• Redis 메모리가 증가합니다. 캐싱된 각 응답에는 1536차원의 부동 소수점 벡터(float vector)가 포함됩니다. 수천 개의 항목이 쌓인 후에는 오래된 항목을 제거(evict)해야 할 것입니다. 저는 redis-py의 MAXMEMORY 정책을 통해 LRU(Least Recently Used) 방식을 사용했습니다.
• 코사인 유사도(Cosine similarity)는 완벽하지 않습니다. 때때로 두 프롬프트(prompt)가 비슷하게 들리지만 서로 다른 답변이 필요한 경우가 있습니다 (예: "가격이 얼마인가요?" vs "할인 후 가격이 얼마인가요?"). 오탐(false positives)을 피하기 위해 임계값(threshold)을 충분히 높게 설정했지만, 여전히 발생하곤 합니다.
• 재시도 버퍼링(Retry buffering)이 실제 장애를 은폐할 수 있습니다. 만약 OpenAI가 10분 동안 다운된다면, 프록시는 계속해서 재시도를 시도하며 요청 할당량(request quota)을 소진할 것입니다. 저는 5회 연속 실패 시 작동하는 서킷 브레이커(circuit breaker)를 추가했습니다.

고려했던 대안들 (Alternatives I considered)

이것을 구축하기 전에 Portkey, Helicone, 그리고 일부 AI 전용 프록시(예: https://ai.interwestinfo.com/의 InterWest 제공 서비스)와 같은 관리형 솔루션(managed solutions)들을 살펴보았습니다. 예산이 넉넉한 팀에게는 그러한 도구들이 훌륭합니다. 하지만 개인 개발자의 실험으로서, 직접 구축해 보는 과정은 LLM API의 장애 모드(failure modes)에 대해 훨씬 더 많은 것을 가르쳐 주었습니다.

만약 제가 프로덕션 환경을 위해 이 작업을 다시 한다면, 아마도 LiteLLM이나 AI Gateway와 같은 오픈 소스 프록시(open-source proxy)로 시작하고 필요한 경우에만 커스텀할 것입니다. 처음부터 직접 구축하는 것은 완전한 제어권을 주었지만, 동시에 유지보수의 부담도 주었습니다.

제가 다르게 했을 점 (What I’d do differently)

1. 첫날부터 모든 것에 계측 (Instrument everything)을 적용하세요. 저는 프록시가 일주일 동안 실행된 후에야 로깅 (Logging)과 메트릭 (Metrics)을 추가했습니다. 이것이 없었기에 어떤 프롬프트 (Prompt)가 캐싱 (Caching)되고 있는지, 혹은 버려지고 있는지 전혀 알 수 없었습니다.
2. 적절한 메시지 큐 (Message queue)를 사용하세요. 현재 프록시는 요청을 동기적 (Synchronously)으로 처리합니다. 높은 처리량 (High throughput)을 위해서는 OpenAI 호출을 백그라운드 워커 (Background worker, 예: Celery, Redis Queue)로 오프로드 (Offload)할 것입니다.
3. 캐싱 (Caching) 코드와 속도 제한 (Rate-limiting) 코드를 분리하세요. 현재는 모든 것이 하나의 핸들러 (Handler)에 섞여 있어, 독립적으로 테스트하기가 어렵습니다.

마치며 (Final thoughts)

이 프록시를 구축하는 과정은 다시 걷는 법을 배우는 것과 같았습니다. 수많은 비틀거림과 넘어짐이 있었지만, 결국에는 안정적인 걸음걸이를 갖게 되었습니다. 가장 큰 교훈은 무엇일까요? AI API를 마법 같은 블랙박스 (Black boxes)로 취급하지 마세요. 그것들은 그저 기묘한 과금 메트릭 (Billing metrics)을 가진 HTTP 엔드포인트 (Endpoints)일 뿐입니다. 약간의 미들웨어 (Middleware)만 있다면, 여러분의 앱이 필요로 하는 방식으로 작동하게 만들 수 있습니다.

여러분의 설정은 어떤 모습인가요? 관리형 서비스 (Managed service)를 사용 중인가요, 아니면 직접 구축 (Rolling your own)하고 계신가요? 무엇이 잘 작동하고 있는지, 그리고 무엇이 돈을 낭비하고 있는지 듣고 싶습니다.