Codex 사용량 제한에 도달했을 때, 안전하게 재개하는 것은 '계속' 버튼을 누르는 것보다 어렵다

저는 긴 코딩 작업을 위해 Codex를 사용합니다. 짜증나는 부분은 자리를 비웠다가 돌아와서 작업이 중단된 것을 발견할 때입니다. 사용량이 다시 가능해지더라도, 저는 여전히 그 중단을 인지하고 무엇을 계속해야 할지 확인해야 합니다.

이것이 제가 만들고 있는 macOS 유틸리티 Continua의 배경이 되는 문제입니다. 의도하는 흐름은 간단합니다: 중단된 Codex 작업을 보존하고, 실제 사용 가능 여부를 기다린 다음, 환경을 확인하고, 그 동일한 작업을 재개하는 것입니다.

마지막 단계를 올바르게 처리하는 것이 쉽지 않습니다. 오늘 진행한 실제 테스트에서 제 자동화 테스트가 잡아내지 못한 실패 사례를 발견했습니다. 이것이 저에게 이러한 종류의 자동화를 구축하는 것에 대해 가르쳐 준 내용입니다.

리셋 시간이 메시지를 보낼 권한을 의미하지는 않는다

유혹적인 구현 방식은 타이머입니다: 리셋 시간을 기억하고, 기다린 다음, “계속”을 전송합니다.

하지만 그 대기 시간 동안 여러 가지가 변경될 수 있습니다:

• 원래의 Codex 프로세스가 종료되거나 대체될 수 있습니다.
• 사용자가 프로젝트를 전환하거나 동일한 작업에 대한 다른 세션을 열 수 있습니다.
• 사용자가 새로운 지침을 보내서 이전의 계속 진행이 무효화될 수 있습니다.
• 타이머가 만료되었을 때도 사용량이 여전히 불가능할 수 있습니다.
• 이전 제출물이 확인(acknowledgement)이 손실되었더라도 성공했을 수 있습니다.

타이머는 언제 다시 확인할지 답합니다. 그것은 특정 작업이 재개하기에 안전하다는 것을 확립하지 않습니다.

Continua에서는 저장된 중단과 계속 진행을 제출할 권한을 분리합니다. 저장된 기록은 원래의 작업을 식별하고 환경을 파악합니다. 재개하기 전에, 컨트롤러는 그것들이 여전히 일치한다는 신선한 증거가 필요합니다.

프로세스는 올바른 프로세스여야 한다

디스크에서 Codex 세션 파일을 찾는 것이 그것이 활성 세션임을 증명하지는 않습니다. 같은 작업에 대한 오래된 파일이 있을 수 있고, 세션 파일 이름은 상위 버전(upstream versions) 간에 변경될 수 있습니다.

현재 구현은 원래의 라이브 라이터와 실제로 열려 있는 롤아웃 파일을 확인합니다. 또한 작업 메타데이터와 프로젝트 범위도 확인합니다. 소유권이 없거나 모호할 때, 계속 진행을 제출하는 것은 추측일 것입니다.

이것은 데스크톱 자동화에 유용한 구분입니다: “기록을 찾았다(I found a record)”와 “이 기록의 실제 소유자를 찾았다(I found the live owner of this record)”는 서로 다른 주장입니다.

오늘의 실패 사례: 재시도하지 않은 안전한 중단

오늘 테스트에서는 진정한 사용량 제한 중단을 경험했습니다. Continua가 이를 보존했지만, 나중에 고정된 작업의 호스트를 명확하게 확립할 수 없어 검토 상태에 들어갔습니다.

사용량이 복구된 후에도 원래 작성자를 다시 확인할 수 있었습니다. 하지만 Continua는 여전히 재개되지 않았습니다. 검토 상태가 영구적으로 되어버린 것입니다.

제가 왜 이전에 호스트 관찰이 모호했는지 확립하지는 못했습니다. 하지만 중요한 실패를 보여주는 증거는 다음과 같습니다: 제출 전에 발생한 불확실성이 환경이 복구된 후에도 재시도되지 않는 상태가 되었다는 점입니다.

수정 사항은 두 가지 상황을 구분합니다:

1. 아무것도 제출되지 않은 경우. 원래 작업을 고정한 상태로 유지하고, 그 경계가 정해진 복구 기간 내에서 환경 검증을 재시도합니다.
2. 이미 제출이 존재할 수 있는 경우. 추가적인 제출을 고려하기 전에 그 결과를 조정(reconcile)해야 합니다. 맹목적으로 재시도하면 동일한 지침을 두 번 보낼 수 있습니다.

그 경계가 UI에 “준비됨(ready)”이라고 표시하는 것보다 더 중요합니다. 컨트롤러는 자신이 어떤 상황에 있는지 알기 위해 충분한 증거를 보존해야 합니다.

새로운 사용자 지침이 승리하다

실패 원인을 진단하는 동안, 저는 원래 채팅창에 새로운 지침을 전송했습니다. 그 시점에서 이전의 중단된 턴(turn)을 재개하는 것은 잘못되었을 것입니다.

설치된 패치 빌드에서는 저장된 체크포인트를 재생하여 더 새로운 활동을 감지했고, 이로 인해 오래된 계속 진행(stale continuation)이 취소되었습니다. 어떠한 계속 진행도 제출되지 않았습니다.

그것이 이 사례에 대한 올바른 결과였습니다. 복구 도구는 사용자가 이전에 자동화하려고 했던 것을 거부해야 할지라도, 사용자의 최신 지침을 존중해야 합니다.

오늘 제가 주장할 수 있는 것들

호스트 재시도(host-retry) 수정 사항이 구현되어 설치되었습니다. 엔진 스위트가 336개의 테스트를 통과했고, 27개의 격리된 네이티브 컨트롤러 검사에서 통과했습니다. 또한 설치된 빌드는 더 새로운 사용자 활동 이후 안전하게 취소되는 것까지 시연했습니다.

해당 결과들은 새로운 실제 사용량 제한 주기(real usage-limit cycle)를 통한 미개입 복구(unattended recovery)를 증명하지는 못합니다. 오늘 원래 주기가 실패했으며, 패치된 빌드 역시 동일한 작업에서 새로운 진정한 중단, 복원 가능한 가용성, 그리고 검증된 지속성을 필요로 합니다.

저는 자동화된 이러한 점검들을 완료된 출시(completed launch)처럼 제시하기보다는 Continua를 초기 테스트 단계에 유지하고 있습니다.

중단된 작업을 자동화하기 위한 체크리스트

만약 유사한 것을 구축하고 있다면, 행복 경로(happy path)를 최적화하기 전에 다음 경계들을 점검해 보시길 바랍니다:

• 중단 시점의 정확한 작업과 범위를 저장합니다.
• 조치를 취하기 전에 라이브 환경을 다시 확인합니다.
• 일시적인 불확실성을 완료되었을 수도 있는 제출(submission)과는 다르게 취급합니다.
• 불확실한 승인(acknowledgement)이 중복을 유발하는 것을 막기 위해 제출 식별자(submission identities)를 유지합니다.
• 새로운 사용자 활동이 나타날 때 오래된 작업은 취소합니다.
• 재시도 횟수를 제한하고 해결되지 않은 결과를 보이게 합니다.
• 패키징된 앱을 피처스(fixtures)뿐만 아니라 실제 이벤트에 대해서도 테스트합니다.

Continua는 추가 할당량이나 사용량 제한 우회 기능을 제공하지 않습니다. 이는 OpenAI 제품이 아닌 독립적인 프로젝트입니다. 그 목표는 사용량이 실제로 돌아온 후 지원되는 Codex 워크플로우 주변의 돌봄(babysitting)을 줄이는 것입니다.

Mac에서 Codex를 사용하는 경우: 긴 작업이 멈췄을 때, 더 큰 문제는 중단 사실을 인지하는 것인지, 무엇을 재개할지 결정하는 것인지, 아니면 자동적인 지속성을 신뢰하는 것입니까?

저는 몇 명의 초기 테스터와 워크플로우 피드백을 찾고 있습니다. Continua 초기 액세스.

공개 고지: 저는 Continua를 구축하고 있습니다. 이 기사는 프로젝트 구현 및 기록된 테스트 증거를 통해 AI 작문 지원을 받아 작성되었습니다. 이는 완료된 복구 시연이 아닌 초기 빌드를 설명합니다.