AI 에이전트에게 서킷 브레이커 (Circuit Breakers)가 필요하다고 깨달은 날

사람들이 AI 에이전트 (AI agents)에 대해 이야기할 때, 대화는 보통 추론 (reasoning), 계획 (planning), 메모리 (memory), 그리고 도구 사용 (tool usage)을 중심으로 흘러갑니다.

하지만 에이전트가 잘못되었을 때 어떤 일이 발생하는지에 대해서는 훨씬 적게 논의됩니다.

몇 달 전, 자율 워크플로 (autonomous workflows)를 실험하던 중 흥미로운 점을 발견했습니다. 에이전트가 극적인 방식으로 실패하는 것은 아니었습니다. 충돌 (crashing)이 일어나는 것도 아니었고, 예외 (exceptions)를 던지는 것도 아니었습니다.

그저 더 열심히 시도하고 있을 뿐이었습니다.

도구 호출 (tool call)이 실패했습니다.

에이전트는 재시도했습니다.

그것 역시 실패했습니다.

그래서 에이전트는 새로운 계획을 생성하고, 다시 재시도하고, 더 많은 도구를 호출하고, 더 많은 추론 (reasoning)을 생성하며 계속해서 소용돌이 속으로 빠져들었습니다.

외부에서 보기에는 생산적으로 보였습니다. 하지만 내부적으로는 루프 (loop)에 갇혀 있었습니다.

그 순간이 제가 서킷 브레이커 (circuit breakers)에 대해 생각하기 시작한 시점이었습니다.

대부분의 엔지니어들은 분산 시스템 (distributed systems)에서의 서킷 브레이커에 익숙합니다. 서비스가 계속 실패하면, 우리는 해당 서비스로의 요청을 중단합니다. 하나의 실패하는 의존성 (dependency)이 전체 시스템을 무너뜨리도록 내버려 두지 않습니다.

AI 에이전트도 동일한 처우를 받아야 합니다.

자율 에이전트 (autonomous agent)는 API를 호출하고, 인프라를 배포하며, 리소스를 수정하고, 토큰 (tokens)을 소비하며, 워크플로를 트리거할 수 있습니다. 가드레일 (guardrails)이 없다면, 작은 실수가 빠르게 값비싼 실수로 이어질 수 있습니다.

애플리케이션 배포를 담당하는 에이전트를 상상해 보십시오.

배포가 실패합니다.

에이전트는 재시도합니다.

여전히 실패합니다.

설정을 변경하고 다시 재시도합니다.

이제 에이전트는 모든 행동이 상황을 악화시키는 사이클 (cycle)에 진입했습니다.

문제는 모델이 지능적이지 않다는 것이 아닙니다.

문제는 경계가 없는 지능은 예측 불가능하다는 것입니다.

서킷 브레이커는 그러한 경계를 도입합니다.

일정 횟수 이상의 실패 시도가 발생하면 실행을 중단할 수 있습니다.

비용이 예산을 초과하면 워크플로를 일시 중지할 수 있습니다.

프로덕션 리소스 (production resources)를 건드리기 전에 인간의 승인을 요구할 수 있습니다.

추가 검증이 수행될 때까지 위험한 행동을 차단할 수 있습니다.

가장 좋은 점은 서킷 브레이커가 에이전트의 자율성을 낮추지 않는다는 것입니다.

그것들은 에이전트를 신뢰할 수 있게 만듭니다.

AI 에이전트가 점점 더 유능해짐에 따라, 우리는 그들에게 어떻게 행동해야 하는지를 가르치는 데 많은 시간을 할애하고 있습니다.

우리는 그들에게 언제 멈춰야 하는지를 가르치는 데에도 동일한 시간을 할애해야 합니다.

왜냐하면 프로덕션 시스템 (production systems)에서는, 다음에 무엇을 해야 하는지를 아는 것보다 언제 멈춰야 하는지를 아는 것이 종종 더 가치 있기 때문입니다.