Codex Sol은 Luna Max를 지휘할 수 있지만, 쿼터 계산은 입증되지 않았다

Codex Sol 사용자들은 새로운 역할 분담 방식을 시험하고 있다. 주력 모델이 지휘를 맡고, 구현 작업은 Luna Max에 보내는 방식이다. 이 구성은 품질과 소비량 사이의 직접적인 충돌을 예고한다. Sol은 계획을 세우고 검토하며, 맞춤형 Luna 워커는 메인 스레드의 모든 턴을 점유하지 않고 코드를 작성한다.

이 아이디어는 AYi AI Notes 게시물에서 나왔다. 이 게시물은 ~/.codex/agents/ 아래에 luna-worker.toml을 만들고, gpt-5.6-luna를 선택한 뒤 추론 강도를 max로 설정하자고 제안한다. 이후 Codex Sol은 오케스트레이터, 즉 작업을 나누고 업무를 위임하며 반환된 변경 사항을 평가하는 에이전트 역할을 맡는다.

이 구성 메커니즘은 실제로 존재하며 문서화되어 있다. 그러나 제시된 쿼터 절감과 두 배의 산출량은 독립적으로 검증되지 않았다. OpenAI가 서브에이전트 워크플로가 비슷한 단일 에이전트 실행보다 더 많은 토큰을 소비할 수 있다고 경고하기 때문에 이 구분은 중요하다. 결과는 파일명보다 어떤 작업을 위임하느냐에 더 크게 좌우된다.

Codex Sol 패턴은 판단과 구현을 분리한다

중요한 변화는 단순히 다른 모델에 접근할 수 있다는 점이 아니다. 아키텍처 판단과 실행을 분리한다는 데 있다.

OpenAI는 Codex 서브에이전트를 별도 스레드에서 할당된 작업을 수행하는 전문화된 에이전트로 설명한다. 부모 에이전트는 이들을 생성하고, 결과를 기다리고, 후속 지침을 보내며, 작업 결과를 하나의 응답으로 결합할 수 있다.

이 구조는 Codex Sol이 영향 범위가 넓은 결정을 계속 맡을 수 있게 한다. 여기에는 작업 분해, 인터페이스 설계, 의존성 선택, 승인 기준, 최종 코드 검토가 포함된다. Luna 워커는 더 좁은 계약을 받아 그 경계 안에서 구현을 처리한다.

OpenAI의 서브에이전트 문서는 로컬 Codex 클라이언트가 ~/.codex/agents/ 아래의 개인 에이전트 파일을 지원한다고 확인한다. 프로젝트별 정의는 대신 리포지토리 내부의 .codex/agents/에 둘 수 있다.

각 독립형 에이전트 파일에는 세 가지 필드가 반드시 포함되어야 한다.

• 에이전트 역할을 식별하는 name

• Codex가 해당 역할이 적합한 시점을 판단하는 데 도움이 되는 description

• 작업 방식을 정의하는 developer_instructions

파일은 일반 세션 설정도 재정의할 수 있다. 여기에는 model, model_reasoning_effort, 샌드박스 제어, 도구, 스킬 구성이 포함된다.

보고된 설정의 대표적인 버전은 다음과 같다.

이 예시는 문서화된 구성 형식을 반영한다. 원문 게시자의 완전한 지침은 소스 자료를 통해 확인할 수 없었으므로, 검증된 파일을 그대로 재현한 것은 아니다.

이 구분은 모델 선택만으로 신뢰할 수 있는 워커가 만들어지지는 않기 때문에 중요하다. 설명은 라우팅에 영향을 주고, 개발자 지침은 범위, 테스트 의무, 중단 조건을 정의한다. 모호한 프로필은 집중된 구현 에이전트를 또 하나의 범용 대화 에이전트로 만들 수 있다.

또한 이 파일이 모든 코딩 요청을 자동으로 Luna 작업으로 만들지는 않는다. 현재 Codex 릴리스는 직접적인 요청이 있거나, 적용 가능한 프로젝트 지침 또는 스킬이 위임을 요구할 때 위임한다. 사용자는 여전히 어떤 작업이 워커의 몫인지 Sol에 알려주는 라우팅 규칙이 필요하다.

그 규칙은 프롬프트, 프로젝트 AGENTS.md, 또는 적용 가능한 다른 지침 계층에 둘 수 있다. 유용한 정책은 아키텍처와 검토는 Sol에 남기고, 범위가 명확한 구현 단위를 Luna로 라우팅한다.

이 패턴은 하나의 주력 모델을 모든 단계에 붙여 두는 기본 습관에 도전한다. 모델 역량을 하나의 설정이 아니라 포트폴리오로 다룬다.

Luna Max가 이례적인 워커 선택인 이유

Luna Max는 효율성 중심 모델과 문서상 최고 수준의 추론 설정을 결합해, 의도적인 품질 대 소비량 실험을 만든다.

OpenAI는 gpt-5.6-sol을 까다로운 작업을 위한 주력 모델로 포지셔닝한다. gpt-5.6-terra는 역량과 효율성의 균형을, gpt-5.6-luna는 명확하고 반복 가능하며 대량 처리에 적합한 작업을 목표로 한다고 설명한다.

이 지침에 따르면 Sol이 이미 모호함을 제거한 경우 Luna는 논리적인 구현 워커가 된다. 검증이 포함된 엔드포인트 추가, 컴포넌트 업데이트, 명세화된 마이그레이션 구현 같은 작은 작업은 주변 시스템을 설계하는 일보다 해법 공간이 더 명확하다.

Max 추론은 이 프로필을 바꾼다. 추론 강도는 지원되는 모델이 답변을 탐색하고 검증하는 데 얼마나 많은 내부 작업을 할 수 있는지를 제어한다. OpenAI는 높은 설정이 복잡한 작업을 개선할 수 있지만, 응답 시간과 토큰 사용량도 늘린다고 말한다.

회사의 GPT-5.6 가이드는 효율적이고 대량 처리하는 워크로드에 Luna를 권장한다. 더 많은 탐색과 검증이 필요한 까다로운 작업에는 max를 권장한다.

따라서 두 설정을 결합하는 방식은 가장 자명한 효율성 구성은 아니다. Luna는 더 낮은 모델 계층을 제공하고, Max는 그 모델에 더 깊이 생각하라고 요구한다. 이 조합이 워커의 모든 턴에서 Sol 수준의 판단 비용을 지불하지 않으면서도 충분한 구현 품질을 유지할 수 있다는 데 베팅하는 셈이다.

이 방식은 작업 분해가 이미 불확실성을 낮춘 경우에 작동할 수 있다. 독립적인 어댑터 열 개가 있는 리포지토리 마이그레이션을 생각해 보자. Sol은 공통 인터페이스를 식별하고, 불변 조건을 정의하며, 테스트를 명세할 수 있다. 그러면 Luna 워커는 동일한 계약을 바탕으로 개별 어댑터를 구현할 수 있다.

워커가 아키텍처를 다시 발견해야 하는 상황에서는 경제성이 약해진다. 각 Luna 에이전트가 전체 리포지토리를 읽고, 요구사항을 논의하고, 계획을 수정하고, 광범위한 변경을 재시도한다면 Max 추론은 예상된 절감 효과를 지워 버릴 수 있다.

이 구성은 프롬프트 품질에도 새로운 부담을 준다. 한 에이전트를 쓰는 사람은 상호작용을 통해 모호함을 해결할 수 있다. 오케스트레이터는 위임 전에 그 모호함을 범위가 정해진 작업 지시서로 바꿔야 한다.

최선의 작업 지시서는 정확한 목표, 관련 파일, 제약 조건, 테스트 명령, 예상 출력, 에스컬레이션이 필요한 조건을 식별한다. 또한 워커에게 변경하지 말아야 할 대상도 알려준다.

바로 이 지점에서 Codex Sol이 워크플로에서 제 역할을 한다. Sol은 사용자의 프롬프트를 단순히 전달해서는 안 된다. 요청을 명확한 소유권과 측정 가능한 완료 기준을 갖춘 구현 단위로 변환해야 한다.

개발자에게 이는 경험 많은 기술 리드가 기여자들에게 작업을 할당하는 방식과 닮아 있다. 리드는 아키텍처를 보호하고 결과를 통합한다. 기여자들은 정의된 범위 안에서 독립적으로 작업한다.

모델은 장기 협업자처럼 조직적 이해를 유지하지 않기 때문에 이 비유에는 한계가 있다. 각 에이전트에는 여전히 충분한 컨텍스트가 필요하며, 추가되는 모든 컨텍스트 패킷에는 소비량과 조정 비용이 따른다.

이미 검색 가능한 엔지니어링 지식 베이스를 유지하는 팀은 여기서 이점이 있다. 안정적인 규칙, 아키텍처 메모, 테스트 가이드는 오케스트레이터에게 범위가 좁은 과제를 배정할 더 나은 자료를 제공한다.

따라서 Luna Max는 보편적으로 저렴한 워커가 아니다. 작업 경계가 명확해질수록 가치가 커지는 전문 실행 프로필이다.

진짜 상대는 단일 모델 코딩이다

핵심 경쟁은 오케스트레이션된 모델 라우팅과 모든 코딩 단계를 하나의 고성능 모델로 처리하는 방식 사이에 있다.

단일 모델 Codex 세션은 이해하기 쉽다. 하나의 에이전트가 리포지토리를 탐색하고, 질문하고, 계획을 작성하고, 파일을 편집하고, 테스트를 실행하고, 실패를 진단하며, 자신의 작업을 검토한다.

이 연속성에는 실제 가치가 있다. 에이전트는 하나의 컨텍스트 안에서 결정을 유지하며, 다른 스레드를 위해 이를 요약할 필요가 없다. 작은 작업은 위임 오버헤드가 구현 작업을 초과할 수 있기 때문에 이런 단순함의 이점을 보는 경우가 많다.

비용은 작업이 커질수록 드러난다. 탐색 로그, 테스트 출력, 포기한 접근 방식, 구현 세부 사항이 요구사항과 아키텍처 결정을 담은 같은 대화에 축적된다.

OpenAI는 이러한 효과를 컨텍스트 오염과 컨텍스트 부패라고 부른다. 관련성이 낮은 자료가 스레드를 채울수록 중요한 정보를 찾기가 더 어려워진다. 회사는 서브에이전트가 잡음이 많은 작업을 메인 대화에서 분리하고 정제된 결과를 반환함으로써 이를 돕는다고 말한다.

제안된 구성에서 Codex Sol은 지속적인 결정의 관리자가 된다. 그 스레드에는 목표, 시스템 제약 조건, 작업 맵, 통합 선택, 검토 결과, 최종 상태가 담겨야 한다.

Luna 워커는 로컬 잡음을 흡수한다. 관련 파일을 검사하고, 패치를 생성하며, 집중된 테스트를 실행하고, 간결한 결과 기록을 반환한다. 이들의 원시 조사 과정은 Sol의 메인 컨텍스트를 차지할 필요가 없다.

이는 쿼터 사용량 이상을 개선할 수 있다. 긴 구현 기록이 초기 요구사항을 실질적 주의 범위 밖으로 밀어낼 위험도 줄일 수 있다. 오케스트레이터는 실패한 모든 명령 대신 요약을 본다.

하지만 위임은 다른 형태의 오버헤드를 만든다. Sol은 워커 프롬프트를 준비하고, 진행 상황을 모니터링하고, 결과를 해석하고, 변경 사항을 검사하며, 때로는 수정을 위해 작업을 다시 보내야 한다.

병렬 쓰기는 또 다른 문제를 더한다. OpenAI는 동시에 발생하는 코드 편집이 충돌을 일으키고 조정 비용을 늘릴 수 있으므로, 읽기 비중이 큰 서브에이전트 작업부터 시작할 것을 권장한다. 같은 공유 모듈을 변경하는 두 에이전트는 각각은 합리적으로 보이지만 함께 적용하면 실패하는 패치를 만들 수 있다.

따라서 합리적인 Codex Sol 워크플로는 소유권에 따라 작업을 분리한다. 한 워커는 백엔드 핸들러를 업데이트하고, 다른 워커는 격리된 테스트를 추가하며, 세 번째 워커는 문서를 감사할 수 있다. 공유 타입과 중앙 구성은 한 명의 소유자 아래에 남겨야 한다.

Git worktree 또는 엄격히 분리된 파일은 간섭을 줄일 수 있지만, 의미론적 충돌까지 없애지는 못한다. 두 변경 사항은 각각 별도로 컴파일되면서도 같은 계약에 대해 양립할 수 없는 가정을 할 수 있다.

오케스트레이터는 구현과 검토도 구분해야 한다. Luna에게 코드를 작성하게 한 뒤 그 결과를 자체적으로 수용하도록 하면 역할 분담이 약화된다. Sol은 원래 작업과 비교해 diff를 검사하고, 테스트를 검증하며, 범위를 벗어난 변경 사항을 찾아야 한다.

이 검토 역할은 Sol을 최상위에 유지해야 하는 가장 강력한 근거다. 주력 모델은 반복적인 편집이 아니라 레버리지가 큰 지점에 역량을 쓴다.

일반적인 순서는 다섯 단계로 진행된다.

1. Sol이 요청을 조사하고 아키텍처 경계를 정의한다.

2. Sol이 계획을 독립적이고 테스트 가능한 과제로 변환한다.

3. Luna Max가 선택된 과제를 별도 스레드에서 구현한다.

4. Sol이 반환된 diff, 테스트 증거, 미해결 위험을 검토한다.

5. Sol이 승인된 작업을 통합하고 더 광범위한 검증을 실행한다.

이 순서가 자동으로 더 빠른 것은 아니다. 여러 과제가 독립적으로 진행될 수 있거나 구현 과정에서 폐기 가능한 컨텍스트가 대량으로 생성될 때 가장 효과적이다.

명확한 수정 방법이 있는 단일 파일 버그라면, 워커가 충분한 컨텍스트를 받기 전에 부모 에이전트가 작업을 끝낼 가능성이 크다. 독립적인 패키지에 걸친 광범위한 기능이라면 오케스트레이션이 오버헤드를 상쇄할 여지가 더 크다.

따라서 올바른 비교 대상은 Sol과 Luna가 아니다. 비용이 큰 연속 스레드와, 서로 다른 단계에서 서로 다른 종류의 주의를 투입하는 계층 구조다.

두 배 산출량 주장은 여전히 증거가 필요하다

현재 이 Codex Sol 구성이 쿼터 사용량을 절반으로 줄이거나 완료 작업량을 두 배로 늘린다는 사실을 입증하는 공개 벤치마크는 없다.

원래의 소셜 게시물은 매력적인 결과를 제시한다. 사용 한도를 절약하면서 두 배 더 많이 생산한다는 것이다. 이 주장은 측정된 제품 보장이 아니라 개인 워크플로에 대한 보고로 다뤄야 한다.

OpenAI는 서브에이전트 워크플로가 유사한 단일 에이전트 실행보다 더 많은 토큰을 소비한다고 명시적으로 밝히고 있다. 각 하위 에이전트가 자체 모델 및 도구 작업을 수행하는 동시에, 부모 에이전트도 작업 생성과 결과 종합에 토큰을 계속 사용하기 때문이다.

이 경고가 해당 구성이 비효율적이라는 점을 입증하는 것은 아니다. Luna를 사용했다는 사실만으로 효율성을 판단할 수 없다는 의미다. 저티어 실행의 이점이 추가 오케스트레이션 비용을 상쇄하는지는 워크로드 설계에 달려 있다.

이 주장을 평가하려면 최소 네 가지 측정치가 필요하다.

첫째, 사용자는 부모와 모든 하위 에이전트를 포함한 총 사용량을 확인해야 한다. Sol 스레드만 보면 작업자 사용량 역시 동일한 워크플로에 속하므로 오해를 낳을 수 있다.

둘째, 완료된 작업의 품질을 측정해야 한다. Sol이 패치 대부분을 다시 작성해야 한다면, 첫 시도가 저렴했다 해도 실제로는 저렴하지 않다. 재작업, 테스트 실패, 리뷰 반복 역시 계산에 포함해야 한다.

셋째, 실제 경과 시간이 필요하다. 병렬 작업자는 총 토큰을 더 소비하면서도 소요 시간을 줄일 수 있다. 이런 교환은 여전히 가치가 있을 수 있지만, 쿼터 절감과는 다르다.

넷째, 비교 가능한 기준선이 필요하다. 동일한 작업 세트를 Sol 단독, Luna Max를 사용하는 Sol, 그리고 필요하다면 더 낮은 추론 설정의 Luna를 사용하는 Sol로 실행해야 한다. 그렇지 않으면 작업 난이도가 차이를 설명할 수 있다.

추론 노력 수준은 특히 면밀히 살펴봐야 한다. OpenAI는 더 높은 노력 수준이 토큰 사용량과 지연 시간을 늘린다고 설명한다. Max는 어려운 작업의 결과를 개선할 수 있지만, 일상적인 수정에 적용하면 Luna를 선택한 효율성 이점을 낭비할 수 있다.

작업 난이도에 기반한 라우팅 정책은 하나의 고정 설정보다 더 설득력 있다. 명확하고 기계적인 변경에는 낮은 추론 수준을 사용하고, 어려운 엣지 케이스가 있는 범위가 제한된 작업에는 Max를 유지할 수 있다.

사회적 주장 역시 런타임 검증 문제에 직면한다. 커스텀 파일은 모델을 지정할 수 있지만, 개발자는 생성된 스레드가 실제로 요청한 역할, 모델, 추론 수준을 받았는지 확인해야 한다.

이 우려는 이론적인 것이 아니다. 한 커뮤니티 버그 보고서는 변화 중인 멀티에이전트 롤아웃 과정에서 하위 에이전트가 부모 설정을 상속한다고 설명했다. 이후 답변에서는 구성 우회 방법이 보고됐지만, 런타임 동작은 빌드와 도구 환경에 따라 달랐다.

또 다른 Codex 이슈는 커스텀 에이전트 파일과 도구 기반 세션 간의 불일치를 기록했다. 보고서는 유효한 프로젝트 에이전트가 사용 가능한 생성 인터페이스를 통해 노출되지 않았다고 밝혔다.

이 보고서들이 현재 커스텀 에이전트가 고장 났다는 사실을 입증하는 것은 아니다. OpenAI의 최신 문서는 에이전트 파일 값이 상속된 설정보다 우선한다고 설명한다. 다만 이 보고서들은 사용자가 의도만 신뢰하지 말고 실제 하위 에이전트 메타데이터를 확인해야 하는 이유를 보여준다.

신뢰할 수 있는 테스트는 각 할당에 대해 다음을 기록해야 한다:

• 요청한 에이전트 역할

• 확인된 모델

• 확인된 추론 노력 수준

• 변경된 파일

• 테스트 명령과 결과

• 부모 리뷰 결과

• 수정 반복 횟수

• 모든 스레드를 아우르는 총 사용량

• 엔드투엔드 경과 시간

그 결과 비교에는 대표성 있는 작업을 사용해야 한다. 보일러플레이트만 포함한 벤치마크는 작업자 모델에 유리하고, 아키텍처적 모호성만 포함한 벤치마크는 Sol에 유리하다. 실제 개발은 두 요소가 섞여 있다.

팀은 실패 격리도 포함해야 한다. 작업자가 제공되지 않은 아키텍처 결정을 요구하는 작업을 받으면 중단해야 한다. 그 결정을 조용히 즉흥적으로 내리면 리뷰 비용과 숨겨진 불일치가 발생한다.

가장 안전한 개발자 지시는 “어떤 대가를 치르더라도 끝내라”가 아니다. “이 경계 안에서 구현하고, 경계가 불충분하면 에스컬레이션하라”이다.

이는 생산성의 의미를 바꾼다. 더 많은 생성 코드가 자동으로 더 많은 산출을 뜻하지는 않는다. 테스트를 통과하고 설계 의도를 보존하는 승인된 변경이 관련 있는 단위다.

통제된 측정 결과가 나오기 전까지 “두 배의 산출”은 독자가 당연한 결과로 받아들일 수 있는 결론이 아니라, 검증할 가치가 있는 가설에 머문다.

Codex Sol 사용자가 다음으로 주목해야 할 점

세 가지 신호가 Sol 주도의 Luna 작업자가 지속 가능한 워크플로가 될지, 아니면 최적화 실험에 머물지를 결정할 것이다.

첫 번째 신호는 검증 가능한 모델 라우팅이다. Codex 클라이언트는 확인된 하위 에이전트 역할, 모델, 추론 노력 수준, 권한 모드를 쉽게 점검할 수 있게 해야 한다.

OpenAI의 문서는 커스텀 에이전트 파일에 설정된 값이 우선한다고 설명한다. 또한 생략된 설정은 명시적 생성 값, [agents] 기본값 또는 부모 세션에서 올 수 있다고 설명한다.

이 확인 순서는 유연하지만, 그 유연성은 실수를 숨길 수 있다. Luna Max를 요청한 개발자는 원시 세션 로그를 뒤지거나 도구 호출을 역공학하지 않고도 Luna Max가 사용됐음을 확인할 수 있어야 한다.

향후 Codex 릴리스가 앱, CLI, IDE, 도구 기반 세션 전반에서 이러한 검증을 일관되게 제공한다면 Sol 주도 패턴의 신뢰도는 높아진다. 라우팅이 계속 클라이언트별 동작에 의존한다면, 주장된 절감 효과는 재현하기 어려울 것이다.

두 번째 신호는 워크로드 수준의 측정이다. 사용자는 에이전트 트리 전반의 사용량, 지연 시간, 재시도, 승인된 산출을 귀속시키는 대시보드가 필요하다.

구현이 다른 곳으로 이동했기 때문에 부모 스레드가 효율적으로 보일 수 있다. 집계 보고가 없으면 위임이 쿼터를 절약했는지, 아니면 단지 이를 재분배했는지 알 수 없다.

가장 유용한 지표는 총 사용량과 승인된 작업을 결합한 형태일 것이다. 그러면 팀은 동일한 리포지토리와 평가 스위트에서 Sol 단독 작업과 Sol이 오케스트레이션한 Luna 작업을 비교할 수 있다.

품질은 사용량과 함께 계속 보이게 해야 한다. 사용량은 줄이지만 리뷰 시간을 두 배로 늘리는 작업자 프로필은 명확한 이점을 제공하지 않는다. 더 빨리 끝나지만 서로 충돌하는 패치를 만들어 내는 병렬 워크플로도 마찬가지다.

세 번째 신호는 안정적인 라우팅 관례의 등장이다. 오늘날 사용자는 커스텀 에이전트를 정의하고 Codex에 위임을 지시할 수 있다. 더 어려운 문제는 언제 위임해야 하는지를 결정하는 일이다.

보고된 구성은 하나의 규칙을 제시한다. Sol이 계획과 리뷰를 맡고, Luna Max가 구현을 맡는다는 것이다. 기억하기는 쉽지만, 프로덕션 팀에는 더 정교한 경계가 필요하다.

성숙한 정책은 다음과 같이 라우팅할 수 있다:

• 아키텍처, 모호한 디버깅, 통합 결정은 Sol로

• 리포지토리 탐색과 문서 스캔은 Terra로

• 범위가 좁은 구현, 반복적인 마이그레이션, 독립적인 테스트는 Luna로

• 보안에 민감하거나 여러 영역에 걸친 리뷰는 다시 Sol로

• 상충하거나 불충분하게 정의된 작업은 수정 전에 부모 에이전트로

이러한 경계는 모델 브랜딩이 아니라 측정 결과를 바탕으로 발전해야 한다. 한 코드베이스에서 좋은 성과를 내는 Luna 작업자도 테스트가 부족하거나 관례가 문서화되지 않은 다른 코드베이스에서는 어려움을 겪을 수 있다.

개발자는 검증하기 쉬운 작업부터 시작해야 한다. 좋은 후보로는 독립적인 테스트 추가, 스키마 기반 어댑터, 기계적인 API 마이그레이션, 명시적 승인 기준을 갖춘 컴포넌트가 있다.

인증 재설계, 롤백 계획이 없는 데이터 마이그레이션, 여러 공유 서브시스템에 걸친 변경부터 시작해서는 안 된다. 그런 작업은 작업자 할당 안에 지나치게 많은 숨은 판단을 담게 된다.

실질적인 다음 단계는 통제된 내부 실험이다. 완료된 이슈 중 작은 세트를 선택해 원래 요구사항을 보존하고, 두 워크플로로 모두 실행한다. 승인된 산출, 총 사용량, 경과 시간, 리뷰 노력을 비교한다.

그 실험 동안 luna-worker.toml 프로필의 범위를 좁게 유지하라. 파일 요약, 테스트 증거, 명시적인 에스컬레이션을 요구하라. Codex Sol에는 기준선에 사용한 것과 동일한 승인 기준에 따라 모든 diff를 검토하도록 요청하라.

작업자가 반복적으로 깔끔하고 범위가 제한된 변경을 반환한다면, 작업 범위를 점진적으로 확장하라. Sol이 결정을 수리하거나 다시 찾아내는 데 상당한 시간을 쓴다면, 모델을 바꾸기 전에 작업 분해를 개선해야 한다.

Codex Sol과 Luna Max 패턴은 AI 코딩의 설득력 있는 미래를 가리킨다. 하나의 모델이 모든 역할을 수행할 필요는 없다. 그러나 오케스트레이션은 공짜 효율성 계층이 아니다. 지속적인 컨텍스트를 라우팅, 검증, 조정과 맞바꾼다.

유용한 질문은 Luna가 더 많은 코드를 작성할 수 있는지가 아니다. Sol이 Luna의 코드가 리뷰를 통과할 수 있을 만큼 명확하게 작업을 정의할 수 있는지다. 실제 작업 전반에서 그 결과를 측정한 뒤, 증거가 개발 대기열 중 얼마를 위임할지 결정하게 하라.