모델 선택의 경제학

설치가 끝났다면 이제 진짜 중요한 질문이 남습니다. 무슨 모델로 일할 것인가입니다. 많은 사람이 여기서 첫 번째 실수를 합니다. "제일 비싼 모델이 제일 좋겠지"라고 생각하는 것이죠. 하지만 솔로 빌더의 현실은 벤치마크 표가 아니라, 한정된 시간과 예산과 집중력 위에서 돌아갑니다.

클로드 코드를 잘 쓰는 사람은 항상 가장 강한 모델을 고르는 사람이 아닙니다. 문제의 난이도에 맞는 모델을 고르는 사람입니다. 같은 목표를 더 싸게, 더 빨리, 더 덜 지치면서 달성할 수 있기 때문입니다. Anthropic의 공식 가이드와 가격표를 함께 보면 이 점이 더 분명해집니다. Haiku는 가볍고 빠른 작업, Sonnet은 일상적인 기본 작업, Opus는 깊은 판단이 필요한 일에 더 어울립니다.¹²

이 장에서는 세 가지를 정리하겠습니다. 첫째, Opus·Sonnet·Haiku를 어떤 역할로 나눠 써야 하는지. 둘째, 큰 컨텍스트 창을 언제 써야 하고 언제 안 써야 하는지. 셋째, 비용과 품질의 균형점을 어떻게 실전에서 찾는지입니다. 마지막으로, 감이 아니라 숫자로 사용 습관을 확인하는 방법까지 다루겠습니다.

Opus 4.7 vs Sonnet 4.6 vs Haiku 4.5

세 모델을 어렵게 볼 필요는 없습니다. 솔로 빌더 입장에서는 이렇게 기억하면 됩니다.

• Haiku 4.5는 빠른 실행 담당입니다.

• Sonnet 4.6은 기본 워크호스입니다.

• Opus 4.7은 어려운 판단을 맡기는 전문가입니다.¹²

공식 가격 기준으로 API 단가는 다음과 같습니다. Haiku 4.5는 입력 100만 토큰당 1달러, 출력 5달러입니다. Sonnet 4.6은 입력 3달러, 출력 15달러입니다. Opus 4.7은 입력 5달러, 출력 25달러입니다.² 숫자만 보면 Opus가 "조금 더 비싼" 정도처럼 보일 수 있습니다. 하지만 실제 작업에서는 출력 토큰, 도구 사용, 누적된 대화 문맥까지 함께 들어가므로 체감 차이는 더 커집니다.

간단히 표로 보면 이렇습니다.

이걸 사람에 비유하면 더 쉽습니다. Haiku는 손 빠른 운영 어시스턴트, Sonnet은 믿고 맡기는 실무형 개발자, Opus는 꼭 필요할 때 부르는 기술 고문에 가깝습니다. 혼자 제품을 만드는 사람에게 중요한 건 셋 다 늘 켜 두는 법이 아니라, 언제 누구를 호출할지 아는 것입니다.

예를 들어 봅시다. "에러 로그 200개를 유형별로 묶어줘" 같은 일은 Haiku에게 시키는 게 맞습니다. "Next.js API 라우트 구조를 정리하고 테스트 코드를 추가해줘"는 Sonnet의 영역입니다. 반면 "지금 이 SaaS를 멀티 테넌트로 갈지, 단일 계정 구조로 갈지, 6개월 뒤 운영 복잡도까지 포함해 판단해줘"는 Opus를 꺼낼 이유가 생깁니다.

여기서 중요한 사실이 하나 있습니다. 모델 이름은 성능 순위표라기보다 역할 구분표에 가깝다는 점입니다. 가장 센 망치를 계속 휘두른다고 좋은 목수가 되는 것은 아닌 것처럼, 가장 비싼 모델만 쓴다고 생산성이 올라가는 것도 아닙니다.

그리고 구독 사용자도 이 차이를 체감합니다. API를 쓰면 비용이 청구서로 보이고, Pro나 Max를 쓰면 비용이 한도와 사용 가능량으로 보입니다. 쉬운 일에 가장 무거운 모델을 계속 쓰면 돈만 더 드는 게 아니라, 하루 전체의 작업 여유도 같이 줄어듭니다.¹²

큰 컨텍스트 창의 진짜 활용법

큰 컨텍스트 창은 들으면 가슴이 뜁니다. "이제 내 레포 전체를 한 번에 먹일 수 있겠네?" 맞습니다. 실제로는 넓은 문맥을 다루는 데 도움이 됩니다. 하지만 여기서 많은 사람이 두 번째 실수를 합니다. 넓은 문맥 창을 '항상 크게 열어두는 것'이 좋은 사용법이라고 착각하는 것입니다.

컨텍스트 윈도우는 저장 창고가 아니라 작업대입니다. 많이 올려놓을 수는 있지만, 많이 올려놓는다고 일이 저절로 잘되지는 않습니다. 오히려 관련 없는 파일, 긴 대화 기록, 장황한 지시문이 한꺼번에 섞이면 모델이 읽어야 할 양만 늘고 핵심 신호는 흐려집니다. 긴 문맥에서는 가운데 정보가 상대적으로 덜 주목받는 이른바 "lost in the middle" 현상도 반복해서 지적되어 왔습니다.³

그래서 큰 컨텍스트는 "매번 크게"가 아니라 "정말 크게 읽어야 할 때 한 번에" 쓰는 쪽이 훨씬 낫습니다. 특히 솔로 빌더에게 유용한 장면은 다음과 같습니다.

• 레포 전체 구조를 한 번에 읽고 아키텍처 리뷰를 받을 때

• PRD, DB 스키마, 기존 이슈, 장애 로그를 묶어 큰 판단을 내려야 할 때

• 마이그레이션 전에 영향 범위를 넓게 파악할 때

• 문서 더미를 한 번에 훑고 누락된 요구사항을 찾을 때

반대로, 버튼 하나 색 바꾸기, API 하나 추가하기, 테스트 한두 개 고치기 같은 일에는 큰 창보다 좋은 컨텍스트 선별이 더 중요합니다. 작은 작업에 거대한 문맥을 매번 들이붓는 것은, 컵라면 끓이는데 업소용 가마솥을 꺼내는 것과 비슷합니다. 가능은 하지만 효율적이지 않습니다.

실전 감각으로 정리하면 이렇습니다. 큰 컨텍스트는 탐색과 진단에 강합니다. 반면 구현 단계에서는 필요한 파일만 좁게 유지한 Sonnet 세션이 더 민첩한 경우가 많습니다. 큰 문맥은 시작할 때 한 번, 결정이 막혔을 때 한 번, 릴리스 전 큰 그림 점검에 한 번 쓰는 방식이 보통 더 좋습니다.

여기서 하나 더 기억할 점이 있습니다. 컨텍스트가 커질수록 모델만 힘들어지는 것이 아닙니다. 당신도 같이 힘들어집니다. 어떤 파일이 왜 들어갔는지, 무엇이 최신 정보인지 추적하기가 어려워지기 때문입니다. 결국 컨텍스트 엔지니어링의 핵심은 "얼마나 많이 넣느냐"가 아니라 얼마나 알맞게 고르느냐입니다.³

비용 vs 품질의 균형점 찾기

이 장의 핵심 문장을 먼저 적겠습니다.

좋은 결과는 가장 비싼 모델에서 나오지 않는다. 가장 맞는 모델 조합에서 나온다.

솔로 빌더가 실제로 가져가야 할 기본 전략은 단순합니다. 기본은 Sonnet, 빠른 잡일은 Haiku, 어려운 판단은 Opus입니다.¹² 이 원칙만 지켜도 사용량과 피로도가 크게 달라집니다.

왜 Sonnet이 기본값이어야 할까요? 공식 안내에서도 Sonnet은 일상적인 작업의 균형점으로 소개됩니다.¹ 코딩, 글쓰기, 분석, 다단계 워크플로우를 모두 무난하게 처리하면서도 Opus보다 가볍기 때문입니다. 솔로 빌더가 하루에 가장 많이 하는 일은 혁명적인 연구가 아니라, 기능 추가, 버그 수정, 리팩터링, 문서 작성, 테스트 보강 같은 반복적이지만 중요한 일들입니다. 이런 일은 대개 Sonnet이 가장 경제적입니다.

Haiku는 생각보다 쓸모가 많습니다. 특히 다음처럼 "정답의 정밀함보다 처리량과 속도"가 중요한 곳에서 강합니다.

• 긴 로그를 짧게 요약하기

• 사용자 피드백을 라벨링하기

• 에러 메시지를 유형별로 분류하기

• 코드베이스에서 특정 패턴을 훑어 체크리스트 만들기

• 초안 수준의 스캐폴딩이나 변환 작업 처리하기

반면 Opus는 자주 쓰는 모델이 아니라 비싸게 아껴 쓰는 모델에 가깝습니다. 예를 들어 이런 순간입니다. 같은 버그를 Sonnet으로 두세 번 고쳤는데 자꾸 옆구리에서 다른 문제가 터진다. 인증 구조를 바꿔야 하는데 테이블 설계, 권한 모델, 배포 리스크가 얽혀 있다. 보안 검토에서 미묘한 권한 누수 가능성을 따져야 한다. 이런 때는 Opus가 값어치를 합니다.

실전에서는 "한 단계 낮게 시작하고, 실패하면 올린다"는 습관이 좋습니다. 처음부터 Opus로 돌진하지 말고 Sonnet으로 시작해 보세요. Sonnet이 명확히 버거워하는 징후가 있을 때만 Opus로 올리는 것입니다. 그 징후는 보통 이런 식으로 나타납니다. 모델이 같은 제안을 반복한다, 구조적 트레이드오프를 흐릿하게 말한다, 수정은 하는데 전체 일관성이 자꾸 깨진다, 위험을 충분히 짚지 못하고 눈앞의 코드만 고친다. 그때는 더 강한 모델이 필요한 순간입니다.

이 원칙을 돈으로도 대략 계산해 볼 수 있습니다. 예를 들어 입력 15만 토큰, 출력 1만 토큰 정도의 작업 하나를 처리한다고 해 보죠. 단순 계산만 하면 Haiku가 약 0.20달러, Sonnet이 약 0.60달러, Opus가 약 1.00달러 수준입니다.² 한 번만 보면 차이가 작아 보여도, 이런 작업이 하루에 여러 번 반복되면 얘기가 달라집니다. 게다가 구독 플랜에서는 이 차이가 돈 대신 사용 가능 시간과 한도로 체감됩니다.

그래서 저는 솔로 빌더에게 모델 선택을 이렇게 권합니다.

• 기본 세션은 Sonnet으로 시작한다.

• 반복적이고 가벼운 정리 작업은 Haiku로 내린다.

• 막히는 판단, 중요한 리뷰, 큰 설계 변경에서만 Opus를 올린다.

이 정도만 지켜도 "왜 이렇게 빨리 한도를 쓰지?"라는 느낌이 줄어듭니다. 모델 선택은 단순한 비용 절감이 아니라, 하루의 리듬을 설계하는 일이기도 합니다.

ccusage로 사용량 추적하기

모델 선택을 잘하고 싶다면, 느낌 말고 기록을 봐야 합니다. 대부분의 개발자는 "나는 Sonnet 위주로 쓰는 편"이라고 말하지만, 막상 보면 어려운 문제도 아닌데 더 무거운 모델을 습관적으로 켜고 있는 경우가 있습니다. 반대로 Haiku로 내려도 되는 작업을 전부 Sonnet으로 처리해 세션을 천천히 갉아먹는 경우도 흔합니다.

이때 필요한 것이 사용량 추적입니다. Claude Code 자체에도 사용량을 확인하는 방법이 있고, API 사용자는 비용 중심 지표를 따로 볼 수 있습니다.²⁴ 여기에 ccusage 같은 외부 도구를 붙이면 날짜별, 세션별, 프로젝트별 패턴을 더 입체적으로 볼 수 있습니다.⁴

ccusage를 쓴다고 해서 갑자기 비용이 줄어들지는 않습니다. 하지만 어디서 새는지는 보이기 시작합니다. 예를 들어 이런 질문에 답할 수 있게 됩니다.

• 어느 프로젝트가 유독 토큰을 많이 먹는가?

• 더 무거운 모델을 쓴 날과 안 쓴 날의 생산성 차이가 실제로 있는가?

• 긴 세션에서 어떤 종류의 작업이 사용량을 폭증시키는가?

• 업그레이드가 필요한가, 아니면 작업 습관을 고쳐야 하는가?

솔로 빌더에게 특히 유용한 관찰 포인트는 세 가지입니다.

첫째, 모델별 비중입니다. 한 달 사용량 중 Opus 비중이 생각보다 높다면, 지금의 문제는 플랜 부족이 아니라 모델 선택 습관일 가능성이 큽니다.

둘째, 세션 길이와 전환 빈도입니다. 관련 없는 일을 한 세션에 오래 몰아넣으면 컨텍스트가 비대해지고, 같은 모델이라도 체감 비용이 커집니다. 이때는 더 비싼 플랜보다 /clear, 새 세션, 작업 분리가 먼저일 수 있습니다.

셋째, 반복 문맥의 낭비입니다. 매번 같은 프로젝트 설명, 같은 규칙, 같은 아키텍처 문서를 길게 다시 넣고 있다면, 좋은 CLAUDE.md와 재사용 가능한 구조를 만드는 쪽이 더 큰 절감 포인트가 됩니다. 모델을 내리는 것보다 문맥을 정리하는 쪽이 효과가 더 큰 경우도 많습니다.

사용량 데이터를 볼 때는 숫자를 죄책감으로 해석하지 마세요. 그건 평가표가 아니라 계기판입니다. 중요한 건 "많이 썼다"가 아니라 "맞게 썼는가"입니다. Sonnet으로 될 일을 Opus로 했다면 개선 여지가 있는 것이고, Opus 덕분에 하루짜리 난제를 한 시간 만에 끝냈다면 그건 좋은 지출입니다.

결국 모델 선택의 경제학은 절약의 기술이 아닙니다. 자원을 결과로 바꾸는 기술입니다. 시간, 토큰, 집중력, 월 구독료를 한 덩어리로 보고 가장 높은 ROI를 뽑아내는 방식이죠. 솔로 빌더는 팀처럼 사람을 늘리기 어렵습니다. 대신 모델을 역할별로 나눠 쓰면서, 혼자서도 작은 팀처럼 움직일 수 있습니다.

다음 장에서 다룰 CLAUDE.md는 바로 이 경제학을 더 강하게 만들어주는 도구입니다. 좋은 모델 선택이 좋은 인력을 뽑는 일이라면, 좋은 CLAUDE.md는 그 인력이 헛짓하지 않게 만드는 운영 매뉴얼입니다.

참고

¹Choosing the right Claude model: Haiku, Sonnet, and Opus

²Plans & Pricing | Claude by Anthropic

³Claude Context Window: 200K Tokens, 1M Beta, and What the Research Shows

⁴Claude Code pricing: how much it costs and which plan you should pick