Claude Fable 5.1 vs GPT-6 Astra,
코딩과 에이전트 작업에서 어느 쪽인가

먼저 결과: 한 표로 보는 두 모델

두 회사가 각자 발표한 수치와, 제가 9월 7일에 직접 연 문서 페이지의 내용을 한 표에 모았습니다. 출처가 발표문인지 직접 확인인지 열에 적었습니다.

표에서 두 줄이 이 글의 결론을 거의 정합니다. 첫째, 캐시 읽기 단가가 4배 차이 납니다. 에이전트는 매 턴 같은 컨텍스트를 다시 읽으므로 긴 세션에서는 이 한 줄이 청구서를 좌우합니다. 둘째, 독립 지수에서 Fable 5.1이 1위이지만 같은 지수의 작업당 비용은 Astra가 절반 이하입니다. 어느 쪽이 “낫다”는 질문은 이 두 줄 중 무엇을 더 무겁게 보느냐의 문제입니다.

벤치마크는 두 회사가 서로 다른 표를 냈습니다

OpenAI 발표문의 표는 Terminal-Bench 4.0에서 Astra 57.9%, Claude Fable 5.1 55.8%, GPT-5.6 Sol 37.3%라고 적습니다. 컴퓨터 사용 쪽은 OSWorld 2.0 72.6%, Agents’ Last Exam 59.3%(Fable 5는 48.7%, Opus 5는 55.5%), ScreenSpot-Pro 92.7%입니다. 같은 발표문 각주에는 Claude 점수를 “공식 리더보드에서 재현했다”고 적고, OSWorld 2.0에서는 Fable 5.1 시스템 카드의 수정된 과제와 채점 대신 공식 설정을 썼다고 밝힙니다. 즉 OpenAI 표의 Claude 숫자는 Anthropic이 낸 숫자와 조건이 다를 수 있습니다.

Anthropic 쪽은 벤치마크 표 자체를 텍스트로 냈고, 자체 재현 결과에 “노이즈 범위 안”이라는 표현을 씁니다. 두 표를 나란히 놓으면 같은 벤치마크 이름 아래 숫자가 1~3점씩 다른 칸이 나오는데, 그 차이는 대개 하네스, 시도 횟수, effort 설정의 차이입니다.

독립 지수에서 눈여겨볼 것은 순위보다 지연 시간입니다. 지수 페이지 기준 첫 토큰까지 Fable 5.1 max는 272초, Astra max는 355초입니다. high 설정으로 내리면 Fable 26초, Astra 46초. 대화형으로 쓰기엔 둘 다 max는 무리이고, high 이하에서 비교해야 체감과 맞습니다.

어디서 쓸 수 있나가 모델 성능보다 먼저 결정합니다

실무에서 모델 선택은 벤치마크가 아니라 “내 도구에 들어와 있는가”에서 끝나는 경우가 많습니다. 9월 7일 기준으로 각 도구의 모델 문서를 직접 열어 확인한 결과입니다.

Cursor 사용자라면 이 표에서 비교가 끝납니다. Astra는 없고 Fable 5.1은 있습니다. 반대로 GitHub Copilot 중심으로 일하는 팀은 Astra가 먼저 들어왔습니다. Claude Code를 쓰면 애초에 선택지가 Fable 5.1입니다. 두 모델을 실제로 고를 수 있는 사람은 API를 직접 붙이는 개발자와, 두 구독을 다 가진 사람뿐입니다.

사고 과정이 보이느냐가 리뷰 방식을 바꿉니다

Astra의 가장 큰 구조 변화는 OpenAI가 recurrent depth라고 부르는 방식입니다. 토큰을 같은 층에 반복해서 통과시키며 잠재 공간에서 추론하고, API는 원문 사고 과정 대신 요약을 돌려줍니다. Hacker News에는 출시 다음 날 “Astra의 recurrent 구조를 얼마나 걱정해야 하나”라는 스레드가 올라왔고, 한 댓글은 이 모델이 “같은 가격대의 어떤 모델보다 사고 과정 밖에 세부를 숨길 수 있다”고 씁니다. Claude는 확장 사고를 표시하고 effort로 깊이를 조절하는 방식을 유지합니다.

이 차이는 코드 리뷰 워크플로에 바로 영향을 줍니다. 사고 과정이 보이면 “왜 이 파일을 건드렸는가”를 모델의 추론에서 읽고 반박할 수 있습니다. 보이지 않으면 결과물만 놓고 판단해야 하므로 검증이 테스트와 diff 중심으로 옮겨갑니다. 그래서 Astra를 쓰는 팀에 필요한 루틴은 다음과 같습니다.

Claude 쪽도 사고 과정이 보인다고 검증을 생략해도 된다는 뜻은 아닙니다. 다만 “어디서 틀렸는지”를 찾는 시간이 다릅니다. 팀에 코드 설명이 중요한 환경, 예컨대 주니어가 리뷰하거나 규제 문서가 필요한 곳에서는 이 차이가 벤치마크 2점보다 큽니다.

직접 실행: Fable 5.1과 Astra에 같은 프롬프트, Sol은 기준선

이 비교의 두 모델을 실제로 돌릴 수 있게 됐습니다. chatgpt.com 웹에는 없던 Astra가 Aside 브라우저의 ChatGPT 연동 목록에는 올라와 있어서, 같은 Plus 계정으로 GPT-6 Astra와 GPT-5.6 Sol에, 그리고 같은 브라우저에서 Claude Fable 5.1에 같은 프롬프트를 한 번씩 보냈습니다. 도구 사용 금지, 한국어 답변, 제목 고정이라는 조건이었고 과제는 셋입니다. 모델 자기 보고, 한국어 금액 문자열을 정수로 바꾸는 TypeScript 함수(60줄 이내, 테스트 8개, 자신 없는 입력 3개), 그리고 이 블로그의 건강보험 글에 나온 주장 하나를 검색 없이 검증하는 과제였습니다. 세 응답의 원문은 Aside 공유 링크로 남겼습니다.

세 코드를 그대로 파일로 옮겨 Node에서 실행했습니다. 필수 케이스는 셋 다 전부 맞았습니다. 차이는 명세 밖에서 났습니다. Sol은 요구하지 않은 기능을 넣다가 줄 수 제한을 넘겼고, Fable 5.1은 더 많은 기능을 넣고도 46줄로 끝냈지만 단위 순서 검증을 빼서 “만억원”이 숫자로 나옵니다. 흥미로운 건 Fable이 그 약점을 답변 안에서 먼저 자백했다는 점이고, Astra는 애초에 요구 범위를 넘지 않아서 그 약점이 생기지 않았습니다. 검증 과제는 세 모델 모두 검색 없이도 맞는 확인 항목을 냈고, 각자 다른 지점을 짚었습니다. Astra는 세대 합산, Sol은 최저보험료, Fable은 제도 연혁이었습니다. 이 블로그의 건강보험 글에 실제로 들어간 사실은 세 지점 전부입니다.

한 번의 실행이라 일반화할 수 없습니다. 다만 “더 적은 반복으로 프로덕션 품질”이라는 발표문의 표현이 이 작은 과제에서는 “명세를 넘지 않는다”로 나타났고, Fable 5.1의 강점은 스스로 약점을 밝히는 쪽에 있었습니다. 코드 리뷰를 사람이 한다면 후자가, 리뷰 없이 바로 쓴다면 전자가 편한 성향입니다.

덧붙이면, 같은 프롬프트를 이 브라우저의 기본 Claude 세션에도 넣어 봤는데 “3억 5천만원”을 350,050,000으로 답했습니다. 다만 그 세션은 모델 버전을 스스로 다르게 보고해 어느 버전인지 확정하지 못했으므로 비교 표에는 넣지 않았습니다.

출시 주에 돌아다니는 말 네 가지

개발자들이 실제로 묻고 있는 것

출시 주에 공개 커뮤니티에서 반복된 질문 세 가지입니다. 링크는 글 끝 출처에 있습니다.

“Astra의 recurrent 구조, 얼마나 걱정해야 하나” (Hacker News, 9월 4일) 사고 과정이 요약으로만 나오는 것이 정렬·감사 관점에서 문제인지 묻는 스레드입니다. 실무 결론은 위 검증 루틴처럼 “결과 기반 검증으로 옮기라”는 쪽으로 모입니다.

“Plus인데 왜 Astra가 안 보이나” 순차 제공 중이고, Enterprise는 관리자가 켜야 합니다. 저도 9월 7일 한국 Plus 계정에서 GPT-5.6 Sol과 GPT-5.5만 보였습니다. 화면은 GPT-6 Astra 정리 글에 있습니다.

“Fable 5.1 캐시 인하가 내 청구서에 얼마나 되나” Anthropic은 8월 실제 사용량 4주치로 일반 워크로드 25%, 컨텍스트가 무거운 에이전트 워크로드 최대 45% 절감이라고 발표했습니다. 단발 요청 위주라면 0%입니다.

작업 유형별로 고르는 기준

두 표를 합치면 이렇게 됩니다. 모델을 고를 수 있는 위치라면 “화면을 조작하는 일”은 Astra, “코드를 오래 붙들고 설명이 필요한 일”은 Fable 5.1 쪽이 먼저입니다. 모델을 고를 수 없는 위치, 즉 도구가 정해져 있다면 그 도구에 들어온 쪽을 쓰고 이 비교는 잊어도 됩니다.