Codex는 장시간 작업을 수행할 수 있으며, 특히 /goal이 지속적인 목표를 부여할 때 더욱 그렇습니다. 더 어려운 부분은 Codex가 몇 시간 또는 며칠 동안 작업하고, 새로운 구현 세부 사항을 발견하며, 여러 종류의 검증을 거치는 동안 방향성을 유지하는 것입니다.
초기 가정은 구현이 시작되면 종종 변경됩니다. 협업 모델은 목표를 유지하면서도 새로운 증거가 나타남에 따라 당신과 Codex 모두 계획을 수정할 수 있는 여지를 남겨야 합니다.
지난 몇 주 동안 저는 다섯 가지 방법을 사용해 왔습니다:
- Codex가 작업을 계획하고 로드맵을 유지하도록 합니다.
- 메인 스레드를 조정에 집중하도록 유지합니다.
- 각 마일스톤 이후 로드맵을 감사하고 코드를 검토합니다.
- Computer Use 테스트를 위해 로컬 스레드를 사용합니다.
- 간결한 업데이트와 대시보드를 통해 진행 상황을 보고합니다.
Codex에서 GPT Image 2로 생성됨
1. Codex가 작업을 계획하고 로드맵을 유지하도록 합니다
저는 보통 /plan 모드보다는 대화로 시작합니다. 제가 구축하려는 것을 설명하고, 대략적인 생각을 말하며, 제약 조건을 공유하고, Codex가 초기 계획을 제안할 수 있을 만큼 충분한 컨텍스트를 얻을 때까지 질문하도록 합니다.
이렇게 하면 초기 논의가 유연해집니다. Codex가 도움을 주기 시작하기 전에 반쯤 구체화된 아이디어를 공식적인 명세로 바꿀 필요가 없습니다. Codex는 저에게 질문하고, 이해한 내용을 다시 반영하며, 격차를 식별하고, 점진적으로 대화를 실행 가능한 계획으로 전환할 수 있습니다.
프로젝트가 구체화되면, Codex에게 현재 Goal을 설정하도록 요청합니다. Goal 모드는 Codex에 지속적인 목표를 부여하여, 목표가 완료되거나, 차단되거나, 대체될 때까지 여러 턴에 걸쳐 동일한 결과를 향해 계속 작업할 수 있게 합니다.
/goal을 사용하여 직접 목표를 설정할 수도 있지만, 보통은 Codex에게 요청합니다. Goal 모드는 harness를 통해 노출되므로, Codex는 우리의 대화, 프로젝트 컨텍스트, 그리고 지금까지 학습한 모든 것을 종합하여 명확한 목표를 만들 수 있습니다. 또한 해당 목표가 완료된 것으로 간주되기 전에 필요한 증거를 정의할 수도 있습니다.
더 큰 프로젝트의 경우, Codex에게 더 넓은 로드맵을 GOALS.md에 작성하도록 요청합니다. 이것은 내장된 Codex 기능이 아닌 프로젝트 규칙이며, 파일 이름은 원하는 대로 지정할 수 있습니다.
저는 보통 GOALS.md를 평평한 작업 목록 대신 마일스톤을 기준으로 구성합니다. 각 마일스톤은 다음을 기록합니다:
- 의도된 결과
- 현재 범위 내의 작업
- 중요한 결정
- 알려진 차단 요소
- 다음 단계로 넘어가기 전에 필요한 증거
Codex는 프로젝트가 진행됨에 따라 파일을 유지 관리합니다. 새로운 발견으로 인해 마일스톤의 범위가 변경되거나, 새로운 마일스톤이 도입되거나, 완료에 필요한 증거가 변경될 수 있습니다.
한 번에 하나의 Goal 모드 목표만 활성화됩니다. 마일스톤이 완료되면 Codex는 GOALS.md를 업데이트하고, 다음 목표를 활성화하며, 계속해서 작업을 진행합니다.
2. 메인 스레드를 조정에 집중하도록 유지합니다
로드맵이 생성되면, 메인 스레드를 목표, 제약 조건, 결정 및 현재 프로젝트 상태에 집중하도록 유지합니다.
메인 스레드는 다음에 무엇이 일어나야 하는지 결정하고, 경계가 있는 작업을 위임하며, 결과를 평가합니다. 모든 구현 세부 사항을 기억할 필요는 없습니다.
작업자는 낯선 코드를 읽거나, 여러 접근 방식을 시도하거나, 실패하는 테스트를 추적하는 데 한 시간을 보낼 수 있습니다. 조정자는 더 넓은 프로젝트에 영향을 미치는 정보만 필요합니다:
- 작업자가 배운 것
- 변경된 사항
- 뒷받침하는 증거
- 다음에 일어나야 할 일
Codex는 이 작업을 subagent에게 위임하거나 별도의 스레드를 생성할 수 있습니다. 기능적으로는 동일한 작업을 수행할 수 있습니다. 나중에 작업을 다시 검토할 것으로 예상될 때는 별도의 스레드를 사용합니다. 별도 스레드는 Codex 앱에 계속 표시되고 자체 기록을 유지하기 때문입니다.
이는 여러 작업이 병렬로 실행될 때 특히 유용해집니다. 각 조사, 구현 또는 검토를 쉽게 검사할 수 있는 동안 메인 스레드는 계속해서 프로젝트를 조정할 수 있습니다.
3. 각 마일스톤 이후 로드맵을 감사하고 코드를 검토합니다
GOALS.md는 Codex가 마지막으로 업데이트했을 때 알려진 정보를 반영합니다. 마일스톤이 끝날 무렵이면 프로젝트는 일반적으로 새로운 것을 발견합니다.
다음 단계로 넘어가기 전에, 다른 스레드에게 로드맵을 현재 상태와 비교하도록 요청합니다:
- 마일스톤이 실제로 완료되었는가?
- 다음 목표가 여전히 올바른 목표인가?
- 누락된 마일스톤이 있는가?
- 새로운 증거가 작업 순서를 변경했는가?
- 완료 정의가 여전히 유효한가?
저는 각 마일스톤이 끝날 때마다, 그리고 새로운 증거가 프로젝트 방향을 실질적으로 변경할 때마다 이 감사를 실행합니다.
또한 구현에 대해 /review를 실행합니다.
로그인 흐름에 대한 구현과 원격 테스트가 완료되었다고 가정해 보겠습니다. 로드맵 감사에서는 실제 로그인된 브라우저에서 흐름을 테스트한 사람이 없다는 것을 알 수 있습니다. 동시에 /review에서는 원격 테스트가 통과했음에도 불구하고 새로운 경로가 토큰을 잘못 저장한다는 것을 발견할 수 있습니다.
조정자는 GOALS.md를 업데이트하고, 토큰 수정을 위임하며, 누락된 브라우저 검증을 추가하고, 그런 다음에야 다음 마일스톤을 활성화합니다.
저는 보통 감사와 검토를 별도의 스레드로 유지합니다. subagent가 동일한 작업을 수행할 수 있지만, 별도 스레드는 나중에 다시 참조할 수 있는 가시적인 기록을 남깁니다.
4. Computer Use 테스트를 위해 로컬 스레드를 사용합니다
제 Codex 세션의 대부분은 원격 인스턴스에서 실행되므로, 노트북을 닫아도 작업을 계속할 수 있습니다. 일부 검사는 여전히 로컬 머신에 의존합니다:
- 로그인된 브라우저
- 로컬 자격 증명
- Xcode
- macOS 권한
- iOS 시뮬레이터
원격 조정자는 이러한 검사 중 하나를 위해 로컬 스레드를 생성할 수 있습니다. 올바른 코드를 테스트하기 위해 원격 diff를 적용하거나 관련 브랜치 또는 커밋을 체크아웃합니다.
로컬 스레드는 브라우저나 애플리케이션을 작동시키고 스크린샷, 로그 및 결과를 반환합니다. 검사가 실패하면 원격 작업자가 문제를 수정하고 로컬 스레드가 다시 테스트합니다.
일반적인 루프는 다음과 같습니다:
- 원격 작업자가 로그인 흐름을 구현합니다.
- 원격 테스트가 통과합니다.
- 로컬 스레드가 Codex Chrome 확장 프로그램을 사용합니다.
- 브라우저 테스트에서 리디렉션 버그가 발견됩니다.
- 원격 작업자가 이를 수정합니다.
- 로컬 스레드가 검사를 반복합니다.
프로젝트는 기본적으로 원격 상태를 유지합니다. 제 컴퓨터는 필요한 검사에만 참여합니다. 원격 스레드는 제가 노트북을 다시 열면 로컬 스레드를 다시 사용할 수 있는지 계속 확인할 수도 있습니다.
5. 간결한 업데이트와 대시보드를 통해 진행 상황을 보고합니다
작업자 스레드는 일반적으로 하나의 작업에 대해 보고합니다. 프로젝트로 돌아가면 전체 상태에 대한 개요가 필요합니다:
- 완료된 것
- 변경된 사항
- 남은 작업
- 결정이 필요한 사항
프로젝트 상태가 변경될 때마다 Codex에게 세 가지 짧은 섹션을 사용하여 보고하도록 요청합니다:
**완료된 작업
다음 작업
차단 요소**
이는 거의 Codex와 매일 스탠드업 미팅을 하는 것과 같지만, 시간 단위로 이루어집니다.
Codex는 동일한 업데이트를 Slack을 통해 직접 메시지나 전용 프로젝트 채널로 보낼 수 있습니다.
Codex 앱에 있는 동안에는 /side를 사용하여 메인 스레드를 방해하지 않고 상태를 확인합니다. 사이드 스레드에서 완료된 작업, 남은 작업, 그리고 수동 클릭, 승인 또는 다른 clickops 작업과 같이 제 도움이 필요한 사항이 있는지 요약을 요청할 수 있습니다.
사이드 스레드에서 요약 받기
사이드 스레드에 제 지침을 메인 스레드로 전달하도록 요청하기
그런 다음 지침을 명확히 하거나, 차단 요소를 해결하거나, 컨텍스트를 추가하거나, 사이드 스레드에게 업데이트된 지침을 메인 스레드로 다시 보내도록 요청할 수 있습니다.
여러 마일스톤이나 병렬 작업 스트림이 있는 프로젝트의 경우, progress-dashboard.html도 유지 관리합니다. 이것은 내장된 Codex UI가 아닌 사용자 정의 프로젝트 아티팩트입니다. 다음을 표시할 수 있습니다:
- 활성 목표
- 완료된 마일스톤
- 증거
- 차단 요소
- 결정
- 최근 업데이트
몇 시간 후에 돌아오면 모든 작업자 스레드를 읽지 않고도 프로젝트 상태를 이해할 수 있습니다. Codex는 대시보드를 Site로 배포하여 원격으로 액세스할 수 있도록 할 수도 있습니다.
요약
저는 프로젝트가 새로운 정보를 발견할 가능성이 있거나, 여러 독립적인 작업을 포함하거나, 둘 이상의 환경에서 증거가 필요할 때 이 구조를 사용합니다.
워크플로는 간단한 주기를 따릅니다. Codex는 초기 대화를 로드맵으로 전환하고, 하나의 마일스톤을 활성화하고, 작업을 위임하고, 결과를 확인한 후 다음 단계로 넘어갑니다. 로컬 스레드는 제 머신이 필요한 검사를 처리하고, 업데이트와 대시보드는 모든 것을 처음부터 재구성하지 않고도 프로젝트로 돌아갈 수 있도록 도와줍니다.
중요한 것은 프로젝트 상태를 충분히 최신 상태로 유지하여 다음 결정이 Codex가 실제로 학습한 내용을 반영하도록 하는 것입니다.
시도해 보기
이 내용을 새 Codex 스레드에 붙여넣으세요:
이것을 장기 실행 프로젝트로 조정하세요.
먼저 제가 구축하려는 것에 대해 인터뷰하는 것으로 시작하세요. 대화식으로 대략적인 아이디어와 제약 조건을 설명하게 한 다음, 그 논의를 초기 계획으로 전환하세요.
공유 로드맵으로 GOALS.md를 생성하세요. 의도된 결과, 범위, 결정, 차단 요소 및 각각에 필요한 증거와 함께 마일스톤을 기준으로 구성하세요.
한 번에 하나의 Goal 모드 목표를 설정하고 유지하세요. 활성 목표는 현재 마일스톤에 해당해야 합니다.
이 스레드를 목표, 제약 조건, 결정 및 프로젝트 상태에 집중하도록 유지하세요. 구현은 subagent 또는 새 스레드에 위임하세요.
작업자는 전체 대화 내용이 아닌 결론, 변경 사항 및 증거를 반환해야 합니다.
나중에 작업을 검사, 계속 또는 검토하고 싶을 수 있는 경우 별도의 스레드를 사용하세요. 자체 가시적인 기록이 필요하지 않은 경계가 있는 작업에는 subagent를 사용하세요.
각 마일스톤 후에는 별도의 스레드를 사용하여 GOALS.md를 현재 상태와 감사하고 구현에 대해 /review를 실행하세요. 다음 목표를 활성화하기 전에 로드맵을 업데이트하세요.
브라우저, 데스크톱 애플리케이션, 권한, 자격 증명 또는 장치 상태에 의존하는 Computer Use 테스트에는 로컬 스레드를 사용하세요.
*프로젝트 상태가 변경되면 다음만 보고하세요: - 완료된 작업 - 다음 작업 - 차단 요소*
프로젝트가 여러 마일스톤 또는 작업자에 걸쳐 있는 경우 progress-dashboard.html을 유지 관리하세요. 합의된 증거가 존재할 때까지 완료를 선언하지 마세요.
또는 이 문서의 Appshot을 가져와 Codex에게 요청할 수도 있습니다:
이 문서에서 orchestrate-projects라는 재사용 가능한 Codex 스킬을 생성하세요.
다음 방법을 유지하세요:
*- Codex가 저를 인터뷰하고 초기 계획을 생성하도록 함 - GOALS.md를 마일스톤 기반 로드맵으로 사용 - 한 번에 하나의 Goal 모드 목표를 활성 상태로 유지 - 메인 스레드를 조정에 집중하도록 유지 - 각 마일스톤 후 로드맵을 감사하고 /review 실행 - 다시 검토하고 싶은 작업에는 별도의 스레드 사용 - Computer Use 테스트에는 로컬 스레드 사용 - 간결한 업데이트, Slack 및 progress-dashboard.html을 통해 진행 상황 보고*
