AI 에이전트가 production에 들어가면 가장 먼저 부딪히는 문제는 모델 품질만이 아닙니다. 장애 격리입니다. 외부 API가 느려지고, vector DB가 timeout되고, tool schema가 바뀌고, 모델이 잘못된 인자를 넣습니다. 하나의 거대한 agent loop 안에 모든 책임을 넣어두면 작은 실패가 전체 workflow 실패로 번집니다.
이 글은 AI 에이전트 장애 격리, agent workflow reliability, human in the loop, retry 설계를 찾는 개발자를 위한 운영 가이드입니다. Google ADK와 A2A 예제, OpenAI Agents SDK, Claude Code 같은 최신 도구들이 공통적으로 보여주는 방향은 같습니다. 에이전트도 분산 시스템처럼 설계해야 합니다.
많은 팀이 에이전트 실패를 prompt 문제로만 봅니다. “실패하면 재시도해”, “정확한 tool을 골라”, “모르면 묻지 말고 처리해” 같은 문장을 더합니다. 어느 정도 도움이 될 수는 있지만, production reliability를 보장하지는 못합니다.
장애 격리는 시스템 설계 문제입니다. 어떤 단계가 실패할 수 있는지, 실패하면 어디까지 되돌릴지, 재시도할지, 사람에게 넘길지, partial result를 저장할지 정해야 합니다. 이 결정은 prompt가 아니라 코드와 상태 머신으로 표현돼야 합니다.
예를 들어 계약 검토 에이전트가 계약서를 읽고, 조항을 추출하고, 정책 위반을 검사하고, 보고서를 작성한다고 해봅시다. 정책 검증 API가 죽었을 때 전체 실행을 실패 처리할 수도 있고, 추출 결과를 저장한 뒤 manual review queue로 넘길 수도 있습니다. 둘의 운영 품질은 완전히 다릅니다.
신뢰할 수 있는 에이전트 workflow는 상태가 분명합니다. “작업 중”이라는 하나의 상태로는 부족합니다. 최소한 submitted, working, waiting_external, completed, failed, manual_review 같은 상태가 필요합니다.
Google ADK 예제에서도 계약 컴플라이언스 파이프라인은 INGESTED, EXTRACTED, COMPLIANCE_PENDING, COMPLIANCE_COMPLETE, MANUAL_REVIEW, REVIEW_READY, APPROVED 같은 checkpoint를 둡니다. 이 구조가 중요한 이유는 재시작과 감사가 가능해지기 때문입니다.
상태가 없으면 장애 후 복구는 감에 의존합니다. 어디까지 끝났는지 모르기 때문에 처음부터 다시 돌리거나, 중간 결과를 잃어버립니다. 반대로 checkpoint가 있으면 실패한 단계부터 재시도하거나, 사람 검토로 전환하거나, 사용자에게 현재 위치를 정확히 보여줄 수 있습니다.
Retry는 필요하지만, 무작정 재시도하면 장애를 키웁니다. rate limit이 걸린 API를 즉시 10번 호출하면 상황은 더 나빠집니다. 잘못된 tool argument 때문에 실패한 요청을 반복해도 결과는 같습니다.
실패 유형을 나눠야 합니다. 네트워크 timeout, 429 rate limit, 5xx 서버 오류는 backoff retry 후보입니다. 400 validation error, permission denied, schema mismatch는 재시도보다 수정이나 human intervention이 필요합니다. 모델이 잘못된 JSON을 냈다면 output repair를 한 번 시도할 수 있지만, 반복 실패하면 중단해야 합니다.
좋은 기준은 retry budget입니다. 단계별로 최대 재시도 횟수와 전체 시간 제한을 둡니다. 예를 들어 외부 검색 API는 3회 exponential backoff, 결제 관련 작업은 1회만 재시도 후 사람 검토, 파일 수정 작업은 테스트 실패 시 2회 자동 수정 후 중단처럼 정합니다.
에이전트 시스템에서 사람 검토는 실패의 상징이 아닙니다. 정상 경로 중 하나입니다. 특히 법무, 보안, 금융, 의료, 배포, 고객 환불처럼 오류 비용이 큰 영역에서는 사람 승인이 workflow에 포함되어야 합니다.
중요한 것은 사람이 무엇을 보고 판단할지입니다. “확인해주세요”만 보내면 검토 비용이 큽니다. 에이전트는 입력 요약, 수행한 단계, 실패 원인, 추천 액션, 위험도를 함께 제공해야 합니다. 그래야 사람이 빠르게 승인하거나 수정할 수 있습니다.
또한 승인 이후의 재개 지점도 명확해야 합니다. 사람이 정책 위반 예외를 승인하면 보고서 생성 단계로 넘어갈지, 검증을 다시 돌릴지, 고객에게 별도 메시지를 보낼지 정해야 합니다. human in the loop는 버튼 하나가 아니라 상태 전환 설계입니다.
에이전트 장애 격리에서 logging과 tracing은 선택 사항이 아닙니다. 어떤 tool을 어떤 입력으로 호출했고, 얼마나 걸렸고, 어떤 오류가 났고, 모델이 어떤 결정을 했는지 추적해야 합니다.
단, 모든 것을 그대로 저장하면 보안 문제가 됩니다. prompt와 tool input에는 개인정보, API key, 고객 데이터가 포함될 수 있습니다. 따라서 로그에는 masking, sampling, retention policy가 필요합니다. 운영팀이 원인을 파악할 만큼은 남기되, 불필요한 원문은 줄여야 합니다.
지표도 필요합니다. task success rate, retry count, manual review rate, timeout rate, 평균 처리 시간, tool별 failure rate를 대시보드로 봐야 합니다. 어떤 tool이 자주 실패하는지 알아야 fallback을 만들 수 있습니다.
실무에서 바로 적용하기 쉬운 패턴은 다음과 같습니다.
첫째, tool adapter를 둡니다. 모델이 직접 외부 API shape를 다루게 하지 말고, 내부 함수가 validation과 error mapping을 처리합니다. 둘째, idempotency key를 사용합니다. 결제, 이메일, 티켓 생성처럼 중복 실행이 위험한 작업은 반드시 중복 방지 키를 둬야 합니다. 셋째, side effect와 analysis를 분리합니다. 읽기, 분석, 초안 작성은 자동화하고, 실제 전송이나 삭제는 승인 뒤 실행합니다.
넷째, fallback model 또는 fallback path를 둡니다. 강한 모델이 실패하면 저렴한 모델로 바꾸는 것이 아니라, 경우에 따라 사람 검토나 partial result 반환이 더 맞을 수 있습니다. 다섯째, 각 단계의 입력과 출력을 schema로 고정합니다. schema가 있어야 테스트와 재시도가 가능합니다.
AI 에이전트 장애 격리의 핵심은 “실패하지 않는 에이전트”를 만드는 것이 아닙니다. 실패해도 어디서 멈췄는지 알고, 안전한 다음 경로로 넘기는 workflow를 만드는 것입니다.
실행 체크리스트는 다음과 같습니다.
핵심 키워드는 AI 에이전트 장애 격리, agent workflow reliability, human in the loop, retry budget, 상태 머신입니다. 에이전트 품질은 모델만으로 결정되지 않습니다. 운영 설계가 절반입니다.
