현장에서 에이전트 데모는 대부분 잘 돈다. 문제는 운영 첫 주에 나온다. 같은 질문인데 오늘은 도구 호출이 늦고, 어제는 권한 오류가 났고, 어떤 날은 답은 맞지만 후속 액션이 틀어진다. 이때 팀은 프롬프트를 고친다. 그러나 운영 장애는 프롬프트만으로 복구되지 않는다.
에이전트 실패는 모델 문제가 아니다
에이전트의 실패 지점은 네 군데다. 모델 호출, tool 호출, 정책 검증, 상태 관리다. 하나라도 흔들리면 사용자는 “AI가 틀렸다”고 말한다. 내부적으로는 다른 사고다.
OpenAI Agents SDK 문서는 input/output/tool guardrail의 실행 경계를 분리하고, tool guardrail이 매 함수형 tool 호출마다 검증을 걸 수 있다고 설명한다. 이는 복구 설계가 답변 생성 이후의 검수만이 아니라 실행 전후의 제어 지점에 걸려야 한다는 뜻이다. (openai.github.io)
에이전트 품질은 정답률보다 실패 후 행동으로 판정된다.
실패를 한 덩어리로 보면 모든 장애가 “다시 해봐”가 된다. 재시도는 복구가 아니라 부하 증폭이 될 때가 많다.
재시도는 예외가 아니라 예산이다
재시도는 일시 장애에만 쓴다. 네트워크 타임아웃, 429/503류 응답, 일시적 tool 실패가 대상이다. 권한 없음, 스키마 불일치, 정책 위반, 사용자의 모호한 요청에는 재시도를 걸지 않는다.
AWS는 2026년 5월 SDK retry 동작 업데이트에서 standard 모드가 retry quota, exponential backoff with jitter, retryable error 세트를 포함한다고 설명했다. 지속 장애에서는 quota가 소진되어 더 빨리 실패하도록 설계된다. (aws.amazon.com) AWS SDK 참조 문서도 retry token bucket이 비면 재시도하지 않는다고 명시한다. (docs.aws.amazon.com)
에이전트에도 같은 원칙을 적용한다.
| 패턴 | 쓰는 경우 | 금지할 경우 |
|---|---|---|
| Retry | 일시적 tool/API 실패 | 정책 위반, 권한 오류 |
| Fallback | 대체 모델·대체 tool·축소 응답 가능 | 정합성 검증 없이 다른 경로로 우회 |
| Circuit breaker | 장애가 반복되어 하류 시스템 보호 필요 | 단순 불편을 장애로 과대 판정 |
재시도는 횟수가 아니라 예산이다. 한 요청 안에서 몇 번까지, 어느 계층에서만, 어떤 오류 코드에만 허용할지 정해야 한다. 여러 계층이 동시에 재시도하면 장애는 복구되지 않고 증폭된다.
폴백은 낮은 품질 답변이 아니다
폴백을 “싸고 약한 모델로 바꾸기”로 이해하면 실패한다. 운영 폴백은 업무를 안전한 상태로 낮추는 설계다.
첫째, 모델 폴백이다. 고성능 모델 장애 시 더 작은 모델로 요약·분류 같은 제한 업무만 수행한다. 둘째, tool 폴백이다. 실시간 조회가 실패하면 캐시나 읽기 전용 데이터로 전환하고, 실행성 액션은 막는다. 셋째, 사람 폴백이다. 일정 기준을 넘으면 담당자 검토로 넘긴다.
OpenAI의 에이전트 가이드는 guardrail 위반이나 실패 임계값 초과 시 human intervention으로 제어를 넘기는 구조를 권고한다. (cdn.openai.com) OpenAI Agents SDK 문서는 output guardrail 실패 시 저장된 state로 model call 없이 guardrail을 다시 실행하는 예시도 제공한다. 이는 폴백이 “처음부터 다시 생성”이 아니라 상태를 보존한 복구여야 한다는 점을 보여준다. (openai.github.io)
서킷브레이커는 멈춤을 제품화한다
서킷브레이커는 장애를 감지하면 일정 시간 특정 경로를 닫는다. 에이전트에서는 결제, 발주, 데이터 수정, 외부 발송 같은 tool에 먼저 적용한다. 답변 생성보다 실행 tool이 더 위험하다.
Claude Agent SDK의 hooks 문서는 PreToolUse, PostToolUse, subagent 시작·종료, idle, 종료 이벤트에서 hook이 실행되고, callback이 결정을 반환하는 구조를 설명한다. 이런 hook 지점은 tool 호출 전 차단, 호출 후 결과 검증, 반복 실패 감지에 쓰인다. (code.claude.com) Anthropic은 Claude Agent SDK를 Claude Code의 agent harness를 일반 에이전트에 확장한 것으로 설명한다. 운영 설계의 핵심은 모델보다 harness다. (anthropic.com)
서킷이 열리면 에이전트는 침묵하지 않는다. “현재 이 작업은 자동 실행하지 않고 검토 대기열로 보냈다”처럼 업무 상태를 남긴다. 반쯤 열린 상태에서는 일부 요청만 시험 통과시킨다. 통과하면 닫고, 실패하면 다시 연다.
참고
- OpenAI, A practical guide to building agents (2026): https://cdn.openai.com/business-guides-and-resources/a-practical-guide-to-building-agents.pdf
- OpenAI Agents SDK, Running agents (현재 문서): https://openai.github.io/openai-agents-js/guides/running-agents/
- OpenAI Agents SDK, Guardrails (현재 문서): https://openai.github.io/openai-agents-python/guardrails/
- AWS Developer Tools Blog, Announcing updated retry behavior for AWS SDKs and Tools (2026): https://aws.amazon.com/blogs/developer/announcing-updated-retry-behavior-for-aws-sdks-and-tools/
- AWS SDKs and Tools, Retry behavior (현재 문서): https://docs.aws.amazon.com/sdkref/latest/guide/feature-retry-behavior.html
- Claude Docs, Intercept and control agent behavior with hooks (현재 문서): https://code.claude.com/docs/en/agent-sdk/hooks
- Anthropic, Building agents with the Claude Agent SDK (2025): https://claude.com/blog/building-agents-with-the-claude-agent-sdk
에이전트 운영 설계는 “잘 답하는 흐름”보다 “틀어졌을 때 멈추고 우회하는 흐름”을 먼저 그리는 일이다. AX LABS는 이 복구 경로를 AX Ops 안에서 지표·권한·운영 절차까지 함께 설계한다. AX Ops 방법론 →