Claude Fable 5 vs Codex GPT‑5.6 — 5개 모델 성능·비용·실사용 비교

모델을 한 줄로 줄이면 아래처럼 볼 수 있다.

*Sonnet 5의 $2/$10은 2026년 8월 31일까지의 출시 가격이며 이후 $3/$15로 바뀐다.

“어느 모델이 제일 좋나”보다 중요한 질문은 어느 단계에서 어떤 모델로 올릴 것인가다. 첫 시도는 Luna·Terra·Sonnet으로 하고, 실패 비용이 커지거나 작업의 경계가 흐려질 때 Sol·Fable로 올리는 편이 합리적이다. Anthropic의 Fable 5 발표와 OpenAI의 GPT‑5.6 발표도 모델을 단일 서열보다 작업 성격과 노력 수준으로 설명한다.

Artificial Analysis Intelligence Index v4.1에서 Fable 5는 60점, GPT‑5.6 Sol은 59점이다. 종합 지능 차이는 1점뿐인데 평가 작업당 비용은 Sol이 대략 3분의 1 수준으로 측정됐다. 같은 기관의 Coding Agent Index에서는 Sol 80.0, Terra 77.4, Fable 77.2, Luna 74.6이다. “Codex가 가성비가 좋다”는 말은 적어도 이 평가에서는 꽤 근거가 있다.

하지만 SWE‑bench Pro를 보면 순서가 바뀐다. OpenAI가 공개한 교차 모델 표에서 Fable 5는 80.0%, Sol 64.6%, Terra 63.4%, Luna 62.7%다. 반대로 Terminal‑Bench 2.1에서는 Sol 88.8%, Terra 87.4%, Luna 84.7%, Fable 83.1%다. 저장소의 까다로운 이슈를 깊게 파는 일은 Fable, 터미널과 도구를 빠르게 굴리는 일은 GPT‑5.6 계열이 강하다는 패턴이다.

Sonnet 5는 Anthropic의 출시 평가에서 SWE‑bench Pro 63.2%, Terminal‑Bench 2.1 80.4%, OSWorld‑Verified 81.2%를 기록했다. 다만 회사마다 에이전트 하네스·노력 수준·토큰 예산이 다르므로 서로 다른 표의 숫자를 소수점까지 직접 순위로 붙이면 안 된다. 아래 차트는 같은 평가기관의 지수만 묶고, Sonnet은 가격표에만 별도로 표시했다.

조건을 일부러 명확하게 닫았다. 1440×900 단일 HTML, 외부 라이브러리 금지, KPI 4개, 모델 5개 표, 인라인 SVG 차트, 라우팅 노트, 동작하는 필터, 접근 가능한 모달을 요구했다. 모든 모델은 API에서 medium effort로 실행했고 출력 상한은 8,000토큰으로 맞췄다. 렌더링은 동일한 Chromium 1440×900에서 확인했다.

비용은 실제 입력·출력 토큰에 2026년 7월 19일 공식 정가를 곱했으며 캐시·세금은 제외했다. 응답 시간은 서울의 한 번의 API 호출이므로 모델의 보편적 속도 지표가 아니다. 더 중요한 것은 이 정도로 범위가 닫힌 과제에서는 Luna와 Sonnet이 모든 기능 조건을 통과했다는 점이다.

Fable 5의 강점은 한 번의 코드 생성보다 긴 작업의 방향을 잃지 않는 것이다. Anthropic은 복잡한 코딩, 대규모 마이그레이션, 여러 날 이어지는 자율 세션을 대표 용도로 든다. 실제 초기 도입에서 Stripe는 5천만 줄 Ruby 코드베이스의 전사적 마이그레이션을 Fable 5가 하루에 수행했으며, 사람 팀이라면 두 달 이상 걸렸을 일이라고 밝혔다. Fable은 화면 스크린샷만 보고 웹앱 소스를 재구축하거나, 별도 지도·상태 도구 없이 Pokémon FireRed를 끝까지 플레이한 사례도 공개됐다.

우리의 작은 UI 실험에서도 화면의 균형과 정보 구조는 가장 차분했다. 하지만 모달을 Escape로 닫는 조건은 누락했고 비용은 Luna의 약 10.5배였다. 즉, Fable의 가격은 픽셀 몇 개를 더 예쁘게 만드는 데 쓰기보다 요구가 불완전하고 탐색 범위가 넓은 일에 써야 한다.

운영 제약도 있다. Fable은 사이버·생물학 관련 일부 요청을 Opus 4.8로 자동 전환할 수 있고, Anthropic은 안전 모니터링을 위해 Fable 사용에 30일 데이터 보존이 필요하다고 안내한다. 민감한 코드베이스라면 성능뿐 아니라 이 정책도 검토해야 한다.

Sonnet 5는 “Fable보다 싸니까 타협”에 가깝지 않다. Anthropic의 공식 평가에서 도구 사용·터미널·컴퓨터 조작은 Opus 4.8과 몇 점 차이까지 좁혔고, 2026년 8월 31일까지 $2/$10의 출시 가격을 적용한다. 우리의 동일 프롬프트에서도 7개 조건을 모두 지켰고 비용은 $0.058이었다.

대신 새 기본값을 알아야 한다. Sonnet 5는 adaptive thinking이 기본으로 켜지고 effort 기본값이 high다. 새 토크나이저는 같은 텍스트를 Sonnet 4.6보다 대략 30% 더 많은 토큰으로 계산한다. 실제 준비 과정에서 아무 설정 없이 5,000토큰 상한을 줬더니 생각 토큰이 예산을 다 쓰고 최종 HTML이 한 글자도 나오지 않았다. Anthropic의 Sonnet 5 마이그레이션 문서가 경고하는 바로 그 상황이다.

해결은 간단했다. 출력이 긴 생성 작업은 max_tokens를 넉넉히 잡고, 비용이 중요하면 effort를 medium으로 낮춘다. “더 길게 생각해”라는 프롬프트보다 API의 effort를 먼저 조정하는 편이 낫다.

GPT‑5.6의 장점은 Sol 하나보다 같은 도구 체계 안에서 가격대를 바꾸기 쉽다는 데 있다.

• •Sol: 복합 추론, 긴 에이전트 작업, 디자인·코드·검증을 함께 맡길 때. max에서는 Coding Agent Index 80으로 선두다.
• •Terra: 일상 개발과 리서치의 기본값. Coding Agent Index 77.4로 Fable 77.2와 비슷하지만 API 출력 단가는 Fable의 30%다.
• •Luna: 분류·변환·정해진 템플릿·짧은 서브에이전트. 지능 지수 51, 코딩 에이전트 74.6으로 가격 대비 낙폭이 작다.

Codex에서는 Plus 이상에서 Sol·Terra·Luna와 effort를 선택할 수 있고, ultra는 여러 에이전트를 병렬로 조율하는 최고 설정이다. 다만 ultra를 상시 기본값으로 두는 것은 낭비다. 처음에는 Terra, 짧고 반복적인 하위 작업은 Luna, 테스트 실패가 반복되거나 아키텍처 판단이 필요할 때 Sol로 올리는 구조가 더 싸고 빠르다.

이번 결과에서 Sol은 가장 밀도 높은 운영 콘솔을 만들었지만 12,000자 제한을 30% 넘겼고 응답도 가장 오래 걸렸다. 반면 Luna는 가장 빠르고 저렴하면서 접근성 조건까지 지켰다. “최상위 = 모든 과제의 최고 선택”이 아니라는 좋은 예다.

초기 파트너 사례를 보면 실무 차이는 정답률 몇 점보다 도구 호출과 재작업 감소에서 나타난다.

• •Stripe: Fable 5로 5천만 줄 Ruby 코드베이스 마이그레이션을 하루에 수행했다고 보고했다.
• •Lovable: GPT‑5.6 도입 후 앱 제작에 필요한 단계가 약 25% 줄고 도구 호출이 35~48% 감소했으며, 막힌 실행이 15% 줄었다고 밝혔다.
• •Qodo: PR 코드 리뷰 평가에서 GPT‑5.6이 GPT‑5.5보다 PR당 토큰을 약 3분의 1로 쓰고 중앙 지연은 절반 수준이었다고 밝혔다.
• •Model ML: Fable과 비교한 덱 생성에서 GPT‑5.6이 덱당 토큰을 39% 덜 쓰면서 더 다듬어진 결과를 냈다고 보고했다.
• •Shopify: 조사→계획→단계별 구현으로 이어지는 Codex 작업에서 이전 모델보다 의도를 잘 따르고 정확한 GitHub 라인 링크를 만들었다고 평가했다.

이 수치는 각 회사의 초기 평가이고 독립 재현 결과는 아니다. 그래도 공통점은 분명하다. 좋은 모델은 “첫 답변이 멋진 모델”이 아니라 툴 호출, 재시도, 사람의 교정 횟수를 줄이는 모델이다. 모델 비용을 계산할 때는 토큰 단가보다 완료된 작업 1건당 총비용을 봐야 한다.

우리가 실제 프로젝트에 적용한다면 다음처럼 운영한다.

1. 01Luna — 정규식 생성, 데이터 변환, 파일명 정리, 테스트 설명, 정해진 컴포넌트 변형처럼 성공 조건이 기계적으로 확인되는 일.
2. 02Terra 또는 Sonnet 5 — 기능 구현, 일반 버그 수정, 문서 리서치, PR 초안처럼 한두 번의 검증으로 끝낼 수 있는 일.
3. 03Sol — 여러 도구를 오가며 설계·구현·브라우저 검증까지 이어지는 작업, 또는 실패가 반복되는 저장소 작업.
4. 04Fable 5 — 경계가 불명확한 대규모 마이그레이션, 며칠짜리 자율 실행, 긴 컨텍스트에서 방향을 유지해야 하는 최종 해결 작업.

승격 조건도 미리 정한다. 동일 테스트가 두 번 실패했거나, 변경 파일이 예상 범위를 넘었거나, 보안·데이터 마이그레이션처럼 실패 비용이 크면 한 단계 올린다. 반대로 동일 패턴이 세 번 연속 성공하면 한 단계 내린다. 이렇게 해야 “좋아 보이니까 매번 Fable/Sol”이라는 비용 습관에서 벗어난다.

마지막으로 이번 직접 실험은 N=1이다. 단일 화면 생성 능력을 보았을 뿐, 수백 파일 저장소나 장시간 에이전트 성능을 대체하지 않는다. 공개 벤치마크도 하네스가 바뀌면 점수가 달라진다. 가장 믿을 만한 평가는 자신의 저장소에서 실패 비용이 큰 20~50개 작업을 뽑아 동일 조건으로 반복하는 것이다.