diff --git a/content/posts/gpt-6-astra-vs-claude-fable-5-1.md b/content/posts/gpt-6-astra-vs-claude-fable-5-1.md
new file mode 100644
index 0000000..66f4b0b
--- /dev/null
+++ b/content/posts/gpt-6-astra-vs-claude-fable-5-1.md
@@ -0,0 +1,269 @@
+---
+title: "GPT-6 Astra와 Claude Fable 5.1, AI 경쟁의 기준이 달라지고 있다"
+description: "GPT-6 Astra와 Claude Fable 5.1이 같은 주에 등장했다. 벤치마크뿐 아니라 직접 사용하며 느낀 속도와 완성도 차이, 에이전트의 성능·비용·제어 문제를 함께 살펴본다."
+date: "2026-09-06"
+tags: ["openai", "anthropic", "gpt-6", "claude", "ai-agent", "api"]
+category: "industry"
+draft: false
+pinned: false
+---
+
+2026년 9월 첫째 주, Anthropic과 OpenAI가 며칠 간격으로 새 모델을 내놨다.
+
+Anthropic은 9월 1일 [Claude Fable 5.1](https://www.anthropic.com/claude-fable-and-mythos-5-1)을 공개했고, OpenAI는 9월 3일 [GPT-6 Astra](https://openai.com/index/gpt-6-astra/)를 발표했다.
+
+둘 다 코딩과 장시간 작업을 중요한 사용 사례로 내세운다.
+
+그래서 처음에는 자연스럽게 성능 비교부터 보게 된다. 어느 모델이 더 높은 점수를 받았는지, 코딩에서는 누가 앞서는지, 컨텍스트는 얼마나 긴지 같은 숫자들이다.
+
+하지만 두 발표를 같이 놓고 보면 더 흥미로운 변화가 있다.
+
+**AI 모델을 평가하는 기준이 한 번의 응답 성능에서 하나의 작업을 끝내는 능력으로 이동하고 있다.**
+
+GPT-6 Astra에서는 비동기 도구 호출과 작업 도중 사용자 개입이 API의 핵심 기능으로 들어왔고, Claude Fable 5.1에서는 장시간 에이전트 작업에서 반복되는 컨텍스트 비용을 줄이는 방향이 강조됐다.
+
+두 회사가 같은 문제를 완전히 같은 방식으로 풀고 있는 것은 아니다. 하지만 둘 다 이제 모델이 질문에 답하는 몇 초가 아니라, 여러 도구를 사용하며 오래 작업하는 상황을 전제로 제품을 설계하고 있다.
+
+## 먼저 성능은 어떻게 달라졌을까
+
+OpenAI는 GPT-6 Astra를 복잡한 end-to-end 작업을 위한 자사의 가장 강력한 모델로 소개한다.
+
+OpenAI가 공개한 비교에서 [AutomationBench](https://openai.com/index/gpt-6-astra/) 점수는 GPT-6 Astra가 **41.4%**, Claude Fable 5.1이 **31.4%**다.
+
+AutomationBench는 여러 단계의 실제 업무 자동화 능력을 평가하는 벤치마크라서 이번 글의 주제인 에이전트 작업과도 꽤 직접적으로 연결된다.
+
+다만 이 숫자 하나를 가지고 Astra가 Fable 5.1보다 전반적으로 더 좋은 모델이라고 결론 내리는 것은 어렵다. 평가마다 사용하는 도구, harness, reasoning 설정이 다를 수 있고 모델 공급자가 직접 공개한 결과라는 점도 고려해야 한다.
+
+Anthropic이 공개한 [Fable 5.1 평가](https://www.anthropic.com/claude-fable-and-mythos-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의 모델 사양은 눈에 띈다.
+
+[공식 모델 문서](https://developers.openai.com/api/docs/models/gpt-6-astra)에 따르면 Astra는 **1,050,000 토큰 컨텍스트 윈도우**와 **128,000 토큰 최대 출력**을 지원한다.
+
+가격은 100만 토큰 기준 입력 **$10**, 캐시 입력 **$1**, 출력 **$50**이다. 272K 입력 토큰을 넘는 요청은 전체 요청에 더 높은 장문 요금이 적용된다.
+
+하지만 더 중요한 변화는 이 숫자들이 아니다.
+
+OpenAI는 Astra와 함께 [async tool calling](https://developers.openai.com/api/docs/guides/async-tool-calling)을 도입했다.
+
+일반적인 tool calling에서는 모델이 도구를 호출하면 애플리케이션이 결과를 돌려줄 때까지 해당 턴이 사실상 멈춘다. Astra에서는 도구를 `async: true`로 정의할 수 있다.
+
+그러면 모델은 한 도구의 실행 결과를 기다리는 동안 다른 도구를 호출하거나, 독립적으로 처리할 수 있는 부분을 계속 추론할 수 있다.
+
+```text
+Model
+  ├─ Tool A 호출 ───────┐
+  ├─ Tool B 호출 ────┐  │
+  │                  │  │
+  ├─ 다른 작업 계속   │  │
+  │                  ↓  ↓
+  └──────────── Tool 결과 반영
+```
+
+물론 OpenAI가 도구를 대신 실행해주는 것은 아니다. 공식 문서에서도 도구 실행과 pending work 관리는 여전히 애플리케이션의 책임이라고 명시한다.
+
+즉 Astra가 해결하는 것은 작업 큐 자체가 아니라 **모델의 추론 흐름이 느린 도구 하나에 묶이지 않도록 하는 부분**이다.
+
+에이전트가 검색, 빌드, 테스트, 외부 API 호출을 여러 번 수행하는 구조에서는 꽤 큰 차이가 될 수 있다.
+
+## 작업 중간에 사용자가 방향을 바꿀 수도 있다
+
+Astra에서 또 하나 흥미로운 기능은 [mid-turn steering](https://developers.openai.com/api/docs/guides/steering)이다.
+
+기존의 일반적인 요청/응답 구조에서는 모델이 긴 작업을 수행하기 시작하면 작업이 끝난 뒤 새로운 요청으로 수정사항을 보내는 흐름이 자연스러웠다.
+
+Astra의 steering은 작업이 진행되는 동안 추가 사용자 지시를 전달할 수 있게 한다.
+
+예를 들어 에이전트에게 프로젝트 전체를 수정하라고 요청했는데 작업 중간에:
+
+> 데이터베이스 마이그레이션은 건드리지 마.
+
+같은 조건을 추가할 수 있다.
+
+몇 초짜리 답변이라면 끝날 때까지 기다리면 된다. 하지만 에이전트가 몇 분, 혹은 그 이상 작업한다면 이야기가 달라진다.
+
+결국 장시간 실행되는 에이전트에는 **실행을 시작하는 API뿐 아니라 실행 중인 작업을 제어하는 API**가 필요해진다.
+
+OpenAI가 [Responses API를 신규 프로젝트에 권장](https://developers.openai.com/api/docs/guides/migrate-to-responses)하고 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](https://www.anthropic.com/claude-fable-and-mythos-5-1)로 변경했다.
+
+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가 장시간 작업을 어떻게 지원하는지, 반복 컨텍스트 비용이 얼마인지, 작업 도중 사람이 얼마나 쉽게 개입할 수 있는지, 실패했을 때 얼마나 적은 비용으로 다시 정상 흐름으로 돌아오는지를 봐야 한다.
+
+그리고 실제 사용하는 사람 입장에서는 속도와 결과물의 완성도, 사람이 개입해야 하는 횟수까지 함께 봐야 한다.
+
+최종적으로는 토큰 하나의 가격보다 하나의 작업을 완료하는 가격이 더 중요해진다.
+
+```text
+좋은 응답을 만드는 모델
+        ↓
+작업을 끝내는 모델
+```
+
+GPT-6 Astra와 Claude Fable 5.1의 경쟁에서 흥미로운 것은 어느 모델이 벤치마크에서 몇 점 더 높은지가 아니다.
+
+**AI 모델을 평가하는 단위가 한 번의 응답에서 하나의 작업으로 바뀌고 있다는 점이다.**
+
+## 출처
+
+- [OpenAI - GPT-6 Astra: A new generation of intelligence](https://openai.com/index/gpt-6-astra/)
+- [OpenAI API - GPT-6 Astra Model](https://developers.openai.com/api/docs/models/gpt-6-astra)
+- [OpenAI API - Model guidance](https://developers.openai.com/api/docs/guides/latest-model)
+- [OpenAI API - Async tool calling](https://developers.openai.com/api/docs/guides/async-tool-calling)
+- [OpenAI API - Mid-turn steering](https://developers.openai.com/api/docs/guides/steering)
+- [OpenAI API - Migrate to the Responses API](https://developers.openai.com/api/docs/guides/migrate-to-responses)
+- [Anthropic - Introducing Claude Fable 5.1 and Claude Mythos 5.1](https://www.anthropic.com/claude-fable-and-mythos-5-1)
+
+---
+
+이 글은 OpenAI와 Anthropic의 2026년 9월 공식 발표와 API 문서를 기준으로 작성했다. 각 회사가 공개한 벤치마크와 비용 절감 수치는 해당 회사의 평가 환경과 실제 사용 데이터에 기반한 결과이므로 독립적인 절대 성능·비용 비교로 해석하지 않았다. 모델 사용감에 관한 내용은 필자가 실제 개발 작업에서 두 모델을 사용하며 느낀 개인적인 경험이며 작업 종류, 도구 환경, 프롬프트에 따라 달라질 수 있다. 자료 조사, 초안 정리와 문장 교정에는 AI 도구를 활용했다.