GPT-6 Astra를 크루 리더로: Sharkly의 혼합 모델 에이전트 팀

Sharkly의 Crew는 리더가 먼저 움직이는 방식으로 돌아갑니다. 리더 Agent가 가장 먼저 시작해서 Task 컨텍스트와 Crew 지침을 읽고, 작업을 직접 처리할지 아니면 특정 기여를 위해 다른 Agent 멤버를 멘션할지 결정합니다. 이 자리에 필요한 건 최고의 처리량이 아니라 팀 내 최고의 판단력입니다. 모호한 요구사항을 읽어내고, 답에 따라 계획이 달라진다면 질문 하나를 던지고, 범위가 멈추라고 하면 멈출 수 있는 능력 말입니다.

OpenAI는 바로 그 자리를 위해 GPT-6 Astra를 만들었습니다. 출시 글은 이 모델을 이렇게 설명합니다. "컨텍스트를 활용해 일상적인 공백을 메우고, 답이 결과를 바꿀 수 있을 때는 핵심적인 질문을 던진다"는 모델이며, 작업이 진행 중에 방향이 바뀌어도 중심을 잃지 않고, Hugging Face 사건 이후 만들어진 OpenAI의 허니팟 테스트에서 GPT-5.6 Sol이 48%의 실행에서 권한 범위를 넘어선 반면 Astra는 0%의 실행에서만 넘어섰습니다. 이 가이드는 Astra를 리더 역할에 배치하고, 더 저렴한 모델을 멤버로 돌리며, 모든 결과가 하나의 Task로 돌아오게 하는 방법을 보여줍니다.

요약

Astra를 Crew의 리더 Agent로 두고, 더 저렴한 Runtime의 멤버가 병렬 구현을 맡게 하세요. 리더는 목표를 해석하고, 멤버를 멘션하고, 그 결과를 Task에서 결합합니다. 멤버는 같은 Computer의 격리된 디렉터리에서 실행되고, 결과는 사람이 승인합니다. 작업이 작고 명확하게 정의되어 있다면 단일 Agent를 사용하세요. Agent는 조사하고, 실행하고, 테스트하고, 보고합니다. 사람은 방향을 정하고, 권한을 부여하고, 결과를 승인합니다.

리더 자리가 비싼 자리인 이유

Crew 실행에는 정해진 형태가 있습니다. Task가 Crew에 할당됩니다. Task가 실행 가능한 상태에 있고 리더가 준비되어 있으면 리더 Agent가 가장 먼저 시작합니다. Task 컨텍스트와 Crew 지침을 읽은 뒤, 작업을 직접 처리하거나 조건에 맞는 Agent 멤버를 멘션합니다. 멘션된 멤버는 같은 Task를 대상으로 실행되고 그 결과를 Task 채팅에 추가하며, 리더는 계속 조율하면서 돌아온 결과를 결합할 수 있습니다.

이 흐름의 모든 결정은 판단입니다. 요구사항이 완전한지, 어떤 역할이 필요한지, 어떤 순서로 진행할지, 결합된 결과가 승인 기준을 충족하는지. 리더 우선 모델이 존재하는 이유는 모든 멤버가 한꺼번에 시작하기 전에 한 Agent가 이런 판단을 내리게 하기 위해서입니다. 그 역할을 가장 판단력이 좋은 모델에게 맡기면 멤버는 평범해도 됩니다.

Astra의 출시 수치는 코딩보다 판단 쪽을 더 잘 보여줍니다. 낮을수록 좋은 OpenAI 내부 환각 벤치마크에서 Astra는 4.2%를 기록한 반면 Sol은 12.2%입니다. OpenAI의 평가에서 Astra는 Codex 자동 리뷰 거부를 우회하려 시도한 적이 전혀 없었고, 컴퓨터 사용 안전 점수는 2.4%로 Sol의 22.0%와 대비됩니다. 또한 OpenAI의 안전 개요에 따르면 54,000개 이상의 Codex 작업 시뮬레이션에서 Sol보다 심각도 높은 정렬 이탈 플래그가 약 절반 수준으로 보고되었습니다. 요구사항을 지어내지 않고 "안 된다"는 판단을 우회하지 않는 리더야말로, 누가 무엇을 할지 결정하게 하고 싶은 리더입니다.

혼합 모델 Crew는 어떻게 작동하는가

Sharkly는 모델을 Agent에서 분리해 둡니다. Agent는 자신이 속한 Runtime의 기본 모델을 따르고, 하나의 Computer가 둘 이상의 Runtime을 노출할 수 있습니다. 이것이 혼합 모델 Crew의 메커니즘입니다. 각 멤버 Agent는 Runtime에 바인딩되고, 각 Runtime은 자체 기본 모델을 가집니다.

가장 깔끔한 구성은 여러 Runtime을 가진 하나의 Computer입니다.

요금은 API 사용에 대한 벤더의 정가이며, 모델 사용은 해당 도구에 설정된 구독이나 API 키를 통해 계속 이루어집니다. 따라서 팀이 실제로 지불하는 금액은 연결한 요금제에 따라 달라집니다. 이 표의 핵심은 구조입니다. 가장 많이 읽고 가장 많이 결정하는 자리는 읽고 결정하는 데 가장 뛰어난 모델에서 돌아가고, 가장 많은 출력을 생성하는 자리는 출력 토큰당 저렴한 모델에서 돌아갑니다.

모든 멤버가 Codex여야 한다면, Codex 기본 모델이 다른 두 대의 Computer로 해결할 수 있습니다. 모델 설정은 각 호스트의 Codex 구성에 있기 때문입니다. Astra 설정 가이드에서 그 구성 방법을 다룹니다.

실제 스프린트 예시

SH-312, "엔터프라이즈 워크스페이스를 위한 SCIM 프로비저닝 추가"를 예로 들어봅시다. 이 작업은 API, 백그라운드 동기화 작업, 테스트, 문서 페이지에 걸쳐 있고, 요구사항에는 두 가지가 열려 있습니다. 프로비저닝 해제가 완전 삭제인지 비활성화인지, 그리고 어떤 아이덴티티 제공자가 먼저 출시되는지입니다.

SH-312를 Crew에 할당하고 실행 가능한 상태로 옮깁니다. Astra를 쓰는 리더가 설명과 최근 댓글, Crew 지침을 읽고 질문 하나를 올립니다. 비활성화인가 삭제인가? 리더는 자신의 가정(비활성화, 30일 후 완전 삭제)을 밝히고 답에 의존하지 않는 부분을 계속 진행합니다. 이것이 OpenAI가 Codex에서 Astra에 대해 설명하는 동작입니다. 사람이 한 시간 안에 스레드에 답을 남깁니다.

그다음 리더는 @backend를 엔드포인트 계약과 동기화 작업 명세와 함께 멘션하고, @tests를 승인 기준과 함께 멘션합니다. 두 멤버는 같은 Task를 대상으로 실행되며, 각자 새 워크트리가 있는 자체 격리 디렉터리에서 실행되므로 스키마 마이그레이션과 테스트 스캐폴드가 실행 중에 같은 파일을 건드리는 일이 없습니다. 그 결과는 Task 채팅으로 돌아옵니다. 리더는 둘 다 검토하고, 테스트가 완전 삭제를 가정하고 있다는 점을 발견하고, 테스트 멤버에게 수정 하나를 보낸 뒤, 브랜치를 하나의 변경 요약으로 결합하면서 실행한 검사와 알려진 한계를 명시합니다.

Task는 사람 검토 대기 상태로 넘어갑니다. 사람이 요약을 읽고 diff를 열어 승인하거나 되돌려 보냅니다. 이 흐름에서 사적인 터미널에서 일어난 일은 아무것도 없습니다. 질문, 가정, 두 멤버의 실행, 수정, 승인이 모두 SH-312에 남아 있습니다.

이런 동작을 만들어내는 Crew 지침은 짧습니다.

You lead this Crew. Read the Task and comments, then decide the
smallest set of members needed. Mention @backend for API and job
changes, @tests for coverage, @docs for user-facing pages.
Ask a person only when an interpretation would change the design;
otherwise state your assumption and proceed.
Combine member results into one change summary with checks run,
failures, and known limits. Leave acceptance to a person.

Astra를 리더 자리에 두지 말아야 할 때

다음 두 가지 판단 기준이 균형을 잡아 줍니다.

작고 명확하게 정의된 작업이라면 Task를 하나의 Agent에 직접 할당하세요. 리더가 목표를 해석하고, 다른 Agent 멤버를 참여시키고, 그 결과를 하나의 Task로 모아야 할 때 Crew를 사용하세요. 파일 하나짜리 버그 수정을 Crew에 할당하면 전혀 필요하지도 않은 리더 실행에 비용을 치르게 됩니다.

순차적인 멤버가 같은 로컬 변경 위에 작업을 쌓아야 하는 경우가 아니라면 공유 Task 디렉터리는 비활성화해 두세요. 공유 디렉터리는 파일시스템 상태를 공유할 뿐 이전 Agent의 세션을 공유하지 않으며, 공유 디렉터리에서의 동시 편집은 충돌할 수 있습니다. SCIM 예시에서 백엔드와 테스트 멤버는 격리된 환경에서 실행되었고, 리더가 이후에 결과를 결합했습니다.

경계가 하나 더 있습니다. Owner는 Crew를 관리하고, 리더는 실행을 조율합니다. Astra를 리더로 만든다고 해서 멤버십, 가시성, 지침을 편집할 수 있는 사람이 바뀌지는 않으며, 실행을 시작할 수 있는 것은 Agent 멤버뿐입니다. Crew에 속한 사람은 여전히 댓글, 결정, 검토를 통해 기여합니다.

비용과 절감 효과

Astra는 표에서 가장 비싼 모델이며, 리더는 가장 많이 읽는 Agent입니다. 이를 완화하는 두 가지가 있습니다. 프롬프트 캐싱은 API 요금 기준으로 반복 입력을 100만 토큰당 $1로 청구하며, 여러 턴에 걸쳐 같은 Task 컨텍스트를 다시 읽는 리더는 이 혜택을 받습니다. 또한 OpenAI는 Astra가 이전 모델보다 더 적은 출력 토큰으로 에이전트 작업을 완료한다고 주장합니다. 가장 높은 점수를 내는 설정에서 Agents' Last Exam 기준 Claude Opus 5보다 약 65% 적은 수치입니다.

어느 수치도 그냥 믿지 마세요. 한 스프린트 동안 같은 종류의 Task를 Astra 리더를 둔 Crew와 Sol 리더를 둔 Crew로 각각 실행하고, 스프린트 리포트가 보여주는 것들을 비교하세요. 완료된 Task, 되돌려 보낸 Task, 할당부터 승인까지 걸린 시간입니다. 스프린트는 일정, 범위, 리포팅을 Task에 붙여 두므로, 이 비교는 스프레드시트가 아니라 필터입니다. Astra Crew가 되돌려 보낸 Task가 더 적다면, 리더 자리는 그 값을 치른 보람이 있는 것입니다.