GPT-6 Astra와 Claude Fable 5.1, AI 경쟁의 기준이 달라지고 있다

GPT-6 Astra와 Claude Fable 5.1이 같은 주에 등장했다. 벤치마크뿐 아니라 직접 사용하며 느낀 속도와 완성도 차이, 에이전트의 성능·비용·제어 문제를 함께 살펴본다.

10분 읽기industry

GPT-6 Astra와 Claude Fable 5.1, AI 경쟁의 기준이 달라지고 있다

2026년 9월 첫째 주, Anthropic과 OpenAI가 며칠 간격으로 새 모델을 내놨다.

Anthropic은 9월 1일 Claude Fable 5.1을 공개했고, OpenAI는 9월 3일 GPT-6 Astra를 발표했다.

둘 다 코딩과 장시간 작업을 중요한 사용 사례로 내세운다.

그래서 처음에는 자연스럽게 성능 비교부터 보게 된다. 어느 모델이 더 높은 점수를 받았는지, 코딩에서는 누가 앞서는지, 컨텍스트는 얼마나 긴지 같은 숫자들이다.

하지만 두 발표를 같이 놓고 보면 더 흥미로운 변화가 있다.

AI 모델을 평가하는 기준이 한 번의 응답 성능에서 하나의 작업을 끝내는 능력으로 이동하고 있다.

GPT-6 Astra에서는 비동기 도구 호출과 작업 도중 사용자 개입이 API의 핵심 기능으로 들어왔고, Claude Fable 5.1에서는 장시간 에이전트 작업에서 반복되는 컨텍스트 비용을 줄이는 방향이 강조됐다.

두 회사가 같은 문제를 완전히 같은 방식으로 풀고 있는 것은 아니다. 하지만 둘 다 이제 모델이 질문에 답하는 몇 초가 아니라, 여러 도구를 사용하며 오래 작업하는 상황을 전제로 제품을 설계하고 있다.

먼저 성능은 어떻게 달라졌을까

OpenAI는 GPT-6 Astra를 복잡한 end-to-end 작업을 위한 자사의 가장 강력한 모델로 소개한다.

OpenAI가 공개한 비교에서 AutomationBench 점수는 GPT-6 Astra가 41.4%, Claude Fable 5.1이 31.4%다.

AutomationBench는 여러 단계의 실제 업무 자동화 능력을 평가하는 벤치마크라서 이번 글의 주제인 에이전트 작업과도 꽤 직접적으로 연결된다.

다만 이 숫자 하나를 가지고 Astra가 Fable 5.1보다 전반적으로 더 좋은 모델이라고 결론 내리는 것은 어렵다. 평가마다 사용하는 도구, harness, reasoning 설정이 다를 수 있고 모델 공급자가 직접 공개한 결과라는 점도 고려해야 한다.

Anthropic이 공개한 Fable 5.1 평가에서는 이전 세대와 비교한 변화가 꽤 크다.

벤치마크 Fable 5.1 Fable 5 Opus 5 GPT-5.6 Sol
Terminal-Bench-Science 0.1 52.6% 24.7% 29.0% 22.4%
Terminal-Bench 4.0 55.8% 42.0% 52.3% 37.3%
AutomationBench 31.4% 17.1% 26.9% 19.6%
CursorBench 3.2.0 73.4% 70.5% 70.0% 67.2%

이 수치도 Anthropic 자체 평가다. 특히 Terminal-Bench 계열은 평가 환경과 safeguards의 영향을 받을 수 있고 Anthropic도 공식 발표에서 해당 조건을 별도로 설명한다.

그래서 여기서 중요한 것은 특정 숫자로 승자를 정하는 것이 아니다.

Fable 5.1이 이전 세대보다 코딩과 장시간 문제 해결에 상당한 개선을 목표로 했다는 것, 그리고 Astra 역시 단순 질의응답보다 복잡한 end-to-end 작업을 전면에 내세웠다는 점이 더 중요하다.

직접 써보니 둘의 성격은 꽤 달랐다

벤치마크와 API 사양만으로는 잘 드러나지 않는 차이도 있었다.

두 모델을 실제 개발 작업에 사용해본 개인적인 인상은 꽤 명확했다.

Astra를 한 문장으로 표현하면 "완벽하지는 않지만 빨랐다"에 가까웠다.

응답과 작업 진행이 빠르고 결과물의 전체적인 완성도도 상당히 괜찮았다. 빠르게 코드를 읽고 수정 방향을 잡은 뒤 결과를 만들어내는 과정에서는 만족스러웠다.

다만 작업이 끝난 뒤 직접 확인해보면 놓친 부분이 종종 있었다. 큰 방향은 맞고 핵심 구현도 해냈지만 세부 조건이나 주변 코드까지 완전히 챙기지 못한 경우가 있었다.

그래서 Astra를 사용할 때는 모델이 빠르게 작업을 진행하게 두되, 중간이나 마지막에 내가 결과를 확인하고 빠진 부분을 다시 지시하는 방식이 잘 맞았다.

반대로 Fable 5.1은 확실히 느리게 느껴졌다.

작업을 맡기고 결과를 받기까지 기다리는 시간은 Astra보다 길었지만, 한 번 결과가 나오면 만족스러운 경우가 많았다. 요구사항을 조금 더 넓게 살피고 세부적인 부분까지 챙겨서 한 번에 완성된 결과에 가까운 것을 가져오는 느낌이 강했다.

물론 이것은 통제된 벤치마크가 아니다. 내가 실제 개발 작업에서 두 모델을 사용하며 받은 개인적인 인상이고, 작업 종류와 도구 환경, 프롬프트에 따라 결과는 달라질 수 있다.

그래도 지금 둘 중 하나를 선택한다면 기준은 의외로 단순하다.

내가 조금 더 신경 써서 작업할 생각이라면 Astra, 가능하면 한 번에 맡기고 싶다면 Fable 5.1.

Astra의 빠른 속도를 이용해 짧은 피드백 루프를 여러 번 돌리는 방식과, Fable 5.1에 조금 더 시간을 주고 완성도 높은 결과를 기다리는 방식의 차이다.

이 경험 때문에 오히려 벤치마크의 승자를 정하는 것보다 작업을 어떤 방식으로 진행하고 싶은가가 모델 선택에서 중요하다고 느꼈다.

Astra에서 더 중요한 것은 모델보다 API 변화다

GPT-6 Astra의 모델 사양은 눈에 띈다.

공식 모델 문서에 따르면 Astra는 1,050,000 토큰 컨텍스트 윈도우128,000 토큰 최대 출력을 지원한다.

가격은 100만 토큰 기준 입력 $10, 캐시 입력 $1, 출력 $50이다. 272K 입력 토큰을 넘는 요청은 전체 요청에 더 높은 장문 요금이 적용된다.

하지만 더 중요한 변화는 이 숫자들이 아니다.

OpenAI는 Astra와 함께 async tool calling을 도입했다.

일반적인 tool calling에서는 모델이 도구를 호출하면 애플리케이션이 결과를 돌려줄 때까지 해당 턴이 사실상 멈춘다. Astra에서는 도구를 async: true로 정의할 수 있다.

그러면 모델은 한 도구의 실행 결과를 기다리는 동안 다른 도구를 호출하거나, 독립적으로 처리할 수 있는 부분을 계속 추론할 수 있다.

Model
  ├─ Tool A 호출 ───────┐
  ├─ Tool B 호출 ────┐  │
  │                  │  │
  ├─ 다른 작업 계속   │  │
  │                  ↓  ↓
  └──────────── Tool 결과 반영

물론 OpenAI가 도구를 대신 실행해주는 것은 아니다. 공식 문서에서도 도구 실행과 pending work 관리는 여전히 애플리케이션의 책임이라고 명시한다.

즉 Astra가 해결하는 것은 작업 큐 자체가 아니라 모델의 추론 흐름이 느린 도구 하나에 묶이지 않도록 하는 부분이다.

에이전트가 검색, 빌드, 테스트, 외부 API 호출을 여러 번 수행하는 구조에서는 꽤 큰 차이가 될 수 있다.

작업 중간에 사용자가 방향을 바꿀 수도 있다

Astra에서 또 하나 흥미로운 기능은 mid-turn steering이다.

기존의 일반적인 요청/응답 구조에서는 모델이 긴 작업을 수행하기 시작하면 작업이 끝난 뒤 새로운 요청으로 수정사항을 보내는 흐름이 자연스러웠다.

Astra의 steering은 작업이 진행되는 동안 추가 사용자 지시를 전달할 수 있게 한다.

예를 들어 에이전트에게 프로젝트 전체를 수정하라고 요청했는데 작업 중간에:

데이터베이스 마이그레이션은 건드리지 마.

같은 조건을 추가할 수 있다.

몇 초짜리 답변이라면 끝날 때까지 기다리면 된다. 하지만 에이전트가 몇 분, 혹은 그 이상 작업한다면 이야기가 달라진다.

결국 장시간 실행되는 에이전트에는 실행을 시작하는 API뿐 아니라 실행 중인 작업을 제어하는 API가 필요해진다.

OpenAI가 Responses API를 신규 프로젝트에 권장하고 agentic primitive를 이쪽에 집중하는 흐름도 같은 방향으로 볼 수 있다.

그리고 직접 사용했을 때 Astra에서 느꼈던 빠른 작업 진행과 잦은 피드백 루프는 이런 방향과도 잘 맞았다. 빠르게 진행시키고 사람이 중간중간 확인하며 방향을 보정하는 방식이다.

Fable 5.1은 같은 문제에서 비용을 건드렸다

Anthropic의 접근에서 특히 눈에 들어오는 것은 cache read 가격이다.

Claude Fable 5.1의 기본 가격은 100만 토큰 기준 입력 $10, 출력 $50으로 Fable 5와 같다.

그런데 Anthropic은 cache read 가격을 75% 낮춰 100만 토큰당 $0.25로 변경했다.

Anthropic은 이 변화로 실제 2026년 8월 사용량을 기준으로 일반적인 workload에서는 Fable 5 대비 약 25%, 복잡한 코딩과 높은 agentic workload에서는 최대 약 45% 비용이 줄어들 수 있다고 설명한다.

이 숫자는 독립적인 보편적 비용 절감률이 아니다. Anthropic이 Claude Enterprise, Claude Code, API에서 실제 사용된 워크로드를 기준으로 계산한 회사 측 추정치다.

하지만 방향 자체는 중요하다.

에이전트는 일반적인 채팅보다 같은 입력을 반복해서 읽는 경우가 많다. 코딩 에이전트라면 시스템 지시, 저장소 규칙, 파일 구조, 도구 설명, 현재 작업 기록 같은 컨텍스트가 여러 턴에서 반복될 수 있다.

따라서 에이전트 비용을 단순히 입력 토큰 가격과 출력 토큰 가격으로만 보는 것은 점점 부족해진다.

캐시 적중률, 도구 호출 횟수, 실패와 재시도, 작업을 끝내기 위해 필요한 전체 턴 수가 실제 비용을 결정한다.

둘의 가격표는 같지만 비용 구조는 같지 않다

기본 가격만 보면 Astra와 Fable 5.1은 같다.

모델 입력 / 1M 캐시 입력·읽기 / 1M 출력 / 1M
GPT-6 Astra $10 $1 $50
Claude Fable 5.1 $10 $0.25 $50

하지만 실제 작업 비용까지 같다는 뜻은 아니다.

Astra는 비동기 도구 호출과 steering처럼 에이전트 실행 방식 자체를 바꿀 수 있는 기능을 제공한다.

Fable 5.1은 반복 컨텍스트가 많은 작업에서 캐시 비용을 크게 낮추는 방향을 선택했다.

그리고 모델마다 하나의 작업을 끝내기 위해 소비하는 토큰과 도구 호출 횟수도 다를 수 있다.

결국 개발자가 봐야 하는 숫자는 점점 cost per token보다 cost per completed task 가까워진다.

비싼 모델이 더 적은 시도와 토큰으로 작업을 끝내면 결과적으로 더 저렴할 수도 있다. 반대로 토큰 단가는 같아도 긴 컨텍스트를 계속 다시 읽거나 실패와 재시도가 많으면 실제 비용은 올라간다.

직접 사용했을 때의 차이도 이 관점에서 볼 수 있었다. Astra가 일부를 놓쳐 두세 번의 짧은 피드백이 필요하더라도 전체 작업 시간이 짧다면 효율적일 수 있다. 반대로 Fable 5.1이 더 오래 생각하더라도 한 번에 원하는 결과를 만들어낸다면 사람의 개입 비용까지 포함했을 때 더 나은 선택일 수 있다.

모델 비교도 응답 단위에서 작업 단위로 바뀐다

실제 에이전트에서는 문제를 푸는 과정 자체가 중요하다.

파일을 찾고, 코드를 수정하고, 테스트를 실행하고, 실패하면 원인을 찾아 다시 수정한다. 사용자가 중간에 조건을 바꾸면 그 요구를 반영하고 결국 완료 가능한 결과를 만들어야 한다.

그래서 이제는 단순 정확도 외에도 이런 질문이 중요해진다.

  • 하나의 작업을 끝내는 데 몇 번의 도구 호출이 필요한가?
  • 실패했을 때 스스로 복구할 수 있는가?
  • 장시간 작업에서 처음의 요구사항을 유지하는가?
  • 중간에 새로운 요구가 들어왔을 때 방향을 바꿀 수 있는가?
  • 같은 컨텍스트를 반복할 때 비용이 얼마나 발생하는가?
  • 사람이 결과를 확인하고 다시 지시하는 데 얼마나 많은 시간이 필요한가?
  • 결국 작업 하나를 완료하는 데 얼마가 드는가?

AutomationBench나 Terminal-Bench 같은 agentic benchmark가 점점 중요해지는 이유도 여기에 있다.

물론 이 벤치마크들도 현실의 모든 개발 작업을 대표하지는 않는다. 특히 내가 느낀 Astra의 속도와 Fable 5.1의 완성도 차이처럼 실제 작업에서 체감하는 요소를 하나의 점수로 표현하기는 어렵다.

OpenAI와 Anthropic은 같은 문제를 다른 방향에서 보고 있다

이번 두 모델을 보면 경쟁 방향의 차이도 보인다.

OpenAI는 Astra에서 에이전트가 오래 작업하는 동안 어떻게 실행을 이어가고 제어할 것인가를 API 수준에서 강화했다. 비동기 도구 호출로 기다리는 시간을 줄이고, mid-turn steering으로 실행 도중 사용자의 새로운 요구를 받을 수 있게 했다.

Anthropic은 Fable 5.1에서 장시간 문제 해결 성능을 높이면서 동시에 반복되는 컨텍스트를 얼마나 경제적으로 처리할 것인가를 건드렸다.

둘 중 하나가 더 올바른 방향이라는 뜻은 아니다. 실제 에이전트에는 둘 다 필요하다.

오래 일할 수 있어야 하고, 도구를 효율적으로 사용할 수 있어야 하고, 작업 도중 인간이 개입할 수 있어야 하며, 그 모든 과정의 비용도 감당할 수 있어야 한다.

그리고 실제로 사용해보면 여기에 한 가지가 더 붙는다.

사람이 그 모델과 어떤 방식으로 일하고 싶은가.

빠르게 결과를 받고 사람이 세부 사항을 확인하며 반복할 것인지, 아니면 더 오래 기다리더라도 한 번에 높은 완성도의 결과를 받을 것인지에 따라 같은 모델의 가치도 달라진다.

지금 둘 중 하나를 고른다면

현재의 개인적인 사용 경험만 놓고 보면 나는 작업 방식에 따라 둘을 나눠 사용할 것 같다.

빠르게 초안을 만들고, 코드를 수정하고, 내가 결과를 직접 확인하면서 짧은 피드백 루프를 반복할 수 있는 작업이라면 Astra가 잘 맞았다. 완성도도 충분히 높았고 무엇보다 빠른 진행이 장점이었다.

다만 세부적인 조건까지 모델이 전부 알아서 챙겨주길 기대한다면 놓친 부분이 눈에 띌 수 있었다. 이 경우에는 사람이 마지막 검수자가 되어야 한다.

반대로 작업 시간이 조금 길어져도 괜찮고, 가능하면 처음 지시한 내용을 넓게 검토해서 한 번에 만족스러운 결과를 받고 싶다면 Fable 5.1 쪽의 경험이 더 좋았다.

정리하면 지금의 선택 기준은 이렇다.

조금 더 신경 써서 같이 작업한다면 Astra. 한 번에 맡기고 결과를 기다리고 싶다면 Fable 5.1.

이 판단은 어디까지나 현재 내가 수행한 작업에서 얻은 개인적인 경험이다. 모델과 제품은 빠르게 바뀌고, 작업 종류에 따라서도 결과는 달라질 수 있다.

하지만 바로 그 점 때문에 모델 비교를 벤치마크 점수 하나로 끝내기 어려워졌다.

이제 개발자는 어떤 모델이 더 똑똑한지만 보면 안 된다

GPT-6 Astra와 Claude Fable 5.1이 거의 같은 시기에 나왔기 때문에 자연스럽게 둘을 경쟁 모델로 비교하게 된다.

하지만 이번 발표에서 더 중요한 변화는 AI 모델이 점점 응답을 생성하는 도구에서 작업을 수행하는 실행 주체에 가까워지고 있다는 점이다.

그렇게 되면 모델을 선택하는 기준도 달라진다.

단순한 지능 점수뿐 아니라 API가 장시간 작업을 어떻게 지원하는지, 반복 컨텍스트 비용이 얼마인지, 작업 도중 사람이 얼마나 쉽게 개입할 수 있는지, 실패했을 때 얼마나 적은 비용으로 다시 정상 흐름으로 돌아오는지를 봐야 한다.

그리고 실제 사용하는 사람 입장에서는 속도와 결과물의 완성도, 사람이 개입해야 하는 횟수까지 함께 봐야 한다.

최종적으로는 토큰 하나의 가격보다 하나의 작업을 완료하는 가격이 더 중요해진다.

좋은 응답을 만드는 모델

작업을 끝내는 모델

GPT-6 Astra와 Claude Fable 5.1의 경쟁에서 흥미로운 것은 어느 모델이 벤치마크에서 몇 점 더 높은지가 아니다.

AI 모델을 평가하는 단위가 한 번의 응답에서 하나의 작업으로 바뀌고 있다는 점이다.

출처


이 글은 OpenAI와 Anthropic의 2026년 9월 공식 발표와 API 문서를 기준으로 작성했다. 각 회사가 공개한 벤치마크와 비용 절감 수치는 해당 회사의 평가 환경과 실제 사용 데이터에 기반한 결과이므로 독립적인 절대 성능·비용 비교로 해석하지 않았다. 모델 사용감에 관한 내용은 필자가 실제 개발 작업에서 두 모델을 사용하며 느낀 개인적인 경험이며 작업 종류, 도구 환경, 프롬프트에 따라 달라질 수 있다. 자료 조사, 초안 정리와 문장 교정에는 AI 도구를 활용했다.

공유