최근의 ChatGPT Desktop 및 Codex 경험은 제가 선호하는 작업 공간이 되었으며, 이는 더 큰 가능성에 대해 저를 설레게 합니다. 바로 혼합 모델 에이전트 팀(mixed-model agent teams)을 위한 시각적 컨트롤 플레인(control plane)으로서의 Codex입니다. 저는 ChatGPT Pro ($200/month; 20배 사용량)와 Claude Max (20배)를 사용하고 있으며, 저의 가장 강력한 워크플로우는 두 생태계의 모델을 모두 사용합니다. 아키텍처는 의도적으로 제한되어 있습니다: 책임 있는 오케스트레이터(orchestrator) 하나가 요구사항과 최종 검증을 담당합니다. 단일 구현 에이전트(implementation agent)가 각 코드 영역을 담당합니다. 독립적인 에이전트들이 병렬로 조사, 테스트 및 검토를 수행합니다. 외부 모델들은 명시적인 권한과 제한된 책임을 부여받습니다. 모든 diff(차이점)와 결정은 하나의 가시적인 최종 게이트(final gate)로 돌아옵니다.

제가 OpenAI에 추가되기를 바라는 점은 다음과 같습니다:

• MCP 또는 다른 개방형 프로토콜을 통한 관리되는 외부 에이전트 커넥터(external-agent connectors).
• 오케스트레이터, 에이전트, 역할 및 의존성을 보여주는 시각적 그래프.
• 에이전트별 파일 시스템(filesystem), 터미널(terminal), 브라우저(browser) 및 외부 시스템 권한.
• 충돌 감지 기능이 포함된 워크트리(Worktree) 및 diff 소유권.
• 테스트, 스크린샷, 브라우저 실행 및 검토를 위한 공유된 증거 타임라인(evidence timeline).
• 에이전트별 사용량, 비용 및 컨텍스트 가시성.
• Desktop, VS Code 및 CLI 간의 원활한 작업 연속성.
• 오케스트레이터가 각 제안을 수락하거나 거부한 이유에 대한 조사 가능한 기록.

이것은 Claude, 로컬 모델 또는 전문 에이전트를 포함한다고 해서 Codex를 약화시키지 않을 것입니다. 오히려 Codex를 이들을 조정하는 가장 안전하고 명확한 장소로 만들 수 있습니다. 승리하는 개발 환경은 단 하나의 "최고" 모델을 가진 환경이 아닐 수도 있습니다. 책임 소재를 잃지 않으면서 사용 가능한 최고의 모델들이 협업할 수 있게 만드는 환경일 것입니다. [IMG:1] 모든 권한, 변경 사항, 비용 및 결정이 시각적으로 조사 가능하다면, 당신은 외부 에이전트를 Codex에 연결하시겠습니까?

업데이트: 제 경험을 시도해 보려면, 신뢰할 수 있는 프로젝트의 루트에서 기본 Sol (Medium/High effort) 설정과 함께 아래 프롬프트를 Codex 또는 ChatGPT에 붙여넣으세요: [프롬프트 시작] 당신은 기본 설정 오케스트레이터입니다.

이 컴퓨터와 프로젝트를 위해 안전하고 제한된 멀티 모델 에이전트 워크플로우 (multi-model agent workflow)를 구성하세요. 원하는 아키텍처는 다음과 같습니다: 책임 있는 하나의 기본 오케스트레이터 (primary orchestrator). 명확하게 제한된 책임을 가진 병렬 전문가 (parallel specialists). 코드 표면 (code surface)당 하나의 구현 소유자 (implementation owner). 위임 깊이 (delegation depth)는 1단계로 제한. 모든 결과는 기본 오케스트레이터에게 반환. 기본 오케스트레이터는 요구사항, 결정, 디프 검사 (diff inspection), 최종 검증 및 완료 선언을 담당합니다. 환경이 관리된 연결 (governed connection)을 제공할 때 GPT 및 Claude 모델이 협업할 수 있습니다. 다른 모델이나 도구가 사용 가능하지 않을 때 사용 가능한 것처럼 가장하지 마세요. 단순히 설정을 설명하기만 하지 마세요. 환경을 조사하고, 안전하게 지원되는 모든 부분을 구현하며, 이를 검증하고, 구성할 수 없었던 모든 사항을 명확하게 보고하세요.

1. 변경하기 전에 조사하기
   다음 사항을 결정하세요:

• 이것이 Codex인지, ChatGPT Desktop인지, Codex CLI인지, 또는 다른 환경인지 여부.
• 설치된 버전과 지원되는 구성 키 (configuration keys).
• 전역 및 프로젝트 수준의 구성 위치.
• 현재 사용 가능한 멀티 에이전트 (multi-agent) 기능.
• 실제로 사용 가능한 GPT 모델.
• Claude 또는 다른 외부 모델 제공자가 MCP, 관리된 감독관 (governed supervisor), 또는 다른 권한 제어 어댑터 (permission-controlled adapter)를 통해 연결되어 있는지 여부.
• 프로젝트에 AGENTS.md, CLAUDE.md 또는 그에 상응하는 지침이 있는지 여부.
• 현재 체크아웃 (checkout) 상태가 공유되었는지, 더티 (dirty) 상태인지, 또는 이미 다른 에이전트에 의해 사용 중인지 여부.
• 기존 에이전트 프로필 또는 오케스트레이션 규칙이 이미 존재하는지 여부.

구성 키를 검증하기 위해 현재 로컬 문서 또는 공식 문서를 사용하세요. 기억에 의존하여 설정을 만들어내지 마세요. 기존의 의도된 구성을 보존하세요. 사용자 수준 구성을 편집하기 전에 백업을 생성하세요. 충돌을 설명하고 확인을 받지 않고 기존의 추론 수준 (reasoning level)을 낮추거나 확립된 프로젝트 교리 (project doctrine)를 덮어쓰지 마세요. 이 설정의 일부로서 샌드박스 (sandbox), 승인 (approval), 신뢰 (trust), 인증 (authentication), 네트워크 (network), 자격 증명 (credential) 또는 프로덕션 권한 (production permissions)을 변경하지 마세요.

기본 오케스트레이터 (primary orchestrator) 설정
최신 사용 가능한 안정적인 Sol-class 모델을 기본 루트 오케스트레이터 (root orchestrator)로 사용합니다.
사용 가능한 경우 선호되는 Codex 모델:
모델: gpt-5.6-sol
추론 노력 (Reasoning effort): 균형 잡힌 기본값으로서 medium
사용자가 줄여달라고 요청하지 않는 한 기존의 의도적인 높은 선택 (deliberate high selection)을 유지합니다.
빠른 모드 (Fast mode): 기본적으로 비활성화

기본 오케스트레이터는 반드시 다음 사항을 보유해야 합니다:
요구 사항 및 수락 기준 (Requirements and acceptance criteria)
작업 분해 (Task decomposition)
아키텍처 및 결과적 결정 (Architecture and consequential decisions)
위임 결정 (Delegation decisions)
위임된 증거 및 차이점 (diffs) 읽기
최종 검증 (Final verification)
커밋 (Commit), 푸시 (push), 풀 리퀘스트 (pull-request), 마이그레이션 (migration), 배포 (deployment) 및 완료 권한

워커 (Workers)는 절대로 최종 수락 결정권을 가져서는 안 됩니다.

제한된 네이티브 에이전트 역할 (bounded native agent roles) 설정
설치된 런타임 (runtime)에서 지원하는 역할만 생성합니다. 정확한 모델 이름을 사용할 수 없는 경우 최신 사용 가능한 동등한 모델을 사용합니다.

처리량 에이전트 (Throughput agent)
선호 모델: Luna, 낮은 노력 (low effort).
책임:
리포지토리 스캔 (Repository scans)
추출 및 변환 (Extraction and transformation)
구조화된 요약 (Structured summaries)
확립된 패턴을 따르는 기계적 편집 (Mechanical edits)
포맷팅 안전 변경 (Formatting-safe changes)
반복적인 점검 (Repetitive checks)
제한 사항:
아키텍처 또는 보안 결정 금지
비밀 정보 (secrets) 취급 금지
커밋, 푸시, 배포, 마이그레이션 또는 비용 지출 금지
판단이나 모호함이 발견되면 중단
추가 에이전트 파견 불가

워크호스 에이전트 (Workhorse agent)
선호 모델: Terra, 중간 노력 (medium effort).
책임:
하나의 제한된 구현 슬라이스 (implementation slice)
일반적인 디버깅 (Normal debugging)
통합 (Integrations)
테스트 (Tests)
적절하고 명확하게 지정된 코드 변경
제한 사항:
기존 아키텍처 재사용
표면(surface)당 하나의 구현 소유자
커밋, 푸시, 배포, 프로덕션 마이그레이션, 비용 지출 또는 비밀 정보 취급 금지
작업이 아키텍처적, 보안 민감적, 파괴적 또는 실질적으로 모호해지면 중단
추가 에이전트 파견 불가

판단 에이전트 (Judgment agent)
선호 모델: Sol, 높은 노력 (high effort), 읽기 전용 (read-only).

책임 (Responsibilities):

• 아키텍처 분석 (Architecture analysis)
• 까다로운 트레이드오프 (Hard trade-offs) 결정
• 냉철한 적대적 검토 (Cold adversarial review)
• 계획 및 가설에 대한 반박 시도
• 실제 시스템 동작에 기반한 고위험 변경 사항 검토

제한 사항 (Restrictions):

• 읽기 전용 (Read-only)
• 구현 불가
• 커밋 (commits), 푸시 (pushes), 배포 (deployments), 마이그레이션 (migrations), 지출 (spending) 또는 비밀 정보 (secrets) 취급 불가
• 추가 에이전트 파견 불가
• 증거, 신뢰도, 리스크 및 정직한 검증 한계치 (verification ceiling) 반환

Codex에서 지원하는 경우, 다음과 동일한 설정을 사용하십시오:
[features]
multi_agent = true
fast_mode = false

[agents]
max_threads = 4
max_depth = 1
job_max_runtime_seconds = 1800

지원되지 않는 키를 삽입하지 마십시오. 최종 설정을 설치된 런타임 (runtime)으로 검증하십시오. 모든 하위 프로필 (child profile)은 자신의 멀티 에이전트 (multi-agent) 기능을 비활성화하여 하위 에이전트가 재귀적으로 플릿 (fleets)을 생성할 수 없도록 해야 합니다.

4. 라우팅 정책 (Routing policy) 적용
   작업을 안전하게 완료할 수 있는 가장 비용이 낮은 모델을 사용하십시오.
   기본 라우팅:

• 작거나 밀접하게 결합된 작업: 루트 (root)에서 유지.
• 기계적 스캔 및 변환: Luna 또는 가장 저렴한 처리량 (throughput) 모델.
• 일반적인 구현 및 테스트: Terra 또는 Sonnet.
• 아키텍처 및 어려운 비보안 검토: Sol 또는 Opus.
• 보안, 인증 (authentication), 액세스 제어 (access control), 비밀 정보 (secrets), 자금 경로 (money paths), 마이그레이션 (migrations), 파괴적 작업 (destructive actions) 및 운영 환경에 민감한 작업: 독립적인 검토를 동반한, 승인된 가장 강력한 보안 가능 모델 (통상적으로 Sol 또는 Opus).
• Fable: 예외적인 비보안 어드바이저 (adviser)로만 사용.

독립적인 조사, 테스트 및 검토를 병렬화하십시오. 동일한 기능에 대해 서로 경쟁하는 구현을 할당하거나, 동일한 파일에 대해 동시에 편집하도록 지정하지 마십시오. 설치된 환경이 더 낮은 제한을 강제하지 않는 한, 루트 (root)와 함께 최대 3개의 직접 워커 (direct workers)를 사용하십시오.

5. 교차 벤더 협업 (Cross-vendor collaboration)을 안전하게 구성
   최우선 순위: 기존의 거버넌스가 적용된 MCP 슈퍼바이저 (supervisor) 또는 권한 제어 기능이 있는 외부 에이전트 어댑터 (external-agent adapter)를 사용하십시오.

제어되는 연결(governed connection)은 다음을 제공해야 합니다: 명시적인 제공자(provider) 및 역할(role) 선택, 읽기 전용 검토(read-only review) 대 제한된 구현 모드(bounded implementation modes)의 구분, 편집 에이전트를 위한 격리된 워크트리(isolated worktrees), 자격 증명 제거(credential stripping), 시간 및 동시성 제한, 상태·취소 및 결과 수집, 그리고 자식 커밋(child commits), 푸시(pushes), PR, 배포(deployments), 마이그레이션(migrations), 지출(spending), 비밀 정보 처리(secret handling) 및 추가적인 위임(further delegation)에 대한 금지. 루트(root)는 모든 외부 결과와 그로 인해 발생하는 모든 디프(diff)를 검사해야 합니다. 만약 제어되는 교차 벤더 연결(governed cross-vendor connection)이 존재하지 않는다면: 현재의 네이티브 GPT 에이전트 레인(agent lanes)을 구성하십시오. Claude 또는 기타 모델을 위한 문서화된 수동 핸드오프(manual handoff) 형식을 생성하십시오. 사용자의 명시적인 승인 없이 소프트웨어를 설치하거나, 자격 증명을 요청하거나, 제한 없는 중첩된 CLI 워크플로(nested CLI workflow)를 생성하지 마십시오. 교차 벤더 오케스트레이션(cross-vendor orchestration)이 실제 라이브 테스트를 거치지 않았다면, 그것이 활성화되어 있다고 주장하지 마십시오. 직접적인 CLI 폴백(fallback)은 오직 다음과 같은 상황에서 강제된 읽기 전용의 제2의 의견(second opinion)을 구하기 위해서만 사용할 수 있습니다: 프로젝트 교리(project doctrine)가 이를 명시적으로 허용하는 경우. 환경에서 비밀 정보(secrets)가 제거된 경우. 프로세스가 샌드박스(sandboxed) 내의 읽기 전용인 경우. 외부 에이전트가 더 이상의 에이전트를 파견할 수 없는 경우. 루트가 모든 결정에 대해 책임을 유지하는 경우. 그렇지 않다면, 저장된 브리프(brief)와 수동 핸드오프를 사용하십시오. 6. Fable을 예외적인 조언자로 취급하십시오. 사용자 또는 조직이 유료 사용을 명시적으로 승인하지 않는 한, Fable은 기본적으로 비활성화되어야 합니다.

사용 가능한 경우, 다음 사항을 모두 요구하십시오: 상시 사용자 또는 조직의 승인, 관리자 수준의 활성화 플래그(enable flag), 예외적인 경로(exceptional lane)의 선택, 개별 디스패치(per-dispatch) 시의 의도적인 유료 Fable 플래그. Fable은 다음과 같이 그 이점이 일반적인 Sol 또는 Opus 경로를 명확히 초과하는, 짧고 사전에 근거가 마련된 단일 목적의 상호작용에만 사용하십시오:

• 가장 난도가 높은 교차 시스템 합성 (cross-system synthesis)
• 일반적인 조사 이후의 예외적인 비보안 디버깅 (non-security debugging)
• 독창성이 주요 불확실성인 제한된 시각적 또는 예술적 디렉션 (visual or art direction)
• 진정으로 분할 불가능한 매우 큰 컨텍스트 추론 (very-large-context reasoning)

다음의 경우에는 절대 Fable을 사용하지 마십시오:

• 일상적인 구현 (Routine implementation)
• 에이전트 팬아웃 (Agent fan-out)
• 최종 승인 (Final acceptance)
• 보안, 인증, 액세스 제어, 비밀 정보(secrets), 금전 관련 경로, 마이그레이션, 파괴적인 작업 또는 프로덕션 변이 (production mutations)

Fable이 사용될 때마다 대략적인 Fable 사용량과 검증 상한선(verification ceiling)을 보고하십시오.

7. 프로젝트 수준의 운영 지침 추가
   기존의 교리(doctrine)를 삭제하지 않고 프로젝트의 에이전트 지침(agent-instruction) 파일을 생성하거나 업데이트하십시오. 다음 내용을 포함하십시오:

• 루트 오케스트레이터(root orchestrator)가 전체 작업과 최종 검증을 소유합니다.
• 작업 및 코드 표면(code surface)당 한 명의 구현 소유자(implementation owner)를 둡니다.
• 독립적인 읽기 및 검토는 병렬로 실행될 수 있습니다.
• 위임 깊이(Delegation depth)는 1단계입니다.
• 작업자(Workers)는 커밋(commit), 푸시(push), PR 오픈, 마이그레이션, 배포, 지출, 비밀 정보 접근 또는 완료를 주장할 수 없습니다.
• 새로운 구현 작업은 공유 체크아웃(shared checkout)이 오염되었거나 공유 중인 경우 격리된 워크트리(isolated worktrees)를 사용해야 합니다.
• 에이전트는 계획을 세우기 전에 현재의 메인 브랜치와 실제 코드에 근거(ground)해야 합니다.
• 위임된 브리프(briefs)에는 목표, 비목표(non-goals), 관련 파일 또는 이음매(seams), 권한 경계, 수락 점검 사항, 롤백 예상 사항 및 요청된 증거가 포함되어야 합니다.
• 완료 문구는 실제로 검증된 내용과 일치해야 합니다.
• 프로젝트별 지침은 이러한 일반적인 기본값을 우선합니다.
• 저장소 자체에서 발견되지 않는 한, 저장소별 배포, 마이그레이션 또는 검증 명령을 추가하지 마십시오.

8. 설정 검증
   안전한 비프로덕션 검증을 실행하십시오:

• 구성(configuration)이 올바르게 파싱되는지 확인합니다.

멀티 에이전트 (multi-agent) 모드가 활성화되었는지 확인하십시오. 최대 깊이 (maximum depth)가 1인지 확인하십시오. 하위 프로필 (child profiles)이 자식(children)을 디스patch할 수 없는지 확인하십시오. 처리량 (throughput)이 낮은 작은 읽기 전용 (read-only) 작업 하나를 디스패치하십시오. 읽기 전용 판단 검토 (read-only judgment review) 하나를 디스패치하십시오. 루트 (root)가 두 결과 모두를 수신하고 합성 (synthesize)할 수 있는지 확인하십시오. 관리되는 외부 에이전트 (external-agent) 연결이 이미 존재하는 경우, 제한된 읽기 전용 교차 벤더 스모크 테스트 (cross-vendor smoke test)를 한 번 수행하고 그 결과를 수집하십시오. 사용자가 명시적으로 요청하지 않는 한 유료 Fable 스모크 테스트를 수행하지 마십시오. 검증 과정에서 생성된 임시 세션 (temporary sessions) 및 워크트리 (worktrees)를 정리하십시오. 설정 중에는 프로덕션 (production)을 커밋 (commit), 푸시 (push), 배포 (deploy), 마이그레이션 (migrate), 게시 (publish) 또는 수정하지 마십시오.

9. 최종 보고서 반환 항목:

• 역량 인벤토리 (capability inventory)
• 생성되거나 변경된 파일
• 생성된 백업
• 간결한 구성 차이 (configuration diff)
• 구성된 네이티브 에이전트 (native agent) 역할
• 교차 벤더 (cross-vendor) 상태: 활성 (active), 수동 전용 (manual-only), 또는 사용 불가 (unavailable)
• Fable 상태: 비활성화 (disabled), 권한은 있으나 제한됨 (authorized-but-gated), 또는 사용 불가 (unavailable)
• 수행된 검증 및 정확한 결과
• 사용자 조치가 필요한 사항
• 증명되지 않은 사항을 설명하는 정직한 한계치 (ceiling)

네이티브 에이전트 스모크 테스트가 통과하지 않는 한 설정이 완료되었다고 말하지 마십시오. 관리되는 라이브 교차 벤더 디스패치 (cross-vendor dispatch)가 실제로 완료되지 않는 한 교차 벤더 오케스트레이션 (cross-vendor orchestration)이 작동한다고 말하지 마십시오.

환경 및 기존 구성을 검사하는 것으로 시작하십시오.