지난 몇 달 동안 저의 워크플로우는 어처구니없는 형태를 띠고 있었습니다. 하나의 모델로 계획을 세우고, 다른 모델로 구현하며, 세 번째 모델로 앞선 두 모델이 수행한 작업을 검토하는 방식이었죠. 취향과 오케스트레이션 (Orchestration)을 위해서는 Fable 5를, 문제를 철저히 파헤치는 작업에는 GPT-5.6 Sol을 사용하며 그 사이에서 수많은 탭 전환을 반복했습니다.

Anthropic은 7월 24일에 Opus 5를 출시했습니다. 이 모델은 Fable 5보다 작고, 더 저렴하며, 대부분의 공개된 벤치마크 (Benchmark)에서 Fable 5를 능가합니다. 이러한 조합은 충분히 혼란스러울 정도로 흥미로운 분석 가치가 있습니다. 왜냐하면 흥미로운 부분은 벤치마크 표가 아니라, 이 모델이 모델 선택 (Model selection) 방식에 미치는 영향이기 때문입니다.

가격은 실제지만, 할인된 것은 아니다

Opus 5의 가격은 입력/출력 토큰 (Token) 100만 개당 $5 / $25입니다. Fable 5는 $10 / $50입니다. 즉, 가격이 절반이라는 헤드라인은 사실입니다.

하지만 토큰당 가격은 잘못된 단위입니다. 모델마다 동일한 결과에 도달하기 위해 사용하는 토큰 수가 다르며, Opus 5는 Fable보다 토큰 효율성 (Token-efficient)이 떨어집니다. Artificial Analysis의 측정치에 따르면 작업당 약 37k 토큰을 사용하는 반면, Fable은 33k 토큰을 사용합니다. 완료된 작업당 비용을 측정하면, 그 격차는 50%에서 20~25%에 가까운 수준으로 줄어듭니다.

이 모델의 성격 전체를 설명해 주는 더 날카로운 수치가 있습니다. 상위 3가지 노력 수준(Effort levels) 전체에서 Opus 5는 작업당 평균 103, 91, 76회의 턴 (Turn)을 기록했는데, 이는 Opus 4.8의 최대치인 55회와 대조됩니다. 에이전트 루프 (Agent loop)가 대략 두 배에 달하는 것입니다. 사람들이 후속 작업에서 불평하는 모든 것들 — 장황함, 과도한 확인, 제어권을 사용자에게 다시 넘기는 행위 — 은 이 하나의 숫자를 다른 각도에서 바라본 결과입니다.

두 가지 실질적인 결과

1. 더 많은 토큰은 더 느린 응답과 더 빨리 채워지는 컨텍스트 윈도우 (Context window)를 의미하며, 이는 긴 에이전트 실행 (Agentic runs) 시 더 빨리 작업에서 벗어나게 됨을 의미합니다.
2. 만약 최첨단 성능 (Frontier capability)에서 해결된 문제당 비용만을 순수하게 최적화한다면, 원시 효율성 (Raw efficiency) 측면에서는 여전히 OpenAI 측이 승리합니다.

경제성이 진정으로 변하는 지점은 구독 (subscriptions) 모델입니다. Fable은 $100/$200 플랜에서 주간 한도의 절반으로 제한되며, $20 Pro 플랜에서는 완전히 제외되었습니다. Opus 5는 Max의 기본 모델이며, 한도를 소모하는 속도가 몇 배 더 느리면서도 한도의 100%를 제공합니다. API가 아닌 Claude 구독 내에서 활동한다면, 이것이 핵심입니다.

왜 더 작은 모델이 더 큰 모델을 이기는가

Fable과 Mythos는 동일한 기반 모델 (underlying model)을 사용합니다. 차이점은 앞에 위치한 분류기 (classifier)에 의해 어떤 요청이 허용되고 어떤 응답이 출력되는지가 강제된다는 점입니다. 가중치 (weights)에서 제거된 것은 아무것도 없습니다.

Opus 5는 해당 Mythos급 모델을 증류 (distillation)한 것으로, 제한 사항이 사후에 덧붙여진 것이 아니라 훈련 (training) 과정에 내재되어 있습니다. 이를 그릇에 뚜껑을 덮는 것이 아니라, 그릇 자체를 필터링하는 것이라고 생각하면 됩니다. Anthropic은 이를 자사의 가장 정렬된 (most-aligned) 릴리스라고 보고합니다. 즉, 기만적 행동 (deceptive behaviour) 비율이 가장 낮고, 오용되도록 속이기 가장 어려우며, 되돌릴 수 없는 작업에 대해 가장 안전합니다.

보통 이러한 과정은 실제 성능 (real-world capability)의 손실을 초래하지만, 여기서는 대부분 손실되지 않았습니다. 다만 흔적은 남았습니다. 4.x 버전 이후의 모든 Opus 릴리스를 자사의 프로덕션 코드 리뷰 파이프라인에서 벤치마크해 온 CodeRabbit은, Opus 5가 리뷰어보다는 빌더 (builder)로서 더 강력한 강점을 가진다는 것을 발견했습니다. Opus 5는 먼저 목표를 명확히 하고, 여러 가지 신뢰할 수 있는 접근 방식을 제안하며, 첫 번째 해결책으로 바로 달려들지 않고 개방형 작업을 처리하며, 4.8보다 수백 개의 백그라운드 에이전트 (background agents)를 더 잘 조율합니다. 그들의 엔지니어 중 한 명은 이전 Opus 모델들보다 덜 불안해 보인다고 평가했습니다. 또한 Fable 5보다 느린 속도를 유지했으며, 보안 작업에서 눈에 띄게 과도하게 주의를 기울이는 모습을 보였습니다. 이는 취약점 공격 (exploitation)에 취약하도록 훈련된 모델에서 예측할 수 있는 정확한 결과입니다.

우리의 목적에는 이 정도면 충분합니다. 디버깅을 위해 실제로 원하는 기능인 취약점 탐지 능력은 여전히 뛰어나기 때문입니다.

또한 엄청난 결과로 이어질 수 있는 지루한 세부 사항이 하나 있습니다. 바로 Opus 5는 데이터 보존 제로 (zero data retention)를 지원한다는 점입니다. Fable과 Mythos의 요청은 조건 없이 기록되고 감사되었기에, 규제 대상 워크로드(regulated workloads)의 상당 부분에서 조용히 탈락했습니다. 이제 그 제약은 사라졌습니다.

벤치마크, 그리고 벤치마크보다 더 중요한 것

Anthropic이 직접 수행한 Fable 5와의 일대일 비교 결과는 다음과 같습니다: 에이전트 기반 터미널 코딩 (agentic terminal coding) 43.3% vs 33.7%, 컴퓨터 사용 (computer use) 70.6% vs 66.1%, 비즈니스 워크플로 (business workflows) 26.0% vs 17.4%. CursorBench에서는 Fable의 최고점보다 약 0.5점 뒤처지지만, 작업당 비용은 대략 절반 수준입니다. ARC-AGI-3에서는 30%에 근접한 점수를 기록했습니다. 이 벤치마크는 인간보다 더 많은 단계를 거치는 것에 페널티를 부여하며, 출시 당시에는 어떤 모델도 1% 이상의 점수를 받지 못했던 지표입니다.

나머지 지표에서도 일관된 패턴이 나타납니다. Opus 5는 사용 가능한 도구를 활용하여 업무를 수행하는 데 있어 Fable과 대등하거나 근소하게 앞서지만, 순수한 사실 회상 (factual recall) 능력에서는 Fable에 뒤처집니다. 모델이 더 작으니, 두뇌(지식)도 적은 셈입니다.

더 흥미로운 결과는 Claire Vo의 실험입니다. 그녀는 7개 모델을 대상으로 평가를 진행했으며, 중요한 점은 블라인드 테스트 (blind eval) 방식으로 순위를 매겼다는 것입니다. 그녀는 경험에 대해 매우 혹독하게 평가했습니다. 신경질적이고, 사과가 많으며, 말이 너무 많아서 출력물을 'Claude slop(Claude의 쓰레기 같은 결과물)'이라고 명명할 정도였습니다. 그럼에도 불구하고 Opus 5는 프론트엔드 디자인과 프로토타이핑에서 최고 점수를 받으며 그녀의 리더보드 1위를 차지했습니다. 그녀의 요약은 이랬습니다.

Every의 Dan Shipper 팀은 출시 전 일주일 동안 코딩, 글쓰기, 그리고 그들의 내부 에이전트(agent)를 대상으로 Opus 5를 테스트했으며, 이를 '사랑하기 어려운 모델'이라고 평가했습니다. 이 모델은 지시 사항에 반박하고, 작업을 마치기 전에 멈추며, 이전 모델들을 위해 구축해 두었던 기술(skills) 및 플러그인(plugins) 내부에서 나쁜 동작을 보였습니다. 그의 프레임워크에 따르면, 이는 근본적인 탁월함은 없으면서 성격적 결함만 가진 '저예산 Fable'과 같았습니다. 반면, Box의 Aaron Levie는 그들의 내부 평가(evals)에서 정반대의 결과—기술 및 의료 관련 작업에서 두 자릿수 성능 향상—를 보고했으므로, 이것이 보편적인 결론은 아닙니다.

그 후 Every는 기존의 기술(skills)들을 삭제하고 처음부터 다시 시작했으며, 결과는 극적으로 개선되었습니다.

이는 앞서 언급된 모든 내용과의 명백한 모순을 해결해 줍니다. 이전 Anthropic 모델들은 과도하게 제약(over-constrained)되어야 했습니다. 모델이 당신이 말한 대로 행동하는 대신 당신이 진정으로 원하는 것을 추론해 버렸기 때문에, 시스템 프롬프트(system prompt), CLAUDE.md, 그리고 기술(skills) 전반에 걸쳐 같은 내용을 반복해야 했습니다. Opus 5는 그렇게 하지 않지만, 당신의 스캐폴딩(scaffolding)은 여전히 그렇게 하고 있습니다. Anthropic 자체의 프롬프팅 가이드(prompting guidance)에서도 이제

• 병합(merge)하려는 모든 작업에는 Opus 5를 기본값으로 사용하세요. 단, 프롬프트를 재구축한 후에 사용해야 하며, 그 전에는 사용하지 마세요.
• 일회성 코드, 스크립트, 그리고 차이점(diff)의 품질보다 완료 속도가 더 중요한 비서 스타일의 작업에는 Sol을 계속 사용하세요.
• 가장 긴 자율 작업(autonomous jobs), 모호한 디버깅(debugging), 그리고 출력을 한 줄씩 읽어야 하는 모든 작업에는 Fable을 계속 사용하세요. Anthropic도 같은 말을 합니다: 일상적인 업무에는 Opus를, 가끔씩 수행하는 심층적인 작업에는 Fable을 사용하라는 것입니다.
• 가능하다면 눈을 감고 스스로 검증하세요. 실제 작업 하나를 가져와 두 모델에서 실행한 다음, 각 모델에게 상대방이 누구인지 알려주지 않은 상태에서 서로의 계획을 검토하게 하세요. 그 비교를 통해 하루 동안 얻은 교훈이 그 어떤 벤치마크(benchmark) 표보다 더 많았습니다.

출시 첫 주에 형성된 합의는 묘하게 구체적입니다: 이 모델은 사용 가능한 최고의 일상적 모델이지만, 옆에 앉아 있기에는 가장 불쾌한 모델이라는 점입니다. 만약 모든 것을 세 번씩 확인하고 끊임없이 사과하는 동료와 함께 지낼 수 있다면, 이는 확실한 업그레이드입니다.

출처: Anthropic의 Opus 5 발표 및 프롬프팅 가이드(prompting guidance), Artificial Analysis, CodeRabbit의 코드 리뷰 벤치마크(code-review benchmark), Claire Vo / How I AI, Dan Shipper / Every, 그리고 Theo의 실습 리뷰. 가격은 2026년 7월 28일 기준 공시된 요율을 바탕으로 확인되었습니다.