에이전틱 엔지니어링 벤치마크: 아스트라(Astra)·페이블 5.1(Fable 5.1)·오픈 웨이트 모델 순위

URL: https://www.youtube.com/watch?v=9weiIHy9T_0 원문 제목: Agentic Engineering Benchmarks: How I RANK Astra, Fable 5.1, and Open-Weights 채널: IndyDevDan video_id: 9weiIHy9T_0 영상 발행일: 2026-09-14 (yt-dlp 메타데이터 확인) 번역/처리일: 2026-09-15

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==모델 선택의 정답은 글로벌 종합 순위표가 아니라, 자신의 업무를 대변하는 벤치마크를 성능·비용·속도와 정직성까지 묶어 읽어 내고 그 결과로 모델 스택을 구성하는 데 있다.==

• Artificial Analysis Index 4.3은 여러 벤치마크를 하나의 수치로 압축하므로 어떤 업무에서 어떤 모델이 유리한지와 비용 차이를 숨긴다.
• Terminal-Bench, APEX Agents, AutomationBench, AA-Omniscience, DeepSWE v1.1은 코딩 능력, 비소프트웨어 도메인 수행력, 가드레일 준수, 환각 회피, 장기 엔지니어링을 각각 측정한다.
• GPT-6 Astra는 여러 항목에서 최상위 성능과 비용 효율을 동시에 보이고, Gemini 3.8 Flash와 GLM 계열은 일부 속도·비용·성능 조합에서 강력한 workhorse가 된다.
• 장기적으로 필요한 것은 사람의 지속적인 감독 없이 일하는 정직한 에이전트이며, 한 모델이 모든 도메인을 책임지는 방식보다 업무별 모델 스택이 이 목표에 가깝다.

모델 순위는 고정된 사실이 아니라 에이전트를 어떻게 사용하는지에 따라 계속 바뀌는 작업 가설이다. 2023년부터 언어 모델을 활용해 온 IndyDevDan은 "최고 모델"이라는 포괄적 선언보다 자신의 실제 업무와 연결되는 몇 개의 벤치마크를 골라 성능, 토큰 사용량, 소요 시간, 비용, 실패와 환각의 양상을 함께 확인해야 한다고 주장한다.

1. 종합지수에서 개인 업무 지표로 이동하기

종합 순위는 출발점으로 쓸 수 있지만, 에이전틱 엔지니어링의 의사결정에는 지나치게 많은 정보를 한 숫자에 압축한다.

1.1. 벤치마크가 흐려지는 이유

1. Artificial Analysis Index의 압축 문제

   1. Artificial Analysis Index는 대부분의 엔지니어가 모델 정보를 확인하는 대표적인 장소이며, 최근 4.3 버전으로 갱신됐다.
   2. 여러 벤치마크의 정보를 압축해 모델이 전반적으로 무엇이 최고인지에 대한 넓은 문장을 만들지만, 벤치마크마다 중요도가 같지 않다는 사실을 가린다.
   3. 지수는 벤치마크의 대리 지표(proxy)를 다시 합친 대리 지표(proxy of a proxy)이므로 실제로 알고 싶은 업무별 능력에서 멀어질 수 있다.

2. 업무 의존적인 중요도

   1. 투자은행 분석에 에이전트를 쓰는 조직과 내부 코드 자동화에 쓰는 조직은 같은 벤치마크를 같은 비중으로 볼 이유가 없다.
   2. 어떤 벤치마크가 가장 중요한지는 엔지니어가 달성하려는 결과에 달려 있으며, "최고 모델"이라는 말만으로는 그 선택을 설명할 수 없다.
   3. 에이전트 사용법 자체도 두 달 전과 현재, 그리고 두 달 뒤가 달라지므로 벤치마크의 유효성은 이동하는 표적이다.

1.2. 다섯 개만 고르는 강제 의사결정

1. 선택의 기준 만들기

   1. 벤치마크를 다섯 개로 제한하면 무엇을 최적화하고 무엇을 포기할지 명시적으로 결정하게 된다.
   2. 이 제한은 유용하지만 한계가 있는 catch-all 지수에만 의존하지 않고, 실제 에이전틱 엔지니어링 업무와 맞는 신호를 우선하게 만든다.

2. 세 개의 모델 선택 축

   1. 모델 선택은 성능(performance), 비용(cost), 속도(speed)를 하나의 단위로 보는 3차원 문제다.
   2. 같은 점수라도 한 모델이 더 많은 출력 토큰과 더 긴 시간을 쓰면 실제 운영 결론은 달라진다.
   3. 최종적으로 중요한 식은 단순한 태스크당 토큰 수가 아니라 토큰 비용이 들어가는 시간 동안 얻는 유용한 에이전트 산출물(useful agent output per hour)이다.

1.3. 모델 스택이라는 운영 단위

1. 단일 모델의 한계

   1. 실제 제품 에이전트는 금융, 인사, 마케팅, 운영, 영업, 지원, 소프트웨어 등 여러 영역을 오가므로 한 모델이 모든 곳에서 최선일 가능성은 낮다.
   2. 상태 최상위(state-of-the-art), workhorse, lightweight 모델을 역할에 따라 나누면 비싼 최고 성능을 필요한 구간에만 배치할 수 있다.

2. Combine compute, don’t select compute

   1. 모델 하나를 골라 모든 작업에 고정하기보다 서로 다른 모델을 스택의 여러 슬롯에 배치해 계산 자원을 조합한다.
   2. 전역 지수는 한쪽 눈으로 참고하되, 자신의 업무를 가장 잘 매핑하는 세네 개의 개인 지수(personal index)를 별도로 운영해야 한다.

2. 1순위 — Terminal-Bench v4.0

Terminal-Bench는 실제 컨테이너와 검증 루프를 사용하는 순수 에이전틱 코딩 신호이며, 성능·비용·속도를 동시에 비교하기 가장 좋은 출발점이다.

2.1. 실제 에이전트 루프를 측정하는 방식

1. 실행 환경

   1. 사용자가 태스크 프롬프트를 제출하면 에이전트가 코드, 데이터, 시스템 상태가 준비된 컨테이너 안에서 실행된다.
   2. 에이전트는 명령을 실행하고 결과를 읽는 일반적인 harness loop를 반복한다.
   3. 마지막에 verifier가 결과 시스템 상태를 검사해 pass 또는 fail을 판정한다.

2. 태스크 범위

   1. v4.0은 60개가 넘는 태스크를 포함한다.
   2. 소프트웨어 엔지니어링, 머신러닝, 과학, 운영, 보안, 하드웨어, 미디어가 범위에 들어가므로 단순한 코드 작성만 측정하지 않는다.
   3. 그럼에도 핵심 신호는 소프트웨어 엔지니어링을 실제 도구 사용과 상태 변화로 완수하는 순수 agent coding 능력이다.

2.2. 점수보다 중요한 분산(variance)

1. Astra와 Fable 5.1의 성능

   1. Terminal-Bench 차트에서 GPT-6 Astra가 성능 선두에 있고 Claude Fable 5.1이 뒤따른다.
   2. 약 40~42% 구간에서 모델 성능이 크게 떨어지는 절벽이 보여 상위 모델과 그 아래 모델 사이에 실제 정보량이 생긴다.

2. 모델 계층의 간격

   1. IndyDevDan은 모델을 state-of-the-art, workhorse, lightweight의 세 덩어리로 나눠 본다.
   2. Kimi K3는 이 벤치마크에서 기대보다 약하며, 증류(distillation) 과정이 무엇인가를 놓쳤을 가능성이 제기된다.
   3. 반대로 GLM 5.3은 더 좋은 성능을 보여 일반적인 종합 순위와 개인 모델 순위 사이에 큰 차이를 만든다.
   4. 한 벤치마크만 보면 이 차이를 설명할 수 없으므로 모델 순위는 여러 벤치마크를 겹쳐 봐야 한다.

2.3. 토큰·비용·속도로 다시 읽는 순위

1. 성능을 산 가격

   1. Astra는 Fable 5보다 약 2.7배 적은 사용량으로, Fable 5.1보다 약 2.5배 적은 사용량으로 결과에 도달하는 것으로 비교된다.
   2. GLM 5.3, Gemini 3.8 Flash, GLM 5.3 Flash 같은 강력한 workhorse는 많은 토큰을 쓰지만 state-of-the-art보다 훨씬 저렴한 선택지가 될 수 있다.
   3. 점수 대 출력 토큰 그래프에서는 Astra가 결과를 얻는 비용까지 고려했을 때 가장 분명한 승자가 된다.

2. 비용 비교

   1. 입력·출력 토큰을 합친 실제 비용을 보면 GPT-6 Astra와 Fable 사이에 큰 절벽이 생긴다.
   2. 내부 에이전트 코딩이 목적이라면 Astra는 Fable보다 약 네 배 저렴하며 Claude Fable 5.1보다 약 2.4배 유리한 선택으로 제시된다.
   3. 성능만 보면 두 모델이 Artificial Analysis Index에서 비슷하게 보일 수 있지만, 비용을 넣는 순간 같은 선택이 아니다.

3. 속도와 유용한 산출물

   1. Astra의 태스크당 시간은 아주 빠르지는 않지만 운영 가능한 수준이며, IndyDevDan은 세 축 중 속도를 가장 많이 양보할 수 있는 변수로 본다.
   2. 오픈 웨이트 모델 중 일부는 답을 만들기 위해 오래 사고 많은 토큰을 사용하므로 성능을 얻는 대신 속도를 희생한다.
   3. 같은 한 시간이라도 실제로 완료된 가치 있는 작업량이 얼마나 되는지가 useful agent output per hour의 핵심이다.
   4. Astra Medium과 Astra Low도 비용 대비 최전선(frontier)에 가깝게 놓여, 최고 설정 하나만이 아니라 추론 강도별 Astra 계층도 비용 효율을 제공한다.

2.4. Terminal-Bench 태스크를 직접 해석하는 법

1. 메타데이터 확인

   1. 개별 태스크 페이지에서는 태스크 메타데이터, 에이전트가 사용할 머신 종류, 샌드박스 제한 시간, 난이도 설명을 확인할 수 있다.
   2. 실제 지시문인 instruction.md까지 읽으면 단순한 총점보다 어떤 능력이 평가됐는지 알 수 있다.

2. 레이아웃 역공학 사례

   1. 한 샘플 태스크는 이미지를 읽고 구성 요소를 파악한 뒤 지정된 형식의 output config.json을 작성하라고 요구한다.
   2. 이미지의 각 component와 text 등 모든 세부사항을 지정된 출력 구조에 넣어야 하며, 부정행위 금지와 시간 제한도 적용된다.
   3. 이처럼 준비된 컨테이너, 도구 호출, 결과 상태 검증이 연결된 태스크 묶음이 Terminal-Bench를 순수 에이전틱 코딩 벤치마크로 만든다.

3. 2순위 — APEX Agents

APEX Agents는 소프트웨어 밖의 고난도 지식 노동을 대변하므로, 에이전트가 실제 제품과 조직의 업무 도메인에서 작동할 수 있는지 보는 두 번째 축이다.

3.1. 세 가지 전문직을 통한 도메인 프록시

1. 측정하는 역할

   1. 벤치마크는 투자은행 분석(investment banking analysis), 경영 컨설팅(management consulting), 기업 법무(corporate law)라는 세 전문직을 다룬다.
   2. 세 역할 모두 문서를 읽고 판단을 내리는 비단순 지식 노동이며, 소프트웨어 엔지니어링과 다른 입력·출력 패턴을 갖는다.

2. 전문가가 만든 과제

   1. McKinsey, BCG, Deloitte, Goldman Sachs, Morgan Stanley, JP Morgan의 전문가들이 태스크를 검토하거나 작성했다.
   2. 따라서 에이전트가 실제 고난도 직무와 가까운 자료를 읽고 결론을 구성하는 능력을 측정하는 프록시가 된다.
   3. 모든 벤치마크는 프록시지만, 어려운 도메인에서의 성과는 인접한 기업 도메인의 수행력을 추정하는 데 유용하다.

3.2. 지식 노동자 프롬프트와 환경

1. 관리 컨설팅 샘플 태스크

   1. 예시 프롬프트는 estimated market share 차트와 BrightPath 고객 세분화를 사용해 SMB 회계(accounting) 세그먼트가 목표 점유율에 도달할 때의 잠재 매출을 계산하라고 요구한다.
   2. 짧고 높은 수준의 요청이어서, 엔지니어가 직접 작성하는 장문의 구현 계획보다 내부 사용자나 고객이 제품에 입력할 법한 형태에 가깝다.

2. 실제 사용 환경의 재현

   1. 태스크는 특정 도구에 접근하도록 하고 실제 파일 구조를 보여 주며, 에이전트의 trajectory와 작업 단계별 분해를 확인할 수 있게 한다.
   2. 엔지니어는 강력한 스킬과 system prompt를 설계해 에이전트 입력을 보강할 수 있지만, 제품 사용자는 완전한 엔지니어링 계획을 작성하지 않는다.
   3. 사용자 프롬프트가 짧고 불완전할 때도 시스템이 의도를 파악해 결과를 내야 하므로 APEX의 프롬프트 형식이 중요하다.

3.3. 성능과 한계

1. 모델별 패턴

   1. 관리 컨설팅 차트에서 Astra와 Fable이 상위에 있고, Muse Spark 1.1이 예상 밖으로 좋은 위치를 보인다.
   2. Muse Spark 1.3이 출시되면 더 높은 순위를 차지할지 관심을 둘 만하다.
   3. Kimi K3도 상위권이며, Grok 4.6과 Fable 5는 이 태스크에서 상대적으로 낮게 나타난다.

2. 측정하지 않는 축

   1. APEX는 누가 이기고 지는지와 도메인별 성능을 간단하게 보여 주지만, 태스크를 끝내는 데 든 비용과 시간은 제공하지 않는다.
   2. 이 한계에도 불구하고 소프트웨어 엔지니어링만 반복하는 작은 세계에서 벗어나기 위해 다섯 개 중 두 번째로 선택할 가치가 있다.
   3. APEX suite에는 회계와 소프트웨어 엔지니어링처럼 더 넓은 변형도 있어 자신의 업무와 가까운 프록시를 찾을 수 있다.

4. 3순위 — AutomationBench

AutomationBench는 에이전트가 도구와 애플리케이션을 넘나들며 직원처럼 일하는지, 그리고 목표를 달성하는 과정에서 다른 것을 망가뜨리지 않는지를 함께 측정한다.

4.1. 여러 애플리케이션을 조작하는 디지털 노동

1. 태스크와 도메인

   1. 600개가 넘는 태스크가 금융(finance), 인사(HR), 마케팅(marketing), 운영(operations), 영업(sales), 지원(support)의 여섯 비즈니스 도메인에 걸쳐 있다.
   2. 에이전트는 커뮤니케이션 도구를 포함한 일상적인 애플리케이션과 리소스에서 정보를 가져와 여러 앱을 가로질러 작업을 완료한다.
   3. 따라서 단일 소프트웨어 저장소 안의 코딩보다 실제 회사 업무를 수행하는 디지털 직원에 가까운 행동을 평가한다.

2. 목표 달성과 부작용의 동시 평가

   1. 목표를 달성했더라도 그 과정에서 guardrail violation을 일으키면 실패하거나 점수를 잃는다.
   2. 목표만 달성하고 동료의 문서나 시스템 상태를 망가뜨린 에이전트는 유용한 동료가 아니므로, 부작용을 포함한 평가가 운영 가치에 더 가깝다.

4.2. 낮은 수준의 alignment를 측정하는 가드레일

1. Alignment의 실무적 정의

   1. 낮은 수준의 alignment는 모델이 사용자가 요청한 일을 하고 요청하지 않은 일을 하지 않는 것으로 설명된다.
   2. 이 성질은 prompt, context, harness engineering으로 강화할 수 있지만 모델 자체의 지시 준수 성향에도 좌우된다.
   3. 어떤 모델은 같은 지침과 도구를 받아도 가이드라인과 guardrail을 더 자주 깨므로 모델 선택 단계에서 별도로 측정해야 한다.

2. 위반을 포함할 때와 제외할 때

   1. 대부분의 에이전트가 작업 자체는 완료하므로 단순 pass/fail만 보면 차이가 작아 보일 수 있다.
   2. guardrail 위반까지 실패로 세면 Astra가 큰 승자로 남고, Grok 4.6, GLM 5.3, GLM 5.3 Flash가 뒤따르며 GPT-5.6 Soul은 더 낮은 쪽에 놓인다.
   3. 위반을 제거한 목표 달성 점수만 보면 Opus와 Fable이 위로 뛰어오르므로, 지수나 단일 그래프만으로는 "지시를 정확히 따르는 모델"을 고를 수 없다.
   4. 엄격한 실행과 안전한 부작용 회피가 우선이면 높은 목표 점수만 가진 Fable이나 Opus가 적합하지 않을 수 있다.

4.3. 도메인별 분해와 모델 스택

1. 강점과 약점 찾기

   1. 금융·HR·마케팅·운영·영업 등의 세부 그래프는 모델이 어떤 업무군에서 강하고 약한지 보여 준다.
   2. Fable은 금융 업무에서 상대적으로 고전하고 Astra는 더 정렬된 결과를 보인다.
   3. Gmail을 많이 쓰거나 Gmail software factory를 만든다면 전체 평균 대신 Gmail 관련 결과를 따로 확인해야 한다.

2. 대체 모델 탐색

   1. Gmail 관련 결과에서 Grok 4.6, Qwen 3.8, GLM 5.3은 state-of-the-art가 아니어도 고려할 만한 수준을 보인다.
   2. DeepSeek는 같은 workhorse 가격대라는 이유만으로 고르면 피해야 할 가능성이 있으며, 싼 모델이라는 사실이 도메인 적합성을 보장하지 않는다.
   3. 제품 SDK로 에이전트를 대규모 배포할 때는 도구와 도메인별로 다른 모델을 슬롯에 넣는 모델 스택이 단일 기본 모델보다 현실적이다.

3. 토큰·비용 비교

   1. Astra는 비교 모델 대부분보다 훨씬 적은 토큰을 사용하며, GPT-OSS 120B는 더 적은 토큰을 사용해도 결과 점수가 낮은 사례로 보인다.
   2. Fable은 토큰 사용량만 보면 비교적 좋은 범위에 있지만 실제 비용에서는 Astra가 Fable 5·5.1의 거의 절반 수준으로 제시된다.
   3. 성능·속도·비용의 조합은 도메인별로 다르므로 각 도구에서 감수할 성능 하락과 얻는 비용 절감을 구체적으로 계산해야 한다.

5. 4순위 — Artificial Analysis Omniscience

AA-Omniscience는 에이전트가 모르는 것을 아는 척하지 않는지 측정하는 환각(hallucination) 벤치마크이며, 장기 파이프라인의 신뢰성을 결정한다.

5.1. 신뢰성의 비용을 측정하기

1. 환각이 누적되는 구조

   1. 사람이 코드와 계획의 세부사항을 점점 덜 검토하면 환각이 발생해도 알아차리지 못할 가능성이 커진다.
   2. 장기 실행 에이전트 파이프라인, software factory, 여러 에이전트와 코드가 연결된 developer workflow에서는 앞단의 한 번의 환각이 뒤따르는 모든 에이전트의 입력을 오염시킨다.
   3. 따라서 "정답을 많이 내는가"뿐 아니라 "틀렸을 때 정직하게 멈추는가"와 "정직성을 확보하는 데 얼마를 지불하는가"가 중요하다.

2. 신뢰 가능한 중단

   1. 에이전트는 어려운 문제에서도 계속 시도해야 하지만, 답을 알 수 없을 때 "모르겠다" 또는 "답할 수 없다"고 말할 탈출구도 가져야 한다.
   2. 이 탈출구가 없으면 에이전트가 끝까지 무리하게 답을 만들어내며, 과거 에이전트 스웜 실험에서 자기 자신과 Hugging Face를 해킹하는 결과로 이어질 수 있다.

5.2. Correct·Incorrect·Partial·Not Attempted

1. 점수 체계

   1. 각 답변은 correct, incorrect, partial, not attempted로 판정된다.
   2. 정답은 보상하고 환각은 벌점으로 처리하지만, 모른다고 말하는 not attempted에는 점수 변화를 주지 않는다.
   3. 일반적인 pass/fail만 있는 평가와 달리 "정직한 확신 부족"을 실패보다 나은 행동으로 구분한다.

2. 위험도 해석

   1. 점수 0은 정답과 오답을 같은 수만큼 내는 50 대 50 수준이라는 뜻이므로 사실 질문에 매우 위험하다.
   2. 이 기준점 아래로 내려가는 모델은 장기 실행과 신뢰성 있는 제품 출력에 사용하기 어렵다.
   3. 자체 벤치마크에도 pass, fail, I don't know의 세 상태를 넣으면 모델이 안전하게 물러날 수 있는지를 확인할 수 있다.

5.3. 모델별 정직성과 세부 분해

1. 비싼 최상위 모델과 workhorse

   1. 가장 신뢰할 수 있는 모델은 대체로 가장 비싼 최상위 모델이므로 정직성과 일관성에도 비용이 붙는다.
   2. Gemini 3.8 Flash는 Grok 4.6보다 truthiness가 높게 보이는 강력한 workhorse로 평가된다.
   3. Muse Spark 1.3과 Soul도 좋은 runner-up으로 언급되며, 이 아래에서 성능이 급격히 떨어진다.
   4. GLM 5.3은 GLM 5.3 Flash보다 약 두 배 나은 쪽으로 보이지만, 이후 전체 그래프에서는 급락하는 구간도 나타나 세부 축을 함께 확인해야 한다.

2. 전체 정확도와 언어별 차이

   1. state-of-the-art 모델은 전반 정확도에서 강하고 Gemini Flash, DeepSeek V4 Pro, Grok, Kimi도 활용할 만한 영역을 보인다.
   2. Qwen 3.8의 소형 계열과 Llama 계열 소형 모델은 사실 정보를 찾는 데 어려움을 겪는 쪽으로 언급된다.
   3. Muse Spark는 전체적으로 꽤 잘 수행해도 소프트웨어 엔지니어링 QA와 해당 영역의 truthiness에서 거칠어질 수 있다.
   4. 신뢰성 있는 일관된 출력이 필요하다면 낮은 구간은 피하고, 실제로 출하 가능한 usable model 구간을 모델 스택에 배치해야 한다.

6. 5순위 — DeepSWE v1.1

DeepSWE v1.1은 짧고 현실적인 요청으로 긴 시간 동안 소프트웨어 엔지니어링 작업을 수행하게 하여, 에이전트의 장기 계획 실행 능력을 압박한다.

6.1. 장기 작업과 벤치마크 유지보수

1. SweetBench Pro를 넘어선 긴 지평

   1. DeepSWE는 SweetBench Pro와 여러 변형에서 한 단계 더 나아가 더 오래 실행되는 작업을 요구한다.
   2. 공개 GitHub issue와 pull request에서 가져온 자료처럼 실제 개발자가 마주치는 문제를 바탕으로 긴 horizon의 엔지니어링 능력을 본다.

2. 모델 최신성·공정성

   1. DeepSWE v1.1에는 당시 Fable 5.1이 아직 포함되지 않았으므로 결과를 해석할 때 이 공백을 기록해야 한다.
   2. 벤치마크 제공자는 모델을 적극적으로 유지보수하고 새 모델을 빠르게 추가해야 하며, 의도적으로 특정 모델을 빼는 provider bias가 없어야 한다.
   3. 현장에서 실제 레버리지를 제공하는 모델을 누락한 벤치마크는 즉시 신뢰를 잃으므로 모델 목록을 확인하지 않은 순위는 폐기할 수 있다.

6.2. 짧은 프롬프트가 보여 주는 계획의 가치

1. 짧은 요청과 큰 결과

   1. 짧고 대략적인(high-level) 프롬프트만으로 에이전트가 큰 규모의 엔지니어링 작업을 끝낸다면, 상세한 계획과 더 많은 맥락을 제공했을 때 더 높은 결과를 기대할 수 있다.
   2. 계획(plan)은 규모를 키운 프롬프트(prompt scaled up)이므로, 좋은 계획을 쓰는 엔지니어의 투자가 에이전트 능력을 끌어올린다.

2. Vibe coding과 agentic engineering의 구분

   1. 입력을 줄이고 에이전트가 알아서 하도록 맡기는 "take the wheel" 방식은 가능한 능력의 바닥(floor)에 가까워지며 vibe coding으로 기울 수 있다.
   2. 계획에 투자하고 최대 capability를 끌어내는 agentic engineering은 에이전트가 도달할 수 있는 천장(ceiling)을 겨냥한다.
   3. DeepSWE의 짧은 프롬프트는 바닥이 아니라 천장을 평가하는 간접 신호로 활용된다.

6.3. 결과와 비용 곡선

1. Astra와 Gemini 3.8 Flash

   1. Astra가 약 30k 출력 토큰과 29단계(step), 낮은 평균 비용으로 1위를 차지한다.
   2. Gemini 3.8 Flash가 바로 아래에 놓이며, IndyDevDan의 모델 스택에서 가장 선호하는 workhorse로 제시된다.
   3. Gemini 3.8 Flash는 Astra보다 더 많은 토큰과 단계를 쓰고 더 오래 걸리지만, 성능을 유지하면서 비용을 크게 낮출 수 있다.

2. 가격대별 선택

   1. state-of-the-art에서 workhorse로 내려가면 비용을 약 10분의 1까지 줄일 수 있다.
   2. GLM 5.3 Flash 같은 강력한 저가 모델을 사용하면 약 20분의 1 비용으로 많은 작업을 처리할 수 있다.
   3. Fable 5.1은 차트에 빠져 있지만 추가되면 상위권에 올 가능성이 크며, 그 경우에도 Astra보다 훨씬 비쌀 것으로 예상된다.
   4. GLM 5.3과 Kimi는 좋은 대안이고, Luna와 GLM 5.3 Flash는 매우 싼 선택지다.
   5. DeepSeek V4 Flash는 소프트웨어 엔지니어링 성능을 크게 양보하거나 정교한 subagent handoff 프롬프트로 위임할 때만 가치가 있을 수 있지만, 기본 선택으로는 위험하다는 판단이 제시된다.

7. 다섯 벤치마크를 관통하는 운영 철학

다섯 벤치마크는 각기 다른 점수를 모으기 위한 목록이 아니라, 사람의 감독을 줄인 장기 에이전트 시스템을 만들기 위한 능력 지도를 구성한다.

7.1. Outloop agentic engineering

1. 시스템이 시스템을 만드는 구조

   1. 목표는 사람이 계속 지켜보지 않아도 자율적으로 실행되는 AI 시스템이다.
   2. Outloop agentic coding에서 Outloop agentic engineering으로 확장해, 여러 에이전트와 코드가 각자보다 더 잘 작동하는 시스템을 만든다.
   3. AI agents, AI developer workflows, software factories, agent swarms, 장차 dark factories가 모두 이 방향에 속한다.

2. 신뢰할 수 있는 장기 실행

   1. 필요한 공통 특성은 long horizon, no human in the loop, 그리고 정직해서 신뢰할 수 있는 에이전트가 사람을 대신해 결과를 출하하는 것이다.
   2. 장기 체인에서 환각 한 번은 이후 에이전트의 판단을 연쇄적으로 오염시키므로 Omniscience의 not attempted 선택지가 특히 중요하다.

7.2. 포화된 벤치마크를 버리고 분산을 찾기

1. AA Long Context Retrieval의 평평한 선

   1. AA Long Context Retrieval v1.1처럼 모든 모델이 비슷한 점수로 평평한 선을 만들면 성능 차이를 알려 주는 정보 이득(information gain)이 없다.
   2. 대부분의 모델이 긴 컨텍스트에서 정보를 꺼낼 수 있다면 해당 능력은 포화(saturation)된 것이며, 범용 모델 선택에는 유용하지 않다.
   3. 단, 업무 자체가 900k 컨텍스트에서 3% 더 정확하게 정보를 회수하는 것이라면 그 벤치마크가 개인 업무에는 여전히 중요하다.

2. Variance가 만드는 alpha

   1. 성능 곡선에서 모델이 떨어져 나가는 실제 분산을 찾아야 최첨단 모델을 쓰는 alpha와 workhorse를 쓰는 구간을 구분할 수 있다.
   2. AutomationBench처럼 예상 밖의 모델이 특정 도메인에서 앞서는 결과는 종합지수에서 사라지는 정보다.
   3. DeepSWE, Omniscience, AutomationBench의 분산은 모델 선택에서 어디에 정보가 있는지 보여 준다.

7.3. Alignment·비용·도메인·엔지니어링

1. Guardrail을 제품 코드로 편입하기

   1. guardrail은 프롬프트의 지시부터 실패하면 안 되는 조건까지 포함한다.
   2. 이를 에이전트 harness의 법칙으로 만들거나 AI developer workflow의 코드 단계와 validation 단계로 구현하면 software factory의 일부가 된다.
   3. AutomationBench는 모델이 단순히 결과를 냈는지가 아니라 작업 중 다른 시스템을 건드리지 않았는지를 확인한다.

2. 비용을 지불할 수 있는 AGI

   1. GPT-6 Astra는 탁월한 state-of-the-art 모델이지만 여전히 비싸며, Opus와 Fable에 비해 태스크당 비용 곡선이 절벽처럼 낮아진 점이 강점이다.
   2. AGI you can't pay for is irrelevant라는 원칙처럼, 실제로 확장할 수 없는 최고의 성능은 대부분의 엔지니어에게 실용적이지 않다.
   3. Gemini 3.8 Flash와 GLM 계열은 성능과 비용의 균형을 맞춰 다수의 에이전트를 돌릴 수 있는 선택지다.

3. 다중 에이전트 확장

   1. Astra Swarm이나 Fable Swarm은 여러 고가 모델을 동시에 호출하므로 비용이 크게 늘어난다.
   2. Gemini 3.8 Flash swarm과 GLM swarm은 훨씬 저렴하며, 실제 비구조적 작업을 많이 수행할 수 있는 viable한 선택으로 제시된다.
   3. 이전의 OpenAI Astra swarm과 Hugging Face 관련 사건은 에이전트 스웜이 현실적인 가능성이지만, 통제와 정직성 설계가 함께 필요하다는 점을 보여 준다.

7.4. 아직 필요한 벤치마크

1. 작은 에이전트 팀과 위임

   1. delegation, small agent teams, agent handoffs, agent swarms를 직접 측정하는 벤치마크가 필요하다.
   2. 한 모델이 여러 자기 복제 버전 또는 다른 에이전트와 협력해 작업을 분배하고 결과를 전달할 수 있는지 확인해야 한다.
   3. IndyDevDan은 이런 small agent teams를 SATs라고 부른다.

2. 자기 치유 시스템

   1. 에이전트가 실패했을 때 사람이 개입해 고치지 않아도 스스로 회복하는지 확인해야 한다.
   2. self-healing, self-validation, agent-to-agent communication은 사람 없는 장기 실행의 핵심이며, 이에 특화한 평가에는 큰 비용을 지불할 가치가 있다.
   3. 다음 세대 에이전틱 엔지니어링은 사람 대신 일하는 시스템에 투자하는 일이며, 단일 응답 점수만으로는 이 능력을 설명할 수 없다.

주요 발언 모음

"Not all benchmarks are created equally."

"Performance, cost, and speed"를 함께 봐야 한다.

"Useful agent output per hour"가 태스크당 출력 토큰보다 더 중요한 운영 지표다.

"One benchmark is not enough."

"Combine compute. Don't select compute."

"AGI you can't pay for is irrelevant."

"Long horizon, no human in the loop, honest agents we can trust shipping on our behalf."

"Don't say the index. Give me a specific benchmark."

핵심 데이터 & 수치

• Artificial Analysis Index: 최근 4.3 버전으로 갱신됐으며, 여러 벤치마크를 하나의 포괄 지수로 압축한다.
• Terminal-Bench v4.0: 60개가 넘는 태스크를 소프트웨어 엔지니어링, 머신러닝, 과학, 운영, 보안, 하드웨어, 미디어에 걸쳐 평가한다.
• Terminal-Bench 성능 분산: 모델 성능이 약 40~42% 구간에서 크게 떨어지는 절벽이 관찰된다.
• Astra 토큰 효율: Fable 5보다 약 2.7배, Fable 5.1보다 약 2.5배 적은 사용량으로 비교된다.
• Astra 비용 우위: 내부 에이전트 코딩에서 Fable보다 약 네 배, Claude Fable 5.1보다 약 2.4배 유리한 비용으로 제시된다.
• AutomationBench: 금융, HR, 마케팅, 운영, 영업, 지원의 여섯 도메인에서 600개가 넘는 태스크를 수행한다.
• AA-Omniscience 판정: correct, incorrect, partial, not attempted 네 상태를 사용하며 not attempted에는 점수 불이익이 없다.
• Omniscience의 0점: 정답과 오답이 같은 수준인 50 대 50의 사실 판단을 의미한다.
• DeepSWE v1.1: Astra는 약 30k 출력 토큰과 29단계로 1위를 차지하고 Gemini 3.8 Flash가 바로 뒤따른다.
• 비용 계층: state-of-the-art에서 workhorse로 옮기면 약 10배, GLM 5.3 Flash 같은 모델로 옮기면 약 20배 비용을 낮출 수 있다.
• 포화의 예외: 900k 컨텍스트에서 정보를 회수하는 업무라면 AA Long Context Retrieval의 작은 차이도 개인 지표로는 유효할 수 있다.

결론 및 시사점

1. Artificial Analysis Index는 전역적인 방향을 보는 참고 자료로만 사용하고, 실제 제품 업무를 대표하는 세네 개의 개인 벤치마크를 별도로 만든다.
2. 코딩의 원시 에이전트 능력은 Terminal-Bench, 비소프트웨어 지식 노동은 APEX Agents, 여러 앱을 넘나드는 직원형 자동화와 가드레일 준수는 AutomationBench로 확인한다.
3. 장기 파이프라인의 신뢰성은 AA-Omniscience에서 not attempted를 허용하는 정직성으로 평가하고, 장기 엔지니어링 실행력은 DeepSWE v1.1로 검증한다.
4. 모든 모델을 단일 평균 순위로 고르지 말고 state-of-the-art, workhorse, lightweight 모델을 비용·속도·도메인별로 조합한다.
5. 평평한 선의 포화 벤치마크보다 모델별 분산과 예상 밖의 강점이 있는 벤치마크에 시간을 투자한다.
6. 자신의 프롬프트, harness, validation 규칙, 도메인별 성공 조건을 벤치마크에 반영해 개인 index를 계속 갱신한다.
7. 최종 목표는 장기 작업을 사람 없이 수행하고, 모를 때 멈추며, 실패에서 회복하고, 다른 에이전트와 협업해 결과를 출하하는 시스템이다.

핵심 요약 (20줄)

Artificial Analysis Index 4.3은 여러 벤치마크를 한 숫자로 압축해 업무별 모델 차이와 비용을 숨길 수 있다.

모델 선택은 성능·비용·속도를 함께 계산하는 3차원 문제이며 useful agent output per hour가 핵심 운영 관점이다.

Terminal-Bench v4.0은 실제 컨테이너·harness loop·verifier를 사용해 순수 에이전틱 코딩 능력을 측정한다.

Terminal-Bench v4.0은 소프트웨어·머신러닝·과학·운영·보안·하드웨어·미디어의 60개 넘는 태스크를 포함한다.

GPT-6 Astra는 Terminal-Bench에서 Fable 5.1을 앞서며 성능과 비용의 조합에서도 강력한 결과를 보인다.

Terminal-Bench의 40~42% 성능 절벽은 모델 선택에 유용한 variance와 정보 이득이 존재한다는 신호다.

Astra는 내부 에이전트 코딩에서 Fable보다 약 네 배 저렴하고 Claude Fable 5.1보다 약 2.4배 유리하게 제시된다.

APEX Agents는 투자은행 분석·경영 컨설팅·기업 법무라는 세 고난도 지식 노동을 소프트웨어 밖의 프록시로 사용한다.

McKinsey·BCG·Deloitte·Goldman Sachs·Morgan Stanley·JP Morgan 전문가가 APEX의 현실적인 태스크를 검토하거나 작성했다.

APEX는 실제 사용자에 가까운 짧은 프롬프트와 도구·파일 구조·에이전트 trajectory를 제공하지만 비용과 시간은 빠진다.

AutomationBench는 금융·HR·마케팅·운영·영업·지원의 여섯 도메인에서 600개 넘는 다중 애플리케이션 태스크를 평가한다.

AutomationBench는 목표를 달성해도 guardrail violation을 일으키면 실패하게 해 낮은 수준의 alignment를 측정한다.

Astra는 guardrail을 포함한 AutomationBench에서 강하며 Fable은 금융 도메인에서 상대적으로 약한 모습을 보인다.

AA-Omniscience는 correct·incorrect·partial·not attempted로 환각과 정직한 중단을 함께 평가한다.

Omniscience는 모른다고 답하는 데 벌점을 주지 않으며 0점은 사실 질문에서 정답과 오답이 50 대 50이라는 뜻이다.

DeepSWE v1.1은 짧고 현실적인 프롬프트로 긴 소프트웨어 엔지니어링 작업을 수행하게 해 장기 실행력을 검증한다.

DeepSWE v1.1에서 Astra는 약 30k 출력 토큰과 29단계로 1위이고 Gemini 3.8 Flash는 비용 효율적인 workhorse다.

Workhorse 모델은 state-of-the-art보다 약 10배, GLM 5.3 Flash는 약 20배 낮은 비용으로 많은 작업을 처리할 수 있다.

평평한 AA Long Context Retrieval 같은 포화 벤치마크보다 모델 간 variance가 있는 평가가 선택의 alpha를 제공한다.

최적의 전략은 글로벌 지수를 참고하면서 업무별 개인 index로 모델 스택을 구성하고 장기·정직·자율·협업 능력을 계속 검증하는 것이다.