에이전트 워크플로 대체 및 재시도: 심층 비교 및 선택 가이드

fallback과 재시도를 비교해야 하는 이유는 무엇인가요?

에이전트 워크플로를 구축할 때 오류 처리는 피할 수 없는 단계입니다. LLM 호출 시간이 초과되거나, 외부 API가 예외를 반환하거나, 도구 실행에 실패하는 경우 재시도(retry)할지 아니면 대체 경로로 전환(fallback)할지 결정해야 합니다. 잘못된 것을 선택하면 리소스 낭비, 작업 교착 상태 또는 일관되지 않은 결과가 발생할 수 있습니다. 이 기사는 실제 엔지니어링 시나리오를 기반으로 둘 사이의 본질적인 차이점과 적용 가능한 경계를 분석합니다.

대체와 재시도의 정의와 핵심 차이점

폴백(다운그레이드/백업): 기본 경로가 실패하는 경우 미리 정의된 대안을 실행합니다. 예를 들어, LLM 호출이 빈 결과를 반환한 후 규칙 엔진으로 전환하여 응답을 생성합니다. 또는 결제 서비스를 사용할 수 없는 경우 대체 게이트웨이로 전환하세요.

재시도: 임시 실패 복구 후 다시 성공할 것으로 예상하고 실패한 작업을 반복합니다. 예를 들어 네트워크 시간 초과 후 지수 백오프를 다시 시도하거나 LLM 출력 형식이 잘못된 경우 재생성을 시도합니다.

치수	대체	재시도
실행 로직	대체 경로로 전환	현재 경로 반복
적용 가능한 시나리오	복구할 수 없는 오류, 비즈니스 차단이 허용되지 않습니다	복구 가능한 일시적 오류
리소스 소비	일반적으로 높음(백업 리소스 필요)	누적 통화 가능 횟수
지연 시간 영향	전환 시간 + 대체 실행	재시도 간격 × 횟수
성공 확률	백업 경로 신뢰성에 의존	점진적인 부패 또는 평탄화

실제 시나리오: 지능형 고객 서비스 주문 쿼리

에이전트가 주문 상태를 쿼리해야 한다고 가정해 보겠습니다. 먼저 새 주문 시스템을 호출하고 실패하면 이전 시스템으로 대체합니다. 동시에 네트워크 시간 초과와 같은 일시적인 오류의 경우 최대 3번의 재시도가 사용됩니다.

시나리오: 새 시스템이 503(서비스 과부하)을 반환합니다. 이때 재시도를 하면 부하가 늘어나므로 바로 이전 시스템으로 대체해야 합니다. 그러나 새 시스템이 429(현재 제한)를 반환하는 경우 기다렸다가 다시 시도할 수 있습니다. 오류 유형이 구별되지 않는 경우 모든 재시도를 사용하면 눈사태가 발생할 수 있습니다. 모든 대체를 사용하면 기존 시스템이 과부하될 수 있습니다.

결정 포인트: 오류 코드와 상황에 따라 메커니즘을 선택해야 합니다. 실제로 재시도는 클라이언트 오류(시간 초과, 형식 오류 등)에 사용되고 대체는 서버 오류(사용 불가, 인증 실패 등)에 사용됩니다.

가장 쉬운 함정: 무제한 재시도 및 암시적 폴백

Pit 1: 무제한 재시도. 팀은 LLM 호출에 대해 무한 재시도를 설정했습니다. 그 결과 LLM은 계속해서 예외를 반환하고 API 수수료로 수천 위안을 소비했습니다. 올바른 접근 방식: 최대 재시도 횟수(일반적으로 2~3회)와 지수 백오프를 설정합니다.

Pit 2: 암시적 폴백 적용 범위 문제. 예를 들어 대체 경로는 독립적으로 모니터링되지 않으므로 장애가 발생한 후 기본 경로가 자동으로 백업으로 전환됩니다. 백업 자체에도 결함이 있어 사용자도 모르게 잘못된 결과를 얻게 된다. 대체 경로에 대한 로그 및 경보도 기록되어야 합니다.

Pit 3: 멱등성을 무시합니다. 재시도 작업은 멱등적이어야 합니다. 그렇지 않으면 반복 실행으로 인해 중복 주문 및 중복 공제가 발생할 수 있습니다. 작업이 멱등성이 아닌 경우 폴백을 사용하거나 중복 제거 메커니즘을 설계하는 데 우선 순위를 두어야 합니다.

특정 작업: 선택 및 구현 방법

1. 분류 오류 유형. 오류를 일시적(재시도 가능)과 영구적(대체 필요)으로 나눕니다. 예를 들어 네트워크 시간 초과 및 HTTP 503은 즉각적인 것으로 간주됩니다. 인증 실패 및 404는 영구적인 것으로 간주됩니다.
2. 재시도 전략을 설정합니다. 지수 백오프 + 지터를 사용하여 서비스 SLA에 따라 최대 재시도 횟수가 조정됩니다. LLM 통화의 경우 15초 간격으로 23회 통화하는 것이 좋습니다.
3. 대체 경로 설계. 백업 경로의 리소스와 데이터가 독립적이고 제자리에서 모니터링되는지 확인하세요. 예를 들어 결제 시 Alipay를 사용하고 WeChat Pay로 대체합니다(사용자 확인 필요).
4. 복합 사용. 먼저 몇 번 다시 시도하고, 그래도 실패하면 대체를 트리거하세요. 예를 들어 외부 API 호출: 3회 재시도 → 캐시된 결과로 대체.
5. 결정 내역을 기록하세요. 디버깅 및 최적화를 용이하게 하기 위해 각 재시도/대체의 이유, 시간 및 결과를 로그에 기록합니다.

실패 시 대체 계획

둘 다 가능하지 않거나 결정할 수 없는 경우 다음을 고려하십시오.

• 수동 개입: 작업을 보류 중으로 표시하고 개발자에게 수동으로 수정하도록 알립니다.
• 현재 단계 건너뛰기: 비즈니스에서 허용하는 경우 이 작업을 무시하고 후속 단계를 계속 수행합니다.
• 안전한 기본값: 전체 작업 흐름이 중단되지 않도록 합리적인 기본값을 반환합니다.

백업 솔루션에는 로그와 모니터링도 있어야 하며 블랙박스가 되어서는 안 됩니다.

결론

대체 및 재시도는 둘 중 하나가 아니라 보완적입니다. 올바른 접근 방식은 오류 유형과 비즈니스 요구 사항에 따라 조합을 사용하는 것입니다. 즉, 재시도는 일시적인 오류를 처리하고 대체는 지속적인 오류를 처리합니다. 동시에 에이전트 워크플로를 안정적이고 신뢰할 수 있게 만들기 위해서는 경계(재시도 횟수, 시간 초과 시간)를 설정하고, 대체 경로를 모니터링하고, 멱등성을 보장해야 합니다.