내가 걱정을 멈추고 AI API 재시도(Retries)를 사랑하게 된 방법

내가 만든 AI 기반 기능이 운영 환경(Production)에서 중단되었던 날을 기억합니다. 금요일 오후였습니다. 사용자들은 "스마트 검색"이 빈 결과를 반환한다며 불만을 제기하고 있었습니다. 근본 원인은 무엇이었을까요? 가끔 500 에러를 반환하는 불안정한 AI API였고, 제 코드는 이에 대해 아무런 조치도 취하지 않았습니다. 그저 충돌(Crash)할 뿐이었습니다.

저는 사용자 쿼리를 AI 모델로 보내고, 출력을 파싱하여 구조화된 결과를 표시하는 깔끔하고 작은 파이프라인을 구축하는 데 2주를 보냈습니다. 로컬 테스트에서는 아름답게 작동했습니다. 하지만 실제 트래픽이 발생하는 운영 환경에서는 API가 약 5%의 확률로 타임아웃(Time out)이 발생하거나 에러를 던졌습니다. 그 5%가 상당수 사용자의 경험을 망쳐놓았습니다.

이 글은 제가 단순한 단일 요청 호출 방식에서 벗어나, 제 주말을 구해준 탄력적인 재시도(Retry) 기반 접근 방식으로 어떻게 변화했는지에 대한 이야기입니다. 만약 여러분이 어떤 외부 AI API라도 통합하고 있다면, 아마 여러분도 이 벽에 부딪혀 본 적이 있을 것입니다.

단순한 접근 방식 (내가 처음에 시도했던 것)

제 원래 코드는 다음과 같았습니다. 예시로 Python과 requests, 그리고 OpenAI의 API를 사용하고 있지만, 이 패턴은 보편적입니다:

import requests

def extract_entities(query):
...

깔끔하고 단순하지만, 틀렸습니다. 처음으로 ConnectionError나 504 Gateway Timeout을 받았을 때, 제 앱 전체가 충돌했습니다. 저의 첫 번째 "해결책"은 이를 try/except로 감싸는 것이었습니다:

def extract_entities(query):
    try:
        response = requests.post(...)
...

이제 앱이 충돌하지는 않았지만, 조용히 None을 반환했습니다. 즉, 사용자는 빈 결과를 보게 되었습니다. 더 나쁜 점은, 에러가 일시적(Transient, 일시적인 네트워크 끊김 등)일 수 있음에도 불구하고 제 코드는 즉시 포기해 버렸다는 것입니다.

막다른 길: 단순한 재시도 (Naive Retries)

그다음 저는 고정된 지연 시간(Fixed delay)을 가진 단순한 재시도 루프를 추가했습니다:

import time

def extract_entities(query):
...

조금 나아졌지만, 결함이 있었습니다. 만약 API에 과부하가 걸린 상태라면, 정확히 1초 동안 대기하고 세 번 재시도하는 방식은 여전히 실패로 돌아갔습니다. 저는 동일한 속도로 API를 계속 두드리고 있었던 것입니다. 또한, 저는 전체 스레드(Thread)를 차단(Blocking)하고 있었습니다. 비동기(Async)도, 큐(Queue)도 없었습니다. 제 앱은 느려지고 응답이 없어졌습니다.

실제로 효과가 있었던 것: 지수 백오프(Exponential Backoff) + 비동기 큐(Async Queue)

저는 세 가지가 필요하다는 것을 깨달았습니다:

지수 백오프 (Exponential backoff) — 재시도 사이의 대기 시간을 늘려 API가 회복할 시간을 줍니다.
지터 (Jitter) — 천둥 치는 들소 문제 (Thundering herd problem)를 피하기 위해 무작위성을 추가합니다.
비동기 백그라운드 큐 (Async background queue) — 메인 요청 스레드 (Main request thread)를 차단하지 마세요. API가 느리다면 사용자가 나중에 답변을 받을 수 있도록 합니다.

다음은 제 프로덕션 시스템을 구한 최종 패턴입니다. 비동기 부분에는 asyncio와 aiohttp를 사용하겠지만, 동일한 개념은 스레드(Threads)나 Celery와 같은 태스크 큐 (Task queues)에서도 작동합니다.

import asyncio
import aiohttp
import random
...

캐싱 (Caching): 숨은 영웅

제가 고생하며 배운 또 다른 사실은, 만약 두 사용자가 5분 이내에 동일한 질문을 한다면 비용을 두 번 지불하고 대기 시간도 두 배로 든다는 것입니다. 저는 TTL (Time-to-live)이 포함된 간단한 인메모리 캐시 (In-memory cache)를 추가했습니다:

import time
from functools import lru_cache

...

이를 통해 API 비용을 30% 절감했고, 반복되는 쿼리에 대한 지연 시간 (Latency)을 개선했습니다.

교훈 (Lessons Learned)

재시도 (Retries)만으로는 충분하지 않습니다 — 백오프 (Backoff), 지터 (Jitter), 그리고 재시도를 사용자의 요청 생명주기 (Request lifecycle)로부터 격리할 방법이 필요합니다.
비동기 (Async)는 게임 체인저입니다 — 재시도 체인 동안 이벤트 루프 (Event loop)를 차단하면 처리량 (Throughput)이 급감합니다.
공격적으로 캐싱하세요 — AI API는 비용이 많이 들고 종종 속도 제한 (Rate-limited)이 걸립니다. 동일한 요청을 캐싱하면 돈과 시간을 아낄 수 있습니다.
재시도를 모니터링하세요 — 각 재시도 시도와 실패를 로그로 남기세요. 저는 API 상태가 좋지 않을 때를 확인할 수 있도록 구조화된 로깅 (Structured logging)을 추가했습니다.

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

이 패턴은 동일한 쿼리가 항상 동일한 결과를 반환하는 멱등성 (Idempotent) 요청에 잘 작동합니다. 만약 API가 멱등적이지 않다면 (예: 호출할 때마다 리소스를 생성하는 경우), 맹목적인 재시도는 중복을 발생시킬 수 있습니다. 그런 경우에는 멱등성 키 (Idempotency keys)나 정확히 한 번 실행 (Exactly-once semantics) 보장이 필요합니다.

또한, API의 속도 제한 (Rate limits)이 매우 엄격하다면 (예: 초당 1회 요청), 지수 백오프조차 도움이 되지 않을 수 있습니다. 이럴 때는 토큰 버킷 (Token bucket) 알고리즘이나 예약된 작업 (Scheduled jobs)이 포함된 적절한 큐를 구현해야 합니다.

다음에 한다면 다르게 할 점

임시방편적인 (ad-hoc) 백그라운드 작업을 구축하는 대신, 적절한 비동기 작업 큐 (async task queue, 예: Celery 또는 RQ)로 시작했을 것입니다. 그렇게 했다면 재시도 관리 (retry management), 데드 레터 큐 (dead letter queues), 그리고 모니터링 기능을 즉시 사용할 수 있었을 것입니다. 빠른 프로토타입 제작을 위해서는 위에서 언급한 비동기 패턴이 괜찮지만, 프로덕션 (production) 환경을 위해서는 내구성 (durability)이 필요합니다.

또한, 직접 루프를 작성하는 대신 tenacity와 같은 라이브러리를 사용하여 재시도 로직 (retry logic)을 구현했을 것입니다.

회복 탄력성 있는 (resilient) AI 통합을 구축하는 것은 하나의 여정입니다. 이제 제 코드는 일시적인 장애 (transient failures)를 우아하게 처리하며, 사용자는 API가 살짝 재채기를 할 때(일시적 오류가 발생할 때) 거의 눈치채지 못합니다. 만약 불안정한 AI API와 싸워본 경험이 있다면, 여러분의 전투 이야기(war stories)를 듣고 싶습니다. 여러분의 재시도 전략 (retry strategy)은 어떤 모습인가요?