인사이트 · 4분 · 06.24

Codex CLI가 당신 SSD에 연 640TB를 쓴다 — AI 도구가 하드웨어를 죽이는 새 리스크

loopy vibecoder

#draft #codex #ssd #ai-tool-risk #observability

핵심 요약 (TL;DR)

OpenAI Codex CLI가 사용자의 ~/.codex/logs_2.sqlite에 글로벌 TRACE 레벨 로그를 기록하면서 21일 만에 37TB를 쓴 버그가 발견됐습니다. 이 페이스라면 연 640TB로 일반 1TB SSD의 보증 수명(약 600 TBW)이 1년 안에 소진됩니다. GitHub 이슈 #28224는 6월 23일 closed, 3개 PR이 머지되어 약 85%의 로그가 제거됐습니다. AI 에이전트가 로컬에서 도는 시대, 위험은 모델 품질이 아니라 backend logger의 default값일 수 있습니다.

어떤 버그는 코드가 아니라 사용자의 하드웨어를 죽입니다. 2026년 6월, 한 GitHub 사용자가 자기 머신의 디스크 활동이 이상하다는 걸 알아챘어요. 추적해보니 범인은 OpenAI Codex CLI였습니다.

무슨 일이 일어났나

@1996fanrui라는 사용자가 6월 14일 GitHub 이슈 #28224를 열었습니다. 발견 사항은 간단했지만 충격적이었어요.

Codex CLI가 ~/.codex/logs_2.sqlite에 글로벌 TRACE 레벨로 모든 의존성 내부 이벤트, WebSocket/SSE raw payload, OpenTelemetry mirror를 기록.
RUST_LOG 환경변수 설정마저 무시.
15초 샘플에서 36,211개 row가 insert되는데 retained row 수는 그대로—끊임없는 insert-and-prune.
21일 가동 결과 37TB writes 누적. 연 환산 약 640TB.

1TB 컨슈머 SSD의 보증 endurance는 보통 약 600 TBW(Terabytes Written)입니다. 즉 이 페이스라면 노트북 1대의 SSD 보증 수명이 12개월 안에 끝난다는 뜻이에요.

왜 이 버그가 무서운가

전통적 소프트웨어 버그는 두 가지 모드입니다. 코드가 망가지거나, 데이터가 망가지거나. 둘 다 "고치면 복구 가능"의 영역이죠. 그런데 이 버그는 다릅니다. 사용자의 물리적 하드웨어를 마모시키는 거예요. 한 번 쓴 SSD 셀은 되돌아오지 않습니다.

그리고 이게 더 무서운 이유는, 사용자가 체감하기 어렵다는 점이에요. CPU가 100% 튄다면 팬 소리로 알아챕니다. 메모리가 새면 시스템이 느려져요. 그런데 SSD 마모는 조용히 진행되다가, 어느 날 갑자기 "보증 수명 만료"로 결말이 납니다. 그제야 "AI 도구 때문이었다"를 알게 되는 거죠.

8일 만에 글로벌 패치 3개

GitHub 이슈 #28224 → OpenAI의 빠른 대응 → 6월 22~23일 사이 3개 PR 머지로 마무리됐습니다.

v0.142.0: "Stop logging every Responses WebSocket event" + "Filter noisy targets"
v0.143.0: "Stop persisting bridged log events"

OpenAI 본인의 추정으로 약 85%의 로그가 제거됐고, 이슈는 6월 23일 closed 됐습니다.

한 명의 사용자가 자기 노트북에서 발견한 버그가 일주일 만에 전 세계 Codex 사용자의 SSD를 살린 사건이에요. 오픈소스와 활발한 이슈 트래킹이 만든 결과인데, 다시 말하면 "이런 버그가 closed-source SaaS에 있었다면" 이라는 가정이 상당히 불편하게 다가옵니다.

바이브코더에게 의미하는 것

저는 이 사건을 보면서 한 가지 새 리스크 카테고리가 보였습니다. "AI 에이전트의 로컬 실행이 호스트 머신에 가하는 부담" 이라는 카테고리예요.

Codex CLI, Claude Code, Cursor의 백그라운드 에이전트, CodeRabbit, Devin—이 도구들의 공통점은 "로컬에서 데몬처럼 돌면서 IDE/터미널과 연동"한다는 거죠. 클라우드 SaaS와 달리, 이들의 default 설정이 망가지면 여러분의 노트북이 직접 청구서를 받습니다. 모델 품질 평가에만 신경 쓰던 사용자가 놓치기 쉬운 축이에요.

지금 점검할 것

1. Codex CLI 버전 확인 및 업데이트

codex --version
# v0.143.0 이상이면 패치 적용됨

구버전이라면 즉시 업데이트하세요.

2. 로그 파일 크기 확인

ls -lh ~/.codex/logs_2.sqlite
# 수십 GB로 자라 있다면 위험 신호

오래 켜둔 머신이라면 이미 상당한 양이 쌓여 있을 수 있습니다. 안전하게 삭제하고 새로 시작해도 됩니다.

3. SSD 마모도 점검 (macOS/Linux)

# macOS
smartctl -a disk0 | grep -i "data units written"

# Linux
sudo smartctl -a /dev/nvme0 | grep -i "data units written"

SMART 정보의 "Data Units Written"이 비정상적으로 높다면, 자기 사용 패턴 대비 점검이 필요해요.

4. 다른 AI 도구의 로그 디렉터리도 한번

Claude Code의 ~/.claude/, Cursor의 로그 디렉터리, 자체 빌드한 에이전트들의 로그 위치—한 번씩 du -sh로 크기를 점검해두는 게 좋습니다.

FAQ

Q. 640TB/년은 정말 실제 발생하는 숫자인가요?
A. 한 사용자의 21일 측정치를 연 환산한 worst case입니다. 실제로는 idle 시간이 많은 노트북에서는 더 적게 발생할 수 있어요. 다만 21일 만에 37TB라는 절대값 자체가 이미 비정상적입니다.

Q. 이미 v0.143.0으로 올렸다면 안전한가요?
A. 85% 감소가 OpenAI 자체 추정이라, 남은 15%가 어떻게 행동하는지는 외부 검증이 더 필요합니다. 일단 즉각적 위험은 해소된 상태로 보입니다.

Q. 이미 SSD가 손상됐다면 복구 가능한가요?
A. 마모된 NAND 셀은 복구 불가입니다. 다만 보증 TBW 안에서는 SSD 제조사 보증이 적용될 수 있으니, 구매 영수증과 SMART 정보를 챙겨두세요.

Q. Claude Code나 다른 AI CLI에도 비슷한 버그가 있을 가능성은요?
A. 구조적으로 가능성이 있습니다. 로컬에서 도는 모든 에이전트 도구는 "기본 로그 레벨"과 "persistence 정책"을 한 번씩 점검할 가치가 있어요. 이번 사건이 좋은 점검 트리거가 됩니다.

바이브코딩의 다음 리스크는 모델이 "이상한 코드를 짜는 것"이 아니라, 도구 자체가 호스트 머신을 갉아먹는 것일 수 있습니다. 한 명의 사용자가 8일 만에 글로벌 패치를 끌어낸 이번 사건은, 우리가 매일 띄워두는 AI 에이전트의 default 설정을 한 번씩 들여다보라는 명확한 신호입니다.

출처: GitHub Issue #28224, TechTimes 보도, Notebookcheck 분석, Hacker News 토론.