AI 에이전트의 '킬 스위치'가 불리언(Boolean)을 반환하는 것이 버그인 이유 (Python Circuit Breaker)

저에게 계정을 잃게 만든 루프입니다:

def check_for_lockout(page) -> bool:
    if page.locator("text=Your account is locked").count():
        alert("🚨 LOCKOUT DETECTED")
...

감지기는 작동했습니다. 2026-07-21에 로그 라인이 나타났고, Telegram이 울렸으며, 선택자는 정확히 일치해야 할 것을 일치시켰습니다. 41초 후 while 루프가 돌아왔습니다. 제 봇은 잠긴 플랫폼을 또 사흘 반 동안 계속 건드렸습니다.

여기에는 AI 문제가 전혀 없으며, 이것이 이 글을 쓸 가치가 있는 이유입니다. 모델은 결코 잘못된 판단을 내리지 않았습니다. 버그는 프로그램을 종료해야 할 때 질문에 답하는 함수였습니다.

반환 값은 단지 제안일 뿐

True를 반환하는 감지기는 그 결정을 호출한 사람에게 넘겨줍니다. 이 호출자는 새벽 2시에 작성한 코드일 수도 있고, 재시도(retry) 래퍼일 수도 있고, 나중에 누군가 추가한 try/except 구문일 수도 있으며, 단순히 프로세스를 재시작하는 스케줄러일 수도 있습니다. 조만간 그들 중 하나는 예의 바른 행동을 합니다: 하나의 동작을 건너뛰고, 이를 기록하며, 계속 진행합니다.

만약 어떤 신호가 "멈춰라"를 의미한다면, 동의하지 않는 호출자를 통과할 수 없어야 합니다. 그것은 프로세스를 종료해야 합니다.

같은 수정 사항이 더 큰 실패 클래스에도 적용됩니다. 대부분의 에이전트 재앙은 하나의 치명적인 결정으로 발생하는 것이 아닙니다. 그것들은 카운팅되는 것 없이 너무 오랫동안 반복된 평범한 동작들입니다.

Knight Capital 사례가 교과서적 예시입니다. 2012년 8월 1일, 이 회사의 라우터는 212개의 소매 주문을 154개 주식에 걸쳐 4백만 건 이상의 체결로 만들었습니다: 45분 동안 3억 9,700만 주가 거래되었고, 4억 6천만 달러 이상의 손실이 발생했으며, 나중에 1,200만 달러의 SEC 합의금(SEC 34-70694)을 지불했습니다. 모든 주문은 그 자체로는 유효했습니다. 부족했던 것은 이 분에 전송된 주문과 나가야 할 수량을 비교하는 무언가였습니다.

에이전트 시대의 버전: 2025년 7월, Replit의 코딩 에이전트는 코드 동결 기간 동안 2,400개 이상의 임원 및 회사 기록이 담긴 프로덕션 데이터베이스를 삭제한 후, 롤백은 불가능했다고 말했습니다. 하지만 그것은 사실이 아니었습니다 (The Register). 패턴은 같습니다. 루프는 권한을 가지고 있고, 상위 계층에서 이를 제한하는 것이 없습니다.

일반적인 가드(guard)들이 놓치는 것들

실제로 종료되는 브레이커

# breaker.py
import json, os, sys, threading, time
from collections import deque
...

여기서 몇 가지 선택은 이상해 보이므로 이유를 설명합니다.

sys.exit나 raise가 아닌 os._exit입니다. sys.exit는 SystemExit을 발생시킵니다. 빈 except:는 이를 포착할 것이고, except BaseException도 마찬가지입니다. 워커 스레드에서 호출되면 해당 스레드만 종료합니다. os._exit은 프로세스를 즉시 종료합니다. 이는 finally 블록과 버퍼링된 I/O를 건너뛰기 때문에, 센티넬(sentinel)이 먼저 기록되고 stderr가 플러시되는 것입니다.

스로틀링(throttling)이 아닌 속도 제한(rate)으로 트립하는 것. 일반적인 속도 제한기는 잠들었다가 다시 시도할 것입니다. 에이전트의 경우, 예상되는 자체 속도를 초과한다는 것은 보통 무언가 잘못되었다는 것을 의미합니다: 재시도 폭풍(retry storm), 중복된 레인(duplicated lane), 루프에 갇힌 프롬프트입니다. 잠드는 것은 이를 숨깁니다. 멈추는 것은 당신이 그것을 보게 만듭니다.

센티넬 파일. launchd나 systemd가 KeepAlive/Restart=always로 실행되면, 단순한 종료만으로는 10초 후에 다시 시작되어 같은 루프로 돌아갑니다. 센티넬은 사람이 삭제할 때까지 재시작을 견디게 합니다.

이를 연결하여 감지기가 더 이상 부드러운 답변을 줄 수 없도록 만듭니다:

breaker = CircuitBreaker(max_per_minute=6, max_total=30, max_runtime_s=6 * 3600)

def check_for_lockout(page):
...

모든 레인(replies, posts, DMs, LLM calls)은 하나의 공유된 acquire를 거칩니다. 개별 레인의 제한으로는 세 개의 레인이 각각 80%씩 합쳐져 240%가 된다는 것을 볼 수 없습니다.

Spend: 20개 에이전트가 '예산 초과'를 일으키는 이유

LLM 지출에도 함정이 있습니다. 당연하게 보이는 확인 코드는 다음과 같습니다:

if spent + estimate <= cap:
    resp = client.messages.create(...)
    spent += actual

이 코드를 20개의 동시 워커에 적용하고, 20개 모두가 쓰기(write)를 수행하기 전에 spent 값을 읽는다고 가정해 봅시다. 각각은 예산 내이지만, 합치면 20배 초과입니다. 확인을 더 자주 한다고 해결할 수 없습니다. 호출 전에 돈을 예약(reserve)함으로써 해결합니다:

class Budget:
    def __init__(self, cap_usd):
        self.cap = cap_usd
...

최악의 경우를 예약한 다음 실제 비용으로 정산합니다. 예산 한도에 도달하면 제공업체(provider)는 절대 호출되지 않습니다. 루프 상단에서 RuntimeError를 포착하고, 예산 초과가 전체 실행을 중지해야 하는 경우(which it usually should) breaker.trip()으로 전달하십시오.

만약 이 로직을 직접 유지 관리하기 싫다면, 제가 사용하는 오픈 소스 버전인 baar-core가 있습니다. 이는 요청이 제공업체로 가기 전에 402 에러를 반환하는 원자적(atomic) 사전 점검 한도입니다 (pip install baar-core). 팀을 위한 noburn.dev는 이를 기반으로 각 사용자별 예산을 각 호출 전에 강제 적용하여, 사용자가 한도를 초과하면 다음 달 청구서에 나타나는 대신 차단되도록 합니다.

나를 구했어야 할 테스트

검출기(detector)가 True를 반환하는지 테스트하지 마십시오. 프로세스가 죽는지를 테스트하십시오:

import subprocess, sys

def test_lockout_kills_process(tmp_path):
...

이 테스트는 종료 코드, 누락된 출력 라인, 그리고 센티넬 파일(sentinel file)을 확인하며 몇 밀리초 만에 실행됩니다. 제 원래 검출기도 테스트가 있었고, 모두 통과했습니다. 왜냐하면 그것들은 단지 잠금(lockout)을 감지했는지 여부만 물었기 때문입니다.

시스템의 안전 점검 중 실제로 아무것도 멈추지 않고 '작동'했던 가장 어리석은 방법은 무엇일까요?

원문 출판: https://robatdasorvi.com/stories/why-every-agentic-loop-needs-a-circuit-breaker-and-how-i-built-one