Codex 가 무거워지기 시작했다면 이 글을 한 번 보세요.

This is the long-form blog cut of a note I originally posted on LinkedIn. The claims, numbers, and product names are the same; the formatting is for reading on the site.

Context

Original framing (translated in place for key technical posts; substance preserved):

처음엔 Codex 의 AI 자체가 느린 줄 알았는데 원인은 달랐어요. 로그가 8GB까지 쌓여 있었고 오래된 채팅이 활성 상태로 남아 있었습니다. 정리하고 나니 체감 속도가 10배 빨라졌다고 합니다.

이 방법이 X 에서 퍼지면서 OpenAI Codex 팀의 Tibo 가 직접 skill 로 만들어달라고 요청했고 지금은 GitHub 에 공개되어 있습니다. 직접 적용해봤는데 확실히 체감이 있었어요.

원본은 15가지인데 겹치는 항목을 묶어서 8가지로 정리했습니다. GitHub repo: https://lnkd.in/gMXPQxCq

① 무엇이 공간을 잡아먹는지 먼저 확인합니다 sessions, worktrees, logs, config, 로컬 DB 를 전부 확인하세요. 원인을 모르면 정리할 수 없거든요. 아래 4, 5, 6번 항목을 기준으로 원인을 분석해보세요.

② Codex 를 닫고 백업을 시작해야 합니다 Codex 가 실행 중이면 잠시 멈추어두세요. 로컬 DB 를 두 곳

처음엔 Codex 의 AI 자체가 느린 줄 알았는데 원인은 달랐어요. 로그가 8GB까지 쌓여 있었고 오래된 채팅이 활성 상태로 남아 있었습니다. 정리하고 나니 체감 속도가 10배 빨라졌다고 합니다.

이 방법이 X 에서 퍼지면서 OpenAI Codex 팀의 Tibo 가 직접 skill 로 만들어달라고 요청했고 지금은 GitHub 에 공개되어 있습니다. 직접 적용해봤는데 확실히 체감이 있었어요.

원본은 15가지인데 겹치는 항목을 묶어서 8가지로 정리했습니다. GitHub repo: https://lnkd.in/gMXPQxCq

① 무엇이 공간을 잡아먹는지 먼저 확인합니다 sessions, worktrees, logs, config, 로컬 DB 를 전부 확인하세요. 원인을 모르면 정리할 수 없거든요. 아래 4, 5, 6번 항목을 기준으로 원인을 분석해보세요.

② Codex 를 닫고 백업을 시작해야 합니다 Codex 가 실행 중이면 잠시 멈추어두세요. 로컬 DB 를 두 곳에서 동시에 건드리면 꼬일 수 있어요. 그리고 config, session index, state DB, memories, plugins 를 백업합니다.

③ 이어갈 작업은 handoff 문서로 먼저 옮기세요 정리하기 전에 이어가고 싶은 스레드부터 handoff 문서로 만들어두세요. 지금까지 한 작업과 다음 단계를 문서에 정리해두면 채팅을 보내도 맥락이 남습니다. 새 스레드에서 그 문서를 불러오면 끊김 없이 재개할 수 있어요.

④ 오래된 긴 채팅을 찾아서 아카이브로 보내세요 Codex 가 느려지는 가장 큰 원인이 이겁니다. 오래된 대화가 활성 상태로 남아 있으면 매번 그 기록을 불러옵니다. 7~10일 지난 채팅 중 중요 표시하지 않은 건 archived sessions 로 옮기세요. 사이드바에 몇 주 전 스레드가 남아 있을 이유가 없습니다.

⑤ stale worktree 와 큰 로그 파일도 같이 빼세요 채팅만 아카이브하면 끝이 아닙니다. 오래된 Codex worktree 가 hot 폴더에 남아 있으면 불필요한 부하가 됩니다. logs_2.sqlite 같은 로그 파일이 GB 단위로 커져 있으면 아카이브 폴더로 옮기세요. Codex 가 새 로그를 알아서 만듭니다. 두 파일 모두 다 삭제가 아니라 아카이브를 하는 편이 안전합니다.

⑥ 경로 꼬임과 죽은 config 항목을 정리합니다 특히 Windows 에서 일반 경로와 ?\C:… 형태 경로가 섞여 있으면 Codex 가 같은 프로젝트를 다르게 인식합니다. config 에 더 이상 존재하지 않는 폴더나 임시 경로가 남아 있으면 그것도 제거하세요.

⑦ 정리 후 반드시 검증하세요 config 가 정상적으로 파싱되는지, DB 가 열리는지, 활성 세션 크기가 줄었는지, 잘못된 경로가 남아 있지 않은지 확인합니다. 무거운 Node 나 dev-server 프로세스가 떠 있으면 필요 없는 것만 직접 닫으세요.

⑧ 이걸 매주 반복하는 루틴으로 만드세요 한 번 정리하고 끝내면 몇 주 뒤에 다시 같은 상태가 됩니다. 그래서 매주 report-only 스크립트를 돌려서 상태를 확인하고 필요할 때만 수동으로 정리하는 게 가장 안전해요. 어쩔 수 없지만 반복적인 주간 루틴으로 만들어야 합니다.

핵심은 하나입니다. 채팅은 오로지 실행용이고 기억은 모두 handoff 문서에 남기세요. 히스토리는 아카이브로 보내야 새 스레드에서 작업 속도를 높일 수 있습니다.

Links

• https://lnkd.in/gMXPQxCq