Claude 모델별 특징과 비용, 그리고 여러 모델을 함께 활용하는 방법까지 정리했습니다.
현재 Claude 라인업에는 정식 출시된 모델이 네 가지 있습니다. Claude Haiku 5.5, Claude Sonnet 5.5, Claude Opus 5.5, Claude Fable 5.2입니다. Claude Mythos 5.2는 사이버 보안과 생명과학 연구에 가장 뛰어난 모델로, 인증 프로그램을 통해 이용할 수 있습니다.
Claude Platform에서 개발하거나 Claude Code로 작업한다면, 자주 하는 작업에 어떤 모델을 써야 할지 고민될 때가 있을 것입니다. 이 글에서는 모델별로 무엇을 얻고 무엇을 포기하게 되는지 살펴보며 그 기준을 정리합니다.
간단히 말하면, 대부분의 작업은 기본 effort 수준인 medium의 Opus 5.5로 시작하면 됩니다.
Claude Code의 기본 모델이 Opus 5.5인 데는 이유가 있습니다. 입력과 출력 토큰당 비용이 Fable 5.2의 절반이면서, 코딩과 지식 업무 대부분에 시작점으로 권장하는 모델이기 때문입니다.
여기서부터는 이렇게 조정하세요.
high의 Opus 5.5로도 부족하거나, 사람이 지켜보지 않는 긴 작업을 돌릴 때도 마찬가지입니다.모델을 바꾸기 전에 먼저 effort 수준을 조정해 보세요. 비용과 성능을 더 세밀하게 조절할 수 있는 수단입니다. high를 넘어서면 effort를 한 단계만 올려도 더 큰 모델만큼 비용이 들 수 있으므로, 실제 작업에서 둘을 비교해 보세요. 이미 high를 넘었다면 effort를 올리는 대신 한 단계 위 모델을 낮은 effort로 테스트해 보는 편이 낫습니다. 반대로 한 단계 낮춰도 필요한 결과를 더 낮은 비용으로 얻을 수 있습니다.
effort를 높이면 모델이 더 오래 생각하고, 도구를 더 많이 호출하고, 자기 결과물을 더 꼼꼼히 검증하는 데 도움이 됩니다. 다만 지연 시간도 늘어납니다. 또 effort를 높인다고 모델이 갖지 못한 지식이나 능력이 생기지는 않습니다. 그런 경우에는 역시 더 큰 모델로 올라가야 합니다.
| 작업 | 시작 모델 | 시작 effort | 이유 |
|---|---|---|---|
| 일상적인 개발과 디버깅, 여러 PR에 걸친 기능 개발 | Opus 5.5 | medium(기본값), 이후 high | 일상 업무에서 비용과 성능의 균형이 좋습니다. |
| 분류, 라우팅, 태깅, 대량 추출 | Haiku 5.5 | medium(기본값) | 모델 라인업 중 비용과 지연 시간이 가장 낮습니다. |
| 파일 검색, 로그 읽기, 요약을 맡는 서브에이전트 | Haiku 5.5 또는 Sonnet 5.5 | 모델의 기본값 | 잘못된 답을 쉽게 알아챌 수 있고, 어차피 판단이 필요한 부분은 메인 모델이 맡습니다. |
| 채팅 및 대화형 세션 | Sonnet 5.5(대량의 단순 채팅은 Haiku 5.5) | low 또는 medium | Sonnet 5.5는 특히 low나 medium effort에서 빠릅니다. |
| 버그 수정, 기능 반복 개선, 명세 기반 작업처럼 범위가 분명한 코딩 | Sonnet 5.5 | medium, 어려운 작업은 high | 범위가 정해진 작업을 Opus 5.5의 절반 토큰 가격으로 잘 처리합니다. |
| 일상적인 문서, 슬라이드, 스프레드시트 | Sonnet 5.5 | high(기본값, Claude Code에서는 medium) | 반복 작업이 빠르고 디자인 감각도 뛰어납니다. 복잡한 재무 모델이나 방대한 자료를 바탕으로 문서를 만들 때는 Opus 5.5로 시작하세요. |
| 조사, 리뷰, 초안 작성처럼 반복해서 실행하는 에이전트 작업 | Sonnet 5.5 | medium | 정의가 명확하고 반복되는 작업에는 더 큰 모델이 필요한 경우가 드뭅니다. |
| 컴퓨터 사용(computer use) 및 비전 중심 워크플로 | Opus 5.5 | medium | 수많은 스크린샷과 이미지를 다루는 긴 에이전트 루프로, 장시간 에이전트 작업을 위해 만든 Opus 5.5에 적합합니다. |
| 대규모 리팩터링과 마이그레이션, 아키텍처 설계, 다수의 서브에이전트 지휘 | Fable 5.2 | medium, 이후 high(API 기본값은 high) | Anthropic이 정식 출시한 모델 중 기술 분야에서 가장 뛰어난 모델입니다. |
| 딥 리서치, 과학·정량 분석 | Fable 5.2 | medium, 이후 high(API 기본값은 high) | 코딩, 금융, 과학 분야에서 가장 어려운 기술 프로젝트를 위해 만들어졌습니다. |
| 아직 잘 모르겠을 때 | Opus 5.5 | medium(기본값) | Claude Code는 Pro, Max, Ultra, Team, Enterprise 및 Anthropic API에서 이 모델을 기본으로 사용하며, 플랫폼 문서에서도 시작점으로 권장합니다. |
| Haiku 5.5 | Sonnet 5.5 | Opus 5.5 | Fable 5.2 | |
|---|---|---|---|---|
| 적합한 용도 | 대량 처리와 비용에 민감한 작업 | 범위가 분명한 작업을 빠르고 능숙하게 처리 | 복잡한 코딩과 지식 업무를 위한 주력 모델 | 가장 도전적이고 정해진 답이 없는 기술 작업 |
| 상대적 지연 시간 | 가장 빠름 | 빠름 | 보통 | 보통 |
| 입력 / 출력, 100만 토큰당 | 프롬프트 10만 토큰 이하 $0.10 / $0.50, 10만 토큰 초과 $0.50 / $2.50 | $2 / $10 | $4 / $20 | $8 / $40 |
| 캐시 읽기, 100만 토큰당 | 10만 토큰 이하 $0.01, 초과 $0.05 | $0.10 | $0.20 | $0.20 |
| 컨텍스트 윈도우 | 100만 토큰 | 100만 토큰 | 100만 토큰 | 100만 토큰 |
| 최대 출력 | 12만 8천 토큰 | 12만 8천 토큰 | 12만 8천 토큰 | 12만 8천 토큰 |
| API의 사고(thinking) 설정 | 적응형, 기본 켜짐, 끌 수 있음 | 적응형, 기본 켜짐, between_tools를 쓰면 사전 사고를 건너뜀 | 적응형, 항상 켜짐 | 적응형, 항상 켜짐 |
API 기본 effort(Claude Code에서는 다를 수 있으며, /effort status로 현재 설정을 확인할 수 있습니다) | medium | high(Claude Code에서는 medium) | medium | high(Claude Code에서는 medium) |
| Fast mode | 미지원 | 미지원 | 지원 | 지원 |
가격은 Claude API 정가 기준입니다. 벤치마크 결과는 Fable 5.2 페이지에서 확인하세요.
모델을 고른다는 것은 무언가를 얻는 대신 다른 무언가를 내주는 일입니다. 예를 들어 더 큰 모델을 택하면 지연 시간을 감수하는 대신 성능을 얻습니다. 고려해야 할 주요 트레이드오프는 다음과 같습니다.
일반적으로 큰 모델일수록 토큰당 비용이 높고 성능도 좋습니다. 하지만 개별 작업 단위로 보면 이 관계가 늘 성립하지는 않습니다.
토큰당 가격이 높다고 해서 작업당 비용이 항상 높거나 결과가 더 좋은 것은 아닙니다. Spending your effort에서 소개했듯이, Anthropic이 Terminal-Bench 3.0으로 실행한 결과 이전 버전인 Fable 5.1은 max에서 58.0%를 기록했고, Opus 5.5는 high에서 절반의 토큰만 쓰고도 58.9%를 기록했습니다.
가장 어려운 작업에서는 가격 차이가 좁혀지기도 합니다. FrontierCode 2.0에서 high의 Fable 5.2는 max의 Opus 5.5와 거의 같은 점수(45.3% 대 45.5%)를 작업당 약 절반의 비용으로 기록했습니다. 그러니 어려운 작업에서 Opus 5.5의 effort를 high 이상으로 올리기 전에 Fable 5.2를 먼저 테스트해 보세요. 일상적인 작업에서는 여전히 medium의 Opus 5.5로 시작하는 것이 좋습니다. 벤치마크 결과는 출시 게시글을 참고하세요.
한편 Claude Platform의 비용 및 지능 측정 결과는 작은 모델의 한계도 보여 줍니다. 작은 모델은 결과를 검증할 수 있는 대량 작업에서는 대체로 좋은 성과를 내지만, 긴 에이전트 루프에는 덜 적합합니다.
두 모델을 비교할 때는 평범한 작업뿐 아니라 가장 어려운 작업의 비용도 함께 계산하세요. 지출 대부분이 어려운 작업에서 나오기 때문입니다. 20개 문제로 구성된 한 검색 벤치마크에서는 단 두 문제가 전체 지출의 43%를 차지했습니다.
설정이 빠를수록 작업은 일찍 끝나지만 놓치는 부분도 늘 수 있습니다. 모델과 effort 수준을 고르기 전에 사용자가 얼마나 기다릴 수 있는지부터 생각해 보세요. 사람이 기다리는 응답이라면 low 또는 medium의 Sonnet 5.5로 시작하세요.
새로운 세대의 모델은 이전 세대보다 빠른 경우가 많습니다. Fable 5.2는 Fable 5.1보다 출력 생성 속도가 최대 30% 빠르고, Sonnet 5.5는 Sonnet 5보다 30% 빠르게 동작합니다.
effort 수준과 지연 시간은 대체로 비례합니다. 정확도가 올라가는 만큼 지연 시간이 늘어나도 괜찮은지 따져 보세요. 예를 들어 SWE-bench Pro에서 medium의 Opus 5.5는 high effort 설정보다 점수가 약 2.5점 낮았지만 비용은 약 70% 수준이었습니다. low에서는 점수가 약 8점 낮았고 비용은 약 3분의 1이었습니다. xhigh에서는 high보다 점수가 약 1.4점 높았지만 비용은 2.5배였습니다.
effort 수준을 바꾸는 것보다 모델이 스스로 검증할 수단을 주는 편이 비용 효율이 높고 지연 시간도 덜 늘어나는 경우가 많습니다. 모델이 작업을 제대로 해내지 못한다면 다음 순서로 시도해 보세요.
결과를 자동으로 확인할 수 있다면 모든 작업을 낮은 수준으로 돌리고, 실패한 작업만 높은 수준으로 다시 실행하세요. 같은 SWE-bench Pro 하위 집합에서 low의 Opus 5.5로 실행하고 실패한 작업을 high로 재실행했더니 작업의 약 97%를 통과했고 비용은 건당 약 $0.17이었습니다. 모든 작업을 high로 돌렸을 때는 통과율 95.3%에 건당 $0.29였습니다.
같은 모델에서 더 빠른 응답이 필요하다면 성능을 포기하는 대신 속도에 비용을 지불할 수도 있습니다. Claude API에서 Opus 5.5와 Fable 5.2는 모두 fast mode를 제공하며, 추가 요금을 내면 출력 속도가 더 빨라집니다.
현재 세대의 모든 모델은 100만 토큰 컨텍스트 윈도우를 지원합니다. 컨텍스트가 크면 모델이 작업을 완수하는 데 도움이 되지만, 매 턴마다 컨텍스트를 다시 전송하므로 그만큼 비용이 듭니다. 그래도 긴 작업에서는 입력 대부분이 캐시 읽기로 과금됩니다.
캐시 읽기 요금은 100만 토큰당 Opus 5.5가 $0.20, Sonnet 5.5가 $0.10입니다. Fable 5.2도 똑같이 $0.20이므로, 캐시 비중이 큰 긴 작업에서 Fable과 Opus의 비용 차이는 캐시되지 않은 입력과 출력에서 발생합니다. 이 부분은 Fable이 토큰당 두 배 비쌉니다.
What a task costs on Opus 5.5에 따르면 컨텍스트가 15만 토큰일 때 한 턴의 캐시 읽기 비용은 약 $0.03이고, 2만 토큰일 때는 약 $0.004입니다.
여기서 얻을 수 있는 교훈은 메인 모델이 클수록 메인 컨텍스트를 가볍게 유지하는 것이 더 중요하다는 점입니다. 비싼 모델의 컨텍스트는 의사결정에만 쓰고, 방대한 읽기 작업은 더 저렴한 서브에이전트에 맡기세요.
Haiku 5.5는 프롬프트 길이에 따라 토큰 가격이 달라지는 유일한 모델입니다. 프롬프트가 10만 토큰 이하이면 낮은 요금이 적용되고, 10만 토큰을 넘으면 그 5배 요금이 적용됩니다. 그래도 긴 프롬프트 구간의 토큰당 가격은 Sonnet 5.5의 4분의 1 수준입니다. 따라서 Haiku 5.5는 짧은 프롬프트에서 가장 큰 효과를 냅니다. 이때 입력 가격이 Sonnet 5.5의 20분의 1이기 때문입니다.
호출마다 긴 프롬프트가 필요하다면 정가가 아니라 작업 완료당 비용을 기준으로 Haiku 5.5와 Sonnet 5.5를 비교하세요.
프롬프트 캐시는 그것을 만든 모델에만 속합니다. 새 모델로 처음 보내는 턴에서는 대화 전체에 대해 캐시 쓰기 요금을 내게 됩니다. 이 턴의 크기를 줄이려면 Claude Code에서 먼저 /compact를 실행하거나, 짧게 정리한 계획을 들고 새 세션을 시작하세요. API에서는 전체 기록 대신 지금까지의 작업 요약으로 새 모델의 대화를 시작하면 됩니다.
각 thinking 블록에는 이를 생성한 모델이 기록되며, 모델마다 읽을 수 있는 다른 모델의 블록은 일부로 제한됩니다. Claude API와 Claude Models on Google Cloud(Google 관리형)에서 Opus 5.5는 Sonnet 5.5와 Haiku 5.5의 thinking 블록을 읽을 수 있습니다. Sonnet 5.5는 Haiku 5.5의 블록을 읽습니다. Fable 5.2는 Opus 5.5, Sonnet 5.5, Haiku 5.5의 블록을 읽습니다. Claude API에서 Fable 5.1은 Opus 5.5의 블록을 읽습니다.
모델은 자기보다 상위 모델의 블록을 읽지 못하므로, 한 단계 아래 모델로 내려가면 이전 추론이 사라집니다. 다른 경우에도 사라질 수 있습니다. 새 모델이 이전 모델의 thinking 블록을 읽지 못하면 API가 해당 블록을 제거하며, 요청 자체는 성공합니다. 그러면 새 모델은 그 추론 없이 작업합니다.
Preserved thinking 문서에 모든 경우가 정리되어 있습니다. Fable 5.2에서 정식 출시된 다른 모델로 옮기면 Fable 5.2의 추론은 모두 사라집니다.
서브에이전트는 자체 컨텍스트 윈도우에서 실행되고 요약만 돌려줍니다. 토큰 비용은 서브에이전트가 실행되는 모델의 요금으로 계산됩니다. Claude Code에서는 서브에이전트 정의에 model: haiku 또는 model: sonnet를 지정하면 됩니다. 모델을 지정하지 않은 서브에이전트의 기본값은 CLAUDE_CODE_SUBAGENT_MODEL 환경 변수로 설정합니다.
다음 내용을 .claude/agents/log-reader.md로 저장하세요.
--- name: log-reader description: Reads test output and logs, and reports each failing case. Use after a test run. tools: Read, Grep, Glob, Bash model: haiku --- Read the logs you're given. For each failure, report the file, the test name and the first error line. Don't edit any files.
작은 모델에는 파일 찾기, 테스트 실행, 로그 읽기처럼 실수를 쉽게 알아챌 수 있는 작업만 맡기세요. 코드 수정과 판단이 필요한 작업은 메인 모델에 두어야 합니다. 작은 모델이 검색 결과를 잘못 읽으면 메인 모델이 엉뚱한 파일을 열고 거기에 토큰을 낭비하게 됩니다.
최신 버전 Claude Code에서는 기본 제공 Explore 서브에이전트가 항상 Haiku로 실행되는 대신 세션에서 사용 중인 모델로 실행됩니다. Claude API에서는 그 모델이 Opus까지로 제한됩니다. 탐색 비용을 낮게 유지하려면 Explore라는 이름의 서브에이전트를 model: haiku로 직접 정의하세요. haiku 별칭이 가리키는 모델은 ANTHROPIC_DEFAULT_HAIKU_MODEL로 고정할 수 있습니다.
Anthropic API에서는 이제 haiku 별칭이 Haiku 5.5를 가리키며, 이를 사용하려면 Claude Code v2.1.293 이상이 필요합니다. Amazon Bedrock, Google Cloud, Microsoft Foundry, Claude Platform on AWS에서는 여전히 Haiku 4.5를 가리킵니다. 자세한 내용은 Claude Code 모델 설정 문서를 참고하세요.
Claude Code에는 opusplan 별칭도 있습니다. 플랜 모드에서는 Opus로 계획을 세우고, 이후 Sonnet으로 그 계획을 실행합니다. 즉 코드 수정을 Sonnet이 맡게 됩니다. 앞서 설명한 방식은 그 반대입니다. 코드 수정은 메인 모델이 맡고, 작은 모델에는 실수를 쉽게 알아챌 수 있는 작업만 줍니다. opusplan를 기본값으로 정하기 전에 직접 작업에 적용해 성능을 측정해 보세요.
어드바이저 도구(베타)는 더 빠르고 저렴한 실행 모델과 더 강력한 어드바이저 모델을 짝지어 줍니다. 실행 모델이 작업을 수행하다가 중간에 어드바이저에게 조언을 구할 수 있습니다. 토큰 대부분은 실행 모델의 요금으로 과금됩니다. 어드바이저는 실행 모델에 없는 능력을 보태 줄 때, 그리고 실행 모델이 조언을 구할 때만 도움이 됩니다. 낮은 effort에서는 조언을 구하는 빈도도 낮아집니다.
효과를 볼 만한 경우는 대부분의 턴이 반복적이고 단순한 에이전트 작업입니다. 다만 플랫폼의 비용 가이드는 신중한 입장입니다. 어드바이저 표에 있는 네 가지 조합 중 실행 모델 단독보다 확실히 나았던 경우는 없었고, 어드바이저는 실행 모델이 조언을 구해야만 도움이 됩니다. 먼저 실행 모델이 조언을 구하는 비율을 측정하세요. 실행 모델이 어떤 어드바이저를 받아들이는지도 확인해야 합니다. 예를 들어 Sonnet 5.5 실행 모델은 Fable 5.2, Opus 5.5, Opus 5, Sonnet 5.5를 어드바이저로 받아들이고, Fable 5.2 실행 모델은 Fable 5.2나 Mythos 5.2만 받아들입니다.
효과가 미미한 경우도 있습니다. 해당 조합 중 하나는 high의 Opus 5.5 실행 모델에 Fable 5.1 어드바이저를 붙여 내부 코딩 벤치마크를 돌린 것으로, 시도당 $2.92에 90.1%를 기록했습니다. high의 Opus 5.5 단독보다 1.7점 높지만 비용은 약 2.1배입니다. 이 정도 차이는 실행마다 생기는 편차와 비슷한 수준이며, effort를 높였을 때 얻는 효과와도 비슷합니다.
앞서 다룬 서브에이전트는 메인 모델이 흐름을 유지하는 동안 부수 작업을 처리합니다. 이 패턴은 컨텍스트 윈도우 하나로는 감당할 수 없는 규모의 작업을 위한 것입니다. 최상위 모델이 총괄하며 작업을 쪼개 저렴한 워커 여러 개에 병렬로 나눠 주고, 돌아온 결과를 병합합니다. 소스 코드 약 2,200만 토큰을 대상으로 한 내부 결함 탐색 벤치마크에서, Opus 5.5가 총괄하고 Sonnet 5.5 워커를 최대 25개까지 동시에 돌린 구성은 기본 effort의 Opus 5.5 단독보다 비용이 약 3분의 1 적게 들었고 점수는 비슷했습니다.
Claude Platform에서는 Claude Managed Agents의 멀티에이전트 오케스트레이션으로 코디네이터 에이전트와 워커 목록을 구성할 수 있습니다. 서로 의존하는 단계가 하나로 이어진 작업이나 컨텍스트 윈도우 하나에 들어가는 작업에는 쓰지 마세요. 이런 경우에는 계획과 병합에 드는 비용이 절감액보다 큽니다. 에이전트 루프 하나가 서브에이전트 팀보다 나은 경우는 When to fold subagents into your main agent loop에서 다룹니다.
모델 선택은 대체로 성능과 비용의 문제지만, 모델 이름만 바꾸고 나머지는 그대로 둘 수 없는 경우도 있습니다. 현재 모든 모델이 도구 사용과 이미지 입력을 지원하지만, 요청을 한 모델에서 다른 모델로 옮기기 전에 테스트해야 할 차이가 있습니다.
between_tools를 쓰면 사고가 도구 호출 사이의 구간으로 제한됩니다. Haiku 5.5도 기본적으로 사고하며, high 이하 effort에서는 thinking을 끌 수 있습니다. 모든 모델에서 응답이 thinking 블록으로 시작할 수 있으므로, 콘텐츠 블록은 type 기준으로 읽어야 합니다.tool_choice을 any 또는 tool로 설정하면 400 오류가 반환됩니다. auto를 보내고, 도구를 strict: true로 표시한 뒤, 프롬프트에서 언제 그 도구를 사용해야 하는지 알려 주세요.computer_toolset_20260801 도구 세트로만 컴퓨터 사용을 지원합니다.budget_tokens를 effort 수준으로 대체하고, 기본값이 아닌 temperature, top_p, top_k 값은 400 오류가 반환되므로 제거하세요. messages는 사용자 턴으로 끝내야 합니다. 모델이 이어서 작성하도록 마지막을 어시스턴트 턴으로 두는 경우에도 400 오류가 반환됩니다.하나의 시스템에서 여러 모델을 쓴다면 가장 엄격한 모델에 맞춰 모든 요청을 구성하세요. 기록은 추가만 하는 방식으로 유지하고, strict 도구와 함께 tool_choice: auto를 보내고, 콘텐츠 블록은 type 기준으로 읽고, 프롬프트와 도구 설명은 가장 문자 그대로 해석하는 모델도 이해할 수 있게 정확히 작성합니다. 그러면 코드를 바꾸지 않고도 단계마다 모델을 한 단계 올리거나 내릴 수 있습니다. 단계 유형별로 모델 하나씩처럼 라우팅 규칙이 단순하다면, 모델에게 고르게 하지 말고 코드로 모델을 선택하세요.
위에서 본 SWE-bench Pro나 Terminal-Bench 같은 공개 결과로는 시작 모델을 정할 수 있습니다. 확정하기 전에는 후보 모델을 내 작업으로 직접 테스트해 보세요.
usage 필드에서 기록합니다.Claude Code에서 빠르게 확인하려면 백로그의 작업 하나를 /model로 두 모델에서 실행하고 /usage가 보고하는 값을 비교해 보세요.
