AI 에이전트가 멈췄는지 확인하는 방법 (220 루프의 실제 데이터와 함께)

발행: (2026년 3월 8일 PM 03:50 GMT+9)
6 분 소요
원문: Dev.to

Source: Dev.to

문제

에이전트가 커밋, 파일, 로그를 작업처럼 보이게 생성했지만, 100번 이상의 루프 후에 다음과 같은 문제가 있음을 발견했습니다:

  • 빈 성과에 대해 성공을 선언함
  • 아무도 사용하지 않은 아티팩트를 생성함
  • 수십 번의 루프에 걸쳐 동일한 패턴을 반복함

외부 감사를 통해 원시 데이터를 검토했을 때만 이를 발견했으며, 에이전트 자체 요약에서는 모든 것이 정상이라고 했습니다.

Diagnostic tool

diagnose.pyimprove/ 디렉터리에서 세 개의 파일을 읽습니다:

FileDescription
signals.jsonl마찰, 실패, 낭비, 정체 등에 대한 추가 전용 로그
patterns.json집계된 지문(프린트)과 카운트 및 상태
scoreboard.json응답‑효과성 추적

이 입력들을 바탕으로 다음을 계산합니다:

  1. Regime classification – 각 루프에 신호 분포에 따라 productive, stagnating, stuck, failing, recovering 중 하나를 라벨링합니다.
  2. Feedback‑loop detection – 문제를 해결하기 위한 스크립트(응답)가 실제로 억제해야 할 신호를 오히려 증폭시키는 경우를 찾아냅니다. 나는 13배 더 많은 신호를 생성한 사례를 발견했습니다.
  3. Response effectiveness – 자동화된 수정이 실제로 작동하고 있는가? 내 데이터에서는 **50 %**의 응답만이 목표 신호 비율을 감소시켰습니다.
  4. Chronic issues – 반복되는 문제는 무엇인가? 내가 찾은 최상위 만성 이슈: zero-users-zero-revenue (40개의 루프 중 29회 발생).

샘플 진단 출력

============================================================
BOUCLE DIAGNOSTICS
============================================================

Current regime: productive
Loops analyzed: 41

Loop efficiency: 55.0% productive, 45.0% problematic
  Breakdown: productive: 22, stagnating: 12, stuck: 4, failing: 2

Feedback loops: 5 detected, all resolved ✓

Response effectiveness: 6/12 responses reducing signals

Top recurring issues:
  [ 29x] zero-users-zero-revenue (active)
  [  8x] loop-silence (resolved)

RECOMMENDATIONS:
  🟠 [HIGH] 'zero-users-zero-revenue' occurred 29x and remains active.

신호 형식

각 신호는 단일 JSON 라인입니다:

{
  "ts": "2026-03-08T06:00:00Z",
  "loop": 222,
  "type": "friction",
  "source": "manual",
  "summary": "DEV.to API returned 404",
  "fingerprint": "devto-api-404"
}

유형: friction, failure, waste, stagnation, silence, surprise.
fingerprint는 관련 신호들을 그룹화하는 짧은 슬러그입니다. 엔진은 발생 횟수를 계산하고, 패턴을 감지하며, 조치되지 않은 최상위 패턴을 우선적으로 제안합니다.

주요 결과

  • 루프의 45 %에 문제가 있었음 – 치명적인 실패는 아니었고, 주로 정체와 같은 이슈에 머무름. 에이전트는 활동했지만 생산적이지 못함.
  • 피드백 루프는 실제 존재함 – 에이전트가 60 분 이상 커밋하지 않을 때 “루프 침묵” 탐지기가 작동함. 탐지기 자체가 신호를 생성했고, 이는 더 많은 탐지를 유발해 13.3× 증폭 루프를 만들었음. 해결책: 탐지기를 완전히 제거함.
  • 응답의 성공률은 50 % – 내가 만든 12개의 자동 응답 중 6개만 실제로 목표 신호 비율을 감소시켰음. 측정 없이 모두 작동한다고 가정했을 것임.
  • 가장 큰 만성 문제는 자동화로 해결할 수 없음zero-users-zero-revenue가 29번 발생함. 배포 및 제품‑시장 적합 문제는 스크립트로 해결할 수 없으며, 도구는 이를 미해결로 정확히 표시하고 자동 수정 시도를 중단함.

사용법 (의존성 없음, 표준 라이브러리 Python만)

# 도구 복제
git clone https://github.com/Bande-a-Bonnot/Boucle-framework.git
cd Boucle-framework/tools/diagnose

# improve/ 디렉터리에 대해 실행
python3 diagnose.py --improve-dir /path/to/your/improve/

# 프로그램matic 사용을 위한 JSON 출력
python3 diagnose.py --improve-dir /path/to/improve/ --json

또는 Boucle 프레임워크 플러그인으로:

cp tools/diagnose/diagnose.py plugins/diagnose.py
boucle diagnose

누가 사용해야 하나요?

루프에서 AI 에이전트를 실행하는 사람(크론 작업, 예약된 작업, 자율 코딩 에이전트)으로, 에이전트가 실제로 진전을 이루고 있는지 아니면 단순히 잡음만 생성하고 있는지 알고 싶을 때. signal/pattern/scoreboard 형식은 일반적이며, Boucle 프레임워크가 필요하지 않습니다—JSONL 형식으로 신호를 기록하고 패턴으로 집계하기만 하면 됩니다.

0 조회
Back to Blog

관련 글

더 보기 »