백그라운드 에이전트를 여러 개 돌리는 개발자라면, 실제 작업과 무관한 곳에서 토큰이 새어 나가고 있을 수 있다. 플레이머릭스 AI(Flamerix AI)가 공개한 MIT 라이선스 도구 'no-agent-summary.js'의 README는, 클로드 코드(Claude Code)가 각 백그라운드 에이전트의 전체 대화 기록을 주기적으로 모델에 되돌려 보내 짧은 상태 문구를 생성하게 만들고, 그 과정에서 상당한 비용이 발생한다고 주장한다. 이 글은 해당 자료를 바탕으로 무엇이 문제이고, 실무자가 어떻게 받아들여야 하는지를 정리한다.
상태표시줄 한 줄에 전체 기록을 보낸다
보고된 동작은 이렇다. 약 30초마다, 실행 중인 모든 백그라운드 에이전트에 대해 클로드 코드가 그 에이전트의 전체 대화 기록(transcript)을 해당 에이전트의 모델(대개 Opus)에 전송하고 "가장 최근 동작을 3~5단어로 설명하라"고 요청한다. 돌아온 답은 에이전트 패널의 상태표시줄만 갱신할 뿐, 모델의 추론이나 사용자의 대화에는 전혀 반영되지 않는다. 즉 결과물에 기여하지 않는 순수 부가 호출인데, 이를 끄는 공식 설정은 없으며 버전 2.1.232(자료 기준 2026년 8월)부터 기본값으로 켜져 있었다고 한다.
핵심은 이 호출의 입력이 '전체 기록'이라는 점이다. 에이전트가 오래 작업할수록 대화 기록은 길어지고, 30초마다 그 긴 입력을 다시 밀어 넣으니 짧은 세 단어짜리 출력과 달리 입력 비용이 계속 불어난다. 백그라운드 에이전트 수가 많을수록 이 효과는 선형 이상으로 누적된다.
측정은 어떻게 이뤄졌나
이 현상은 DRIM이 클로드 코드의 OpenTelemetry 내보내기에서 포착했다고 한다. claude_code.api_request 이벤트를 query_source 기준으로 묶어 보니, agent_summary로 분류된 요청이 메인 대화 자체보다 더 많은 비용을 차지했다는 것이다. 여기서 말하는 '비용'은 청구서상의 금액이 아니라 클로드 코드가 요청마다 자체 추정하는 값(cost_usd)이며, 구독 요금제 사용자에게 실제로 사라지는 것은 돈이 아니라 레이트리밋(rate-limit) 여유분이라는 설명도 덧붙는다. 작업 한도에 더 빨리 도달한다는 뜻이다.
자료는 단일 관측에만 기대지 않는다. 이슈 #86879에 네 건의 독립 측정이 모여 있고 그 범위가 18~26%라고 전한다. 플레이머릭스 자체 텔레메트리에서도 주간 비용 비중이 7월 3.5~7%에서 2.1.233을 받은 주에 7.3%, 이어 11.8%로 올랐고 10월 중순에는 약 16%에 이르렀다고 한다. 수치 편차가 크다는 점은 사용 패턴에 따라 체감 손실이 달라진다는 의미로 읽는 편이 안전하다.
우회 방식과 그 한계
제시된 대응책은 바이너리를 건드리지 않는 Bun 프리로드(preload)다. 약 80줄짜리 스크립트가 setTimeout/setInterval을 감싸, 콜백의 소스 텍스트에 요약 타이머의 특정 문자열(예: [AgentSummary] Timer fired 로그 라인)이 들어 있으면 실제 타이머 대신 작동하지 않는 핸들을 돌려준다. 나머지 타이머는 그대로 통과시킨다. 굳이 코드 수정이나 fetch 가로채기가 아니라 타이머 후킹을 택한 이유도 설명돼 있다. 해당 모듈은 Bun 바이트코드로 미리 컴파일돼 있어 바이너리 안의 JS 텍스트를 고쳐도 소용이 없고, API 클라이언트가 전역 fetch를 거치지 않기 때문이다. 다만 Function.prototype.toString은 바이트코드에서 실행되는 콜백이라도 소스를 돌려주므로, 그 안의 문자열로 타이머를 식별할 수 있다는 것이다. 작동하지 않는 타이머에 2³¹−1밀리초를 쓰는 이유도 흥미롭다. 노드와 Bun은 그보다 큰 지연을 1밀리초로 처리하기 때문에, '무한대'로 설정하면 오히려 즉시 실행돼 버린다.
설치는 BUN_OPTIONS에 --preload를 전역으로 걸거나, PATH 앞단에 claude 래퍼를 두는 방식이다. 데몬과 이미 실행 중인 세션을 모두 재시작해야 적용되며, 정상 적용 시 preload active mode=off 로그가 보여야 한다. 검증은 CC_AGENT_SUMMARY_LOG로 타이머 억제 로그를 확인하거나, OpenTelemetry에서 query_source = agent_summary가 0으로 유지되는지 보는 방법이 제시된다. 자료는 OpenTelemetry 확인만이 모든 실패 모드를 잡아낸다고 못 박는다.
바로 그 지점이 이 도구의 가장 큰 약점이기도 하다. 매칭이 콜백 안의 소스 문자열에 의존하므로, 업데이트가 그 문자열을 바꾸면 후크는 아무것도 걸러내지 못하고 요약 호출이 조용히 되살아난다. 바이너리를 수정하지 않는 대신 업데이트에 취약한 구조인 셈이다. 테스트는 리눅스, 클로드 코드 2.1.257~2.1.312 범위에서만 이뤄졌다는 점, 그리고 클라이언트 런타임 동작을 바꾸는 행위가 서비스 약관과 충돌할 수 있다는 점도 자료가 스스로 경고한다.
실무자가 취할 자세
이 보고는 아직 벤더의 공식 확인을 거친 사안이 아니라 외부 관측과 추정에 기반한 것이다. 그러나 '결과물에 닿지 않는 호출이 레이트리밋을 갉아먹는다'는 문제 제기 자체는 점검해 볼 가치가 있다. 백그라운드 에이전트를 상시 돌리는 팀이라면, 서드파티 스크립트를 바로 설치하기 전에 먼저 자신의 OpenTelemetry 데이터에서 agent_summary 비중을 직접 측정해 보는 편이 낫다. 숫자가 유의미하게 크다면 그때 우회책의 득실과 약관 리스크를 저울질하면 된다. 반대로 비중이 작다면 업데이트마다 깨질 수 있는 후크를 유지보수하는 비용이 더 클 수도 있다. 요지는 남의 측정치를 그대로 믿기보다, 이 도구가 제시한 측정 방법만이라도 자기 환경에 적용해 근거를 확보하는 것이다.