자율 에이전트(Autonomous Agents)가 실패하는 이유는 프롬프트가 아니라 운영(Ops) 때문이다: 신뢰성 체크리스트

저는 계속해서 똑같은 이야기를 듣고 있습니다: "내 에이전트가 작동하지 않아요, 더 나은 프롬프트가 필요해요." 하지만 대개 그것은 문제가 아닙니다.

제 자신의 파이프라인(실제 수치)에서 목격한 것:
지난 24시간 동안 38개의 예약된 작업(scheduled jobs)이 실행되었습니다. 그 중 14개가 실패했습니다. 제 프롬프트가 나빴기 때문이 아니라, 프롬프트를 둘러싼 시스템이 취약했기 때문입니다:

• HTTP 429 속도 제한 (rate limits)
• 제공자 불일치 (provider mismatch) / 지원되지 않는 모델 (unsupported model)
• 누락된 API 키 (missing API keys)
• 간헐적인 네트워크 오류 (intermittent network failures)

만약 당신이 관리자 없이 작동하는(unattended) 에이전트를 구축하고 있다면, 프롬프트 품질은 기본 중의 기본(table stakes)입니다. 신뢰성(Reliability)이 곧 제품입니다.

모든 에이전트에게 필요한 지루한 신뢰성 계층 (The boring reliability layer)
다음은 실제 시스템과 접촉하는 모든 에이전트 워크플로우에 대해 제가 이제 필수 사항으로 취급하는 체크리스트입니다.

1. 에러 예산 (Error budgets) (실패가 드문 일인 척하는 것을 멈추세요)
   "건강한 상태"가 무엇을 의미하는지 정의하십시오:

• 워크플로우당 일일 실패 횟수
• 일시 중지 전 최대 연속 실패 횟수
• 최대 복구 시간 (max time-to-recover)
  이것을 측정하지 않는다면, 당신은 에이전트를 출시하는 것이 아니라 데모(demo)를 출시하고 있는 것입니다.

2. 제공자 상태 확인 (Provider health checks) + 폴백 모델 (fallback models)
   에이전트는 당신이 원하든 원하지 않든 멀티 제공자(multi-provider) 환경에서 작동합니다. 어떤 제공자든 최악의 순간에 다운되거나, 동작을 변경하거나, 속도 제한(rate-limit)을 걸 수 있다고 가정하십시오.
   최소 요구 사항:

• 비용이 많이 드는 실행 전 상태 확인 (health check)
• 제공자별 속도 제한 추적 (per-provider rate limit tracking)
• 자동 폴백 모델/제공자 (automatic fallback model/provider)

3. 멱등성 (Idempotency) (재시도는 안전해야 합니다)
   만약 재시도가 부수 효과(side-effects)를 중복시킨다면, 당신의 에이전트는 결국 피해를 입힐 것입니다.
   패턴:

• 작업 ID(task id) 생성
• "이미 완료됨" 마커 저장
• 가능한 경우 조건부 쓰기(conditional writes) 사용

4. 백오프 (Backoff) + 지터 (jitter) + 데드 레터 큐 (dead-letter queue)
   백오프 없는 재시도는 자가 DDoS(self-DDoS)와 같습니다.
   의사 코드 (Pseudo-code):

import random, time

def retry(fn, max_attempts=5, base=1.0):
    for attempt in range(1, max_attempts + 1):
        try:
            return fn()
        except Exception as e:
            sleep = base * (2 ** (attempt - 1)) + random.random()
            time.sleep(min(sleep, 60))
            if attempt == max_attempts:
                raise

또한, 무언가가 반복적으로 실패하면 데드 레터 큐(dead-letter queue)로 보내고 사람에게 알리십시오 (또는 최소한 워크플로우를 일시 중지하십시오).

5. 관찰 가능성 (Observability): 최종 텍스트뿐만 아니라 도구 호출 (tool calls)을 기록하십시오. 에이전트가 실패할 때, 여러분은 다음 질문에 답할 수 있어야 합니다: 어떤 도구 호출 (tool call)이 실패했는가? 어떤 입력값 (input)이 전송되었는가? 어떤 출력값/에러 (output/error)가 돌아왔는가? 어떤 재시도 경로 (retry path)가 실행되었는가? 이것이 없다면 디버깅 (debugging)은 추측의 영역이 됩니다. 논쟁적인 부분: 운영 계층 (ops layer)이 없는 자율 에이전트 (autonomous agent)는 그저 느낌 (vibes)에 의존하는 예약된 API 호출에 불과합니다. 만약 여러분이 프로덕션 (production) 환경에서 에이전트를 실행하고 있다면, 무엇이 가장 자주 실패합니까: 모델 (models), 도구 (tools), 아니면 데이터 (data)입니까? Created by Ramagiri Tharun