Opus 4.8 vs Sonnet vs Haiku: 2026년의 작업 라우팅 방식

고정된 5/25 가격, 3배 더 저렴한 Fast mode, 그리고 기권(abstention) 기능이 2026년의 라우팅 계산법을 재정립했습니다.
저는 SWE-Bench Pro 69.2를 근거로, 조용한 오답(silent wrong answer)이 치명적인 비용을 초래할 때 Opus 4.8을 선택합니다.
Sonnet은 중간 정도의 상대적 비용으로, 범위가 명확하고 볼륨이 크며 지연 시간(latency)에 민감한 작업에서 승리합니다.
Haiku는 분류(classification)나 초안 작성과 같이 가장 저렴하고 빠른 작업을 담당합니다.
Fast mode는 약 2.5배 더 빠르게 실행되며, 노력의 수준은 낮음에서 최대까지 확장됩니다.

지난 2년 동안 규칙은 간단했습니다. 기본적으로 저렴한 티어(tier)를 사용하고, 저렴한 모델이 실패할 때만 최상위 티어로 격상하는 것이었습니다. 2026년에는 어려운 작업에 대해 이 방식을 뒤집었습니다. 제가 실제로 실행하는 라우팅 로직과, 그 기준선을 옮긴 Opus 4.8의 세 가지 변화를 소개합니다.

2026년 라우팅 계산법을 바꾼 것들

과거의 계산법은 손실(loss) 중심이었습니다. 최상위 티어의 지능은 프리미엄 비용이 발생했기에, 저는 이를 아껴서 사용했습니다. 처음에는 작은 규모로 시작했다가, 저렴한 모델이 다중 파일 리팩토링(multi-file refactor)에서 비틀거리는 것을 지켜본 뒤, 업그레이드 비용을 지불하고 프롬프트를 다시 작성하곤 했습니다. 이는 하나의 작업을 위해 두 번의 과정을 거치는 셈이었습니다.

올해 세 가지가 변했습니다. 첫째, 최상위 티어의 권장 소비자 가격(list price)이 고정되었습니다. Opus 4.8은 4.7과 마찬가지로 입력 100만 토큰당 5, 출력 100만 토큰당 25를 유지합니다. 전체 1M 컨텍스트 윈도우(window)를 사용할 때도 롱 컨텍스트(long-context) 추가 요금이 없습니다. 따라서 성능은 계속 향상되는 반면, 작업당 비용의 상한선은 더 이상 상승하지 않았습니다.

둘째, 새로운 Fast mode는 약 2.5배 더 빠르게 실행되며, 기존 빠른 티어 가격의 약 3분의 1 수준입니다. 이는 지연 시간에 민감한 제 작업 영역에서 거의 3배 더 저렴하다는 의미입니다. 과거에는 속도가 티어를 낮추는 이유였지만, 이제는 더 무거운 모델을 유지하면서 Fast mode를 켜기만 하면 됩니다.

셋째, 그리고 이것이 실제로 저의 기본 설정을 바꾼 요소는 바로 기권(abstention)입니다. Opus 4.8은 이전 모델들보다 자신의 코드 버그를 인지하지 못한 채 통과시킬 확률이 약 4배 낮으며, 자신 있게 추측하는 대신 "확신할 수 없습니다"라고 말합니다. 리뷰어 Simon Willison은 이를 기권을 통한 정직함(honesty by abstention)이라고 불렀습니다. 모델이 위험한 지점을 숨기는 대신 표시해주기 때문에, 틀렸을 때 발생하는 비용이 낮아집니다.

이러한 요소들을 종합하면, 비용이 많이 드는 실패 모드(나중에 배포하고 디버깅해야 하는 확신에 찬 오답)는 최상위 계층(top tier)에서 더 드물게 발생하게 되며, 그 반면 사용 비용은 변하지 않았습니다. 출시된 기능에 대한 전체 사양 분석은 Opus 4.8 출시 요약을 참조하세요. 여기서 저는 이것이 제가 어떤 모델을 선택하는 방식을 어떻게 바꾸는지에 대해서만 관심을 두고 있습니다.

Opus 4.8을 선택하는 순간

저의 판단 기준은 단 하나의 질문입니다. '여기서 조용한 오답(silent wrong answer)의 비용이 얼마나 큰가?' 만약 그 비용이 높다면, 언제나 Opus 4.8을 선택합니다.

어려운 에이전트 방식의 코딩(agentic coding)이 가장 명확한 사례입니다. 여러 파일에 걸쳐 있고, 방대한 컨텍스트(context)를 유지해야 하며, 수십 번의 도구 호출(tool calls) 전반에 걸쳐 계획을 일관되게 유지해야 하는 작업들이 이에 해당합니다. 저에게 이 상황에 대응하는 벤치마크는 SWE-Bench Pro이며, 여기서 Opus 4.8은 4.7 버전의 64.3점에서 상승한 69.2점을 기록했습니다. 동일한 테스트에서 Opus 4.8은 GPT-5.5(58.6점)와 Gemini 3.1 Pro(54.2점)를 능가합니다. SWE-Bench Verified에서는 88.6점을 기록했습니다. 이 수치들은 제 저장소(repos) 전반에서 실제 리팩터링(refactor)을 수행할 때 느끼는 체감과 일치합니다.

더 깊은 이유는 기권(abstention)에 있습니다. 15개 파일에 걸친 마이그레이션(migration) 작업에서 최악의 결과는 모델이 막히는 것이 아닙니다. 모델이 조용히 함수 시그니처(function signature)를 지어내고, 성공(green)으로 표시하여 배포한 뒤, 세 번의 커밋(commit) 후에 버그가 나타나게 만드는 것입니다. Opus 4.8은 그러한 행동을 할 확률이 4배 더 낮습니다. 대신 멈춰서 자신이 검증할 수 없는 부분을 저에게 알려줍니다. 제가 유일한 리뷰어인 작업에서는, 그 경고(flag)가 약간의 속도 향상보다 훨씬 더 가치가 있습니다.

또한 저는 하나의 CLAUDE.md 파일로 스튜디오 운영하기에서 설명한 저의 15개 저장소 설정 전체를 가로질러 추론해야 하는 모든 작업에 대해 기본적으로 이 모델을 사용합니다. 방대한 컨텍스트 전반에 걸쳐 하나의 일관된 계획을 세우는 것이야말로 최상위 계층 모델이 그 가격만큼의 가치를 증명하는 바로 그 지점입니다.

공정하게 말하자면, 모든 분야에서 압승을 거둔 것은 아닙니다. Terminal-Bench 2.1에서는 GPT-5.5에 밀려 74.6 대 78.2를 기록했으며, GPQA에서도 4.7 버전과 비교해 약간 뒤처졌습니다 (93.6 대 94.2). 저는 이러한 지표들을 계속 염두에 두고 있습니다. 하지만 작은 실수가 큰 비용으로 이어질 수 있는 다중 파일 추론 (multi-file reasoning) 작업의 경우, 4.8은 제가 문제를 상급 모델로 격상시키기 전 사용하는 도구가 아니라, 기본값 (default)으로 사용하는 모델입니다. 이는 제가 [Opus 티어를 정당화하는 6가지 워크플로우]에서 다루었던 논리와 동일합니다.

Sonnet이 적절한 선택인 경우

Sonnet은 범위가 잘 정해진(well-scoped) 모든 작업을 위한 저의 핵심 작업 도구 (workhorse)입니다. 모델에게 명확한 사양 (spec), 단일 파일, 그리고 엄격한 완료 정의 (definition of done)를 전달할 수 있다면, 최상위 계층의 추가적인 추론 능력은 예산 낭비에 불과합니다. Sonnet은 상대적 비용 측면에서 중간 위치(Opus보다는 저렴하고 Haiku보다는 비쌈)에 있으며, 바로 그 중간 지점이 제 작업량의 대부분이 발생하는 곳입니다.

제가 찾는 패턴은 다음과 같습니다: 작업의 경계가 명확하고, 좋은 결과물이 어떤 모습일지 이미 대략 알고 있는 경우입니다. 기존 디자인 시스템에 맞춰 컴포넌트를 작성하는 것, 방금 작성한 함수에 테스트를 추가하는 것, 모호함을 해결할 필요 없이 깔끔한 사양을 코드로 번역하는 것 등이 해당됩니다. 경로를 이탈할 수 있는 숨겨진 다단계 계획이 없으므로, 모델의 자제력 (abstention)은 덜 중요하며, 저는 차라리 작업당 비용을 낮게 가져가는 쪽을 선호합니다.

지연 시간 (Latency)에 민감한 루프 또한 Sonnet의 영역입니다. 빠르게 반복하며 매 라운드마다 신속한 응답이 필요한, 긴밀한 '작성-실행-읽기 (write-run-read)' 사이클 내의 모든 작업이 여기에 해당합니다. Opus의 사고 예산 (thinking budget)은 저에게 기다림이라는 오버헤드 (overhead)로 느껴집니다. Sonnet은 이 루프를 빠릿하게 유지해 줍니다.

또한 저는 호출당 비용이 누적되는 대량 배치 작업 (high-volume batch work)에서도 Sonnet을 선호합니다. 코드베이스 전체에 걸쳐 수행하는 20개의 유사하고 단순한 수정 작업 같은 경우입니다. 배치 전체에 걸쳐 절감액이 쌓이며, 각 작업이 작기 때문에 비용이 많이 드는 조용한 오류 (silent error)가 발생할 위험도 애초에 낮습니다. 이것이 바로 [Anthropic의 어드바이저 전략]의 핵심입니다. 즉, 유능한 추론 능력을 가격 계층 아래로 밀어 내려 중간 계층이 일상의 더 많은 부분을 처리하도록 만드는 것입니다.

솔직한 테스트 방법은 다음과 같습니다. 만약 작업이 너무 국한되어 있어 잘못될 리가 없다고 판단되어 출력물을 한 줄씩 검토하는 수고를 하지 않겠다면, Sonnet이 정답입니다. 하지만 모든 줄을 다시 확인하고 싶다는 생각이 드는 순간, 그것이 바로 상위 모델로 옮겨가야 한다는 신호입니다.

Haiku가 승리하는 경우

Haiku는 가장 저렴하고 빠른 계층이며, 그것이 바로 Haiku의 역할입니다. 저는 Haiku에게 여러 파일에 걸쳐 추론하거나 긴 계획을 유지하라고 요구하지 않습니다. 대신 한 번에 한 가지 작은 일을, 빠르게, 수천 번 수행하도록 요청합니다.

분류 (Classification) 작업은 Haiku의 홈런입니다. 주제별로 기사에 태그를 달거나, 들어오는 항목들을 버킷(buckets)에 분류하거나, 특정 기준(rubric)에 따라 점수를 매기는 일 등이 이에 해당합니다. 작업 범위가 좁고 출력물이 짧으며, 전체적인 정확도를 집계하여 확인하기 쉽습니다. 이런 작업에 최고 등급의 비용을 지불하는 것은 목록을 알파벳 순으로 정리하기 위해 시니어 엔지니어를 고용하는 것과 같습니다.

초안 작성 또한 Haiku의 또 다른 주력 분야입니다. 어차피 제가 다시 작성할 첫 번째 단계의 카피(copy)나, 제가 직접 편집할 상용구(Boilerplate), 혹은 그냥 훑어보기만 하면 되는 빠른 요약 등이 해당됩니다. 출력물이 완성된 결과물이 아니라 시작점일 때, 다듬어진 품질보다는 속도가 우선시되며, 가장 저렴한 계층이 물량 면에서 승리합니다.

제가 피하는 함정은 판단력이 필요한 업무에 Haiku가 스며들게 두는 것입니다. Haiku가 틀리기 시작하는 정확한 시점은 단 하나의 잘못된 답변이 중요해지는 순간입니다. Haiku는 Opus 4.8이 가진 4배의 기권 (abstention) 이점을 누리지 못하므로, 높은 이해관계가 걸린 단일 호출 (single calls) 상황에서는 최상위 모델이라면 불확실성을 표시했을 부분에서 추측을 해버릴 수 있습니다. 5,000개의 태그 배치 작업에서는 몇 번의 실수가 상쇄되겠지만, 운영 환경(production)에 배포되는 단 한 번의 코드 변경에서는 단 한 번의 확신에 찬 실수가 모든 문제를 일으킵니다. 따라서 라우팅 규칙은 단순히 가격이 아니라, 물량(volume)과 폐기 가능성(disposability)이어야 합니다. 검증 비용이 저렴하고 다시 수행하는 비용이 저렴하다면 Haiku를 사용하십시오. 만약 단 하나의 출력물이 무게감을 갖는다면, 상위 모델로 이동하십시오.

모든 것을 바꾸는 두 개의 다이얼

모델을 선택하는 것은 결정의 절반에 불과합니다. 그 위에 있는 두 가지 설정 또한 그만큼 중요하지만, 사람들은 이를 기본값(defaults)으로 남겨둡니다.

첫 번째 다이얼은 Fast mode(빠른 모드)입니다. 이는 약 2.5배 더 빠르며, 기존의 fast-tier(빠른 계층) 가격의 약 3분의 1 수준, 즉 이전보다 거의 3배 더 저렴합니다. Opus 4.8, 4.7, 4.6에서 사용할 수 있습니다. 이를 통해 저는 속도를 위해 모델 계층을 낮추는 대신, 지연 시간(latency)에 민감한 작업에 무거운 모델을 계속 유지할 수 있습니다. 저의 현재 습관은 이렇습니다: 난이도에 따라 모델을 선택한 다음, 대화형 루프(interactive loop)에 있거나 매 턴마다 기다려야 할 때는 언제든 Fast mode를 켭니다.

두 번째 다이얼은 effort(노력)입니다. 단계는 low, medium, high, xhigh, max로 나뉩니다. 이 단계들은 사고 시간(thinking time)을 속도 및 비용과 맞바꿉니다. Opus 4.8의 경우 실질적인 기본값은 high 근처에 위치합니다. 여러 파일에 걸쳐 진행되는 어려운 agentic coding(에이전트 기반 코딩)의 경우, 많은 사람들이 xhigh에서 시작하여 모델이 행동하기 전에 더 오래 추론(reason)하도록 둡니다. 저는 이를 가볍게 유지합니다: 진정으로 어려운 계획(planning)에는 더 많은 effort를, 정답이 대부분 조회(lookup)인 작업에는 더 적은 effort를 할당합니다.

다음은 제가 라우팅(routing)할 때 사용하는 표입니다.

작업 유형	모델	Fast / Effort
어려운 다중 파일 리팩터링, agentic coding	Opus 4.8	Fast off, xhigh effort
여러 리포지토리에 걸친 아키텍처 또는 계획	Opus 4.8	Fast off, high effort
대화형 코딩 루프, 빠른 반복	Opus 4.8	Fast on, high effort
범위가 명확한 단일 파일 코드, 테스트	Sonnet	Fast on, medium effort
대량 배치 편집, 지연 시간에 민감함	Sonnet	Fast on, low/medium effort
분류, 태깅, 초안 작성	Haiku	Fast on, low effort

연구용 프리뷰 기능인 Dynamic Workflows(수백 개의 병렬 서브 에이전트를 펼치는 기능)는 Max, Team, Enterprise 플랜을 위해 이 모든 것 위에 구축되어 있지만, 이는 별도의 주제이며 요약본에서 다룹니다.

결론 (Bottom Line)

저의 경험칙은 한 줄로 요약됩니다: 모델이 얼마나 저렴한가가 아니라, 조용한 오답(silent wrong answer)이 얼마나 비용이 많이 드는가에 따라 라우팅하십시오. 조용한 실수가 큰 비용을 초래할 때(복잡한 다중 파일 코딩, 혹은 제가 유일한 리뷰어인 모든 작업), 이제 Opus 4.8이 저의 기본값입니다. 왜냐하면 5/25의 고정된 가격이 상한선을 안정적으로 유지하는 동안, (답변을) 거부하는 것이 틀렸을 때 발생하는 비용을 낮춰주기 때문입니다. 작업 범위가 명확할 때는 Sonnet을 사용합니다. 저렴하고, 일회성이며, 대량의 작업일 때는 Haiku를 사용합니다. 그다음 두 개의 다이얼을 설정하십시오: 제가 기다려야 하는 모든 루프(loop)에는 Fast mode를, 진정으로 어려운 계획(planning)에는 더 많은 노력(more effort)을 할당합니다. 이것이 전체 프레임워크입니다. 최상위 티어는 더 이상 제가 아껴 써야 하는 사치품이 아니라, 어려운 작업을 위한 합리적인 기본값이 되었습니다. 이는 1년 전 제가 처했던 상황과는 실질적인 변화입니다. 제가 실제 클라이언트 및 제품 빌드에 이 라우팅을 어떻게 적용하는지 알고 싶다면, 여기 제 1인 스튜디오가 실제로 출시하는 결과물이 있습니다.