Agentic Engineering Benchmarks: How I RANK Astra, Fable 5.1, and Open-Weights

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Astra·Fable 5.1·오픈 웨이트 모델의 에이전틱 엔지니어링 순위는 종합 점수보다 실제 업무의 성능·비용·속도와 제약 준수를 기준으로 매겨야 한다.

📌 핵심 요점

1. 평가 기준은 실제 작업과 맞아야 한다. Terminal Bench는 실행 결과, Apex Agents는 전문 지식 업무, Automation Bench는 목표 달성과 제약 준수, Omniscience는 사실성, Deep SWE는 장시간 개발 능력을 살핀다. 하나의 종합 순위로 이 차이를 대체하기 어렵다.
2. Astra는 제시된 코딩 비교에서 성능과 작업당 비용이 강점이다. Terminal Bench에서 Fable 5.1보다 앞서며, 해당 비교의 실행 비용은 Fable 5.1보다 약 2.4배 저렴하다고 설명된다. 다만 가장 빠른 모델은 아니며, 토큰 사용량과 실제 청구 비용도 구분해야 한다.
3. 완료율이 높아도 제약을 어기면 실무 적합성이 낮아진다. Automation Bench에서는 가드레일 반영 여부에 따라 모델의 상대적 위치가 달라진다. 필수 조건은 모델 평가뿐 아니라 하네스와 개발 워크플로의 코드 검증에도 포함해야 한다.
4. 장기 자율 작업에서는 모른다고 멈추는 능력이 중요하다. Omniscience는 환각에 벌점을 주고 답변 거부에는 점수 변화를 주지 않는다. 전체 정확도와 이러한 사실성 점수는 다르며, 에이전트 간 인계에서 오류가 확산될 가능성도 고려해야 한다.
5. 업무별 모델 조합이 비용과 성능의 균형을 만든다. 장시간 개발에서는 Gemini 3.8 Flash처럼 완료가 느려도 비용 이점이 있는 후보가 제시된다. 다만 위임·팀 조율·실패 복구·자체 검증 능력은 선택한 다섯 벤치마크만으로 충분히 평가되지 않는다.

🧩 배경과 문제 정의

• 종합 벤치마크 지수는 서로 다른 능력을 하나의 점수로 압축하므로, 실제 업무에 중요한 성능 차이와 비용 차이를 가릴 수 있다. 에이전트 활용 방식도 빠르게 바뀌어 평가 기준을 계속 점검해야 한다.
• 모델 선택에는 성능·비용·속도를 함께 고려해야 한다. 핵심 목표는 높은 점수 자체보다 투입 비용과 시간을 감안한 ‘시간당 유용한 에이전트 작업량’이다.
• Terminal Bench, Apex Agents, Automation Bench, Omniscience, Deep SWE는 각각 코딩 실행, 전문 지식 업무, 제약 준수, 사실성, 장시간 개발 능력을 평가하는 대리 지표다. 업무별 강점이 달라 여러 모델을 조합하는 선택이 중요하다.

🕒 시간순 섹션별 상세정리

1. 종합 순위보다 실제 업무에 맞는 평가 기준이 중요하다

• Artificial Analysis 지수 4.3은 많은 정보를 압축하지만, 개별 벤치마크의 중요도는 엔지니어가 해결하려는 문제에 따라 달라진다. 모든 업무에 동일한 종합 순위를 적용하기는 어렵다 [00:15]
• 에이전트 활용 방식은 몇 달 사이에도 바뀌며, 단일 벤치마크는 모델의 모든 능력을 설명하지 못한다. 다섯 개만 선택한다는 제약은 필요한 능력과 우선순위를 명확하게 만든다 [00:50]

2. Terminal Bench는 명령 실행부터 최종 상태까지 검증한다

• 에이전트는 코드·데이터·시스템 상태가 준비된 컨테이너에서 명령과 결과를 반복 처리한다. 검증기는 최종 상태를 기준으로 성공과 실패를 판정하며, 60개가 넘는 과제가 소프트웨어·머신러닝·과학·운영·보안·하드웨어·미디어를 포괄한다 [02:19]
• 비교 결과에서는 Astra가 앞서고 Fable 5.1이 뒤따르며, 40~42% 수준에서 모델 간 성능 격차가 크게 벌어진다. 이런 격차는 최상위 모델을 선택할 실질적인 이득이 있는지 판단하는 단서다 [02:58]

3. 토큰 효율과 실제 비용이 비슷한 성능의 가치를 가른다

• Astra의 토큰 사용량은 Fable 5보다 약 2.7배, Fable 5.1보다 약 2.5배 적게 나타난다. GLM 5.3이나 Gemini 3.8 Flash 같은 주력 모델은 저렴한 가격과 별개로 결과에 도달하기까지 많은 토큰을 쓸 수 있다 [04:01]
• 평가의 중심은 과제당 출력 토큰에서 ‘시간당 유용한 에이전트 산출물’로 이동한다. Astra의 중간·낮은 추론 설정도 비용 대비 성능에서 최상위권에 가깝게 나타난다 [04:49]

4. 작업 시간과 과제 원문으로 코딩 성능의 의미를 확인한다

• Astra의 과제 처리 속도는 최고 수준은 아니지만 활용 가능한 수준으로 평가된다. 일부 오픈 웨이트 모델은 결과를 얻기 위해 긴 추론 시간을 쓰므로, 저렴한 가격이 높은 시간당 작업량을 보장하지는 않는다 [06:31]
• Terminal Bench의 과제별 자료에는 실행 머신, 시간 제한, 난도 설명과 실제 지시가 포함된다. 이미지의 구성 요소를 해석해 지정된 config.json 형식으로 레이아웃을 재구성하는 사례는 점수가 어떤 작업 능력을 반영하는지 보여준다 [07:19]

5. Apex Agents는 소프트웨어 밖의 전문 지식 업무를 평가한다

• Apex Agents는 투자은행 분석, 경영 컨설팅, 기업 법무를 대상으로 하며, 관련 전문기관의 전문가들이 과제를 검토한다. 난도가 높은 세 직군의 결과를 다른 디지털 지식 업무에 대한 대리 지표로 활용한다 [08:18]
• 이 평가에는 비용과 완료 시간이 빠져 있어 성능·비용·속도를 모두 비교할 수 없다는 한계가 있다. 약 85%, 특히 90% 이상을 벤치마크 포화 수준으로 보는 판단도 함께 드러난다 [08:54]

6. 실제 사용자의 짧은 요청을 처리하는 능력도 필요하다

• 시장점유율 차트와 고객 세분화 자료를 이용해 목표 점유율 달성 시 중소기업 회계 부문의 잠재 매출을 계산하는 과제는, 지식 근로자가 실제로 입력할 법한 짧고 상위 수준의 요청에 가깝다 [10:16]
• 내부 사용자와 고객은 엔지니어처럼 상세한 계획이나 정교한 시스템 프롬프트를 작성하지 않는다. 제품은 이런 입력을 처리할 수 있어야 하며, 평가에는 도구 접근권한·파일 구조·에이전트의 실제 작업 경로도 포함된다 [10:34]

7. Automation Bench는 목표 달성과 가드레일 준수를 함께 요구한다

• Automation Bench는 재무·인사·마케팅·운영·영업·지원의 여섯 영역에서 600개가 넘는 과제를 다룬다. 에이전트는 일상적인 업무 도구에서 정보를 가져오고 여러 애플리케이션을 오가며 작업한다 [13:58]
• 목표를 달성해도 가드레일을 위반하면 실패하거나 점수를 잃는다. 단순 완료 여부에 더해, 작업 도중 원치 않는 행동이나 부수적인 문제를 일으켰는지를 평가한다 [14:37]

8. 완료율만 보면 가려지는 모델별 제약 위반 차이

• 가드레일을 반영한 결과에서는 Grock 4.6, GLM 5.3, GLM 5.3 Flash 등이 눈에 띄며, Fable 5.1은 상위권보다 약 8~9% 낮게 평가된다. 최신 최상위 모델이라고 모든 업무 자동화 평가에서 앞서는 것은 아니다 [15:46]
• 가드레일 위반을 제외하고 목표 완료율만 보면 Opus와 Fable의 위치가 올라간다. 따라서 엄격한 지침 준수가 필요한 업무에서는 높은 완료율만으로 모델을 선택하기 어렵고, Astra가 유리한 결과를 보인다 [16:56]

9. 애플리케이션별 강점과 비용을 바탕으로 모델을 조합한다

• Gmail 중심 작업에서는 Grog 4.6, Quinn 3.8, GLM 5.3이 최상위 모델 외의 후보로 나타나지만 Deepseek는 상대적으로 약하다. 저렴한 주력 모델이라는 분류만으로 특정 도구에서의 적합성을 판단할 수 없다 [18:14]
• 제품 에이전트를 확장할 때는 업무와 도구마다 다른 모델을 배치하는 모델 조합이 유리하다. 어느 영역에서 성능을 조금 양보할 수 있는지 알아야 비용 절감 선택도 구체화된다 [18:43]

10. Omniscience는 모를 때 답하지 않는 선택을 평가에 포함한다

• Omniscience는 환각률을 통해 작업 규모가 커질 때 모델을 얼마나 신뢰할 수 있는지 살핀다. 사람이 코드와 계획의 세부 사항을 덜 검토할수록, 답을 모를 때 중단할 수 있는 능력의 중요성이 커진다 [20:23]
• 답변은 정답·오답·부분 정답·미시도로 분류된다. 모델이 답변을 시도하지 않는 선택을 허용한다는 점이 핵심이다 [21:18]

11. 사실성 점수는 비용과 모델 규모에 따른 차이를 드러낸다

• 신뢰도가 높은 모델은 대체로 비싼 최상위 모델이며, Gemini 3.8 Flash·Muse Spark 1.3·Soul도 유력한 대안으로 나타난다. 이 비교에서는 이들이 Grock 4.6보다 사실성 측면에서 좋은 결과를 보인다 [22:53]
• GLM 5.3은 5.3 Flash H보다 해당 점수가 약 두 배 높게 나타난다. 종합 지수에 정보를 다시 압축하면 이런 개별 능력의 차이를 놓치기 쉽다 [23:28]

12. 전체 정확도와 분야별 사실성은 별도로 확인해야 한다

• 전체 정확도에서는 최상위 모델뿐 아니라 Gemini Flash, DeepSeek V4 Pro, Grock, Kimmy도 비교적 좋은 결과를 보이지만 GLM 5.3은 약해진다. 답변 거부를 포함한 사실성 점수와 전체 정확도는 서로 다른 측면을 드러낸다 [24:23]
• Muse Spark는 전반적인 성적에 비해 소프트웨어 엔지니어링 질의응답의 사실성이 약해진다. 안정적인 출력을 원한다면 모델의 전체 순위와 실제 적용 분야의 강점을 함께 봐야 한다 [24:46]

13. Deep SWE는 장시간 개발 능력과 평가의 최신성을 함께 보게 한다

• Deep SWE는 SWE-bench Pro 등의 평가보다 더 오래 걸리는 소프트웨어 개발 작업을 수행하도록 요구한다. 핵심은 긴 작업 구간에 걸쳐 개발을 지속하는 능력이다 [25:37]
• 확인 시점의 1.1 버전에는 Fable 5.1이 빠져 있으며, 곧 추가될 것이라는 기대는 아직 전망이다. 평가 제공자가 새 모델을 적극적으로 반영하는지, 특정 공급자의 모델을 의도적으로 제외하지 않는지도 선택 기준이 된다 [25:48]

14. 짧은 프롬프트의 성과를 상세 계획의 잠재력과 연결한다

• Deep SWE는 현실적인 짧은 프롬프트를 사용한다. 적은 지시로 많은 개발 작업을 완수하는 능력을 확인할 수 있다는 점이 장점이다 [26:34]
• 상세한 계획과 풍부한 정보를 제공하면 더 높은 능력을 끌어낼 수 있다는 기대가 드러난다. 다만 짧은 프롬프트의 평가 결과 자체가 상세 계획의 효과를 직접 검증한 것은 아니다 [26:47]

15. 장시간 작업에서는 속도를 양보해 주력 모델의 비용 이점을 얻는다

• 주력 모델로 작업을 옮기면 최상위 모델 대비 비용을 약 10분의 1로, GLM 5.3 Flash 같은 경우 약 20분의 1로 낮출 수 있다는 비교가 드러난다. 절감 효과는 해당 모델에 적합한 작업을 배정할 때 의미가 있다 [27:55]
• Gemini 3.8 Flash는 더 많은 토큰과 단계를 사용해 완료까지 오래 걸리지만 결과에 도달한다. 속도보다 성능과 비용을 우선하는 장시간 소프트웨어 개발 작업의 후보가 된다 [28:32]

16. 장기 자율 작업을 기준으로 벤치마크를 선택한다

• DeepSeek V4 Flash는 소프트웨어 엔지니어링 성능을 크게 양보하거나, 인계 프롬프트를 정교하게 설계해 하위 에이전트에 위임할 때 활용 가치가 있을 수 있다. 다만 이를 선택하기에는 위험이 크다는 평가이며, Deep Suite는 GitHub 이슈와 풀 리퀘스트를 바탕으로 장기 소프트웨어 작업을 평가한다 [29:48]
• Terminal Bench, Apex Agents, Automation Bench, Omniscience, Deep Suite를 고른 공통 기준은 감독 없이 작동하는 에이전트 시스템이다. 에이전트 팀과 코드가 함께 시스템을 구축하고, 사람이 작업 과정에 개입하는 정도를 줄이는 ‘아웃루프 에이전틱 엔지니어링’을 지향한다 [31:04]

17. 포화된 점수보다 모델 간 차이와 가드레일 준수를 중시한다

• AA Long Context Retrieval V1.1처럼 점수가 평평하게 모인 평가는 모델 선택에 주는 정보가 적다. 다만 900k 컨텍스트에서 정보를 회수하는 작업에 Kimmy K3의 3% 차이가 실질적인 이점이라면, 해당 평가는 여전히 중요할 수 있다 [31:59]
• Deep Suite와 Omniscience 등에서는 모델 간 성능 차이가 나타나며, Automation Bench처럼 최상위 모델이 항상 앞서지는 않는 경우도 있다. 이런 차이가 실제 모델 선택에 유용한 정보를 제공한다 [32:21]

18. 장기 실행의 실용성은 비용과 환각 억제에 달려 있다

• 감당할 수 없는 비용의 지능은 실무에서 활용하기 어렵다. Astra는 여전히 비싸지만 작업당 비용에서는 Opus·Fable보다 크게 유리하다는 평가이며, Kimmy·GLM·Gemini도 성능과 비용의 균형을 위한 후보로 꼽힌다. 가격은 시간이 지나며 내려갈 것으로 전망한다 [34:00]
• 장기 에이전트 파이프라인에서는 한 에이전트의 환각이 이후 모든 에이전트에 잘못된 결과를 전달할 수 있다. 따라서 낮은 기만성과 환각 억제가 중요하며, Omniscience는 이 위험을 살피는 평가로 의미가 있다 [34:30]

19. 소프트웨어를 넘어 실제 업무와 에이전트 협업을 평가해야 한다

• 실제 제품을 만들려면 소프트웨어 개발뿐 아니라 재무·인사·마케팅·운영·영업·지원과 해당 산업의 업무를 수행해야 한다. 투자은행 분석, 경영 컨설팅, 법률 조사와 규제·소송·인수합병·컴플라이언스 같은 어려운 과제는 다른 전문 영역의 수행 능력을 가늠하는 대리 지표가 될 수 있지만, 잘할 것이라는 기대 수준이다 [36:24]
• Deep Suite와 Terminal Bench 같은 엔지니어링 평가도 필요하지만, 코딩에만 집중해서는 안 된다. 장시간 사람의 개입 없이 신뢰할 수 있는 결과를 내는 능력이 시스템을 만드는 시스템, 소프트웨어 팩토리, 에이전트 스웜과 향후 다크 팩토리의 공통 요건이다 [37:02]

20. 업무에 맞는 여러 평가로 모델 조합을 구성한다

• 하나의 벤치마크에 집착하기보다 자신의 업무 영역과 맞는 여러 평가를 함께 봐야 한다. 이를 통해 단일 모델을 고르는 데서 나아가 작업에 적합한 모델 조합을 구성할 수 있다 [38:29]
• 종합 지수와 함께 자신의 업무에 맞춘 평가 기준을 유지하고, 성능·비용·속도를 함께 고려해야 한다. 최종 선택의 기준은 전역적인 순위보다 실제 수행할 작업과 벤치마크의 일치 여부다 [38:53]

🧾 결론

• Astra의 강점은 여러 비교에서 확인되지만, 모든 업무와 도구에서 동일하게 우세하다는 뜻은 아니다.
• 모델 선택의 실용적 기준은 성능·비용·속도를 함께 반영한 ‘시간당 유용한 에이전트 작업량’이다.
• 실제 업무에 맞는 여러 평가를 조합하고, 분야별 제약 준수와 사실성까지 확인해야 적합한 모델 구성을 만들 수 있다.

📈 투자·시사 포인트

• 에이전트 제품의 비용 구조를 판단할 때는 토큰 단가와 함께 작업당 실행 비용 및 완료 시간을 봐야 한다. 저렴한 단가가 높은 생산성을 보장하지는 않는다.
• 업무와 도구에 따라 모델을 나누어 배치하는 역량은 제품 확장 시 비용 절감의 근거가 된다. 어느 작업에서 성능이나 속도를 양보할 수 있는지가 중요하다.
• 기업 도입 가능성을 평가할 때 코딩 점수뿐 아니라 재무·인사·법무 등 실제 업무 수행, 제약 준수, 오류 전파 억제를 함께 살펴야 한다.
• 향후 가격 하락과 미포함 모델의 상위권 진입은 자료 속 전망이다. 이를 현재 확인된 비용 우위나 성능으로 간주해서는 안 된다.

⚠️ 불확실하거나 확인이 필요한 부분

• 비용 배수와 성능 순위는 제시된 평가 조건에 한정된다. 추론 설정, 입력·출력·캐시 토큰, 실행 환경과 가격 기준을 확인해야 다른 업무에 적용할 수 있다.
• Apex Agents에는 비용과 완료 시간이 빠져 있다. 전문 지식 업무의 성능만으로 시간당 생산성이나 경제성을 판단하기 어렵다.
• 확인 시점의 Deep SWE 1.1에는 Fable 5.1이 포함되지 않았다. 향후 순위와 Astra 대비 비용에 관한 설명은 전망이며, 자료에 혼용된 Deep SWE·Deep Suite 명칭의 관계도 확인이 필요하다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 실제 업무를 코딩 실행, 전문 지식 작업, 도구 자동화, 사실 확인, 장시간 개발로 나누고 대응하는 벤치마크를 선정한다.
• 동일한 업무와 실행 조건에서 후보 모델의 성공률, 제약 위반, 실제 비용, 완료 시간을 함께 기록한다.
• 반드시 지켜야 할 조건과 위반 시 경고할 조건을 하네스 및 코드 검증 단계에 반영한다.
• 분야별 사실성과 답변 거부를 별도로 확인하고, 잘못된 결과가 다음 에이전트로 전달되는 사례를 점검한다.

❓ 열린 질문

• 우리 업무에서는 어느 정도의 속도 저하나 성능 차이를 허용해야 더 저렴한 모델의 이점이 실제 생산성으로 이어지는가?
• 개별 모델의 벤치마크 성적이 에이전트 팀의 조율·자체 검증·실패 복구 성과를 얼마나 설명할 수 있는가?
• 사람이 검토하는 비중을 줄일 때, 사실성 및 제약 준수의 최소 허용 수준을 어떻게 정할 것인가?