2026년 8월 7일, 한 분이 준 Plus 권한을 쓰던 중 Codex로 아무것도 하지 않았는데 주간 한도가 또 사라지는 문제를 겪었다. 이번에는 추측을 멈추고 모든 클라이언트를 끈 채 103시간을 지켜봤다. 그 시간 동안 소진은 0%였다. 앱을 켜자 정확히 6%가 빠졌고, 끄자 그 자리에서 멈췄다.
이상함을 처음 확인한 순간은 언제였나?
출발점은 단순했다. Codex로 아무것도 하지 않았는데 주간 한도가 다시 사라졌다. 이전처럼 가능성만 나열하는 대신, 이번에는 앱과 다른 클라이언트를 분리해 관찰하는 잠복 실험을 선택했다. 무엇을 켜고 무엇을 끈 상태에서 숫자가 움직이는지를 보는 것이 목적이었다.
“켜면 새고 끄면 멈추는 걸 세 번 반복했다.”
이 문장은 이번 기록의 결론을 먼저 말한다. 하지만 결론은 한 번의 우연한 수치가 아니라, 서로 다른 조건에서 되풀이한 관찰 위에 있다. 클라이언트를 전부 끈 상태, 프록시와 로그인만 남긴 상태, 앱을 실행한 상태를 나누고 각각의 시간과 변화를 기록했다.
103시간 동안 무엇을 꺼 두고 관찰했나?
첫 장면은 모든 클라이언트를 종료한 상태였다. 이 상태를 103시간 47분 유지했을 때 소진은 0%였다. 이어서 프록시와 로그인은 살리고 앱만 꺼 둔 조건도 41시간 동안 확인했고, 이때도 소진은 0%였다. 단순히 로그인되어 있다는 사실만으로 수치가 줄어든 것은 아니었다.
이 두 조건은 어떤 기능이 원인이라고 증명하는 마지막 답은 아니지만, 최소한 ‘로그인만 되어 있으면 계속 소진된다’는 설명에는 맞지 않는 기록이다. 103시간 47분과 41시간은 각각 긴 시간 동안 0%라는 결과를 남겼다. 그래서 다음 단계에서는 다른 조건을 하나씩 더했다.
앱을 다시 켠 뒤 어떤 변화가 있었나?
앱을 실행했을 때는 15분마다 1%씩 정확히 6%가 빠졌다. 앱을 종료하면 그 자리에서 멈췄고, 다시 켜자 감소가 재개됐다. 이 켜기와 끄기, 다시 켜기를 나는 세 번 반복했다. 앱 실행과 수치 변화의 순서가 같은 방식으로 반복된 것이 이번 기록의 핵심이다.
원문에서는 앱을 켜 두기만 해도 옛 세션의 제안이 백그라운드로 돌며 한도를 먹는다고 적었다. 이 설명은 관찰한 현상과 함께 남긴 해석이다. 나는 새 작업을 실행했을 때의 소진이 아니라, 앱을 켜고 끄는 조건 변화에 맞춰 6%와 정지가 반복되는 모습을 기록했다.
숫자로 보면 조건별 차이는 어떻게 보이나?
시간과 수치를 한 표에 놓으면 무엇을 비교했는지 더 분명해진다. 아래 표는 내가 적은 관찰값이며, 다른 환경에서 같은 결과를 보장하는 일반 규칙은 아니다.
| 조건 | 관찰 시간 | 소진 기록 |
|---|---|---|
| 클라이언트 전부 종료 | 103시간 47분 | 0% |
| 프록시·로그인 유지, 앱만 종료 | 41시간 | 0% |
| 앱 실행 | 15분 간격 | 1%씩, 합계 6% |
| 앱 종료 | 종료 직후 | 즉시 정지 |
문제를 외부에 어떻게 남겼나?
나는 이 현상을 GitHub 이슈 37445번으로 남겼다. 댓글에도 계속 숫자를 기록하겠다고 했다. 재현 조건을 말로만 적는 대신 103시간 47분, 41시간, 15분, 1%, 6%, 그리고 세 번의 반복이라는 값을 함께 둔 이유다. 문제가 다시 생기거나 다른 사람이 확인할 때, 무엇을 비교했는지부터 알 수 있어야 하기 때문이다.
이 글의 원문에서 말한 이슈는 GitHub 이슈 37445다. 이 링크는 내가 남긴 관찰과 토론의 맥락을 확인하기 위한 것이며, 이 글은 해당 이슈의 해결 여부나 이후 상태를 새로 주장하지 않는다.
다시 같은 문제가 생긴다면 무엇부터 할까?
내가 다시 한다면 ‘한도가 줄었다’는 한 문장만 남기지 않고, 앱이 켜져 있는지, 모든 클라이언트를 종료했는지, 로그인과 프록시는 어떤 상태인지, 그리고 몇 분 뒤 숫자가 어떻게 달라졌는지를 순서대로 적겠다. 이번 실험은 0%가 나온 긴 관찰과 6%가 빠진 짧은 관찰을 함께 비교했기 때문에 방향을 좁힐 수 있었다.
- 모든 클라이언트를 끈 시간과 소진율을 함께 기록한다.
- 로그인 상태와 앱 실행 상태를 하나씩 분리한다.
- 변화가 보인 간격을 분 단위로 남긴다.
- 한 번의 변화가 아니라 켜기·끄기 반복에서 같은지 확인한다.
- 외부 보고에는 조건과 수치를 함께 적는다.
이 실험을 읽고 많이 받은 질문
103시간 동안 정말 아무것도 안 했나요?
원문에 적은 조건은 모든 클라이언트를 종료한 상태이며, 103시간 47분 동안 소진 0%를 관찰했다는 것이다.
로그인만 되어 있으면 한도가 줄었나요?
프록시와 로그인만 살리고 앱을 꺼 둔 41시간의 기록에서는 소진이 0%였다.
앱을 켜면 한 번에 6%가 빠졌나요?
내 기록에서는 앱 실행 뒤 15분마다 1%씩 빠져 합계 6%가 됐다. 종료하면 즉시 멈추고 다시 켜면 재개됐다.
이 현상은 모든 사용자에게 동일한가요?
이 글은 내 조건에서 관찰한 기록이다. 다른 계정이나 환경에서도 동일하다고 일반화하지 않으며, 원문도 내 실험값을 남긴 것이다.
그날의 기록이 남긴 전환점
이번에는 문제를 발견한 뒤 바로 범인을 정하지 않았다. 103시간 47분의 0%, 41시간의 0%, 15분마다 1%씩 합계 6%, 그리고 세 번의 반복을 차례로 쌓았다. 그래서 ‘켜면 새고 끄면 멈춘다’는 문장이 감상이 아니라 관찰 순서의 요약으로 남았다.
숫자와 조건을 같이 적은 이유
한도가 사라졌다는 말만으로는 무엇을 다시 확인해야 하는지 알기 어렵다. 그래서 나는 103시간 47분, 41시간, 15분, 1%, 6%처럼 시간을 수치와 함께 적었다. 이 값들은 멋있어 보이기 위한 장식이 아니라, 앱을 실행한 조건과 종료한 조건을 비교하기 위한 표식이었다.
내 기록에서 0%는 아무런 문제가 없다는 보증이 아니라, 해당 조건에서 관찰된 결과다. 반대로 앱을 켠 뒤의 6%도 모든 경우의 사용량을 뜻하지 않는다. 두 결과를 같은 문장에 두고 켜기와 끄기를 세 번 반복했기 때문에, 나는 추측 대신 재현 가능한 순서를 외부에 남길 수 있었다.
이처럼 조건을 나눠 두면 다음 확인에서 무엇을 바꿔야 하는지도 명확해진다. 이번에는 앱의 실행 여부가 그 기준이었다.
관찰한 숫자를 다음 사람도 같은 순서로 읽을 수 있게 남기는 것이 이 실험의 마지막 목적이었다.
이 글은 제가 2026-08-07에 스레드에 올리고 직접 겪은 일을, 빠졌던 맥락과 확인 방법까지 더해 다시 쓴 글입니다. 원문은 여기서 볼 수 있습니다 → 원본 스레드 글