Codex Multi-Agent v2 모델 분담 실전 가이드
Codex의 멀티에이전트 기능이 흥미로운 이유는 단순히 여러 작업을 동시에 실행할 수 있기 때문만은 아닙니다. 더 중요한 변화는 각 서브에이전트가 맡은 일의 난이도와 성격에 맞춰 모델과 추론 강도를 다르게 선택할 수 있는 구조가 공식 구현에 들어왔다는 점입니다. 하나의 강한 모델이 조사, 구현, 테스트, 문서화를 모두 처리하던 방식에서 벗어나, 오케스트레이터는 전체 판단을 맡고 빠른 모델은 범위가 좁은 반복 작업을 수행하도록 나눌 수 있습니다.
이 글은 특정 모델 조합이 항상 더 싸거나 빠르다고 단정하지 않습니다. OpenAI Codex 공식 저장소의 현재 설정 구조와 도구 명세를 기준으로 무엇이 실제로 지원되는지, 버전과 모델 카탈로그에 따라 무엇이 달라질 수 있는지, 팀에서 안전하게 적용하려면 어떤 측정과 품질 게이트가 필요한지를 정리합니다. Threads의 choi.openai 계정에서 확인한 최신 게시물은 화제성을 파악하는 보조 자료로만 활용했고, 기술 사실은 공식 코드와 릴리스 정보로 다시 확인했습니다.
무엇이 달라졌나: 병렬 실행보다 모델 선택권
전통적인 단일 에이전트 흐름에서는 하나의 세션이 요구사항을 읽고, 저장소를 탐색하고, 코드를 수정하고, 테스트 결과를 해석합니다. 작업이 길어질수록 컨텍스트가 커지고, 간단한 파일 검색에도 고성능 모델의 추론 시간이 쓰입니다. 멀티에이전트는 일을 잘게 나눌 수 있지만, 모든 자식 에이전트가 부모와 같은 모델과 추론 강도를 그대로 상속한다면 비용과 지연시간을 줄일 여지가 제한됩니다.
현재 Codex 공식 코드의 spawn_agent 도구 명세에는 조건이 충족될 때 model과 reasoning_effort 오버라이드가 노출됩니다. 명세 설명은 모델을 지정하지 않으면 부모 세션의 선호 설정을 상속하고, 명시적 변경이 필요할 때만 오버라이드를 사용하도록 안내합니다. 즉 기본값은 일관성이고, 모델 분담은 의도적으로 선택하는 예외입니다. 이 설계는 모델 라우팅을 무조건 자동 최적화로 보지 않고 운영자가 책임져야 할 정책으로 다룬다는 뜻입니다.
설정 구조에도 같은 방향이 보입니다. 공식 저장소의 AgentsToml에는 서브에이전트 기본 모델과 기본 추론 강도를 위한 필드가 정의돼 있습니다. 실행 시 개별 spawn 요청의 값이 우선하고, 요청에 값이 없으면 설정의 기본값을 사용할 수 있도록 구현돼 있습니다. 다만 필드가 코드에 존재한다는 사실과 모든 배포 채널에서 동일하게 노출된다는 사실은 다릅니다. 안정판, 알파판, 데스크톱 앱에 포함된 CLI 버전, 서버에서 내려오는 모델 카탈로그가 서로 다를 수 있으므로 실제 세션의 도구 스키마와 버전을 함께 확인해야 합니다.
이미지: AI 생성 개념 도해 — 오케스트레이터가 조사·구현·검증 역할로 작업을 분배하고 결과를 다시 모으는 구조
공식 구현에서 확인되는 네 가지 사실
첫째, 모델 오버라이드는 아무 문자열이나 받아 실행하는 구조가 아닙니다. Codex는 현재 세션에서 사용할 수 있는 모델 목록을 조회하고, 요청한 모델이 해당 멀티에이전트 백엔드 버전을 지원하는지 확인합니다. 지원하지 않거나 목록에 없는 이름이면 사용 가능한 후보를 포함한 오류를 반환하도록 구현돼 있습니다. 따라서 블로그나 SNS에 나온 모델 이름을 그대로 설정에 붙여 넣기보다, 실제 세션이 보여주는 선택지와 도구 설명을 기준으로 해야 합니다.
둘째, 모델과 추론 강도는 별도로 검증됩니다. 특정 모델을 선택했다고 해서 임의의 reasoning effort 값을 모두 사용할 수 있는 것은 아닙니다. 공식 코드는 선택한 모델의 지원 추론 수준 목록을 확인하고, 지원하지 않는 값이면 오류를 돌려줍니다. 운영 관점에서는 모델 라우팅 표에 모델 이름만 적을 것이 아니라 허용되는 추론 강도까지 묶어 관리해야 한다는 의미입니다.
셋째, 선택 목록은 무한정 길게 노출되지 않습니다. 현재 공식 구현에는 spawn 도구가 보여줄 모델 오버라이드 후보 수를 제한하는 상수가 있습니다. 모델 카탈로그에 많은 모델이 있어도 도구 설명에는 필터를 거친 일부만 표시될 수 있습니다. 사용자가 알고 있는 모델이 목록에 보이지 않는다면 구독 문제라고 단정하기 전에 모델의 picker 노출 여부, V2 호환 메타데이터, 현재 앱이 쓰는 CLI 빌드를 확인해야 합니다.
넷째, 자식 에이전트는 부모의 실시간 실행 환경을 단순히 오래된 설정 파일에서 복제하지 않습니다. 공식 구현은 작업 디렉터리, 승인 정책, 권한 프로필처럼 현재 턴에서 결정된 런타임 값을 자식 설정에 반영하는 절차를 둡니다. 모델만 분리하고 권한 경계를 잊으면 안 되는 이유입니다. 빠른 모델에 반복 작업을 맡기더라도 쓰기 권한, 네트워크 접근, 승인 방식은 작업 위험도에 맞게 설계해야 합니다.
좋은 역할 분담은 모델 이름보다 작업 경계에서 시작한다
모델 라우팅을 도입할 때 가장 흔한 실수는 강한 모델과 빠른 모델을 먼저 정한 뒤 작업을 억지로 끼워 맞추는 것입니다. 먼저 해야 할 일은 실패 비용이 낮고 완료 조건을 자동으로 검사할 수 있는 작업을 찾는 것입니다. 예를 들어 파일 목록 수집, 특정 심볼의 참조 위치 검색, 테스트 로그의 오류 그룹화, 이미 정해진 템플릿에 따른 기계적 변경은 범위가 좁고 산출물을 검증하기 쉽습니다. 이런 작업은 빠른 서브에이전트 후보가 됩니다.
반대로 요구사항이 모호하거나 여러 모듈의 의미를 함께 이해해야 하는 설계 결정, 보안 경계를 바꾸는 수정, 데이터 마이그레이션 계획, 충돌하는 증거를 종합하는 진단은 오케스트레이터나 더 강한 추론 모델이 맡는 편이 안전합니다. 핵심은 코드 작성 자체의 길이가 아니라 잘못된 판단이 미치는 범위입니다. 한 줄짜리 권한 수정은 짧아도 위험하고, 수십 파일의 동일한 이름 변경은 길어도 자동 검증이 가능할 수 있습니다.
검증 역할은 구현 역할과 분리할 가치가 큽니다. 구현을 수행한 에이전트는 자신의 가정에 끌려가기 쉽습니다. 별도의 검증 에이전트가 변경된 파일, 테스트 결과, 요구사항 체크리스트를 독립적으로 확인하면 누락을 줄일 수 있습니다. 그렇다고 검증 모델을 무조건 가장 강한 모델로 정할 필요는 없습니다. 정적 검사, 단위 테스트, 스키마 검증처럼 판정 기준이 명확한 경우에는 빠른 모델이 결과를 수집하고, 최종 승인만 오케스트레이터가 수행할 수 있습니다.
실전 라우팅 표를 만드는 방법
팀에서 시작하기 좋은 방식은 작업을 네 가지 축으로 평가하는 것입니다. 첫 번째는 모호성입니다. 입력만 보고 단일한 정답을 정의할 수 있는지 봅니다. 두 번째는 영향 범위입니다. 실패가 한 파일에 머무는지, 배포와 데이터에 영향을 주는지 구분합니다. 세 번째는 검증 가능성입니다. 테스트나 구조화된 출력으로 자동 판정할 수 있는지 확인합니다. 네 번째는 컨텍스트 의존성입니다. 전체 대화와 설계 배경이 필요한지, 몇 개 파일만으로 충분한지 측정합니다.
- 낮은 모호성, 작은 영향 범위, 높은 검증 가능성: 빠른 모델의 서브에이전트에 적합합니다.
- 낮은 모호성, 넓은 영향 범위: 실행은 분담하되 승인과 병합은 오케스트레이터가 맡습니다.
- 높은 모호성, 작은 영향 범위: 탐색용 시안을 여러 개 만든 뒤 강한 모델이 비교합니다.
- 높은 모호성, 넓은 영향 범위: 처음부터 강한 모델이 계획과 판단을 주도해야 합니다.
라우팅 규칙은 모델 브랜드가 아니라 역할 이름으로 표현하는 것이 유지보수에 유리합니다. 예를 들어 explorer, builder, verifier처럼 책임을 정의하고 각 역할 뒤의 모델은 운영 설정에서 바꿉니다. 모델 카탈로그나 가격 정책이 바뀌어도 프롬프트와 작업 계약을 다시 쓰지 않아도 됩니다. 역할 계약에는 입력 범위, 허용 도구, 출력 형식, 완료 조건, 금지 행동을 포함해야 합니다.
이미지: AI 생성 비교 도해 — 단일 모델 직렬 처리와 역할별 모델 라우팅의 차이
속도와 비용은 반드시 결과 단위로 측정한다
빠른 모델을 섞으면 항상 비용이 내려간다는 주장은 성립하지 않습니다. 작업 분해가 잘못되면 서브에이전트 사이의 설명과 결과 병합에 추가 토큰이 들고, 낮은 품질의 초안을 반복 수정하느라 전체 시간이 늘어날 수 있습니다. 동시에 많은 에이전트를 실행하면 벽시계 시간은 줄어도 총 연산량은 커질 수 있습니다. 따라서 토큰당 가격이나 개별 호출 지연시간보다 검증을 통과한 변경 한 건당 총비용과 총소요시간을 봐야 합니다.
최소 측정 항목은 네 가지입니다. 작업 시작부터 최종 승인까지의 시간, 모든 에이전트가 소비한 합산 토큰 또는 크레딧, 재시도 횟수, 첫 번째 검증 통과율입니다. 여기에 병합 충돌 수와 사람이 개입한 시간을 추가하면 실제 생산성을 더 정확히 볼 수 있습니다. 비교 실험에서는 같은 유형의 작업 묶음을 단일 모델 방식과 역할별 라우팅 방식으로 각각 수행하고, 결과 품질 기준을 동일하게 유지해야 합니다.
특히 조사 작업은 병렬화가 쉬워 보이지만 중복 탐색이 발생하기 쉽습니다. 탐색 에이전트마다 검색 범위와 질문을 분리하고, 결과를 근거 링크와 함께 짧은 구조로 반환하게 해야 합니다. 구현 작업도 파일 소유권이 겹치지 않게 나누는 편이 좋습니다. 같은 파일을 여러 에이전트가 동시에 고치면 절약한 시간보다 충돌 해결 시간이 더 길어질 수 있습니다.
컨텍스트 분리와 보안 경계
서브에이전트가 부모의 전체 대화를 모두 받아야 하는지는 작업마다 다릅니다. 전체 이력을 전달하면 배경 이해는 쉬워지지만 토큰 비용과 민감 정보 노출 범위가 커집니다. 반대로 컨텍스트를 지나치게 줄이면 자식이 이미 결정된 제약을 놓치고 엉뚱한 결과를 낼 수 있습니다. 좋은 위임 메시지는 목표, 범위, 필요한 파일, 금지 사항, 검증 명령, 반환 형식을 포함하는 작은 작업 계약입니다.
권한은 모델 능력과 별개로 최소화해야 합니다. 저장소 조사만 하는 에이전트에는 쓰기 권한이 필요하지 않습니다. 테스트 로그를 분류하는 작업에는 외부 네트워크가 필요하지 않을 수 있습니다. 배포 자격 증명이나 개인 데이터가 있는 환경에서는 자식 에이전트가 읽을 수 있는 경로를 더 좁혀야 합니다. 모델 라우팅이 편리해질수록 더 많은 자식 실행이 생길 수 있으므로, 권한 정책과 감사 로그는 먼저 준비하는 편이 안전합니다.
또한 모델별로 도구 호출 특성과 지시 이행 성향이 다를 수 있습니다. 같은 프롬프트를 다른 모델에 배정했을 때 출력 형식이 달라지는 문제를 줄이려면 JSON 스키마, 파일 변경 목록, 테스트 결과 같은 구조화된 반환 계약을 사용합니다. 반환값을 믿고 바로 병합하지 말고 오케스트레이터가 실제 파일 상태와 테스트 결과를 다시 확인해야 합니다.
버전과 호환성에서 조심할 점
현재 공식 저장소의 main 브랜치에서 모델 오버라이드와 V2 관련 구현을 확인할 수 있지만, 사용자가 설치한 안정판에 동일한 코드가 포함됐다고 가정하면 안 됩니다. 공식 GitHub 릴리스 페이지에는 안정판과 여러 알파판이 함께 제공되고, 시점에 따라 기능이 먼저 알파 채널에 들어갈 수 있습니다. 실제 적용 전 codex --version을 기록하고, 세션에서 보이는 spawn 도구 스키마에 model과 reasoning_effort가 존재하는지 확인해야 합니다.
모델 이름도 고정 상수가 아닙니다. 서버의 모델 카탈로그와 구독, 앱 표면, 멀티에이전트 백엔드 버전에 따라 노출 후보가 달라질 수 있습니다. 공식 구현은 V2를 지원하지 않는 모델을 후보에서 거르므로, 부모에서 사용할 수 있는 모델이 자식 오버라이드 목록에는 없을 수 있습니다. 이때 설정 파일을 억지로 수정하기보다 현재 배포의 지원 범위를 받아들이고 기본 상속 방식으로 폴백하는 것이 안전합니다.
공개 이슈에는 특정 버전에서 설정한 자식 모델이 적용되지 않거나, V2 호환 메타데이터와 실제 실행 가능성이 어긋난다는 보고도 있습니다. 이슈는 공식 제품 약속이 아니라 사용자 보고이므로 사실을 일반화해서는 안 되지만, 운영 체크리스트를 만드는 데는 유용합니다. 중요한 자동화라면 자식 세션이 실제로 어떤 모델과 추론 강도로 시작했는지 로그로 확인하고, 기대값과 다르면 즉시 단일 모델 방식으로 되돌릴 수 있어야 합니다.
작게 시작하는 도입 절차
- 현재 Codex 버전과 멀티에이전트 백엔드를 기록합니다. 새 세션의 도구 명세에서 모델 오버라이드 필드와 사용 가능한 후보를 확인합니다.
- 최근 작업 가운데 실패 영향이 작고 자동 테스트가 있는 작업 10개 정도를 선택합니다. 문서 정리, 참조 검색, 독립된 테스트 추가처럼 경계가 분명한 작업이 좋습니다.
- explorer, builder, verifier 세 역할의 입력과 출력 계약을 작성합니다. 각 역할이 수정할 수 있는 파일과 실행할 검증 명령을 제한합니다.
- 먼저 부모 모델 상속 방식으로 멀티에이전트 분해가 제대로 작동하는지 확인합니다. 작업 경계가 안정된 뒤 일부 역할에만 모델 오버라이드를 적용합니다.
- 단일 모델 기준선과 라우팅 실험의 시간, 총사용량, 재시도, 첫 검증 통과율을 비교합니다. 품질 기준은 낮추지 않습니다.
- 모델 또는 버전을 바꿀 때마다 작은 회귀 작업 묶음을 다시 실행합니다. 결과가 나빠지면 역할 계약과 라우팅을 분리해 어느 쪽이 원인인지 확인합니다.
설정 예시는 설치 버전에 따라 키와 노출 방식이 바뀔 수 있으므로 그대로 복사하는 것보다 현재 공식 코드와 자신의 도구 스키마를 기준으로 작성해야 합니다. 운영 문서에는 특정 모델 이름뿐 아니라 폴백 규칙을 포함합니다. 예를 들어 빠른 모델이 목록에 없으면 부모 모델을 상속하고, 추론 강도가 지원되지 않으면 해당 모델의 기본값을 사용하며, 두 번 연속 검증에 실패하면 오케스트레이터가 직접 재수행하도록 정할 수 있습니다.
실패 조건과 반론
모든 프로젝트가 멀티에이전트의 이점을 얻는 것은 아닙니다. 저장소가 작고 작업이 강하게 얽혀 있거나, 테스트가 부족하고 요구사항이 자주 바뀌는 환경에서는 작업 분해 비용이 이득보다 클 수 있습니다. 한 사람이 짧게 끝낼 수 있는 수정에 세 역할을 붙이면 프롬프트와 검토만 늘어납니다. 이 경우에는 단일 에이전트가 전체 맥락을 유지하는 편이 효율적입니다.
모델 라우팅은 품질 책임을 분산하는 장치도 아닙니다. 빠른 에이전트가 만든 결과를 강한 에이전트가 검토한다고 해서 자동으로 안전해지는 것은 아닙니다. 검토자가 원본 파일과 실행 결과를 보지 않고 요약만 읽으면 오류가 그대로 통과할 수 있습니다. 품질 게이트는 실제 테스트, 린트, 타입 검사, 보안 스캔, 변경 범위 확인처럼 외부 증거에 연결되어야 합니다.
또 하나의 반론은 재현성입니다. 모델 카탈로그가 바뀌거나 같은 모델이 업데이트되면 결과가 달라질 수 있습니다. 이를 완전히 없앨 수는 없지만 역할 계약, 도구 버전, 설정 스냅샷, 테스트 입력을 기록하면 영향 범위를 줄일 수 있습니다. 중요한 것은 특정 모델 조합을 영구한 정답으로 선언하는 것이 아니라, 측정 가능한 라우팅 정책으로 관리하는 것입니다.
운영자가 매 실행에서 확인할 체크리스트
첫 번째로 위임 전 작업 계약을 확인합니다. 목표가 한 문장으로 명확한지, 수정 가능한 파일과 읽기만 가능한 파일이 구분돼 있는지, 완료를 판정할 명령이 있는지 살펴봅니다. 서브에이전트가 스스로 범위를 넓혀야만 끝낼 수 있는 작업이라면 분해가 덜 된 것입니다. 요구사항을 다시 나누거나 오케스트레이터가 직접 판단할 부분을 먼저 처리해야 합니다.
두 번째로 실행 중 동시성과 소유권을 확인합니다. 병렬 에이전트가 같은 파일, 같은 데이터베이스 마이그레이션, 같은 배포 환경을 건드리지 않도록 합니다. 읽기 작업은 겹쳐도 문제가 작지만 쓰기 작업은 명시적인 소유자를 한 명만 둡니다. 공통 인터페이스를 바꾸는 작업은 선행 변경을 먼저 확정한 뒤 후속 작업을 시작해야 불필요한 재작업을 줄일 수 있습니다.
세 번째로 결과의 증거를 확인합니다. 에이전트의 성공 문구만으로 완료를 판정하지 않습니다. 실제 변경 파일 목록, 변경 내용, 테스트 종료 코드, 실패 로그, 생성된 산출물의 경로를 확인합니다. 테스트가 통과했더라도 실행하지 않은 테스트 범위가 무엇인지 기록해야 합니다. 빠른 모델이 요약한 결과는 탐색을 돕는 정보이지 최종 증거가 아닙니다.
네 번째로 비용과 지연의 원인을 분리합니다. 총시간이 줄지 않았다면 모델이 느린 것인지, 작업 분해가 잘못된 것인지, 병합과 검증에서 대기한 것인지 구분합니다. 총사용량이 늘었다면 같은 파일을 여러 에이전트가 반복해서 읽었는지, 부모가 과도한 대화 이력을 전달했는지, 실패한 작업을 동일한 지시로 재시도했는지 살펴봅니다. 원인을 분리하지 않고 더 빠른 모델로 바꾸면 문제를 숨길 뿐입니다.
다섯 번째로 폴백이 실제로 작동하는지 점검합니다. 요청한 자식 모델이 카탈로그에 없거나 추론 강도가 거절될 때 부모 모델 상속으로 안전하게 돌아가는지, 서브에이전트가 중단될 때 미완성 변경이 격리되는지, 검증 실패가 두 번 이어질 때 사람이 확인할 수 있도록 멈추는지 시험합니다. 정상 경로만 테스트한 라우팅 정책은 버전 업데이트나 일시적인 서비스 변화에 취약합니다.
마지막으로 주기적인 회귀 검증을 운영 일정에 포함합니다. Codex 버전이나 모델 설정을 변경할 때 대표 작업 묶음을 다시 실행하고 이전 결과와 비교합니다. 작업 묶음에는 단순 검색, 독립 구현, 교차 파일 수정, 실패 로그 분석처럼 서로 다른 유형을 넣습니다. 평균값만 보지 말고 최악의 지연, 재시도 빈도, 품질 게이트 실패 사례도 함께 봐야 합니다. 이 기록이 쌓이면 어떤 역할에 빠른 모델을 써도 되는지 팀 고유의 근거가 생깁니다.
시범 운영 결과를 공유할 때는 성공 사례만 모으지 않습니다. 라우팅이 오히려 느렸던 작업, 자식 모델이 잘못 이해한 지시, 오케스트레이터가 다시 수행한 작업도 함께 기록합니다. 실패 사례는 역할 경계를 고치는 가장 직접적인 자료이며, 다음 모델 업데이트 뒤에 다시 실행할 회귀 테스트가 됩니다. 기록 형식을 일정하게 유지하면 감상이 아니라 데이터로 정책을 조정할 수 있습니다.
결론: 강한 모델 한 개보다 운영 설계가 먼저다
Codex Multi-Agent v2의 모델 선택 기능은 오케스트레이터와 실행자를 다른 속도와 추론 수준으로 조합할 수 있는 기반을 제공합니다. 공식 구현은 부모 설정 상속을 기본으로 두면서, 지원되는 모델과 추론 강도 안에서 명시적 오버라이드를 허용하고 있습니다. 동시에 버전, 모델 카탈로그, V2 호환성에 따라 실제 노출 범위가 달라질 수 있도록 방어적으로 설계돼 있습니다.
실무에서의 핵심은 어떤 모델이 가장 강한가가 아닙니다. 어떤 작업을 독립적으로 검증할 수 있는가, 실패 영향이 어디까지인가, 자식에게 어떤 컨텍스트와 권한만 줄 것인가, 결과당 총비용과 시간을 어떻게 측정할 것인가가 먼저입니다. 이 네 가지가 준비되면 빠른 모델은 반복 작업을 줄이고 강한 모델은 중요한 판단에 집중할 수 있습니다. 준비되지 않은 상태에서는 에이전트 수만 늘고 검토 비용이 커질 수 있습니다.
따라서 첫 도입은 작은 저장소나 비핵심 작업에서 시작하고, 현재 설치 버전의 실제 도구 스키마를 확인하며, 단일 모델 기준선과 비교해 효과를 측정하는 방식이 좋습니다. 모델 라우팅을 기능 토글이 아니라 지속적으로 검증하는 운영 정책으로 다룰 때 멀티에이전트의 장점을 안정적으로 가져갈 수 있습니다.
참고 자료
'Codex' 카테고리의 다른 글
| Codex MCP output_token_limit 설정과 잘림 원리 (0) | 2026.09.02 |
|---|---|
| Codex GPT-5.4 지원 종료, 8월 31일 무엇을 바꿔야 할까? (0) | 2026.08.31 |
| Codex 0.151.0 업데이트: MCP 도구 결과·플러그인 변화 (0) | 2026.08.31 |
| loveholidays Codex 도입, 코드 변경 79%는 무엇을 뜻하나? (0) | 2026.08.28 |
| Codex 장기 세션 최적화 — 느려지는 구조와 개선 원리 (0) | 2026.08.15 |
