Claude 모델 고르기 — 똑똑한 것부터 시작하라

1. 이 글은 무엇에 관한 글인가?

한 줄로 요약하면 이렇습니다.

"싼 모델부터 써보고 부족하면 올린다"는 순서가 뒤집혔습니다. 지금 권장되는 순서는 가장 똑똑한 모델로 시작해서, effort(노력 수준)를 낮춰가며 비용을 맞추는 것 입니다.

어제 글(덜어내는 컨텍스트 엔지니어링)에서 마지막에 이렇게 적었습니다. "하네스는 모델에 맞춰 조정되는 것이다." 그렇다면 그 모델은 어떻게 고르나요? 이번 글이 그 질문에 대한 답입니다.

우리가 습관적으로 하던 계산

모델을 고를 때 대부분 이렇게 생각합니다.

"Haiku가 100만 토큰에 $1이고 Opus가 $5네.
 5배 비싸잖아? 일단 Haiku로 해보고, 안 되면 올리자."
   ↓
 Haiku가 3번 만에 못 풀어서 재시도
   ↓
 프롬프트를 계속 다듬어서 겨우 통과시킴
   ↓
 ...결국 토큰은 더 쓰고, 사람 시간은 훨씬 더 씀

이 계산의 함정은 단위가 틀렸다 는 것입니다. 우리가 지불하는 건 토큰이 아니라 "일 하나를 끝내는 데 드는 비용" 입니다. Anthropic이 짚은 지점이 정확히 여기입니다.

토큰당 단가가 비싸도, 작업당 비용은 더 똑똑한 모델이 더 싼 경우가 많다 — 특히 낮은 effort에서. 더 유능한 모델은 턴을 적게 쓰기 때문입니다.

한 번에 끝내는 모델과 세 번 만에 끝내는 모델이 있다면, 토큰 단가가 3배여도 총액은 같습니다. 거기에 사람이 프롬프트를 고치느라 쓴 시간 까지 넣으면 계산은 완전히 뒤집힙니다.

2. 모델 계층 — 4가지 등급

Claude 모델은 개별 모델 이름이 아니라 등급(class) 으로 이해하는 편이 빠릅니다. 세대는 계속 바뀌지만 등급의 성격은 유지되기 때문입니다.

Mythos는 이중용도(dual-use) 사이버보안·생물학 분야를 다루는 검증된 조직에만 제공되고, 일반 공개용은 안전장치가 추가된 Fable 입니다. 같은 등급의 형제라고 보면 됩니다.

지금 시점의 실제 라인업

2026년 8월 기준 주요 모델을 정리하면 이렇습니다.

• Sonnet 5는 2026-08-31까지 도입가 $2 / $10 이 적용됩니다. 지금 벤치마킹한다면 이 점을 감안하세요.
• 가격·라인업은 바뀝니다. 글의 숫자를 믿지 말고 공식 문서를 확인 하세요. 여기서 봐야 할 건 절대값이 아니라 등급 간 배율 입니다.

여기서 눈에 띄는 사실 하나. Haiku만 200K이고 나머지는 전부 1M 입니다. "긴 컨텍스트가 필요하다"는 이유만으로 최상위 모델을 고를 필요는 없다는 뜻입니다.

3. 무엇을 물어봐야 하나 — 4가지 질문

Anthropic이 제시한 판단 기준은 4개입니다. 순서대로 답하면 후보가 좁혀집니다.

① 이 일은 얼마나 어려운가?    → 등급의 하한선을 정한다
② 지연(latency) 요구는?       → 사용자가 기다리는 화면인가, 배치인가
③ 접근 제약은?                → 특정 클라우드·리전·규정만 써야 하는가
④ 단위 경제성은?              → 하루 1만 건인가, 하루 10건인가

각 질문이 실제로 무엇을 가르는지 보겠습니다.

③이 의외로 자주 걸립니다. 모든 기능이 모든 플랫폼에 있는 것이 아닙니다. 예를 들어 fast mode(같은 모델을 더 빠른 출력 속도로 돌리는 옵션)는 일부 모델·일부 경로에서만 지원됩니다. "모델은 정했는데 우리 배포 환경에서 그 기능이 없더라" 같은 일이 실제로 생깁니다.

4. 두 번째 축 — effort

여기가 이번 이야기의 핵심입니다. 모델 선택은 1차원이 아니라 2차원 입니다.

         effort →   low    medium   high    xhigh    max
       ┌────────────────────────────────────────────────
Fable  │   ·        ·        ·        ·        ●   ← 최고 성능
Opus   │   ·        ·        ●        ●        ·
Sonnet │   ·        ●        ·        ·        ·
Haiku  │   ●        ·        ·        ·        ·   ← 최저 비용
       └────────────────────────────────────────────────
                 ↖ 여기 대각선이 진짜 선택지

effort 는 한 작업에 얼마나 깊이 생각할지를 조절하는 값입니다(low / medium / high / xhigh / max). 그리고 여기서 나오는 결론이 직관과 다릅니다.

높은 등급 + 낮은 effort 가 낮은 등급 + 높은 effort 보다 효율적일 때가 있다.

즉 "Opus는 비싸니까 Sonnet을 쓰자"가 아니라, "Opus를 낮은 effort로 돌리면 어떤가?" 를 먼저 재봐야 한다는 뜻입니다. 이게 "가장 똑똑한 모델로 시작하라"는 조언의 실질적인 내용입니다.

그래서 실무 순서는

① 지금 일반 공개된 가장 똑똑한 모델을 고른다
② 기본 effort로 돌려서 "품질 기준선"을 만든다
③ effort를 한 단계씩 낮춘다 → 품질이 유지되는 지점을 찾는다
④ 그래도 비싸면, 그때 등급을 내려서 ②③을 다시 한다

③에서 멈추는 경우가 생각보다 많습니다. 등급을 내리지 않고도 비용이 맞아버리는 것이죠. 반대로 ①을 건너뛰고 밑에서 시작하면, 기준선 자체가 없어서 "이게 최선인가?"를 영원히 알 수 없습니다.

5. 어드바이저 전략 — 두 모델을 같이 쓰기

하나 더. 모델을 하나만 고를 필요가 없습니다.

어드바이저 전략(advisor strategy) 은 빠르고 싼 모델을 작업자(worker) 로, 더 유능한 모델을 조언자(advisor) 로 두는 구성입니다.

  [ 조언자 ]  더 똑똑한 모델
      │  계획이 맞나? / 결과가 쓸 만한가?
      │  ↕ 필요할 때만 물어봄
  [ 작업자 ]  빠르고 싼 모델
      │
      └─ 토큰의 대부분을 여기서 생성

핵심은 "필요할 때만 물어본다" 는 것입니다. 비싼 모델을 처음부터 끝까지 돌리는 대신, 방향을 정하는 순간과 결과를 판정하는 순간에만 부릅니다.

효과는 숫자로 나와 있습니다.

SWE-bench Pro 기준, Sonnet 5 + Fable 5 어드바이저 조합은 Fable 5 점수의 10% 이내 를 가격의 63% 로 달성했습니다.

품질의 90% 이상을 63% 비용에 얻는다는 뜻입니다. 이 조합이 항상 이기는 건 아니지만, "등급 하나를 통째로 고른다"는 이분법에서 벗어나면 선택지가 늘어난다 는 점이 중요합니다.

주의 — 조언자는 작업자보다 약할 수 없다

당연해 보이지만 실수하기 쉬운 지점입니다. 조언자 모델은 작업자 모델과 같거나 더 유능해야 합니다. 거꾸로 짝지으면 애초에 거부됩니다. 조언은 위에서 아래로만 흐릅니다.

6. 벤치마크는 왜 답을 안 주나

"그냥 벤치마크 점수 제일 높은 걸 쓰면 되지 않나요?" 여기에 두 가지 문제가 있습니다.

문제 1 — 포화(saturation)

상위 모델들은 표준 벤치마크의 문제를 거의 다 맞춥니다. 98점과 97점 사이에서는 아무것도 구별되지 않습니다. 자를 대고 재는데 눈금이 다 떨어진 셈입니다.

문제 2 — 당신의 문제가 아니다

벤치마크는 일반적인 문제 를 잽니다. 하지만 우리가 궁금한 건 우리 문제 에서의 성능입니다. 이 둘은 자주 어긋납니다.

자체 eval 만들기가 이 글에서 가장 실행하기 어려운 조언 이라는 건 인정합니다. 하지만 시작은 생각보다 작아도 됩니다.

① 최근 실패했던 실제 케이스 20개를 모은다
② 각각에 대해 "통과 조건"을 한 줄로 적는다
   (예: "price 컬럼이 숫자형인 CSV를 반환한다")
③ 후보 모델·effort 조합을 여기에 돌린다
④ 통과율 · 총 토큰 · 소요 시간을 같이 기록한다

여기서 ②가 핵심입니다. "결과가 괜찮다" 같은 기준으로는 아무것도 판정할 수 없습니다. 기계가 채점할 수 있는 문장으로 적어야 합니다.

7. 오해하기 쉬운 지점

오해 1 — "그럼 무조건 제일 비싼 걸 쓰라는 건가?"

아닙니다. 시작점을 위에서 잡으라는 것 이지 거기 머물라는 게 아닙니다. 4단계 순서의 절반(③④)은 내려오는 과정입니다. 위에서 시작하는 이유는 단 하나, 기준선을 알기 위해서 입니다.

오해 2 — "어드바이저 전략을 다 쓰면 되겠네"

두 모델을 쓰면 구조가 복잡해지고 지연도 늘어납니다. 조언을 구하는 왕복이 추가되기 때문입니다. 단일 모델 + effort 조절로 해결되면 그게 낫습니다. 어드바이저는 "단일 모델로는 품질·비용이 동시에 안 맞을 때" 꺼내는 카드입니다.

오해 3 — "한 번 정하면 끝인가?"

아닙니다. 모델은 계속 나오고 가격도 바뀝니다. 그래서 자체 eval이 중요합니다. eval이 있으면 새 모델이 나올 때마다 반나절이면 재평가 할 수 있지만, 없으면 매번 감으로 다시 시작해야 합니다. eval은 모델 선택 도구이자 재선택 도구 입니다.

8. 정리 — 결국 두 가지

이 글의 조언을 압축하면 두 문장입니다.

그리고 이건 앞선 두 글과 같은 이야기이기도 합니다.

• 자가치유 하네스 — 규칙을 더할 때 도 검증하고 승인받아라
• 덜어내는 컨텍스트 엔지니어링 — 규칙을 덜어낼 때 도 검증해라
• 이번 글 — 모델을 고를 때 도 검증해라

세 글의 공통 구조는 같습니다. 감으로 결정하지 말고, 자기 워크로드로 재고 나서 결정하라. 하네스든 프롬프트든 모델이든, 판단 기준을 밖에서 빌려오면 그 순간부터 자기 문제를 못 보게 됩니다.

핵심 메시지는 하나입니다.

"어느 모델이 제일 좋은가"는 답이 없는 질문이다. 답이 있는 질문은 "우리 일에서 어느 조합이 제일 좋은가"이고, 그건 재봐야만 알 수 있다.

참고 문서

• Anthropic, Claude Models Explained: Choosing the Best Model for Your Use Case (2026)
• Anthropic, The New Rules of Context Engineering for Claude 5 Generation Models (2026)
• Anthropic, Models overview — 최신 모델 ID·컨텍스트·가격
• 이전 글 — 덜어내는 컨텍스트 엔지니어링 · 자가치유 하네스 엔지니어링