에이전트 장애 복원력 설계 (Agent Resilience Design)

“에이전트는 장애가 없는 환경이 아니라, 장애에서 살아남는 구조로 만들어야 한다.” Auth Profile 순환 → Model Fallback 체인 → Agent Loop의 3중 안전망. Prompt Caching 보존을 위한 세션 스티킨스(Session Stickiness)가 비용 최적화와 장애 대응을 동시에 달성한다.

핵심 원칙

Rate limit, API 장애, 결제 오류는 언제든 발생할 수 있다. AI 에이전트 운영에서 장애를 “없애는” 것은 불가능하다 — “자동으로 살아남는 구조”를 만드는 것이 현실적인 목표다.

Model Failover — 2단계 안전망

1단계: Auth Profile 순환

같은 모델에 여러 계정(OAuth, API 키)을 등록하면 하나가 막혔을 때 다음 계정으로 자동 전환한다.

우선순위 규칙:

• OAuth가 API 키보다 우선 (동일 프로바이더)
• LRU(오래 안 쓴 계정) 먼저 시도

장애 유형별 복구 전략:

장애 유형	복구 방식	이유
Rate Limit (429)	쿨다운 후 재시도	기다리면 해결
결제 오류	비활성화 (최대 24h)	기다려도 해결 안 됨

지수 백오프(Exponential Backoff) 쿨다운:

1차 실패 → 1분 대기
2차 실패 → 5분 대기
3차 실패 → 25분 대기
4차+   → 1시간 (상한)

2단계: Model Fallback 체인

모든 계정이 막혔을 때 더 저렴하거나 여유로운 모델로 자동 전환한다:

Claude Opus → Claude Sonnet → GPT-4o → Gemini Flash

실전 사례: Opus Rate limit → Sonnet 전환 → 브리핑 자동 발송 성공. 에이전트 개입 없음. (출처: bbojjak-openclaw-resilience-failover-lesson19)

세션 스티킨스 (Session Stickiness)

정의: 한번 선택된 Auth Profile은 세션이 끝날 때까지 유지한다.

이유: agent-memory-architecture의 Prompt Caching 보존.

세션 내 같은 계정 → 연속 요청 → 캐시 히트 → 90% 할인
세션 내 계정 변경 → 캐시 미스 → 전액 과금

Prompt Caching은 시스템 프롬프트(SOUL.md, AGENTS.md 등)와 이전 대화를 캐시한다. 계정이 바뀌면 캐시 키가 달라져 새로 청구된다.

결론: 세션 스티킨스는 단순한 편의 기능이 아니라 비용 최적화와 장애 대응을 동시에 달성하는 설계다.

Agent Loop — 안전 컨테이너

에이전트 작업(Run)의 6단계 처리 흐름:

1. Intake          — 메시지 수신
2. Context Assembly — 컨텍스트 구성
3. Model Inference  — LLM 호출 ← Failover는 여기서 작동
4. Tool Execution   — 도구 실행
5. Streaming Replies — 답변 전달
6. Persistence      — 세션 저장

Agent Loop이 Model Inference 단계를 감싸기 때문에:

• Failover가 3번에서 재시도해도 나머지 단계(4~6)는 정상 실행됨
• 재시도 전후 세션 히스토리가 꼬이지 않음

비유: Model Failover = 내비게이션(막히면 다른 길 탐색) / Agent Loop = 자동차 안전장치(어떤 길이든 차가 안전하게 달리도록 보장)

Timeout: 10분. 무한 루프 방지.

장애 대응 설계 체크리스트

운영 에이전트를 위한 장애 복원력 점검:

• Auth Profile이 여러 개인가? (최소 2개 권장)
• Model Fallback 체인이 설정되어 있는가?
• 결제 오류와 Rate Limit을 구분해서 처리하는가?
• 세션 스티킨스가 활성화되어 있는가? (Prompt Caching 보존)
• Agent Loop Timeout이 설정되어 있는가?
• 장애 발생 시 알림 채널이 있는가? (Slack 등)

작업별 모델 분리 — 비용과 복원력 동시 달성

Model Fallback 체인에서 Sonnet이 Opus의 폴백이 되기 전에, 처음부터 작업에 맞는 모델을 선택하면 비용이 절감되고 Rate limit도 덜 걸린다.

작업 유형	권장 모델	이유
하트비트, 단순 크론잡	Sonnet	복잡한 추론 불필요, 1/5 비용
분석 크론잡, 전략 판단	Opus	정확도 필요
서브에이전트	Sonnet	기본값, 새 컨텍스트

→ agent-token-optimization의 작업별 모델 분리 전략과 연결.

실전 결과: 하트비트·크론잡 Sonnet 전환으로 14일 $928\to$612 예상 (34% 절감).

관련 개념

• agent-token-optimization — 작업별 모델 분리; 능동적 compact; 세션 크기 관리
• agent-memory-architecture — Prompt Caching + 세션 스티킨스 연결
• agentic-scheduling-design — 하트비트 Sonnet 전환 = 스케줄링 비용 최적화
• agent-error-learning-loop — 장애 대응도 에러 학습 루프와 동일한 “자동 복구” 원칙

소스

• bbojjak-openclaw-resilience-failover-lesson19