세션 로그 731GB, 디스크를 채운 서브에이전트

코덱스 CLI(Codex CLI)로 장시간 작업하던 이용자의 디스크가 세션 기록만으로 가득 찬 사례가 보고됐다. 재개된 부모 세션 하나가 서브에이전트 세션 파일 2,393개를 만들었고, 이 파일들의 크기 합계가 약 731.5GiB에 달했다. 전체 세션 디렉터리는 약 755GiB까지 불어나 1.8TiB 볼륨 사용률이 99~100%에 도달했다. 관련 깃허브 이슈는 7월 20일 기준 여전히 열려 있으며, 재현 버전은 코덱스 CLI 0.144.6으로 표기돼 있다.

무슨 일인가 / 배경

코덱스 CLI는 나중에 세션을 다시 열 수 있도록 대화와 실행 이력을 JSONL 형식 파일로 남긴다. 문제는 이 기록이 캐시가 아니라는 점이다. 지워버리면 과거 세션을 다시 열 수 없으므로, 용량이 찼다고 무작정 삭제하기 어렵다.

증가 속도는 가팔랐다. 보고된 사례에서 7월 11일 하루에 약 109.1GiB, 다음 날에는 약 149.2GiB의 세션 데이터가 생성됐다. 7월 디렉터리에는 세션 파일이 약 2,931개 있었고 그중 797개가 개당 400MiB를 넘었다. 조사 시점에 문제의 부모 프로세스는 약 23시간째 실행 중이었다.

핵심 짚어보기 — 거대한 파일이 아니라 이벤트 폭증

분석에서 흥미로운 부분은 용량이 쌓인 방식이다. 거대한 기록 하나가 파일을 채운 것이 아니었다. 대표 사례로 제시된 서브에이전트 하나는 3분 19초 남짓 실행됐는데, 그 사이 약 4억 8천만 바이트 분량에 35만 3천여 개의 레코드를 남겼다. 초당 1,770여 건, 2.31MiB에 해당하는 기록량이다. 내역을 보면 토큰 집계 이벤트가 18만여 개, 에이전트 메시지가 10만여 개, 패치 적용 종료 이벤트가 3만여 개였다. 짧게 실행된 작업 하나가 사용자가 실제로 본 활동량보다 훨씬 많은 이벤트를 남긴 것이다.

신고자는 증폭 요인을 몇 가지로 추정했다. 서브에이전트별 이벤트가 중복 기록되는 문제, 문맥 압축 이력이 원본 도구 출력과 함께 반복 저장되는 문제, 세션을 재개할 때 과거 이력이 새 파일에 다시 쓰이는 문제다. 실제로 다른 이슈에서는 압축 이력 반복 저장으로 단일 파일이 732MB까지 커진 사례가, 또 다른 이슈에서는 2GB가 넘는 세션을 재개하자 새 날짜 폴더에 2.3~2.4GB 파일이 다시 생성된 사례가 보고됐다. 다만 공식적인 원인 분석은 아직 공개되지 않았고, 위 내용은 파일을 직접 뜯어본 신고자의 추정이다.

1인기업 실전 적용 포인트

• 지금 바로 용량부터 재라. du -sh ~/.codex/sessions로 전체 크기를, du -sh ~/.codex/sessions/*/*로 월별 크기를 확인하면 된다. 특정 월만 수백 GB로 튀어 있으면 같은 문제일 가능성이 높다.
• 장기 재개 세션에서 서브에이전트를 대량으로 돌리지 마라. 문제 조합은 오래 살아 있는 부모 세션 + 세션 재개 + 반복적인 자식 생성이다. 작업 단위를 끊어 새 세션으로 시작하는 것만으로 위험이 크게 줄어든다.
• 큰 명령 출력은 문맥에 그대로 넣지 말고 파일로 흘려라. 빌드 로그나 테스트 출력을 파일로 저장한 뒤 필요한 줄만 읽게 하면, 기록 용량과 토큰 비용이 동시에 줄어든다.
• 월 1회 용량 점검을 캘린더에 걸어라. 세션 기록은 조용히 쌓이고, 알아차리는 시점은 대개 디스크가 꽉 차서 다른 작업이 실패할 때다.

전망 / 주의점

관련 이슈 세 건은 모두 열린 상태이며, 이들이 같은 결함에서 비롯됐는지 서로 다른 저장 문제가 겹친 것인지도 아직 확정되지 않았다. 정식 수정이 확인되기 전까지는 작업 습관 쪽에서 위험을 줄이는 것이 현실적인 대응이다. 넓게 보면 이 사건은 코딩 도구 하나의 버그를 넘어, 에이전트를 여러 개 띄워 오래 돌리는 방식이 남기는 부산물을 아무도 세지 않고 있었다는 사실을 보여준다. 자동화 루프를 늘려가는 중이라면 산출물뿐 아니라 로그·중간 파일·세션 기록의 증가 속도도 함께 지표로 잡아둘 필요가 있다.

출처: GeekNews (https://news.hada.io/topic?id=31618)