제가 Codex Plus를 쓰면서 발견한 가장 흥미로운 작업 패턴 중 하나는 프롬프트 문장 자체보다도 타이밍과 더 관련이 있습니다.
5시간 한도나 주간 한도의 마지막 3–5% 정도가 남았을 때, 저는 더 이상 그 잔여분을 작은 요청에 쓰지 않습니다. 오히려 반대로 합니다. 미리 준비해 둔 여러 프로젝트에 걸쳐 가장 큰 개발 작업을 시작하는 데 그 남은 사용량을 씁니다.
보통 이런 작업들입니다. 전체 TypeScript 마이그레이션, 저장소 전반의 ESLint 정리, 코드베이스 전체에 대한 깊은 버그 검토, 또는 가볍게 실행하기에는 부담스러운 대규모 리팩터링 같은 일들입니다.
제 작업 방식이 바뀐 이유
이유는 단순합니다. 눈에 보이는 한도가 다 소진된 것처럼 보인 뒤에도 Codex가 계속 작업하는 모습을 한 번이 아니라 여러 번 봤기 때문입니다. 겉으로는 세션이 끝난 것처럼 보이는데도 작업이 계속 진행되고, 때로는 그대로 완료되기도 했습니다.
물론 이것을 제품의 보장된 규칙이라고 말하려는 것은 아닙니다. 반복적으로 겪은 경험이 제 행동을 바꿀 만큼 인상적이었다는 뜻입니다. 이 패턴을 본 뒤로는 마지막 몇 퍼센트를 아껴야 할 자원으로 보지 않게 됐습니다. 오히려 가장 비용이 크고 영향력이 큰 작업을 시작할 최적의 순간처럼 느끼게 됐습니다.
지금은 마지막 구간을 어떻게 쓰는가
예전처럼 안전하고 가벼운 요청에 마지막 사용량을 쓰는 대신, 지금은 고강도 개발 작업을 시작하는 출발점처럼 활용합니다. 예를 들면 다음과 같습니다.
- 전체 TypeScript 마이그레이션
- 저장소 전반의 ESLint 정리
- 대규모 코드베이스에 대한 깊은 버그 검토
- 구조 수준의 대규모 리팩터링
핵심은 준비 상태입니다. 프로젝트가 이미 실행 가능한 상태이고 작업 범위가 분명할수록 이 방식은 더 유용합니다. 그런 시점에는 남은 한도를 작은 일에 쓰는 것이 오히려 가장 가치 높은 순간을 흘려보내는 느낌이 듭니다.
왜 이게 중요하게 느껴지는가
Codex Plus 같은 도구는 단순히 성능만의 문제가 아닙니다. 노력을 어떤 타이밍에 배치하느냐도 중요합니다. 같은 한도라도 시점을 조금만 바꾸면 실제로 얻는 가치가 크게 달라질 수 있습니다.
제 경우에는 제품을 대하는 감각 자체가 달라졌습니다. 마지막 몇 퍼센트는 이제 세션의 끝처럼 느껴지지 않습니다. 망설임을 멈추고 가장 무거운 일을 도구에 넘겨야 하는 순간처럼 느껴집니다.
가끔은 눈에 보이는 한도가 끝난 뒤에도 Codex가 계속 제 대신 일해 주는 것처럼 느껴집니다. 이것이 의도된 경계 상황인지, 아니면 특정 작업이 실제로 마무리되는 방식 때문인지는 모르겠습니다. 다만 충분히 유용했기 때문에 지금은 이 관찰을 기준으로 작업 흐름을 짜고 있습니다.
개발자에게 유용한 실전 포인트
소프트웨어 개발에 Codex Plus를 쓰고 있다면, 마지막 한도를 어떻게 쓸지 직접 시험해 볼 가치가 있습니다. 마지막 몇 퍼센트는 반드시 보수적으로 써야 한다고 가정할 필요는 없습니다. 적어도 제 경우에는 그 반대가 더 효과적이었습니다.
특히 마이그레이션, lint 정리, 대규모 검토, 여러 저장소에 걸친 리팩터링 작업에서 다른 개발자들도 비슷한 패턴을 봤는지 정말 궁금합니다.