Codex 오케스트레이션의 실제 메타는 무엇인가요? (Claude는 너무 쉬워 보이네요)

Claude Code가 오케스트레이션을 처리하는 방식이 마음에 든다면 우회 방법이 있습니다. CLIProxyAPI를 Claude 및 Codex 인증과 함께 설정하고, Claude Code를 여기에 연결한 다음, 환경 변수를 설정하는 claudex 별칭을 만드세요. 기본적으로 Claude Code의 하네스를 GPT 모델과 함께 사용할 수 있습니다.

Claude Code 세션 ID에서 안정적인 prompt_cache_key를 도출하니까, 같은 세션 내의 요청들은 여전히 OpenAI 캐싱을 적용받을 수 있을 거야. tmux 자체가 캐시를 깨뜨리는 원인은 아닐 거다.

저는 멀티 에이전트 Codex 설정이 서로 꼬이지 않게 하려고 몇 주 동안 이 짓을 해봤습니다. Symphony 문서는 플러그 앤 플레이처럼 보이지만 실제로는 그렇지 않습니다. 특히 OpenAI 모델이 아닌 에이전트들을 체인으로 연결해야 하고 컨텍스트 윈도우가 커지기 시작하면 더더욱 그렇습니다. 결국 저에게 효과가 있었던 건 FastAPI 레이어와 Redis 큐를 얇게 깔고 각 Codex 인스턴스를 별도의 워커로 실행하는 것이었습니다. 투박하긴 하지만 무거운 프레임워크들처럼 작업을 중간에 날려먹지는 않더군요.

Codex 오케스트레이션이 더 어려운 건 놀랄 일도 아님. 실행 환경이 그냥 텍스트 반환하는 API 호출이 아니라 실제 제약이 있는 샌드박스 VM이니까. Claude가 쉽게 느껴지는 건 부분적으로는 주변 MCP 생태계가 더 성숙하고 모델 자체가 툴 콜 패턴을 안정적으로 따르도록 튜닝됐기 때문임. 내가 겪어본 바로는 오케스트레이션 레이어보다 검증 레이어가 훨씬 중요함. 에이전트가 자기가 뭘 했는지 확인을 못 하면, 그 위에 조정을 더 얹어봤자 불확실성만 커질 뿐임.

내가 정착한 실전 메타는 '에이전트 늘리기'가 아님. 확실한 소유권 경계가 있는 작은 상태 머신임:

1. 한 작업당 한 명의 리스 홀더 지정.
2. 모든 워커는 격리된 워크트리나 브랜치, 그리고 제한된 툴 스코프를 가짐.
3. 작업 전달은 공유된 채팅 기록이 아니라 diff, 테스트, 로그, 영수증 같은 아티팩트를 통해 이루어짐.
4. 오케스트레이터는 작업을 명시적인 상태에 따라 이동시킴: 대기 중 -> 리스됨 -> 실행 중 -> 증거 제출됨 -> 검증됨 -> 병합됨 또는 실패.
5. 별도의 검증자...