2026년 8월 1일 밤 9시, 나는 사용량이 다 닳았다는 사실을 알았다. 손을 쓰지 못해 입술로 커서를 움직이는 내게 사용량은 곧 작업 시간이다. 바닥나면 그날 일도 멈춘다. 그런데 그날은 코덱스를 거의 쓰지 않았는데도 70%가 사라져 있었다. 닷새를 뒤졌고, 세 번 틀린 뒤 네 번째에야 원인을 찾았다.
거의 쓰지 않았는데 왜 70%가 사라졌을까?
내가 처음 확인한 사실은 단순했다. 코덱스를 거의 쓰지 않은 날에 사용량의 70%가 사라졌고, 그 변화는 밤 9시에야 눈에 들어왔다. 문제의 크기와 원인은 처음부터 같지 않았다. 숫자는 분명했지만 그 숫자가 왜 줄었는지는 바로 말할 수 없었다.
“사용량이 곧 내 작업 시간이라 바닥나면 그날 일이 멈춘다.”
이 기록을 적을 때 중요한 것은 불편함을 크게 보이게 만드는 일이 아니라, 사용량이 내 작업 흐름에서 어떤 자리를 차지하는지 분명히 하는 일이다. 누군가에게 사용량은 다음 날 다시 확인할 수 있는 숫자일 수 있다. 내게는 그날 이어 가던 일을 멈춰야 하는 기준선이었다. 그래서 나는 ‘얼마나 줄었나’와 ‘왜 줄었나’를 따로 확인하기로 했다.
첫 번째 오진은 왜 계정 도용이었나?
처음에는 계정 도용을 의심했다. 내가 선택한 대응은 전 기기 로그아웃이었다. 사용하지 않았는데 수치가 줄었다면 다른 곳의 접근을 먼저 의심하는 것이 자연스러웠기 때문이다. 그러나 전 기기에서 로그아웃한 뒤에도 숫자는 계속 줄었다.
여기서 얻은 것은 해결책이 아니라 반증이었다. ‘다른 기기에서 누군가 쓰고 있다’는 가설은 그럴듯했지만, 로그아웃 뒤에도 같은 현상이 이어졌다는 기록과 맞지 않았다. 가능성이 있어 보이는 설명과 실제 숫자가 함께 움직이는지는 별도로 봐야 했다.
두 번째와 세 번째 확인에서 무엇이 달랐나?
두 번째에는 재로그인을 의심했다. 나는 분 단위로 로그를 뽑았고, 마지막 호출이 로그아웃보다 앞에 있었다는 사실을 확인했다. 즉 로그아웃 이후의 수치 변화는 마지막 호출의 시간 순서와 맞지 않았다. 원인을 거꾸로 짚고 있었다는 결론에 닿았다.
세 번째에는 내가 등록한 자동화를 점검했다. 매일 아침 9시에 도는 자동화를 껐지만, 다음 날에도 결과는 똑같았다. 자동화가 있다는 사실과 그 자동화가 이번 사용량 변화의 원인이라는 말은 다르다. 끈 뒤에도 같은 현상이 보였기 때문에, 이 가설도 원인으로 남길 수 없었다.
- 첫 번째 가설: 계정 도용, 전 기기 로그아웃 뒤에도 숫자가 계속 줄어 반증됨
- 두 번째 가설: 재로그인, 분 단위 로그에서 마지막 호출이 로그아웃보다 앞이었음
- 세 번째 가설: 매일 오전 9시 자동화, 꾼 다음 날에도 같은 변화가 이어짐
- 확인 기간: 닷새, 오진 횟수: 세 번, 원인 발견: 네 번째 확인
왜 그럴듯한 가설을 바로 믿지 않았을까?
세 번의 가설은 모두 처음에는 말이 됐다. 계정 도용은 사용하지 않은 사용량 감소를 설명해 보였고, 재로그인은 세션 변화를 설명해 보였으며, 자동화는 예약된 동작이라는 점에서 의심할 만했다. 하지만 나는 각각에 맞는 행동을 한 뒤 수치가 달라지는지를 다시 봤다. 달라지지 않은 가설은 설명이 아니라 오진으로 남겼다.
원문에는 네 번째에 원인을 찾았다고만 남겼다. 그래서 이 글에서도 그 원인이 무엇이었다고 덧붙이지 않는다. 원인을 공개하지 않은 기록에 빈칸을 채우는 것보다, 닷새 동안 어떤 순서로 가능성을 지웠는지를 남기는 쪽이 더 정확하다. 이 글의 핵심은 특정 원인의 이름이 아니라, 수치 변화 앞에서 확인 순서를 거꾸로 잡지 않았다는 데 있다.
비슷한 상황에서 먼저 남길 기록은 무엇일까?
나처럼 사용량 변화의 원인을 찾는다면, 먼저 추측을 확정하지 않고 시간과 행동을 한 줄씩 나눠 두는 편이 낫다. 내가 확인한 범위에서 전 기기 로그아웃, 분 단위 로그, 자동화 중지는 각각 다음 가설을 시험하는 동작이었다. 같은 조치를 했다는 사실만 적는 것이 아니라, 조치 뒤 숫자가 바뀌었는지도 함께 적어야 한다.
참고로 서비스의 사용량 기록과 계정 보안 관련 안내는 제공사가 갱신할 수 있다. 내 상황을 일반화하기보다, 각 서비스의 현재 안내를 함께 확인하는 것이 안전하다. OpenAI 도움말은 계정과 제품 사용 관련 공식 안내를 확인할 수 있는 출발점이다.
오해하기 쉬운 지점을 표로 정리하면?
| 처음 생각 | 내가 한 확인 | 기록으로 남은 결과 |
|---|---|---|
| 계정 도용 | 전 기기 로그아웃 | 숫자가 계속 줄었음 |
| 재로그인 | 분 단위 로그 확인 | 마지막 호출이 로그아웃보다 앞이었음 |
| 오전 9시 자동화 | 자동화 중지 | 다음 날에도 같은 변화가 있었음 |
댓글로 자주 받는 질문
사용량이 줄면 계정 도용부터 봐야 하나요?
나는 처음에 계정 도용을 의심했지만, 전 기기 로그아웃 뒤에도 숫자가 계속 줄어 이번 원인으로는 남기지 못했다.
로그는 왜 분 단위로 봤나요?
두 번째 가설을 확인할 때 마지막 호출과 로그아웃의 앞뒤를 비교해야 했기 때문에, 나는 분 단위 로그를 뽑아 확인했다.
자동화를 끄면 바로 결론이 나나요?
내 경우 자동화를 꾼 다음 날에도 결과가 같았다. 자동화가 존재한다는 사실만으로 원인이라고 결론 내리지는 않았다.
결국 원인은 무엇이었나요?
원문에는 네 번째에 찾았다고만 적혀 있다. 공개되지 않은 원인을 이 글에서 추정하거나 새로 만들지는 않는다.
그래서 남은 기준
밤 9시에 70%라는 숫자를 본 뒤, 나는 닷새 동안 세 번 틀렸다. 그래도 각 가설을 행동과 시간 기록으로 검증했기 때문에, 맞지 않는 설명을 버릴 수 있었다. 사용량이 내 작업 시간인 만큼, 다음에도 숫자가 이상하면 먼저 원인을 이름 붙이기보다 내가 무엇을 했고 숫자가 어떻게 움직였는지부터 남길 생각이다.
기록을 남길 때 지킨 순서
이번 문제에서 나는 70%라는 결과를 본 뒤 바로 한 가지 설명을 확정하지 않았다. 전 기기 로그아웃, 분 단위 로그 확인, 오전 9시 자동화 중지는 각각 다른 질문에 답하기 위한 행동이었다. 한 행동이 수치를 바꾸지 못했다면 그 행동 자체가 실패가 아니라, 다음 가설을 지우는 기록이 됐다.
특히 세 번 모두 그럴듯했다는 점을 남기고 싶다. 그럴듯함은 확인의 출발점일 수 있어도 결론은 아니다. 닷새 동안 같은 숫자를 다시 보고, 조치 전후의 순서를 남기고, 맞지 않는 설명을 지웠다. 네 번째에 원인을 찾았다는 원문 한 줄은 앞선 세 번의 반증이 있었기에 가능했다.
이 글은 제가 2026-08-01에 스레드에 올리고 직접 겪은 일을, 빠졌던 맥락과 확인 방법까지 더해 다시 쓴 글입니다. 원문은 여기서 볼 수 있습니다 → 원본 스레드 글