AI Watchdog: AI 코딩 에이전트를 모니터링하고 생산성을 높이는 방법

저는 AI 코딩 에이전트(Kilo, Claude Code, Codex, Aider, 그리고 저만의 스크립트)를 많이 사용합니다. 그런데 항상 같은 문제에 부딪혔습니다.

작업을 시작하고 자리를 비웠다가 20분 후에 돌아와서, 그 에이전트가 정말 잘 작동하는 건지, 저를 기다리고 있는 건지, 아니면 토큰을 소모하며 무한 재시도 루프에 빠진 건지 모르는 상태로 터미널만 바라보고 있게 되는 겁니다.

그래서 제가 항상 존재하기를 바랐던 것을 직접 만들었습니다.

AI Watchdog — AI 코딩 에이전트를 위한 실시간 가시성 및 개입 시스템입니다. 이 도구는 에이전트가 수행하는 모든 것을 수집하고, 다중 신호 신뢰 모델(multi-signal confidence model)을 통해 작동 중인지/대기 중인지/진짜로 막혔는지 판단하며, 결과에 실제로 영향을 미치는 순간에만 사용자에게 알림을 보냅니다.

왜 '막힘 감지(stuck detection)'가 어려운가

'5분 동안 출력이 없으면 → 막힘'이라는 단순한 규칙은 틀렸고, 저는 이 기능을 배포하는 것을 거부했습니다. 에이전트는 컴파일, 의존성 설치, Docker 실행, 또는 긴 테스트 스위트(test suite)를 진행하는 동안 정상적으로 조용할 수 있기 때문입니다. 이런 기준으로 알림을 보내면 하루 만에 도구 사용을 중단하게 될 것입니다.

그래서 Watchdog은 독립적인 감지기들의 가중치 결합 앙상블(weighted ensemble of independent detectors)을 실행하며, 각 감지기는 설명 가능한 신호(explainable signal)를 생성합니다:

신뢰도는 트리거된 가중치들의 제한된 합(clamped sum)이며, 모든 기여 가중치는 추적 가능하므로 UI는 항상

가장 자랑스러운 부분은 산술 계산이 당신에게 유리하게 작동한다는 것입니다. 'Total silence(총 침묵)' 점수는 55점입니다—60점 임계치보다 5점 낮습니다. 파일 변경 없이 코드를 실행한 경우 65점을 기록하며 기준을 넘었습니다. 침묵 자체가 증거는 아닙니다. 그것은 설계 규칙이었지, 조정 과정에서 발생한 우연이 아니었습니다.

주요 기능
Live Command Center — WebSocket을 통해 모든 실행 과정을 스트리밍합니다.
Trace view — 전체 이벤트 트리를 제공하여 어느 순간에 문제가 발생했는지 정확히 볼 수 있습니다.
하나의 명령어로 어떤 에이전트든 연결할 수 있습니다: watchdog wrap -- kilo run "fix the failing test" Kilo, Claude Code, Codex, Aider, OpenCode, npm test, 사용자 지정 스크립트 등. 표준 입력(stdin)은 그대로 전달되고, 종료 코드는 전파되며, 15초마다 하트비트가 발생합니다.
TypeScript + Python SDK — 기존 에이전트를 측정하는 데 단 다섯 줄의 코드가 필요합니다.
VS Code 확장 프로그램 — 터미널 명령 및 파일 변경 사항을 지원합니다.
5가지 모드를 가진 '멈춘 에이전트 시뮬레이터'를 통해 신뢰하기 전에 감지기(detector)를 검증할 수 있습니다.
구조적으로 멀티테넌시(Multi-tenant by construction) — 모든 리포지토리 메서드에 organizationId가 필수입니다. 따라서 이를 누락한 메서드는 컴파일되지 않습니다.
Fail-closed redaction — 만약 마스킹 모듈을 로드할 수 없다면, 원본 비밀 정보를 저장하는 대신 예외(throws)를 발생시킵니다.
~1,500개의 테스트 케이스가 있으며, E2E에서 아무것도 목업(mocked)하지 않았습니다—실제 API 프로세스, 실제 Postgres, 실제 WebSocket, 실제 자식 CLI(child CLI)를 사용합니다.

솔직히 어려웠던 부분들
저는 크로스-테넌트 읽기 오라클을 배포한 후 그 문제를 발견했습니다. 스코프가 지정되지 않은 전역 UNIQUE(dedupe_key)는 누구나 추측할 수 있게 만들었습니다: 다른 테넌트의 알림을 읽을 수 있었습니다. 이를 (organization_id, dedupe_key)로 재스코프(Rescoped)하여 수정했습니다.

제 파티션 헬퍼는 개발 데이터베이스를 삭제할 수도 있었습니다. 모든 스키마에서 pg_class가 일치했기 때문에, 병렬 테스트 스키마가 프로덕션 파티션을 삭제하는 문제가 발생했습니다. 저는 이것을 이론화하기보다 직접 관찰했습니다. 이제는 current_schema()에 고정했습니다.

상태 쓰기는 비교-설정(compare-and-set) 방식이 아니었습니다—읽기 후 쓰기 경쟁 조건(read-then-write race). 이제는 UPDATE ... WHERE id=$1 AND state=$2를 사용합니다.

의도적인 편차: Next.js는 사용하지 않습니다 (SSR은 인증이 필요한 실시간 SPA에 아무것도 제공하지 않음). ORM도 사용하지 않습니다 (직접 작성한 SQL을 사용하여 결정론적이며, 월별 RANGE 파티셔닝 및 CAS에 대한 완전한 제어권을 가집니다). 그리고 감지 엔진은 순수합니다 — DB도, 네트워크도, process.env도 없습니다 — 이것이 바로 이를 포괄적으로 테스트 가능하게 만드는 요소입니다.

아무도 보지 못하는 핵심 디테일: 히스테리시스(hysteresis) 상태를 영속화하는 것이 중요한 쓰기 작업입니다. 이 과정을 건너뛰면 STUCK 감지가 조용히 절대 작동하지 않습니다.

다음 계획:

• sweeper를 실제 BullMQ 워커로 추출하고 자문 잠금(advisory locks)을 적용하여 여러 API 복제본이 중복으로 sweeping하는 것을 방지합니다.
• 실제 어댑터 기능 활성화 — 현재 모든 어댑터에서 supportsPauseResume 및 supportsProcessMetrics는 false입니다. 저는 꾸미기보다는 정직한 기능 매트릭스를 제공하고 싶습니다.
• 에디터 기반 에이전트를 위한 실제 관측 가능성 루프(observability loop) — VS Code 확장 프로그램은 다른 확장 프로그램 내부의 채팅 트래픽을 볼 수 없습니다 (Kilo, Cline, Roo). 이를 노출하는 API가 없기 때문에 현재로서는 localhost 브릿지 및 터미널/파일 신호가 정직한 한계입니다.
• SSO/MFA, 감사 로그(audit logs), 더 풍부한 알림 규칙, 심층적인 CI 통합

오픈 소스로 공개하는 이유:
흥미로운 부분 — 즉 감지 방법론, 가중치 테이블, 억제 규칙, 히스테리시스 설계 — 은 방어하기보다 공유할 때 더 가치가 있습니다.

LLM 추적 도구는 모델 호출은 보지만 에이전트가 실제로 막히는 쉘(shell), 파일, git 활동은 볼 수 없습니다. APM 도구는 에이전트 실행 자체를 모델링하지 않습니다. 에이전트 플랫폼은 폐쇄적이고 단일 공급업체에 의존합니다. 아무도 중립적이고 실행 중심적인 계층을 소유하고 있지 않습니다. 저는 이 부분이 되기를 바랍니다.

→ https://aiwatchdog.vercel.app/ 에서 사용해 보세요.

만약 에이전트가 작동하는지 궁금해서 20분을 날려본 적이 있다면, 듣고 싶습니다. 그리고 만약 당신의 에이전트가 Watchdog이 아직 이해하지 못하는 무언가를 한다면, 알려주세요 — 그 보고서들이 말 그대로 로드맵입니다.