Banked Codex reset 사용법: 5시간·주간 한도 막혔을 때 확인할 것

reset은 추가 크레딧이 아닙니다

Codex를 업무에 붙이면 가장 당황스러운 순간은 모델이 틀릴 때보다 한도에 막힐 때입니다. 특히 긴 디버깅이나 리팩터링 중간에 멈추면, 남은 작업보다 맥락 복구가 더 비쌉니다. OpenAI 도움말은 banked reset을 “사용하기 전까지 계정에 저장되는 일회성 Codex 사용량 한도 reset”으로 설명합니다. 중요한 점은 이것이 구매한 credit도 아니고, 플랜 사용량을 영구적으로 늘리는 기능도 아니라는 것입니다.

실무에서는 reset을 비상 버튼처럼 생각하기 쉽습니다. 하지만 실제로는 적용 조건, 만료, 대상 usage window를 확인해야 하는 운영 도구입니다. 무작정 누르면 주간 reset 날짜가 바뀌거나, 필요한 시점보다 이르게 써버릴 수 있습니다. 팀 단위로 Codex를 쓰는 경우에는 더 조심해야 합니다.

이 글은 banked Codex reset을 언제 확인하고, 언제 쓰고, 문제가 생겼을 때 어떤 정보를 모아야 하는지 정리합니다. 핵심은 간단합니다. reset은 “막혔을 때 누르는 버튼”이 아니라 “큰 작업 전후로 관리해야 하는 한도 복구 수단”입니다.

banked reset과 automatic reset은 다릅니다

OpenAI 문서 기준으로 banked reset과 automatic 또는 global reset은 다른 개념입니다. banked reset은 계정에 저장되고 사용자가 직접 적용해야 합니다. 반면 automatic/global reset은 대상 사용량 한도에 직접 적용되며 Settings에 저장된 reset으로 나타나지 않습니다.

이 차이를 모르면 운영 중 혼선이 생깁니다. 예를 들어 팀원이 “reset을 받았다”고 말했을 때, 그것이 저장된 banked reset인지 이미 적용된 global reset인지 확인해야 합니다. 저장된 reset이면 Settings → Usage에서 만료와 적용 범위를 확인할 수 있습니다. 자동 적용 reset이면 별도 버튼이 없을 수 있습니다.

또 하나 중요한 점은 reset이 성공적으로 최소 하나의 eligible usage window를 갱신할 때만 소비된다는 설명입니다. 만약 갱신할 대상이 없다면 나중을 위해 남아 있을 수 있습니다. 그래서 reset 버튼이 보인다고 바로 눌러야 하는 것은 아닙니다. 현재 어떤 한도가 막혔는지 먼저 봐야 합니다.

언제 써야 하나: 작업 기준으로 판단하기

banked reset은 작은 작업에 쓰기보다 맥락 복구 비용이 큰 작업에 쓰는 편이 낫습니다. 예를 들어 대규모 장애 분석, 릴리즈 직전 회귀 테스트 수정, 중요한 보안 패치처럼 중단 비용이 큰 작업입니다. 반대로 문서 정리, 코드 스타일 수정, 단순 질문에는 reset을 아끼는 편이 합리적입니다.

사용 전에는 세 가지를 확인합니다. 첫째, 현재 막힌 것이 5시간 window인지 weekly window인지 확인합니다. 문서에 따르면 full banked reset은 5시간과 weekly Codex usage window를 refresh하고 weekly reset date를 바꿀 수 있습니다. 둘째, 만료 시간을 확인합니다. unused reset은 만료되면 복구되거나 재발급되지 않을 수 있습니다. 셋째, 지금 작업이 reset을 쓸 만큼 중요한지 판단합니다.

팀 환경이라면 개인 판단만으로 쓰지 않는 편이 좋습니다. 특히 Business나 Enterprise 환경에서는 workspace 정책과 좌석별 권한이 얽힐 수 있습니다. 적어도 “릴리즈 차단”, “장애 대응”, “보안 이슈” 같은 사용 기준을 문서화해두면 불필요한 논쟁이 줄어듭니다.

Settings → Usage에서 봐야 할 항목

문서 기준으로 banked reset은 desktop app, CLI, web의 settings → usage에서 확인할 수 있습니다. 표시 예시는 “1 reset available” 또는 “Full reset”처럼 나타날 수 있습니다. 사용 전에는 expiration detail을 보고 confirm해야 합니다.

여기서 확인할 것은 네 가지입니다. 첫째, 올바른 계정과 workspace를 보고 있는지입니다. 개인 계정과 회사 workspace를 번갈아 쓰는 개발자는 이 부분에서 자주 헷갈립니다. 둘째, reset이 적용되는 대상입니다. 모든 제한을 다 풀어주는 만능 버튼으로 보면 안 됩니다. 셋째, 만료 시간입니다. 넷째, 사용 후 reset 시간이 어떻게 바뀌었는지입니다.

사용 직후 dashboard가 바로 바뀌지 않을 수 있다는 설명도 있습니다. 퍼센트가 즉시 변하지 않는다면 refresh하거나 Settings → Usage를 다시 열고, 계정과 workspace가 맞는지 확인합니다. 이 과정을 기록하지 않으면 나중에 support에 문의할 때 설명이 약해집니다.

reset이 없거나 적용되지 않을 때의 대응

reset이 보이지 않거나 적용되지 않았다면 먼저 계정과 workspace를 확인합니다. 그 다음 Settings → Usage를 새로고침합니다. 여전히 문제가 있으면 support에 문의할 수 있지만, 문서에는 support가 수동 또는 courtesy reset을 제공하지 않는다고 설명되어 있습니다. 즉 “몰랐다”, “만료됐다”, “자격이 없었다”는 이유만으로 대체 reset이나 credit이 제공된다고 기대하면 안 됩니다.

문의가 필요하다면 자료를 모아야 합니다. 문서가 요구하는 정보는 예상한 offer 또는 announcement, 사용한 날짜·시간·시간대, 현재 Usage page 스크린샷, 사용한 Codex client와 model입니다. 이 정보 없이 “reset이 안 됐다”고만 보내면 확인이 느려집니다.

팀 내부에서도 같은 원칙을 쓰면 좋습니다. reset 관련 이슈가 생기면 Slack이나 이슈에 스크린샷, 시간대, 사용 모델, 막힌 window를 같이 남깁니다. 그래야 다음에 같은 문제가 반복될 때 운영 규칙을 바꿀 수 있습니다.

팀 운영 템플릿

Codex를 자주 쓰는 팀이라면 reset 사용 기록을 간단히 남기세요. 복잡한 도구가 필요하지 않습니다. 다음 항목만 있으면 충분합니다.

이 기록은 비용 관리보다 작업 연속성 관리에 가깝습니다. 어떤 작업이 reset을 자주 요구하는지 보면, 프롬프트가 너무 크거나, 파일 범위가 넓거나, 모델 선택이 과할 가능성을 찾을 수 있습니다.

실행 체크리스트

• reset은 추가 credit이 아니라 일회성 사용량 한도 refresh로 이해합니다.
• banked reset과 automatic/global reset을 구분합니다.
• 사용 전 Settings → Usage에서 계정, workspace, 만료, 대상 window를 확인합니다.
• 릴리즈 차단, 장애 대응, 보안 패치처럼 중단 비용이 큰 작업에 우선 사용합니다.
• 사용 후 dashboard가 바로 바뀌지 않으면 새로고침하고 계정을 다시 확인합니다.
• 문제가 계속되면 offer, 사용 시각과 시간대, Usage 스크린샷, client와 model 정보를 모아 문의합니다.

Codex reset은 개발 생산성을 늘리는 마법 버튼이 아닙니다. 다만 중요한 작업이 한도 때문에 끊기는 상황을 줄이는 운영 장치입니다. 다음에 reset 버튼이 보인다면 바로 누르기 전에 물어보세요. 지금 이 작업은 reset을 쓸 만큼 복구 비용이 큰가요?