내 에이전트는 아무것도 하지 않으면서 Slack에서는 '성공' 중이었다 — 이를 잡아낸 모니터링 스택

D1의 행(row) 수가 완전히 멈춰 있는 동안에도 내 Slack 봇은 성공 메시지를 보내고 있었습니다. 에이전트가 충돌(crashing)한 것이 아니었습니다. Slack 알림 단계는 완료하고 실제 작업은 모두 건너뛰고 있었던 것입니다. 알림(Alerts)만으로는 절대 이를 잡아낼 수 없었을 것입니다.

해결책은 Slack, D1 로깅, 그리고 비용 추적(cost tracking)을 세 개의 별개 도구가 아닌 하나의 연결된 파이프라인으로 취급하는 것이었습니다. 제가 최종적으로 결정한 스키마(schema)는 의도적으로 가볍게 구성되었습니다. 7개의 컬럼으로 이루어져 있으며, 그중 tokens_used가 가장 중요한 역할을 합니다:

CREATE TABLE agent_runs (
  id          TEXT PRIMARY KEY,
  agent_name  TEXT NOT NULL,
...

D1에 tokens_used가 없다면, 비용 대시보드(cost dashboard)는 오늘 얼마를 썼는지만 알려줄 뿐, 어떤 에이전트가 그 비용을 소모했는지는 알려주지 않습니다. 저는 제 분석 도구의 월간 Claude 비용을 약 20달러 정도로 심리적으로 추정하고 있었습니다. 실제 수치는 38달러였습니다. 로그에 대해 집계 쿼리(aggregation query)를 실행하기 전까지는 전혀 알지 못했습니다.

저를 괴롭혔던 또 다른 문제는 MCP stdio 전송(transport) 타임아웃(timeouts)이었습니다. 저는 며칠 동안 이것이 OAuth 설정 오류라고 확신하며 시간을 보냈습니다. 하지만 아니었습니다. 한 도구가 가끔 30초 이상 걸리는 외부 API를 호출하고 있었습니다. stdio 전송의 읽기 타임아웃(read timeout)은 그보다 짧았고, Workers의 30초 벽 시계 제한(wall clock limit)이 상황을 악화시켰습니다. 그 결과 서브프로세스(subprocess)가 오해의 소지가 있는 종료 코드(exit code) 1번과 함께 강제 종료되었습니다. D1에 쌓여가는 timeout 상태 행들이 실제로 이 패턴을 드러내 주었습니다. 해당 로그가 없었다면, 이는 그저

저는 2분 만에 12,000건의 쓰기 작업을 기록한 KV 쓰기 폭발 (KV write explosion) 현상과 이를 D1을 사용하는 특정 에이전트로 추적해낸 과정, 그리고 느린 도구 (slow tools)를 위한 Durable Object 리팩토링 (refactor) 내용을 포함한 전체 분석 내용을 riversealab.com에 작성했습니다.

전체 포스트 보기 →