codex 5시간 한도에 막혔을 때, 작업을 멈추지 않는 분산 워크플로

2026년 08월 27일

0 Views

Codex로 API 리팩터링을 맡겨두고 Warp 터미널에서 테스트 루프를 돌리던 중, 갑자기 “나중에 다시 시도하라”는 식의 5시간 대기 메시지에 걸렸습니다. 결론부터 말하면 codex 5시간 한도는 우회할 문제가 아니라, 작업 단위를 쪼개고 대체 에이전트로 이어서 처리해야 하는 운영 문제에 가깝습니다.

한도에 걸린 지금, 마지막 diff와 실패 테스트부터 기록해두세요. 다음 요청 품질이 바로 달라집니다.

특히 한 번에 큰 PR을 만들게 하거나, 실패한 테스트를 계속 재시도시키면 생각보다 빨리 막힙니다. 저처럼 Claude Code, Cursor, Codex를 번갈아 쓰는 분이라면 이 글의 핵심은 간단합니다. Codex에는 “좁고 검증 가능한 작업”만 맡기고, 대기 시간에는 Claude Code나 Cursor로 컨텍스트 정리와 테스트 보강을 진행하는 겁니다.

지금 한도에 걸렸다면 먼저 작업 로그를 남기세요.

멈춘 지점, 마지막 명령어, 실패 테스트를 적어두면 5시간을 그냥 버리지 않습니다.

바로 체크리스트 보기

제가 실제로 막힌 셋업

당시 작업은 Node.js 백엔드의 인증 미들웨어를 정리하는 일이었습니다. 흐름은 이랬습니다. Warp에서 Git 브랜치를 따고, Codex에게 오래된 Express 라우터를 정리하게 한 뒤, npm test와 npm run lint 결과를 다시 붙여 넣었습니다.

문제는 제가 작업을 너무 크게 던졌다는 겁니다. “인증 구조 전체를 정리하고 테스트까지 맞춰줘”라고 요청했더니 Codex가 여러 파일을 한꺼번에 고쳤고, 저는 실패 로그를 다시 던지며 재시도를 반복했습니다. 몇 번은 생산적이었지만, 어느 순간부터 한도 메시지가 뜨면서 흐름이 끊겼습니다.

핵심 답: 5시간은 ‘개발 중단 시간’이 아니다

이 제한은 계정, 요금제, 모델, 서버 상태, 사용 패턴에 따라 표시 방식이 달라질 수 있습니다. 그래서 정확한 리셋 시각을 외워두기보다 대기 시간을 전제로 워크플로를 설계하는 편이 안전합니다.

제가 바꾼 방식은 단순합니다. Codex에는 “한 파일의 타입 오류 3개 고치기”, “이 테스트 하나를 통과시키기”, “이 함수의 부작용 제거하기”처럼 끝이 보이는 일만 맡깁니다. 큰 설계 판단은 Claude Code에서 먼저 정리하고, Cursor는 코드베이스 탐색이나 빠른 수정을 할 때 씁니다.

한도에 걸렸을 때 선택지는 이렇게 갈립니다

선택지	좋은 점	주의할 점	추천 상황
그냥 기다리기	가장 안전하고 정책 위반 리스크가 없음	컨텍스트를 잃기 쉬움	이미 PR이 거의 완성된 경우
작업을 더 작게 쪼개기	다음 사용량을 아낄 수 있음	처음에는 귀찮음	리팩터링, 테스트 수정, 마이그레이션
Claude Code로 이어가기	터미널 중심 작업과 긴 맥락 정리에 강함	도구별 응답 스타일 차이를 맞춰야 함	실패 로그 분석, 변경 계획 정리
Cursor에서 수동 보정	파일 이동과 부분 수정이 빠름	큰 자동 변경을 계속 맡기면 산만해짐	작은 UI/코드 수정, 참조 검색

구체 예시: 인증 미들웨어 리팩터링을 쪼개는 법

예를 들어 “로그인 관련 코드를 전부 개선해줘”는 한도도 빨리 쓰고 결과 검증도 어렵습니다. 저는 다음처럼 바꿨습니다.

1. authMiddleware.ts에서 any 타입 제거
2. refreshToken 검증 로직만 순수 함수로 분리
3. authMiddleware.test.ts의 실패 케이스 2개만 통과
4. 변경된 파일 기준으로 README의 환경변수 설명만 갱신

이렇게 나누면 Codex가 실패해도 피해 범위가 작습니다. 한도에 걸려도 마지막 단계가 명확해서 Claude Code에 “여기까지 했고, 다음은 3번”이라고 넘길 수 있습니다. 실제로 저는 이 방식으로 대기 시간 동안 테스트 이름 정리, TODO 주석 제거, 커밋 메시지 초안 작성까지 처리했습니다.

이런 분에게 이 운영법을 추천합니다

Codex를 메인 개발자로 쓰려는 입문자

처음에는 에이전트에게 크게 맡기는 게 편해 보입니다. 하지만 초반일수록 작은 작업으로 성공 경험을 쌓는 편이 낫습니다. “한 번에 앱 만들기”보다 “한 엔드포인트를 테스트와 함께 완성하기”가 한도 관리에도 좋습니다.

Claude Code·Cursor를 같이 쓰는 빌더

이미 여러 도구를 쓰고 있다면 역할을 나누세요. 제 기준은 이렇습니다. Codex는 빠른 구현 후보 만들기, Claude Code는 터미널에서 계획·검증 루프 잡기, Cursor는 파일 위치를 보며 손으로 마무리하기. Gemini는 문서나 대안 아이디어를 넓게 볼 때 가끔 씁니다.

많이 하는 실수: 한도 메시지를 보고 바로 새 대화를 파는 것

급하면 새 세션, 새 프롬프트, 다른 모델을 막 열게 됩니다. 그런데 이때 가장 많이 터지는 문제가 서로 다른 에이전트가 같은 파일을 다른 방향으로 고치는 충돌입니다.

저는 한도에 걸리면 먼저 git diff를 저장합니다. 그다음 git status, 실패한 테스트 명령어, 마지막으로 기대한 동작을 메모합니다. Notion을 써도 되고, 저는 그냥 리포지토리 안에 임시로 agent-notes.md를 만들 때가 많습니다.

FAQ

Q. codex 5시간 한도는 정확히 언제 풀리나요?

표시되는 제한은 계정과 사용 상황에 따라 달라질 수 있어 고정 시각으로 단정하기 어렵습니다. 화면에 안내된 대기 시간을 기준으로 보고, 최신 조건은 OpenAI 공식 문서를 확인하는 게 안전합니다.

Q. VPN이나 계정 변경으로 해결해도 되나요?

권하지 않습니다. 서비스 약관이나 계정 안정성 문제가 생길 수 있습니다. 개발자로서는 우회보다 작업 단위 축소와 도구 분산이 장기적으로 훨씬 낫습니다.

Q. 한도에 안 걸리려면 프롬프트를 어떻게 써야 하나요?

“전체 수정” 대신 파일명, 실패 테스트, 완료 조건을 함께 주세요. 예를 들면 “authMiddleware.test.ts의 ‘expired token’ 케이스만 통과시키고, 변경 이유를 3줄로 설명해줘”처럼 쓰면 낭비가 줄어듭니다.

지금 바로 할 일

1분 안에 기록: 마지막 프롬프트, 에러 메시지, 실행한 명령어를 적습니다.
작업 쪼개기: 다음 요청을 파일 1~2개, 테스트 1개 단위로 줄입니다.
대체 루프 실행: Claude Code나 Cursor에서 diff 검토, 테스트 보강, 커밋 메시지를 준비합니다.
재개 조건 만들기: 한도가 풀리면 바로 붙여 넣을 “다음 한 문장 요청”을 미리 써둡니다.

codex 5시간 한도는 짜증나는 장애물이지만, 잘게 나눈 작업 로그가 있으면 팀원 한 명이 잠깐 자리 비운 정도로 줄일 수 있습니다. 다음 사용 가능 시간이 오기 전까지는 코드를 더 벌리지 말고, 검증 가능한 다음 한 걸음을 준비해두세요.

오늘도, 코딩할 용기.

codex 5시간 한도에 막혔을 때, 작업을 멈추지 않는 분산 워크플로