BLUF — 장점은 있지만 이전 평가보다 좁다. 관찰성을 보존할 때만 전환 권장
report_worker submit/status/followup, watchdog, 자동 재기동·복구와 함께 cx_report_job.bat <job_id> 같은 “필요할 때 Codex 창 붙이기”를 제공한다. 현재의 저장 thread·resume·세션 분리 능력은 그대로 유지해야 한다.Exhibit 1. 차별점 재평가 — 문맥·재개·충돌은 우열이 아니라 공통 조건
| 평가축 | 현재 rN↔rxN 고정 페어 | 단순 동기식 BAT | 권장 비동기 job worker |
|---|---|---|---|
| 사용자 창 | Claude 8 + Codex 8 | Claude만 | Claude만 상시 표시 |
| Codex 직접 관찰 | 각 rx 창을 바로 봄 | 최종 결과 전까지 안 보임 | 상태 stream + 필요시 TUI attach로 보완 |
| Claude가 작업 중 다른 명령 처리 | foreground relay가 끝날 때까지 현재 turn 점유 | 동기 BAT면 동일 | submit 직후 job ID를 받고 다시 응답 |
| 문맥 분리 | r1↔rx1, r2↔rx2가 별도라 서로 섞이지 않음 | 호출별 새 문맥 | job별 저장 thread |
| 후속 수정·재개 | 지금도 기존 rx를 resume | ephemeral이면 약함 | 기존 job thread resume |
| 토큰 | 문제 아님 | 문제 아님 | 설계 판단 기준에서 제외 |
| app-server 장애 복구 | 현재 운영에도 필요 | 보통 없음 | watchdog·재기동·job 복구를 구현 조건으로 둠 |
| Hub index 동시 쓰기 | 현재도 동일 위험 | 동일 위험 | 단일 registrar 또는 lock으로 기존 위험까지 해결 |
교정: 고정 rx가 서로 섞인다는 이전 주장은 철회한다. 현재도 세션 재개가 되며, rate limit과 동일 파일 동시 수정도 새 구조만의 단점이 아니다. 새 구조의 순증 가치는 창 관리 감소, Claude 비동기 응답, 중앙 watchdog·복구 자동화다.
Exhibit 2. 권장 구조 — Claude는 접수·상태·결과, Codex는 보고서 job
작업 scope와 승인조건 전달
job 상태와 최종 결과 표시
submit → job ID 즉시 반환status/watch → 진행 확인followup → 같은 thread 재개thread/start조사·HTML·Hub 등록 수행
완료 후 thread ID와 결과 저장
작업 원장
각 job은 최소한 job_id, caller_claude_session, thread_id, objective, status, progress, report_path, hub_registered, started_at, updated_at, error, approval_pending을 기록한다. Claude 번호와 Codex 번호를 1:1로 고정하지 않는다. 한 Claude 세션이 여러 job을 만들 수 있고, 다른 Claude 세션도 job ID를 받아 상태를 조회할 수 있다.
Vendor 라우터 위치
보고서 Codex worker가 조사 과정에서 공용 도구가 필요할 때 ask_vendor를 호출한다. 접수 Claude가 먼저 vendor를 고르고 다시 Codex에 넘기지 않는다. 도구 선택과 실무 맥락이 같은 worker 안에 있어야 중복 호출과 정보 손실이 적다.
Exhibit 3. 실제 순증 단점과 필수 보완
cx_report_job.bat <job_id> TUI attach를 모두 제공해야 한다.새 구조의 단점이 아닌 것
- 장시간 무응답: 현재 foreground relay에도 이미 존재한다. 새 구조가 동기 BAT면 그대로이고, 비동기 submit이면 오히려 해결된다.
- rate limit·동시작업: 현재 8개 rx도 공유하는 위험이다. 새 구조만의 불이익이 아니다.
- 파일 충돌: 각 보고서는 고유 HTML을 쓰므로 보통 충돌하지 않는다. 모든 보고서가 Hub 카드 등록을 위해 같은
reports-hub/index.html을 수정할 때만 겹친다. 현재도 같은 위험이며 단일 registrar로 개선할 수 있다. - 문맥 오염·후속 재개: 현재 고정 rx도 이미 분리·resume되므로 새 구조의 우위가 아니다.
전환 권고 — 관찰성까지 갖춘 10-job 파일럿
- 기존 페어 보존: 파일럿 동안 r1~r8/rx1~rx8을 삭제하지 않는다.
- 비동기 진입점:
submit은 즉시 job ID를 반환하고 Claude를 다시 사용할 수 있게 한다. - 가시성 동등화: status stream, 원문 event log,
cx_report_job.bat <job_id>를 구현해 사용자가 언제든 해당 Codex 창에 붙을 수 있게 한다. - 자동 복구: watchdog이 app-server health/PID를 확인하고 재기동한 뒤 미완료 job의 저장 thread를 resume한다.
- 공유 파일 직렬화: 보고서 HTML은 각 job이 쓰고, Hub index 카드 등록만 단일 registrar가 처리한다.
- 합격선: Claude가 submit 후 즉시 사용 가능, 직접 관찰 접근 100%, app-server 강제 종료 후 job 복구 100%, 결과·Hub 카드 유실 0, 후속 수정 재개 100%.
최종 판정: 조건부 권장 이제 남는 장점은 “창 8개 제거”와 “Claude를 작업 중에도 계속 사용”, “복구 자동화”다. 문맥 분리·resume·토큰·동시성은 전환 근거에서 제외한다. on-demand Codex TUI attach가 빠지면 관찰성 손실이 커서 전환하지 않는 편이 낫다.
근거와 한계
- 로컬
reports/CLAUDE.md: r1~r8 일반 메시지의 rx1~rx8 원문 릴레이와 고정 thread 매핑. - 로컬
reports/codex-relay/MULTI-SESSION-HANDOFF.md: 공유 app-server, active-writer 충돌, rx 번호 추가·운영 부담. - 로컬
reports/codex-relay/relay.mjs: thread resume, turn start, incremental event, 승인 처리, timeout·retry. - 로컬
vendor/ask_vendor.ps1: ephemeral read-only 실행과 final-only 반환. 짧은 도구 선택에는 적합하지만 장기 쓰기 job과 요구가 다름. - OpenAI 공식 문서 — Codex App Server:
thread/start,thread/resume,thread/read,turn/start, 진행 이벤트와 완료 상태.
미확인 10-job 실측 전에는 토큰 절감, 평균 완료시간, 동시 worker 적정 수를 수치로 보장할 수 없다. 이 보고서는 로컬 아키텍처 감사와 공식 인터페이스 비교에 근거한 설계 판정이며, 실제 worker 구현·부하시험은 수행하지 않았다.
범위: Windows의 reports 프로젝트와 현재 Claude/Codex 로컬 세션 구조. 배포·외부 메시지·보고서 콘텐츠 품질 자체는 비교 범위에서 제외했다. 커버리지: 현재 구현과 직접 관련된 경로를 검토한 구조 분석이며 자동화 프레임워크 전수조사가 아니다.