
Claude Code Max 월 $200 × 8개월을 작업별로 분석 — 40%는 로컬 LLM으로 대체 가능했습니다
요약
Claude Code Max 플랜을 8개월간 사용하며 태스크별 비용을 분석한 결과, 약 40%의 작업은 로컬 LLM으로 대체 가능함을 확인했습니다. 코드 생성, 리팩토링 등 7개 카테고리별 실측 데이터를 통해 비용 효율적인 AI 도구 운용 방안을 제시합니다.
핵심 포인트
- Claude Code Max 사용량의 40%는 로컬 LLM(Qwen 35B 등)으로 대체 가능
- 태스크(코드 생성, 리뷰, 디버깅 등)에 따라 비용 효율성이 크게 달라짐
- 8개월간의 실제 사용 로그를 바탕으로 한 카테고리별 비용 분석 데이터 제공
- Anthropic의 향후 과금 체계 변경 전 고정 플랜 기준의 실측 결과
먼저 결론부터 말씀드립니다.
저는 Claude Code Max의 월 $200 플랜을 8개월 동안 유지했습니다. 누적 32만 엔. 사용 로그를 7개 카테고리로 분류하여, 각 카테고리를 「RTX 4070 + Qwen 3.6 35B-A3B」로 대체할 수 있는지 판정한 결과, 시간 환산 시 약 40%는 로컬 LLM (Local LLM)으로 교체 가능했습니다. 나머지 60%는 대체 불가능합니다.
참고로 「40%는 대체 가능했다」는 사실을 깨닫는 데 32만 엔이 들었으므로, 수업료로서는 다소 비싼 편입니다.
「Claude Code Max는 비싸다」와 「싸다」는 모두 틀린 말입니다. 태스크(Task)별로 보지 않으면 의미 없는 금액입니다. 이 기사에서는 8개월 치의 사용 로그를 월별·카테고리별로 집계하여, 어느 부분이 로컬로 대체 가능하고 어느 부분이 대체 불가능한지 실측을 통해 구분합니다.
또한 본 기사는, 2026년 08월부터 예고된 Anthropic의 과금 변경(Max 종량제화) 전, 고정 금액 플랜 하에서의 8개월 실측 데이터입니다. 종량제로 전환된 후에는 동일한 사용 패턴이라도 금액이 달라질 가능성이 높으므로, 그 위치를 먼저 명시해 둡니다.
동일한 장르 내에서 내용 구분이 필요하므로, 위치를 명시합니다.
- 「RTX 4070으로 로컬 LLM의 전기세를 24시간 측정」: 24시간 누적 전기세(엔)
- 「인터넷이나 API에도 연결하지 않고, 로컬 Qwen 35B로 코딩 에이전트를 구동하기」: 완전 로컬 운용 구축기
- 「Claude Code · Cursor · Codex, 결국 어떻게 구분해서 사용하는 것이 정답인가」: 3가지 툴 비교
- 본 기사: Claude Code Max 단독을 8개월간, 7개 카테고리 × 월별로 분석하여 카테고리별 로컬 대체 가능 여부를 판정
저는 Claude Code의 session.jsonl과 claude-code-usage --json 일일 덤프를 매일 밤 백업하고 있습니다. 거기서 8개월 분량을 카테고리별로 집계했습니다. 카테고리는 다음 7가지입니다.
- 코드 생성 (Code Generation): 신규 파일/신규 함수 구현
- 리팩토링 (Refactor): 기존 코드의 구조 변경 (동작은 바꾸지 않음)
- 리뷰 (Review): 차이점(Diff) 독해, 버그 지적, 네이밍 리뷰
- 회의록 (Minutes): 회의 녹취록으로부터의 요약·액션 아이템 추출
- 번역 (Translation): JA↔EN/PT/ES (기사·README의 1차 번역)
- 검색 (Search): 리포지토리 내·웹 검색 및 요약
- 디버깅 (Debug): 에러 로그 분석, 근본 원인 가설 수립
월별로 세션 시간(Claude Code가 작동한 실제 시간, 대기 시간 제외)으로 나열한 것이 다음과 같습니다. 단위는 분이며, n=1(저 1인의 실운용 데이터), 24시간 × 5일/주 가동한 달이 포함되어 있습니다.
| 월 | 코드 생성 | 리팩토링 | 리뷰 | 회의록 | 번역 | 검색 | 디버깅 | 합계(h) |
|---|---|---|---|---|---|---|---|---|
| 2025-12 | 1,850 | 720 | 610 | 280 | 340 | 720 | 480 | 83.3 |
| ... | 합계 | 16,800 | 6,470 | 5,510 | 2,520 | 3,050 | 6,430 | 4,280 |
| 비율 | 37.2% | 14.3% | 12.2% | 5.6% | 6.8% | 14.2% | 9.5% | 100% |
월 $200 고정이므로, $/카테고리 환산은 「$200 × 각 카테고리의 시간 비율」로 근사할 수 있습니다.
코드 생성에 월 $74.4, 리팩토링에 월 $28.6, 리뷰에 월 $24.4, 검색에 월 $28.4, 디버깅에 월 $19.0, 번역에 월 $13.6, 회의록에 월 $11.2. 이것이 지출 내역입니다.
대체 LLM은 RTX 4070(12GB VRAM) + Qwen 3.6 35B-A3B(MoE, GGUF Q4_K_M, cpu-moe 활성화)를 사용했습니다. Beam Search 추론이 아닌 Greedy Search를 사용했으며, 컨텍스트(Context) 길이는 32k(실용 범위)로 운용했습니다. 동일한 프롬프트를 로컬과 Claude Code Max 양쪽에서 실행하여, 다음 기준으로 「대체 가능」을 판정했습니다.
- 출력의 타당성: 제가 최종 채택한 코드에 대해, 로컬 출력의 수정 비용이 Claude Code의 2배 이내
- 대기 시간: 동일한 길이의 출력에서 3배 이내 (Qwen 35B로 대략 40-60 tok/s decode)
- 문맥 (Context): 32k token으로 충분한 태스크
판정 결과입니다.
새로운 파일의 템플릿 작성, 기존 패턴의 복제, 간단한 유틸리티 함수는 로컬(Local)로도 충분했습니다. 제 체감으로는, 단일 파일 완결·200행 이하·기존 패턴 답습 코드의 95%는 대체 가능합니다.
대체할 수 없었던 것은 다음과 같습니다.
- 여러 파일에 걸친 리팩터링 (Refactoring) + 테스트 추가를 한 번에 수행하는 케이스
- 도구(MCP, Playwright, Bash)를 넘나드는 구현 (로컬은 Agent SDK 미지원으로 연동 불가)
- 라이브러리의 최신 사양에 의존하는 구현 (Qwen 3.6의 지식 컷오프는 2026-03. 그 이후의 API는 알지 못함)
대체 가능률은 시간 기준으로 **약 60%**입니다. $/월 환산 시 $44.6는 대체 가능, $29.8는 Claude Code 필수입니다.
「함수 추출·이름 변경·타입 추가」 수준의 리팩터링은 로컬에서 98% 수행할 수 있습니다. 이유는 리팩터링은 새로운 발상이 필요 없기 때문입니다. 기존 코드를 패턴에 따라 정렬하는 것뿐이므로, Qwen 35B로도 거의 차이가 나지 않았습니다.
대체 가능률은 **약 90%**입니다. $/월 환산 시 $25.7는 대체 가능합니다.
수백 행 차이의 의도 추출·네이밍 피드백은 대체 가능합니다. 다만, 아키텍처 판단이 포함된 리뷰(「이 추상화는 너무 빠르다」, 「이 경계는 여기가 아니다」)는 Opus급 추론이 필요하며, 로컬에서는 논점에서 벗어납니다.
대체 가능률은 **약 55%**입니다.
회의 녹취록으로부터 요약 및 액션 아이템 추출은 Qwen 35B로 완벽하게 대체 가능합니다. 저는 7개월 차부터 회의록 용도를 완전히 로컬로 이전했습니다. Claude Code로 수행할 합리적인 이유가 없습니다.
대체 가능률은 **약 100%**입니다. $/월 환산 시 $11.2는 대체 가능합니다.
JA↔EN 1차 번역도 로컬로 충분했습니다. 전문 용어의 통일·톤 조절은 최종적으로 인간의 수정이 필요한 점은 양쪽 모두 동일하며, 품질 차이는 발생하지 않습니다.
대체 가능률은 **약 100%**입니다. $/월 환산 시 $13.6는 대체 가능합니다.
이것이 로컬 대체의 가장 큰 벽입니다. Claude Code의 WebSearch/WebFetch/context-forge 검색은 실시간성 + 거대한 문맥에서의 요약 능력이 필요하며, 로컬 32k context로는 물리적으로 부족합니다.
대체 가능률은 **약 10%**입니다. $/월 환산 시 $25.5는 Claude Code 필수입니다.
kubectl logs나 journalctl을 수동으로 붙여넣어 가설을 도출하게 하는 용도는 로컬로 가능합니다. 다만, **Bash나 grep을 능동적으로 실행하며 원인을 추적하는 「에이전트적 디버깅」**은 Agent SDK가 필요하여 로컬로는 불가능합니다.
대체 가능률은 **약 40%**입니다.
위의 내용을 합산합니다.
| 카테고리 | 비율 | 대체 가능률 | 대체 가능 시간 | 대체 불가능 시간 |
|---|---|---|---|---|
| 코드 생성 | 37.2% | 60% | 22.3% | 14.9% |
| ... | 합계 | 100% | — | 59.5% / 40.3% |
시간 기준으로 약 4할은 로컬 LLM으로 이전 가능, 6할은 Claude Code Max 필수입니다. 금액으로 환산하면, $200/월 중 $80분은 로컬 대체 후보, $120분은 대체 불가능합니다.
저는 현재 회의록·번역·간이 리팩터링을 로컬로 완전히 이전하고, Claude Code 플랜을 $200/월 유지하면서 「사용처를 좁히는」 운용을 하고 있습니다. 낭비를 줄이는 것이 아니라, 입구를 나누는 발상입니다.
대체 불가능한 6할의 내역을 한 문장으로 요약하면:
Opus급 추론(아키텍처 판단), 거대 컨텍스트(수십 개의 파일 동시 독해), 도구 협업(MCP/Bash/Playwright를 하나의 태스크로 묶음).
이 세 가지는 로컬 LLM이 하드웨어 한계로 막히게 됩니다. VRAM 12GB의 제약으로 context 32k가 실질적인 한계이며, Agent SDK도 없고, tool use 학습도 부족합니다. 이 3개 영역에 월 $120를 지불할지는, 개인 사업자로서 「기계에게 시키지 않으면 하루가 끝나지 않는 태스크가 있는가」에 따라 결정됩니다. 저는 있다고 판단했습니다.
구체적인 예로 적겠습니다. 제가 지난주에 수행한 작업 중 로컬에서는 불가능했던 것은 다음과 같습니다.
- Next.js 15 App Router에서 링크 구조를 재설계하고, 기존 32개 파일의 import 경로를 일괄 수정하면서 테스트를 통과시키기 (수십만 토큰의 context + Bash + npm test의 반복)
- MCP 서버의 인증 관련 취약점 체크 (WebSearch로 CVE 참조 + git blame으로 regression을 추적하는 복합 작업)
- 상용 RAG 파이프라인 디버깅 (Playwright로 E2E 재현 + 로그 해독 + 수정 + 다시 Playwright로 확인까지 일련의 대화로 진행)
이 세 가지는 모두 단일 프롬프트 응답만으로는 끝나지 않습니다. **도구를 호출하고 그 결과를 받아 다음을 판단하는 반복 (Iteration)**이 필요한데, 이 부분이 로컬 LLM에는 구조적으로 부족합니다. Qwen 35B 자체는 똑똑하지만, Agent 측의 구현이 따라오지 못하고 있다는 인상입니다.
"대체 가능한 태스크를 로컬로 옮기는" 작업을 실무에서 어떻게 운영하고 있는지도 적어두겠습니다.
저는 Claude Code를 실행하기 전에, 그날의 태스크를 머릿속으로 3가지로 분류합니다.
회의록·번역: 처음부터 Ollama + Qwen 35B로 별도의 터미널을 엽니다. Claude Code는 열지 않습니다 -
리팩토링·단일 파일 생성: 먼저 로컬로 던집니다. 90초를 기다렸는데 출력이 미흡하다면 Claude Code로 전환합니다 -
검색·다중 파일·디버깅: 처음부터 Claude Code를 사용합니다
이 분기만으로도 Claude Code의 세션 시간이 체감상 3할 정도 줄었습니다. 종량제로 전환된 후에는, 이 3할 분량이 직접적인 비용 절감으로 이어질 전망입니다.
Ollama 측의 셋업은 ollama pull qwen2.5:32b-instruct-q4_K_M 한 번이면 끝납니다. (Qwen 3.6이 나오기 전에는 2.5를 사용했습니다.) Qwen 3.6 35B-A3B도 이번 달부터 Ollama 공식 레지스트리에서 배포가 시작되어, ollama pull qwen3.6:35b-a3b로 설치할 수 있습니다. RTX 4070 12GB + cpu-moe 환경에서 40-60 tok/s decode 성능이 나옵니다 (제 실측치이며, 첫 번째 prompt-eval은 200 tok/s 정도입니다).
회의록 용도는 더욱 간단합니다. 저는 Shortcut을 통해 ⌘+⌥+M에 "녹음 파일을 Qwen 35B에 던져 요약하기"를 할당해 두었습니다. 회의 종료 → Shortcut 실행 → 3분 대기 → 회의록이 클립보드에 복사되는 흐름입니다. Claude Code를 여는 것보다 훨씬 빠릅니다. 기다리는 3분 동안 커피를 내리기 때문에, 절약한 Claude Code 비용의 일부는 자연스럽게 원두 값으로 전환됩니다.
수치는 저 개인의 8개월, 1개 환경에 대한 실측치입니다. 다음과 같은 한계가 있습니다.
세션 시간은 대기 시간(wait)을 포함하지 않음: 손을 멈추고 있는 시간은 제외했습니다. 실제로 책상 앞에 앉아 있었던 시간은 더 깁니다 -
대체 가능 여부 판단은 저의 주관: "수정 비용이 2배 이내"라는 것은 저만의 합의 기준이며, 다른 사람에게는 더 엄격하거나 느슨할 수 있습니다 -
Qwen 3.6 35B-A3B의 컷오프 날짜는 2026-03: 그 이후의 API·라이브러리 변경 사항은 알지 못하므로, 해당 영역은 판단이 관대하게 설정되었을 가능성이 있습니다 -
저는 특히 "테스트 자동화", "회의록", "번역"의 비중이 높음: 프론트엔드 전문가는 카테고리 비중이 다를 것이며, 대체율의 절대값도 차이가 날 것입니다
수치는 어디까지나 구조를 참고하는 용도로 사용해 주세요. 카테고리별로 분해하는 발상 자체는 누구에게나 이식 가능합니다.
2026-08부터 Claude Code Max가 종량제에 가까운 체계로 변경된다는 예고가 있습니다 (공식 발표 대기 중). 종량제가 되면, 위 카테고리 중 "번역", "회의록"처럼 대량의 토큰을 소모하기 쉬운 태스크가 지출을 끌어올릴 가능성이 높습니다.
고정 금액 플랜 하에서 이 두 카테고리를 무제한으로 사용하던 운영 방식은, 종량제 전환 후 비용 구조가 바뀌기 때문에 지금부터 로컬 이전을 준비해 두는 것이 합리적입니다. 저는 6월 시점에 그 판단을 내렸고, 월 11시간 분량의 부하를 로컬로 돌렸습니다.
- 8개월 × 7개 카테고리로 보면,
시간 환산 4할은 로컬 LLM으로 대체 가능 - 대체 가능한 내역: 리팩토링(90%), 회의록(100%), 번역(100%), 코드 생성(60%), 리뷰(55%), 디버깅(40%) - 대체 불가능한 것은
**검색(10% 대체)**과, **Opus급 추론·거대 컨텍스트·도구 협업(Tool Use)**의 3개 영역 - "Claude Code Max가 비싸다/싸다"는 논의는 무의미하며,
태스크별로 나누어 보아야 비로소 의미가 생기는 금액입니다.
Claude Code의 일일 운영 흐름(Daily Workflow)과 태스크 분해(Task Decomposition)의 노하우는 이 책에 정리되어 있습니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Qiita AI의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기