실패는 정보입니다
AI 에이전트가 작업을 완수하려 시도하다가 실패하면, 그 실패 자체에 가치 있는 정보가 담겨 있습니다. API가 429(속도 제한)를 반환했다면, 에이전트에게 속도를 늦추라고 알려 주는 것입니다. 모델이 잘못된 JSON을 생성했다면, 에이전트에게 형식 검증을 추가하라고 알려 주는 것입니다. 파일이 예상 경로에 없었다면, 에이전트에게 작업 전에 경로를 검증하라고 알려 주는 것입니다.
실패를 일회성 이벤트로 다루는 에이전트는 같은 실수를 반복합니다. 실패를 포착하고 거기에서 배우는 에이전트는 점진적으로 더 신뢰할 만해집니다. 그 차이는 실패가 에이전트가 나중에 참조할 수 있는 어딘가에 기록되는지 여부입니다.
실패 분류하기
모든 실패가 똑같지 않으며, 에이전트의 대응은 유형에 따라 달라져야 합니다. 일시적 실패(네트워크 타임아웃, 속도 제한, 일시적 서비스 중단)는 백오프와 함께 재시도를 촉발해야 합니다. 영구 실패(잘못된 자격 증명, 누락된 권한, 지원되지 않는 작업)는 다른 접근이나 에스컬레이션을 촉발해야 합니다. 논리 실패(에이전트의 계획이 잘못되었지, 실행이 잘못된 것이 아닌 경우)는 재계획을 촉발해야 합니다.
분류가 중요한 이유는 실패에 대한 잘못된 대응이 상황을 더 나쁘게 만들기 때문입니다. 영구 실패에 재시도하는 것은 시간을 낭비합니다. 일시적 실패 후 재계획하는 것은 좋은 계획을 낭비합니다. 일시적 실패를 에스컬레이션하는 것은 사람을 불필요하게 귀찮게 합니다.
실패 지식 베이스 구축하기
가장 효과적인 패턴은 실패를 검색 가능한 형식으로 저장하는 것입니다. 무엇이 시도되었는지, 무엇이 잘못되었는지, 근본 원인이 무엇이었는지, 결국 무엇이 동작했는지가 그 내용입니다. 작업을 시도하기 전에 에이전트가 이 지식 베이스에서 비슷한 과거 실패를 검색하고 그에 따라 접근을 조정합니다.
"지난번에 1MB 이상 페이로드로 이 API를 호출했더니 타임아웃이 났다. 해결책은 요청을 더 작은 청크로 묶는 것이었다." 이것이 에이전트의 메모리 시스템에 들어 있다면, 실패한 후 우회책을 다시 알아내는 대신 큰 페이로드를 사전에 묶을 수 있습니다.
피드백 루프
에이전트 실패에 대한 사람의 피드백은 특히 가치가 있습니다. 에이전트가 스스로 알아낼 수 없는 "왜"를 제공하기 때문입니다. "그것이 실패한 이유는 우리 스테이징 환경이 VPN 접근을 요구하기 때문이다"는 에이전트가 시행착오로는 발견할 수 없었을 컨텍스트입니다. 이 피드백을 포착하고 향후 작업을 위해 에이전트에게 제공하면 학습 루프가 닫힙니다.
일부 에이전트 프레임워크는 사용자가 실패한 작업에 주석을 달 수 있는 내장 피드백 메커니즘을 포함합니다. 그 주석은 에이전트의 장기 메모리의 일부가 되어, 향후 비슷한 상황에서의 처리를 향상시킵니다.
잘못된 교훈 피하기
에이전트는 실패에서 잘못된 교훈을 배울 수도 있습니다. API 호출이 일시적인 문제로 한 번 실패했다면, 에이전트가 그 API를 영구적으로 피해서는 안 됩니다. 실패 지식에는 만료일이나 신뢰 수준이 필요합니다. "이 API는 3개월 전에 불안정했다"는 "이 API는 5분 전에 실패했다"보다 덜 관련성이 있습니다.