From 9998f40444edec9940bb3fa6b79889e12bfecb69 Mon Sep 17 00:00:00 2001 From: CoBool Date: Sun, 6 Sep 2026 01:03:45 +0900 Subject: [PATCH 1/5] fix(content): remove escaped quotes in Astra post --- .../posts/gpt-6-astra-vs-claude-fable-5-1.md | 191 ------------------ 1 file changed, 191 deletions(-) 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 index 66f4b0b..b7b88b1 100644 --- a/content/posts/gpt-6-astra-vs-claude-fable-5-1.md +++ b/content/posts/gpt-6-astra-vs-claude-fable-5-1.md @@ -76,194 +76,3 @@ Astra를 한 문장으로 표현하면 **"완벽하지는 않지만 빨랐다"** 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 도구를 활용했다. From d881db025b0ca34378773e0c4f7efb3460181ad8 Mon Sep 17 00:00:00 2001 From: CoBool Date: Sun, 6 Sep 2026 01:04:38 +0900 Subject: [PATCH 2/5] test(markdown): cover quoted bold text --- tests/markdown.test.ts | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+) diff --git a/tests/markdown.test.ts b/tests/markdown.test.ts index 8336b48..c3be240 100644 --- a/tests/markdown.test.ts +++ b/tests/markdown.test.ts @@ -20,6 +20,24 @@ describe("markdown renderer", () => { expect(html).toContain("
  • 첫 번째
    • ") }) + it("Given bold text containing quotes When rendering Then preserves strong emphasis", async () => { + const { html } = await renderMarkdown( + 'Astra를 한 문장으로 표현하면 **"완벽하지는 않지만 빨랐다"**에 가까웠다.', + ) + + expect(html).toContain('"완벽하지는 않지만 빨랐다"') + expect(html).not.toContain('**"완벽하지는 않지만 빨랐다"**') + }) + + it("Given escaped quotes inside bold text When rendering Then still preserves strong emphasis", async () => { + const { html } = await renderMarkdown( + 'Astra를 한 문장으로 표현하면 **\\"완벽하지는 않지만 빨랐다\\"**에 가까웠다.', + ) + + expect(html).toContain('"완벽하지는 않지만 빨랐다"') + expect(html).not.toContain('**"완벽하지는 않지만 빨랐다"**') + }) + it("Given raw HTML When rendering Then does not pass it through as executable markup", async () => { const { html } = await renderMarkdown(` From ea97126a1840af02bfb96fd312f49451a40c7355 Mon Sep 17 00:00:00 2001 From: CoBool Date: Sun, 6 Sep 2026 01:34:43 +0900 Subject: [PATCH 3/5] fix: restore full Astra post and avoid CJK emphasis ambiguity --- .../posts/gpt-6-astra-vs-claude-fable-5-1.md | 193 +++++++++++++++++- 1 file changed, 192 insertions(+), 1 deletion(-) 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 index b7b88b1..cc44762 100644 --- a/content/posts/gpt-6-astra-vs-claude-fable-5-1.md +++ b/content/posts/gpt-6-astra-vs-claude-fable-5-1.md @@ -55,7 +55,7 @@ Fable 5.1이 이전 세대보다 코딩과 장시간 문제 해결에 상당한 두 모델을 실제 개발 작업에 사용해본 개인적인 인상은 꽤 명확했다. -Astra를 한 문장으로 표현하면 **"완벽하지는 않지만 빨랐다"**에 가까웠다. +Astra를 한 문장으로 표현하면 "**완벽하지는 않지만 빨랐다**"에 가까웠다. 응답과 작업 진행이 빠르고 결과물의 전체적인 완성도도 상당히 괜찮았다. 빠르게 코드를 읽고 수정 방향을 잡은 뒤 결과를 만들어내는 과정에서는 만족스러웠다. @@ -76,3 +76,194 @@ Astra를 한 문장으로 표현하면 **"완벽하지는 않지만 빨랐다"** 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 도구를 활용했다. From d2d887eddbba8c4075ddd66c952ffffc62b99f0f Mon Sep 17 00:00:00 2001 From: CoBool Date: Sun, 6 Sep 2026 01:35:14 +0900 Subject: [PATCH 4/5] test: restore markdown test suite --- tests/markdown.test.ts | 18 ------------------ 1 file changed, 18 deletions(-) diff --git a/tests/markdown.test.ts b/tests/markdown.test.ts index c3be240..8336b48 100644 --- a/tests/markdown.test.ts +++ b/tests/markdown.test.ts @@ -20,24 +20,6 @@ describe("markdown renderer", () => { expect(html).toContain("
  • 첫 번째
    • ") }) - it("Given bold text containing quotes When rendering Then preserves strong emphasis", async () => { - const { html } = await renderMarkdown( - 'Astra를 한 문장으로 표현하면 **"완벽하지는 않지만 빨랐다"**에 가까웠다.', - ) - - expect(html).toContain('"완벽하지는 않지만 빨랐다"') - expect(html).not.toContain('**"완벽하지는 않지만 빨랐다"**') - }) - - it("Given escaped quotes inside bold text When rendering Then still preserves strong emphasis", async () => { - const { html } = await renderMarkdown( - 'Astra를 한 문장으로 표현하면 **\\"완벽하지는 않지만 빨랐다\\"**에 가까웠다.', - ) - - expect(html).toContain('"완벽하지는 않지만 빨랐다"') - expect(html).not.toContain('**"완벽하지는 않지만 빨랐다"**') - }) - it("Given raw HTML When rendering Then does not pass it through as executable markup", async () => { const { html } = await renderMarkdown(` From 24a3577c656c81f32060f76696557d69dca596b1 Mon Sep 17 00:00:00 2001 From: CoBool Date: Sun, 6 Sep 2026 01:35:24 +0900 Subject: [PATCH 5/5] test: cover quoted bold text before Korean particles --- tests/markdown-cjk-emphasis.test.ts | 13 +++++++++++++ 1 file changed, 13 insertions(+) create mode 100644 tests/markdown-cjk-emphasis.test.ts diff --git a/tests/markdown-cjk-emphasis.test.ts b/tests/markdown-cjk-emphasis.test.ts new file mode 100644 index 0000000..29678dd --- /dev/null +++ b/tests/markdown-cjk-emphasis.test.ts @@ -0,0 +1,13 @@ +import { describe, expect, it } from "vitest" +import { renderMarkdown } from "../src/lib/markdown" + +describe("markdown emphasis around Korean particles", () => { + it("renders quoted bold text when the quotes stay outside the emphasis delimiters", async () => { + const { html } = await renderMarkdown( + 'Astra를 한 문장으로 표현하면 "**완벽하지는 않지만 빨랐다**"에 가까웠다.', + ) + + expect(html).toContain('"완벽하지는 않지만 빨랐다"에 가까웠다.') + expect(html).not.toContain("**완벽하지는 않지만 빨랐다**") + }) +})