AI 에이전트에게 복잡한 작업을 맡겼는데, 중간에 API 호출이 실패했습니다. 에이전트는 당황하고, 지금까지의 작업은 모두 날아갑니다. 처음부터 다시 시작해야 할까요?
아닙니다. 잘 설계된 에이전트 시스템은 실패를 예상하고 대비합니다.
❝실패는 "만약(if)"의 문제가 아니라 "언제(when)"의 문제입니다. 중요한 것은 실패를 방지하는 것이 아니라, 실패로부터 우아하게 복구하는 것입니다.
❞
이 글에서는 프로덕션 환경에서 검증된 실패 복구 패턴과 Anthropic 엔지니어링 팀의 실전 전략을 살펴보겠습니다.
이 글은 Anthropic Engineering Blog와 Error Recovery Strategies in AI Agent Development를 참고하여 작성했습니다.에이전트는 왜 실패하는가?
✦실패의 유형
AI 에이전트가 실패하는 원인은 크게 두 가지로 나뉩니다:
| 유형 | 설명 | 예시 |
|---|---|---|
| Transient (일시적) | 잠시 후 재시도하면 성공 | 네트워크 타임아웃, API 레이트 리밋, 서버 과부하 |
| Terminal (영구적) | 재시도해도 실패 | 잘못된 입력, 권한 없음, 비즈니스 규칙 위반 |
💡 핵심 원칙: 일시적 오류는 재시도하고, 영구적 오류는 즉시 포기합니다.
❌ 나쁜 예: 모든 오류를 무한 재시도
→ 잘못된 API 키로 1000번 재시도 (의미 없음)
✅ 좋은 예: 오류를 분류한 후 적절히 대응
→ 타임아웃? 재시도!
→ 403 Forbidden? 즉시 중단 + 사용자 알림✦에이전트 특유의 실패 패턴
일반 소프트웨어와 달리, AI 에이전트에는 고유한 실패 유형이 있습니다:
| 패턴 | 설명 | 위험도 |
|---|---|---|
| 환각 루프 | 잘못된 정보를 기반으로 계속 작업 | 높음 |
| 컨텍스트 드리프트 | 작업 중 원래 목표에서 벗어남 | 중간 |
| 도구 남용 | 같은 도구를 반복 호출 (무한 루프) | 높음 |
| 과도한 자신감 | 잘못된 결과를 "완료"로 보고 | 높음 |
5가지 실패 복구 패턴
✦패턴 1: Retry with Backoff (재시도 + 백오프)
가장 기본적인 복구 전략입니다. 실패 시 점진적으로 간격을 늘려가며 재시도합니다.
재시도 전략: Exponential Backoff + Jitter
시도 1: 즉시 실행 → 실패
시도 2: 1초 후 재시도 → 실패
시도 3: 2초 후 재시도 → 실패
시도 4: 4초 후 재시도 → 성공!
+ Jitter (랜덤 지연):
여러 에이전트가 동시에 재시도하는
"Thundering Herd" 문제 방지| 설정 | 권장값 | 이유 |
|---|---|---|
| 최대 재시도 횟수 | 3-5회 | 무한 루프 방지 |
| 초기 대기 시간 | 1초 | 즉시 재시도보다 안정적 |
| 최대 대기 시간 | 30-60초 | 지나친 대기 방지 |
| Jitter 범위 | 0-100% | 동시 재시도 분산 |
✦패턴 2: Checkpointing (체크포인팅)
장기 실행 작업에서 중간 상태를 저장하여, 실패 시 마지막 저장 지점부터 재개합니다.
작업 흐름 (체크포인트 없이):
[A] → [B] → [C] → ❌ 실패 → 처음부터 다시
작업 흐름 (체크포인트 있을 때):
[A] → 💾 → [B] → 💾 → [C] → ❌ 실패
↓
[C]부터 재개!# claude-progress.txt
## Checkpoint: 2026-02-08 14:30
- Step 1: DB 스키마 생성 ✅
- Step 2: API 엔드포인트 구현 ✅
- Step 3: 프론트엔드 연동 🔄 (진행 중)
- 로그인 폼 완료
- API 연결 실패 (CORS 이슈)
## Recovery Plan
- CORS 설정 수정 후 Step 3 재개
- Step 1, 2는 다시 할 필요 없음💡 체크포인팅은 하네스의 핵심입니다. 진행 문서와 Git 커밋이 자연스러운 체크포인트 역할을 합니다.
✦패턴 3: Circuit Breaker (서킷 브레이커)
연속 실패가 감지되면 일시적으로 작업을 중단하여 시스템을 보호합니다.
서킷 브레이커 상태:
[CLOSED] ── 정상 작동
│
▼ (연속 N회 실패)
[OPEN] ── 모든 요청 차단 (쿨다운)
│
▼ (일정 시간 경과)
[HALF-OPEN] ── 테스트 요청 1개 허용
│
├→ 성공 → [CLOSED] 복귀
└→ 실패 → [OPEN] 유지| 상황 | 서킷 브레이커 동작 |
|---|---|
| API 서버 다운 | 5회 실패 후 차단, 30초 후 재시도 |
| 에이전트 무한 루프 | 같은 도구 10회 연속 호출 시 차단 |
| 토큰 한도 초과 | 즉시 차단, 사용자 알림 |
✦패턴 4: Fallback (대체 경로)
주 경로가 실패할 때 대안적인 방법으로 목표를 달성합니다.
Fallback 체인:
[주 경로] API 호출
│
▼ 실패
[대체 1] 캐시된 데이터 사용
│
▼ 실패
[대체 2] 기본값 반환
│
▼ 실패
[최종] 사용자에게 수동 처리 요청| 실패 상황 | Fallback 전략 |
|---|---|
| 웹 검색 실패 | 로컬 문서에서 검색 |
| 코드 실행 실패 | 다른 접근법으로 재작성 |
| 파일 읽기 실패 | Git에서 이전 버전 복구 |
| LLM API 다운 | 더 작은 모델로 대체 |
✦패턴 5: Graceful Degradation (우아한 저하)
전체 시스템 실패 대신, 가능한 범위까지만 수행하고 나머지를 보고합니다.
요청: "코드 작성 + 테스트 + 문서화 + 배포"
정상 시: 4개 모두 수행
저하 시: 코드 작성 + 테스트만 수행
+ "문서화와 배포는 수행하지 못했습니다" 보고❝아무것도 하지 못하는 것보다, 일부라도 완료하는 것이 항상 낫습니다.
❞
Anthropic의 실전 전략
Anthropic 엔지니어링 팀이 멀티 에이전트 연구 시스템을 운영하며 적용한 전략입니다.
✦모델 지능 활용
💡 핵심 인사이트:
"도구 실패를 에이전트에게 알려주면,
에이전트 스스로 대안을 찾아 적응합니다."
예시:
에이전트: "웹 검색 도구를 호출합니다"
시스템: "검색 실패: 타임아웃"
에이전트: "다른 검색어로 재시도하겠습니다"
(스스로 전략 변경)✦상태 관리 원칙
| 원칙 | 설명 |
|---|---|
| 오류 지점부터 재개 | 처음부터 재시작하지 않음 |
| 견고한 실행 코드 | 장시간 실행 중 상태 유실 방지 |
| 관찰성 확보 | 에이전트 결정 패턴 모니터링 |
✦Rainbow Deployments
기존 에이전트 중단 없이 새 버전을 점진적으로 배포:
v1 ████████████ (100% 트래픽)
v1 ████████ v2 ████ (80:20)
v1 ████ v2 ████████ (40:60)
v2 ████████████ (100%)실전 적용 가이드
✦Claude Code에서의 실패 복구
CLAUDE.md에 실패 복구 전략을 정의할 수 있습니다:
# CLAUDE.md
## 실패 대응 규칙
1. 도구 실행 실패 시 최대 3회 재시도
2. 같은 오류가 3회 반복되면 다른 접근법 시도
3. 복구 불가 시 진행 파일에 상태 기록 후 중단
4. 절대 실패를 숨기지 말 것 - 명확히 보고
## 체크포인트 규칙
1. 기능 단위로 git commit (체크포인트)
2. progress.md에 현재 상태 기록
3. 실패 시 마지막 커밋부터 재개✦실패 복구 체크리스트
| 단계 | 행동 | 설명 |
|---|---|---|
| 1 | 분류 | Transient vs Terminal 판별 |
| 2 | 재시도 | 일시적 오류면 Backoff로 재시도 |
| 3 | 대체 | 재시도 실패 시 Fallback 경로 |
| 4 | 차단 | 연속 실패 시 Circuit Breaker |
| 5 | 보고 | 복구 불가 시 상태 저장 + 사용자 알림 |
✦패턴별 적용 상황
"API 타임아웃이 발생했다"
→ Retry with Backoff
"긴 작업 중간에 세션이 끊겼다"
→ Checkpointing
"외부 서비스가 완전히 다운됐다"
→ Circuit Breaker + Fallback
"일부 작업만 실패했다"
→ Graceful Degradation마치며
✦핵심 요약
| 패턴 | 한 줄 요약 |
|---|---|
| Retry + Backoff | 점진적 간격으로 재시도 |
| Checkpointing | 중간 저장으로 작업 보존 |
| Circuit Breaker | 연속 실패 시 일시 중단 |
| Fallback | 대안 경로로 목표 달성 |
| Graceful Degradation | 가능한 범위까지만 수행 |
✦지금 시작하세요
실패를 방지하는 것이 아니라, 실패로부터 우아하게 복구하는 시스템을 설계하세요. 그것이 견고한 에이전트와 취약한 에이전트의 차이입니다.
실패 복구 체크리스트:
[ ] 오류를 Transient/Terminal로 분류했는가?
- 일시적 오류와 치명적 오류의 구분 기준 정의
[ ] 장기 작업에 체크포인팅을 도입했는가?
- 진행 문서 + Git으로 중간 저장점 확보
[ ] CLAUDE.md에 실패 대응 규칙을 추가했는가?
- 에이전트의 오류 복구 전략 명문화견고한 복구 전략이 곧 견고한 에이전트입니다. 실패했을 때 스스로 복구하고, 부분적으로라도 가치를 전달하는 것 — 그것이 AI 에이전트의 진정한 능력입니다.