폭주하는 AI 에이전트를 위한 킬 스위치(Kill Switch) 벤치마킹 — 그리고 왜 실제 수치는 퍼센트(%)가 아닌

AI 비용 제어에 대한 주장은 흔합니다. "에이전트 지출을 60% 절감하세요!"라는 문구는 모든 랜딩 페이지에 등장합니다. 그래서 저는 단순한 주장 대신, 여러분이 단 한 번의 명령어로 직접 실행해 볼 수 있는 벤치마크(Benchmark)와 그 수치가 실제로 무엇을 의미하는지에 대한 정직한 해석을 제시하고자 합니다. 헤드라인에 나오는 퍼센트(%)는 가장 흥미롭지 않은 부분이기 때문입니다.

요약하자면 이렇습니다: 저는 동일한 루핑(Looping) 에이전트를 두 번 실행했습니다. 한 번은 보호 장치 없이, 다른 한 번은 엄격한 달러 예산(Hard dollar budget) 뒤에서 결정론적(Deterministic) 제공자를 대상으로 실행하여 지출을 측정했습니다. 그런 다음, 왜 "절감된 %"라는 프레임워크가 이 기술의 가치를 과소평가하는지, 그리고 왜 고정된 상한선(Ceiling)이 실제로 중요한 수치인지를 보여드리겠습니다.

설정 (The setup)

저는 왜 폭주하는 에이전트가 로깅(Logging), 모니터링(Monitoring), 그리고 max_tokens를 통과해 버리는지에 대해 글을 쓴 적이 있습니다. 그것은 단 하나의 이상한 호출 때문이 아니라, 개별적으로는 모두 유효한 수천 개의 호출 때문이며, 이를 막을 수 있는 유일한 방법은 결정론적이고, 호출 전(Pre-call)에 이루어지며, 실행당(Per-run) 적용되는 제한뿐입니다. 이 벤치마크는 바로 그 제한이 제 역할을 수행하는지를 측정합니다.

테스트 프레임워크(레포지토리의 benchmark/)는 두 실행 사이의 유일한 변수가 예산 작동 여부(Budget fired)가 되도록 설계되었습니다:

• 결정론적 제공자 (Deterministic provider). Chat Completions API의 모의(Mock) 환경을 사용하여 매 호출마다 고정된 토큰 사용량(입력 1000 / 출력 1000)을 반환합니다. 네트워크 변동이 없고, 실제 비용이 들지 않으며, 정확하게 재현 가능합니다.
• 고정된 실제 가격. gpt-4o를 정가($1M 입력 토큰당 $2.50 / 출력 토큰당 $10.00)로 설정했습니다. 이에 따라 한 번의 호출 비용은 1000·2.50/1e6 + 1000·10.00/1e6 = $0.0125가 됩니다.
• 모델링이 아닌 측정 (Measured, not modeled). 통제된 실행(Governed run)의 지출은 벤치마크에 의해 계산되는 것이 아니라, 런타임(Runtime) 자체의 비용 장부(GET /v1/runs/{id} -> usage.dollars)에서 직접 읽어옵니다. 런타임은 각 호출을 계측하며, 상한선을 넘게 될 호출이 발생하기 전에 실행을 중단합니다.
• 양쪽 모두 동일한 호출당 가격을 적용하여, 두 수치를 직접 비교할 수 있게 했습니다.

통제된 실행에 $0.25 상한선을 설정한 50회 반복 폭주 에이전트의 경우:

RiskKernel 비용 벤치마크 -- 폭주 루프 (runaway loop)

루프 길이 (N) 50
...

20회 호출 × $0.0125 = 정확히 $0.25. 21번째 호출은 프로세스를 벗어나기 전에 거부되었습니다. 베이스라인(Baseline)은 50회 모두 실행되었습니다.

왜 "60%"는 잘못된 수치인가

60%라는 수치가 헤드라인처럼 보일 수 있습니다. 하지만 그렇지 않습니다. 이는 제가 N(루프 길이)을 설정한 위치에서 비롯된 결과물일 뿐입니다. 저는 50회 호출 루프를 선택했고, 예산 제한이 20회에서 이를 차단했습니다. 루프를 더 길게 만들면 퍼센트는 올라갑니다. 왜냐하면 통제된 지출(governed spend)은 변하지 않기 때문입니다:

폭주 루프가…	베이스라인 지출 (Baseline spend)	통제된 지출 (Governed spend)	절감액 (Saved)
50×	$0.63	$0.25	$0.38 (60%)
...

통제된(governed) 열은 평탄합니다. 그것이 핵심입니다. 폭주 루프는 자연적인 중단 조건이 없습니다. 그것이 바로 폭주를 만드는 원인입니다. 따라서 베이스라인은 사람이 알아차릴 때까지 계속 증가하며, 전형적인 $47K 사고 사례에서는 무려 11일이 걸렸습니다. 당신이 구매하는 것은 퍼센트 단위의 할인이 아닙니다. 그것은 에이전트가 얼마나 심하게 오작동하든, 혹은 누군가가 확인하기까지 얼마나 오랜 시간이 걸리든 상관없이, 당신이 설정한 값을 초과할 수 없는 수치입니다.

따라서 저는 이 분야에서 제가 할 수 있는 주장을 포함하여 "X% 더 저렴함"이라는 주장들을 신뢰하지 않습니다. 퍼센트는 당신이 벤치마크 대상으로 삼은 실패 사례에 전적으로 의존하기 때문입니다. 정직한 보증은 상한선(ceiling)입니다. 즉, 지출은 예산에 의해 제한되며, 그것으로 끝입니다.

이 벤치마크가 정직한 이유 (그리고 이것이 전부가 아닌 이유)

저는 당신이 저자보다 테스트 환경(harness)을 더 신뢰하기를 바랍니다. 그러므로:

• 단 한 번의 명령, 키(key) 불필요, 실제 비용 발생 없음: python3 benchmark/benchmark.py. 모의(mock) 데이터와 가격 책정 파일이 바로 거기에 있습니다. 직접 조사하고, 변경하고, 망가뜨려 보세요.
• 거버넌스(governance) 효과를 격리하기 위해 제공자 지연 시간(latency)과 변동성(variance)을 의도적으로 제거했습니다. 이것은 밀리초(ms)가 아닌 '달러($)'에 관한 벤치마크입니다. 런타임 자체가 추가하는 강제 실행 오버헤드(enforcement overhead)는 미미하며, 이는 별도의 지연 시간 벤치마크에 속하는 사항입니다. 이 벤치마크에 슬쩍 끼워 넣지 않겠습니다.
• 단 하나의 차원, 즉 비용 상한선(cost ceiling)을 측정합니다. "계속 실행해도 안전하다"는 개념의 나머지 절반은 충돌 복구(crash-recovery)입니다. 즉, 장시간 실행 중인 프로세스를 kill -9로 종료한 뒤 재지출 없이 재개하는 기능이며, 이는 이 테스트 환경(harness)이 아닌 examples/kill-9-resume에서 엔드 투 엔드(end-to-end)로 입증됩니다. 시간 기반(timed) 복구 벤치마크가 다음 순서입니다.

핵심 요약 (The takeaway)

에이전트 비용을 제어한다고 주장하는 무엇인가를 평가하고 있다면, 다음 두 가지를 요구하십시오: 테스트 환경(harness) (수치를 재현할 수 있도록) 그리고 상한선(ceiling) (평균값이 아닌 최악의 상황을 알 수 있도록). 재현 가능한 루프 길이(loop length)가 없는 퍼센트(%) 수치는 마케팅일 뿐입니다. 호출 전 거부되고, 컴파일된 코드 내에서 강제되며, 원장(ledger)으로부터 읽어오는 확고한 상한선이야말로 당신이 논리적으로 추론할 수 있는 서비스 수준 협약(SLA)입니다.

런타임은 RiskKernel입니다: 오픈 소스(Apache-2.0), 셀프 호스팅 가능, pip install riskkernel 또는 docker run으로 사용 가능하며, 이미 보유한 에이전트 앞에 환경 변수 하나만 설정하면 됩니다. 벤치마크를 실행한 후, 어디를 더 개선해야 할지 제게 알려주세요. 벤치마크는 사람들이 그것을 망가뜨리려 시도할 때에만 신뢰를 얻을 수 있습니다.