Codex, 과도한 로그 기록으로 SSD 수명 위협

Codex의 SQLite 로그 데이터베이스는 약 21일간 37TB의 데이터를 기록하며, 이는 연간 640TB에 달하는 수치입니다. 이처럼 과도한 쓰기 작업은 쓰기 증폭(Write Amplification) 현상을 유발하여 SSD의 내구 연한(Write Endurance)을 심각하게 단축시킵니다. 특히, 1TB SSD의 경우 1년 안에 보증된 쓰기 용량을 초과할 수 있다는 분석이 나옵니다. 이는 데이터 격리 아키텍처(Data Isolation Architecture) 부재와 함께, 로그 데이터의 실제 가치 대비 과도한 리소스 소모를 야기합니다.

문제의 근본 원인으로 TRACE 레벨의 과도한 로깅 설정이 지목됩니다. 전체 로그의 약 70.7%를 차지하는 TRACE 레벨 로그는 대부분 inotify 이벤트와 같은 저수준 시스템 정보나 내부 통신 기록을 포함합니다. 또한, 로그 데이터에 대한 데이터 미저장 정책(Zero-Retention Policy)이 부재하여 불필요한 데이터가 계속 축적되는 것으로 보입니다. 이를 개선하기 위해 로그 필터링(Log Filtering) 강화 및 데이터 보존 정책(Data Retention Policy) 수립이 시급합니다.

커뮤니티에서는 SQLite 트리거(Trigger)를 사용하여 로그 삽입을 차단하거나, VACUUM FULL 명령어로 데이터베이스 크기를 줄이는 임시 해결책이 공유되었습니다. 하지만 이는 근본적인 해결책이 아니며, 품질 관리(Quality Control) 및 테스트 프로세스(Testing Process) 부재에 대한 비판이 제기됩니다. 특히, AI 기반 코드 생성 도구(AI Code Generation Tool)가 오히려 개발자의 연구 및 검증 노력을 대체하면서 이러한 '슬롭웨어(Slopware)' 문제가 발생하는 것 아니냐는 지적도 있습니다.

이슈가 공개된 지 일주일이 지났음에도 OpenAI 측의 공식적인 대응이 없어 개발자 커뮤니티의 실망감이 커지고 있습니다. 일부 사용자는 Claude Code에서도 유사한 로그 과다 기록 문제가 발생했다고 언급하며, AI 모델 제공 업체들의 기술적 책임감에 대한 의문이 제기됩니다. 특히, Closed Source 정책으로 인해 사용자가 직접 문제를 해결하기 어렵다는 점이 비판의 대상이 되고 있습니다.

과도한 로그 기록 대신, 이벤트 종류, 지속 시간, 성공/실패 여부, 토큰 사용량, 페이로드 크기 등 요약된 정보만 저장하는 방안이 제안되었습니다. 또한, RAM 기반 임시 저장소(RAM-backed tmpfs) 활용이나 로그 데이터베이스 크기 제한(Log Database Size Cap) 설정 등도 대안으로 논의되고 있습니다. 이는 데이터 격리 아키텍처(Data Isolation Architecture)를 통해 불필요한 로그를 최소화하고, 리소스 효율성(Resource Efficiency)을 높이는 방향으로 나아가야 함을 시사합니다.