LLM 에이전트를 모니터링하기 위해 Lyapunov 안정성 이론을 사용해 보았습니다 — 실제로 효과가 있었던 것과 없었던 것

핵심적인 질문: "이거 그냥 max_iterations 아닌가요?"

이 부분에 대해 먼저 말씀드리겠습니다.

만약 여러분이 단일 LLM과 10번의 도구 호출(tool calls)을 사용하는 ReAct 루프를 구축하고 있다면, 물리 이론에서 영감을 받은 모니터링 라이브러리는 필요하지 않습니다. max_iterations=10으로 설정하고, 예산 상한선(budget cap)을 추가한 뒤 다음 단계로 넘어가면 됩니다. LangGraph, CrewAI, 그리고 모든 현대적인 에이전트 프레임워크는 이미 이를 기본적으로 지원합니다.

제가 state-harness를 만든 이유는 max_iterations가 해결하지 못하는 문제에 직면했기 때문입니다. 그리고 2,367번의 실행을 통해 벤치마킹을 진행한 결과, 이 방식이 할 수 없는 것 또한 알게 되었으며, 이에 대해서도 똑같이 투명하게 말씀드리겠습니다.

max_iterations가 해결하지 못하는 문제

단순한 반복 횟수 제한(iteration caps)이 미치지 못하는 두 가지 구체적인 시나리오가 있습니다.

1. 탐색 트리 에이전트 (Search-Tree Agents: MCTS, Beam Search)

SWE-bench 작업을 해결하거나 Devin과 같은 도구의 기반이 되는 아키텍처와 같은 고급 코딩 에이전트들은 평면적인 루프(flat loop)로 작동하지 않습니다. 이들은 **탐색 트리 (search tree)**를 탐색합니다. 각 노드는 여러 개의 후보 솔루션으로 분기됩니다. 통제력을 잃고 회전하는(spirals) 노드는 단순히 한 번의 턴을 낭비하는 것에 그치지 않고, 모든 하위 분기(downstream branch)를 팽창시킵니다.

50개의 노드로 구성된 탐색 트리에서 max_iterations=50으로 설정하고 상황이 종료되기를 기다릴 수는 없습니다. 에이전트는 반복(iterating)하는 것이 아니라 _분기(branching)_하고 있기 때문입니다. 토큰 사용량은 이차 함수적으로(quadratically) 증가합니다. 단 하나의 막힌 분기만으로도 트리 수준의 예산 상한선이 인지하기도 전에 수천 개의 토큰을 태워버릴 수 있습니다. 분기당 비용은 개별적으로 보면 정상적으로 보이기 때문입니다.

2. 대규모 환경에서의 실패 패턴 집계 (Failure Pattern Aggregation at Scale)

하루에 100개의 에이전트 작업을 실행한다면, LangSmith를 열어 실패한 5개의 트레이스(traces)를 살펴보고 수동으로 디버깅하면 됩니다. 그 방식은 작동합니다.

하지만 하루에 10,000개 이상의 작업을 실행한다면, 수동으로 트레이스를 검사하는 것은 불가능합니다. 관측성(observability) 비용(수백만 개의 멀티 턴 트레이스를 저장하고 인덱싱하는 비용)만으로도 상당한 금액이 됩니다. 여러분에게 실제로 필요한 것은 다음과 같습니다: 실패 패턴을 에지(edge)에서 비용 없이 분류하고, 이를 구조화된 속성(structured attribute)으로 메트릭 파이프라인(metrics pipeline)에 내보내는 것입니다. 그러면 여러분의 Grafana 대시보드에 다음과 같이 표시될 것입니다: "이번 주 실패의 40%는 SQL 도구에 대한 재시도 폭풍(retry storms)입니다 → 지수 백오프(exponential backoff)를 추가하세요."

그것은 max_iterations가 제공해 주는 것이 아닙니다. LangSmith가 제공하는 것도 아닙니다 (적어도 모든 트레이스(trace)에 대해 인덱싱 비용을 지불하지 않는 한 말이죠). 그것이 바로 state-harness가 설계된 목적입니다.

핵심 통찰: 성장률 정규화 (Growth-Ratio Normalization)

물리학에서 Lyapunov 안정성 (Lyapunov stability)은 동적 시스템(dynamical system)이 평형 상태로 돌아갈지 아니면 발산할지를 결정합니다.

저는 LLM 에이전트의 토큰 소비를 누적 토큰 성장(cumulative token growth)의 함수인 "에너지" V(k)를 갖는 동적 시스템으로 모델링했습니다. 안정성 기준은 간단합니다. 연속된 단계에서 에너지 미분값 ΔV ≥ 0 이라면, 시스템은 발산하고 있는 것입니다.

문제점: 모든 멀티턴(multi-turn) 대화에서 토큰 사용량은 컨텍스트 윈도우(context window)에 히스토리가 누적되기 때문에 단조 증가(monotonically grow)합니다. 단순한 Lyapunov 모니터는 모든 정상적인 대화에서도 작동하여 트리거될 것이며, 100%의 거짓 양성(false positives)을 발생시킬 것입니다.

해결책: 가공되지 않은 토큰 수를 모니터링하는 대신, 각 턴을 실행 중인 베이스라인(baseline)에 대해 정규화하여 **성장률 (growth ratio)**을 계산합니다.

• 성장률 ≈ 1.0 → 에이전트가 예상된 속도로 토큰을 소비하고 있음 (안정적)
• 성장률 > 2.0× 가 3회 이상의 연속된 턴 동안 유지됨 → 에이전트가 매 턴마다 불균형적으로 더 많은 토큰을 소비하고 있음 (발산 중)

이 정규화가 핵심적인 통찰입니다. 이는 열역학에서의 강도성 물리량과 외연성 물리량 (intensive and extensive quantities)의 구분과 유사합니다. 즉, 질량(절대적 수치)이 아닌 밀도(비율)를 모니터링하는 것입니다.

통합: 5줄의 코드

from state_harness import GrowthRatioGuard, FailureReport

guard = GrowthRatioGuard(token_budget=50_000)
...

가드(guard)가 트리거되면, 진단 보고서는 LLM 호출 없이 비용 제로로 실패 패턴을 분류합니다:

⚠️  STABILITY TRIPPED at turn 12

Pattern: Context Accumulation Spiral (confidence: 92%)
...

분류된 패턴과 제안된 조치 사항은 OpenTelemetry로 깔끔하게 내보내집니다:

분류된 패턴과 제안된 조치 사항은 OpenTelemetry로 깔끔하게 내보내집니다:

from opentelemetry import trace
span = trace.get_current_span()
span.set_attributes(report.to_otel_attributes())
...

프레임워크 통합 (Framework Integrations)

LangGraph:

from langgraph.prebuilt import create_react_agent
from state_harness.adapters import monitor_graph

...

CrewAI:

from state_harness.adapters import CrewAICallback

callback = CrewAICallback(token_budget=200_000)
...

벤치마크: 효과가 있었던 것과 그렇지 않았던 것 (Benchmarks: What Worked and What Didn't)

저희는 세 가지 벤치마크에 대해 5가지 조건의 제거 연구(ablation study)를 거쳐 총 2,367회 실행 동안 state-harness를 평가했습니다.

효과가 있었던 것: 안정적인 작업에서 거짓 양성 없음 (What worked: Zero false positives on stable tasks)

1,136회의 MINT 실행(단일 루프 추론)과 750회의 τ³-bench 실행(중간 루프 고객 서비스) 전반에 걸쳐 state-harness는 한 번도 오작동하지 않았습니다. 성장률 정규화(growth-ratio normalization)는 이를 안정적인 대화로 정확하게 식별했으며 2% 미만의 토큰 오버헤드만 발생시켰습니다.

이것이 가장 중요한 결과입니다. 건강한 에이전트의 작동을 방해하는 모니터링 도구는 아예 모니터링을 하지 않는 것보다 더 나쁩니다.

효과가 있었던 것: 검색 트리에서의 컴퓨팅 절감 (What worked: Compute savings on search trees)

SWE-bench Verified(37개의 Django 인스턴스, Moatless-tools SearchTree 에이전트, Gemini 2.5 Flash)에서:

조건	컴퓨팅량 (노드 수)	감소율
A. 기준선 (모니터링 없음)	945	—
...

이 모니터는 모든 최대 예산 소진 이벤트(max-budget burnout events)를 제거했습니다(7개 작업이 50노드 상한에 도달 → 0). 또한 벽 시간(wall time)을 30% 줄였습니다.

효과가 없었던 것: 해결률 개선 (What didn't work: Improving resolve rates)

이것은 대부분의 오픈 소스 프로젝트들이 숨기려는 솔직한 부분입니다.

저희는 비결정성(nondeterminism)을 측정하기 위해 조건별로 3개의 독립적인 시도(총 333회 실행)를 수행했습니다:

조건	평균 ± 표준편차 (Mean ± σ)
A. 기준선	44.1% ± 4.1%
...

단순한 예산 제한(naive budget cap)만으로도 유사한 해결률을 달성할 수 있습니다. 조건 간 분산(cross-condition variance, 2.9%)은 조건 내 비결정성(within-condition nondeterminism, 4.1%)보다 작습니다. state-harness는 에이전트를 더 똑똑하게 만드는 것이 아니라 실패를 진단 가능하게 만듭니다.

보너스 발견: 비결정성의 하한선 (Bonus finding: The nondeterminism floor)

τ³-bench와 SWE-bench 모두 코드 작업에 대해 Gemini 2.5 Flash의 **내재적 비결정성 하한선(intrinsic nondeterminism floor)이 약 4~5%**라는 결과로 수렴했습니다. 이는 성능 차이가 8% 미만이라고 보고하는 단일 실행 벤치마크 비교는 통계적으로 신뢰할 수 없음을 의미합니다. 만약 어떤 논문에서 "우리 에이전트가 6% 더 우수하다"라고 주장한다면, 그들이 몇 번의 시행(trials)을 거쳤는지 물어보십시오.

세 가지 메커니즘 (그리고 솔직한 절제 연구 (Ablation))

state-harness는 모두 Rust(PyO3를 통해)로 작성된 세 가지 구성 요소를 가집니다:

1. Lyapunov Monitor (~1μs/step): 위에서 설명한 성장률 에너지 함수 (growth-ratio energy function).
2. RG Decimator (~100μs/compress): 재규격화 군 (Renormalization Group, RG) 이론에서 영감을 받은 TF-IDF 기반의 이력 압축 (history compression).
3. Holographic Engine (~10μs/check): 10,000차원 양극 벡터 (bipolar vectors)를 사용하는 VSA 기반의 의미론적 드리프트 탐지 (semantic drift detection).

솔직한 절제 연구 (Ablation) 결과: Lyapunov 단독으로 전체 이점의 약 90% (38.6% 중 34.4%)를 제공합니다. RG와 VSA는 점진적인 가치를 더해줄 뿐입니다. 최대한의 단순함을 원한다면, 기본 설정으로 GrowthRatioGuard만 사용하고 나머지는 무시하십시오.

누가 사용해야 하는가 (그리고 사용하지 말아야 하는가)

당신이...라면	state-harness를 사용해야 할까요?
챗봇이나 RAG 파이프라인을 구축 중이라면	❌ 아니요. 이것들은 발산(spiral)하지 않습니다.
...

시도해 보세요

• GitHub: github.com/vishal-dehurdle/state-harness
• PyPI: pip install state-harness
• 연구 논문 (Research Paper): vishalvermalabs.com/papers/empirical-lyapunov-stability-agent-failure

제어 이론 (control theory)이 확률적 소프트웨어 (stochastic software)에 유용한 런타임 보장 (runtime guarantees)을 제공할 수 있는지 탐구하는 연구 프로젝트로 구축되었습니다. 대규모로 에이전트를 운영하며 비용 부담 없는 실패 진단 (zero-cost failure diagnostics)을 원하시거나, 혹은 단순히 AI 시스템에 물리학을 적용하는 것에 관심이 있으시다면 여러분의 피드백을 기다립니다.