내 AI 에이전트는 세션당 488번 답변했지만, 결과물은 아무것도 내놓지 못했다

AI 코딩 에이전트(AI coding agent)를 처음으로 혼자 실행해 두었을 때, 누구나 당연히 느끼는 공포가 있습니다. '만약 그냥 멈춰버리면 어떡하지?' 라는 공포 말입니다.

구독료만 축내면서, 오지 않을 사람을 기다리며 아무것도 하지 않고 가만히 앉아 있으면 어쩌나 하는 걱정 말이죠.

그래서 저는 그 상황에 대비해 무언가를 만들었습니다. Claude Code를 재시작 루프(restart loop)로 감쌌습니다. 3분 동안 조용해질 때마다 다시 업무로 복귀하도록 독려하는 와치독(watchdog)을 추가했습니다. 정체되지 않도록 훅(hooks)을 조정했습니다. 약 한 달 동안, 제 노력의 거의 전부가 단 하나의 목표, 즉 **'기계가 절대 유휴 상태(idle)가 되지 않게 하는 것'**에 집중되었습니다.

효과는 있었습니다. 기계는 거의 유휴 상태가 되지 않았습니다.

그러던 어느 저녁, 저는 첫날부터 했어야 했던 일을 했습니다. 한 달 동안 어떻게 진행되었는지에 대한 제 인상을 믿는 것을 멈추고, 직접 숫자를 세어 보았습니다.

로그를 통해 본 '생산적인' 자율성의 한 달

Claude Code가 실행되는 모든 세션은 ~/.claude/projects/*/*.jsonl 경로의 디스크에 트랜스크립트(transcript)를 남깁니다. 저는 제 로그 전체에 대해 15줄짜리 스크립트를 실행했습니다. 저에게 유리하게 반올림하지 않고 있는 그대로 적겠습니다:

• 295개 세션, 약 32일에 걸쳐 진행.
• 세션당 중앙값(Median) 488개의 어시스턴트 응답(assistant responses). ('어시스턴트 응답'은 도구 호출, 결과 읽기, 결정, 다음 호출로 이어지는 하나의 실제 작업 턴(turn)을 의미합니다.)
• 295개 세션 중 252개(85%)가 100개 이상의 응답을 생성.
• 말 그대로 아무것도 하지 않은 세션 — 응답 0개: 6개. 2%.

이 중앙값을 곱씹어 보십시오. 중간값에 해당하는 세션에서 488번의 작업 턴이 일어났습니다. 제가 관찰해 온 유일한 지표인 '이게 작동하고 있는가?' 라는 관점에서는 이것은 승리였습니다. 기계는 유휴 상태가 아니었습니다. 기계는 마치 소방 호스(firehose)처럼 쏟아져 나오고 있었습니다.

저는 겨우 2%의 확률로 발생하는 실패 모드(failure mode)를 방어하기 위해 한 달을 보낸 것입니다.

장부의 다른 한 면

같은 달, 같은 기계였습니다. 실제로 결과물로 나온 모든 것은 다음과 같습니다:

• ~/products/ 아래에 생성된 47개의 제품 폴더.
• 작성, 편집을 마치고 게시를 기다리고 있는 36개의 완성된 초안.
• 누적 매출 ¥6,144.
• 제가 기록하기 시작한 결과 장부(outcome ledger)에 기록된 판매량 0건.

47개의 제품 폴더. 완료되었지만 한 번도 발송되지 않은 36개의 초안. 이것이 295번의 세션 동안 세션당 488번씩 이어진 끊임없는 활동이 쌓아 올린 결과였습니다. 독자, 사용자, 혹은 구매자가 단 한 번도 본 적 없는 거대한 작업 재고(inventory) 말입니다.

소방 호스가 바닥을 향해 쏟아지고 있었던 것입니다.

내부에서는 동일하게 느껴지는 두 종류의 숫자

여기에 명확한 함정이 있습니다. 에이전트는 두 종류의 숫자를 키울 수 있으며, 세션 안에 있는 동안에는 이 두 숫자가 똑같이 느껴집니다.

첫 번째 종류는 움직임(motion)을 측정합니다: 응답(responses), 도구 호출(tool calls), 커밋(commits), 수정된 파일, 작성된 초안 등입니다. 이것들은 비용이 저렴합니다. 쉬지 않고 움직이는 에이전트는 이를 무제한으로 늘리며, 모든 증가분은 마치 진전(progress)처럼 느껴집니다. 세션은 바빴고, 커밋 횟수는 올라갔습니다. 분명 무언가 일어나고 있었습니다.

두 번째 종류는 외부 가치(outward value)를 측정합니다: 게시된 것, 판매된 것, 실제 사람이 반응한 것들입니다. 이것들은 비용이 많이 듭니다. 그리고 잔인한 점은, _에이전트가 더 열심히 일한다고 해서 이 숫자를 키울 수는 없다_는 사실입니다. 게시를 하려면 자신의 작업을 판단(judgment)의 대상에 노출하겠다는 결정이 필요합니다. 판매를 하려면 반대편에 누군가가 있어야 합니다. 그 어떤 양의 내부적 움직임도 스스로 그 간극을 메울 수는 없습니다.

자율 에이전트(autonomous agent)는 당신이 무엇을 진전으로 간주하도록 허용하느냐에 따라 그것을 최적화합니다. 만약 "진전"이 움직임을 의미한다면, 에이전트는 당신에게 움직임을 제공할 것입니다. 외부 숫자가 0에 머물러 있고 당신이 기계가 얼마나 열심히 일하는지 스스로를 축하하는 동안에도, 세션당 488번의 응답을 쏟아내면서 말이죠. 제가 유휴 상태(idleness)를 방지하기 위해 만든 바로 그 기능이 함정을 _더욱 악화_시켰습니다. 지치지 않는 기계는 게으른 기계보다 훨씬 더 빠르게, 안도감을 주는 움직임을 생성하기 때문입니다.

이것은 Claude Code의 문제가 아닙니다. 어떤 자율 작업자에게 무엇을 측정하라고 말하느냐의 문제입니다. 하지만 에이전트는 이 문제를 더욱 심각하게 만듭니다. 왜냐하면 에이전트는 움직임을 진전으로 착각하게 만들던 자연스러운 마찰력—지루함, 피로, 잡무를 하기 전의 인간적인 멈춤—을 제거해 버리기 때문입니다.

당신의 기계에서 직접 측정하세요

제 488번이라는 수치를 맹신하지 마세요. 만약 여러분이 Claude Code를 실행한다면, 동일한 주장을 여러분 자신의 로그(logs)를 통해 확인할 수 있습니다. 이것은 단지 읽기만 할 뿐, 아무것도 변경하지 않습니다.

import glob, os, statistics
counts = []
...

이제 그 중앙값(median)을 오직 여러분만이 만들어낼 수 있는 숫자와 나란히 놓아보세요. 같은 기간 동안 이 기계가 실제로 실제 사람에게 전달한 결과물은 몇 개인가요? 발행된 포스트, 판매, 누군가에게 도움이 된 답변 같은 것들 말입니다. 만약 첫 번째 숫자는 크고 두 번째 숫자가 0에 가깝다면, 여러분은 바닥을 향해 쏟아지고 있는 소방 호스(firehose)를 발견한 것입니다.

해결책은 더 빠른 기계가 아니라, 다른 점수판입니다

탈출구는 더 많은 훅(hooks)이나 더 촘촘한 재시작 루프(restart loop)가 아닙니다. 에이전트가 비싼(expensive) 숫자를 세도록 만드는 것입니다. 제 사례를 변화시킨 단 하나의 변화는 바로 **결과 장부 (outcome ledger)**였습니다. 이는 publish(발행), sell(판매), release(출시), 그리고 real reaction(실제 반응)만이 유효한 이벤트로 기록되는, 오직 추가(append)만 가능한 단일 파일입니다. 도구 호출(Tool calls)은 여기에 기록되지 않습니다. 커밋(Commits)도 기록되지 않습니다. 초안(Drafts)도 기록되지 않습니다. 에이전트의 진척도가 그 파일에 의해 측정될 때, "헬퍼 함수를 세 번째로 리팩터링했습니다"는 승리처럼 보이지 않게 되며, "아직 아무도 이것을 보지 못했습니다"라는 사실이 가시화됩니다.

저는 이 내용의 전체 버전—장부, 위험한 행동 전에 실행되는 게이트(gate), 침묵하는 실패(silent-failure) 탐지, 그리고 컨텍스트 윈도우(context-window) 경계를 생존하는 법—을 실제 로그를 기반으로 구축한 짧고 솔직한 책으로 작성했습니다. 동반 리포지토리(companion repo)는 무료이며 바로 실행 가능합니다 (위의 카운터, 확장된 verify.py, 그리고 첫 번째 장의 전체 내용 포함):

👉 github.com/yurukusa/autonomous-claude-ops

만약 여러분이 에이전트를 무인으로 실행하고 있거나 곧 실행할 예정이라면, 먼저 두 가지 숫자를 세어보세요. 움직임에 관한 숫자는 여러분을 기분 좋게 할 것입니다. 하지만 외부로 향하는 숫자가 여러분의 사용자가 유일하게 보게 될 숫자입니다.