Codex Desktop이 Crashpad 대기 덤프를 계속 생성하는 문제

에이전트를 돌리면서 디스크 공간이 부족해졌는데, 주요 원인은 워크트리마다 중복되는 빌드 산출물과 과도한 스왑이었음. 모든 작업에 git 워크트리를 쓰다 보니 빌드 관리 개선만으로는 한계가 있었고, 특히 큰 저장소에서는 동시에 진행하는 기능 수를 줄여야 했음.
Mac이 생각보다 자주 메모리 한계에 도달했지만 한동안은 성능이 괜찮아서 알아채기 어려웠음. 그러다 급격히 느려졌고, 내가 확인한 바로는 디스크에 쌓인 스왑 공간을 회수하려면 재부팅하는 수밖에 없었음. 밤새 작업을 돌리는 등 하루에 몇 번씩 이런 일이 생기면 사용량이 빠르게 불어남.

예전에는 작업을 병렬로 나누고 검증 지점을 정해서 하위 에이전트에 미리 맡기면 잘 돌아갔는데, 이제 하위 에이전트 8~16개만 돌려도 수백 GB의 난장판이 됨. 이런 동작을 쉽게 끌 수 있었으면 좋겠음. 쓰기 시 복사(CoW) 워크트리도 해결책이 못 됨. 빌드 산출물만으로도 그만큼 쌓이기 때문임.

회사에서 Mac 노트북과 원격 Windows VM을 제공하는데, 이제 에이전트 빌드와 테스트는 Mac에서 전혀 하지 않음. WSL 인스턴스에 SSH 접근 권한을 주고 VM에서 마음껏 돌리게 함.
아직은 에이전트가 직접 변경 사항을 가져오거나 내가 작업 사본을 최신으로 유지해야 하는 임시방편임. 컨테이너나 GitHub Actions로 정리할까 고민 중이지만, 지금도 충분히 쓸 만함. 예전에는 회의 도중 백그라운드 에이전트가 빌드를 시작하면 영상이 끊겨서 작업을 전부 종료해야 했는데, 이제는 만족스럽게 돌아감.

비슷한 일을 겪었는데 언어별로 좋은 해결책이 있기도 함. Rust 워크트리를 쓴다면 https://mr-boxington.jdx.dev/를 확인해 볼 만함.
스왑이 RAM 기반 tmpfs 때문에 생기는 건 아닌지 확인해 봤는지 궁금함. 내 경우에는 대부분 /tmp가 원인이어서, 최근 약 2시간 동안 사용하지 않았고 어떤 명령도 파일 핸들을 잡고 있지 않은 임시 파일을 자주 삭제하도록 작업을 만들었음.
이전 코딩 에이전트가 명령을 분기 실행한 뒤 남겨 둔 프로세스도 많았음. 그래서 에이전트 실행기에 세션마다 cgroup을 만들고 작업 완료 시 그 안의 프로세스를 모두 종료하는 기능을 추가함.

쓰기 시 복사(CoW) 워크트리로 바꾸는 게 가장 큰 개선책임. 이미 대부분의 운영체제에서 사용할 수 있으니 곧 널리 알려질 것 같음.

Linux에서는 메모리를 많이 쓰는 작업 전에 스왑을 비활성화하기 시작함. Claude가 벤치마크나 작업으로 가용 메모리를 전부 먹어 치우면 시스템이 응답하지 않아 프로세스를 종료할 수도 없었음.
스왑을 끄면 OOM 킬러가 해당 작업을 종료하고, Claude는 그 뒤에 상황을 파악해 대응함.

이번 건 버그 같지만, Codex는 정상 동작 중에도 수 GB의 로그를 만듦. 몇 달째 계속되는 걸 보면 OpenAI는 괜찮다고 여기는 듯함.
도움이 되는 건 두 가지임. 하나는 파일시스템 수준 압축으로, Btrfs는 Rust 병렬 빌드에서 경합이 심해서 ZFS를 사용함. 다른 하나는 sessionwiki 같은 도구로 오래된 세션을 보관 처리하는 것으로, 내 제어 시스템에도 통합해 둠.

Btrfs가 Rust 병렬 빌드 같은 동시 작업에서 문제를 겪는다는 내용은 처음 접함. 읽어 볼 만한 자료가 있는지?

지난 한 달간 너무 자주 쓰다가 결국 4TB USB4 SSD를 구매함. Codex가 내 디스크도 먹어 치우고 있는데, 아이러니하게도 주된 해결책 역시 Codex임. 여기저기 남은 찌꺼기를 지우는 작업을 만들어 돌리고 있음.

처음부터 이런 에이전트 실행 환경을 Docker 컨테이너에 격리해 둬서 정말 다행임.

3D 세계를 세밀하게 조정하는 개인 프로젝트에서 Codex가 워크트리에 스크린샷을 비롯한 산출물을 수천 개 만들고 치우지 않음.
회사에서는 Excel 기반 금융 업무를 코드로 옮기는 중인데, Codex와 Windows VM 사이에 자체 에이전트를 연결해 작업을 맡겼더니 불필요한 검증 테스트를 수천 개 생성·저장해서 90GB를 차지함. Codex 특유의 현상으로 보이며, Claude Code나 Antigravity에서는 겪어 본 적 없음.

빌드 과정에서 오래된 산출물을 지우라고 직접 시켜야 한다는 게 황당함. 지시하지 않으면 테스트 빌드와 이전 빌드 폴더를 끝없이 보관하고, 문서나 참고 자료도 대체로 마찬가지임.
한동안은 VM 전체 권한과 전용 프로젝트 폴더를 줘도 삭제 요청을 계속 거부하거나 몰래 보관 처리해서 정말 성가셨음. 전부 git 저장소에 들어 있는데도 그랬음. 지금은 좀 나아졌지만, 여전히 최종 병합 전 기본 절차에 불필요한 프로젝트 내용을 삭제하는 정리 스크립트 작성을 넣어 둠.

최근 몇 주 사이에 Claude도 jj 작업 공간 여러 개와 수 GB의 빌드 파일을 남겨 둠. 그러지 않도록 agents.md를 수정하라고 시켜야 했음.

Codex의 검증 테스트 집착 때문에 정말 미칠 지경임.

Rust 빌드 산출물 크기는 악명 높음. 어디서 무엇을 빌드하든 의존성을 공유하도록 공용 빌드 저장 공간을 강제로 쓰게 하는 방법도 있지만, 애초에 출력 파일을 더 작게 만들 수는 없는지 답답함.
하드디스크 가격이 합리적인 수준으로 내려가지 못할 이유는 늘 생기는 듯함. 어릴 때는 지금쯤 엑사바이트 하드디스크를 쓰고 있을 줄 알았음.

~/.bun/install/cache/@openai 폴더도 확인해 볼 만함. 내 경우에는 각각 약 300MB인 codex와 codex-code-mode-host 바이너리가 어째서인지 11개나 따로 들어 있었음.

ChatGPT 앱 설정의 저장 공간 항목에서 디스크 사용량과 관련 정보를 확인할 수 있음.

바이브 코딩 지지자들이 원하는 대로 소프트웨어 스택의 모든 계층에 이런 비대화와 버그가 퍼진다고 상상해 보길 바람. 전부 무너질 것 같음.

Windows XP 이전에는 데스크톱 Windows 사용자가 잦은 시스템 충돌에 익숙했고, 1990년대에는 바이러스가 세계 곳곳의 사무실을 마비시키곤 했음. 그래도 아무것도 무너지지 않았고 Linux로 옮겨 가지도 않았으며, 다들 익숙해졌을 뿐임.
예전이 지금보다 훨씬 나빴던 만큼, 대부분은 편익과 불편의 맞교환을 받아들일 것으로 봄.