2026년 8월 2일, 지난 글에서 원인을 막았다고 적은 뒤 닷새가 지났을 때였다. 한도가 11시간 만에 0이 됐다. 그날 나는 코덱스를 한 번도 열지 않았고 세션 기록 폴더도 만들어지지 않았다. 사용량이 곧 내 작업 시간인 상황에서, 엿새를 통째로 잃을 수 있다는 감각이 먼저 왔다.
한도가 줄었는데 작업 기록이 없다면 무엇부터 봐야 할까?
내가 남긴 답은 단순했다. 기록이 없는 날에는 내가 코덱스를 열지 않았다는 점부터 분명히 적는 것이다. 11시간, 0, 닷새라는 숫자는 추측보다 먼저 확인한 관찰값이다. 무엇이 사용량을 가져갔는지 바로 단정하지 않고, 이미 꺼 둔 항목과 남아 있는 조건을 차례로 분리했다.
“그날 나는 코덱스를 한 번도 열지 않았다. 세션 기록 폴더가 아예 안 만들어졌다.”
사용량 숫자만 보면 내가 작업해서 줄어든 것처럼 보일 수 있다. 하지만 이 기록에는 반대 근거가 함께 있다. 세션 폴더가 없었다는 점, 로그아웃 뒤 다시 로그인해도 숫자가 계속 내려갔다는 점이다. 두 가지를 같이 적어 둬야 나중에 기억만으로 상황을 다시 만들지 않게 된다.
지난번에 끈 두 가지는 실제로 멈춰 있었나?
지난번에 잡은 범인은 두 개였다. 매일 아침 도는 자동화와 프로젝트를 열 때마다 도는 추천 프롬프트다. 이번 기록에서는 둘 다 꺼 둔 상태였고, 추천 프롬프트는 3일째 발동이 0건이었다. 이미 조치한 항목이 다시 원인이라고 가정하지 않기 위해, 꺼 둔 상태 자체를 별도 조건으로 남겼다.
- 매일 아침 도는 자동화는 꺼 둔 상태였다.
- 프로젝트를 열 때마다 도는 추천 프롬프트도 꺼 둔 상태였다.
- 추천 프롬프트의 발동 기록은 3일째 0건이었다.
- 클라우드에 돌던 작업은 없었다.
- 로그인된 기기는 두 대였고 둘 다 내 맥이었다.
조건을 적어 보면 남은 공간은 오히려 더 좁아진다. 클라우드에서 도는 작업도 없고, 두 대의 로그인 기기도 모두 내 맥이며, 추천 프롬프트도 0건이었다. 그래서 “아마 이것 때문”이라는 짧은 결론보다 “이 조건에서도 한 주치가 하루 만에 사라졌다”라는 문장이 더 정확했다.
로그아웃과 재로그인 뒤에도 숫자가 내려간 사실은 왜 중요한가?
로그아웃하고 다시 로그인해도 숫자는 계속 내려갔다. 이 한 줄은 화면에 표시된 숫자만 다시 보지 않고, 계정 상태를 바꾼 뒤에도 같은 현상이 이어졌다는 기록이다. 이 시점에서 내가 할 수 있는 말은 해결됐다는 선언이 아니라, 이미 확인한 조건만으로는 설명되지 않았다는 것이다.
이런 기록의 핵심은 원인을 지어내지 않는 데 있다. 닷새 뒤, 11시간, 0, 엿새, 3일, 두 대처럼 원문에 있는 수치를 놓고 보면 사건의 순서는 명확하다. 먼저 지난 글에서 원인을 막았고, 그다음 새 한도 문제가 생겼으며, 작업 기록과 자동화·클라우드·기기 조건을 다시 확인했다.
이번 기록에서 남겨야 할 결론은 무엇인가?
나는 한도가 줄었다는 결과만 쓰지 않고, 작업을 열지 않았다는 사실과 세션 폴더가 없었다는 사실을 함께 남겼다. 사용량은 내 작업 시간을 뜻하기 때문에, 원인을 확정할 수 없을 때도 잃어버린 시간과 이미 배제한 조건을 분리해서 적는 편이 다음 확인의 출발점이 된다.
참고로 이 글에서 다루지 못한 서비스의 공식 안내는 OpenAI Codex 도움말 모음에서 직접 확인하는 편이 안전하다. 아래 내용은 그 안내를 실행했다는 뜻이 아니라, 원문에 남은 기록을 다시 읽기 위한 참고 링크다.
다시 확인할 때의 메모
다음에 같은 숫자를 다시 보게 된다면, 나는 먼저 그날의 세션 폴더 유무를 적고, 매일 도는 자동화와 추천 프롬프트의 상태를 다시 본 뒤, 클라우드 작업과 로그인 기기를 차례로 적을 것이다. 이것은 새 원인을 단정하는 절차가 아니다. 같은 조건을 같은 순서로 남겨, 설명되지 않는 부분을 더 선명하게 만드는 방법이다.
원문에서 가장 눈에 띄는 것은, 나는 이미 원인을 잡았다고 쓴 뒤 다시 같은 종류의 숫자를 봤다는 점이다. 그래서 이번 점검은 처음부터 모든 가능성을 넓게 늘어놓는 대신, 지난번에 끈 두 항목을 먼저 확인하는 방식으로 시작한다. 자동화와 추천 프롬프트를 둘 다 꺼 두었고, 추천 프롬프트는 3일째 0건이었다는 기록은, 이전 조치가 남아 있는지를 확인한 흔적이다.
그다음에 남은 것은 세션 기록, 클라우드 작업, 로그인 기기다. 세션 폴더가 만들어지지 않았고, 클라우드에 돌던 작업도 없었으며, 로그인된 기기는 두 대의 내 맥뿐이었다. 이 목록은 원인을 찾아냈다는 증거가 아니라, 그날 무엇을 살폈는지 보여 주는 점검표다. 원인을 모를수록 “없었다”고 확인한 조건을 버리지 않고 남겨야 한다고 나는 생각했다.
또 하나는 시간의 크기다. 한도가 11시간 만에 0이 됐다는 말과 엿새를 통째로 잃었다는 말은 같은 사건을 서로 다른 각도에서 보여 준다. 앞의 숫자는 화면에서 확인한 변화이고, 뒤의 숫자는 그 변화가 내게 어떤 작업 공백으로 다가왔는지다. 둘을 나눠 쓰면 숫자와 경험이 뒤섞이지 않는다.
이 글을 다시 읽으며 정리한 기준은 세 가지다. 내가 실제로 작업을 열었는지, 이미 꺼 둔 자동화가 다시 움직였는지, 계정 상태를 바꾼 뒤에도 변화가 이어졌는지다. 원문에는 이 세 기준 각각에 대한 관찰이 있다. 반대로 그 관찰로 설명되지 않는 부분도 있다. 그래서 여기서는 해결책보다, 다음 확인을 위해 남겨 둔 관찰의 순서를 더 중요하게 둔다.
댓글로 많이 받은 질문
그날 코덱스를 아예 열지 않았다는 근거는 무엇인가?
원문에는 세션 기록 폴더가 아예 만들어지지 않았고 그날 코덱스를 한 번도 열지 않았다고 적혀 있다. 이 두 기록을 함께 근거로 남겼다.
지난번에 막은 항목은 무엇이었나?
매일 아침 도는 자동화와 프로젝트를 열 때마다 도는 추천 프롬프트 두 가지였다. 이번에는 둘 다 꺼 둔 상태였다고 원문에 적혀 있다.
추천 프롬프트는 실제로 다시 실행됐나?
아니다. 원문 기준으로 추천 프롬프트는 3일째 발동이 0건이었다. 그래서 이번 사용량 감소를 그 항목 하나로 설명하지 않았다.
로그인 기기는 몇 대였나?
로그인된 기기는 두 대였고 둘 다 내 맥이었다. 클라우드 작업도 없었다는 조건을 함께 확인했다.
이 글은 제가 2026-08-02에 스레드에 올리고 직접 겪은 일을, 빠졌던 맥락과 확인 방법까지 더해 다시 쓴 글입니다. 원문은 여기서 볼 수 있습니다 → 원본 스레드 글