서브에이전트 2,393개, 로그 731GiB — 에이전트 폭주의 청구서가 도착했다

에이전트 폭주가 어떤 모습인지 궁금하셨다면, 이제 실물 사진이 있어요. 한 Codex CLI 사용자가 GitHub 이슈 #34061에 올린 수치인데, resume으로 이어 쓰던 부모 세션 하나가 서브에이전트 2,393개를 만들었고, 그 세션 로그만 약 731.5GiB였어요. ~/.codex 디렉토리 전체는 760GB — 1.8TiB짜리 맥 디스크가 99~100%까지 차올랐다고 해요.

지난주에 저는 자율 실행이 기본값이 되면서 경쟁축이 '멈추는 능력'으로 옮겨갔다고 썼어요. 그때는 8시간 폭주라는 시간 단위의 사례였는데, 일주일 만에 기가바이트 단위의 청구서가 도착한 거예요. 그리고 같은 주에 도구 3개가 약속이라도 한 듯 억제 장치를 추가했어요. 이번 글은 그 물증과 대응을 나란히 놓고 읽는 글이에요.

물증: 3분 19초짜리 서브에이전트가 483MB를 썼다

이슈의 수치를 뜯어보면 폭주의 구조가 보여요. 대표 사례로 지목된 서브에이전트 세션 하나는 단 3분 19초 돌았는데 JSONL 레코드 353,255건, 483MB를 기록했어요. 초당 약 1,770건, 2.31MiB씩 쓴 거예요. 원인은 하나가 아니에요. Codex는 모든 세션을 JSONL로 영구 기록하는데, 장수 세션을 resume할 때마다 컨텍스트 압축(compaction)이 전체 히스토리 스냅샷을 다시 저장하고, 도구 출력 원문도 그대로 남아요. 한 파일 안에서 압축 레코드 175건이 571MB를 차지한 경우도 있었어요. 성실하게 기록하는 시스템과 성실하게 증식하는 서브에이전트가 만나면, 하루에 109GiB씩 쌓입니다(7월 11일 실측).

더 눈여겨볼 건 대응 상태예요. 이 이슈(7/18 등록)와 같은 계열의 이전 이슈 두 건(5/28의 compaction 중복, 6/23의 resume 시 전체 재기록)까지 세 건 모두 열려 있고, 확인 시점 기준 메인테이너 응답이 없어요. 해결책은 커뮤니티 워크어라운드뿐이고요. 사용자 보고라는 한계는 있지만, 세 건이 같은 방향을 가리키고 있어요.

같은 주, 3사의 대응은 이미 시작됐다

흥미로운 건 경쟁 도구들의 릴리스 노트예요. 같은 주에 나온 변경들이 정확히 이 문제를 겨냥하고 있거든요.

OpenCode는 깊이를 잘랐어요. v1.18.2부터 서브에이전트가 중첩 서브에이전트를 만드는 걸 기본 차단하고, 필요하면 subagent_depth 설정으로만 풀 수 있게 했어요. 2,393개 같은 숫자는 대부분 에이전트가 에이전트를 낳는 재귀에서 나오니까, 재귀 자체를 기본값에서 제거한 거예요.

Claude Code는 횟수에 캡을 씌웠어요. v2.1.212는 세션당 서브에이전트 생성 한도를 기본 200으로 뒀는데, 릴리스 노트의 표현이 정확히 "runaway delegation loops를 막기 위해"예요. 웹 검색도 세션당 200회 캡이 생겼고요. 이어서 v2.1.215는 /verify와 /code-review 스킬을 에이전트가 스스로 실행하지 못하게 바꿨어요 — 시키지 않은 검증 루프를 도는 과잉 성실함을 껐다는 뜻이에요. v2.1.211엔 이런 항목도 있어요. 백그라운드 에이전트 결과를 보고할 때 "결과를 지어내는 대신 실제 완료를 기다린다." 폭주만큼이나 무서운 게 폭주를 숨기는 보고인데, 그것까지 손댄 거죠.

oh-my-opencode는 기다림에 규율을 넣었어요. v4.18.2의 부제가 "Waiting-Discipline Patch"인데, 문제 사례가 구체적이에요. 긴 세션에서 에이전트가 빈 입력을 91번 폴링하며 매번 약 13.4만 토큰을 태운 실측 로그가 있었대요. 아무것도 안 하면서 컨텍스트 전체를 계속 되새김질한 거예요. 패치 후엔 대기 중 상태 확인이 누적 컨텍스트를 재사용하고, 검증은 입력이 바뀌었을 때만 다시 돌아요.

해석: 정지 조건 다음은 자원 상한이에요

지난주 글에서 3사의 접근을 "런타임 감독 / 사후 제어 / 사전 계약"으로 나눴는데, 이번 주 패치들은 넷째 범주를 추가해요. 자원 상한(budget). 깊이 제한, 스폰 캡, 대기 토큰 절약 — 전부 "무엇을 해도 되는가"가 아니라 "얼마까지 써도 되는가"의 문제예요. 권한 모델이 행동의 종류를 다룬다면, 상한은 행동의 총량을 다뤄요. 폭주 사례가 보여주듯 개별 행동은 전부 정상(로그 기록, 서브에이전트 생성, 상태 확인)이어도 총량이 사고가 되거든요. 토큰의 2%만 코드에 쓰인다에서 다룬 낭비 구조의 끝판이 바로 이거예요.

그리고 이 사건은 서브에이전트가 기본으로 백그라운드에서 도는 시대의 필연적 이면이기도 해요. 안 보이는 곳에서 도는 에이전트는 안 보이는 곳에서 쌓아요. 가시성 없는 자율성의 비용이 디스크라는 가장 물리적인 형태로 나타난 거죠.

이렇게 볼 수도 있어요

유보할 점이 셋 있어요. 첫째, 731GiB는 한 명의 사용자 보고이고 벤더 확인이 없어요. 다만 같은 계열 이슈가 석 달에 걸쳐 세 건이고, 경쟁사들이 같은 주에 관련 장치를 넣은 걸 보면 고립 사례로 치부하긴 어렵다고 봐요. 둘째, 캡 200이라는 숫자에 근거가 제시된 건 아니에요. 정상 사용을 막지 않으면서 폭주를 막는 값이 어디인지는 아직 업계가 감으로 정하는 단계예요. 셋째, 대응의 비대칭이 눈에 띄어요. 문제가 보고된 Codex 쪽은 아직 무응답이고, 장치를 먼저 넣은 건 경쟁 도구들이에요. 이게 개발 우선순위의 차이인지 신호를 놓친 건지는 더 지켜봐야 해요.

한국 개발자 입장에서

오늘 할 일 하나와 앞으로 볼 것 둘을 남길게요. 오늘 할 일 — Codex CLI를 쓰신다면 터미널에서 du -sh ~/.codex/sessions를 한 번 돌려보세요. 저장 공간이 이유 없이 줄고 있었다면 범인이 여기 있을 수 있어요(세션 파일을 지우면 해당 세션의 resume이 영구히 깨지니, 프로세스를 멈추고 백업 후 정리하세요). 앞으로 볼 것 하나 — 도구 선택 체크리스트에 "자원 상한이 기본값인가"를 추가하세요. 옵션으로 있는 것과 기본으로 켜진 것은 사고 확률이 완전히 달라요. 둘 — 조직 도입 품의에는 "에이전트 세션 로그의 보존 정책과 상한"을 질문 항목으로 넣으세요. 지난주엔 정지 조건 명세를 요구하라고 했는데, 이제 한 줄이 더 붙는 거예요. "이 에이전트는 최대 얼마까지 쓰고, 그 기록은 어디에 얼마나 쌓입니까?"

---

근거가 된 소식: openai/codex #34061 — Insane Codex Disk Usage from Subagents, OpenCode v1.18.2, Claude Code v2.1.212·v2.1.215, oh-my-opencode v4.18.2 (발견 경로: GeekNews)