세 가지 레이어를 추가하기 전까지 나의 AI 통합은 재앙이었다

몇 달 전, 나는 AI 통합 문제를 다 해결했다고 생각했습니다. 사용자가 업로드한 문서의 요약을 생성하기 위해 OpenAI의 API를 호출하는 Python 서비스를 만들었습니다. 간단하죠? 몇 개의 requests.post 호출을 대충 엮고, 약간의 에러 처리(정중한 try/except)를 추가한 뒤 일을 마쳤습니다.

하지만, 제가 완전히 틀렸습니다.

문제의 첫 번째 신호는 429 에러, 즉 속도 제한(rate limits)이었습니다. 그다음은 OpenAI 측에서 발생하는 간헐적인 5xx 에러였습니다. 그다음은 사용자들이 참을성 없이 브라우저를 새로고침하게 만드는 지연 시간(latency) 급증이었습니다. 그리고 가장 최악이었던 것은? 비용이었습니다. 모든 재시도와 불필요한 호출이 실제 돈을 낭비하게 만들었습니다.

더 나은 접근 방식이 필요했습니다. 여기 나의 정신 건강(그리고 예산)을 구해준 회복 탄력성 있는(resilient) AI 통합 레이어를 구축하며 배운 내용이 있습니다.

실패한 순진한 접근 방식

나의 첫 번째 버전은 부끄러울 정도로 단순했습니다:

import requests

def summarize(text):
...

이 방식은 세 가지 이유로 무너졌습니다:

재시도 로직(retry logic) 부재 – 일시적인 503 에러가 발생하면 요청이 즉시 종료되었습니다.
캐싱(caching) 부재 – 두 명의 사용자가 동일한 문서를 업로드하면, 나는 동일한 요약에 대해 비용을 두 번 지불했습니다.
폴백(fallback) 부재 – OpenAI가 다운되었을 때, 나의 앱도 죽었습니다.

나는 몇 가지 임시방편을 시도했습니다. 재시도 전 간단한 time.sleep()을 넣거나, 메모리 내에 dict 캐시를 사용하는 식이었죠. 하지만 그것들은 취약했고 확장성(scale)이 없었습니다.

마침내 성공한 세 가지 레이어 접근 방식

엉망인 상태를 패치하는 대신, 나는 세 가지 핵심 레이어인 회복 탄력성 있는 재시도(Resilient Retries), 지능형 캐싱(Intelligent Caching), 그리고 **자동화된 폴백(Automated Fallback)**을 중심으로 통합 과정을 처음부터 다시 작성했습니다. 각 레이어는 상황을 지나치게 복잡하게 만들지 않으면서 특정 고충(pain point)을 해결했습니다.

레이어 1: 지수 백오프(Exponential Backoff) + 지터(Jitter)

고정된 지연 시간을 사용하는 단순한 재시도는 재앙입니다. 장애 발생 시 API에 가해지는 부하를 증폭시키기 때문입니다. 내가 필요했던 것은 재시도 간격을 분산시키기 위해 무작위 지터(random jitter)를 결합한 지수 백오프(exponential backoff)였습니다.

import time
import random
from functools import wraps
...

이것만으로도 에러율을 15%에서 0.5% 미만으로 줄일 수 있었습니다. 하지만 나는 여전히 동일한 요청에 대해 똑같은 호출을 여러 번 수행하고 있었습니다.

레이어 2: 2단계 캐싱 (Two-Level Caching)

프로세스 전반에 걸쳐 작동하고 재시작 후에도 유지되는 캐시가 필요했습니다. 인메모리 딕셔너리 (In-memory dict)는 너무 휘발성이 강했고, Redis는 제 작은 앱에 쓰기에는 너무 무거웠습니다. 저는 하이브리드 방식을 선택했습니다. 동일한 요청 내에서의 반복 호출을 위한 간단한 functools.lru_cache와 장기 저장을 위한 로컬 SQLite 데이터베이스를 조합했습니다.

from functools import lru_cache
import sqlite3
import json
...

이 방식은 반복되는 문서 요약본을 캐시에서 제공함으로써 API 비용을 약 40% 절감해 주었습니다.

레이어 3: 우아한 폴백 모델 (Graceful Fallback Models)

가장 큰 골칫거리는 OpenAI가 다운되었을 때, 제 앱이 (비록 속도는 느려지더라도) 여전히 작동하기를 원한다는 점이었습니다. 저는 설정 가능한 순서에 따라 여러 제공업체 (providers)를 시도하고, 우아하게 폴백 (failover)하는 클라이언트를 구축했습니다.

class AIProviderRouter:
    def __init__(self, config):
        self.providers = []
...

이제 OpenAI가 503 에러를 반환하면, 라우터는 투명하게 Anthropic을 시도하고, 그다음 로컬 Mixtral 인스턴스를 시도하며, 모든 것이 실패했을 때만 포기합니다. 제 사용자들은 이를 거의 눈치채지 못합니다.

모두 통합하기

다음은 최종 클라이언트의 단순화된 버전입니다:

from retry_decorator import retry_with_backoff
from cache import AICache
from router import AIProviderRouter
...

이것이 전부입니다. 세 개의 레이어, 각각이 하나의 실제 문제를 해결합니다. 마법 같은 것은 없습니다.

교훈 및 트레이드오프 (Trade-offs)

캐시 TTL (Time To Live)이 중요합니다. 처음에는 24시간 캐시로 시작했지만, 오래된 요약본이 사용자들을 혼란스럽게 했습니다. 현재는 기본값을 1시간으로 사용하지만, 엔드포인트별로 설정이 가능합니다.
폴백은 공짜가 아닙니다. 서로 다른 제공업체는 서로 다른 품질의 응답을 제공합니다. 응답 형식을 변환하기 위해 정규화 (normalisation) 레이어를 추가해야 했습니다.
모니터링은 필수입니다. 재시도 횟수, 캐시 히트율 (cache hit rates), 폴백 사용량에 대한 지표 (metrics)가 없다면 저는 눈을 감고 비행하는 것과 다름없었을 것입니다. 각 레이어에 간단한 Prometheus 카운터를 추가했습니다.

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

앱이 빠른 프로토타입(prototype)이고 신뢰성에 신경 쓰지 않는다면, 복잡성을 건너뛰세요.
실시간 응답(100ms 미만)이 필요한 경우, 과도한 캐싱(caching)과 다중 재시도(retries)는 지연 시간(latency)을 치명적으로 높입니다. 직접 결제가 가능한 전용 추론 엔드포인트(inference endpoint)를 고려하세요.
예산이 한정되어 있다면, 폴백 제공자(fallback providers)를 추가하기 전에 캐시 히트(cache hits)를 최적화하는 데 집중하세요.

다음에 제가 다르게 할 일

저는 첫날부터 설정 중심(configuration-driven)의 클라이언트로 시작했을 것입니다. ai.interwestinfo.com에서 제공하는 것과 같이 이러한 레이어들을 추상화(abstract)해주는 도구 말입니다(어느 리포지토리(repo) 댓글에서 언급된 것을 보았습니다). 바퀴를 다시 발명하는 것은 즐거운 일이지만, 항상 수익성이 있는 것은 아니기 때문입니다. 하지만 직접 구축해 본 경험은 그렇지 않았다면 배우지 못했을 미묘한 차이(nuances)들을 가르쳐 주었습니다.

이것이 저의 이야기입니다. 속도 제한(Rate limits), 청구서, 그리고 다운타임(downtime)은 제가 AI API에 대해 순진하게 생각하는 것을 멈추게 만들었습니다. 백오프(backoff), 캐시(cache), 폴백(fallback)으로 이어지는 이 3단계 패턴은 취약하고 엉망이었던 상태를 제가 실제로 밤에 잠을 편히 잘 수 있을 정도의 상태로 변화시켰습니다.

여러분의 설정은 어떤 모습인가요? 더 간단한 패턴을 찾으셨나요, 아니면 특정 도구를 고수하시나요? 여러분에게 효과가 있었던(혹은 실패했던) 방식이 무엇인지 정말 듣고 싶습니다.