GPT-6 아스트라를 오케스트레이터로 쓰면 안 되는 이유와 되는 조건

GPT-6 아스트라가 9월 4일 일반 공개된 뒤, 클로드코드와 Codex를 함께 쓰는 사람들 사이에서 같은 질문이 반복된다. 가장 비싼 모델을 총괄 자리에 앉히고 싼 모델에게 손발을 시키는 게 맞는가, 아니면 아스트라는 페이블 5.1 아래 서브에이전트로 내려보내야 하는가. 이 기사는 두 배치가 실제로 어떻게 설정되고 어디서 한도와 시간이 새는지를 공개 문서와 실사용 기록으로 따진다.

하루 사이에 뒤집힌 방의 평가

클코단에서 이 화제는 질문 하나로 시작했다. 아스트라를 오케스트레이터로 두고 루나·솔을 서브에이전트로 붙여 쓰는 사람이 있느냐는 것이었다. 곧 한 참가자가 자기 방식을 소개했다. 큰 설계는 아스트라를 최고 추론 강도로 돌려 잡고, 나머지 모듈 구현은 솔을 high 강도로 돌린다는 구성이었다.

저녁이 되자 반대 평가가 나왔다. 아스트라는 총괄 자리에 맞지 않으니 페이블 밑에서 서브 역할이나 맡기라는 의견이었다. 바깥의 실사용 기록을 보면 이 두 평가는 조건이 다를 뿐 둘 다 근거가 있다.

아스트라를 위에 두는 사람들은 실제로 이렇게 짠다

Codex CLI는 config.toml의 [agents] 블록에서 서브에이전트 기본 모델과 추론 강도를 정한다. default_subagent_model과 default_subagent_reasoning_effort가 그 키다. 역할별 TOML 파일에 model과 model_reasoning_effort를 적으면 그 역할만 따로 고정된다. ChatGPT 공식 서브에이전트 문서가 이 우선순위를 명시한다.

공개 저장소 codex-astra-luna-orchestrator가 이 구조를 그대로 쓴 예다. Pro 플랜 프로필은 루트를 gpt-6-astra medium으로, explorer·worker·tester·researcher 네 역할을 gpt-5.6-luna max로 고정한다. 리뷰어만 아스트라 low로 따로 둔다. 설치는 저장소를 클론해 setup.sh를 실행하고 대상 저장소 경로와 플랜을 고르면 .codex 설정과 AGENTS.md가 복사된다.

같은 저장소의 Plus 프로필은 루트마저 루나 max로 바꾼다. 루트 스레드가 작업 내내 살아 있어 가장 큰 비용 항목이라는 게 README의 설명이다.

Claude Code 안에서 아스트라를 총괄로 쓰는 길도 있다. Eigenwise Toolshed 마켓플레이스의 model-gateway 플러그인이 로컬 프록시로 ChatGPT 로그인을 OpenAI 쪽에 넘기고, 나머지 요청은 앤트로픽으로 흘린다. 모델 ID 앞에 claude- 접두어가 있어야 Claude Code가 인식하고, 뒤에 [1m]을 붙여야 20만 토큰에서 압축하지 않는다. 플러그인 제작자는 사흘 써 본 뒤 아스트라가 자기가 앉혀 본 총괄 중 가장 낫다고 썼다. 일을 직접 떠안지 않고 끝까지 위임하더라는 이유다.

총괄 자리의 아스트라가 한도를 태우는 방식

반대편 기록도 구체적이다. 한 개발자는 솔로 잘 돌던 AGENTS.md 기반 오케스트레이션에 아스트라를 얹고 잠들었다가, 주간 한도 초기화 직후 반나절도 안 돼 100%가 소진된 것을 봤다. 추론 강도를 낮춰 두 번 다시 돌렸지만 결과는 비슷했다. 세션을 들여다보니 아스트라가 하위 모델에 맡겨야 할 일을 전부 자기 것으로 끌어올렸고, 하위 에이전트 완료 확인을 LLM 호출로 잦게 반복해 컨텍스트 압축까지 강제하고 있었다.

이 개발자가 재구성한 배치는 이렇다. 총괄은 솔 high, 단계 관리자는 솔 medium, 실무는 루나·테라·솔, 리뷰어는 대화를 물려받지 않은 새 솔 medium이다. 아스트라는 본선에서 빼고 설계 충돌이나 스키마 변경 같은 예외 자문역으로만 남겼다. 서브에이전트 대기 시간은 min_wait_timeout_ms를 120000으로 올렸다.

Kilo 팀의 프로덕션 프리뷰 후기도 방향이 같다. 아스트라는 에이전트 무리를 조율하는 능력이 매우 좋았고 어려운 문제의 품질도 혼자 풀 때보다 크게 올랐지만, 국소 수정을 요청하면 거대한 PR로 돌아오는 과설계 편향이 있었다. 밤새 한 번에 약 2,000단계를 돌린 사례도 적었다.

오픈AI 문서가 이 성향의 배경을 설명한다. 아스트라는 AGENTS.md 같은 파일의 지시에 이전 모델보다 민감하고, 입력이 결과를 바꿀 만하면 사용자에게 질문하려고 멈추는 경향이 있다. openai/codex 저장소에는 아스트라가 정해진 범위의 작업을 끝내지 못하고 수리와 재계획을 반복한다는 이슈도 올라와 있다.

"아스트라 max로 계획, 솔 high로 실행"의 비용 계산

방에서 모범사례로 소개된 조합은 계획 단계에 최고 강도를 쓴다. 이 선택이 값어치를 하는지는 Artificial Analysis의 강도별 실측이 답한다. 아스트라의 작업당 비용은 low 0.63달러에서 medium 1.16달러, high 1.41달러, xhigh 1.85달러, max 2.57달러로 오르는데, 지능 지수는 49에서 55까지만 움직인다. low에서 medium으로 가는 한 칸이 가장 크고, 그 위는 한 칸에 1점씩이다.

오픈AI의 이전 가이드는 다른 모델에서 옮겨올 때 기존 강도를 유지하라고만 말한다. 써본 사람들 사이에선 medium을 기본으로 두고 실패한 작업만 올리라는 반응이 많다.

솔 high 쪽은 실사용 근거가 하나 있다. 앞서 본 재구성 사례에서 총괄을 솔 medium으로 두었을 때 백로그 조회 건수가 지시와 달라도 그냥 진행하는 사고가 났고, high로 올리자 다시 조회하고 의존성을 확인해 순서를 고쳤다. 그 개발자는 high를 총괄 자리에만 쓴다.

페이블 밑에 아스트라를 두면 무엇이 달라지나

Claude Code 서브에이전트는 .claude/agents/ 아래 마크다운 파일의 model 필드로 모델을 고른다. 공식 문서 기준 별칭은 sonnet·opus·haiku·fable이고 전체 모델 ID도 받는다. 서브에이전트 전체 기본값은 settings.json의 CLAUDE_CODE_SUBAGENT_MODEL로 정한다. 다만 프론트매터 model 필드가 무시되고 부모 모델을 물려받는다는 버그 리포트가 4월에 올라와 있으니 한 번 실행해 확인해야 한다.

페이블 5.1을 총괄로 세우는 데는 한도 계산이 따라온다. Max 플랜에서 페이블은 주간 한도의 50%까지만 쓸 수 있고, /usage에 전체 한도와 페이블 한도가 따로 표시된다. Claude Code 기본 강도는 high다. Artificial Analysis는 페이블 5.1이 max 강도에서 이전 세대보다 출력 토큰을 약 1.7배 쓴다고 측정했다. 총괄 자리에서 max를 고르면 그 비용을 그대로 낸다.

아스트라를 이 밑에 넣으려면 앞서 본 model-gateway 같은 프록시가 필요하다. 그 제작자의 로그에서는 총괄인 아스트라 요청이 4,492건, GPT-5.6 계열 실무 요청이 16,207건이었다. 리뷰어는 다른 모델 가족인 Opus에 맡겼는데, 작성자와 같은 맹점을 공유하지 않는다는 이유였다.

벤치마크는 어느 쪽 총괄이 옳은지 판정해 주지 않는다. Terminal-Bench 4.0에서는 오픈AI 보고 기준 아스트라 57.7%, 페이블 5.1 55.8%다. Artificial Analysis의 Coding Agent Index는 Claude Code 위의 페이블 5.1이 70, 아스트라가 67이다. 두 모델의 API 단가는 입력 100만 토큰 10달러, 출력 50달러로 같고, 캐시 읽기만 페이블 0.25달러, 아스트라 1달러로 갈린다.

방의 저녁 결론인 "페이블 밑 서브"는 바깥 기록에서 두 형태로 나타난다. 리뷰어 자리에 low 강도로 두거나, 설계 충돌 때만 부르는 자문역으로 두는 방식이다. 남는 질문은 하나다. 멈춰서 묻고, 지시를 지나치게 지키고, 일을 스스로 끌어안는 아스트라의 성향이 총괄의 결함인지, 아니면 위임 규칙을 아직 아스트라에 맞게 다시 쓰지 않은 사용자 쪽 문제인지다.