Codex에 며칠 걸릴 수 있는 큰 개발 일을 맡길 때는 긴 프롬프트 하나보다 명세, 단계별 완료 조건, 실행 안내, 검증, 진행 기록을 함께 준비하는 편이 관리하기 쉽습니다. OpenAI가 2026년 2월 23일 공개한 장시간 실행 사례도 약 25시간 이어진 실험을 통해 이 다섯 요소가 중요하다고 정리했습니다.
간단 요약
- 시작점: 결과물과 범위를 명세로 고정
- 단계마다 끝났다고 판단할 기준 작성
- 실행 절차·검증 명령·진행 기록을 유지
- 25시간 사례는 실험이지 일반적인 보장값이 아님
1. 긴 작업에서 먼저 흔들리는 것
큰 요청을 한 문장으로만 주면 목표가 넓고 완료 기준은 흐려집니다. 중간에 구현 방향이 조금 달라져도 무엇이 올바른 결과인지 비교하기 어려워집니다. 작업을 시작하기 전에 목표, 반드시 포함할 기능, 제외할 항목을 짧은 명세로 남겨야 이후 결정이 같은 기준을 따릅니다.
2. 1단계: 명세를 완료 가능한 결과로 바꾸기
“설계 도구를 만들어 달라” 대신 사용자가 할 수 있어야 할 동작, 지원할 데이터, 저장 방식, 이번 작업에서 다루지 않을 범위를 씁니다. 세부 구현을 모두 정할 필요는 없지만, 사용자가 확인할 수 있는 결과와 제약은 분명해야 합니다.
기능 목록만 나열하지 말고 순서와 통과 조건을 함께 적습니다. 예를 들어 기본 화면을 만든 뒤 입력·저장이 연결되는지 확인하고, 다음으로 내보내기 기능과 오류 처리를 추가할 수 있습니다. 첫 단계가 끝났다는 판단이 가능해야 뒤 단계의 변경도 추적하기 쉬워집니다.
3. 3단계: 실행 안내에 작업 방식 쓰기
OpenAI 사례는 계획 문서와 별도의 실행 안내를 사용했습니다. 여기에는 어떤 디렉터리를 먼저 살펴볼지, 기존 구조를 유지할지, 중요한 변경 뒤 무엇을 확인할지 적을 수 있습니다. 실행 안내는 명세를 복사하는 곳이 아니라 작업 순서와 판단 방법을 정리하는 자리입니다.
내 경우 판단 순서
- 완료 결과와 제외할 범위를 적습니다.
- 첫 마일스톤의 확인 가능한 종료 조건을 둡니다.
- 검증 결과와 다음 행동을 기록하고 진행합니다.
4. 4단계: 자동 검증을 반복하기
테스트, 린트, 형식 검사, 빌드를 단계별로 실행하면 마지막에 오류가 몰리는 일을 줄일 수 있습니다. 실패하면 오류 원인과 수정 내용을 기록하고, 수정 뒤 같은 검사를 다시 수행합니다. 테스트가 없는 부분은 수동 확인 방법과 남은 위험을 기록해 완료 표시만으로 검증을 대신하지 않도록 합니다.
현재 완료된 항목, 막힌 지점, 다음 행동, 중요한 가정을 짧게 남기면 세션이 중단되거나 다른 사람이 이어 받아도 흐름을 복구할 수 있습니다. 기록은 길게 늘일 필요가 없습니다. 명세에서 달라진 결정이 있으면 이유와 영향을 함께 기록하는 것이 핵심입니다.
Codex 장기 작업 계획은 한 번 써두고 그대로 믿는 계약서가 아니라, 실제 진행에 따라 갱신되는 안내입니다. 요구사항이 바뀌면 명세와 완료 조건을 같이 고치고, 이미 통과한 검증을 다시 실행할지 판단하세요. 다음 담당자가 기록만 읽고 현재 상태와 남은 위험을 알 수 있는지 확인하는 것도 유용합니다. 그 정보가 없다면 작업을 더 오래 실행하기 전에 상태 기록을 보완하는 편이 재개와 검토를 쉽게 만듭니다.
마일스톤이 지나치게 커서 며칠간 확인이 없다면 더 작게 나누는 편이 좋습니다. 반대로 자잘한 항목이 많아 진행 기록만 늘어난다면, 함께 검증할 수 있는 결과를 묶어 관리하세요. 계획의 단위는 작업을 통제하기 위한 형식이 아니라 실제로 결과와 위험을 확인할 수 있는 크기여야 합니다.
5. 25시간 사례를 읽을 때 주의할 점
OpenAI 글에서 소개한 약 25시간 실행은 빈 저장소에서 디자인 도구를 만드는 실험 사례입니다. 글은 GPT-5.3-Codex가 약 13M 토큰을 사용하고 약 3만 줄을 생성했다고 설명하지만, 이는 특정 조건의 시연 결과입니다. 모든 작업에서 같은 시간이나 품질을 재현한다는 보증으로 읽을 수 없습니다.
작업을 넘기기 전 명세 파일이 있는지, 첫 마일스톤에 관찰 가능한 완료 조건이 있는지, 검증 명령을 실행할 수 있는지 확인하세요. 외부로 영향을 보내거나 되돌리기 어려운 단계가 있다면 사람의 승인을 둘 위치도 정합니다. 장기 작업의 자율성은 결과를 들여다보지 않는다는 뜻이 아니라, 사람이 정기적으로 확인할 지점을 미리 설계한다는 뜻입니다.
✅ 결론
큰 작업은 “끝까지 알아서”라는 지시보다 사람이 확인할 수 있는 단계와 결과 기준이 있을 때 관리하기 쉽습니다. 먼저 작은 마일스톤 하나를 정의하고, 실행·검증·기록이 실제로 이어지는지 확인한 뒤 자율 범위를 넓히세요.
자료 출처 OpenAI Developers, 「Run long horizon tasks with Codex」(2026년 2월 23일) 확인 기준. 기능과 안내는 변경될 수 있습니다.
FAQ — 자주 묻는 질문
Q1. Codex에 장기 작업을 맡기면 25시간 연속 실행할 수 있나요?
그 사례는 OpenAI가 공개한 한 차례의 실험입니다. 환경, 모델, 작업, 사용 한도에 따라 달라질 수 있으므로 일반적인 실행 시간으로 약속하지 않습니다.
Q2. 계획 문서는 얼마나 자세해야 하나요?
단계별 산출물과 완료 조건을 검증할 수 있을 정도면 충분합니다. 구현 세부사항을 모두 미리 정하기보다, 방향을 바꾸어야 할 때 비교할 기준과 제약을 분명히 남기세요.
Q3. 검증은 마지막에 한 번만 해도 되나요?
긴 작업에서는 단계마다 가능한 검사를 반복하는 편이 오류를 일찍 찾고 수정 범위를 줄이는 데 유리합니다. 작업 특성에 따라 테스트·린트·빌드·수동 확인을 조합하세요.
※ 이 글은 2026년 9월 29일 기준 OpenAI 공식 안내를 바탕으로 작성한 정보성 해설입니다. 제품 기능과 운영 방식은 바뀔 수 있으며, 실제 저장소 적용과 코드 변경 결과는 프로젝트 환경에서 별도로 검토해야 합니다.
