요약
Codex Desktop이 맥에서 충돌 덤프 파일을 끝없이 쌓아 디스크를 수백 GB까지 채운다는 버그 보고입니다.
6월 2일 오픈AI의 Codex 저장소에 올라온 깃허브 이슈입니다. 맥용 Codex Desktop이 Crashpad(크로뮴 기반 앱의 충돌 보고 도구) 대기 폴더에 덤프(충돌 순간의 메모리 기록) 파일을 계속 쓴다는 내용이며, 넉 달 넘게 보고가 이어졌지만 아직 해결되지 않았습니다.
왜 중요한가
- 앱은 멀쩡히 돌아가는 동안 디스크만 조용히 차서, 사용자는 저장 공간이 바닥난 뒤에야 원인을 알게 됩니다.
- 보고자들은 충돌 반복과 별개로, 쌓인 보고서를 지우는 보존 정책이 없는 것 자체가 버그라고 지적합니다.
- 공식 수정이 없어 사용자들이 충돌 보고를 막는 임시방편에 기대고, 교체할 수 없는 저장장치가 빨리 닳는다는 우려도 나왔습니다.
핵심 내용
- 덤프는 대부분 충돌 보고를 맡은 browser_crashpad_handler 자신의 것으로, 시작 점검에 실패하고 다시 뜨기를 반복합니다.
- 초당 덤프 하나꼴로 하루 약 15GB씩 늘었다는 보고가 있고, 파일 수가 폴더 한도(65,535개 링크)에 닿은 사례도 있습니다.
- 10월 17일 보고에서는 두 경로를 합쳐 약 323GB, 파일 404만 개가 쌓여 남은 공간이 1.4GB까지 줄었습니다.
- 한 프로젝트 기여자는 6월에 새 macOS에서 고쳐졌을 것이라고 답했지만, 이후 사용자들은 문제가 계속된다고 반박했습니다.
- 사용자들은 주기적 삭제 스크립트를 돌리거나 폴더를 읽기 전용으로 바꾸지만, 이렇게 하면 충돌 보고 자체가 막힙니다.
HN 반응
- 여러 이용자가 에이전트가 빌드 결과물, 스크린샷, 테스트 파일을 정리하지 않아 디스크가 찼다는 경험을 보탰고, Claude Code도 그렇다는 말이 나왔습니다.
- 오픈AI가 나비에-스토크스 문제를 풀었다고 내세우면서 이런 버그는 방치한다는 비판과 함께 DaisyDisk, Mole 같은 디스크 정리 도구 추천이 이어졌습니다.
에이전트를 돌리다 보니 디스크 압박이 심했습니다. 원인은 크게 두 가지였습니다.
모든 작업에 git worktree를 쓰는 제 방식입니다. 그리 놀랍지는 않은데, 워크트리마다 중복으로 쌓이는 빌드 산출물이 주범이었습니다. 빌드 관리를 좀 더 효율적으로 해서 얻은 이득은 제한적이었고, 결국 특히 큰 저장소 몇 곳에서는 동시에 진행하는 기능 수를 줄일 수밖에 없었습니다.
더 고약했던 건 제가 생각보다 자주 메모리 한계에 부딪혀서 맥이 스왑을 엄청나게 쓰고 있었다는 점입니다. 그러는 동안에도 시스템은 놀랄 만큼 쾌적했는데, 어느 순간 그렇지 않게 됩니다. 제가 아는 한 이럴 때 유일한 "해결책"은 기기를 재시작하는 것뿐입니다. 한 번 디스크에 쓰인 스왑 공간은 시스템이 되돌려 받을 방법이 없습니다. 하루에 몇 번씩 이런 일이 벌어지면(밤새 뭔가를 돌려 두면 쉽게 그렇게 됩니다) 순식간에 쌓입니다.
리눅스에서는 메모리를 많이 쓰는 작업을 하기 전에 스왑을 꺼 두는 습관이 생겼습니다. Claude가 아무 생각 없이 가용 메모리를 전부 삼켜 버리는 벤치마크나 작업을 돌리곤 하거든요. 그러면 이유는 모르겠지만 시스템이 먹통이 되고 프로세스를 죽일 수도 없게 됩니다. 스왑을 꺼 두면 OOM 킬러가 Claude가 하던 작업을 알아서 정리하고, Claude는 나중에 상황을 파악하고 해결합니다.
저도 비슷한 문제를 겪었습니다. 다만 언어별로 좋은 해결책이 있을 때도 있습니다. Rust 기반 워크트리라면 https://mr-boxington.jdx.dev/ 를 꼭 확인해 보세요.
스왑 얘기인데, 혹시 RAM 기반 tmpfs 파티션 때문은 아닌가요? 저는 그게 원인이었고 스왑 대부분이 /tmp에서 나온 것이었습니다. 그래서 최근 약 2시간 동안 쓰이지 않았고 어떤 명령도 핸들을 잡고 있지 않은 임시 파일을 모조리 지우는 공격적인 작업을 자주 돌게 만들었습니다.
또 하나 발견한 건, 이전 코딩 에이전트들이 명령을 포크해 놓고 그대로 방치한 프로세스가 잔뜩 남아 있다는 점이었습니다. 그래서 에이전트 스포너에 각 에이전트 세션을 cgroup 안에서 자동으로 띄우고, 작업이 끝나면 그 안의 프로세스를 전부 죽이는 장치를 만들어 넣어야 했습니다.
카피 온 라이트(copy on write) 방식의 워크트리로 바꾸는 게 가장 큰 변화를 가져옵니다. 곧 상식이 될 만한 내용이고, 이미 대부분의 운영체제에서 쓸 수 있습니다.
버그처럼 보이긴 하지만, 정상적으로 잘 돌아가는 Codex도 로그를 수 GB씩 만들어 냅니다. 몇 달째 이러는 걸 보면 OpenAI는 이 정도는 괜찮다고 여기는 모양입니다.
도움이 되는 방법이 두 가지 있습니다.
파일시스템 수준 압축입니다. 저는 Btrfs가 동시 Rust 빌드에서 경합 문제가 심해서 ZFS를 씁니다.
sessionwiki( https://github.com/youdie006/sessionwiki ) 같은 도구로 오래된 세션을 아카이브합니다. 저는 이걸 제 컨트롤 플레인( https://github.com/BrokkAi/mjolnir/ )에 통합해 뒀습니다.
btrfs가 Rust 빌드를 여러 개 동시에 돌리는 것 같은 동시 작업에서 문제가 있다는 얘기는 들어 본 적이 없습니다. 읽어볼 만한 자료가 어디 있을까요?
저는 지난 1년 동안 DaisyDisk를 아주 잘 써 왔습니다. https://daisydiskapp.com
Mole도 괜찮아요.
TUI 버전은 무료이고, 취향에 맞으면 유료 앱도 있어요.
https://github.com/tw93/Mole
맞아요, Mole 정말 훌륭해요. DaisyDisk 결제하고 며칠 뒤에 Mole을 알게 됐는데, 그 뒤로는 DaisyDisk를 한 번도 안 썼어요. 처음 돌렸을 때 노트북에서 80GB가 확보됐고요.
DaisyDisk는 정말 좋은 앱입니다. 방금 확인해 보니 11년도 더 전에 구입했더군요.
지금도 업데이트되고, 완벽하게 잘 돌아가고, 2.0 버전을 내서 강제로 구형으로 만드는 일도 없었습니다. 믿을 수 있는 좋은 도구입니다.
DaisyDisk 좋죠. Mole도 제 맥에서 Claude, Gemini 등이 남긴 파일을 잔뜩 찾아서 지워 줬어요.
https://github.com/tw93/Mole
~/.bun/install/cache/@openai 폴더도 한번 보세요.
무슨 이유에선지 제 폴더에는 codex와 codex-code-mode-host 바이너리가 각각 11개씩 있었어요. 하나당 약 300MB씩이요.
참고로 ChatGPT 앱 설정에 저장 공간 섹션이 있어서, 디스크 사용량과 관련 정보를 보여줘요.
3D 월드를 세밀하게 튜닝해야 하는 사이드 프로젝트를 하고 있습니다. Codex가 워크트리 안에 스크린샷을 비롯한 산출물을 수천 개나 만들어 놓고는 뒷정리를 하지 않았습니다.
회사 프로젝트에서는 금융 업무 프로세스를 엑셀에서 코드로 옮기고 있는데, Codex가 불필요한 검증 테스트를 수천 개씩 만들어 저장해 뒀습니다. Codex와 윈도 VM 사이를 커스텀 에이전트로 연결해서 풀어 놓았더니 90GB가 날아갔습니다.
이건 분명히 Codex만의 문제이고, Claude Code나 Antigravity에서는 이런 일을 본 적이 없습니다.
빌드 과정에 오래된 산출물 정리를 넣으라고 일일이 말해 줘야 하는 게 한심해요. 안 그러면 테스트 빌드와 옛날 빌드 폴더를 끝도 없이 쌓아 두고 정리를 안 하거든요. 문서나 참고 자료도 대체로 마찬가지고요.
VM 하나와 전용 프로젝트 폴더의 전권을 맡겼더니, 제가 시킨 걸 계속 지우지 않거나 말없이 아카이브만 해 두던 정말 짜증 나는 시기도 있었어요. 전부 이미 git 저장소에 들어 있는데도요. 지금은 그래도 많이 나아진 것 같지만, 변경 사항을 최종 병합하기 전의 기본 단계에는 여전히 "불필요한 프로젝트 콘텐츠를 지우는 정리 스크립트를 만들 것"을 넣어 둬요.
헐, Claude도 최근 몇 주 사이에 제 환경에 수 GB짜리 빌드가 든 jj 워크스페이스를 여러 개 남겨 놨어요.
그러지 말라고 agents.md를 고치게 시켜야 했네요...
Codex는 검증 테스트에 집착해요. 진짜 미치겠어요.
에이전트는 자기 결과물을 확인할 수 있는 어떤 형태의 테스트를 선호합니다.
저는 "루프를 닫을" 수 있을수록 좋다고 봅니다. 제가 에이전트에게 맡기는 일 중 제일 좋아하는 것이, 펌웨어 버그에 JTAG 접근과 시리얼 포트를 함께 주는 겁니다. 그러면 플래싱, 디버깅(변수 살펴보기, 브레이크포인트 설정 등), 로깅까지 전부 완전히 자율적으로 이뤄집니다.
가끔씩만 나타나 재현하기 어려운 버그에 특히 잘 맞습니다. 브레이크포인트를 걸거나 모니터링 스크립트를 짜 두고 잠들었다가, 버그가 터지면 하니스가 깨워 주면 상태를 살펴보고, 디버깅으로 세운 가설을 바탕으로 새 빌드를 만들어 플래싱하고, 다시 반복합니다. 하루가 넘도록 완전히 자율적으로 돌아간 세션도 있었는데, 골치 아픈 레이스 컨디션을 한 줄로 해결하는 멋진 답을 들고 오더군요.
그런 점에서 사람과 같습니다. 하루 종일 코드를 읽어도 어딘가에 닿을 수는 있겠지만, 무슨 일이 일어났는지 확인하고, 새 이론을 세우고, 시험하고, 반복할 수 있는 쪽이 99%의 경우 훨씬 강력합니다.
OpenAI의 초지능이 나비에-스토크스 방정식을 풀 수 있다면, 제 맥 디스크를 330GB나 먹어 치운 이 한심한 버그는 왜 못 고치는 거죠? 제발 GitHub 이슈 좀 분류해 주세요.
이걸 보세요: https://github.com/openai/codex/issues/25921#issuecomment-6237799309
앞의 것은 아주 근사하게 홍보할 수 있지만, 뒤의 것은 거의 그럴 수 없으니까요.
https://www.briefia.fr/en/article/openai-revendique-la-resolution-de-navier-stokes-cout-estime-jusqu-a-40-m 에 따르면 나비에-스토크스 방정식을 푸는 데 OpenAI가 최대 4천만 달러를 쓴 것으로 추정됩니다. OpenAI가 같은 돈을 들여 초지능으로 이 버그를 고치게 한다면 아마 고쳐질 겁니다.
하지만 별로 경제적이지는 않은 모양이네요. :-)
자기들이 주장하는 증명을 검증하려면 진짜 수학자를 고용해야 할 테니까요.
바이브 코더들이 뜻대로 해서 소프트웨어 스택의 모든 층에서 이만한 비대함과 버그투성이를 보게 된다면 어떨까요. 전부 무너질 겁니다.
윈도 XP 이전에는 데스크톱 윈도 사용자들이 시스템 충돌을 자주 겪는 데 익숙했습니다. 1990년대에는 바이러스가 전 세계 사무실을 마비시키곤 했습니다. 그래도 아무것도 무너지지 않았고, 아무도 리눅스로 갈아타지 않았습니다. 다들 그냥 익숙해졌습니다. 예전에는 지금보다 훨씬 심했으니, 대부분의 사람은 그런 트레이드오프를 받아들일 거라고 생각합니다.
AI 슬롭으로 이런 일이 생기는 게 정말 놀랍기는 한가요?
OpenAI의 슬롭 코딩을 보여 주는 좋은 사례네요. 에이전트가 중범죄를 저지르는 걸 못 막는 것도 당연하죠.