저는 하루에 10,000개의 채용 공고를 처리하는 LLM 스코어링 파이프라인을 구축하는 데 몇 달을 보냈습니다. 스테이징(Staging) 환경에서는 아주 아름답게 작동했습니다. 하지만 프로덕션(Production)에 적용하자 비용이 빠르게 치솟기 시작했습니다.

문제는 모델이 아니었습니다. 문제는 제가 프로덕션 시스템이 아닌 데모를 만들었다는 점이었습니다. "작동한다"와 "확장 가능한 규모에서 안정적으로 작동한다" 사이의 간극은 대부분의 AI 에이전트 프로젝트가 실패하는 지점입니다. 창업자들은 API 비용으로 자금을 소진합니다. 엔지니어링 팀은 처음 100개의 요청에는 작동하지만 1,000번째 요청쯤에는 무너져 버리는 무언가를 출시합니다.

실제 프로덕션 환경에서 살아남을 수 있는 신뢰성 계층(Reliability Layer)을 구축하며 제가 배운 것들을 공유합니다.

아무도 경고해주지 않는 비용 폭발

저의 첫 번째 실수는 OpenAI API를 단순한 유틸리티처럼 취급한 것이었습니다. 프롬프트를 보내고, 응답을 받고, 다음으로 넘어갔습니다. 추적도 없었고, 예산도 없었으며, 요청당 비용(Cost-per-request)에 대한 가시성도 없었습니다.

몇 주 후, 빌링 대시보드(Billing dashboard)를 확인했을 때 저는 아키텍처를 완전히 재고하게 만드는 숫자를 보았습니다. 파이프라인이 불필요한 호출을 반복하고 있었습니다. 매 실행마다 동일한 문서를 다시 임베딩(Re-embedding)하고 있었습니다. GPT-4o mini가 충분히 처리할 수 있는 작업에 GPT-4를 사용하고 있었습니다.

저는 두 가지 변경 사항으로 이를 해결했습니다.

첫째, 모든 배치 처리(Batch processing)를 OpenAI의 Batch API를 통해 라우팅했습니다. 이는 훨씬 저렴하며 몇 시간의 지연 시간(Latency)을 감수하면 동일한 처리량(Throughput)을 처리할 수 있습니다. 실시간 응답이 필요하지 않은 일일 스코어링 파이프라인의 경우, 이러한 트레이드오프(Tradeoff)는 고민할 가치도 없는 당연한 선택입니다.

async function submitScoringBatch(listings: JobListing[]) {
  const batch = listings.map((listing) => ({
    custom_id: listing.id,
...

둘째, 작업 복잡도에 기반한 모델 라우팅(Model routing)을 추가했습니다. 단순한 분류(Classification) 작업은 비용이 아주 적은 GPT-4o mini로 보냅니다. 복잡한 추론(Reasoning)은 GPT-4를 유지합니다. 파이프라인은 호출을 한 후에가 아니라, 호출하기 전에 작업 유형을 확인합니다.

재시도 로직(Retry Logic)은 선택이 아닌 필수입니다

LLM API는 실패합니다. 자주 발생하지는 않지만, 발생할 때는 최악의 순간에 발생합니다. 속도 제한(Rate limits), 타임아웃(Timeouts), 일시적인 서버 오류(Transient server errors) 등은 모두 일어날 수 있는 일입니다.

가장 단순한 접근 방식은 에러를 포착(catch)하고 즉시 재시도(retry)하는 것입니다. 하지만 그렇게 하면 모든 실패한 요청이 동일한 순간에 재시도되어 API를 더욱 강력하게 타격하는 천둥 치는 들소(thundering herd) 문제를 일으키게 됩니다.

저는 지터(jitter)를 포함한 지수 백오프(exponential backoff) 방식으로 전환했습니다. 각 재시도는 더 오래 대기하며, 부하를 분산하기 위해 무작위 오프셋(random offset)을 가집니다. 세 번의 실패 후에는 더 이상 가망 없는 일에 API 호출을 낭비하는 대신, 재시도를 중단하고 수동 검토를 위해 에러를 로그로 남깁니다.

async function callWithRetry(prompt: string, maxRetries = 3): Promise<string> {
  for (let attempt = 0; attempt < maxRetries; attempt++) {
    try {
...

이 패턴은 종속된 시스템들을 다운시킬 정도로 길게 지속된 API 중단(outage) 상황에서 파이프라인이 연쇄 장애(cascading failures)를 일으키는 것을 막아주었습니다. 파이프라인은 속도를 늦추고 작업을 큐(queue)에 쌓아두었으며, API가 복구되었을 때 자동으로 회복되었습니다.

기능 호출(Function Calling): 기능이 아닌 가드레일(Guardrail)로서

대부분의 사람들은 기능 호출(function calling)을 LLM이 행동을 취하게 하는 방법으로 생각합니다. 하지만 저는 이를 LLM이 출력할 수 있는 내용을 제한하는 방법으로 생각합니다.

자유 텍스트 생성(free text generation)의 문제는 모델이 결국 당신이 요청하지 않은 것을 생성하게 된다는 점입니다. 저의 점수 산정 파이프라인(scoring pipeline)에서는 구조화된 출력(structured output)이 필요했습니다. 즉, 1에서 10 사이의 점수, 신뢰 수준(confidence level), 그리고 한 문장의 근거(justification)가 필요했습니다. 그 외에는 아무것도 없어야 했습니다.

엄격한 JSON 스키마(JSON schema)를 사용한 기능 호출은 모델의 출력을 시스템의 나머지 부분에 닿기 전에 제가 파싱(parse)하고 검증(validate)할 수 있는 형태로 바꾸어 놓았습니다.

const scoringFunction = {
  name: "score_listing",
  description: "Score a job listing for relevance",
...

스키마는 계약(contract) 역할을 합니다. 모델이 유효한 출력을 생성할 수 없다면, 데이터베이스를 쓰레기 데이터로 오염시키는 대신 호출이 빠르게 실패(fail fast)합니다. 저는 무엇인가를 기록하기 전에 모든 필드를 제약 조건(constraints)에 따라 확인하는 검증 단계를 추가했습니다.

관찰 가능성(Observability): 사용자가 문제를 발견하기 전에 문제를 찾는 방법

보이지 않는 것은 고칠 수 없습니다. 저는 미묘한 프롬프트 드리프트(prompt drift)로 인해 스코어링 파이프라인(scoring pipeline)이 아무도 알아차리기 전까지 며칠 동안 저품질 결과를 조용히 반환했을 때, 이 교훈을 뼈아프게 배웠습니다.

저는 에러 트래킹(error tracking)을 위해 Sentry를 연결했고, 프론트엔드 측의 세션 리플레이(session replay)를 위해 LogRocket을 연결했습니다. 하지만 진정한 가치는 모든 LLM 호출에 구조화된 로깅(structured logging)을 추가하는 데서 왔습니다.

각 요청은 다음을 기록합니다: 사용된 모델, 프롬프트 해시(prompt hash), 응답 시간, 토큰 수, 결과, 그리고 모든 에러입니다. 이를 통해 API와의 모든 상호작용에 대해 검색 가능한 이력을 가질 수 있습니다.

logger.info("LLM call completed", {
  model: "gpt-4o-mini",
  promptHash: hash(prompt),
...

문제가 발생했을 때, 저는 추측하지 않습니다. 로그를 쿼리(query)합니다. 문제를 일으킨 정확한 프롬프트, 정확한 응답, 그리고 정확한 비용을 확인합니다. 이를 통해 디버깅(debugging)은 추측 게임에서 데이터 기반의 작업으로 바뀝니다.

신뢰성 계층(Reliability Layer)은 경쟁 우위입니다

대부분의 AI 제품은 이러한 요소 없이 출시됩니다. 데모(demo)에서는 잘 작동합니다. 데모에는 10,000개의 동시 요청이나 예측 불가능한 API 동작, 또는 500 에러를 즉시 알아차리는 사용자가 없기 때문입니다.

만약 당신이 AI 기능을 출시하는 창업자라면, 당신의 경쟁자들은 아마 신뢰성 측면에서 편법을 쓰고 있을 것입니다. 그들은 재시도(retries)를 처리하지 않고, 비용을 모니터링하지 않으며, 출력을 검증하지 않습니다.

이는 당신이 지루한 작업을 수행함으로써 승리할 수 있음을 의미합니다. 배치(batch) API 경로를 추가하세요. 지수 백오프(exponential backoff)를 구현하세요. 함수 호출(function calling)을 통해 모델의 출력을 제한하세요. 모든 것을 로깅하세요.

화려하지는 않습니다. 하지만 이는 제대로 작동하는 제품과, 사람들이 자신의 워크플로(workflow)를 믿고 맡길 수 있을 만큼 일관되게 작동하는 제품 사이의 차이를 만듭니다.

만약 당신의 팀이 프로덕션 환경에서 LLM 신뢰성 문제로 고군분투하며 그로 인해 출시가 늦어지고 있다면, 그것이 바로 제가 도와드리는 분야입니다. 기꺼이 경험을 공유하겠습니다.

작성자: Abdul Rehman, 프로덕션 SaaS, MVP 및 AI 자동화를 구축하는 풀스택 AI 엔지니어. 더 많은 내용은 PrimeStrides에서 확인하세요.