워드프레스 사이드바 간격 하나 고치려고 Claude Code를 켰는데, 습관처럼 Opus로 맞춰두고 30분 만에 사용량 경고를 본 적 있다면 이 글이 맞습니다. 결론부터 말하면 기본값은 Sonnet, 되돌리기 비싼 판단만 Opus, 반복 잡무는 Haiku로 나누는 게 비전공자에게 가장 안전한 조합이에요. Opus가 항상 정답이 아니라는 게 핵심이고요. 아래에서는 스펙표를 베끼는 대신, 워드프레스 수정·오류 해결·글 초안 같은 실제 작업 단위로 어떤 모델이 값어치를 하는지, 토큰이 어디서 새는지, Claude Code에서 모델을 어떻게 확인하고 바꾸는지까지 순서대로 정리했습니다.
- 정말 Opus만 쓰면 될까? 결론부터
- 1. 한눈에 보는 Claude 모델 비교표
- 2. 모델 이름부터 헷갈린다 — 네이밍 규칙과 계층 구조
- 3. 실제 작업별로 무엇을 쓸까 — 6가지 상황 처방
- 4. 토큰이 녹는 이유 — 비용이 새는 4가지 패턴
- 5. Claude Code에서 모델 확인·변경하는 방법
- 6. 벤치마크와 체감이 갈리는 지점
- 7. 모델 선택 3단계 체크리스트
- 자주 묻는 질문
- 참고자료
정말 Opus만 쓰면 될까? 결론부터
📌 핵심 요약
Claude 모델은 성능 순위가 아니라 작업 난이도로 나눠 쓰는 게 맞아요. 평소 작업은 Sonnet, 구조를 잘못 잡으면 되돌리기 비싼 판단만 Opus, 정해진 규칙을 반복하는 잡무는 Haiku가 기본 조합입니다.
모델 비교 글을 찾는 사람들의 진짜 질문은 “어느 게 제일 똑똑하냐”가 아니에요. “내가 지금 하려는 이 작업에 뭘 켜야 하냐”죠. 그래서 순위표를 외우는 건 도움이 안 됩니다. 순위는 이미 이름에 들어 있으니까요.
더 쓸모 있는 기준은 되돌리는 비용이에요. 잘못 나와도 Ctrl+Z 한 번이면 끝나는 작업인지, 아니면 폴더 구조나 데이터베이스 설계처럼 나중에 뒤집으려면 며칠이 날아가는 작업인지. 전자는 아래 등급으로 충분하고, 후자만 위 등급이 값어치를 합니다.
비전공자가 특히 손해를 보는 지점이 여기예요. 코드를 못 읽으니 결과가 맞는지 판단이 안 되고, 그 불안을 “제일 좋은 모델로 돌리면 안심”으로 메꾸게 되거든요. 그런데 CSS 여백 20px을 32px로 바꾸는 작업은 어떤 모델이든 틀리지 않습니다. 틀려도 새로고침 한 번으로 확인되고요. 그 작업에 최상위 모델을 쓰면 정확도는 그대로인데 한도만 빨리 소진돼요.
반대로 정말 상위 모델이 필요한 순간에 한도가 남아 있지 않은 게 더 큰 문제예요. 플러그인 충돌로 사이트 전체가 백지가 됐을 때, 그때 쓸 여유가 있어야 하니까요. 모델 선택은 결국 한도 배분 문제라고 보는 편이 실전에 가깝습니다.
1. 한눈에 보는 Claude 모델 비교표
Claude 모델군은 크게 세 계층으로 나뉩니다. 위에서부터 Opus, Sonnet, Haiku예요. 아래 표는 각 계층의 역할과 어울리는 작업을 정리한 것이고, 구체적인 버전명·컨텍스트 윈도우·100만 토큰당 단가는 개정이 잦으니 반드시 공식 문서에서 현재 값을 확인하세요.
| 계층 | 성격 | 잘 맞는 작업 | 주의점 |
|---|---|---|---|
| Opus | 가장 깊은 추론, 여러 단계를 스스로 쪼개서 진행 | 원인 불명 오류 추적, 사이트 전체 구조 설계, 여러 파일이 얽힌 리팩터링 | 단가와 한도 소모가 가장 큼. 간단한 작업엔 과잉 |
| Sonnet | 성능과 비용의 균형점, 일상 작업의 기본값 | 테마 파일 수정, 플러그인 설정, 블로그 글 초안, 일반 코딩 | 맥락이 아주 길어지면 초반 지시를 놓칠 수 있음 |
| Haiku | 가장 빠르고 저렴, 정형화된 일 처리 | 대량 요약·분류, 커밋 메시지, 오타 점검, 반복 변환 | 애매한 지시나 판단이 필요한 일에는 약함 |
표에서 가장 중요한 칸은 성능이 아니라 주의점입니다. Opus의 약점은 성능이 아니라 소모량이고, Haiku의 약점은 속도가 아니라 애매한 지시 처리예요. 그래서 실전 선택은 “내 지시가 얼마나 명확한가”로도 갈립니다.
“버튼 색을 #2f6b60으로 바꿔줘”는 지시가 완결돼 있으니 Haiku급으로도 충분해요. “디자인이 좀 촌스러운데 세련되게 다듬어줘”는 판단이 잔뜩 필요하니 Sonnet 이상이 맞고요. 같은 CSS 작업인데 지시 성격에 따라 답이 달라지는 거죠.
⚠️ 주의사항
모델 이름 뒤에 붙는 버전 숫자와 API 단가는 몇 달 단위로 바뀝니다. 블로그에서 본 숫자를 그대로 계산에 넣지 말고, 결제나 도입 판단 직전에는 Anthropic 공식 모델 문서와 요금 페이지에서 그날 기준 값을 다시 확인하는 습관이 안전해요.
2. 모델 이름부터 헷갈린다 — 네이밍 규칙과 계층 구조
모델 비교가 어려운 첫 번째 이유는 이름이에요. 이름 구조만 이해하면 새 모델이 나와도 혼란이 없습니다. 규칙은 단순해요.
계층 이름 = 크기와 추론 깊이
Opus(대작), Sonnet(정형시), Haiku(단시). 문학 형식 이름을 길이 순서대로 붙인 거예요. 이름이 길이를 뜻하니 순서가 헷갈릴 일이 없습니다.
버전 숫자 = 세대
같은 계층이라도 세대가 올라가면 성능이 바뀝니다. 그래서 “신형 중간 등급이 구형 최상위보다 나은가”라는 질문이 늘 생기는데, 세대 차가 벌어지면 실제로 그런 역전이 일어나기도 해요. 계층만 보고 판단하면 안 되는 이유입니다.
모델 ID와 별칭은 다르다
API로 부를 때 쓰는 정식 ID는 날짜가 붙은 긴 문자열이고, 최신 버전을 자동으로 따라가는 별칭도 따로 있어요. 개인 실습이면 별칭이 편하지만, 결과가 갑자기 달라지면 곤란한 자동화라면 날짜가 고정된 ID를 쓰는 편이 안전합니다.
추론 강도는 별도 변수
모델을 고른 뒤에도 “얼마나 오래 생각하게 할지”를 조절하는 설정이 따로 있습니다. 같은 모델이라도 생각을 길게 시키면 답이 나아지지만 토큰과 시간이 늘어요. 즉 선택 변수는 모델 하나가 아니라 둘입니다.
4번을 놓치는 사람이 많아요. 답이 부실하다고 바로 상위 모델로 올리기 전에, 같은 모델에서 생각을 더 오래 하게 하는 옵션부터 시도해보는 게 순서예요. 그것만으로 해결되는 경우가 꽤 있습니다.
계층 사이에 특화 모델이 추가되기도 하는데, 이 경우도 판단 방식은 같아요. “전 계층보다 위냐 아래냐”를 따지지 말고 “어떤 작업에 특화됐다고 설명돼 있나”를 읽으면 됩니다. 특화 모델은 보통 범용 성능보다 특정 용도의 결과물 품질을 노린 포지션이라, 그 용도가 아니면 굳이 바꿀 이유가 없어요.
3. 실제 작업별로 무엇을 쓸까 — 6가지 상황 처방
여기가 이 글의 본론이에요. 비전공자가 워드프레스와 바이브코딩을 하면서 실제로 마주치는 작업 6개를, 어떤 모델로 돌리는 게 합리적인지 순서대로 정리했습니다.
1) 테마 CSS 한두 줄 수정 → Sonnet, 경우에 따라 Haiku
글자 크기, 여백, 색상 변경 같은 작업이에요. 결과가 바로 눈에 보이고 틀려도 되돌리기가 쉬우니 상위 모델이 필요 없습니다. 다만 “자식 테마에 넣어야 하는데 부모 테마 파일을 건드리는” 실수가 자주 나오는 구간이라, 프롬프트에 “반드시 자식 테마 style.css에만 추가하고 부모 테마는 수정하지 마”를 넣어두면 모델 등급과 무관하게 사고를 줄일 수 있어요.
2) 사이트가 백지로 뜨는 치명적 오류 → Opus
플러그인 충돌이나 PHP 문법 오류로 화면 전체가 하얗게 되는 상황이요. 원인이 어디인지 모르는 상태에서 여러 가설을 세워 하나씩 지워가야 하니, 추론을 오래 끌고 가는 능력이 실제 차이를 만듭니다. 이때 중간 등급으로 버티면 “이걸 해보세요, 안 되면 저걸 해보세요”가 반복되면서 오히려 토큰을 더 쓰게 되는 경우가 흔해요. 처음부터 상위 모델로 에러 로그 전문을 붙여 던지는 게 총비용에서 이득인 전형적인 사례입니다.
3) 블로그 글 초안과 구조 짜기 → Sonnet
한국어 글의 자연스러움은 최상위 모델이라고 무조건 더 좋진 않아요. 상위 모델은 문장을 정교하게 다듬는 대신 말이 길어지고 격식이 올라가는 경향이 있어서, 편안한 블로그 톤에는 중간 등급이 더 맞는다는 평이 많습니다. 대신 글감 기획이나 시리즈 전체 목차처럼 판단이 많이 필요한 단계는 상위 모델에서 한 번 뽑아두고, 개별 글 집필은 중간 등급으로 내려오는 분업이 효율적이에요.
4) 글 50개 요약·태그 분류 → Haiku
형식이 고정된 반복 작업이요. 출력 형식을 예시로 못 박아주면 하위 모델로도 결과가 거의 흔들리지 않습니다. 이런 작업을 상위 모델로 돌리는 건 가장 아까운 낭비예요. 비용이 수십 배 차이 나는데 결과물 차이는 거의 없으니까요.
5) 폴더 구조·데이터 설계 결정 → Opus
글 100개를 쓴 뒤에 카테고리 구조를 뒤집으면 URL이 전부 바뀌고 검색 유입이 날아갑니다. 되돌리는 비용이 가장 큰 종류의 결정이죠. 코드 한 줄도 안 쓰는 대화지만, 여기에 상위 모델을 쓰는 건 충분히 값어치가 있어요. 실제 파일을 만들기 전에 “이 구조의 단점과 나중에 바꾸기 어려운 부분을 먼저 알려줘”라고 물어보는 방식이 잘 통합니다.
6) 커밋 메시지·파일명 정리 → Haiku
깃 커밋 메시지 작성처럼 짧고 규칙적인 일은 속도가 곧 편의예요. 응답을 기다리는 시간이 짧으면 작업 리듬이 끊기지 않습니다.
💡 꼭 알아두세요
한 세션 안에서 계획은 상위 모델, 실행은 중간 모델로 나누는 방식이 비용 효율이 좋습니다. “먼저 수정 계획만 세워줘, 코드는 아직 쓰지 마”로 설계를 받고, 모델을 낮춘 뒤 그 계획대로 실행시키는 흐름이에요.
4. 토큰이 녹는 이유 — 비용이 새는 4가지 패턴
모델을 잘 골라도 사용량이 빠르게 줄어든다면 원인은 모델이 아니라 습관일 가능성이 큽니다. 초보자가 반복하는 패턴 네 가지예요.
- 대화를 끝내지 않고 계속 이어붙임 — 대화가 길어지면 이전 내용을 매 요청마다 다시 읽습니다. 작업이 끝났는데 같은 창에서 새 주제를 시작하면, 관계없는 옛 대화까지 값을 치르는 셈이에요. 주제가 바뀌면 세션을 새로 시작하는 게 가장 효과 큰 절약법입니다.
- 큰 파일을 통째로 읽히기 — 수천 줄짜리 테마 파일 전체를 읽게 하면 그 자체로 입력 토큰이 폭발해요. “header.php의 상단 50줄만 보고”처럼 범위를 좁히거나, 해당 부분만 잘라 붙이는 편이 낫습니다.
- 성능 과잉 — 앞에서 다룬 내용이죠. 오타 수정에 최상위 모델을 쓰는 것. 기본값을 중간 등급으로 두고 필요할 때만 올리는 방향으로 습관을 뒤집어야 해요.
- 재시도 루프 — 원인을 모른 채 “안 되네요”만 반복하면 매 시도마다 전체 맥락이 다시 소모됩니다. 세 번 시도해서 안 되면 모델을 올리거나, 에러 메시지 원문과 상황 설명을 다시 정리해 새 세션에서 던지는 게 빠릅니다.
특히 2번과 4번은 체감 차이가 큽니다. 같은 오류를 잡는 데 어떤 사람은 열 번 주고받고 어떤 사람은 두 번에 끝내는 차이가, 모델 등급보다 “무엇을 얼마나 정확히 던졌는지”에서 나올 때가 많아요. 에러 로그 전문, 방금 무엇을 바꿨는지, 어떤 화면에서 발생하는지 이 세 가지를 한 번에 주는 습관이 결국 비용을 줄입니다.
5. Claude Code에서 모델 확인·변경하는 방법
Claude Code를 쓰는 사람에게는 모델 비교보다 이 부분이 더 급할 수 있어요. 지금 무슨 모델로 돌고 있는지부터 모르는 경우가 많으니까요.
현재 모델 확인
터미널 입력창에 슬래시(/)를 치면 사용 가능한 명령 목록이 나옵니다. 그중 model 관련 명령을 실행하면 현재 어떤 모델로 작동 중인지, 선택 가능한 목록이 무엇인지 함께 표시돼요. 명령 이름은 버전에 따라 달라질 수 있으니 목록에서 직접 확인하는 방식이 가장 확실합니다.
세션 중간에 전환
같은 명령으로 작업 도중에도 모델을 바꿀 수 있어요. 이때 지금까지의 대화 맥락은 유지됩니다. 그래서 “상위 모델로 원인을 파악하고, 낮춰서 수정을 실행”하는 분업이 실제로 가능해요. 다만 대화가 이미 아주 길어진 상태라면 낮춘 모델이 초반 지시를 흘릴 수 있으니, 전환 직후 핵심 규칙을 한 번 다시 적어주는 게 안전합니다.
자동 배분 모드 활용
모델을 직접 고르는 대신, 계획 단계에서는 상위 모델을 쓰고 실제 실행은 중간 모델로 내려오는 혼합 모드가 제공되는 경우가 있습니다. 매번 수동으로 바꾸기 번거로운 초보자에게 특히 편한 선택이에요. 사용 가능 여부와 이름은 플랜과 버전에 따라 다르니 모델 목록에서 확인하세요.
VSCode·에디터 환경
에디터 확장으로 쓰는 경우에도 내부는 같은 엔진이라, 통합 터미널에서 같은 슬래시 명령이 동작합니다. 확장 패널에 모델 선택 UI가 따로 있다면 그쪽이 더 편하고요. 프로젝트마다 기본 모델을 고정해두고 싶다면 설정 파일에 기본값을 적어두는 방법도 있는데, 설정 키 이름은 공식 문서 기준으로 맞추는 게 좋습니다.
참고로 계정이나 플랜에 따라 고를 수 있는 모델 범위가 달라집니다. 목록에 원하는 모델이 안 보이면 설정이 아니라 플랜 문제일 수 있어요. 여러 계정을 쓰는 경우 로그아웃 관련 명령으로 세션을 정리한 뒤 다시 로그인하면 사용 가능한 모델 목록이 갱신됩니다.
⚠️ 주의사항
한도가 남아 있다고 안심하고 워드프레스 실제 서버 파일을 바로 고치게 하는 건 위험해요. 모델 등급과 무관하게, 수정 전 파일 백업과 데이터베이스 백업이 먼저입니다. 로컬 환경이나 스테이징에서 먼저 돌려보는 습관이 사고를 막아줘요.
6. 벤치마크와 체감이 갈리는 지점
공식 문서나 벤치마크 점수만 보면 상위 모델이 모든 항목에서 앞섭니다. 그런데 실제 사용자 후기에서 반복적으로 언급되는 어긋남이 몇 가지 있어요. 비전공자에게 특히 영향이 큰 네 가지를 꼽아보면 이렇습니다.
한국어 문장의 결은 점수와 다르게 느껴지는 대표 항목이에요. 상위 모델은 문장 구조가 단단하지만 설명이 길어지고 딱딱해지는 쪽으로 기울고, 중간 등급은 짧고 말맛 있는 문장을 잘 뽑는다는 평이 많습니다. 블로그 글이라면 후자가 손을 덜 타요. 다만 전문 용어가 많은 기술 설명이나 논리 전개가 중요한 긴 글은 상위 모델 쪽이 안정적입니다.
지시 준수도 갈립니다. “이 파일만 수정하고 다른 건 건드리지 마”라는 제약을 얼마나 지키는지요. 상위 모델은 스스로 판단해 주변 코드까지 개선하려는 경향이 있어서, 통제하고 싶은 작업에서는 오히려 성가실 수 있어요. 코드를 못 읽는 사람 입장에서는 “내가 시키지 않은 변경”이 가장 무서운 부분이니, 이 대목에서 등급을 올리는 게 답이 아닐 때가 있습니다.
장문 유지력은 상위 모델의 확실한 우위예요. 30번 넘게 주고받은 대화에서 초반에 정한 규칙을 기억하는 정도가 눈에 띄게 다릅니다. 긴 리팩터링 작업을 한 세션으로 끌고 갈 거라면 여기서 값어치가 나옵니다.
디버깅 집요함도 마찬가지입니다. 첫 시도가 실패했을 때 다른 각도로 접근을 바꾸는지, 같은 방법을 반복하는지에서 차이가 큽니다. 원인 불명 오류에 상위 모델을 권하는 실질적 이유가 이것이에요.
정리하면 상위 모델이 확실히 이기는 건 길고 어려운 추론이고, 항상 이기지는 않는 건 짧은 글의 문체와 제약 준수입니다. 커뮤니티에서 “모델 성격이 바뀐 것 같다”는 말이 도는 것도 대개 이런 체감 영역에서 나오는 이야기라, 점수표보다 자기 작업으로 직접 비교해보는 게 가장 정확해요. 같은 프롬프트를 두 모델에 던져 결과를 나란히 두고 보는 것만으로 판단이 섭니다.
7. 모델 선택 3단계 체크리스트
매번 고민하지 않으려면 판단 기준을 세 개로 줄이는 게 좋아요. 아래 순서대로 자문하면 대부분 3초 안에 결정됩니다.
- 틀렸을 때 되돌리는 비용이 큰가? — 파일 하나 되돌리면 끝이면 중간 등급, 구조·데이터·URL처럼 나중에 뒤집기 어려우면 상위 등급.
- 내 지시가 완결돼 있는가? — 형식과 결과를 문장으로 다 적을 수 있으면 하위 등급으로 충분. 판단을 맡겨야 하면 한 단계 올려요.
- 같은 일을 몇 번 반복하는가? — 한 번이면 등급을 올려도 부담이 적지만, 50번 반복할 작업이면 단가가 그대로 50배로 곱해집니다. 반복량이 많을수록 아래로 내려가세요.
📋 점검 체크리스트
✓ 주제가 바뀔 때 세션을 새로 시작한다
✓ 파일 전체보다 필요한 범위만 읽히고 있다
✓ 원인 불명 오류는 로그 전문과 함께 상위 모델로 올린다
✓ 반복 잡무는 하위 모델에 출력 형식 예시와 함께 맡긴다
✓ 실제 서버 파일 수정 전에 백업을 받았다
✓ 버전·단가는 공식 문서에서 현재 값을 확인했다
이 기준을 한 주만 의식적으로 적용해보면, 예전에는 하루도 못 버티던 한도로 훨씬 오래 작업하게 되는 변화를 확인할 수 있어요. 모델을 바꾸는 것보다 작업을 쪼개는 습관이 만드는 차이가 더 크기 때문입니다.
자주 묻는 질문
Claude Code에서 모델별 차이점은 무엇인가요?
추론 깊이와 토큰 소모량의 차이가 가장 큽니다. 상위 모델은 여러 파일이 얽힌 문제를 스스로 쪼개서 끝까지 추적하는 힘이 있고, 중간 모델은 일상적인 파일 수정과 기능 추가를 빠르게 처리해요. 하위 모델은 형식이 정해진 반복 작업에 최적입니다. 코딩 작업의 난이도보다 불확실성이 클 때 등급을 올리는 것이 기준이에요.
Claude 모델 중 어떤 모델을 추천하나요?
단일 정답은 없고 네 가지 시나리오로 나뉩니다. 일상 코딩·글쓰기는 Sonnet, 원인 불명 오류와 구조 설계는 Opus, 대량 요약·분류는 Haiku, 그리고 매번 고르기 번거롭다면 계획과 실행에 서로 다른 모델을 자동 배분하는 혼합 모드가 편합니다.
Haiku와 Opus는 정확히 무엇이 다른가요?
같은 계열의 양극단입니다. Haiku는 속도와 저비용, Opus는 추론 깊이가 강점이고요. 명확한 지시를 대량으로 처리할 때는 둘의 결과 차이가 거의 없지만, 문제 정의 자체가 모호할 때는 격차가 크게 벌어집니다. 즉 차이는 난이도가 아니라 모호함에서 드러나요.
글쓰기와 번역에는 어떤 모델이 유리한가요?
편안한 톤의 블로그 글은 중간 등급이 손을 덜 타는 경우가 많고, 논리 전개가 긴 기술 문서나 전문 용어가 많은 번역은 상위 등급이 안정적입니다. 같은 문단을 두 모델에 동일 프롬프트로 던져 비교해보면 자기 문체에 맞는 쪽이 금방 드러나요.
작업 중간에 모델을 바꿔도 대화 맥락이 유지되나요?
네, 같은 세션 안에서는 지금까지의 대화가 그대로 이어집니다. 다만 상위에서 하위로 내릴 때는 초반에 정한 제약을 놓칠 수 있으니, 전환 직후 지켜야 할 규칙 두세 줄을 다시 적어주는 편이 안전합니다.
요금제와 API 중 무엇이 유리한가요?
사람이 직접 대화하며 작업하는 비중이 높으면 정액 요금제가 예측 가능해서 유리하고, 자동화 스크립트로 대량 호출한다면 사용량 기반 API가 통제하기 쉽습니다. 플랜별 한도와 단가는 개정이 잦으니 결제 전에 공식 요금 페이지에서 현재 조건을 확인하세요.
참고자료
- Anthropic 공식 모델 개요 문서 — 각 모델의 계층, 모델 ID, 컨텍스트 윈도우와 최대 출력 토큰의 현재 값을 확인할 수 있어요.
- Anthropic 요금 안내 페이지 — 구독 플랜과 API 단가를 비교할 때 기준이 되는 공식 페이지입니다.
- Claude Code 공식 문서 — 슬래시 명령, 모델 설정, 에디터 연동 방법이 정리돼 있습니다.
- WordPress 자식 테마 공식 문서 — 테마 수정 작업을 AI에 맡길 때 어디를 고쳐야 안전한지 판단하는 기준이 됩니다.
모델 비교를 찾아 헤매는 이유는 대개 하나예요. “내가 지금 잘못된 모델로 돈과 한도를 태우고 있는 건 아닐까” 하는 불안이죠. 그 불안은 순위표로는 풀리지 않고, 되돌리는 비용·지시의 명확성·반복 횟수 이 세 가지 질문으로 풀립니다. 기본값을 Sonnet으로 두고, 구조를 결정하거나 원인 모를 오류를 잡을 때만 Opus를 꺼내고, 형식이 정해진 잡무는 Haiku에 넘기는 순서를 권합니다. 여기에 주제가 바뀌면 세션을 새로 열고 파일은 필요한 범위만 읽히는 습관까지 붙이면, 모델을 바꿔 아끼는 양보다 더 큰 여유가 생겨요. 버전명과 단가는 계속 바뀌니 큰 결정 전에는 공식 문서로 그날 값을 한 번 확인하는 것만 잊지 마세요.
함께 보면 좋은 글
