페이블이 Pro 요금제에 잠깐 제공됐을 때, 저는 모든 작업을 페이블로 돌렸습니다. 제일 좋은 모델이라니까요. 며칠 뒤에 남은 건 성능 감동이 아니라 바닥난 한도였습니다.
그 반대도 해봤습니다. 아끼려고 큰 작업을 아래 모델로 내렸더니 이번엔 디테일이 빠지더군요. 실패를 양방향으로 다 겪고 나서야 제대로 된 클로드 모델 비교가 필요하다는 걸 인정했습니다. 공식 문서를 다시 읽고 정리한, 4종을 가르는 기준을 적습니다.
제일 좋은 모델을 전부에 썼더니, 한도가 먼저 죽었습니다
“어차피 쓸 거면 제일 똑똑한 걸로.” 페이블을 기본값으로 두고 짧은 수정, 파일 정리, 간단한 질문까지 전부 맡겼습니다. 오래 못 갔습니다. 한도 경고가 먼저 왔거든요.
나중에 공식 문서를 읽고 머쓱해졌습니다. 앤트로픽은 페이블을 “가장 어려운 미해결 문제”에 쓰라고 안내하고, 쉬운 작업으로만 시험하면 이 모델의 능력 범위를 과소평가하게 된다고까지 적어뒀습니다. 가격도 입력 기준 오퍼스의 2배($10 vs $5, 백만 토큰당)죠.
쉬운 작업에서는 능력 차이가 안 보입니다. 비용 차이만 남습니다. 저는 그 차이를 한도로 지불했습니다.
아끼려고 내렸더니, 이번엔 디테일이 빠졌습니다
그래서 반대로 갔습니다. 큰 작업도 오퍼스나 소넷으로. 어느 정도는 굴러갔는데, 페이블로 하던 급의 작업에서 빠지는 게 생기더군요. 놓친 걸 다시 잡는 왕복이 늘었고, 재작업도 결국 토큰이라는 건 앞 글에서 겪은 그대로였습니다.
두 실패의 공통점은 하나입니다. 작업 크기와 모델 등급을 안 맞춘 것. 위로 안 맞추면 돈이 새고, 아래로 안 맞추면 재작업이 생깁니다.
클로드 모델 비교 — 공식 문서 기준 4종
수치는 전부 앤트로픽 공식 모델 문서에서 가져왔습니다(2026-08-02 확인).
공식 권고도 명확합니다. 같은 문서가 복잡한 에이전틱 코딩과 기업 업무는 오퍼스 5로 시작하고, 최고 성능이 필요할 때 페이블 5를 쓰라고 안내합니다.
표를 읽을 때 짚어둘 게 두 가지 있습니다.
- 소넷 5의 도입가($2/$10)는 2026년 8월 31일까지입니다. 이 글을 9월 이후에 읽으신다면 정가($3/$15) 기준으로 보시면 됩니다.
- 하이쿠만 컨텍스트가 200k이고, 지식 시점이 2025년 2월로 크게 뒤처집니다. “제일 싸다”만 보고 고르면 여기서 걸립니다. 최근 도구나 라이브러리를 물으면 낡은 답이 올 수 있다는 뜻이거든요. 다만 하이쿠는 제가 실사용이 없어서, 이 글에서는 스펙만 전하고 사용 소감은 적지 않습니다.
스펙표에 없는 것 — 모델마다 지침을 다르게 받아야 합니다
그럼 스펙표만 보고 고르면 끝일까요? 아니었습니다. 써 보니 모델마다 일하는 성격이 달랐고, 나중에 찾아보니 그 차이가 공식 문서에 그대로 적혀 있었습니다. 앤트로픽은 모델별 프롬프팅 문서를 아예 따로 둡니다.
제가 겪은 것과 문서를 맞춰보면 이렇습니다.
- 소넷은 지시를 문자 그대로 따릅니다. 한 절만 고치라는 지시를 전체에 확장해 주길 기대하면 안 됩니다. 공식 문서도 “지시를 넓게 적용하려면 범위를 명시하라”고 적습니다. 제가 겪은 그대로였죠.
- 페이블은 지침이 촘촘할수록 오히려 나빠졌습니다. 이것도 문서에 있습니다 — 이전 모델용으로 만든 절차서가 “지나치게 처방적이면 출력 품질을 떨어뜨릴 수 있다”고요. 단계를 일일이 적는 대신 목표와 제약만 주는 쪽이 나았습니다.
- 오퍼스는 시키지 않아도 자기 검증을 합니다. 문서는 “검증하라”는 지시가 과잉 검증을 만드니 빼라고, 빼면 품질 손실 없이 낭비 토큰이 줄어든다고 적습니다. 제 규칙 파일에 있던 재확인 지시가 정확히 그 낭비였습니다.
하나는 반대로 낡아 있었습니다. 예전 오퍼스 기준으로 “서브에이전트를 잘 안 쓰니 언제 쓸지 시켜라”라고 적어뒀는데, 지금 문서는 오퍼스 5가 오히려 더 적극적으로 위임하니 상한을 걸라고 합니다. 같은 문장이 한 세대 만에 정반대 지침이 된 거죠. 모델이 바뀌면 모델 지침도 낡습니다. 설명서가 낡는 건 패키지만의 일이 아니더군요.
그래서 지금 기준 — 모델이 아니라 작업에 맞춥니다
질문이 바뀌었습니다. “어느 모델이 제일 좋나”가 아니라 “이 작업이 뭘 요구하나”입니다.
| 작업의 성격 | 제 선택 |
|---|---|
| 며칠짜리 모호한 문제, 오래 혼자 달려야 함 | 페이블 — 이때만 |
| 여러 파일에 걸친 코딩, 구조 판단 | 오퍼스 (기본값) |
| 빠른 왕복, 명확한 지시, 정해진 범위 | 소넷 |
| 등급을 내리고 싶을 때 | 재작업 비용까지 계산 — 내려서 아낀 것보다 다시 하는 게 비쌀 때가 있습니다 |
그리고 모델을 정하는 것에서 끝내지 않고, 규칙 파일에 모델별 주의사항을 갈라 적어뒀습니다. 소넷에게는 범위를 명시하고, 페이블에게는 단계 나열을 덜어내고, 오퍼스에게는 재확인 지시를 뺐습니다. 위에서 본 공식 문서와 하나씩 맞춰본 뒤에요.
정리하면
| 했던 것 | 결과 |
|---|---|
| 제일 좋은 모델을 전부에 | ✗ 능력 차이는 안 보이고 한도만 소진 |
| 아끼려고 큰 작업을 하위 모델로 | ✗ 디테일 누락 → 재작업, 재작업도 토큰 |
| 작업 요구에 등급을 맞춤 | ○ 성능도 비용도 제값 |
| 모델별로 지침을 갈라 적음 | ○ 같은 모델에서 더 나은 결과 |
스펙표는 시작점입니다. 결국 가르는 기준은 스펙이 아니라 자기 작업 목록에서 나옵니다. 제 경우 그 목록의 대부분이 “여러 파일에 걸친 코딩”이라 기본값이 오퍼스가 됐을 뿐, 작업이 다르면 답도 다를 겁니다.
한도가 왜 그렇게 빨리 닳는지는 클로드 토큰 편에 따로 적었습니다. 모델을 갈라 쓰기 전에 그쪽 구조를 먼저 아는 게 순서상 맞습니다.
