Codex SQLite 로그 이슈, SSD 쓰기량까지 번진 개발도구 리스크

OpenAI Codex GitHub 이슈 하나가 HN에서 빠르게 퍼졌다. 제보자는 Codex가 로컬 SQLite feedback log database에 지속적으로 많은 데이터를 쓰고 있으며, 약 21일 uptime 동안 SSD에 37TB 쓰기가 발생했다고 적었다. 이 수치를 단순 환산하면 연간 약 640TB가 된다. 이슈는 현재 open 상태로 표시되어 있다.

문제의 파일은 ~/.codex/logs_2.sqlite와 WAL, SHM 파일이다. 제보자는 retained rows가 681,774개이고 estimated retained log content가 1,035.6MiB라고 정리했다. TRACE 로그가 retained bytes의 70.7%를 차지했고, mirrored telemetry 성격의 로그까지 합치면 대부분의 저장량이 특정 로그 범주에 몰려 있다는 분석도 포함했다.

이 이야기가 개발자에게 민감한 이유는 AI coding tool의 위치 때문이다. editor 옆에서 오래 켜져 있고, terminal과 browser, local file context를 오가며, 작업 로그를 남긴다. 기능이 강력할수록 로컬에 어떤 상태가 쌓이는지, retention과 log level이 어떻게 통제되는지, 문제 발생 시 사용자가 알아차릴 수 있는지가 중요해진다.

HN 댓글은 workaround, log retention, telemetry boundary를 파고들었다. 일부는 SQLite trigger로 insert를 막는 임시 회피책을 공유했고, 다른 쪽은 open source라면 사용자가 직접 patch할 수 있다는 점을 언급했다. 아직 단일 이슈 제보인 만큼 수치는 환경별로 확인이 필요하다. 그래도 결론은 명확하다. AI 개발도구는 모델 품질뿐 아니라 로컬 자원 사용과 관찰 가능성까지 제품 품질에 포함된다.