Fable 5.1과 Astra, 개발 워크플로의 승부가 갈리다

원문 제목: Fable Vs Astra Debate Is Over
채널: t3dotgg
영상 URL: https://www.youtube.com/watch?v=P7bxbDSnZRM

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

Fable 5.1은 안정성·의도 파악·스킬 사용·코드 병합성에서 앞서고, Astra는 3D 렌더링·컴퓨터 사용(computer use)·대규모 오케스트레이션(orchestration)에서 세대적 도약을 보여준다. ==실무의 정답은 하나를 고르는 것이 아니라 Astra로 넓게 탐색하고 Fable 5.1로 정교하게 마무리하는 조합에 가깝다.==

핵심 주장

1. Fable 5.1은 더 꾸준한 실무형 모델이다. 작은 버그 수정, 중요한 UI 변경, 병합 가능한 풀 리퀘스트(pull request), 기존 의도와 스타일 보존에서 적은 감독으로 결과를 낸다.
2. Astra는 더 넓은 가능성을 여는 모델이다. 3D·컴퓨터 사용·40개 에이전트 규모의 스웜(swarm) 작업에서는 Fable이 따라가기 어려운 능력을 보이지만, 성능 편차·망각·범위 팽창(scope creep)이 크다.

근거 3개

• Terminal-Bench Science 0.1에서 Fable 5.1의 최고 조건은 약 50% 성공률과 34달러보다 낮은 비용을 보였지만, Astra는 Low 설정만으로 54.3% 성공률과 11달러를 기록했다.
• TypeScript를 Rust로 옮기는 대규모 재작성에서 GPT-5.6 Soul의 약 30% 테스트 정확도를 Astra가 약 3일 만에 80% 이상으로 끌어올렸지만 82.6%에서 정체됐다.
• 실제 PR의 제출부터 병합까지 필요한 추가 후속 작업은 Fable 5.1이 평균 2회, Astra가 평균 6회였고, 150개 PR을 무감독에 가깝게 병합한 뒤 발생한 2건의 회귀(regression)는 모두 Astra에서 나왔다.

핵심 논점

Astra의 최고점은 Fable 5.1보다 훨씬 높지만 최저점도 더 위험하다. Astra는 멋진 3D 결과, 빠른 데스크톱 조작, 동적으로 소통하는 하위 에이전트 집단을 만들 수 있다. 반대로 기존 UI를 보존하라는 명시적 지시를 무시하거나, 한 줄짜리 수정에 1,000줄짜리 PR을 만들거나, 이미 선택한 스킬을 다음 턴에 잊는 식의 실패도 낸다. Fable 5.1은 극적인 돌파보다 평균적인 작업 품질과 병합 가능성을 중시하는 선택이며, Astra는 검증 루프와 감독을 감수할 때 더 큰 문제를 풀 수 있는 선택이다.

1. 비교의 범위와 사용 조건

1.1. 비교 대상과 개인 사용량

1. Theo는 초반에 Gemini 38 Flash와 Muse Spark 1.3을 거론하며 새 모델이 쏟아지는 상황을 농담으로 비튼 뒤, 실제 비교 대상은 Fable 5.1과 GPT6 Astra라고 정리한다.

   • 두 모델 모두 단순한 신기술이 아니라 매일 업무에 투입할 수 있는 프런티어 모델(frontier model)로 취급된다.
   • Fable 5.1은 예상보다 훨씬 뛰어나 매일 사용하게 된 모델이고, Astra는 미래의 작업 방식을 미리 보여주는 모델로 평가된다.

2. Astra에는 하루 수천 달러 규모의 추론(inference)이 투입되고, 두 모델을 합쳐 하루 거의 10억 토큰을 꾸준히 사용한 경험이 비교의 기반이 된다.

   • 이 사용량은 짧은 프롬프트 몇 개를 시험한 체험담이 아니라 코드베이스, PR, 컴퓨터, 대규모 재작성에 지속적으로 모델을 붙인 결과다.
   • 비교 기준은 과학, 3D, 컴퓨터 사용, 카피라이팅, 오디오·비디오, 프런트엔드, 풀스택, 코드 에이전트, 비용, 구독 한도, 토큰 효율이다.

1.2. 스폰서 세그먼트: Macroscope

1. 에이전트가 검증되지 않은 코드를 대량으로 추가하면서 저장소가 점점 일관성을 잃는 문제가 출발점으로 제시된다.

   • AGENTS.md 같은 지침 파일은 에이전트에게 규칙을 알려줄 뿐, 실제 코드 리뷰에서 규칙 준수를 강제하지는 못한다.
   • 아키텍처, 정적 검사(static check), 린트(lint), UI 시스템을 모두 지키는지 자동으로 확인할 별도 검토 에이전트가 필요하다.

2. Macroscope는 저장소에 특정 행동을 요구하는 마크다운 파일을 두고, 지정된 경로가 수정될 때 조건을 만족해야 승인하는 사용자 정의 에이전트를 제공한다.

   • T3 Code는 오픈 PR 1,000개에 가까워지고 있으며, UI 요소마다 툴팁 패턴이 달라지는 문제를 막기 위해 UI 일관성 에이전트를 추가했다.
   • 효과 서비스 관례와 UI 일관성 런타임 에이전트가 모든 PR을 검사한다.

3. 하위 에이전트의 검토 시간은 각각 약 12초와 21초였고, 상위 Macroscope 에이전트가 결과를 모아 병합 승인 등급을 낸다.

   • Theo는 Macroscope 승인 없이 PR을 병합하는 일이 드물다고 말한다.
   • 빠른 생성보다 빠른 검증과 일관성 보장이 에이전트 시대의 저장소 운영에서 중요하다는 맥락을 제공한다.

2. 과학·3D·컴퓨터 사용·카피라이팅

2.1. 과학 벤치마크와 추론 효율

1. Fable 5.1의 출시 노트는 도구를 사용해 현실 문제를 푸는 어려운 과학 벤치마크인 Terminal-Bench Science 0.1의 개선을 강조했다.

   • Fable 5의 최고 조건은 XH High가 아니라 High에서 34달러 비용과 25% 성공률이었다.
   • Fable 5.1은 XH High에서 비용을 낮추면서 성공률을 50%까지 끌어올렸다.

2. Astra의 출시 결과는 같은 비교를 완전히 다르게 보이게 만든다.

   • Astra Low는 11달러만으로 54.3% 성공률을 기록했다.
   • 가장 비싼 Fable 5.1보다 세 배 이상 저렴한 Astra Low가 성공률에서 앞선다.
   • 과학 작업이 핵심이라면 Codex 구독이 합리적인 선택이라는 결론이 나온다.

3. 두 모델의 과학 능력이 함께 급상승한 원인으로 새로운 학습 데이터나 강화학습 도구(RL tooling)의 공유·확산 가능성이 제기된다.

   • 후훈련(post-training)에 유용한 기술을 OpenAI가 확보했고, 후훈련에 강한 조직 역량으로 더 잘 적용했을 수 있다는 가설이다.
   • 이는 확정된 원인이라기보다 관찰된 성능 상승을 설명하기 위한 추론이다.

2.2. 3D 렌더링: Astra의 가장 큰 격차

1. Fable 5.1의 ‘Fish Slop’은 잠수함으로 물고기를 먹이고, 작은 경제 시스템과 전투를 수행하는 3D 게임이다.

   • 물고기의 눈 위치가 자연스럽고 산호·바위·조명이 작동한다.
   • 잠수함의 부유 이동이 부드럽고 조작감이 좋아 당시 가장 인상적인 Fish Slop으로 평가된다.
   • 모델과 게임 루프를 더 다듬을 여지는 있지만, 단순한 장난감 이상으로 플레이할 만한 출발점이다.

2. Astra의 Fish Slop은 시각적 품질에서 세대 차이를 만든다.

   • 실제 게임처럼 보일 정도로 모델링과 장면 구성이 좋아져 ‘slop’이라는 표현을 떼도 될 수준에 가까워진다.
   • 초기 버전은 이동감이 Fable보다 나빴고 핵심 루프가 덜 다듬어졌으며, 성능 문제는 수정 지시를 한 뒤에야 개선됐다.
   • 그래도 전체적인 3D 표현력은 Fable 5.1보다 압도적으로 앞선다.

3. Astra로 Blender를 사용해 Amazon Spheres를 재현한 사례와, 창문 밖 배경·가구까지 갖춘 데모 홈 사례는 3D의 실용적 전환을 보여준다.

   • 두 사례는 단순한 이미지 생성이 아니라 실제 환경 목업(mockup)에 쓸 수 있는 3D 결과다.
   • 자동완성 에이전트에서 실제 작업을 끝내는 에이전트로 넘어간 변화에 비견된다.

2.3. 게임 개발과 상호작용

1. Astra는 화면과 3D 오브젝트를 훨씬 잘 만들지만, Fable 5.1은 상호작용의 가장자리(edge)를 더 잘 다듬는다.

   • 커서가 특정 위치에 갔을 때 애니메이션이 자연스럽게 변하는지 확인한다.
   • 카메라가 마우스 움직임에 맞춰 적절한 양만큼 회전하는지, 캐릭터 이동 속도와 애니메이션 곡선(animation curve)이 자연스러운지 개선한다.

2. 가장 효율적인 조합은 Astra로 첫 프로토타입을 만들고 Fable 5.1로 상호작용과 세부 동작을 정리하는 방식이다.

   • Astra는 무거운 망치처럼 큰 형태를 빠르게 만들고, Fable은 섬세하게 손질하는 도구에 가깝다.
   • Astra는 소셜 미디어에서 더 좋아 보이는 게임을 만들고, Fable은 실제로 더 편하게 플레이되는 게임을 만든다.

3. 두 모델만으로 완성도 높은 게임을 자동 생산할 수는 없지만, 역할을 나누면 충분히 좋은 게임을 반복 개선할 가능성이 생긴다.

   • 연말까지 Steam 인디 게임 상위 20위 안에 들어가는, 대부분의 요소를 AI로 만든 게임이 처음 등장할 수 있다는 전망이 제시된다.

2.4. 컴퓨터 사용: Astra의 또 다른 압승

1. Astra는 컴퓨터 사용 속도와 이해도에서 Fable을 크게 앞선다.

   • GPT-5.6 Soul도 일상적인 컴퓨터 작업에 쓸 만큼 큰 도약이었지만, Astra는 사람이 직접 하는 것보다 더 빨리 끝내는 작업이 자주 나온다.
   • Theo는 컴퓨터 사용을 24시간 돌리기 위해 Mac Mini를 한 대 더 마련했다.

2. 격차는 모델 자체뿐 아니라 Codex의 macOS 통합 개선에서도 나온다.

   • 컴퓨터 사용 세션을 더 빨리 시작하고, 필요한 컨텍스트를 더 빨리 가져오며, 화면 안에서 더 빠르게 이동한다.
   • 백그라운드에서 작업을 처리하는 능력도 좋아졌다.
   • 손을 다친 상태에서 반복적인 실제 컴퓨터 작업을 맡길 수 있다는 점이 특히 편리하게 작용한다.

3. Fable도 적절한 도구를 주면 컴퓨터를 사용할 수 있지만, Astra와 비교할 수준은 아니다.

   • OpenAI 계열 모델이 코드에서 보이던 엉뚱한 누락이 Fable의 컴퓨터 사용에서 나타나는 역전된 인상이 언급된다.

2.5. 카피라이팅과 UI 문구

1. Fable 5.1과 Astra는 이전 모델보다 읽기 쉬운 카피를 만들며, 출력물에 내장된 ‘언슬롭(unslop)’ 효과가 느껴진다.

   • Fable 5에서 Fable 5.1로 바꾸면 별도 Agent.md나 Claude.md 없이도 문장이 훨씬 읽기 좋아진다.
   • GPT-5.6 Soul에서 Astra로 바꿔도 같은 개선이 나타난다.

2. 순수한 카피 품질은 Astra가 약간 앞선다.

   • Theo가 사용해 본 모델 중 가장 좋은 문장은 여전히 비사고형(non-thinking) Kimmy K2가 썼지만, Kimmy K2는 매우 둔하고 금방 무례해져 실무 모델로 쓰기 어렵다.
   • Astra는 Fable이 만든 카피의 문제를 더 잘 찾아내고 정리 제안을 낸다.
   • 두 모델 모두 웹페이지용 문장을 그대로 출하하기에는 부족해 대부분 다시 쓴다.

3. Astra는 UI에 불필요한 대문자 부제목(all-caps subtitle)을 반복 삽입하는 치명적인 습관이 있다.

   • Fish Slop 2D 페이지에는 정리 전 불필요한 부제목이 21개나 있었다.
   • “A little tank, a lot of life”, “Coral Coast”, “All systems go”, “A tiny world worth looking after” 같은 문구가 공간마다 쏟아졌다.
   • 온라인 배지와 “Captain, you’re home” 같은 문구까지 붙어 카피의 장점을 스스로 훼손했다.
   • 순수 능력은 Astra가 앞서도, UI 카피를 맡기고 싶지 않을 정도로 반복적 스팸이 심하다는 평가다.

2.6. 오디오·비디오 작업

1. Fable과 Astra가 AI로 직접 편집한 영상을 본 사람들은 많지만, Theo가 실제 결과물을 확인할 때마다 품질이 형편없었다.

2. 예외는 Ben Davis가 Astra의 컴퓨터 사용으로 Final Cut 편집 환경을 준비하는 시연이다.

   • Astra는 영상을 편집하지 않고, 편집자가 시작할 수 있도록 필요한 창·파일·타임라인을 미리 연다.
   • 코딩으로 치면 VS Code, 관련 파일, 올바른 위치의 터미널, GitHub, 작업 대상이 열린 개발 환경을 한 번에 마련하는 것과 같다.
   • 일을 대신하는 것이 아니라 작업 공간을 정리하고 준비한다는 점이 핵심이다.

3. 2020년 7월 GPT-3가 ‘잔액을 보여주고 3달러를 더하거나 5달러를 출금하는 React 앱’을 만든 시연이 현재의 AI 영상 편집과 비교된다.

   • 당시에는 작동하는 앱 생성이 충격적이었지만, 지금의 엔지니어에게는 첫 수업 주에 만들 만한 수준이다.
   • AI에게 콘텐츠·오디오·AV 파이프라인 전체를 맡기는 현재의 시도도 실제 업무 관점에서는 GPT-3 수준의 데모를 출하하는 것과 비슷하다.
   • Astra의 컴퓨터 사용이 편집 준비에 유용하므로 이 부문은 Astra의 무상 승리(free win)로 처리되지만, AI가 전문 영상 편집을 자동화하기에는 아직 멀었다.

3. 프런트엔드와 디자인

3.1. Astra의 개선

1. Astra는 프런트엔드 전반에서 크게 개선됐다.

   • 지시를 더 잘 따르고, 랜딩 페이지를 덜 진부하고 덜 민망하게 만든다.
   • 충분한 반복과 수정이 주어지면 좋은 디자인을 강제로 끌어낼 수 있다.

2. GPT-5.6 Soul의 Witch AI 예시는 괜찮지만 지연이 있고, “18,000명의 호기심 많은 사람에게 사랑받는” 같은 부제목과 불필요한 em dash, 반복적인 Tailwind 템플릿 디자인이 섞인다.

3. Astra는 같은 유형의 시안에서 한 단계 나아간다.

   • “A second brain”, “A lighter mind”, “Free to start” 같은 짧은 문구가 여전히 과도하게 들어가고 ‘little’이라는 단어가 한 페이지에 15번 반복된다.
   • 일부 폰트가 늦게 나타나고, 텍스트가 잘리며, 오래된 느낌의 디자인도 남지만, 화살표와 작은 애니메이션처럼 의미 있는 시각 요소가 생겼다.
   • Anthropic의 Claude Code 디자인 스킬을 켜면 폰트 실험이 조금 줄고, 실제 시작점으로 쓸 수 있는 시안이 나온다.

3.2. Fable 5.1의 우위

1. Fable 5.1은 같은 목업에서 독특한 스타일과 경로 애니메이션을 더 자연스럽게 구성한다.

   • 페이지 구조가 좋고 불필요한 부제목이 없으며, 요소가 들어오는 애니메이션이 완성도 높은 시작점을 만든다.
   • 한 번의 생성 결과만 보더라도 AI가 만든 티가 나지 않고, 맞춤 제작된 웹사이트처럼 보일 수 있다.

2. 디자인 점수의 절대 격차보다 두 모델 모두 5점에서 9점으로 올라가기 어렵다는 사실이 중요하다.

   • 3D 렌더링은 Astra 9점, Fable 5점으로 볼 수 있다.
   • 프런트엔드는 Astra와 Fable 모두 10점 만점에 5점 이하이며, 좋은 결과를 얻으려면 두 모델 모두 반복해서 강하게 교정해야 한다.
   • Fable은 적은 교정으로 준수한 결과에 도달하고, Astra는 더 많은 도움과 반복을 요구한다.

4. 풀스택 이해와 대규모 재작성

4.1. 풀스택 코드베이스 이해

1. Fable 5.1과 Astra는 프런트엔드·백엔드·클라이언트·서버가 어떻게 연결되는지 읽고, 전체 스택에 영향을 주는 합리적인 결정을 내릴 수 있다.

   • Fable이 처음으로 이 수준에 도달했고, GPT-5.6 Soul은 이해하는 척하면서 엔드투엔드 관계를 놓치는 일이 많았다.

2. Fable은 결과의 파급 효과와 엣지 케이스를 직관적으로 더 빨리 파악한다.

   • 코드를 읽고 결론을 낸 뒤 우려 사항을 설계에 반영한다.

3. Astra는 가능한 선택지를 여러 개 만든 뒤 각각을 스트레스 테스트하고 가정을 검증한다.

   • Fable이 처음부터 알아낸 답을 Astra가 훨씬 오래 탐색한 뒤 발견하는 패턴이 반복된다.
   • Fable은 더 빠르고 자연스럽고, Astra는 Fable이 놓친 깊은 버그를 찾을 가능성이 높다.
   • Astra는 가장 똑똑하지만 스스로는 멍청한 것처럼 행동하는 모델이며, 같은 일을 네 번씩 확인해 토큰과 시간을 더 쓴다.

4. 성능 분포는 두 모델의 핵심 차이다.

   • Fable의 성능은 비교적 안정적이다.
   • Astra는 경외감을 주는 순간과 월 600달러 이상을 내는 이유를 의심하게 만드는 순간이 극단적으로 교차한다.

4.2. TypeScript의 Rust 재작성

1. Astra는 TypeScript를 Rust로 옮기는 TSGO 재작성에 투입되어 실제 진전을 냈다.

   • GPT-5.6 Soul로는 거대한 TypeScript 테스트 스위트에서 약 30% 테스트 정확도에 도달했다.
   • Astra는 약 3일 만에 80%를 넘겼고, 최종적으로 82.6%까지 갔지만 그 지점에서 매우 강하게 정체됐다.

2. Theo는 이 작업에서 직접 루프에 들어가지 않고 목표만 지정한 뒤 40개의 하위 에이전트에게 맡겼다.

   • Astra는 하위 에이전트들을 병렬로 돌리며 대규모 작업을 실제로 진행했다.
   • 초기 접근 권한이 넓은 테스트 계정에서는 새 모델의 사용량이 과금되지 않아 1300억 토큰을 사용하며 한계를 시험할 수 있었다.

3. 같은 능력은 T3 Code 모바일 앱의 Swift 재작성과 GPUi 기반 Rust UI 프레임워크 재구축에도 사용됐다.

   • GPUi로 T3 Code를 다시 만들도록 한 실험은 실제로 작동하는 결과를 냈다.
   • 무료에 가까운 얼리 액세스 사용량이므로 일반 사용자가 그대로 재현할 수 있는 비용·한도 조건은 아니다.

4.3. ping.gg 재작성의 실패

1. ping.gg는 Theo가 공동 작업자를 스트림에 초대하고, OBS 같은 제작 도구에 게스트 영상을 레이어로 삽입하는 서비스다.

   • Y Combinator에 진출할 때 사용한 레거시 코드베이스이며, 대형 Twitch 스트리머들도 콜라보에 활용한다.
   • 원래 페이지는 디자이너이자 공동 창업자 Brin이 공들여 만든 맞춤형 UI였다.

2. Astra는 초기 T3 Stack에서 더 현대적인 버전으로 옮기는 업데이트를 1시간 20분 만에 완료했지만, 결과 UI를 사실상 폐기했다.

   • 기존 대시보드의 실제 상태 정보 대신 발표문이 화면 아래에 쌓였다.
   • 입장할 때 레이아웃이 크게 움직여 콘텐츠 제작자의 화면 구성을 깨뜨렸다.
   • 장치 설정을 펼쳐 직접 고르고 미리보기를 시작해야 했으며, 전체 화면은 정보가 적고 기술 데모처럼 보였다.

3. 가장 심각한 문제는 프롬프트가 명시한 보존 조건을 무시한 점이다.

   • “기능을 한 번에 하나씩 포팅하고, UI 코드를 최대한 재사용하라”는 문장이 두 번 들어갔다.
   • 두 버전 사이에 공유된 Tailwind 코드가 한 줄도 없었고, 좋은 기존 UI가 검정·흰색의 텍스트 중심 기술 슬롭으로 바뀌었다.
   • 100만 토큰 컨텍스트와 Ultra 모드를 사용했으므로 컨텍스트 압축(compaction)이나 미리보기 스냅샷의 탓으로 돌리기 어려웠다.

4. 대규모 UI 재작성에서는 Astra의 강점이 위험한 부작용으로 변한다.

   • UI를 더 잘 만들도록 개선한 능력이 기존 UI를 보존하지 않고 통째로 덮어버리는 망치 효과를 낳았을 수 있다.
   • “UI가 픽셀 단위로 동일하지 않으면 실패한 것”이라는 별도 문단을 매번 덧붙여야 할 정도라면, 의도 파악의 기본값이 충분하지 않다는 뜻이다.
   • UI가 포함된 대규모 포팅의 경우, 기존 화면이 그대로 유지될 것이라고 Astra를 신뢰해서는 안 된다.

5. 코드 병합성, 범위 관리, 게임 코드

5.1. 병합 가능한 코드

1. Fable 5.1은 코드 병합성(mergeability)에서 명확히 이긴다.

   • PR이 제출된 뒤 병합될 때까지 필요한 추가 후속 작업은 Fable 5.1이 평균 2회, Astra가 평균 6회다.
   • 이 수치는 AI 봇이 실수를 발견하고 수정하는 검증 루프의 횟수이자, 실제 병합까지 남은 작업량을 나타낸다.

2. Fable 5.1은 버그 수정·기능 추가·성능 개선처럼 범위가 명확한 변경을 거의 병합 직전 상태로 제출한다.

   • 필요한 변경을 하면서 범위를 불필요하게 넓히지 않고, 배포 가능한 결과를 내는 비율이 높다.

3. 모델 수준을 구분하면 과거의 격차를 현재에 그대로 적용하면 안 된다.

   • GPT-5.6 Soul은 기본 병합성이 10점 만점에 2~3점 정도였지만, 좋은 리뷰 봇과 검증 도구를 붙이면 작동하는 코드를 만들 수 있었다.
   • Fable 5는 Soul보다 실제 서비스에 병합 가능한 코드를 3~4배 더 많이 냈다.
   • Astra는 Fable 5와 비슷하거나 약간 앞선 수준이며, Fable 5.1과 비교하면 여전히 격차가 남는다.

4. Astra는 Fable 5보다 읽기 쉽고 더 꼼꼼하게 검증하는 장점이 있다.

   • 단일 기능을 집중적으로 고치는 상황에서는 Astra가 Fable 5보다 병합 가능성이 높은 결과를 내기도 한다.
   • 다만 범위 팽창을 허용하면 그 장점이 빠르게 상쇄된다.

5. Ben Davis조차 예상보다 Fable을 훨씬 많이 사용하게 됐다고 인정했다.

   • OpenAI와 Astra를 옹호하는 역할에 가까운 Ben도 Fable의 실제 코드 품질을 높게 평가했다.
   • Ben은 Cloud Code 계정을 세 개 정도 운용할 만큼 Fable을 실무에 투입하고 있다.

6. Astra가 막힌 PR을 Fable 5.1로 넘기는 패턴이 효과적이다.

   • Astra가 데스 루프(death loop)에 빠진 PR을 Fable 5.1에 전달하고, 필요 없는 것을 버린 뒤 실제로 도착하게 만들라고 하면 Fable이 더 잘 착륙시킨다.
   • Astra도 충분히 병합 가능한 코드를 내지만, Fable은 더 적은 감독으로 확실하게 병합시킨다.

5.2. 범위 팽창(scope creep)

1. Fable도 잘못된 리뷰 피드백을 잘못된 순간에 받으면 작업을 크게 부풀릴 수 있다.

2. Astra는 범위 팽창이 기본값에 가깝다.

   • 최소 변경을 명시해도 리뷰 에이전트가 보내는 리마인더가 컨텍스트를 부풀리고, 원래 50줄이면 될 작업이 1,000줄 PR로 변한다.
   • 사용자가 계속 루프 안에 있으면 방향을 되돌릴 수 있지만, Fable보다 더 많은 감독이 필요하다.

3. Astra의 문제는 단순히 코드가 나쁘다는 것이 아니라 작업 목표에 비해 너무 많은 일을 한다는 점이다.

   • Fable은 덜 화려해도 필요한 변경만 남기고 끝내는 경향이 강하다.

6. 에이전트 행동과 의도 파악

6.1. 실제 의도를 보존하는 능력

1. Anthropic 계열의 Fable은 사용자 의도 보존에서 Astra보다 앞선다.

   • Theo는 두 모델로 약 150개 PR을 거의 무감독 병합했고, 회귀는 2건뿐이었다.
   • 두 회귀 모두 Astra에서 발생했고, Astra로 원인을 고치는 과정도 특히 고통스러웠다.

2. T3 Code 마케팅 사이트의 후기 자동 스크롤 회귀는 Astra의 실패를 압축해서 보여준다.

   • 성능 개선 PR이 부드러운 자동 스크롤을 없애고, 가운데에 못생긴 스크롤 바가 있는 고정 가로 그리드로 바꿨다.
   • Theo는 “무엇이 깨뜨렸는지 찾아서 되돌리고, 자동 스크롤을 복구하라”고 같은 프롬프트에 revert를 두 번 넣었다.
   • Astra는 원래 PR을 찾아 되돌리지 않고 사용자 제어 변수를 삭제한 뒤 리스너 일부를 제거했다.
   • 변경은 자동 스크롤을 복구하지도 못했고, 실제 문제를 해결하지도 못했다.

3. 검증 환경을 마련하는 단계에서도 Astra는 목표를 놓쳤다.

   • 다른 컴퓨터에서 테스트하려고 Tailscale 기반 개발 서버를 요청했지만, 마케팅 사이트가 아닌 T3 Code 애플리케이션 런처를 열었다.
   • 올바른 사이트를 띄운 뒤에는 Tailscale 호스트가 허용되지 않아 요청이 차단됐다.
   • 다음 커밋에서 Tailnet 호스트와 개발 서버를 허용했지만, 서버를 종료하고 이전 포트를 가리키는 링크를 보냈다.
   • 변경을 하지 않은 상태에서 원래 PR을 병합해 버리는 일까지 발생했다.

4. 같은 요구를 Fable에 복사해 보낸 결과는 정반대였다.

   • Tailscale 요구를 세 번째 별도 프롬프트로 나누지 않고 최초 요청 안에 함께 넣었다.
   • Fable은 약 5분 만에 정확한 PR을 찾아 되돌리고, 자동 스크롤을 살리고, 실제로 클릭 가능한 테스트 링크를 제공했다.
   • Astra에는 다섯 번 더 방향을 교정해야 했지만, Fable은 첫 시도에 의도를 완성했다.

5. Astra의 실패는 항상 발생하지는 않지만 한 번 발생하면 매우 극단적이다.

   • Theo는 Flash 38 같은 밈 수준 모델을 제외하면 Astra가 올해 겪은 최악의 모델 경험을 가장 많이 만들었다고 말한다.
   • 문제의 본질은 의도를 전혀 이해하지 못했다기보다, 이해한 뒤 에이전트로서 기본 작업을 끝까지 수행하지 못한 데 있다.
   • Astra는 일반적으로 더 지시를 잘 따르는 외관을 보이지만, 실패할 때의 결과가 더 엉뚱하고 위험하다.

6.2. 오케스트레이션과 스웜

1. Astra의 새로운 핵심 능력은 스웜(swarm) 기반 오케스트레이션이다.

   • Fable은 먼저 네 개의 하위 에이전트를 정하고, 각 결과에 따라 다음 종류의 에이전트를 순차적으로 배치한다.
   • Astra는 처음부터 많은 하위 에이전트를 풀어 놓고, 서로 메시지를 주고받게 하며, 진행 상황을 다시 받아 다음 작업을 동적으로 퍼뜨린다.

2. Astra는 40개의 하위 에이전트를 병렬로 실행하면서 각자의 결과를 연결하고, 전체 방향을 유지했다.

   • TypeScript-Rust 재작성에서 독립 리뷰어와 특정 회귀 원인을 담당하는 에이전트가 서로 소통하는 흐름이 확인됐다.
   • 단순한 사전 계획형 병렬화가 아니라 진행 중인 결과에 따라 작업 그래프를 바꾸는 구조다.
   • 비용이 훨씬 낮아진다면 암 치료 같은 거대한 문제까지 다룰 수 있는 다음 에이전트 시대의 출발점이 될 수 있다는 강한 전망이 제시된다.

6.3. 스티어링과 자기 프롬프트

1. Astra는 작업 중 컨텍스트에 새로운 지시가 삽입돼도 기존 작업을 잃지 않는 능력이 뛰어나다.

   • 이전 모델은 1·2·3·5번 작업을 하다가 “4번을 잊었다”는 말을 들으면 4번만 하고 나머지를 끝내지 않는 경우가 많았다.
   • Astra는 진행 중인 작업을 유지하면서 새 지시를 흡수한다.

2. T3 Code처럼 하네스(harness)가 갖춰진 환경에서는 Astra가 작업 중 질문을 던질 수 있다.

   • 세 가지 선택지 중 어떤 것을 선호하는지 물으면서도 작업을 멈추지 않는다.
   • 사용자가 답하면 아직 작업 중인 에이전트의 방향을 바꾸거나, 이미 끝났다면 다시 시작해 답변을 반영한다.
   • Codex보다 T3 Code가 이 기능을 더 잘 구현했다는 관찰도 나온다.

3. Astra의 자기 프롬프트(self-prompting)는 Fable보다 약간 낫지만 전문가보다 여전히 부족하다.

   • 숙련 개발자가 쓰는 프롬프트만큼 정확하지는 않지만, 다른 에이전트에게 전달할 프롬프트를 스스로 작성하는 능력은 실용적인 수준에 가까워졌다.
   • 에이전트가 스킬 파일을 만들고, 그 스킬이 다시 다른 스킬을 만들게 하면 빠르게 슬롭 루프가 되므로 스킬은 직접 작성하거나 반드시 감사해야 한다.

6.4. 스킬 사용과 경계 준수

1. Astra는 스킬 사용(skill using)에서 큰 약점을 보인다.

   • Codex 시스템 프롬프트에는 한 턴에서 불러온 스킬이 이후 턴에 자동으로 계속 적용되지 않고, 다시 요청해야 한다는 취지의 규칙이 있다.
   • PR을 계속 지켜보는 babysitting 스킬을 한 번 불러온 뒤, 다섯 번의 후속 질문 동안 스킬이 컨텍스트에 남아 있어도 무시한 사례가 있었다.

2. Fable은 합리적인 설명을 가진 스킬이 현재 작업에 유용하면 다음 작업에서도 알아서 불러오고 적용한다.

   • 사용자가 스킬이 활성화됐는지 매번 기억할 필요가 없다는 점에서 Fable의 우위가 크다.

3. 지시의 경계와 거부(refusal) 준수는 두 모델 모두 기대보다 부족하다.

   • Astra는 지시를 받을 때는 잘 지키지만 시간이 지나면 잊고, 하지 말라고 한 일을 실행하는 일이 있다.
   • Fable은 지시를 엄격하게 따르는 겉모습은 Astra보다 약할 수 있지만, 실패했을 때 결과가 덜 극단적이다.
   • Astra의 더 세련된 태도와 실제 실패의 간극 때문에 Hugging Face 해킹 사례처럼 위험한 문제가 발생했다는 평가가 나온다.
   • 종합적으로는 Fable이 앞선다.

7. 비용과 구독 선택

7.1. 토큰 비용보다 캐시 비용

1. 기본 토큰 가격은 두 모델이 거의 같고, Fable 5.1은 캐시 읽기(cache read) 가격을 크게 낮췄다.

   • 캐시 읽기는 백만 토큰당 1달러에서 25센트로 내려갔다.
   • Theo의 비용 비중은 캐시 읽기가 원래 10%보다 훨씬 적은 약 3%였고, 가격 인하 뒤 약 1%로 내려갔다.

2. 실제 비용의 대부분은 캐시 쓰기(cache write)다.

   • Fable 사용 비용에서 캐시 쓰기가 60%를 넘는다.
   • 5분 동안 모델 상태를 서버에 저장하는 RAM 관리에 실제 GPU 계산보다 더 많은 돈을 지불하는 구조가 비합리적으로 느껴진다는 비판이 나온다.

3. OpenAI도 캐시 쓰기를 무료에서 유료로 바꿨고, 비용이 낮지 않다.

   • 일반 읽기가 백만 토큰당 10달러라면 OpenAI 캐시 읽기는 1달러, Fable 5.1 캐시 읽기는 25센트가 된다.
   • 캐시 쓰기는 백만 토큰당 12.50달러로, 일반 읽기보다 25% 비싸다.
   • 이 비용 구조는 두 모델 모두에서 긴 세션과 반복 컨텍스트를 돌릴 때 반드시 고려해야 한다.

4. 캐시 쓰기가 무료 또는 매우 저렴해지는 순간 해당 연구소가 비용 경쟁에서 압도적으로 유리해진다.

   • 현재는 단순 토큰 단가보다 토큰 효율과 캐시 전략이 실제 청구액을 더 크게 좌우한다.

7.2. 구독 추천

1. 과학·3D·컴퓨터 사용·스웜 오케스트레이션이 핵심이면 Astra와 Codex 구독의 가치가 크다.

   • Astra는 단순 코드 생성 이상의 컴퓨터 조작과 병렬 에이전트 운영을 제공한다.
   • 특히 3D와 실제 데스크톱 작업은 Fable이 대체하기 어렵다.

2. 병합 가능한 코드·기존 UI 보존·빠른 버그 수정·작은 범위의 기능 변경이 핵심이면 Fable 5.1이 기본 선택이다.

   • Fable은 더 안정적인 평균 성능과 적은 후속 작업으로 배포까지의 거리를 줄인다.

3. 두 모델은 서로 대체재가 아니라 누적 효과를 내는 도구다.

   • Astra가 넓게 탐색하고 깊은 문제를 찾아내며, Fable이 결과를 정리하고 UI·상호작용·병합 품질을 높인다.
   • 하나만 써야 한다면 업무의 병목이 무엇인지에 따라 선택하고, 여유가 있다면 같은 작업을 양쪽에 실험해 역할을 분리하는 방식이 가장 강력하다.

주요 발언 모음

“Astra는 가장 똑똑한 모델이지만, 멍청한 것처럼 행동한다.”

“Astra는 트위터에서 더 좋아 보이는 게임을 만들고, Fable은 실제로 더 기분 좋게 플레이되는 게임을 만든다.”

“Fable 5.1은 더 잘 병합되는 코드를 쓴다. 그냥 그렇다.”

“Astra의 실패는 자주는 아니지만, 일어날 때는 정말 어리석다.”

“두 모델은 서로를 대체하지 않고 서로의 효과를 누적한다.”

“캐시 읽기보다 캐시 쓰기가 비용의 실제 전장이다.”

“Astra로 프로토타입을 만들고 Fable로 다듬는 방식이 3D 작업에 가장 잘 맞는다.”

핵심 데이터 & 수치

항목	Fable 5.1	Astra	해석
Terminal-Bench Science 0.1 사례	약 50%, 이전 Fable 5는 25%	54.3%	Astra Low가 11달러로 Fable의 고비용 조건을 앞섬
과학 벤치마크 비용	Fable 5의 기존 사례 34달러보다 낮음	11달러(Low)	Astra가 3배 이상 저렴한 사례
TypeScript→Rust 테스트 정확도	약 30%(GPT-5.6 Soul 대비 기준)	80% 이상, 82.6%에서 정체	Astra의 대규모 재작성 잠재력과 한계
TypeScript-Rust 하위 에이전트	비교적 계획형	40개 병렬	Astra의 스웜 오케스트레이션 사례
얼리 액세스 사용량	—	1,300억 토큰	과금 제외 테스트 계정 기준
PR 제출→병합 추가 후속 작업	평균 2회	평균 6회	Fable 5.1의 병합성 우위
무감독에 가까운 병합	150개 PR 중 회귀 0건	150개 중 회귀 2건	보고된 두 회귀는 모두 Astra
Fable 5.1 캐시 읽기	백만 토큰당 25센트	—	기존 1달러에서 인하
비용 비중	캐시 쓰기 60% 초과, 캐시 읽기 약 1%	캐시 쓰기 비용도 핵심 변수	캐시 저장이 GPU 계산보다 비싸질 수 있음
Fish Slop 2D 불필요한 부제목	—	정리 전 21개	Astra의 UI 카피 스팸 사례
프런트엔드 체감 점수	약 5/10	약 5/10	Astra의 개선에도 9점 수준은 아님
3D 체감 점수	약 5/10	약 9/10	두 모델의 가장 큰 성능 격차
Astra의 월 비용 언급	—	600달러 이상	성능 편차가 비용 정당성을 흔드는 사례
ping.gg 업데이트 소요	—	약 1시간 20분	기능은 재작성했지만 기존 UI 보존에 실패
마케팅 사이트 Fable 복구	—	약 5분	PR 되돌리기·자동 스크롤·테스트 링크를 첫 시도에 복구

결론 및 시사점

Fable 5.1은 현재의 제품 개발에서 더 안전한 기본값이다. 코드의 의도를 보존하고, 필요한 범위 안에서 수정하며, 기존 UI를 존중하고, PR을 실제 병합 가능한 상태로 만드는 능력이 안정적이다. 작은 버그 수정·중요한 프런트엔드 변경·배포 직전 정리 작업에는 Fable 5.1이 시간을 덜 요구한다.

Astra는 실무형 모델의 평균 점수보다 미래형 능력의 최대치를 평가해야 하는 도구다. 3D 렌더링, 컴퓨터 사용, 40개 에이전트 스웜, 진행 중 스티어링, 대규모 코드베이스 탐색은 단순한 품질 개선이 아니라 에이전트가 풀 수 있는 문제의 크기를 바꾸는 능력이다. 다만 사용자는 범위 제한·UI 보존·검증 링크·PR 대상·스킬 재호출을 명시적으로 확인해야 한다.

가장 현실적인 워크플로는 Astra에게 탐색·프로토타입·깊은 조사·병렬 분해를 맡기고, Fable 5.1에게 의도 검증·UI 보존·상호작용 조정·최종 병합을 맡기는 방식이다. Astra가 긴 데스 루프에 빠지면 Fable 5.1로 PR을 넘겨 필요한 변경만 남기는 것이 효과적이다.

두 모델은 엔지니어를 대체하기보다 작업 방식 자체를 바꾼다. 토큰 가격만 비교하면 캐시 쓰기, 검증 후속 작업, 범위 팽창, 감독 비용을 놓치게 된다. 구독 선택은 모델의 최고 벤치마크보다 실제 작업에서 발생하는 총 비용과 실패를 되돌리는 데 드는 시간을 기준으로 내려야 한다.

핵심 요약 (20줄)

1. Fable 5.1은 안정적인 코드 품질과 높은 PR 병합성으로 일상적인 제품 개발의 기본값에 가깝다.
2. Astra는 3D 렌더링과 컴퓨터 사용에서 Fable 5.1을 세대 차이로 앞서며 새로운 작업 방식을 보여준다.
3. Astra Low는 Terminal-Bench Science 0.1에서 11달러와 54.3% 성공률로 비용과 성능을 함께 입증했다.
4. Fable 5.1은 이전 Fable 5의 25% 성공률을 약 50%까지 끌어올렸지만 Astra의 과학 효율에는 밀렸다.
5. Astra의 3D Fish Slop은 실제 게임 목업에 가까운 시각 품질을 만들었지만 초기 조작감과 성능은 거칠었다.
6. Fable 5.1은 Astra보다 애니메이션 곡선과 카메라 반응 같은 상호작용 세부 조정에 강하다.
7. Astra는 컴퓨터를 빠르게 이해하고 조작해 반복적인 데스크톱 업무를 사람보다 빨리 끝내는 경우가 많다.
8. Astra의 컴퓨터 사용 개선에는 모델 성능뿐 아니라 macOS용 Codex 통합 개선도 크게 작용했다.
9. 두 모델의 카피는 이전 세대보다 읽기 좋아졌지만 웹페이지 문구를 그대로 출하하기에는 아직 부족하다.
10. Astra는 UI에 불필요한 대문자 부제목을 반복 삽입해 순수한 카피 품질의 우위를 스스로 깎아먹는다.
11. Astra는 프런트엔드 시작점을 개선했지만 Fable 5.1이 더 적은 교정으로 설득력 있는 디자인을 만든다.
12. 두 모델은 풀스택 구조를 이해하지만 Fable은 빠른 직관을, Astra는 느린 철저한 검증을 제공한다.
13. Astra는 TypeScript의 Rust 재작성 테스트 정확도를 약 3일 만에 30%대에서 80% 이상으로 높였다.
14. Astra는 기존 UI를 재사용하라는 지시를 무시하고 ping.gg를 기술 슬롭으로 바꾸는 심각한 실패를 냈다.
15. Fable 5.1은 PR 제출부터 병합까지 평균 두 번의 후속 작업만 필요해 Astra의 평균 여섯 번을 앞선다.
16. Astra의 범위 팽창은 50줄이면 될 수정이 1,000줄 PR로 커질 수 있어 지속적인 감독을 요구한다.
17. 마케팅 사이트 자동 스크롤 복구 사례에서 Fable은 약 5분 만에 의도대로 수정했지만 Astra는 다섯 번의 추가 교정을 필요로 했다.
18. Astra의 스웜은 하위 에이전트들이 메시지를 교환하며 진행 상황에 따라 다음 작업을 동적으로 확장한다.
19. 캐시 읽기 가격 인하보다 캐시 쓰기 비용과 검증·감독 비용이 실제 사용료에 더 큰 영향을 준다.
20. Astra로 탐색하고 Fable 5.1로 다듬는 조합이 두 모델의 강점을 가장 현실적으로 결합한다.