# Codex 로깅 버그가 로컬 SSD에 TB 단위 쓰기를 발생시켜 SSD 수명을 빠르게 소모할 수 있음 > Clean Markdown view of GeekNews topic #30738. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=30738](https://news.hada.io/topic?id=30738) - GeekNews Markdown: [https://news.hada.io/topic/30738.md](https://news.hada.io/topic/30738.md) - Type: GN+ - Author: [xguru](https://news.hada.io/@xguru) - Published: 2026-06-23T09:04:34+09:00 - Updated: 2026-06-23T09:04:34+09:00 - Original source: [github.com/openai](https://github.com/openai/codex/issues/28224) - Points: 1 - Comments: 1 ## Topic Body - Codex가 로컬 **SQLite 피드백 로그 DB**에 지속적으로 대량 데이터를 기록하며, 한 사용자 환경에서 21일 가동 후 메인 SSD에 약 **37TB**가 기록됨 - 이를 환산하면 연간 약 **640TB**, 1TB SSD 기준 연 약 640회 전체 쓰기에 해당하며, 일부 컨슈머 SSD의 보증 수명(약 600 TBW)을 1년 이내에 소진할 수 있음 - 보존 행은 약 50만 개에 불과하지만 AUTOINCREMENT 카운터는 **55억 ID**를 넘겨, 보존 행과 누적 삽입 ID 사이에 약 **1만 배 격차**가 존재 - 원인은 SQLite 피드백 로그 싱크가 **글로벌 TRACE 기본값**(`Targets::new().with_default(Level::TRACE)`)으로 설정되어, 의존성 내부 로그와 대용량 raw 프로토콜 페이로드까지 모두 영구 기록하기 때문 - 2026년 6월 22일 두 개의 **PR이 병합**되어 약 85%의 로그를 차단함에 따라 이슈가 종료됨 --- ### 핵심 증상 및 영향 범위 - Codex가 다음 파일에 지속적으로 대량 기록 발생 - `~/.codex/logs_2.sqlite` - `~/.codex/logs_2.sqlite-wal` - `~/.codex/logs_2.sqlite-shm` - 21일 가동 후 메인 SSD에 약 **37TB** 기록, 프로세스/파일 단위 점검에서 Codex SQLite 로그가 주요 지속 기록원으로 확인됨 - 연간 약 **640TB**로 환산, 1TB SSD 기준 연 약 640회 전체 드라이브 쓰기 수준 - 일부 컨슈머 SSD는 약 **600 TBW** 등급으로, 보증 쓰기 수명을 **1년 미만**에 소진 가능 ### 증거 데이터 - ## Evidence1 — 쓰기 증폭(write amplification) - 현재 `logs_2.sqlite` 파일 크기: **1.2 GiB** - 현재 보존 행: 506,149개 - 누적 할당 row id: **5,543,677,486개** - 보존 행(약 0.5M)과 누적 삽입 ID(55억+) 사이 약 **1만 배 격차**, WAL·인덱스·프루닝·체크포인트·페이지 재기록·기기 단위 증폭을 제외해도 10TB+ 규모의 과거 로그 churn 추정 - ## Evidence2 — 레벨/타깃 분포 - 보존 행 681,774개, 추정 보존 로그 콘텐츠 약 1,035.6 MiB - 레벨별 비중: **TRACE 70.7%**, INFO 25.7%, DEBUG 3.0%, WARN 0.6% - 최대 target+level 쌍 - `codex_api::endpoint::responses_websocket` (TRACE) 527.4 MiB - `codex_otel.log_only` (INFO) 141.2 MiB - `codex_otel.trace_safe` (INFO) 121.2 MiB - `log` (TRACE) 97.4 MiB - 상위 소스는 글로벌 TRACE 로그, 미러링된 텔레메트리 로그, raw websocket/SSE 페이로드 기록이 대부분 - `codex_otel.log_only` + `codex_otel.trace_safe`가 추가로 **25.3%** 차지, 해당 카테고리 필터링 시 표본 기준 보존 로그 바이트의 약 **96% 제거** 가능 - 가장 빈번한 TRACE 소스(`target=log`)는 `inotify event`(예: `ld.so.cache` 128,764회), tokio-tungstenite 내부 호출, `WouldBlock` 등 저수준 항목이 다수 - ## 쓰기 증폭 측정 - 15초 표본에서 보존 행은 681,774개로 변동 없이, 약 **36,211개 행이 삽입**됨 - 삽입→인덱싱→WAL 기록→프루닝이 반복되는 **insert-and-prune** 패턴으로 쓰기 증폭 발생 ### 추정 원인 - SQLite 피드백 로그 싱크가 **글로벌 TRACE 기본값**(`Targets::new().with_default(Level::TRACE)`)으로 설치됨 - 이로 인해 의존성/내부 로그와 대용량 raw 프로토콜 페이로드까지 모든 타깃이 TRACE 레벨로 영구 저장됨 ### 제안된 수정 방향 - 피드백 로그는 유지하되 기본 영구 저장 범위를 좁힐 것 - SQLite 피드백 로그 싱크에 글로벌 TRACE 사용 금지 - `target=log`, `hyper_util`, tokio-tungstenite 내부, inotify 스팸, 저수준 OpenTelemetry SDK 로그 등 저가치 노이즈의 임계값 상향 또는 제거 - raw websocket/SSE 페이로드 전체 저장 대신 요약(이벤트 종류, 소요시간, 성공/실패, 토큰 사용량, 페이로드 바이트 길이) 저장 - `codex_otel.log_only` / `codex_otel.trace_safe` 미러 이벤트는 디버깅에 유용한 경우 외 저장 회피 - 스레드 단위 캡만으로는 부족하므로 **글로벌 로그 DB 크기/쓰기 상한** 추가 - `sqlite_logs_enabled = false` 같은 옵션도 유용하나, 핵심 해결은 더 나은 기본 필터링 ### 다중 플랫폼 재현 보고 - ## macOS - macOS 15.7.7 / Codex 26.616.51431 환경에서 `logs_2.sqlite` 113M, `MAX(id)=34,277,360`에 보존 행 31,405개, 60초 표본 2회에서 약 **초당 60회 쓰기** 확인 - 1~2시간 세션 동안 `codex` 프로세스가 약 **50GB** 기록한 사례 보고 - ## Windows - Windows Codex Desktop(`codex.exe app-server --analytics-default-enabled`)에서 `RUST_LOG=warn` 및 명시적 trace 설정이 없는데도 TRACE 행이 지속 삽입됨 - 보존 행 약 71k, `sqlite_sequence`의 `logs` 값은 1,850만 초과로 과거 insert/prune churn 다수 - 10분 분포에서 TRACE 1,812행, 상위 TRACE 타깃에 `codex_api::endpoint::responses_websocket`(3.5MB+), `codex_api::sse::responses` 포함 - 기대 동작: `RUST_LOG=warn` 시 의존성/내부 TRACE 및 대용량 페이로드를 지속 저장하지 않아야 함 ### 추가 위험 및 임시 완화책 - ## 데이터 손실 위험 - 디스크가 가득 찬 상태에서 재부팅 시 Linux 로그인 실패 가능 - Codex `/goal` 모드가 디스크 공간 확보를 시도하며 파일/폴더를 삭제해 **데이터 손실** 발생 가능 - ## 임시 완화 스크립트 - 실행 중 WAL을 트리밍하는 `trim-codex-wal.sh`(`PRAGMA wal_checkpoint(TRUNCATE)` 사용), cron으로 15분마다 실행 가능 - 로그/WAL 파일 삭제 후 Codex 관련 프로세스에 SIGTERM→SIGKILL을 보내 디스크 공간을 즉시 확보하는 `fix-codex-wal.sh` - `logs` 테이블 삽입을 무시하는 SQLite 트리거(`block_log_inserts`)를 추가하면 WAL 증가가 멈춤, 되돌릴 때는 `DROP TRIGGER IF EXISTS block_log_inserts` - `VACUUM`은 DB를 재기록하므로 대용량 파일에서는 일회성 대형 쓰기를 유발할 수 있어, 트리거 추가 후 WAL 증가 중단 확인 뒤에 `DELETE`/`VACUUM` 실행 권장 - 사설 SQLite 스키마 수정이므로 향후 Codex 업데이트/마이그레이션이 테이블 재생성, 트리거 제거 등으로 동작할 가능성 있음 - 영구 수정 전까지 SSD 손상을 막으려면 해당 DB를 ramdisk에 두는 방법도 제시됨 ### 해결 및 종료 - 2026년 6월 22일 두 개의 PR 병합으로 약 **85% 로그 절감**, 이에 따라 이슈가 완료 처리됨 - 모든 Responses WebSocket 이벤트 로깅 중단 (#29432) - 영구 로그에서 노이즈 타깃 필터링 (#29457) - 별도 제안 패치에서는 글로벌 TRACE 대신 `INFO+` 기본 저장, `codex_otel.log_only`·`codex_otel.trace_safe`·`hyper_util`·`log`·`opentelemetry_sdk` 등을 `WARN+`로 상향 - 수정 사항이 `rust-v0.142.0`으로 릴리스됨 ## Comments ### Comment 60185 - Author: neo - Created: 2026-06-23T09:04:35+09:00 - Points: 1 ###### [Hacker News 의견들](https://news.ycombinator.com/item?id=48626930) - **Codex**는 slopware의 악명 높은 사례 중 하나라고 봄 macOS에서 창만 보이게 둬도 스피너 메시지를 표시하느라 GPU를 100% 사용함 **MBP M5에서 스피너 메시지만으로 GPU 100%** 가 찍히고, 모델을 기다리는 시간 대부분 동안 팬이 크게 돌기 때문에 배터리 사용 시 조심해야 함 이 이슈는 GitHub에 올라온 지 거의 6개월 됐고, 아마 바이브 코딩으로 만든 잡동사니가 출시된 뒤부터였을 것 같음 직접 고치고 싶어도 이유는 모르겠지만 비공개 소스라 불가능함 어떤 모델이 더 나은지, 바이브 코딩이 가능한지 논쟁이 많지만, 자금·인력·모델 역량이 가장 풍부한 회사 중 하나가 바이브 코딩으로 할 수 있는 수준이 이 정도라고 봄 CEO가 이미 “코딩에 집중한다”고 밝힌 상황에서 이런 심각한 실수는 회사 내부에 뭔가 정말 망가졌다는 신호로 보이고, Polymarket에서도 OpenAI가 곧 선도 모델을 낼 거라고 보는 사람이 거의 없음 세상에는 Anthropic의 경쟁자가 필요하기 때문에 비극적임 - Claude Code도 바로 옆에 있으니 **slopware** 사례에서 빼먹으면 안 됨 - AI로 10배 생산성이 나오고 AGI나 ASI에 가깝다면, **Codex**나 **Claude Code CLI** 같은 제품이 어떻게 아직도 이렇게 형편없을 수 있는지 모르겠음 “에이전트형 AI 혁명”이 이미 이런 문제를 해결했어야 하는 것 아닌가 싶음 설마 내부에서 “처리 중이니 기다려 달라”거나 “너무 힘든 작업”이라고 하고 있진 않을 텐데 - 기본적으로 모든 걸 오픈소스로 공개하던 조직에서 일할 때, 사이드 프로젝트까지 포함해 뭔가를 비공개로 남기는 이유는 하나뿐이었음. **부끄러움**임 아무도 쓰레기 같은 코드베이스의 공개 얼굴이 되고 싶어 하지 않음 그 코드로 터무니없는 가격을 정당화하고 있다면 그 부담은 세 배쯤 커질 것 같음 - Codex만이 아니라 macOS의 **ChatGPT 앱**도 몇 시간 열어두면 시간이 지나며 RAM을 60GB 먹고 다른 앱들을 다 죽임 이해가 안 됨 브라우저에서 Google AI Studio를 쓰려고 해도 CPU를 100% 사용함 결국 모든 걸 직접 앱으로 만들어야 하나 싶음 - 초창기에는 세상에 ChatGPT의 경쟁자로 Anthropic이 필요하다고 했는데, 이제는 완전히 한 바퀴 돌아옴 - X에 이 문제의 **임시 우회책**이 올라와 있음[1] `sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"` 또 노트북에서 해당 sqlite 파일에 `VACUUM FULL`을 실행했더니 27GB에서 73MB로 줄어듦[2] [1]: [https://xcancel.com/bdsqlsz/status/2067964486615810369]() [2]: [https://xcancel.com/jeethu/status/2068087449469780434]() - 이번에도 **데이터베이스 수준 규칙**이 하루를 구해줌 - 진짜 해결책은 사용을 중단하고 **Pi**로 갈아타는 것임 - 모두가 OpenAI를 비판하고 있고 그럴 만하지만, Claude Code와 달리 **Codex는 공식적으로 커스터마이즈 가능**하다는 점은 상기할 만함: [https://github.com/openai/codex]() 패치하기도 꽤 쉬움 - 그건 **CLI**이고, 여기서 말하는 독점 **Codex 앱**은 아님 - 충격적임 이슈가 열린 지 일주일 됐는데, 내가 보기엔 OpenAI는 그냥 침묵 중임 이런 판매사들이 이런 문제에 굉장히 민감할 거라고 생각했는데 이해가 안 됨 당연히 GitHub의 잠재 이슈를 감시하고 수정안을 제안하는 여러 에이전트를 붙여놨겠지? …그렇겠지? 자기 도구들을 돌려서 GitHub 이슈를 실시간으로 고치게 하는 건 당연히 사소한 일이어야 할 텐데 - OpenAI는 이슈 수정에 꽤 약한 것 같음 개인적으로 좋아하는 사례는 **#2472**인데, GPT-5 출시 무대에서 “수정”했다고 시연했지만 티켓은 아직 열려 있고 그 “수정”도 병합되지 않았음 이 사실을 짚은 원래 글은 [https://blog.tymscar.com/posts/openaiunmergeddemo/]()이고, 이슈는 [https://github.com/openai/openai-python/issues/2472]()임 - 같은 문제에 대한 GitHub 이슈가 **4월부터** 있었음 Codex를 많이 쓰고 있고 성능(UX와 출력)에는 매우 만족하지만, 이 문제를 아직 고치지 않았다는 건 이해하기 어려움 - 이 문제는 **수정된 것으로 보이고**[0], 다음 릴리스에 들어갈 듯함 [0] [https://github.com/openai/codex/commit/e98d43ac372ddf7f513c0...]() - 바이브 코딩은 “빠르게 움직이고 망가뜨려라”를 완전히 다른 수준으로 끌어올림 - 지금 우리 회사에서 누군가의 **바이브 코딩한 쓰레기**가 심각하게 잘못돼서 대형 장애를 붙잡고 있음 - 이제 망가뜨릴 것도 점점 바닥나고 있음 - 기술 부채가 없다면 **바이브 코딩**은 대체로 프로토타이핑에는 유용함 실제 제품에서는 진짜 소프트웨어 엔지니어가 절대 대체되지 않을 것임 - 약간 주제에서 벗어나지만, 이 회사들은 저장소 루트 폴더를 **Claude.md**나 **copilot.md**로 더럽히는 걸 그만둬야 함 한 방에 모여서 `docs/llm/*` 같은 잘 알려진 폴더 구조를 정해야 함 - 작년 말 Claude Code가 지연으로 엉망이었을 때 OpenAI는 거의 잡은 승리를 놓쳤음 요즘은 **Codex**가 시작하자마자 타이핑 지연이 있고, Claude Code는 가끔 멈추긴 해도 대체로 내가 키를 누르면… 말 그대로… 누른 대로 표시됨 - 내 경우는 정확히 반대임 - **Claude Code**는 거의 못 쓸 수준이라고 느낌 몇 단어 이상 입력할 때는 항상 neovim에서 입력해야 함 - 이건 사실 아주 전형적인 실수임 모든 것에 **추적/디버그 로그**를 켠 채 출시한 것인데, 재미있게도 영향이 일반적인 방식으로 나타나진 않음 예전 같으면 개발자가 trace 수준 로깅을 켜서 앱이 재앙적으로 느려지고 다음 업데이트에서 바로 고쳤을 텐데, 이제는 메모리·CPU 속도·디스크 속도가 압도적으로 좋아져서 그런 식으로 바로 드러나지 않는 지점에 온 게 미친 일임 - 에이전트 작업이 서버 쪽에서 이뤄지니, 얇은 클라이언트가 **로컬 리소스**를 다 잡아먹어도 된다는 점도 한몫함 - 누가 이 씩씩한 스타트업에 **토큰** 좀 기부해 줬으면 함. 도움이 필요해 보임