AI 에이전트의 무한 반복을 막는 서킷 브레이커와 재시도 전략

AI 에이전트가 도구를 호출하고 결과를 확인한 뒤 다시 판단을 내리는 구조는 여러 단계를 자동으로 처리할 수 있어 유용하지만, 설계가 허술하면 같은 행동을 계속 되풀이하는 상태에 빠지기 쉽다. 찾지 못한 파일을 같은 방식으로 반복해서 검색하거나, 실패한 API 요청을 동일한 파라미터로 다시 보내거나, 테스트가 깨졌는데 원인을 살피지 않고 같은 수정만 되풀이하는 경우가 대표적이다. 이런 반복은 비용과 처리 시간을 늘릴 뿐만 아니라, 결과를 신뢰하기 어렵게 만든다.

사람이 곁에서 지켜본다면 이상 징후를 보고 즉시 멈출 수 있지만, 자동화된 에이전트 파이프라인에서는 멈추는 기준 자체를 시스템 안에 넣어두어야 한다. 이때 필요한 개념이 서킷 브레이커와 재시도 전략이다. 실패했을 때 곧바로 한 번 더 시도하는 대신, 어떤 실패는 재시도할 가치가 있고 어떤 실패는 즉시 멈춰야 하는지를 미리 구분해두는 접근이다.

재시도와 중단을 구분하는 기준

일시적 오류와 구조적 오류는 다르게 다뤄야 한다

재시도는 네트워크 지연, 타임아웃, 일시적인 rate limit처럼 시간이 지나면 자연스럽게 해소될 수 있는 문제에 효과가 있다. 반면 잘못된 인증 정보, 존재하지 않는 리소스, 권한 부족처럼 같은 입력을 다시 보내도 결과가 바뀌지 않는 오류에는 재시도가 의미가 없다. 오히려 같은 실패를 여러 번 반복하며 호출 비용만 늘어난다. 따라서 재시도 전략을 세우기 전에 오류를 임시 오류, 입력 오류, 권한 오류, 모델 판단 오류 정도로 나눠두는 작업이 먼저 필요하다.

서킷 브레이커는 반복을 강제로 끊는 장치다

서킷 브레이커는 일정 조건이 충족되면 더 이상 같은 행동을 시도하지 못하도록 회로를 여는 안전장치다. 예를 들어 동일한 도구 호출이 연속으로 같은 오류를 세 번 반환하면 회로를 열어 자동 재시도를 멈추고, 사용자 확인이나 상위 오케스트레이터의 판단을 기다리게 할 수 있다. 원래 분산 시스템 장애 대응에서 쓰이던 개념이지만, 도구를 반복 호출하는 AI 에이전트 구조에도 그대로 적용할 수 있다.

상태를 기록해야 반복을 판단할 수 있다

반복을 막으려면 에이전트가 직전에 무엇을 했는지 시스템이 알 수 있어야 한다. 도구 호출 이력, 입력 파라미터, 오류 코드, 모델이 다음 행동을 선택한 이유가 기록으로 남아야 지금 시도가 이전 시도와 같은지 판단할 수 있다. 이런 기록이 없으면 매 단계가 처음 겪는 상황처럼 보이기 때문에, 서킷 브레이커 조건을 아무리 잘 정의해도 실제로 작동시키기 어렵다.

실제로 적용하는 방법

재시도 가능한 오류 목록을 명시하기

타임아웃, 429 rate limit 응답, 일시적인 5xx 서버 오류처럼 재시도할 만한 조건을 목록으로 정리해둔다. 반대로 401 인증 실패, 403 권한 부족, 404 리소스 없음, 입력 스키마 검증 실패는 같은 입력으로는 결과가 달라지지 않으므로 재시도 대상에서 제외한다. 이 구분을 코드 로직과 에이전트에게 주는 지침 양쪽에 반영해두면, 모델 스스로도 불필요한 재시도를 줄이게 된다.

지수 백오프와 상한선을 함께 설정하기

재시도 간격은 고정된 시간보다 실패가 반복될수록 대기 시간을 늘리는 지수 백오프 방식이 일반적으로 더 안정적이다. 다만 백오프만 적용하고 최대 재시도 횟수나 최대 대기 시간을 정해두지 않으면, 느리게 진행되는 무한 반복과 다를 바가 없어진다. 작업의 중요도에 따라 상한선을 다르게 설정하는 편이 현실적이다.

동일 입력이 반복되는지 감지하기

같은 도구를 같은 파라미터로 여러 차례 호출했는데도 결과가 달라지지 않는다면, 그 시점에서 다음 단계로 넘어가거나 실행을 멈추도록 설계한다. 검색 쿼리, 파일 경로, API 엔드포인트, 실행한 명령어를 해시 값으로 기록해두면 반복 여부를 비교적 간단하게 판단할 수 있다.

멈춘 뒤의 행동까지 함께 설계하기

서킷 브레이커가 열렸을 때 실패 메시지만 반환하고 끝나면 사용자 입장에서는 무엇이 문제였는지 알기 어렵다. 왜 멈췄는지, 마지막으로 확인된 정보는 무엇인지, 어떤 입력을 주면 다시 진행할 수 있는지를 함께 전달하는 편이 좋다. 자동화 시스템에서는 멈춤도 오류가 아니라 하나의 정상적인 상태로 설계해야 한다.

주의할 점

재시도 횟수를 지나치게 낮게 잡으면 일시적인 오류에도 쉽게 실패로 처리되고, 반대로 지나치게 높게 잡으면 비용과 응답 지연이 함께 커진다. 작업의 중요도와 실패 시 손실을 함께 고려해 기준을 다르게 두는 편이 좋다. 단순 조회성 작업이라면 빠르게 포기해도 무방하지만, 여러 단계로 이어지는 배치 작업의 중간 단계라면 제한된 범위 안에서 조금 더 신중하게 재시도할 수 있다.

또 하나 흔히 놓치는 부분은, 모델이 다른 방식으로 다시 시도했다고 설명하지만 실제 도구 호출 파라미터는 거의 동일한 경우다. 자연어로 된 설명만 신뢰하지 말고, 실제로 전달된 입력값을 기준으로 반복 여부를 판단해야 한다. 에이전트 루프를 통제할 때는 모델의 설명보다 기록된 상태를 기준으로 삼는 편이 훨씬 안정적이다.

정리

AI 에이전트가 같은 행동을 반복하는 문제는 모델 성능을 높이는 것만으로는 해결되지 않는다. 재시도할 만한 오류와 그렇지 않은 오류를 먼저 구분하고, 동일한 실패가 반복될 때 서킷 브레이커로 흐름을 멈추며, 멈춘 이유를 사용자나 상위 시스템에 명확히 전달하는 구조가 함께 필요하다. 잘 설계된 멈춤 기준은 에이전트를 덜 유능하게 만드는 장치가 아니라, 결과를 더 예측 가능하게 만들어주는 장치에 가깝다.