무슨 일이 있었나요
요즘 Claude Code 쓰시는 분들 정말 많죠. 최근에는 에이전트 하나만 붙잡고 일하기보다 백그라운드 에이전트 여러 개를 동시에 띄워서 병렬로 일을 시키는 방식이 점점 흔해지고 있어요. 한쪽에서는 테스트를 고치고, 다른 쪽에서는 문서를 정리하고, 또 다른 쪽에서는 리팩터링을 하는 식으로요.
그런데 한 개발자가 GitHub Gist에 흥미로운 관찰 결과를 공유했어요. 핵심 주장은 “Claude Code가 백그라운드 에이전트마다 트랜스크립트를 정기적으로 모델에 보낸다”는 건데요. 쉽게 말하면 백그라운드에서 돌고 있는 에이전트들의 대화 기록이, 사용자가 따로 요청하지 않았는데도 주기적으로 모델 API로 전송된다는 이야기예요.
“AI 코딩 도구가 모델한테 뭘 보내는 건 당연한 거 아냐?” 싶으실 수 있어요. 그런데 포인트는 누가, 언제, 얼마나 자주 보내느냐예요. 이게 토큰 사용량, 그리고 요금제 한도와 바로 이어지거든요.
트랜스크립트가 뭐길래
트랜스크립트는 에이전트가 지금까지 주고받은 기록 전체예요. 사용자 지시와 모델의 답변은 물론이고, 에이전트가 실행한 도구의 결과물까지 다 들어가요. 읽어 들인 파일 내용, 터미널 명령 출력, 테스트 로그 같은 것들이요. 에이전트가 오래 일할수록 이 기록은 눈덩이처럼 불어나요. 빌드 로그 몇 번 읽고 큰 파일 몇 개만 열어도 금방 수만 토큰이 되거든요.
여기서 알아둘 개념이 하나 있어요. LLM API는 기본적으로 상태가 없는(stateless) 구조예요. 이게 뭐냐면, 모델은 이전 대화를 스스로 기억하지 못하니까 요청할 때마다 필요한 맥락을 통째로 다시 보내줘야 한다는 뜻이에요. 기억을 계속 잃어버리는 동료한테 뭘 물어볼 때마다 지금까지의 회의록을 처음부터 다시 읽게 하는 상황이랑 비슷해요.
그래서 도구가 백그라운드 에이전트의 상태를 파악하려고 트랜스크립트를 주기적으로 모델에 넘긴다면, 예를 들어 “이 에이전트가 지금 뭘 하는 중인지” 한 줄 요약을 화면에 띄우려는 경우라면, 실제 작업과는 별개로 에이전트 수 × 전송 빈도 × 트랜스크립트 길이만큼 비용이 더 붙을 수 있어요. 일종의 ‘관리 비용’이 생기는 셈이에요.
물론 조심해서 볼 부분도 있어요. 이런 요청이 작고 저렴한 모델로 가는지, 프롬프트 캐싱(앞부분이 같은 요청을 재사용해서 비용을 줄이는 기술)이 적용되는지, 어떤 버전과 설정에서 생기는지에 따라 실제 영향은 크게 달라질 수 있거든요. Gist는 한 사용자의 관찰과 분석이니까, 정확한 동작은 본인 환경에서 직접 확인해 보는 게 가장 확실해요.
왜 이렇게 만들었을까
공정하게 보면 이런 설계에는 나름의 이유가 있을 수 있어요. 에이전트를 여러 개 돌리면 각자 지금 뭘 하고 있는지 궁금하잖아요. 그렇다고 수천 줄짜리 로그를 직접 읽을 수는 없으니까, 모델에게 요약을 맡기는 건 꽤 자연스러운 선택이에요. 메인 에이전트가 하위 에이전트의 진행 상황을 보고 다음 작업을 조율하는 데 쓰일 수도 있고요.
결국 쟁점은 투명성이에요. 사용자가 시키지 않은 호출에 토큰이 쓰인다면, 최소한 그 사실과 대략적인 비용은 알 수 있어야 한다는 거죠. 정액 요금제의 사용량 한도 안에서 일하는 분들한테는 “왜 이렇게 빨리 한도에 닿지?”라는 의문의 답이 될 수도 있어요.
업계 전체의 숙제이기도 해요
이건 Claude Code만의 이야기가 아니에요. Cursor, GitHub Copilot 에이전트 모드, OpenAI Codex, Gemini CLI 같은 에이전트형 코딩 도구도 비슷한 고민을 안고 있거든요. 컨텍스트가 길어지면 오래된 대화를 요약해서 줄이는 컴팩션(compaction)이 필요하고, 여러 에이전트를 조율하려면 상태 요약도 필요해요. 이런 ‘눈에 안 보이는 LLM 호출’은 업계 전반에 깔려 있어요.
차이는 그걸 얼마나 드러내느냐예요. 요청 단위로 토큰을 보여주는 도구도 있고, “사용량 몇 %” 정도만 보여주는 도구도 있어요. 에이전트를 병렬로 많이 돌리는 게 일상이 될수록, 오케스트레이션 비용(에이전트를 관리하는 데 드는 비용)을 얼마나 투명하게 보여주느냐가 도구를 고르는 기준이 될 거라고 봐요.
실무에서 해볼 수 있는 것들
첫째, 직접 재 보세요. Claude Code의 /cost, /context 같은 명령으로 세션의 사용 현황을 볼 수 있어요. 백그라운드 에이전트를 켰을 때와 껐을 때를 비교해 보면 바로 체감되실 거예요.
둘째, 회사 도입을 검토하고 있다면 트래픽을 확인해 보세요. 프록시를 거쳐서 어떤 요청이 언제 나가는지 보면, 보안 심사 때도 좋은 근거 자료가 돼요.
셋째, 병렬화는 정말 필요할 때만 하세요. 작업을 서로 독립적으로 쪼갤 수 있는지 먼저 따져 보세요. 에이전트가 늘어날수록 비용은 단순히 더한 것보다 커질 수 있어요.
마무리
한 줄로 정리하면 에이전트를 많이 띄우는 건 공짜가 아니고, 관리 비용까지 계산에 넣어야 한다는 거예요. AI 도구가 자율적으로 움직일수록 사용자가 모르는 사이에 일어나는 일도 늘어나거든요.
여러분은 백그라운드 에이전트를 실무에서 얼마나 쓰고 계신가요? 그리고 AI 도구의 ‘숨은 호출’은 사용자에게 어디까지 공개되어야 한다고 생각하세요?
🔗 출처: Hacker News