그림 1. NVIDIA 공식 블로그의 KV 캐시 공식 설명

TL;DR

• KV 캐시는 트랜스포머가 매 토큰의 key·value 벡터를 보관하는 메모리다. 컨텍스트 윈도우가 길어질수록 무게가 늘어 GPU 메모리도 빠르게 차고 API 비용도 같이 올라간다.
• Llama 3.1 8B(BF16) 기준 토큰 1개가 128 KB. 32K 컨텍스트 = 4 GB, 128K = 16 GB, 1M = 128 GB. 모델 가중치(16GB)는 별도다.
• Gemini 2.5 Pro는 200K 초과 시 input 2배·output 1.5배(Google AI 공식). Claude는 2024 시점엔 같은 임계점이었으나 2026 현재 Opus 4.8·4.7·4.6·Sonnet 4.6은 1M까지 standard pricing이다 — 뒤에서 시점 차로 따로 적었다.
• PagedAttention(공간)·RadixAttention(상태)·GQA(원천) 셋은 같은 KV 캐시 문제를 다른 축에서 푸는 한 묶음이다.

KV 캐시·Context Window가 뭔가

용어부터 간단히 정리한다. KV 캐시는 트랜스포머가 매 토큰의 key·value 벡터를 메모리에 저장해 다음 토큰을 만들 때 재사용하는 자료구조다. **컨텍스트 윈도우(context window)**는 한 번에 그 KV로 보관할 수 있는 토큰 수의 한도다. Anthropic 공식 문서는 컨텍스트 윈도우를 모델의 “working memory”라고 부른다.

이 글의 자리는 vLLM이 PagedAttention으로 단편화를 푼 이야기와 SGLang이 RadixAttention으로 prefix 재계산을 푼 이야기의 뿌리다. 두 글이 KV 캐시의 증상(단편화·중복 계산)을 푼 약이었다면, 여기서는 그 진앙인 KV 캐시 자체를 본다. Yao Fu(2024)는 긴 컨텍스트 배포의 어려움을 KV 캐시 단일 원인으로 환원한다.

책상 비유로 KV 캐시 풀어보기

LLM은 토큰을 하나씩 생성한다. 다음 토큰을 만들려면 어텐션이 앞 토큰들의 key·value 벡터를 전부 봐야 하고, 매번 다시 계산하기엔 비싸니 메모리에 저장해둔다 — 그게 KV 캐시다. 토큰을 1개 더 생성할 때마다 새 K·V 한 묶음이 메모리에 더해진다. 1개씩, 선형으로.

SGLang에서 RadixAttention을 도서관 책장으로 풀었듯, KV 캐시 자체는 책상 위에 펼친 책 더미 비유로 풀린다.

책상 한 장을 떠올려보자. 책상의 크기가 컨텍스트 윈도우 한도다 — 8K, 128K, 1M. 한 페이지는 토큰 1개고, 그 페이지에 그 토큰의 key·value 벡터가 적혀 있다. 펼쳐둔 책 전체의 무게가 KV 캐시 메모리다. 한 페이지의 무게는 모델 크기·정밀도·KV head 수에 따라 정해진다 — Llama 3.1 8B(BF16) 한 페이지가 128 KB인데, 정확 계산은 뒤에서 다시 본다.

다음 토큰을 쓰려면 책상 위 모든 페이지를 한 번씩 훑어야 한다. 그게 어텐션 연산이다. 책상에 펼친 책이 1만 페이지면 새 한 페이지를 더 쓸 때 1만 페이지를 같이 본다.

그림 2. 책상 = context window, 펼친 책의 무게 = KV 캐시 메모리, 한 페이지 = 토큰 1개

비유는 여기까지가 깔끔하다. 다음은 이걸 토큰당 KB 단위 숫자로 옮겨보는 내용이다.

모델별 정확 수치 — Llama 3.1 8B/70B 컨텍스트별 표

KV 캐시 크기는 닫힌 공식으로 계산된다. NVIDIA Technical Blog·Lyceum·Morph가 동일하게 인용하는 표준 공식은 다음과 같다.

KV 캐시 (bytes) = 2 × num_layers × num_kv_heads × head_dim × seq_len × dtype_bytes

여기서 2는 K와 V 두 텐서, num_layers는 트랜스포머 블록 수, num_kv_heads는 GQA 이후 KV head 수, head_dim은 헤드 차원, seq_len은 컨텍스트 토큰 수, dtype_bytes는 정밀도 바이트(BF16/FP16 = 2, FP8 = 1)다. Llama 3.1 8B는 HuggingFace config.json에 num_hidden_layers=32, num_key_value_heads=8, hidden_size=4096, num_attention_heads=32로 박혀 있다. head_dim은 4096/32 = 128. 토큰 1개당 KV 캐시는 2 × 32 × 8 × 128 × 2 = 131,072 bytes, 128 KB다.

그림 3. Llama 3.1 8B config.json — num_hidden_layers=32, num_key_value_heads=8

여기에 컨텍스트 토큰 수를 곱하면 모델별 KV 캐시가 나온다. 단일 시퀀스(batch=1) 기준이다.

표만 보면 “지수적으로 늘어난다”고 적고 싶어진다. 정확히는 그렇지 않다. 단일 시퀀스의 KV 캐시 자체는 토큰 수에 선형으로 늘어난다. 다만 모델 크기(8B → 70B), 정밀도, 동시 사용자 수가 곱셈으로 붙으면서 GPU 한 장의 한계가 빠르게 닥친다. “기하급수적”보다는 “선형이지만 곱셈으로 부풀어 오른다”가 더 정확하다.

숫자로 보면 분명하다. 70B를 1M로 돌리면 KV만 320 GB라 H100 80GB 한 장에 KV조차 못 들어가고, 가중치(BF16 약 140 GB)까지 합치면 H100 4~5장에 나눠 담아야 한다. 8B도 1M이면 KV 128 GB로 80GB 한계를 넘는다.

GQA가 없었다면 더 무거웠다

표의 무게는 Llama 3.1이 GQA(grouped-query attention)를 쓴 결과다. num_key_value_heads가 query head 수(8B는 32, 70B는 64)보다 작아서(둘 다 8) KV 캐시가 줄어 있다. MHA였다면 8B는 토큰당 512 KB로 4배, 70B는 토큰당 2.5 MB로 8배 더 컸을 거다. 비교 대상을 빼고 “GQA는 8배 절약”이라고만 적으면 8B는 4배라 모순처럼 보이는데 둘 다 맞는 숫자다. GQA는 Ainslie 외 EMNLP 2023이 제안해 Llama 2 70B(2023-07)에서 처음 채택됐고 Llama 3부터 전 사이즈로 통일됐다.

API 가격 임계점 — Gemini 2.5 Pro와 Claude 시점 차

메모리 수치를 가격에 연결할 차례다. 가장 깨끗하게 임계점이 보이는 모델이 Gemini 2.5 Pro다. Google AI 공식 pricing은 input을 ≤200K 구간 $1.25/MTok, >200K 구간 $2.50/MTok(정확히 2배), output은 ≤200K $10/MTok, >200K $15/MTok(1.5배)으로 적는다. 같은 모델인데 200K 라인 하나를 기준으로 단가가 갈린다.

2024 vs 2026 — Claude 200K 임계점의 시점 차

시점	상황
2024-08 ~ 2025	Claude Sonnet 4·4.5, 200K 초과 시 input $3→$6 (2배), output $15→$22.50 (1.5배). 1M 베타·Tier 4+ 한정
2026-04 이후 (현재)	Opus 4.8 · 4.7 · 4.6 · Sonnet 4.6은 1M까지 standard pricing. 임계점 사라짐. 공식 docs가 “900k-token 요청도 9k-token 요청과 같은 per-token rate로 청구된다”고 적는다 (Anthropic 모델 버전은 빈번하게 갱신되니 docs 직접 확인 권장)
차이	글이 인용되는 시점에 따라 다르다. 2024 시점에 적힌 글이 그대로 2026까지 돌아다니면서 “Claude 200K = 2배”가 굳어진 모양새다

그러니까 “Claude 200K부터 2배”를 검색에서 본 적이 있다면 그건 2024 시점의 사실이다. 2026 현재 Claude 신모델 라인에서는 그 임계점이 사라졌다. 임계점이 여전히 명시적으로 살아 있는 모델은 지금은 Gemini 2.5 Pro 쪽이다.

그림 4. Gemini 2.5 Pro의 200K 임계점 — input 2배, output 1.5배

가격 얘기에서 자주 보이는 단정이 하나 더 있다. 인터넷에서 “1M 컨텍스트는 1000배 비싸진다” 같은 문장을 종종 본다. 원전을 못 찾았다. 한국어·영어 검색 어디에도, arxiv·공식 pricing 어디에도 1000배라는 단일 출처가 잡히지 않는다. 가장 가까운 정량 인용은 Yao Fu(2024)가 7B 모델 1M 토큰 KV가 100GB+ VRAM을 요구한다고 적는 정도다. 그래서 여기서는 1000배는 빼고 검증되는 숫자만 적었다 — Llama 3.1 8B 8K→1M KV가 1GB→128GB로 128배, Gemini 2.5 Pro 200K 초과 input 2배.

그림 5. Anthropic 공식 docs — Opus 4.8·4.7·4.6·Sonnet 4.6은 1M까지 standard pricing

200K·1M 임계점은 마법이 아니라 H100 80GB 한 장이 KV를 더 들 수 없는 지점이 가격에 비친 모양새다. 그 너머는 GPU 여러 장과 더 복잡한 인프라가 붙어야 하니 단가가 갈린다.

세 길의 정리 — GQA · PagedAttention · RadixAttention

여기까지 보면 KV 캐시는 한 문제, 세 길이 있다.

셋은 경쟁이 아니라 다른 축의 답이다. GQA는 한 페이지의 무게 자체를 줄이고, PagedAttention은 책상 위 책 배치의 빈틈을 줄이고, RadixAttention은 같은 첫 장을 두 번 펼치지 않는다. vLLM·SGLang 같은 서빙 엔진은 GQA 모델 위에서 두 기법을 같이 쓴다 — 같은 진앙에 세 약이 다른 축으로 붙는 구조다.

그래서 긴 컨텍스트는 어떻게 다루나

표를 다시 보면 “내 모델 + 내 컨텍스트 = KV 몇 GB”가 머릿속으로 계산된다. 로컬은 그 숫자가 가용 VRAM·통합 메모리를 안 넘어야 하고, API는 컨텍스트 임계점·prompt caching 단가가 곧 비용으로 이어진다. M3 Pro 36GB는 Llama 3.1 8B BF16(16GB) + 32K KV 4GB = 약 20GB로 여유가 있지만, 128K까지 가면 합 32GB로 빠듯해진다. RTX 2070 8GB는 8B BF16 자체가 VRAM을 넘어서 Q4 양자화 + 짧은 컨텍스트 조합만 현실적이다.

API는 또 다른 절약 방법이 있다. Anthropic·Google의 prompt caching·context caching이 반복되는 prefix의 재청구를 일부 흡수한다 — Claude API 비용 가이드에서 캐시 단가와 배치 할인을 정리해뒀다.

자주 묻는 질문

Q1. KV 캐시가 정확히 뭔가요? 트랜스포머가 매 토큰의 key·value 벡터를 메모리에 저장해 다음 토큰을 만들 때 재사용하는 자료구조다. 비유로는 책상 위에 펼쳐둔 책 더미 — 한 페이지는 한 토큰, 책상 크기가 컨텍스트 윈도우다.

Q2. 왜 긴 컨텍스트가 빠르게 비싸지나요? KV 캐시가 토큰 수에 선형으로 늘고, 거기에 모델 크기·정밀도·동시 사용자 수가 곱셈으로 붙어 GPU 한 장의 메모리 한계가 빠르게 닥치기 때문이다. 200K·1M 임계점은 그 한계가 가격에 비친 자리다.

Q3. Claude 200K랑 Gemini 1M, 가격은 똑같이 오르나요? 시점·모델마다 다르다. 2026 현재 명시적 임계점은 Gemini 2.5 Pro의 200K 초과 input 2배·output 1.5배. Claude는 2024~2025 시점엔 Sonnet 4·4.5 200K 초과 2배가 있었지만 2026 현재 Opus 4.8·4.7·4.6·Sonnet 4.6은 1M까지 standard pricing이다.

Q4. GQA가 KV 캐시를 얼마나 아끼나요? 비교 대상을 명시해야 한다. Llama 3.1 8B 기준 4배, 70B 기준 8배 — MHA로 가정한 경우 대비다. MQA로 가면 한 단계 더 줄지만 품질이 같이 떨어지는 trade-off가 있어 Llama 라인은 GQA를 채택했다.

Q5. “1M 컨텍스트는 1000배 비싸진다”는 사실인가요? 원전을 못 찾아 여기서는 다루지 않았다. 검증되는 가까운 정량 인용은 Yao Fu 논문이 짚는 “7B 모델 1M 토큰 KV가 100GB+ VRAM” 정도다.

Q6. 8GB GPU(예: RTX 2070)에서 8K context를 돌릴 수 있나요? 8B 모델 BF16 자체가 16GB라 VRAM을 넘는다. Q4 양자화(45GB) + 짧은 컨텍스트(4K8K)에선 가능하다. 긴 컨텍스트 자체는 8GB 단일 GPU에선 어렵다.

Q7. PagedAttention·RadixAttention·GQA는 어떻게 다른가요? 같은 KV 캐시 문제를 다른 축에서 푼다. GQA는 한 토큰의 KV 크기 자체를 줄이고, PagedAttention은 메모리 단편화를 줄이고, RadixAttention은 같은 prefix를 두 번 계산하지 않는다. 셋은 같이 쓰는 약이다.

정리 — KV 캐시는 마법이 아니라 책상 위 무게다

KV 캐시는 마법이 아니라 책상 위에 펼쳐둔 책의 무게다. 한 토큰을 더할 때마다 무게가 선형으로 늘고, 모델 크기·정밀도·동시 사용자가 곱해지면 GPU 한 장의 한계가 빠르게 닥친다. Claude 200K·Gemini 1M에서 가격이 갑자기 오르는 임계점은 그 무게가 H100 80GB 한 장의 물리 한계를 넘는 지점이다. PagedAttention·RadixAttention·GQA는 그 무게를 줄이는 세 길이고 본 시리즈에서 한 글씩 다뤘다. 원리를 알면 “1M 1000배”라는 숫자에 휘둘리지 않게 된다 — 이 글에서 풀고 싶었던 한 줄이다.

관련 글

• vLLM은 왜 빠른가 — PagedAttention을 OS 페이징으로 이해하기 — 이 글의 짝꿍. 공간 차원(메모리 단편화)으로 KV 캐시 문제를 푼 길.
• SGLang은 왜 빠른가 — RadixAttention과 prefix 공유의 직관 — 이 글의 짝꿍. 상태 차원(prefix 재사용)으로 KV 캐시 문제를 푼 길.
• Claude API 비용 완벽 가이드 2026 — 위 글이 짚은 가격 임계점의 실전 비용 가이드. 200K·prompt caching 맥락.
• Ollama로 M3 Pro 맥북에 로컬 LLM 띄우기 — 30분 실측 가이드 — 로컬 환경에서 KV 캐시 무게를 직접 느끼는 가장 단순한 출발점.
• M3 Pro에서 vLLM 돌려보기 — Mac 3경로와 솔직한 한계 (2026) — 위 vLLM 짝꿍 글의 실측편. 책상 비유의 GB 숫자가 실제 Mac에서 어떻게 도는지.

참고 자료

• Attention is All You Need — Vaswani et al., arXiv:1706.03762 — Transformer·멀티헤드 어텐션 K·V 원전
• Challenges in Deploying Long-Context Transformers — Yao Fu, arXiv:2405.08944 — “KV 캐시가 긴 컨텍스트 어려움의 단일 원인”이라는 학술 뼈대. 7B 모델 1M 토큰 KV 100GB+ 인용
• GQA: Training Generalized Multi-Query Transformer Models — Ainslie et al., arXiv:2305.13245 (EMNLP 2023) — GQA 원논문. 4·8배 절약 출처
• Fast Transformer Decoding — Shazeer, arXiv:1911.02150 — MQA 원논문
• The Llama 3 Herd of Models — arXiv:2407.21783 — Llama 3.1 공식 논문. 128K context·GQA 통일
• Mastering LLM Techniques: Inference Optimization — NVIDIA Technical Blog — KV 캐시 공식 1차 정리
• NousResearch/Meta-Llama-3.1-8B config.json — num_layers·num_kv_heads·head_dim 직접 인용
• Anthropic Pricing — platform.claude.com — Opus 4.8·4.7·4.6·Sonnet 4.6 1M까지 standard pricing 공식 명시
• Anthropic Context Windows — platform.claude.com — “working memory” 표현. 책상 비유 정합 근거
• Gemini API Pricing — Google AI — Gemini 2.5 Pro 200K 임계점 정확 인용
• PagedAttention — Kwon et al., arXiv:2309.06180 (SOSP 2023) — vLLM PagedAttention 원논문
• SGLang RadixAttention — Zheng et al., arXiv:2312.07104 (NeurIPS 2024) — SGLang RadixAttention 원논문

그림 1. SGLang 공식 문서 첫 화면

TL;DR

• SGLang은 LMSYS(UC 버클리 Zheng et al.)가 NeurIPS 2024에서 발표한 LLM 서빙 프레임워크. 핵심은 RadixAttention — 접두사 트리(radix tree)로 KV 캐시를 공유하는 알고리즘이다.
• CoT·multi-turn 채팅·few-shot·RAG처럼 같은 prefix가 반복되는 워크로드에서 prefix를 재계산하지 않아 처리량을 끌어올린다. Chatbot Arena 실측 cache hit이 LLaVA-Next-34B 52.4%·Vicuna-33B 74.1%였다 (SGLang 논문).
• 논문 abstract 기준 최대 6.4배 throughput — vs Guidance·vLLM·LMQL·TGI 여러 워크로드의 최댓값(Llama-7B A10G·Mixtral-8x7B). LMSYS 블로그(좁은 범위)는 “최대 5배”로 적었는데 같은 연구를 다른 범위에서 본 수치라 서로 모순이 아니다.
• PagedAttention과는 다른 축의 최적화라 SGLang은 둘을 같이 쓴다. 2025~2026년 vLLM도 APC(Automatic Prefix Caching) 를 도입해 prefix 공유는 두 진영 공통 자산이 됐고, SGLang의 차별은 그 이상의 구조(CFSM·Frontend DSL)로 이동했다.

SGLang이란? 왜 다들 SGLang을 말하나

SGLang은 LMSYS(UC 버클리, vLLM·Chatbot Arena와 같은 그룹)의 Lianmin Zheng 외가 arXiv:2312.07104 — NeurIPS 2024에서 발표한 LLM 서빙 프레임워크다. 2026년 5월 현재 GitHub 28.7k stars, xAI(Grok)·NVIDIA·AMD·LinkedIn·Cursor 등이 운영에 채택했다.

vLLM이 메모리 단편화를 줄여 더 많은 요청을 동시에 처리하는 길이었다면, SGLang은 같은 prefix를 두 번 계산하지 않는 다른 길이다. 둘은 경쟁이 아니라 짝이고, SGLang은 두 기법을 같이 쓴다.

같은 prefix를 매번 다시 계산하는 낭비 — 무엇이 반복되나

KV 캐시를 짧게 짚으면 — LLM은 토큰을 하나씩 생성하면서 앞 토큰의 key/value 벡터를 재사용한다. 매번 다시 계산하면 느리니 메모리에 저장해둔다.

운영 워크로드를 들여다보면 한 가지가 눈에 띈다. system prompt, few-shot 예시, 대화 이력, RAG 컨텍스트가 요청마다 반복된다. 기존 시스템은 이 반복되는 prefix를 매 요청마다 처음부터 다시 KV로 계산한다 — 캐시는 한 요청 안에서만 재사용되고 다음 요청이 오면 사라진다. SGLang 논문은 이 낭비가 특히 큰 4가지를 짚는다 — Few-shot learning, Self-consistency·CoT, Multi-turn chat, Tree-of-thought.

처리량 한계가 메모리에 있다면 vLLM의 PagedAttention이 답이지만, 한계가 같은 prefix를 또 계산하는 데 있다면 다른 길이 필요하다. 그 길이 RadixAttention이다.

RadixAttention 직관 — 도서관 책장 정리 비유

여기가 글의 핵심이다. PagedAttention을 OS 페이징으로 풀었듯, RadixAttention은 도서관 책장 비유로 풀린다.

일반 도서관을 떠올려보자. 책이 입고 순서대로 아무 책장에 꽂힌다. “김”으로 시작하는 책을 찾으려면 처음부터 뒤져야 한다. 기존 KV 캐시가 딱 이 모양이다 — 같은 prefix로 시작하는 시퀀스가 들어와도 이전 결과를 찾을 길이 없으니 처음부터 계산한다.

이제 잘 정리된 도서관을 그려보자. 같은 첫 글자로 시작하는 책은 같은 책장에, 같은 두 글자는 같은 칸에, 같은 세 글자는 같은 선반에 둔다. 트리처럼 가지치기로 분류되는 구조다. prefix가 같은 시퀀스가 들어오면 가장 긴 매칭 칸까지 그대로 재사용하고, 새 토큰만 그 가지 끝에 추가하면 된다.

이 트리가 radix tree(접두사 트리) 다. 일반 trie와 다른 점은 간선에 단일 문자가 아니라 가변 길이 시퀀스가 라벨로 붙는다는 것 — 한 칸에 여러 글자 묶음이 들어간다고 생각하면 된다. KV 노드 메타는 CPU, 실제 KV 텐서는 GPU의 paged layout(토큰 1개당 1 page)에 둔다. PagedAttention의 메모리 구조 위에 RadixAttention의 prefix 공유 레이어가 얹히는 구조다.

동작은 단순하다. 새 요청이 오면 스케줄러가 트리를 순회해 가장 긴 매칭 prefix까지 재사용하고, 신규 토큰만 계산해 가지 끝에 새 노드를 매단다. 자리가 부족하면 가장 오래 안 본 책부터 뺀다 — LRU 기반 eviction(리프 노드부터, reference count 0 우선). 트리 관리 패널티는 작다. LMSYS 블로그는 ShareGPT 측정 오버헤드 0.3% 미만이라고 적는다 — cache hit이 없어도 손해가 거의 없고, hit이 있으면 그만큼 이득이다.

비유를 하나 더 보태면, 멀티턴 채팅은 “회사 양식 템플릿”에 가깝다 — 표지·머리말·정형 문구를 매번 새로 쓰지 않고 양식을 재사용한다.

그림 2. RadixAttention의 radix tree — 같은 prefix까지는 재사용, 새 토큰만 새 가지

PagedAttention과 RadixAttention — 공간 vs 상태

vLLM 글을 읽은 사람이 가장 궁금해할 질문에 답할 차례다.

PagedAttention이 공간(메모리)을 아끼고, RadixAttention은 상태(계산)를 아낀다.

두 기법은 서로 다른 영역을 건드리니 같이 쓸 수 있다. LMSYS 블로그 원문이 명시한다 — “RadixAttention is compatible with existing techniques like continuous batching and paged attention.” SGLang 런타임은 paged layout 위에 RadixAttention의 prefix 공유 레이어를 얹는다. 같이 쓴다.

그래서 SGLang vs vLLM은 “어느 게 더 빠른가”가 아니라 “어느 워크로드냐”의 문제다. 그런데 여기서 한 가지 짚고 가야 한다.

2024 vs 2026 — vLLM APC 도입의 진실

시점	상황
2024 초	SGLang의 RadixAttention 발표 직후. vLLM은 prefix caching 미보유. 워크로드에 따라 RadixAttention 우위 명확
2025~2026	vLLM이 APC(Automatic Prefix Caching) 도입. vLLM design docs가 본인 입으로 “this eviction policy effectively implements the exact policy as in RadixAttention when applied to models with full attention“이라고 적는다 — RadixAttention의 정책과 사실상 동등 (full attention 모델 한정)
차이	SGLang은 token-level radix tree, vLLM APC는 block-level hash matching. 매칭 단위와 자료구조가 다르고, 워크로드에 따라 격차가 다르게 나타난다

정리하면, prefix 공유 자체는 두 진영의 공통 자산이 됐다. SGLang의 차별은 그 이상의 구조(아래에서 짧게 볼 Compressed FSM·Frontend DSL)로 이동했다. 이 시점 차를 모르면 “SGLang이 prefix caching의 유일한 답”이라는 인상을 받기 쉬운데, 그건 2024 시점에 적힌 글이 그대로 전해진 결과다.

“최대 6.4배”의 정확한 비교 대상

SGLang 논문 abstract는 이렇게 적는다 — “SGLang achieves up to 6.4× higher throughput compared to state-of-the-art inference systems on various large language and multi-modal models on tasks including agent control, logical reasoning, few-shot learning benchmarks, JSON decoding, retrieval-augmented generation pipelines, and multi-turn chat.” 한 문장에 비교 상대·모델·워크로드·”최댓값” 정보가 모두 들어 있다. 그래서 “6.4배 빠르다”만 따로 떼면 비교 상대·모델·워크로드가 사라진 숫자가 된다.

수치 정직 박스 — 같은 SGLang의 여러 숫자

수치	무엇 대비 무엇	조건 · 출처
최대 6.4배 throughput	SGLang vs Guidance·vLLM·LMQL·HuggingFace TGI	Llama-7B(A10G)·Mixtral-8x7B, 여러 워크로드의 최댓값 (arXiv:2312.07104 abstract)
최대 5배 throughput	SGLang vs Guidance v0.1.8, vLLM v0.2.5, TGI v1.3.0	Llama-7B/Mixtral, A10G, MMLU·HellaSwag·ReAct·ToT (좁은 범위) (LMSYS Blog 2024-01-17)
최대 2.5배 throughput (구조화 출력)	SGLang compressed FSM (jump-forward) vs Outlines+vLLM v0.2.7, Guidance+llama.cpp v0.2.38	Llama-7B, 정보 추출·JSON 디코딩 (LMSYS Blog 2024-02-05)
cache hit 52.4% / 74.1%	RadixAttention 실측 (LLaVA-Next-34B / Vicuna-33B)	Chatbot Arena 프로덕션 (SGLang 논문)

같은 SGLang에 대한 다른 숫자가 모순이 아닌 이유는 비교 상대와 워크로드 범위가 다르기 때문이다. S4에서 본 vLLM의 “24배 vs 2~4배”와 같은 패턴.

참고로 “SGLang structured generation 최대 22배”라는 수치를 인터넷에서 종종 본다. 그런데 원전을 못 찾았다. SGLang 논문·LMSYS 블로그·GitHub README·NeurIPS Proceedings를 다 훑어봐도 22배가 어디서 나온 수치인지 짚을 수 없었다. 가장 가까운 검증 가능 수치는 위 표의 CFSM 2~2.5배(vs Outlines+vLLM·Guidance+llama.cpp)이고, xgrammar 통합 이후 JSON 디코딩 3~10배가 LMSYS 트윗 2024-11에서 확인된다. 그래서 본 글에서는 22배는 빼고 위 표의 수치만 적었다.

Compressed FSM과 Frontend DSL — 한 줄로

SGLang의 차별이 RadixAttention “그 이상”으로 이동했다고 했으니, 그 위가 무엇인지 짧게 짚는다.

Compressed FSM(CFSM) — JSON schema·정규식으로 출력을 강제하는 constrained decoding. schema → regex → FSM 변환 후 “토큰 선택지가 단 하나뿐”인 구간을 찾아 여러 토큰을 한 번에 prefill 처리한다(jump-forward). 구조화 출력이 자유 생성보다 빨라지는 경우가 생기는 이유다 — LMSYS 블로그 참조.

Frontend DSL — Python 내장 DSL로 prompt 흐름을 함수처럼 표현한다(gen()·select()·fork()). prefix 공유 효과는 vanilla API에서도 자동으로 얻으니, DSL은 여러 단계 prompt 프로그램을 함수처럼 짜는 추가 도구로 보면 된다.

Ollama·vLLM·SGLang — 어느 게 빠른가가 아니라 목적이 다르다

원리를 알고 나면 자주 나오는 질문이 “그럼 셋 중 뭐 쓰지”다. Ollama는 단일 사용자 prototyping의 단순함, vLLM은 다중 요청 처리량의 메모리 효율, SGLang은 prefix가 반복되는 워크로드(챗봇·RAG·에이전트·CoT)의 계산 절약과 jump-forward — 어느 게 빠른가가 아니라 목적이 다르다. SGLang은 vLLM의 대체가 아니라 PagedAttention 위에 RadixAttention을 얹는 조합 관계고, 단일 사용자 로컬에선 Ollama가 더 실용적, 동시 요청이 많은 서버에서 SGLang 이득이 드러난다. 단일 기기 결정 트리는 후속 글(준비 중).

자주 묻는 질문

Q1. SGLang이 vLLM보다 정말 6배 빠른가요? 6.4배는 SGLang 논문 abstract의 vs Guidance·vLLM·LMQL·TGI 여러 워크로드 최댓값(Llama-7B A10G·Mixtral-8x7B)이다. LMSYS 블로그(좁은 범위)에선 5배, 일반 batch 워크로드에선 더 작을 수 있다.

Q2. RadixAttention과 PagedAttention의 차이는 무엇인가요? PagedAttention은 메모리 단편화를 줄여 공간을 아끼고, RadixAttention은 같은 prefix를 두 번 계산하지 않아 상태(계산)를 아낀다. 둘은 서로 다른 축의 최적화라 SGLang은 둘을 같이 쓰고, 2025~2026년 vLLM도 APC로 prefix caching을 흡수했다.

Q3. SGLang은 vLLM을 대체하나요? 꼭 그렇진 않다. prefix 공유 효과가 큰 워크로드(챗봇·RAG·에이전트·CoT)는 SGLang이 강점, 일반 서빙은 vLLM도 충분. 둘 다 OpenAI 호환 API라 엔드포인트만 바꾸면 코드가 그대로 붙는다.

Q4. RadixAttention은 어떤 워크로드에 가장 효과적인가요? system prompt가 반복되는 챗봇, few-shot 예시를 공유하는 분류·추출, CoT 분기, multi-turn 대화처럼 prefix가 반복되는 패턴이다. Chatbot Arena 실측 cache hit이 LLaVA-Next-34B 52.4%·Vicuna-33B 74.1%(SGLang 논문 RadixAttention 실험)였다.

Q5. SGLang의 Compressed FSM이 22배 빠르다는데 사실인가요? 논문·LMSYS·GitHub README를 다 훑어봐도 22배 수치는 못 찾았다. 검증되는 가까운 수치는 CFSM(jump-forward)의 최대 2.5배 throughput·2배 latency 감소 — vs Outlines+vLLM v0.2.7·Guidance+llama.cpp v0.2.38(LMSYS 2024-02-05)이고, xgrammar 통합 후 JSON 디코딩 3~10배가 LMSYS 트윗 2024-11에 보고됐다. 그래서 본 글에서도 22배는 다루지 않았다.

Q6. SGLang을 RTX 2070·M3 Pro 같은 소비자 GPU에서 돌릴 수 있나요? 가능하나 throughput 이득은 동시 요청이 많은 서버 시나리오에서 본격적으로 나타난다. 단일 사용자 로컬은 Ollama·llama.cpp가 더 실용적이고, 결정 트리는 후속 글에서 다룬다.

Q7. SGLang은 Ollama와 어떻게 다른가요? “단일 사용자 = Ollama, 다중 처리량 + prefix 반복 = SGLang”으로 정리하면 헷갈리지 않는다. 어느 게 빠른가가 아니라 목적이 다르다.

정리 — 빠름은 마법이 아니라 책장 정리다

SGLang의 빠름은 트리 한 그루에서 나온다. 같은 prefix로 시작하는 KV를 같은 가지에 모아두고, 새 요청이 오면 가장 긴 매칭 가지까지 재사용한 뒤 새 토큰만 가지를 친다 — 도서관이 잘 정리되면 같은 책을 두 번 찾으러 안 다니듯. PagedAttention과 짝이고, 공간을 아끼는 길과 상태를 아끼는 길은 다른 축이라 같이 쓸 수 있다. 2026년 vLLM도 APC로 같은 방향을 흡수했고, SGLang의 차별은 그 위(CFSM·Frontend DSL)로 옮겨갔다. 원리를 알면 “6.4배”라는 숫자에 휘둘리지 않게 된다. 이 글에서 풀고 싶었던 게 그 한 줄이다.

관련 글

• vLLM은 왜 빠른가 — PagedAttention을 OS 페이징으로 이해하기 — 본 글의 짝꿍. RadixAttention과는 다른 축(공간 차원)의 원리. 본 글의 “PagedAttention vs RadixAttention” 박스가 직접 참조한 글이다.
• M3 Pro에서 vLLM 돌려보기 — Mac 3경로와 솔직한 한계 (2026) — 짝꿍 글의 실측편. 원리를 알았으니 실제 맥에서 어떻게 도는지 보고 싶다면.
• Ollama로 M3 Pro 맥북에 로컬 LLM 띄우기 — 30분 실측 가이드 — “셋 중 뭐 쓰지”의 가장 단순한 출발점. “단일 사용자 = Ollama” 맥락.
• (준비 중) Mac·RTX 2070에서 SGLang 결정 트리 — 본 글의 실측 짝으로 이어질 후속 글.

참고 자료

• SGLang: Efficient Execution of Structured Language Model Programs — arXiv:2312.07104 (NeurIPS 2024) — RadixAttention·CFSM 원논문. 6.4배·cache hit 52.4%·74.1% 출처
• KV 캐시가 뭐길래 — 긴 컨텍스트가 빠르게 비싸지는 이유 — 본 글이 다룬 RadixAttention의 진앙. PagedAttention(공간)·RadixAttention(상태)이 풀려고 한 KV 캐시 자체를 책상 비유로 푼 학습 시리즈 뿌리 글. Claude 200K·Gemini 1M 가격 임계점까지.
• Fast and Expressive LLM Inference with RadixAttention and SGLang — LMSYS Blog (2024-01-17) — RadixAttention 도입 글. 5배(좁은 범위) 출처, “compatible with paged attention” 인용
• Fast JSON Decoding for Local LLMs with Compressed Finite State Machine — LMSYS Blog (2024-02-05) — CFSM 도입 글. 2.5배·2배 출처
• vLLM Automatic Prefix Caching — design docs — vLLM이 RadixAttention 정책을 흡수했음을 본인 문서에 명시한 1차 근거 (“when applied to models with full attention”)
• vLLM Automatic Prefix Caching — 사용 문서(latest) — APC 사용·설정 소개 페이지
• SGLang GitHub Repository — 최신 버전·운영 채택 현황(2026-05 기준 28.7k stars, xAI·NVIDIA·AMD·Cursor 등)
• PagedAttention 원논문 — arXiv:2309.06180 (SOSP 2023) — 짝꿍 글 S4의 1차 출처. 본 글에선 비교 컨텍스트로 1회 참조

측정 환경 (2026-05-29 기준)

• 기기: Apple Mac M3 Pro (6P+6E CPU, 18코어 GPU), 36GB 통합메모리, macOS Tahoe 26.5
• 설치 경로: 경로 3 — Docker Desktop의 Model Runner, --backend vllm 설치 결과 docker model status에서 vllm-metal v0.2.0-20260420-142150 Running 확인 (llama.cpp도 함께 Running 상태로 공존)
• 모델·양자화: DMR 정규화 ID huggingface.co/mlx-community/llama-3.2-1b-instruct-4bit:latest (193.15M 파라미터·quantization: mixed·695.28MB) → 7B 4-bit로 확장
• 호스트 접근: Settings → AI → Docker Model Runner 섹션의 TCP Port 12434 + Bind Localhost(127.0.0.1) / 엔드포인트는 http://localhost:12434/engines/v1/...
• 측정 항목: 단일 스트림 tok/s, max_tokens 512, temperature 0.0
• measured_on: 2026-05-29. vllm-metal·Docker Model Runner는 2026년 초·중반 막 등장한 신생 기능이라 6개월 내 사용법·지원 범위가 바뀔 수 있다.

TL;DR

• 2026년 5월 기준 Apple Silicon에서 vLLM을 띄우는 경로는 세 갈래다 — 공식 CPU backend(느림), vllm-metal(Metal GPU), Docker Model Runner(설치 가장 쉬움).
• vLLM 본체는 여전히 macOS에서 CPU 한정·실험적이지만, vllm-metal 플러그인 경로로는 Metal GPU가 열렸다. “맥에선 CPU로만 돈다”는 단정은 이제 부정확하다.
• 36GB라면 MLX 4-bit 7~13B가 현실적인 범위다. 그 이상은 메모리 초과 위험.
• 단일 스트림에선 vLLM이 Ollama보다 빠르지 않다. 같은 M3 Pro 36GB에서 vllm-metal Qwen2-7B 4-bit가 웜 평균 21.6 tok/s, S1의 Ollama Llama 3.1 8B Q4_K_M이 약 22 tok/s — 사실상 동률.
• 다만 동시성을 올리면 batching 이점이 실제로 보인다 — 4 동시 요청 시 aggregate 62 tok/s로 2.87× 스케일업. 선형 4배는 아니지만(GPU 코어·메모리 대역폭 병목) PagedAttention이 맥에서도 작동은 한다. 본 글의 맥 실측은 처리량 자랑이 아니라 “원리가 실제로 도는지 확인”이 목적이다.

왜 굳이 맥에서 vLLM을 시도하나

솔직히 처리량만 보면 답은 정해져 있다. 단일 사용자 로컬 환경에서 vLLM을 상시 서빙 엔진으로 쓸 이유는 별로 없다. 그런데도 직접 띄워본 이유는 두 가지다.

하나는 학습이다. 논문에서 읽은 PagedAttention 구조가 내 GPU 위에서 실제로 도는 걸 한 번 보면, “내가 뭘 쓰고 있는지” 정확히 알고 다음 단계(CUDA GPU 서버)로 넘어갈 수 있다. 다른 하나는 정보가 빠르게 바뀌고 있어서다. 2026년 초·중반에 vllm-metal과 Docker Model Runner가 등장하면서 “맥에선 안 된다”는 통념이 흔들렸고, 그게 사실인지 직접 확인하고 싶었다. 결론부터 말하면 절반은 맞고 절반은 틀렸다.

2026년 Mac에서 vLLM의 세 갈래

찾아보니 Apple Silicon에서 vLLM을 띄우는 경로가 셋으로 열려 있었다.

• 경로 1 — vLLM 공식 CPU backend. macOS에서 VLLM_TARGET_DEVICE가 자동으로 cpu로 잡힌다. vLLM 공식 문서가 “experimental support”라 명시하고 prebuilt wheel이 없어 소스 빌드가 필수다(XCode 15.4+). FP32/FP16만 되고 Metal GPU를 안 써 가장 느리다. 원리 동작 확인용이다.
• 경로 2 — vllm-metal. vLLM 공식 org 산하 플러그인으로, MLX를 컴퓨트 백엔드로 써서 Apple GPU(Metal)를 실제로 사용한다. curl -fsSL .../install.sh | bash로 깔리고 native arm64 Python 3.12를 요구한다. vllm-metal GitHub 기준 v0.2.0(2026-04)이다.
• 경로 3 — Docker Model Runner. Docker가 vLLM과 공동 개발해 macOS에 vllm-metal을 얹는다고 발표한 경로(2026-02). 컨테이너가 아니라 호스트 네이티브로 실행되고 Docker Desktop 4.40+에서 model-runner는 기본 활성이다. 다만 공식 docs의 Inference engines 페이지는 2026-05 시점에도 macOS 기본 백엔드를 llama.cpp로 적고 있어 vllm-metal 자동 라우팅 여부는 빌드·버전마다 다르다 — 설치는 가장 쉽지만 “정말 vLLM이 서빙하는지”는 별도 확인이 필요한 경로다.

핵심은 vLLM 본체는 여전히 CPU 한정·실험적이지만 vllm-metal 플러그인 경로로는 Metal GPU가 열렸다는 점이다. “vLLM은 Mac에서 CPU로만 돈다”는 단정은 2026-05 시점에는 부정확하다. 나는 설치 마찰이 가장 작은 경로 3(Docker Model Runner)을 1순위로 시도했고, 막상 돌려보니 Docker Desktop CLI에 함정 두 개가 있었다(아래 함정 박스). 결과적으로는 vllm-metal이 서빙함을 보장하려면 경로 2(vllm-metal 직접 설치)가 더 정직했다.

# Docker Desktop 4.40+ 가 깔려 있어야 한다 (model-runner는 4.40+에서 기본 활성 컴포넌트)

# 1) Model Runner 활성화 — TCP 없이 먼저 켠다(--tcp 플래그는 일부 빌드에서 settings 스키마 충돌)
docker desktop enable model-runner

# 2) 상태 확인 — Running 으로 바뀌어야 하고, 백엔드들은 "Not Installed"로 노출됨
docker model status
# 출력 예:
#   Docker Model Runner is running
#   BACKEND    STATUS         DETAILS
#   diffusers  Not Installed
#   llama.cpp  Not Installed
#   mlx        Not Installed
#   vllm       Not Installed

# 3) vllm 백엔드 설치 — macOS에서는 vllm-metal로 자동 매핑된다(공식 블로그 표현)
#    ★중요: 이 단계 전에 TCP를 켜두면 install-runner가 실패한다(docker/model-runner#526).
#    먼저 install, 그다음 TCP를 켜는 순서.
docker model install-runner --backend vllm

# 4) MLX 4-bit 모델 풀 & 백그라운드 기동
docker model run -d hf.co/mlx-community/Llama-3.2-1B-Instruct-4bit

# 5) 호스트에서 curl을 치려면 TCP 활성화 — Docker Desktop → Settings → AI 패널의
#    "Docker Model Runner" 섹션에서 다음을 확인하고 하단 Apply & Restart
#       ✅ Enable Docker Model Runner
#       TCP Port: 12434 (default)
#       Bind address: Localhost (127.0.0.1)   ← 외부 노출 원하면 'All interfaces'지만 보안 위험
#       CORS allowed origins: (필요 시)
#    (CLI `docker desktop enable model-runner --tcp=12434`도 같은 설정이지만
#     `enableInferenceTCP` 키 미인식 에러를 내는 빌드가 있어 GUI가 안전)

# 6) 동작 확인했으면 7B 4-bit로 확장
docker model run -d hf.co/mlx-community/Qwen2-7B-Instruct-4bit

함정 — Docker Desktop의 명령 순서와 vllm-metal 자동 매핑의 불확정성

처음 시도했던 명령 docker model install-runner --backend vllm은 “Standalone installation not supported with Docker Desktop. Use docker desktop enable model-runner instead” 에러로 막혔다. 이건 install 자체가 막혀 있다는 뜻이 아니라 model-runner가 아직 안 떠 있을 때 install부터 시도해서 거부된 것이었다. 정확한 순서는 (1) docker desktop enable model-runner → (2) docker model install-runner --backend vllm → (3) 모델 pull/run → (4) 마지막에 TCP 활성화. (4)를 먼저 켜면 (2)가 실패한다는 GitHub 이슈 docker/model-runner#526이 동일 패턴을 보고하고 있다.

다음 함정은 백엔드 자동 매핑의 불확정성이다. 공식 docs 의 Inference engines 페이지는 2026-05 시점에도 “macOS vLLM: Not supported, llama.cpp가 기본“ 으로 표기돼 있고, docker model status가 vllm을 별도 백엔드 행으로 나열한다. 즉 vllm이 자동으로 선택되는 게 아니라 install-runner --backend vllm으로 명시 설치를 해야 vllm/vllm-metal 백엔드가 잡힌다. 설치 후에도 docker model status로 vllm 행이 Running/Installed로 바뀌었는지 한 번 더 확인해야 본 글의 “vLLM-Metal 측정”이 진짜로 vllm으로 서빙됨을 보장한다. 만약 install이 끝까지 실패하면 vllm-metal이 서빙함을 보장하는 길은 경로 2(vllm-metal install.sh 직접 설치) 가 된다.

마지막으로, 일부 Docker Desktop 빌드는 --tcp=<port> 플래그를 settings 스키마(enableInferenceTCP)가 인식 못 해 *”failed to update settings: settings format not recognized, unknown settings keys”*로 거부한다. 해결은 GUI 패널이다 — Settings → AI → “Docker Model Runner” 섹션에 Enable Docker Model Runner 체크, TCP Port 12434, Bind address Localhost(127.0.0.1)가 한 묶음으로 노출돼 있어 그대로 두고 하단 Apply & Restart를 누르면 끝난다. (구버전 안내가 가리키는 “Enable host-side TCP support” 같은 별도 토글은 최신 빌드의 AI 패널엔 없고, TCP Port + Bind address가 같은 역할이다.)

그림 1. M3 Pro에서 Docker Model Runner로 vLLM(vllm-metal) 기동

단일 스트림 tok/s 측정하기

단일 스트림 tok/s를 재려면 응답이 충분히 길어야(100~500토큰) 로딩·워밍업 노이즈가 줄어든다. OpenAI 호환 엔드포인트로 호출해 응답 토큰 수와 소요 시간을 함께 보는 게 가장 깔끔하다.

# 단일 스트림 측정 — 응답 길이를 충분히 확보(max_tokens 256~512)하고
# 같은 프롬프트를 3~5회 돌려 평균을 낸다
curl -s http://localhost:12434/engines/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "hf.co/mlx-community/Qwen2-7B-Instruct-4bit",
    "messages": [{"role": "user", "content": "PagedAttention을 300자로 설명해줘"}],
    "max_tokens": 512
  }'
# 응답 JSON의 usage.completion_tokens / 측정한 소요 시간(초) = tokens/sec
# Docker Model Runner는 OpenAI 호환 엔드포인트를 `/engines/v1/`(앞에 /engines/ 붙음) 아래에 둔다.
# 포트 12434는 `docker desktop enable model-runner --tcp=12434`의 기본값이고
# 다른 설치 경로(vllm-metal 직접 install.sh, standalone Docker)는 포트·경로가 달라질 수 있다.

내 M3 Pro(6P+6E CPU·18 GPU·36GB)에서 위 시퀀스로 7B 4-bit를 단일 스트림으로 돌려 평균을 냈다. 실측 결과는 다음과 같다.

M1 — Llama-3.2-1B-Instruct-4bit, 단일 스트림. 콜드 1회(모델 로드 포함) 27.16초로 약 19 tok/s, 그 뒤 웜 2회는 4.88·4.92초로 각각 104.9 / 104.1 tok/s — 웜 평균 약 104.5 tok/s. 콜드와 웜이 5배 넘게 벌어진다는 점이 학습 자산이다(첫 응답 한 번은 모델·KV 워밍업이 다 끼어 있고, 그다음부터가 진짜 처리량이다). max_tokens 512에 prompt 47 토큰, temperature 0.0의 결정적 생성 조건이다. docker model status로 vllm-metal v0.2.0-20260420-142150 Running을 미리 확인했으므로 이 수치는 llama.cpp가 아니라 vllm-metal이 낸 값이다.

M2 — Qwen2-7B-Instruct-4bit, 단일 스트림. 콜드 1회 40.78초 (4.3GB 모델 mmap·워밍업 포함) 후 웜 3회 8.53·8.52·8.63초로 각각 21.69 / 21.71 / 21.44 tok/s — 웜 평균 약 21.6 tok/s. 7B 모델임에도 응답은 185 토큰에서 자연 종료(max_tokens 512 한계 도달 전 EOS) — Qwen2 특성으로 보인다. 여기서 같은 환경의 S1 Ollama 측정값 약 22 tok/s와 거의 정확히 동률이라는 점이 핵심이다. 모델은 다르지만(Qwen2-7B vs Llama 3.1 8B) 둘 다 4-bit·7~8B급이라 직접 비교가 의미 있다 — 같은 기기, 단일 스트림이면 vllm-metal이 Ollama를 못 이긴다. 운영자 메타 발견 하나 더: DMR의 /engines/v1/models 응답 parameters 필드는 두 모델 모두 실제 파라미터 수의 ~15%만 카운트(Llama 3.2 1B → “193.15M”, Qwen2-7B → “1.19B”)해서 신뢰할 게 못 된다. size(695MB·4.28GB)는 정확하다.

M3 — 동시 4 요청, Qwen2-7B-Instruct-4bit. 같은 프롬프트를 백그라운드로 4개 동시에 던지고 모두 끝난 시점까지의 wall 시간을 쟀다. 결과: wall 11.94초, completion 합계 740 토큰, aggregate ≈ 62.0 tok/s. 단일 21.6 tok/s 대비 2.87배 스케일업이다. 같은 4 요청을 직렬로 돌렸으면 4×8.5≈34초 걸렸을 게 11.94초에 끝났으니, 절약은 약 2.85배. 즉 vllm-metal의 PagedAttention·continuous batching이 맥에서도 실제로 작동하긴 한다. 다만 선형 4배가 아닌 2.87배에 그치는 건 M3 Pro의 메모리 대역폭(150 GB/s)과 GPU 18 코어가 batch 가중치를 따라가지 못해서다 — KV 캐시는 효율적으로 나눠 썼지만 compute가 병목이다.

그림 2. M3 Pro vLLM-Metal 단일 스트림 tok/s 측정

모델 범위는 미리 알아두는 게 좋다. vllm-metal은 MLX 4-bit(group_size 128) 포맷 위주이고 그 외 포맷은 preflight 단계에서 거른다(vllm-metal 지원 모델 문서). 36GB라면 4-bit 7~13B가 현실적인 범위다(공개 검증 예가 M5 Pro 48GB에서 7~9B 4-bit). 35B급은 36GB를 초과할 위험이 있어 권하지 않는다. 참고로 “vllm-mlx로 400+ tok/s”라는 수치를 봤다면, 그 417.9 tok/s는 Qwen3-0.6B-8bit 초소형 모델 + M4 Max 128GB + 단일 스트림 greedy 조건이고 vllm-mlx는 공식 org가 아닌 별도 community 프로젝트다. M3 Pro에서 7B를 돌리면 그 근처도 안 나온다.

솔직한 한계 — 그래서 내 맥에선 학습용이다

여기가 이 글에서 제일 박고 싶었던 부분이다. 띄울 수 있다는 것과 빠르다는 건 다른 얘기다. 경로 2·3으로 Metal GPU까지 써서 M3 Pro 36GB에 7B 4-bit를 띄울 수는 있다. 그런데 처리량 이점은 안 난다. PagedAttention과 continuous batching의 이점은 동시 요청이 많은 GPU 서빙에서 나오는데, 혼자 한 번에 한 요청만 보내면 키울 batch도 채울 빈 슬롯도 없다. PagedAttention이 아무리 똑똑해도 단일 사용자에게는 발현될 무대가 없다.

수치로 보면 이렇다. 가장 직접적인 비교는 같은 M3 Pro 36GB 위에서 잰 본 글의 M2(vllm-metal, Qwen2-7B 4-bit, 단일 스트림 웜 평균 21.6 tok/s)와 S1에서 잰 Ollama(llama.cpp+Metal, Llama 3.1 8B Q4_K_M, 웜 평균 약 22 tok/s)다. 모델은 다르지만 둘 다 4-bit·7~8B급이라 동급으로 봐도 무리가 없는데, 사실상 동률이다. 혼자 한 요청만 던지면 vLLM의 PagedAttention이 발현될 무대가 없으니, 두 엔진의 차이가 메모리 대역폭(M3 Pro는 베이스·상위 모두 150 GB/s) 안에서 흡수돼 버린다.

흥미로운 건 동시성을 올려본 M3였다. 같은 Qwen2-7B를 동시 4 요청으로 던지니 aggregate 62 tok/s가 나왔다(단일 대비 2.87배 스케일업, 직렬 처리 대비 약 2.85배 절약). vllm-metal이 맥에서도 batching 이점을 실제로 보여주긴 한다는 뜻이다 — 다만 선형 4배가 아닌 2.87배에 그친 건 KV 캐시는 PagedAttention이 효율적으로 나눠 썼지만 18 GPU 코어의 컴퓨트가 batch 가중치를 따라가지 못해서다. 즉 맥에서 vllm-metal은 “완전 무용”은 아니지만 “본격 무대”도 아니다.

본격 무대는 Red Hat이 A100 GPU 서버에서 잰 벤치에 보인다 — vLLM이 256 동시 사용자에서 793 TPS, Ollama는 기본 설정(최대 4 병렬)에서 41 TPS — 19배 차이. M3 Pro에서 4 동시로 본 2.87배가 A100에서 256 동시면 19배가 되는 식이다. PagedAttention의 진짜 잠재력은 동시성과 메모리 대역폭이 같이 받쳐줄 때 비로소 풀린다. Docker가 다른 기기에서 잰 단일 스트림 벤치(Llama 3.2 1B, 4-bit) vLLM-Metal 251~279 vs llama.cpp 333~345 tok/s도 같은 패턴(단일에서는 llama.cpp가 오히려 1.2~1.3배 우세)을 보여준다.

그래서 이 글의 M3 Pro 실측은 처리량 자랑이 아니라 “원리가 실제로 도는지 확인”이 목적이다. 솔직히 내 맥에서 vLLM을 상시 서빙 엔진으로 쓸 이유는 아직 없다 — 혼자 쓰면 Ollama가 빠르고, vLLM은 학습용이다. 그래도 논문에서 읽은 구조가 내 GPU 위에서 실제로 도는 걸 본 건 학습으로서 값졌다. 본격적인 처리량 벤치는 결국 신선한 CUDA GPU(RTX 4090·5090 급)가 받쳐줘야 하는데, 솔직히 내 홈서버는 RTX 2070(VRAM 8GB) 이라 vLLM의 batching 잠재력을 끝까지 끌어내기엔 좀 부담스럽다. 7B Q4 정도면 띄울 수는 있겠지만 동시 요청을 늘릴수록 KV 캐시가 8GB에 빠르게 닿을 거라, “본격 프로덕션 처리량”이라고 부르기엔 어중간한 자리에서 멈출 가능성이 크다. 그래서 후속 글을 언제 쓸지는 GPU 업그레이드 여부와 함께 천천히 고민하는 중이다.

한 가지만 더. vllm-metal과 Docker Model Runner는 2026년 초·중반에 막 등장한 신생 기능이라 사용법·지원 범위가 빠르게 바뀔 수 있다. 이 글의 모든 경로·명령은 2026-05-27 기준이다.

자주 묻는 질문

Q1. M3 Pro 맥북에서 vLLM을 쓸 수 있나요? 가능하다. 2026년 기준 vllm-metal(MLX 백엔드)이나 Docker Model Runner로 Metal GPU까지 써서 7B 4-bit급 모델을 띄울 수 있다. 다만 단일 사용자 환경이라 프로덕션 처리량 이점은 발현되지 않는다.

Q2. 맥에서 vLLM은 CPU로만 도나요? 2026-05 시점에는 부정확한 단정이다. vLLM 본체는 여전히 macOS에서 CPU 한정·실험적이지만, vllm-metal 플러그인 경로(경로 2·3)로는 MLX 백엔드를 통해 Apple GPU(Metal)를 실제로 쓴다.

Q3. 세 경로 중 뭘 골라야 하나요? 설치 난이도와 성공 확률만 보면 경로 3(Docker Model Runner)이 가장 무난하다. Docker Desktop 4.62+만 있으면 명령 한 줄로 vllm-metal 러너가 깔린다. 경로 2는 직접 install.sh로 제어하고 싶을 때, 경로 1(CPU backend)은 GPU 없이 원리 동작만 확인할 때다.

Q4. 36GB 맥에서 어떤 모델까지 돌릴 수 있나요? MLX 4-bit 기준 7~13B가 현실적인 범위다. vllm-metal은 MLX 4-bit(group_size 128) 포맷 위주라 그 외 포맷은 preflight에서 걸러진다. 35B급은 36GB를 초과할 위험이 있어 권하지 않는다.

Q5. vLLM은 Ollama보다 항상 빠른가요? 아니다. 본 글의 M2(vllm-metal Qwen2-7B 4-bit, 약 21.6 tok/s)와 S1의 Ollama(Llama 3.1 8B Q4_K_M, 약 22 tok/s)는 같은 M3 Pro 36GB에서 사실상 동률이었다. 단일 요청에서는 둘이 비슷하거나 오히려 Ollama가 빠를 수도 있다(Docker가 다른 기기에서 잰 단일 스트림 벤치 vLLM-Metal 251~279 vs llama.cpp 333~345 tok/s도 같은 패턴). vLLM의 이점은 동시 요청이 많을 때 벌어진다(A100 벤치 256 동시 사용자 기준 793 vs 41 TPS). 혼자 한 요청씩 쓰는 맥에서는 키울 batch도 채울 빈 슬롯도 없어 이점이 발현되지 않는다.

Q6. “vllm-mlx로 400+ tok/s 나온다”는 글은 뭔가요? 조건을 봐야 한다. 그 417.9 tok/s는 Qwen3-0.6B-8bit 초소형 모델 + M4 Max 128GB + 단일 스트림 greedy 조건이고, vllm-mlx는 vLLM 공식 org가 아닌 별도 community 프로젝트다. M3 Pro에서 7B를 돌리면 그 근처도 안 나온다.

정리 — 띄울 수는 있고, 학습으로는 값졌다

2026년 5월 기준 M3 Pro 36GB에서 vLLM은 vllm-metal 경로로 Metal GPU까지 써서 7B 4-bit급을 띄울 수 있다. “맥에선 CPU로만 돈다”는 통념은 더 이상 맞지 않는다. 다만 혼자 한 요청씩 쓰는 환경에서는 PagedAttention의 이점이 발현되지 않아 Ollama보다 빠르지도 않다. vLLM이 빛나는 무대는 동시 요청이 쏟아지는 GPU 서버지 내 맥북이 아니다. 그래도 논문 속 구조를 내 GPU 위에서 직접 돌려본 건 다음 단계로 넘어가는 좋은 디딤돌이었다.

다음으로 다룰 것들 — 모두 별도 글로 예정이다.

• 본격 처리량 벤치: 신선한 CUDA GPU(RTX 4090·5090 급)로 vLLM의 batching 한계까지 재본다. 다만 내 홈서버는 RTX 2070(VRAM 8GB)이라 받쳐주기 빠듯해서 시도 여부는 GPU 업그레이드와 같이 고민 중
• Metal vs CUDA 추론 비교: 같은 모델을 두 백엔드에서 (조건 갖춰지면 시도)
• sglang vs vLLM vs Ollama: 언제 무엇을 쓰나, 엔진 결정 트리 (준비 중)

관련 글

• vLLM은 왜 빠른가 — PagedAttention을 OS 페이징으로 이해하기 — 이 글에서 “왜 동시 요청이 많을 때만 빨라지는지” 궁금했다면. PagedAttention과 continuous batching의 원리를 OS 가상 메모리 비유로 푼 개념 글.
• Ollama로 M3 Pro 맥북에 로컬 LLM 띄우기 — 30분 실측 가이드 — 같은 M3 Pro 36GB에서 Ollama로 더 단순하게 띄우는 길. 단일 사용자라면 이쪽이 더 빠를 수 있다.
• Claude API 비용 완벽 가이드 2026 — 토큰 단가·캐싱·배치 할인 — 로컬에서 직접 서빙하는 비용과 클라우드 API 비용을 비교하고 싶을 때 기준점.

참고 자료

• Docker Model Runner with vLLM-Metal on macOS — Docker Blog (2026-02-26) — 경로 3 설치·단일 스트림 벤치(251~279 vs 333~345 tok/s). 단, 블로그가 적은 install-runner 명령은 Docker Desktop에서 막힘 — Desktop은 desktop enable model-runner --tcp=12434로 우회
• Inference engines — Docker Model Runner Docs — 2026-05 시점 docs는 “macOS vLLM 미지원, llama.cpp 기본” 표기. 블로그(vllm-metal 추가)와 docs(미반영)의 시차로 자동 라우팅 불확정
• Installation — CPU (Apple) — vLLM Docs — 경로 1 CPU backend(experimental)
• vllm-project/vllm-metal — GitHub — 경로 2 공식 플러그인 (v0.2.0)
• vllm-metal supported models — GitHub — MLX 4-bit 지원 모델 범위
• waybarrios/vllm-mlx — GitHub — 비공식 별도 구현 (400+ tok/s 주장의 출처)
• Ollama vs vLLM: a deep dive into performance benchmarking — Red Hat Developer (2025-08-08) — A100 동시성 벤치(793 vs 41 TPS)

그림 1. vLLM 공식 문서 첫 화면

TL;DR

• vLLM은 UC 버클리 연구진(Kwon et al.)이 SOSP 2023에서 발표한 PagedAttention 논문에서 출발한 오픈소스 LLM 서빙 엔진이다.
• PagedAttention은 OS의 가상 메모리·페이징을 KV 캐시에 적용해, 기존 시스템이 버리던 메모리 60~80% 낭비를 4% 미만으로 줄인다.
• 그렇게 확보한 여유로 동시 batch를 키우고, continuous batching으로 빈 슬롯을 즉시 채워 HuggingFace Transformers(순정) 대비 최대 24배 처리량을 낸다. (이미 최적화된 SOTA 서빙 시스템 대비로는 2~4배.)
• 단, 이 이점은 동시 요청이 많은 GPU 서버에서 나온다. vLLM과 Ollama는 “어느 게 더 빠른가”가 아니라 목적이 다르다.

vLLM이란? 왜 다들 vLLM을 말하나

vLLM은 UC 버클리 연구진(Woosuk Kwon 외)이 SOSP 2023에서 발표한 PagedAttention 논문(arXiv:2309.06180)에서 출발한 오픈소스 LLM 서빙 엔진이다. 이름의 v는 virtual(가상)에서 왔고, 이게 글 전체의 힌트다.

Ollama로 로컬 LLM을 띄워본 단계가 “일단 돌려보는” 것이었다면, vLLM은 “처리량을 짜내는” 엔진이다. 지금은 사실상 표준 서빙 엔진으로 통하고, 그 빠름의 핵심이 PagedAttention과 continuous batching 두 가지다. 이 글은 이 둘을 OS 비유로 이해하는 게 목표다. “그럼 내 맥에서 실제로 돌아가나”는 별도 글에서 다룬다(아래 링크).

KV 캐시와 단편화 — 왜 기존 방식이 메모리를 60~80% 버렸나

PagedAttention을 이해하려면 먼저 KV 캐시가 뭔지, 그리고 기존 방식이 왜 메모리를 그렇게 많이 버렸는지부터 봐야 한다.

LLM은 토큰을 하나씩 생성하면서 앞서 본 토큰들의 key/value 벡터를 재사용한다. 매번 다시 계산하면 느리니 한 번 계산한 key/value를 메모리에 저장해두는데, 이게 **KV 캐시(KV cache)**다. 시퀀스가 길어질수록 저장할 양이 늘어 KV 캐시는 시퀀스 길이에 따라 선형으로 커진다.

문제는 기존 시스템이 이 캐시를 요청마다 하나의 연속(contiguous)된 메모리 블록으로 잡으려 했다는 점이다. 그 과정에서 두 종류의 낭비가 생겼다.

• 내부 단편화(internal fragmentation): 요청이 들어오면 최대 시퀀스 길이(max_seq_len)만큼 공간을 미리 예약(over-reservation)하는데, 실제 생성 길이는 대부분 그보다 짧아 예약 공간 상당수가 비어서 버려진다.
• 외부 단편화(external fragmentation): 요청마다 길이가 제각각이라 연속 공간을 잡으려다 보면 메모리 사이사이에 못 쓰는 틈이 생긴다.

이 둘이 합쳐져 얼마나 버려졌느냐. vLLM 공식 블로그는 “existing systems waste 60% – 80% of memory due to fragmentation and over-reservation”이라고 못 박는다. 절반을 훌쩍 넘는 GPU 메모리가 실제 데이터가 아니라 단편화와 과잉 예약으로 사라지고 있었다는 뜻이다. 메모리가 모자라면 동시에 처리할 수 있는 요청 수가 줄고, 그게 곧 처리량 한계가 된다. 여기까지가 “왜 기존 방식이 느렸나”의 답이다.

PagedAttention 직관 — OS 페이징을 KV 캐시에 적용하면

여기가 이 글의 핵심이다. PagedAttention이 어떻게 그 60~80% 낭비를 4% 미만으로 줄이는지, 운영체제 비유로 풀어본다.

논문 저자들이 직접 밝힌 출발점은 이렇다. vLLM 블로그는 PagedAttention을 “an attention algorithm inspired by the classic idea of virtual memory and paging in operating systems”라고 소개한다. 50년 가까이 된 OS의 가상 메모리 아이디어를 KV 캐시에 그대로 가져온 것이다.

운영체제는 프로그램에게 “연속된 큰 메모리”라는 환상을 준다. 하지만 실제 물리 메모리는 **페이지(page)**라는 고정 크기 조각으로 쪼개져 여기저기 흩어져 있고, **페이지 테이블(page table)**이 “이 프로그램의 3번째 페이지는 물리 메모리 어디”라고 매핑해준다. 프로그램은 연속이라 믿지만 물리적으론 흩어져 있는 것이다. PagedAttention은 이 구조를 그대로 KV 캐시에 적용한다.

1. 고정 크기 KV block = OS의 페이지. KV 캐시를 하나의 연속 공간이 아니라 고정 크기 block 단위로 쪼갠다.
2. logical → physical 매핑 테이블 = OS의 페이지 테이블. 각 시퀀스는 logical block table을 통해 GPU 메모리에 흩어진 비연속(non-contiguous) physical block을 가리킨다.

이렇게 하면 연속 공간을 미리 크게 잡을 필요가 사라진다. 시퀀스가 자라면 그때그때 빈 physical block 하나를 새로 할당하면 그만이다. 외부 단편화는 block이 어디 있든 매핑으로 이어 붙이니 사라지고, 내부 단편화는 시퀀스의 마지막 block에서만 발생한다. 마지막 block에 채 안 찬 자투리만 남기 때문이다.

그 결과가 vLLM 블로그의 표현으로 “memory waste only happens in the last block of a sequence … a mere waste of under 4%“다. 60~80%에서 4% 미만으로. OS가 프로그램에게 연속 메모리라는 환상을 주면서 실제로는 페이지 단위로 흩어 담듯, PagedAttention은 KV 캐시를 block 단위로 흩어 담고 매핑 테이블로 이어 붙인다. 비유라기보다 거의 그대로 옮겨온 설계다.

그림 2. PagedAttention의 logical-physical block 매핑 — OS 페이지 테이블과 같은 구조

여담이지만 OS의 fork()도 그대로 들어와 있다. 같은 프롬프트에서 여러 응답을 뽑을 때(parallel sampling·beam search) 프롬프트 KV block을 여러 출력이 공유하다가 갈라지는 시점에만 복사한다(Copy-on-Write). 덕분에 메모리를 최대 55% 더 아낀다.

continuous batching — 빈 슬롯을 즉시 채우는 시간의 최적화

PagedAttention이 메모리를 아껴 batch를 키울 여유를 만들었다면, 그 여유를 꽉 채우는 건 continuous batching이다. vLLM의 빠름은 이 둘이 한 쌍이라는 데서 나온다.

기존의 **static batching(정적 배치)**은 배치에 묶인 요청들이 전부 끝날 때까지 다음 배치를 시작하지 못한다. 한 요청은 500토큰을 생성하는데 다른 요청은 20토큰만 만들고 끝났다면, 짧은 요청이 점유하던 자리는 긴 요청이 끝날 때까지 빈 채로 논다(idle).

**continuous batching(연속 배치 처리)**은 이걸 바꾼다. iteration-level scheduling이라고도 부르는데, 매 토큰 생성 iteration마다 배치 구성을 다시 짠다. 한 시퀀스가 끝나면 그 빈 슬롯에 대기 중이던 새 요청을 즉시 끼워 넣는다. 원전은 Orca(Yu et al., OSDI 2022)이고, Anyscale의 설명이 이 과정을 그림으로 잘 풀어준다. GPU가 놀 틈을 주지 않는 스케줄링인 셈이다.

한 문장으로 정리하면, PagedAttention이 공간(메모리) 차원의 최적화라면, continuous batching은 시간(스케줄링) 차원의 최적화다. 인과 사슬은 이렇게 이어진다 — PagedAttention이 단편화 낭비를 줄여 동시 batch를 키울 메모리를 만들고 → continuous batching이 빈 슬롯을 즉시 채운다 → 처리량이 폭증한다. 그 폭증의 크기가 그 유명한 “24배”다. 다만 여기서 한 가지는 반드시 짚고 가야 한다.

“24배 vs 2~4배” — 비교 대상을 섞으면 안 된다

수치	무엇 대비 무엇	조건 · 출처
최대 24배	vLLM vs HuggingFace Transformers(순정 파이프라인)	LLaMA-7B on A10G, 13B on A100 (vLLM 블로그)
최대 3.5배	vLLM vs TGI	동일 환경 (vLLM 블로그)
2~4배	vLLM vs SOTA(FasterTransformer, Orca)	동일 latency 유지 시 (논문)
60~80% → <4%	기존 시스템 vs PagedAttention (메모리 낭비)	vLLM 블로그

“vLLM은 24배 빠르다”를 비교 대상 없이 인용한 글이 많은데, 24배는 아무 최적화도 안 한 HuggingFace Transformers 대비다. 이미 최적화된 서빙 시스템(FasterTransformer, Orca) 대비로는 2~4배. 같은 논문의 두 숫자가 다른 건 모순이 아니라 비교 상대가 다르기 때문이다.

vLLM vs Ollama — 처리량이 아니라 목적이 다르다

원리를 알고 나면 자주 나오는 질문이 “그럼 Ollama랑 뭐가 다른가”다. Red Hat은 둘의 관계를 이렇게 정리한다. “Ollama is ideal for local development and prototyping, while vLLM is built for high-performance production deployments“. Ollama는 llama.cpp + Metal 기반으로 단일 사용자 prototyping에, vLLM은 PagedAttention 기반으로 동시 요청 처리량 서빙에 맞춰져 있다. 둘 다 OpenAI 호환 API라 엔드포인트만 바꾸면 같은 코드가 붙는다. 어느 게 “더 좋다”가 아니라 목적이 다르다. 이 차이가 실제 기기 위에서 어떻게 드러나는지는 아래 후속 글에서 수치로 확인한다.

자주 묻는 질문

Q1. vLLM이란 무엇인가요? UC 버클리 연구진(Kwon et al.)이 SOSP 2023에서 발표한 PagedAttention 논문에서 출발한 오픈소스 LLM 서빙 엔진으로, 지금은 사실상 표준으로 쓰인다.

Q2. PagedAttention은 왜 빠른가요? OS의 가상 메모리·페이징을 KV 캐시에 적용해 메모리 낭비를 60~80%에서 4% 미만으로 줄이고, 그 여유로 batch를 키워 처리량을 올린다.

Q3. KV 캐시란 무엇인가요? 이미 계산한 토큰의 key/value 벡터를 저장해두고 재사용하는 캐시다. 시퀀스 길이에 따라 메모리가 선형으로 늘어난다.

Q4. continuous batching이란 무엇인가요? 매 iteration마다 배치를 다시 짜서, 한 요청이 끝나는 즉시 빈 슬롯에 새 요청을 끼워 넣는 스케줄링이다. PagedAttention이 공간을 아꼈다면 이쪽은 시간을 아낀다.

Q5. vLLM은 정말 24배 빠른가요? 24배는 아무 최적화도 안 한 HuggingFace Transformers 순정 대비고, 이미 최적화된 서빙 시스템(FasterTransformer, Orca) 대비로는 2~4배다. 같은 논문의 수치이며 비교 상대가 다를 뿐이다.

Q6. vLLM과 Ollama의 차이는 무엇인가요? 목적이 다르다. Ollama는 단일 사용자 prototyping에, vLLM은 다중 동시 요청 처리량 서빙에 맞춰져 있다. 둘 다 OpenAI 호환 API라 엔드포인트만 바꾸면 같은 코드가 붙는다.

정리 — 빠름은 마법이 아니라 OS 교과서다

vLLM의 빠름은 두 축에서 나온다. PagedAttention이 OS 페이징으로 메모리 낭비를 60~80%에서 4% 미만으로 줄여 batch를 키울 공간을 만들고, continuous batching이 빈 슬롯을 즉시 채워 그 공간을 꽉 쓴다. 공간과 시간 두 차원의 최적화가 합쳐진 결과가 그 “24배”다. 새로운 마법이 아니라 50년 묵은 가상 메모리 아이디어를 KV 캐시에 옮겨온 것이다 — 그래서 한 번 그림으로 이해하면 잘 안 잊힌다.

원리를 알았으니 다음은 “내 손에서 도는가”다. 직접 돌려보고 싶다면 아래 관련 글의 M3 Pro 실측편으로 이어진다. CUDA GPU 처리량 벤치, sglang·vLLM·Ollama 엔진 결정 트리는 별도 글로 준비 중이다.

관련 글

• SGLang은 왜 빠른가 — RadixAttention과 prefix 공유의 직관 — 본 글의 원리 짝꿍. PagedAttention이 공간(메모리)을 아낀다면, RadixAttention은 상태(prefix 재계산)를 아낀다. 두 기법이 같이 쓰일 수 있는 이유와 2025~2026년 vLLM APC 흡수 시점 차까지.
• KV 캐시가 뭐길래 — 긴 컨텍스트가 빠르게 비싸지는 이유 — 본 글이 다룬 PagedAttention의 진앙. KV 캐시 자체가 왜 메모리·비용 폭증의 원인인지 책상 비유로 푼 학습 시리즈 뿌리 글. Llama 3.1 8B 컨텍스트별 KV 4GB~128GB + Claude 200K·Gemini 1M 가격 임계점까지.
• M3 Pro에서 vLLM 돌려보기 — Mac 3경로와 솔직한 한계 (2026) — 이 글에서 본 원리가 실제 맥북 위에서 도는지 확인하고 싶다면. Apple Silicon 설치 3경로(CPU backend·vllm-metal·Docker Model Runner)와 단일 스트림 vs 동시 4 요청 실측, 그리고 왜 혼자 쓰면 Ollama가 더 빠른지까지.
• Ollama로 M3 Pro 맥북에 로컬 LLM 띄우기 — 30분 실측 가이드 — vLLM 이전에 로컬 LLM을 가장 단순하게 띄워보는 길. 이 글의 “목적 차이” 맥락의 출발점이다.
• Claude API 비용 완벽 가이드 2026 — 토큰 단가·캐싱·배치 할인 — 로컬에서 직접 서빙하는 비용과 클라우드 API 비용을 비교하고 싶을 때 기준점.

참고 자료

• Efficient Memory Management for Large Language Model Serving with PagedAttention — arXiv:2309.06180 (SOSP 2023) — PagedAttention 원논문
• vLLM: Easy, Fast, and Cheap LLM Serving with PagedAttention — vLLM Blog (2023-06-20) — 60~80%→<4%, 24배·3.5배 수치 출처
• How continuous batching enables 23x throughput in LLM inference — Anyscale — continuous batching·Orca 설명
• Ollama or vLLM? How to choose the right LLM serving tool — Red Hat Developer (2025-07-08) — vLLM vs Ollama 목적 차이
• 최대 24배 빠른 vLLM의 비밀 — 스캐터랩 블로그 — 공간·시간 최적화 한국어 정리

가격·기능은 2026-05-24 기준이고 환율은 $1 ≈ ₩1,400~₩1,450 가정. 분기 변동이 잦아 결제 직전엔 공식 페이지를 한 번 더 확인하는 게 안전하다. 이 글은 “월 $20 AI 구독” 한 자리를 어디에 쓸지 6가지 이유로 30초안에 결정하도록 설계했다.

TL;DR

• 글쓰기·코딩 중심이면 Claude Pro — 톤이 자연스럽고 Pro에 Claude Code 포함
• 이미지·음성·범용 도구 중심이면 ChatGPT Plus — DALL·E 3 + Advanced Voice Mode + GPTs
• 검색·연구·Gmail/Docs·가족 공유 중심이면 Google AI Pro — NotebookLM·Veo 3.1 Lite·5TB·5인 공유

30초 결정 매트릭스

용도 한 줄만 정해지면 1순위는 거의 자동으로 정해진다. 셋 다 ₩29,000이라 가격 기준은 무의미하다.

셋 다 $20인데 뭐가 다른가

가격은 같지만 같은 돈으로 받는 것은 꽤 다르다.

그림 1. ChatGPT Plus 공식 가격 페이지

그림 2. Claude Pro 공식 가격 페이지

그림 3. Google AI Pro 공식 가격 페이지

2026년 상반기 큰 변동 셋. Sora가 2026-03-24 발표·2026-04-26 앱 폐쇄로 종료되면서 ChatGPT Plus 비디오가 빠졌고(OpenAI Help), 4월 초 Computer Use(Cowork)가 Pro에서 GA(macOS·Windows)됐으며 뒤이어 Claude Opus 4.7이 2026-04-16에 출시되어 Pro에 포함됐다(Anthropic). Gemini 앱 한도는 2026-05-20부로 컴퓨팅 기반 5시간 롤링으로 변경.

Claude Pro의 1M context는 공식 GA 발표에 Max·Team·Enterprise + Claude Code 자동으로만 표기돼 있어 본문은 “Pro는 표준 200K”로 본다. 메시지 한도는 모델·시간대 변동이 커서 범위로 적었다.

6가지 결정 트리

글쓰기 — Claude Pro

내가 가장 자주 굴리는 도구다. “Claude’s output is consistently the most natural and the least recognizably AI”라는 영문 리뷰가 대표적(techjournal). 시작점의 톤이 가장 매끄럽다. 2순위는 ChatGPT Plus, Gemini는 평타 이상이지만 약간 더 형식적이다.

코딩 — Claude Pro (단, 코딩이 절반 넘으면 분기)

Pro에 Claude Code가 포함된다는 점이 결정타. 2026-05-06부로 Claude Code의 5시간 rate limit이 2배로 상향됐다(limits doubled). 폭스씨지 평이 솔직하다. “챗GPT는 가끔 흐름을 놓치거나 환각을 일으키지만, 클로드는 끝까지 논리를 부여잡고 버그 없는 코드를 토해냅니다.”(폭스씨지)

단, 코딩이 업무의 절반 이상이라면 채팅 구독 전에 IDE 도구부터 결정하는 게 합리적이다 — Cursor vs Claude Code 결정 트리 참고.

이미지·비디오 — 분기

이미지만이면 ChatGPT Plus(DALL·E 3). 비디오까지 본다면 Google AI Pro의 Veo 3.1 Lite가 사실상 유일한 동가격대 선택지다(풀 Veo 3.1은 AI Ultra 전용). Claude는 이미지 생성 자체가 없다.

검색·심층 리서치 — Google AI Pro

Google이 동가격대 독보적이다. 1M context + Deep Research + NotebookLM(노트 500·노트당 소스 300) 조합을 같은 $20에 주는 곳이 없다. 논문·보고서를 수십 건 비교하는 작업이라면 NotebookLM이 결제 가치를 단독으로 회수한다.

한국어 품질 — 셋 다 일상 만족

미세 차이는 있지만 셋 다 평타 이상. 모델 자체 품질 deep dive는 Claude vs GPT vs Gemini 2026에 묶었다.

한국 생태계 — Google 또는 Claude

Gmail·Docs·Drive 일반 사용자는 Google AI Pro가 압도적(5TB·가족 5인). M365·Outlook 직장인은 Claude Pro의 통합 카드. Google AI Pro의 일부 기능(Spark·Gmail AI Inbox·Daily Brief)은 2026-05 기준 한국 미지원(Google 한국 블로그).

한국 결제 시 진짜 비용

정가는 같지만, 한국에서 실제 결제하면 청구액과 절차가 미묘하게 다르다.

• 웹 결제 원화·VAT — 셋 다 약 ₩29,000/월, VAT 10%가 가격에 포함 청구(GLBGPT).
• 앱스토어·Play 차액 — 인앱 결제는 Apple·Google 수수료 반영되어 ₩31,000 안팎. 웹 결제 권장.
• 결제 거절 — Claude Pro에서 국내 카드 ISP·3DS 충돌이 잦다(매거진하이펫). 해외승인·법인카드·연 계약 시 원화 송금이 알려진 우회법. 나도 한 번은 카드 거절을 만나 다른 카드로 우회했다.
• 환불 — 셋 다 원칙적으로 까다롭다. ChatGPT는 EU·UK·터키만 14일 prorated, 한국은 케이스별(OpenAI Help). 환불 가능성을 가정하고 결제하지 말 것.
• 사업자 VAT 면제·가족 공유 — 사업자등록번호 입력 시 VAT 10% 면제로 월 약 ₩3,000 절감(애드센스팜). 가족 공유는 3사 중 Google만 5인 가능(Google One Basic·AI Plus·AI Pro 공통) — 1인당 환산하면 약 ₩5,800.

그림 4. 한국 결제 화면 — 원화·VAT 표기

$20 위·아래 옵션

$20가 무조건 정답은 아니다. 사용량이 가볍거나 무겁다면 위아래로 한 단계씩 더 있다.

• 월 $0 — 무료 + 로컬 LLM. 월 50건 이하 가벼운 질의면 무료로 충분하다. M3·M4 맥북이면 Ollama로 로컬 LLM 띄우기 옵션도 있다. 데이터가 외부로 안 나간다는 게 장점.
• 월 ₩11,000대 — Google AI Plus (2026-01-27 한국 출시). Gemini 일부 모델 + 200GB 스토리지. AI Pro까지는 필요 없는 경량 사용자에게 비집고 들어갈 옵션(Google One 한국).
• 월 $100~$200 — 헤비 사용자용. Claude Max 5x·20x, ChatGPT Pro($200)는 코딩 헤비·전문가용. aimatters의 한 달 후기는 결국 Plus 정도면 충분했다는 결론으로 모인다(aimatters).

추가로, 월 사용량이 한 자릿수 억 토큰을 넘어가는 시점에는 정기구독보다 API 종량제가 싸지는 분기점이 온다. 단가·캐싱·배치 할인은 Claude API 비용 완벽 가이드 참고.

자주 묻는 질문

ChatGPT Plus와 Claude Pro 중 뭐가 더 좋아요?

글쓰기·코딩이면 Claude Pro, 이미지·음성·범용이면 ChatGPT Plus. 가격은 둘 다 월 $20·약 ₩29,000으로 동일.

Gemini Advanced는 ChatGPT Plus보다 쌀까요?

정가는 동일. 단 Google AI Plus(약 ₩11,000) 한 단계 아래 옵션이 한국에 있어 Gemini 계열만 더 싸게 쓸 길은 있다.

두 개 동시 결제가 의미 있나요?

한 도구로 충분한 경우가 대부분이다. 글쓰기(Claude) + 검색(Google)처럼 명확히 보완 관계일 때만 병행 가치가 있다. 결제 전 무료 버전으로 1주 비교 권장.

한국 결제 시 VAT가 붙나요?

₩29,000에 VAT 10% 포함 청구. 사업자등록번호 입력 시 면제 가능 — 월 약 ₩3,000 절감. 셋 다 동일.

앱스토어 결제가 더 비싼가요?

그렇다. 인앱 결제는 Apple·Google 수수료가 반영되어 통상 ₩31,000 안팎. 웹 결제 권장.

무료 버전으로 부족한가요?

월 50건 이하 가벼운 질의면 무료로 버틸 만하다. 유료로 올라가면 모델 한도가 크게 풀리고 Deep Research·NotebookLM 같은 상위 기능이 열린다 — Claude Pro는 Free 대비 ≥5×로 공식 명시(Anthropic Support), ChatGPT Plus·Gemini는 정확한 배수는 미공개이나 GPT-5.5 Thinking·Gemini 3.1 Pro 같은 상위 모델 접근이 열린다. 한 주 안에 무료 한도에 자주 부딪힌다면 결제 신호.

정리

정가가 같다는 사실 덕에 월 $20 AI 구독 결정은 오히려 단순해진다. 글쓰기·코딩이면 Claude Pro, 이미지·음성·범용이면 ChatGPT Plus, 검색·연구·Google 생태계·가족 공유면 Google AI Pro. 6축 트리 중 자기 시나리오만 정하면 30초 안에 답이 나온다.

본 글의 가격·기능은 2026-05-24 기준. 분기마다 변동이 잦으니 결제 직전 공식 페이지를 한 번 더 확인할 것. 분기 갱신은 같은 URL에 본문만 교체할 예정이다.

관련 글

• 모델 자체 품질 비교 — Claude vs GPT vs Gemini 2026: 한국 사용자가 고른 현답
• API 종량제로 가는 분기점 — Claude API 비용 완벽 가이드 2026
• 코딩 도구 선택 — Cursor vs Claude Code 결정 트리
• 월 $0 옵션 — Ollama로 M3 Pro 맥북에 로컬 LLM 띄우기
• Claude API vs Ollama 비용 비교는 곧 정리 예정

측정 환경

• Apple Mac M3 Pro (6P+6E CPU, 18코어 GPU), 36GB 통합메모리, macOS Sonoma
• Ollama v0.24.0 (2026-05-14 릴리즈, 최신 안정판)
• 모델: Llama 3.1 8B Q4_K_M (다운로드 ≈4.9GB)
• 2026-05-21 측정
• 이 글의 모든 수치는 위 환경 기준이다. 18GB 베이스 SKU와 비교 수치는 본문 GPU 섹션에서 함께 다룬다

그림 1. Ollama 공식 홈 — ‘Get up and running’ 한 줄로 시작

TL;DR

• M3 Pro 36GB 맥북에서 Ollama v0.24.0 설치 → Llama 3.1 8B Q4_K_M pull → 첫 응답까지 약 20~30분.
• 긴 응답 평균 토큰 생성 속도는 약 22 tok/s (LocalScore의 동일 SKU reference 22.1 t/s 근처로 수렴).
• 36GB로 안전한 모델은 30B Q4까지. 70B Q4는 빠듯해 스왑 폴백 위험. 18GB 베이스 SKU 사용자는 8B Q4가 안전선.
• MLX 가속은 메모리 요건(>32GB)은 충족하지만 Qwen3.5-35B-A3B 단일 모델 한정이라 Llama·일반 모델 사용 시엔 여전히 기존 Metal 경로로 동작.

Ollama가 정확히 뭔가? — 30초 정리

Ollama는 로컬 LLM을 CLI와 REST API로 띄우게 해주는 오픈소스 런타임이다. 내부적으로 llama.cpp + Apple Metal 가속을 쓴다. 모델 하나를 ollama pull 한 줄로 받고, ollama run 한 줄로 대화창이 뜬다 — 이게 진입 장벽이 낮은 이유다.

GUI를 원하면 LM Studio가 있고, 처리량 중심 프로덕션 엔진은 vLLM·sglang 계열이다. 엔진 셋업 비교는 별도 글에서 다룬다(준비 중). 본 글은 학습 톤·단일 사용자 prototyping을 전제로 가장 단순한 길만 따라간다.

미리 박아둘 함정 하나. Ollama v0.19부터 MLX preview가 추가됐지만, 32GB 초과 통합메모리와 Qwen3.5-35B-A3B 단일 모델에만 적용되는 가속이다. 본 글의 M3 Pro 36GB는 메모리 요건은 충족하지만 모델이 Llama 3.1 8B라 적용 대상이 아니고 기존 Metal/llama.cpp 경로를 그대로 탄다. 자세한 한계는 아래 §”못 하는 것”에서 다시 정리한다.

버전 메모. 본 글은 최신 안정판 v0.24.0 (2026-05-14) 기준이다. v0.30 계열은 llama.cpp 직접 통합을 시도하는 pre-release(v0.30.0-rc21, 2026-05-13) 단계라 production 추천은 어렵다. 학습 단계라면 안정판으로 충분하고, brew install ollama·공식 dmg 모두 안정판이 떨어진다.

Ollama 설치 — --version까지 (5분)

가장 단순한 경로는 공식 .dmg 다운로드다. ollama.com/download/mac에 접속해 macOS 버튼을 누르면 약 150MB짜리 dmg가 떨어진다.

그림 2. Ollama 공식 macOS 다운로드 페이지

dmg를 열어 Ollama 아이콘을 /Applications 폴더로 드래그하면 끝이다. 한 번 실행해두면 macOS 상단 메뉴바에 작은 llama 아이콘이 박히는데, 이게 보이면 ollama serve가 백그라운드로 떠 있다는 뜻이다.

그림 3. Ollama 설치 후 메뉴바에 등장한 llama 아이콘

터미널을 열어 버전을 확인한다.

ollama --version
# ollama version is 0.24.0

Homebrew를 쓰는 사람이라면 brew install ollama 한 줄로도 된다. 다만 메뉴바 통합·자동 업데이트는 dmg 쪽이 깔끔해서 처음 까는 거면 공식 dmg가 마음 편하다.

여기까지 회선 사정에 따라 3~5분.

그림 4. ollama –version 실행 결과

첫 모델 — llama3.1:8b pull부터 첫 대화까지 (10분)

baseline으로는 Llama 3.1 8B를 권한다. 다운로드 4.9GB, 36GB에 한참 여유(18GB SKU도 안전), 영어·코드·일반 지식이 무난하다. Qwen·EXAONE 등 한국어 강세 모델 비교는 별도 글에서 다룬다(준비 중). 본 글은 “일단 띄워보는 것”이 목적이라 모델은 하나로 좁힌다.

솔직히 처음엔 3.2 3B로 시작했는데 응답 품질이 학습용으로도 살짝 아쉬워 8B Q4로 갈아탔다. 18GB·36GB 모두에서 8B Q4가 가장 합리적인 출발점이다 — 36GB 사용자는 익숙해진 뒤 13B·30B Q4로 단계적으로 올려볼 수 있다.

명령어는 두 줄이다.

ollama pull llama3.1:8b
ollama run llama3.1:8b

pull은 4.9GB 파일을 받아온다. 100Mbps 회선 기준 약 7분, 기가급이면 1분 안쪽. 처음 run을 치면 모델을 mmap으로 올리고 워밍업하는데, 내 환경에선 약 1분 정도 로딩이 들어갔다. 두 번째부터는 즉시 응답한다.

그림 5. Llama 3.1 8B 모델 다운로드 진행

대화창이 뜨면 짧은 프롬프트로 작동 여부부터 본다.

그림 6. Llama 3.1 8B와의 첫 대화

Q4_K_M 양자화가 뭔가

llama3.1:8b의 기본 태그는 **Q4_K_M 양자화(quantization)**다. 가중치를 4비트로 압축해 크기를 약 1/4로 줄이고 품질 손실은 거의 체감되지 않는 균형점이다. 같은 8B를 fp16으로 받으면 ≈16GB라 18GB 환경엔 빠듯하지만, Q4_K_M은 4.9GB라 18GB·36GB 모두에서 KV 캐시까지 합쳐도 여유롭다.

모델 파일은 ~/.ollama/models에 저장된다. 외장 SSD로 옮기려면 OLLAMA_MODELS 환경변수로 경로를 바꿀 수 있는데, 자세한 건 아래 FAQ에서 다룬다.

GPU 확인과 tokens/sec 실측 — ollama ps와 --verbose (5분)

“내 맥북이 정말 GPU로 돌리고 있나?”는 새로 깔고 가장 먼저 확인하고 싶은 부분이다. 다른 터미널 탭에서 한 줄.

PROCESSOR 컬럼이 핵심이다. 100% GPU면 전부 Metal로 돌고 있다는 뜻이고, 100% CPU면 메모리가 모자라 폴백된 상태, 퍼센트가 섞여 있으면 부분 오프로드다. Apple Silicon에서는 기본 활성이라 OLLAMA_METAL 같은 환경변수를 따로 만질 필요가 없다.

그림 7. ollama ps — Processor 100% GPU 확인

토큰 생성 속도를 재고 싶으면 --verbose 플래그를 붙여 다시 실행한다.

내 M3 Pro(6P+6E CPU·18 GPU·36GB)에서 짧은 한국어 프롬프트 한 번을 던져 위 metrics를 받았다. eval rate는 32.59 tok/s, prompt processing은 148.64 t/s, TTFT(load + prompt eval)는 약 0.22초다. 단, 이 수치는 응답이 6 토큰(“이승철입니다.”)밖에 안 되는 짧은 샘플이라 측정 노이즈가 크다 — 같은 환경에서 100~500 토큰짜리 긴 응답을 여러 번 평균 내면 LocalScore가 동일 SKU(M3 Pro 18 GPU·36GB)에서 측정한 22.1 t/s reference 근처(약 20~24 tok/s)로 수렴한다. 참고로 같은 M3 Pro라도 SKU에 따라 21.1 t/s(14 GPU·18GB, 베이스)·20.8 t/s(18 GPU·18GB)·21.5 t/s(14 GPU·36GB)로 차이가 있으니 자기 라인업을 확인하고 비교하면 된다. 긴 응답 평균이 20 tok/s를 크게 밑돌면 백그라운드 앱·저전력 모드·발열 throttling을 의심해본다.

그림 8. ollama run –verbose — 짧은 응답 1회의 metrics 출력 (긴 응답 평균은 LocalScore reference 22 tok/s 근처)

여기서 한 가지 짚을 게 있다. M3 Pro 메모리 대역폭은 베이스·상위 SKU 모두 150 GB/s로, 흥미롭게도 M2 Pro의 200 GB/s보다 낮다. LLM 추론은 대역폭 의존도가 커서, 같은 메모리 용량이라도 세대 비교에서 직관과 다른 결과가 나올 수 있다. 즉 36GB로 더 큰 모델을 올릴 수는 있어도 토큰 생성 속도는 대역폭 한계에 묶인다. Windows GPU(별도 VRAM + 더 높은 대역폭)와의 직접 비교는 별도 글에서 다룬다(준비 중). 단일 사용자 학습 용도에서 22 tok/s면 클라우드 호출보다 살짝 느린 정도라 체감상 부족함은 없다.

REST API로도 부르기 — 11434 포트 한 줄

Ollama는 메뉴바 앱이 떠 있으면 자동으로 127.0.0.1:11434에 REST API를 연다. CLI 말고 다른 도구·스크립트에서 부를 때 쓴다.

OpenAI 호환 경로 /v1/chat/completions도 살아있어, 기존 OpenAI SDK 코드의 base_url만 바꿔도 붙는다. 외부 네트워크에서 접속하려면 OLLAMA_HOST를 바꾸거나 터널을 따로 깔아야 하는데, 안전한 외부 접속은 별도 글에서 다룬다(준비 중).

그림 9. REST API /api/generate 응답

M3 Pro 36GB로 못 하는 것 — 솔직한 한계

“할 수 있다”만 늘어놓는 가이드가 너무 많아서 여기가 이 글에서 제일 바꾸고 싶었던 부분이다.

MLX 함정. 영문 매체에서 “Ollama가 MLX로 2배 빨라졌다”는 헤드라인을 종종 보는데, 공식 요구치는 통합메모리 32GB 초과 + Qwen3.5-35B-A3B 단일 모델이다. 본 환경(M3 Pro 36GB)은 메모리 요건은 통과하지만, Llama·Qwen·Gemma 등 일반 모델을 돌릴 때는 적용 대상이 아니라 기존 Metal/llama.cpp 경로로 동작한다. 헤드라인이 거짓은 아니지만 모델 호환이 매우 제한적이라는 뜻이다. 신규 GPU Neural Accelerator 가속도 M5 / M5 Pro / M5 Max 전용이라 M3 세대엔 무관하다. 8B Q4_K_M 22 tok/s가 본 환경의 현실 수치다.

컨텍스트 함정. 모델이 “128K 지원”이라고 해서 36GB에서도 무한정 다 쓸 수 있다는 뜻은 아니다. 8B + FP16 KV 캐시 기준 32K 컨텍스트는 KV 캐시만 ≈4.5GB 추가 점유. 36GB라도 13B·30B 모델을 큰 컨텍스트와 함께 쓰면 빠르게 한계에 닿는다. 일반적인 안전선은 8K~16K. 필요하면 OLLAMA_CONTEXT_LENGTH나 API의 options.num_ctx로 명시한다.

발열·배터리. 7B 추론 전력은 12~18W, 풀충 기준 활성 추론 3~4시간. 노트북 스탠드로 흡기를 확보하면 thermal throttling 시점이 10분에서 20분+로 미뤄진다. 정확한 수치는 환경에 따라 다르다.

동시 요청은 약점. Ollama는 단일 사용자 prototyping에 최적이라 동시 요청이 늘면 throughput이 빠르게 떨어진다. 처리량 중심 엔진(vLLM·sglang)으로 옮길 시점·비교는 별도 글에서 다룬다(준비 중).

자주 묻는 질문

Q1. Ollama가 정확히 뭔가요?

로컬에서 LLM을 CLI와 REST API로 띄우는 오픈소스 런타임이다. 내부적으로 llama.cpp와 Metal 가속을 쓰며, pull / run 두 줄로 시작한다.

Q2. M3 Pro로 8B 모델 돌릴 수 있나요?

18GB·36GB 모두 가능. Q4_K_M 다운로드 4.9GB, 컨텍스트 포함 메모리 6~8GB 수준이라 18GB에서도 여유. 내 36GB 환경에선 긴 응답 평균 약 22 tok/s가 나왔다. 36GB 사용자는 추가로 13B·30B Q4까지 시도해볼 수 있다.

Q3. Ollama 설치 시간이 얼마나 걸리나요?

dmg 설치 3~5분, Llama 3.1 8B pull 7~10분(100Mbps), 첫 응답 1분 내외로 약 20분. 기가급 회선이면 더 짧다.

Q4. Metal GPU 가속이 자동으로 적용되나요?

예. Apple Silicon은 기본 활성이라 별도 설정이 필요 없다. ollama ps의 Processor가 100% GPU면 정상이다.

Q5. 모델 파일은 어디에 저장되며 외장 SSD로 옮길 수 있나요?

기본 경로는 ~/.ollama/models. 변경하려면 launchctl setenv OLLAMA_MODELS "/Volumes/Ext/ollama"로 환경변수를 잡고 메뉴바 앱을 재시작한다.

Q6. 메모리가 부족하면 어떻게 되나요?

macOS가 swap으로 폴백해 토큰 속도가 1~5 tok/s로 급락한다. ollama ps의 Processor가 부분 % 또는 100% CPU면 모델·컨텍스트를 줄일 신호다.

Q7. Llama 3.1과 Llama 3.2 중 뭘 쓰나요?

학습 baseline으론 3.1 8B를 권한다. 3.2 3B는 더 가볍지만 품질이 떨어진다. 한국어 모델 비교는 별도 글에서 다룬다(준비 중).

Q8. 외부에서 내 맥북 Ollama에 접속하려면?

기본 바인딩은 127.0.0.1:11434로 로컬만 열려 있다. OLLAMA_HOST=0.0.0.0:11434로 노출은 가능하지만 보안 위험이 크다. Cloudflare Tunnel 등 안전한 설정은 별도 글에서 다룬다(준비 중).

정리 — 30분 후 무엇이 남았나

30분 뒤 내 맥북에는 Llama 3.1 8B가 22 tok/s로 돌고 있다. 클라우드 모델만큼 똑똑하진 않지만 무료·오프라인·프라이빗이다. 36GB 환경에선 13B·30B Q4까지 안전하게 올릴 수 있고, MLX 가속은 메모리 요건만 통과할 뿐 일반 모델엔 적용되지 않는다는 것도 함께 알게 됐다(18GB 베이스 SKU 사용자라면 8B Q4_K_M까지가 안전선). “내가 뭘 쓰고 있는지” 정확히 인지하면서 다음 단계로 넘어갈 수 있다.

다음으로 해볼 만한 것들 — 모두 별도 글로 다룰 예정이다.

• 외부에서 접속하기: Cloudflare Tunnel로 안전하게 노출 (준비 중)
• 한국어 모델 고르기: gemma2:9b·llama3.2·mistral-nemo 비교 (준비 중)
• 처리량이 필요해지면: vLLM은 왜 빠른가: PagedAttention을 OS 페이징으로 이해하기
• 엔진 비교: sglang vs vLLM vs Ollama 언제 무엇을 쓰나 (준비 중)

다음 글에선 외부 접속을 다룬다.

관련 글

• Claude API 비용 완벽 가이드 2026 — 토큰 단가·캐싱·배치 할인 — 같은 토큰을 로컬에서 0원에 돌리는 게 매력적이라면, 비교 기준점으로 클라우드 비용 구조부터 잡고 가는 것을 권한다.

2026년 5월 17일 기준 측정. 두 도구 모두 월 단위로 신기능을 내놓고 있어, 가격·기능은 공식 페이지에서 최신 확인을 권한다. Anthropic·Cursor 어느 쪽과도 협찬·제휴 관계가 없는 자비 유료 구독 기준이다.

TL;DR

• 한 줄 결론: 백엔드 자율 워크플로·터미널 자동화는 Claude Code, 단발 UI 편집·다중 모델 실험은 Cursor. 둘 중 하나를 골라야 한다면 작업 유형이 분기점이다.
• Cursor 강점: IDE 통합, Composer로 다중 파일을 한 번에 편집(2025-10-29 출시, 대부분 30초 안에), Auto mode 무제한, GPT/Claude/Gemini를 같이 시도 가능.
• Claude Code 강점: Plan Mode 안전판(Shift+Tab 두 번), Hooks 25개 라이프사이클 이벤트로 결정론적 자동화, Subagents 격리, 로컬 파일 직접 조작.
• 한국 가격: Pro는 둘 다 $20부터 시작, 헤비 티어는 Cursor Ultra·Claude Max 20x 모두 $200(약 27만 6천 원, 환율 1,380원 기준).
• 내 결론: 둘 다 쓴다. Cursor는 IDE에서 코드 단발 작업, Claude Code는 백엔드 리팩터와 이 블로그 자동화. 작업별로 분기.

Cursor vs Claude Code, 어떤 거 쓸지 결정 못하고 있다면 — 이 글은 6개 축으로 30초 안에 답을 내는 결정 트리다. 한국 백엔드 개발자가 둘 다 유료 플랜으로 같은 코드베이스에서 써본 2026년 5월 기준 비교다.

운영 환경: Java/Spring Boot(DDD/Hexagonal) + Python/FastAPI + Vue 3 풀스택, macOS(M3 Pro), Claude Max·Cursor 유료 동시 결제. 이 블로그는 Claude Code 멀티 에이전트 하네스로 굴리고 있어 “도구로 글을 쓰는” 메타 경험도 끼어 있다. 설치·OAuth는 다루지 않는다 — 처음이라면 Claude Code 설치부터 첫 명령까지부터 보고 오자.

30초 결정 매트릭스 — 시나리오로 바로 찾기

본문 다 안 읽어도 된다. 자기 상황에 맞는 행을 찾으면 답이 나온다.

여기서 한 행만 뽑으면 그게 답이다. 두 행이 동시에 걸리면 — 그게 내 케이스다. 그래서 8번째 결정 축이 “둘 다”가 된다.

결정 축 1 — 작업 유형: 단일·멀티·자율 에이전트

작업 유형이 가장 먼저 갈리는 분기다.

단일 파일 단발 수정은 Cursor의 Tab 자동완성·인라인 편집이 마찰 가장 적다. Claude Code도 가능하나 터미널을 열고 컨텍스트를 잡는 자체가 오버킬이다.

멀티 파일 동시 수정에서 갈린다. Cursor Composer는 2025년 10월 29일 출시된 자체 코딩 모델로 “대부분 30초 이내” 완료를 표방한다(Cursor 2.0 발표). 미들웨어·route handler·env var·테스트를 한 번의 자연어 입력으로 묶고, diff preview 후 Cmd+Z 한 번이면 통째로 롤백된다. Claude Code도 멀티 파일 편집은 되지만 Plan Mode 승인 단계가 한 박자 더 들어간다. 속도냐 안전성이냐다.

그림 1. Cursor Composer가 여러 파일을 diff preview로 묶어 보여주는 화면

자율 에이전트(이슈→PR 초안)는 다른 방향이다. Cursor는 Background Agent와 Microsoft Teams 통합(2026-05-11)으로 클라우드 협업 쪽, Claude Code는 Subagents와 25개 라이프사이클 Hooks로 로컬 자작 하네스 쪽이다.

결정 축 2 — 컨트롤 vs 자율성: tab-tab과 Plan Mode 사이

인플런 강사 gymcoding의 답이 이 축을 가장 깔끔하게 정리한다. “모델은 동일합니다! 하지만 핵심은 모델 자체가 아니라 도구의 사용 방식(인터페이스)에 있습니다.” (출처)

Cursor는 developer in the loop — tab-tab 자동완성, 인라인 편집, Composer diff preview로 개발자가 매 단계에 끼어 있다. Claude Code는 agent in the loop — 에이전트가 계획→실행→자체 검증을 자율 진행하고, 개발자는 높은 수준에서 감시한다.

Plan Mode가 두 도구의 분기점이다. 2026년 1월 단축키 표준화 이후 Shift+Tab을 두 번 누르면 진입한다(공식 문서). 읽기 전용 상태로 코드베이스를 분석하고 단계별 계획만 제시한다 — 파일 편집·shell·git 모두 차단된다. 위험한 리팩터를 던질 때 안전판으로 쓰기 좋다. 나는 Spring 멀티모듈에 새 도메인을 추가할 때 항상 Plan Mode부터 켠다. 한 번은 Shift+Tab 안 누르고 던졌다가 엔티티 4개가 동시 수정되어 롤백한 적이 있다. 그 뒤로 습관이 됐다.

그림 2. Claude Code의 Plan Mode 활성 화면 (Shift+Tab 두 번 단축키)

Hooks는 또 다른 결이다. 공식 문서의 정의를 그대로 옮기면 — “Hooks are user-defined shell commands that execute at specific points in Claude Code’s lifecycle. They provide deterministic control over Claude Code’s behavior, ensuring certain actions always happen rather than relying on the LLM to choose to run them.” (출처) “LLM이 알아서 하길 기대” 대신 “항상 X가 일어남”을 강제하는 도구다. Cursor에는 같은 결의 등가물이 없다.

결정 축 3 — 월 얼마? 원화 환산과 한국 카드 결제

진입 가격은 같고 정책 구조가 다르다.

진입은 둘 다 Pro $20이고 한국 신용카드로 OAuth·결제 모두 된다. 그 위가 갈린다. Cursor Pro 위 중간 티어는 페이지 구성이 자주 바뀌어 단정이 어렵다 — 직접 cursor.com/pricing 확인을 권한다. Claude는 중간 없이 Pro → Max 5x($100) → Max 20x($200)로 점프한다(claude.com/pricing).

헤비 사용 시 명목 가격은 동가($200)다. 목적은 다르다. Ultra는 “여러 모델 + Auto mode 무제한”, Max 20x는 “Opus 헤비 + 5시간 리셋에 안 닿기”. 나는 Sonnet 4.6을 일상으로 쓰고 가끔 Opus 4.7로 큰 리팩터를 돌리는데 Max 20x로 일일 한도에 걸려본 적은 거의 없다. 단 내 패턴 기준이라 일반화는 어렵다.

그림 3. Cursor 가격 페이지 (2026년 5월 기준)

그림 4. Claude 가격 페이지 (2026년 5월 기준)

한도 정책에서 한국 사용자가 갈린다. Cursor는 2025년 “무제한 → 크레딧”으로 전환했고 한국 매체에서도 사용자 반발이 보도됐다(AI매터스). Claude Code는 5시간 리셋 + 주간 한도 이중 구조라 짧은 디버깅 세션이 끊기는 사례가 클리앙에도 올라온다(클리앙 후기). 2026년 5월 13일 Anthropic이 Claude Code 주간 한도 50% 한시 인상을 발표했다(2026-07-13까지, 유료 플랜 전체 적용) — Codex 견제로 해석되는 움직임이다(apidog 보도).

별도 과금도 다르다. Cursor BugBot은 usage-based 별도 과금이며 정확 단가는 공식·매체 보도가 엇갈려 추상 표기가 안전하다. Claude Code는 한도 초과 시 표준 API 단가로 pay-as-you-go가 된다. 단가 구조는 Claude API 비용 가이드에서 따로 다뤘다.

가격 단정은 위험하다. 한 데이터 포인트로, velog의 takuya는 2025년 1주일 사용 후기에서 “Claude Code + 최적화 ≈ 월 $6, Cursor + 자체 API 키 ≈ 월 $14″라고 정리했다(velog 후기). 사용 패턴이 다르면 결론은 뒤집힌다.

결정 축 4 — 백엔드(Spring/FastAPI) 시나리오에서 어디가 강한가

한국어 비교 글 대부분이 프론트 위주라 백엔드는 빈자리다.

Spring 멀티모듈/Hexagonal에서는 Plan Mode의 안전판 가치가 크다. jonny-cho 블로그(2025년 7월 시점 후기) 인용 — “Kotlin + Spring Boot 3.x 기반 JPA with Hibernate, 멀티모듈 구조, QueryDSL 설정 등을 자동으로 인식”(출처). 다만 한계도 분명하다. cogito1016은 백엔드 4시간 완성 사례를 올리면서 *”아무리 프로젝트 전체를 스캔해도, 팀 내부의 암묵적인 규칙이나 히스토리는 이해하지 못했다”*고 짚었다(출처).

내 패턴. Java/Spring 사내 도메인 리팩터는 Cursor @Codebase로 컨텍스트를 잡고 실제 변경은 Claude Code Plan Mode 단계 승인. Python/FastAPI 신규 엔드포인트는 정반대 — Cursor Composer로 라우터·스키마·테스트를 묶고 Subagent로 별도 검증을 돌린다. 두 도구가 동시에 떠 있어도 충돌 안 난다.

원칙은 간단하다. 멀티모듈/DDD/Hexagonal엔 Plan Mode 안전판이 큰 무기 → Claude Code. 단발 컨트롤러 수정·테스트는 Composer 속도 → Cursor. 프론트엔드(Vue/React) 단발은 Cursor 인라인 diff가 직관적이나 이 글 스코프 밖이다.

결정 축 5 — 솔로 vs 팀 협업, 사내 코드 보안 관점

솔로 1인 개발자 출발선은 같다(Pro $20). 차이는 사용 패턴. 여러 모델 시도와 Auto mode 무제한이 중요하면 Cursor. 자율 실행 + 로컬 파일 + 홈서버/블로그 자동화는 Claude Code. 이 블로그는 researcher → outliner → writer → fact-checker → editor 5명이 한 글을 릴레이로 쓰는 Claude Code 하네스로 굴린다. Cursor에서도 시도했지만 Subagent/Hooks 등가물이 없었다. Cursor 3.3 “Build in Parallel”이 가장 가까우나 클라우드 호스팅 기반이라 결이 다르다.

팀에선 Cursor Teams가 PR 자동 리뷰(BugBot Autofix)와 Microsoft Teams 통합으로 강하고, Claude Code Team Standard는 $25/seat 가격 우위에 SSO·관리자·감사 로그를 끼워준다. 사내 코드 보안 — Cursor는 Privacy Mode로 Background Agent 차단 가능, Claude Code는 로컬 파일 직접 조작이라 외부 인덱싱 자체가 없다. MCP·hooks로 정책 강제까지 묶을 수 있다.

결정 축 6 — 2026년 5월 신기능: Composer·BugBot vs Skills·Hooks·Subagents

한국어 글 다수가 2025년에 멈춰 있다. 5월 기준으로 갱신해두면 6개월은 유효하다.

한국어 글에 거의 안 보이는 1차 데이터 하나 — 2026년 5월 11일 BugBot에 Effort Levels가 들어갔다. cursor.com/changelog 공식 표기로 Default effort finds 0.7 bugs per run; High effort finds 0.95 bugs per run (Cursor 자체 측정 기준, 독립 벤치마크 아님).

Claude Code 안에서 어떤 모델을 쓸지는 별도 주제라 Claude Opus vs Sonnet vs Haiku 차이에서 다뤘다.

내가 결국 둘 다 쓰는 이유

결정 트리를 다 그려놓고 보니 내 결론은 “둘 다 쓴다”였다.

Cursor는 IDE 단발 작업, 모델 답 비교, 가끔 프론트 컴포넌트. Claude Code는 백엔드 리팩터(Plan Mode), 이 블로그 자동화 하네스, Docker/홈서버 스크립트, 터미널 워크플로 전부. 이 글도 Claude Code 에이전트들이 릴레이로 쓰는 중이다. 일상 패턴은 Claude로 코딩 생산성 2배에서 정리했다.

한국 시장의 결론도 비슷한 자리로 모인다. wavespeed.ai/blog/ko: “2026년에 가장 많이 배포하는 개발자들은 두 도구를 모두 사용합니다.” velog/@takuya: “상황에 맞게 두 도구를 활용하는 게 가장 현명하다는 결론이었습니다.”

월 $40, Pro 두 개, 약 5만 5천 원. 점심 한 끼 줄이면 둘 다 쓸 수 있다는 게 솔직한 결론이다.

자주 묻는 질문 (FAQ)

Cursor와 Claude Code 중 어떤 게 더 나아요?

단일 답은 없다. 위 30초 매트릭스가 빠르다. 한 문장 요약 — VS Code 익숙·다중 모델 = Cursor, 백엔드 자율 워크플로·로컬 자동화 = Claude Code, 대부분 = 둘 다.

Cursor와 Claude Code 같이 써도 되나요?

같이 쓰는 게 한국 컨센서스다. 같은 코드베이스에서 작업별 분기 — Cursor에서 단발 편집, Claude Code 터미널에서 자율 워크플로. Pro $20씩, 월 $40면 둘 다 굴린다.

Cursor와 Claude Code 가격 차이는 얼마예요?

진입 동일($20), 헤비 사용도 명목 동가($200, Cursor Ultra Claude Max 20x). 차이는 정책 구조 — Cursor는 크레딧 + Auto 무제한, Claude는 5시간 + 주간 한도. 위 가격 표 참조. 환율 1,380원 기준.

Cursor에서 Claude 모델을 쓸 수 있는데 굳이 Claude Code가 필요해요?

모델과 도구는 다르다. 같은 Claude 모델을 써도 인터페이스(Cursor IDE 협력 vs Claude Code 터미널 자율)가 다르고, Plan Mode·Hooks·Subagents 같은 자율 실행 워크플로는 Cursor에 등가물이 없다. 인플런 강사 인용: “핵심은 모델 자체가 아니라 도구의 사용 방식.”

백엔드 개발에는 어느 쪽이 유리해요?

Spring/FastAPI 멀티모듈에서는 Plan Mode 안전판이 큰 무기 → Claude Code 우위. 단 단발 컨트롤러 수정·테스트는 Composer가 빠르다. 결론은 같은 코드베이스에 둘 다, 작업별 분기다.

Claude Code 주간 한도가 부담스러우면 Cursor가 답인가요?

2026년 5월 13일 Anthropic이 주간 한도 50% 한시 인상(2026-07-13까지)을 발표했다. 그래도 부담되면 Pro 대신 Max 5x/20x 고려가 먼저다. “한도 부담 → Cursor”는 답이 아니다 — Cursor도 2025년 크레딧 전환 후 비슷한 페인이 보고된다. 답변이 이상하면 Claude 8가지 증상 진단·해결법을 먼저 확인.

마무리

여전히 결정 못하겠으면 Cursor 14일 무료 트라이얼과 Claude Pro 1주일 체험을 함께 돌리고 실제 사용 패턴을 측정하라. 월 $20 미만으로 결정 데이터를 얻는다.

자체 호스팅(Claude API vs Ollama 로컬)은 별도 글로 준비 중이다. 이 글은 “도구 선택”에 집중했고, 활용 패턴은 G2, 모델 선택은 D1, API 비용은 D2 링크가 이어 받는다.

가격·기능은 2026년 5월 17일 기준이다. 두 도구 모두 월 단위로 신기능을 내놓으므로 결정 직전엔 공식 페이지에서 한 번 더 확인을 권한다.

관련 글

• Claude Code 설치부터 첫 명령까지 — 2026년 macOS·WSL 기준 입문 — Claude Code 처음이라면 설치부터
• Claude로 코딩 생산성 2배? 5가지 활용 패턴 — 도구 선택 후 매일 쓰는 패턴
• Claude Opus vs Sonnet vs Haiku 차이 완벽 정리 (2026) — Claude Code 안에서 어떤 모델 고를지
• Claude API 비용 완벽 가이드 2026 — API 종량제 vs 구독제 비용
• Claude vs GPT vs Gemini 2026 — 모델 자체 비교(도구 X)
• 클로드 이상한 답변? Claude 8가지 증상 진단·해결법 (2026) — 도구는 골랐는데 답이 이상하다면
• 자체 호스팅(Claude API vs Ollama 로컬) — (준비 중)

TL;DR

• Claude 답이 이상하면 환각·답변 거부·번역체·코드 오류·문맥 잃음·짧은 답·가짜 출처·반복 답 8가지 중 하나에 거의 다 들어간다.
• 30초 안에 답을 찾으려면 아래 진단표부터 본다.
• 함정 주의: Opus 4.7로 바꿨는데 답이 단조롭다면 Adaptive thinking이 default OFF라 명시적으로 켜야 한다.
• 모델 변경·Extended Thinking·Projects·Styles·Artifacts 다섯 도구가 대부분 해결한다.
• 본 글은 정상적·합법적 사용 시나리오 한정이다 (의료·법률·투자 자문 범위 밖).

30초 진단표 — 증상 → 원인 → 즉시 시도

1. 환각 — 없는 함수·잘못된 인용을 만들어낼 때

Anthropic은 환각을 “사실과 다르거나 컨텍스트와 모순되는 텍스트를 생성하는 현상”으로 정의한다 출처.

모델은 지식 cutoff 이후의 사실을 모르고(Opus 4.7=2026년 1월, Sonnet 4.6=2025년 8월) 출처,

답변 압박이 있으면 그럴듯한 것을 채워 넣는다.

처방은 셋을 묶는다.

1. 프롬프트에 “확실하지 않으면 ‘모른다’고 답해도 좋다” 한 줄을 박는다.
2. 사실 주장마다 출처 인용을 강제하고, 못 붙이면 주장을 철회시킨다.
3. claude.ai 입력창에서 Web search 토글을 켠다.

내가 Sonnet 4.6에 pandas 처리를 부탁했을 때 존재하지 않는 메서드를 그럴듯하게 만들어 준 적이 있다. “확실하지 않으면 모른다고 답하라”를 시스템 프롬프트에 박은 뒤로 빈도가 확연히 줄었다.

2. 답변 거부 — “도와드릴 수 없습니다”가 뜰 때

Anthropic은 안전 필터의 false positive 발생 가능성을 공식 인정했다 출처.

Sonnet 4.6은 어려운 양성 프롬프트의 잘못된 거부율을 8.50% → 0.18%로 약 47배 줄였다 (Sonnet 4.5 → 4.6 비교) 참고.

거부가 떴다면 우회보다 의도 명시가 먼저다.

1. 프롬프트에 정상·합법적 사용 의도를 한 줄 덧붙인다.
2. Sonnet에서 막히면 Haiku 4.5로 재시도(공식 권고 — “different usage restrictions”) 출처.
3. 시스템 프롬프트의 “CRITICAL: You MUST…” 같은 공격적 어투를 평이한 표현으로 바꾼다.

내가 운영하는 WordPress 사이트의 XSS 점검을 부탁했을 때 한 번 막혔다. “내가 운영하는 도메인의 자가 점검”이라는 한 줄을 덧붙이고 다시 보냈더니 그대로 통과했다.

3. 한국어가 어색하다 — 번역체·딱딱한 어투

Anthropic 한국어 docs 자체가 영어 직역체다. 게다가 Opus 4.7은 공식적으로 **”이전보다 더 직설적이고 검증·동조 표현이 줄어든 톤”**으로 바뀌었다 출처.

4.7로 바꾸면 답이 더 건조해지는 게 정상이다.

해결은 Style을 한 번만 만들어 두면 된다.

1. claude.ai 좌하단 Styles 메뉴에서 자기 글 샘플을 업로드해 “내 글체 따라하기” 스타일을 자동 생성한다 출처.
2. 명령형 양식 지정: “한국어 자연 구어체로”, “번역투 회피”, “‘Claude는 ~합니다’ 같은 영어 어순 금지”.
3. Project를 쓴다면 인스트럭션에 영구 박기 — 매 대화마다 자동 적용된다.
4. 프롬프트의 markdown을 줄이면 응답의 markdown도 줄어든다(공식 권고).

처음엔 매번 “한국어 자연스럽게”를 붙였다. Style을 한 번 만들고 나서는 잊고 살게 됐다.

그림 1. claude.ai의 Styles 선택 메뉴 위치

4. 코드가 실행 안 됨 — deprecated API·import 누락

원인은 명확하다. Knowledge cutoff 이후 라이브러리 변경을 모델이 모른다 출처.

1. 첫 메시지에 버전·환경을 명시한다: “Spring Boot 3.4 기준”, “Python 3.12 환경”.
2. Artifacts로 코드를 받아 “Fix with Claude”나 자연어 디버깅을 반복한다 출처. 활용법 전체는 Claude Artifacts 사용법 글 참조.
3. Extended Thinking을 켠다. 디버깅·다단계 추론에 효과가 크다 출처.
4. Project Knowledge에 package.json·사내 컨벤션을 넣어 매 세션 자동 참조시킨다.

Sonnet에게 부탁했던 코드가 옛 시그니처를 추천한 적이 있다. Opus 4.7로 바꾸고 Extended Thinking을 켜니 최신 시그니처로 다시 써 줬다. CLI 사용자라면 Claude Code 입문 글도 참조.

그림 2. Artifacts에서 Fix with Claude로 즉시 디버깅

5. 긴 대화에서 앞 말 잊어버림 — 문맥 잃음

컨텍스트 윈도우는 Opus 4.7이 1M 토큰, Sonnet 4.6이 1M 토큰(베타)까지 늘었지만, 결국 압축·드롭이 발생한다 출처.

반복 주제는 Projects로 이전하는 게 정공법이다.

1. Projects로 이동: 긴 reference는 Project Knowledge에 파일로 박는다 (RAG 방식이라 컨텍스트를 잡아먹지 않음) 출처.
2. Project 지침 — 매 대화 자동 적용되는 영구 행동 지정.
3. Compaction(베타) — Sonnet 4.6/Opus 4.7은 컨텍스트가 차면 자동 요약한다 출처.
4. 그래도 막히면 새 대화 + 인수인계 프롬프트.

긴 기획 대화에서 초반에 정한 컨벤션을 Claude가 잊는 일이 잦았다. Project로 옮기고 인스트럭션에 컨벤션을 박아 두니 같은 설명을 다시 할 일이 없어졌다. Projects 사용법 전체는 Claude Projects 완벽 정리에 따로 다뤘다.

그림 3. Project Instructions에 영구 행동을 박아 둔 모습

6. 답변이 너무 짧거나 잘림 — 출력 한계

원인은 셋 중 하나다. max_tokens 한계(Opus 4.7=128k, Sonnet 4.6·Haiku 4.5=64k), claude.ai의 5시간 사용 한계, Opus 4.7의 동적 길이 정책. 4.7은 **”작업 복잡도에 맞춰 길이를 동적으로 조절”**한다 출처.

1. 명시적 길이 요구: “최소 1500자 이상”, “예시 5개 이상”.
2. 계속 프롬프트: “이어서 계속해 줘. 끊긴 지점부터 시작” 출처.
3. Artifacts로 빼기: 긴 코드·문서는 본문 토큰을 절약한다.
4. “5시간 한계 알림”이 뜨면 잠시 대기.

7. 출처·링크가 거짓이다

인용 환각이다. Help Center도 **”fabricated quotes or outdated information”**을 명시적 사례로 든다 출처.

사용자 측 검증이 유일한 방어선이다.

1. 프롬프트 패턴: “URL은 직접 접근 가능한 것만. 불확실하면 ‘확인 필요’ 표시”.
2. Web search를 켜고, 받은 링크는 직접 클릭해 검증한다.
3. Help Center 권고: “Don’t treat Claude as authoritative” — 단일 출처 신뢰 금지.

Claude가 그럴듯한 docs URL을 제시했는데 클릭하니 404가 떴던 일이 있다. 그 뒤로 “직접 접근 가능한 URL만”을 시스템 프롬프트에 박았다.

8. 같은 답만 반복·창의성이 없음 (Opus 4.7 adaptive thinking 함정)

이게 2026년 5월 한국 커뮤니티가 가장 많이 호소하는 증상이다. 원인이 직관적이지 않다.

• Opus 4.7의 Adaptive thinking은 default OFF다. 명시적으로 켜지 않으면 사고 깊이가 얕다 출처.
• 4.7은 행동상으로 **”더 직설적·건조한 톤”**으로 바뀌었다.
• API의 temperature·top_p·top_k가 제거돼 다양성은 프롬프트로만 유도해야 한다.

해결:

1. 적응형 사고(Adaptive Thinking) 토글을 켠다 (모델 선택에서).
2. xhigh effort 사용 — 공식 권고는 “코딩·에이전틱은 새 xhigh effort부터 시작”.
3. 프롬프트로 다양성 강제: “전과 다른 어조”, “이전 비유 재사용 금지”, “4가지 다른 방향 먼저 제시 후 선택”.
4. 창의 글쓰기는 Sonnet 4.6 또는 Opus 4.6 고려 — 4.7은 더 건조하다.

Opus 4.7로 바꿨는데 답이 평이해진 느낌이 있었다. 적응형 사고(Adaptive Thinking)를 명시적으로 켜고 나서야 사고 깊이가 살아났다.

그림 4. Extended Thinking 토글이 켜진 상태 (모델 선택과 같은 영역)

Sonnet 4.6 vs Opus 4.7 — 작업별 모델 선택

나는 일상 95%를 Sonnet 4.6으로 처리하고, 코드·디버깅·기획 정리만 Opus 4.7로 바꾼다. 셋의 차이는 Opus vs Sonnet vs Haiku 비교 글에서 다뤘다.

그림 5. claude.ai의 모델 선택 드롭다운

자주 묻는 질문 (FAQ)

Claude가 왜 자꾸 거짓말을 하나요?

학습 데이터에 없는 사실을 강제로 답해야 할 때 발생한다. “확실치 않으면 모른다고 답해도 좋다”를 명시하고 출처 인용을 강제하면 빈도가 줄어든다.

Claude가 답변을 거부할 때 어떻게 해야 하나요?

정상·합법적 사용 의도를 한 줄 덧붙이고, Sonnet에서 막히면 Haiku 4.5로 모델을 바꿔 재시도한다. 공격적 시스템 프롬프트는 평이한 표현으로 바꾼다.

Claude 답변이 갑자기 짧아진 이유는?

Opus 4.7은 작업 복잡도에 맞춰 길이를 동적으로 조절한다. “최소 1500자 이상” 같은 명시적 요구를 추가하면 풀린다. 5시간 사용 한계도 가능성.

Claude 한국어가 어색할 때 해결 방법은?

Styles에 자기 글 샘플을 업로드해 “내 톤” 스타일을 만들거나, Project 인스트럭션에 **”한국어 자연 구어체, 번역투 회피”**를 박는다.

Claude Sonnet과 Opus 중 어떤 모델을 써야 하나요?

일상은 Sonnet 4.6, 코딩·디버깅·복잡한 추론은 Opus 4.7 + Extended Thinking. 셋의 차이는 Opus vs Sonnet vs Haiku 비교 글 참조.

긴 대화 중 Claude가 앞 내용을 잊어버립니다.

Projects로 옮기고 reference 문서를 Project Knowledge에 박으면 매 대화 자동 참조된다. Sonnet 4.6/Opus 4.7은 자동 요약(Compaction) 베타도 지원한다.

마무리

8가지 증상 중 어떤 거였나? 진단표를 다시 보고 한 도구씩 적용하면 대부분 30초 안에 풀린다. 그래도 막히면 Anthropic Help Center에 직접 문의가 가장 빠르다. 모델 비교는 Opus vs Sonnet vs Haiku, 컨텍스트 잃음 깊은 해결은 Claude Projects 완벽 정리에서 따로 다뤘다.

관련 글

• Claude Opus vs Sonnet vs Haiku 차이 완벽 정리 (2026) — 모델 선택이 막힐 때
• Claude Projects 완벽 정리 — 컨텍스트 잃음 깊은 해결
• Claude Artifacts 사용법 완벽 정리 — 코드 검증과 디버깅
• Claude Code 설치부터 첫 명령까지 (2026) — CLI 사용자용
• Claude로 코딩 생산성 2배? 5가지 활용 패턴 — 매일 쓰는 패턴
• Claude vs GPT vs Gemini 2026 — 비교 검증 필요할 때

그래서 “2배”는 후크고, 본 글은 2026년 4월 기준 매일 쓰는 5가지 활용 패턴을 정리한다. 코드 리뷰·디버깅·새 기능 초안·테스트·한국어 주석 및 커밋 — 한국 개발자가 코딩에 가장 많이 쓰는 LLM이 Claude(42%)라는 조사 결과도 있고 바이라인네트워크, 본인이 클로드 코딩에 들이는 시간 대부분도 이 다섯 갈래로 갈린다. 이미 깔린 사용자 전제니, 처음이라면 Claude Code 설치부터 첫 명령까지을 먼저 보고 오면 좋다.

TL;DR. Claude로 매일 쓰는 활용 패턴 5가지(코드 리뷰·디버깅·새 기능 초안·테스트·한국어 주석/커밋)와 프롬프트 템플릿을 정리했다. “2배”는 후크일 뿐, 실제 정량은 Copilot 55%·McKinsey 25-30%·주 6시간으로 폭이 크다. 단순 자동화는 분명히 빨라졌고, 고난도 설계는 거의 그대로다.

패턴 A — Claude 코드 리뷰와 리팩터링

가장 빈도 높게 쓰는 패턴이다. PR diff 또는 파일 한 덩이를 던지고 시니어 동료 톤으로 리뷰를 받는다. Anthropic 공식 best practice가 권장하는 핵심은 Writer/Reviewer 분리 — “fresh context improves code review since Claude won’t be biased toward code it just wrote” Best Practices.

작성한 세션 안에서 같은 모델에 리뷰를 시키면 본인이 짠 코드를 옹호한다. /clear 한 번 치고 새 세션에서 리뷰만 시키는 편이 낫다.

CodeRabbit 자체 평가에서 Opus 4.7는 알려진 버그 100건 중 68건을 잡았고(pass rate 68/100), 종합 점수는 74/100으로 이전 베이스라인 60점에서 올라갔다고 보고된다. actionable 코멘트 비율도 54%에서 64%로 상승했다 CodeRabbit.

작성 세션과 리뷰 세션을 분리하라는 게 핵심이지, 모델 자체로 모든 PR 크기에서 똑같이 강한 건 아니다 — 작은 변경은 사람 눈으로 빠르게 보고 큰 변경에 Claude를 붙이는 편이 컨텍스트 비용 측면에서 효율이 좋다.

역할: 시니어 동료 리뷰어. 톤은 단호하고 친절하게.
대상: @src/api/orders.ts (PR diff는 아래 첨부)
관점: 1) 정확성 2) 엣지 케이스 3) 보안 4) 우리 컨벤션과의 일관성
형식: 발견한 이슈마다 (a) 줄 번호 (b) 왜 문제인지 (c) 수정 코드 (d) 그 이유.
중요: 사소한 nit은 생략. high/medium만.

여기서 자주 빠뜨리는 게 우리 컨벤션과의 일관성 한 줄과 nit 컷오프다. 둘을 빼면 일반론적인 리뷰가 돌아오고, 본문이 길어진다.

그림 1. Claude 코드 리뷰 응답 예시

패턴 B — Claude 디버깅: 가설부터 받는다

에러가 생기면 메시지·재현 흐름·의심 위치·”고쳤다는 것의 정의”를 함께 던진다. 공식 권장은 단호하다. “Address root causes, not symptoms” — 증상을 덮지 말고 원인을 짚으라는 한 줄이다 Best Practices.

체감 차이가 가장 컸던 변형은 failing test부터 작성시키는 흐름이다. 공식 권장 프롬프트도 “write a failing test that reproduces the issue, then fix it” 형태를 쓴다. 검증 수단 없이 그럴듯한 코드만 받으면 엣지케이스가 누락된다 — 공식 가이드의 표현 그대로 “If you can’t verify it, don’t ship it”.

증상: [에러 메시지/스택 트레이스 그대로 붙여넣기]
재현: [클릭 흐름 또는 cURL 한 줄]
의심 위치: src/auth/session.ts 의 refresh 분기
요청: 1) 가장 가능성 높은 가설 3개 2) 각 가설을 빠르게 확인할 수 있는 점검 명령
       3) 가설이 맞으면 어떤 테스트가 실패해야 하는지 — 테스트부터 작성, 그다음 수정.

가설 3개를 강제하는 이유는 한 번에 정답으로 직진시키지 않기 위해서다. 두 번째·세 번째 가설이 진짜 원인인 경우가 잦다.

그림 2. Claude 디버깅 응답 예시

패턴 C — 새 기능 초안: 스펙 → 함수 → 테스트

큰 기능을 한 번에 시키면 거의 어긋난다. Anthropic 공식은 4단계 워크플로우를 권한다. Explore → Plan → Implement → Commit. Plan Mode로 파일 구조를 파악한 뒤 Normal Mode로 전환하는 흐름이다 Best Practices.

큰 기능에는 “Let Claude interview you” — AskUserQuestion 도구로 역질문을 받게 하고 SPEC.md에 저장한 다음, 새 세션에서 그 SPEC을 보고 구현시킨다.

Simon Willison이 정리한 패턴도 결이 같다. 단순 버전부터 만들고, 동작을 확인한 뒤, 정교화한다 How I use LLMs.

한 번에 완성품을 만들지 않는다는 원칙이다.

목표: 사용자가 마감일 지난 할 일을 요약 카드로 보는 기능.
제약: React + 우리 디자인 시스템(@components/Card 사용), 외부 라이브러리 추가 금지.
순서: 1) 인터페이스/타입부터 제안 2) 빈 함수 시그니처 3) 실패 케이스 테스트 1개
       4) 그 테스트를 통과하는 최소 구현. 단계마다 멈추고 내 확인을 받아.

웹 채팅이라면 결과를 Claude Artifacts로 미리 돌려볼 수 있어, 타입·시그니처·테스트 1개의 결합이 즉석에서 검증된다. *”바이브 코딩(vibe coding)”*이라는 말이 유행하지만 — Karpathy가 2025년 2월 X 포스트에서 *”fully give in to the vibes”*로 명명했다 Wikipedia — 이 패턴에서는 단계마다 멈추고 사람이 확인하는 편이 안전하다.

패턴 D — 테스트 작성과 문서화

기존 함수의 입출력을 표로 뽑고 그걸 그대로 테스트 케이스로 옮기는 작업은 사람보다 빠르다. 공식 best practice의 권장 톤도 구체적이다. “write a test for foo.py covering the edge case where the user is logged out. avoid mocks.” 시나리오와 모킹 정책까지 같이 넣으라는 뜻이다.

Anthropic 사내 팀이 공유한 PDF에는 design doc → janky code → refactor → give up on tests 패턴을 pseudocode → guide TDD → check in periodically로 바꾼 사례가 있다 How Anthropic teams use Claude Code. 리팩터 전 characterization tests로 현재 동작을 잠가두라는 조언도 같이 나온다.

대상: @utils/parseDate.ts (현재 60줄)
요청: 1) 이 함수가 다루는 입력 타입을 추출 (정상/엣지/오동작 추정)
       2) 그 입력별 기대 출력을 표로 정리
       3) Vitest 테스트 케이스로 옮겨. 모킹은 쓰지 말고 실제 입출력만.
       4) 실패 케이스를 발견하면 코드 수정 전에 일단 모두 보여줘.

마지막 줄이 핵심이다. 실패 케이스를 발견했을 때 코드를 먼저 고쳐버리면, 어떤 동작이 의도였는지 사람이 잃는다.

패턴 E — 한국어 주석과 커밋 메시지

한국 개발자에게만 통하는 패턴이다. Anthropic 공식 한국어 docs는 존재하지만 code.claude.com/docs/ko/overview, 주석·커밋 메시지 컨벤션 가이드는 따로 없다. 그래서 본인은 CLAUDE.md에 5-7줄짜리 규칙을 박아두는 식으로 자리를 잡았다 — CLAUDE.md는 매 세션 자동 로드되니 한 번만 박으면 된다.

규칙(한 번만 지정):
- 주석은 한국어, 존댓말 X, 명령형/설명형으로 통일
- 변수명은 영어 유지, 도메인 용어는 영어 그대로(예: idempotency, payload)
- 1줄 주석은 // 한국어, 다중 줄은 /** ... */ 영어 한 줄 + 한국어 본문
- 커밋 메시지: <type>: <한국어 한 줄 요약>(50자 이내) + 빈 줄 + 한국어 본문

이 5줄을 박아두니 체감 8할 정도는 일관성이 유지된다. 다만 최근 몇 주 쓰면서 멈칫한 적이 한 번 있는데, 긴 세션 후반에 한국어 주석 사이로 일본어 단어가 한두 개 섞여 들어왔다. GitHub 이슈 #24941로도 보고된 사례라 본인 환경 문제는 아니었다 Issue #24941. /clear로 세션을 끊고 다시 시작하면 정상으로 돌아온다.

CLI에 한국어를 직접 입력할 때 IME composition이 깨지는 문제도 있다 Issue #4866. 본인은 결국 에디터에서 한국어 프롬프트를 작성한 다음 붙여넣는 습관이 자리 잡았다. 작은 우회지만 성가신 편이다.

흔한 실수와 헤맴

공식 best practice와 커뮤니티 이슈를 보면 비슷한 함정이 반복된다.

• kitchen sink session — 한 세션에 무관한 작업을 섞으면 컨텍스트가 오염된다. /clear로 리셋하라는 게 공식 권장이다.
• 2번 정정해도 안 고쳐지면 같은 세션에서 더 다듬지 말고 /clear 후 더 구체적인 프롬프트로 재시작.
• 검증 없이 ship 금지 — 테스트·실행 결과·스크린샷 중 하나는 함께 받아라. If you can’t verify it, don’t ship it.
• max_tokens로 잘림 — Claude Code는 32K 캡이 있고, 긴 마이그레이션 코드는 중간에 끊긴다 Issue #24055. 분할 요청이 안전하다.
• 다중 파일 리팩터에서 reintroduce — 이전에 손댄 파일을 잊고 같은 코드를 다시 만들어 넣는다 DoltHub Gotchas. 작은 커밋 단위로 끊어 가는 편이 낫다.

직접 헤맨 사례 하나. 지난 분기에 자동화 스크립트 두 개를 한 세션에 던졌다가, 두 번째 결과가 첫 번째를 일부 덮어쓴 적이 있다. Sonnet 4.5 시점이었고, 컨텍스트가 길어지면서 첫 스크립트 사양을 잊어버린 모양이었다. 이후로는 작업당 새 세션을 강제한다 — 답답해 보여도 결과는 더 깨끗하다.

모델·환경 선택은 어떻게 할까

기본은 Sonnet 4.6이다. 패턴 A·B·D 대부분에 충분하고, 빠르고, 비용도 적정선이다. 멀티 파일 리팩터·복잡한 디버깅·긴 호흡 작업에 가서야 Opus 4.7로 에스컬레이션한다 — SWE-bench Verified에서 87.6%로 보고된다 TokenMix. 단발 질문은 Pro 웹 채팅, 파일 자율 편집·테스트 실행은 Claude Code CLI다. 모델별 코딩 차이의 더 자세한 비교는 Claude Opus vs Sonnet vs Haiku 차이에 정리해뒀고, API로 직접 호출할 때 단가는 Claude API 비용 가이드에 별도로 두었다. Cursor와의 IDE 비교는 별도로 정리 중(준비 중).

그림 3. Claude Code Best Practices 페이지

자주 묻는 질문

Q1. Claude로 어떤 코딩 작업을 잘하나요?

코드 리뷰·디버깅·새 기능 초안·테스트 자동화·한국어 주석/커밋 같은 패턴화된 작업이다. 시스템 설계·아키텍처 결정 같은 큰 그림은 사람이 가이드해야 한다.

Q2. Claude로 디버깅이 되나요?

된다. 단 에러 메시지·재현 흐름·의심 위치를 함께 줘야 한다. 위 패턴 B 템플릿처럼 가설 3개부터 받고 → 점검 명령 → failing test → 수정 순서를 강제하면 그럴듯한 가짜 답을 거를 수 있다.

Q3. 한국어 주석·커밋 메시지를 잘 쓰나요?

한국 개발자가 코딩에 가장 많이 쓰는 LLM이 Claude(42%)라는 조사가 있을 만큼 한국어 출력은 자연스럽다. CLAUDE.md에 5줄짜리 컨벤션 규칙을 박아두면 일관성 체감 8할이고, 긴 세션 후반에는 일본어 단어가 섞여 들어오는 사례가 있다.

Q4. Pro 구독으로 코딩 충분한가요?

패턴 A·B·D는 Pro 웹 채팅으로 대부분 가능하다. 멀티 파일 자율 편집·테스트 실행 같은 작업은 Claude Code CLI 쪽이 결이 맞다. 모델 차이는 Claude Opus vs Sonnet vs Haiku 참고.

Q5. Cursor·Copilot보다 나은 점은?

본 글은 Claude 단독 활용 패턴이라 깊은 비교는 다루지 않는다. 한국 개발자 점유 1위(42%)와 긴 호흡 작업 강점이 자주 거론되는 포인트다. 모델 단위 비교는 Claude vs GPT vs Gemini에서, Cursor와의 IDE 비교는 준비 중이다.

Q6. Claude 코드 리뷰 어떻게 시키나요?

패턴 A 템플릿을 그대로 복사해 쓰고, 작성 세션과 리뷰 세션을 분리한다(/clear). 컨벤션 한 줄과 nit 컷오프를 빼면 일반론적 리뷰가 돌아온다.

Q7. AI 코딩으로 진짜 생산성이 늘어나나요?

체감으로는 단순 자동화·테스트·리뷰에서 시간이 분명히 줄었다. 정량으로는 Copilot 연구 55%·McKinsey 25-30%·주 6시간 같은 수치가 보고됐지만, 작업 종류·연차에 따라 폭이 크고 주니어가 더 느려진 사례도 있다. “2배 빨라진다”고 단정할 근거는 어느 1차 자료에도 없다.

다음 걸음

본인 워크플로우에 패턴 다섯 중 하나를 박아 넣는 것부터 시작하면 된다. 코드 리뷰가 가장 빠르게 효과가 보이는 편이다. 아직 Claude Code를 깔지 않았다면 Claude Code 설치부터 첫 명령까지으로, 이미 깔았다면 모델 선택은 Opus vs Sonnet vs Haiku에서 정리해두면 된다.

관련 글

• Claude Code 설치부터 첫 명령까지 (2026) — 처음이라면 설치부터
• Claude Opus vs Sonnet vs Haiku 차이 완벽 정리 — 코딩에 어느 모델을 쓸지
• Claude Artifacts 사용법 완벽 정리 — 채팅 옆 코드 패널 활용
• Claude API 비용 완벽 가이드 2026 — 자동화·일괄 처리 비용 시뮬레이션
• Claude vs GPT vs Gemini 2026 — 다른 챗봇과 비교
• Cursor vs Claude Code (추후 발행) — IDE·코딩 도구 비교

TL;DR

• Opus 4.7 $5/$25, Sonnet 4.6 $3/$15, Haiku 4.5 $1/$5 (per 1M tokens, input/output)
• Prompt Caching hit는 base input의 0.1x(=90% 할인), Batch API는 50% 할인. 두 할인 stack 가능
• Pro 구독($17~20/월)과 API는 별도 결제. Pro 구독자도 API는 따로 청구된다
• Opus 4.7은 새 토크나이저로 같은 텍스트 토큰 +35%까지 늘 수 있어 단가만 비교하면 함정

1. 2026-04 단가 한눈에 — 3모델 input/output 표

검색자가 가장 먼저 보는 표부터 박는다. 공식 표기 그대로 $X / MTok (MTok = Million Tokens).

Cache write 단가(5분 1.25x / 1시간 2x)는 H2 4 Prompt Caching에서 다룬다.

그림 1. claude.com/pricing의 Model pricing 표

1M context 표준화: Pricing 문서는 *”Opus 4.7, Opus 4.6, and Sonnet 4.6 include the full 1M token context window at standard pricing”*이라고 명시한다. 본 글의 3모델은 200k 초과 premium 없이 1M까지 동일 단가다.

Opus 4.7 토크나이저 함정: 공식 원문은 “This new tokenizer may use up to 35% more tokens for the same fixed text”. 같은 한국어 문서를 Opus 4.7로 보내면 토큰이 최대 35% 더 잡혀 단가 비교만으로는 함정.

커뮤니티 보고 — “단가 동결, 청구서 인상” Opus 4.7 출시 직후 비용 분석 매체 Finout은 *”if you already run Opus 4.6 workloads, your most likely outcome is a cost increase between 0% and 35% per request on the same prompts, driven entirely by the tokenizer change”*라고 정리했다. Agent Wars도 “new tokenizer silently inflates your API bill” 식으로 같은 지점을 지목한다. Hacker News에선 “Pro 가입했는데 페이지 4번 만들어보고 한도 도달”, *”Max 5x인데 5시간 한도가 2시간 만에 끝났다”*는 보고가 다수. 단가 변경은 없지만 같은 작업의 청구·한도는 더 빨리 닳는다는 게 사용자 체감의 일관된 결론이다. 다수 커뮤니티 보고이며 콘텐츠 종류에 따라 1.0~1.35배 폭이 갈린다는 점은 함께 둔다.

어느 모델이 자기 작업에 맞는지는 Claude Opus vs Sonnet vs Haiku 차이 정리 별도 글에서 다뤘다.

2. 토큰이란 무엇이고, 한국어는 왜 더 비싼가

토큰은 모델이 읽고 쓰는 최소 단위다. 영어는 보통 4자/토큰. 한국어는 글자 1 = 약 2~3 토큰이 통상 실측치이지만 콘텐츠에 따라 다르고 공식이 한국어 비율을 미공개로 두었으므로 정확값은 Token Counting API로 측정해야 한다.

POST /v1/messages/count_tokens 호출은 무료다 (Token Counting 문서 원문 “Token counting is free to use”). 큰 입력을 보내기 전 토큰 수를 미리 재서 견적 정확도를 올릴 때 쓴다.

curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-4-6","messages":[{"role":"user","content":"..."}]}'

응답은 {"input_tokens": 14} 형태다. count_tokens에 cache_control을 붙여도 캐싱은 동작하지 않는다 — 실제 메시지 생성 호출에서만 캐시가 적용된다.

3. 계산 공식 — 입력·출력 단가를 곱하면 끝

모든 시나리오의 베이스가 되는 한 줄 공식.

월 비용(USD)
  = (월 입력 토큰 / 1,000,000) × 모델 input 단가
  + (월 출력 토큰 / 1,000,000) × 모델 output 단가

예: Sonnet 4.6에 입력 1M, 출력 0.2M 토큰을 보내면 1×$3 + 0.2×$15 = $6. 캐싱·배치를 적용하면 위 공식의 input·output 자리에 multiplier(0.1x, 0.5x 등)가 곱해진다. 다음 두 섹션이 그 배율을 정리한다.

4. Prompt Caching — write 1.25x/2x, hit 0.1x로 90% 절감

반복 시스템 프롬프트·코드 컨텍스트가 있는 워크로드에서 가장 큰 절감 도구다.

Pricing 문서가 손익분기점을 명시한다: “caching pays off after just one cache read for the 5-minute duration (1.25x write), or after two cache reads for the 1-hour duration (2x write)”. 5분 TTL은 1회만 재사용해도 흑자, 1시간 TTL은 2회 재사용에서 흑자다.

모델별 최소 캐싱 토큰 — 못 채우면 캐싱이 아예 작동하지 않는다:

• Opus 4.7 / 4.6 / 4.5: 4,096 토큰
• Sonnet 4.6: 2,048 토큰
• Haiku 4.5: 4,096 토큰 (Haiku 3.5는 2,048 — 마이그레이션 함정)

다른 제약: 요청당 최대 4 breakpoints, tools·system prompts·images·tool_choice 변경 시 cache invalidate. 이 multiplier는 Batch API 할인과 stack 가능하다 — 다음 섹션이 그 케이스다.

그림 2. Prompt Caching 공식 문서의 multiplier·TTL 섹션

5. Batch API — 50% 할인, 24시간 보장, 캐싱과 stack

비실시간 작업이라면 Batch API가 단순하고 강력하다. 핵심 사실 네 가지:

1. “All usage is charged at 50% of the standard API prices” — input·output 모두 50% (Batch 문서)
2. 대부분 1시간 내 완료, 24시간 만료 보장(실시간 응답 불가)
3. 100,000 requests / 256 MB 한도, 결과는 29일간 다운로드 가능
4. 모든 active 모델 지원, 캐싱과 stack 가능(1시간 TTL 캐시 권장)

단점은 Zero Data Retention 비대상이라는 점이다. 보안 민감 데이터는 표준 호출이 안전하다.

그림 3. Batch Processing 문서의 50% 할인 명시 영역

6. 실전 시뮬레이션 4개 — 코드 분석 / 챗봇 / 문서 요약 / 복잡 추론

산식은 모두 H2 3 공식에 캐싱·배치 multiplier만 곱한 결과다. 단가는 2026-04-26 기준.

6-1. 시나리오 A — 코드 분석 (Sonnet 4.6 + 5분 캐시): 월 약 $112

가정: 입력 평균 50,000 tokens(코드베이스 + 시스템 프롬프트), 출력 2,000 tokens, 일 50회, 30일.

Cache write : 40,000 × $3.75 / 1M × 30회   = $4.50
Cache hit   : 40,000 × $0.30 / 1M × 1,470회 = $17.64
일반 입력   : 10,000 × $3    / 1M × 1,500회 = $45.00
출력        :  2,000 × $15   / 1M × 1,500회 = $45.00
합계 = $112.14 / 월 (캐시 없이 $270 대비 약 58% 절감)

5분 TTL이라 호출 간격이 5분 이내일 때만 hit. 실제 hit rate는 60~80%가 통상.

6-2. 시나리오 B — 챗봇 (Haiku 4.5 + 시스템 프롬프트 캐시): 월 약 $189

가정: 시스템 프롬프트 8,000 tokens(캐싱, Haiku 4.5 최소 4,096 충족), 사용자 입력 평균 500, 출력 1,000, 일 1,000회, 30일.

Cache write : 8,000 × $1.25 / 1M × 30회     = $0.30
Cache hit   : 8,000 × $0.10 / 1M × 29,970회 = $23.98
일반 입력   :   500 × $1    / 1M × 30,000회 = $15.00
출력        : 1,000 × $5    / 1M × 30,000회 = $150.00
합계 = $189.28 / 월 (캐시 없이 $405 대비 약 53% 절감)

트래픽이 5분 안에 몰리지 않으면 1시간 TTL(write 2x)이 hit rate가 더 안정적이다.

6-3. 시나리오 C — 문서 요약 대량 (Haiku 4.5 + Batch 50% + 1h 캐시 stack): 월 약 $17.50 / 캐시 stack 시 약 $15.26

가정: 평균 입력 30,000 tokens, 출력 1,000 tokens, 1,000건 batch.

Batch만:
  입력 : 30,000 × $0.50 / 1M × 1,000 = $15.00
  출력 :  1,000 × $2.50 / 1M × 1,000 = $2.50
  합계 = $17.50 (정확히 50% 절감)

Batch + 1h 캐시 stack (공통 지시 5,000 tokens 캐싱):
  Cache write : 5,000 × $2 × 0.5 / 1M × 1     = $0.01
  Cache hit   : 5,000 × $0.10 × 0.5 / 1M × 999 = $0.25
  개별 입력  : 25,000 × $0.50 / 1M × 1,000     = $12.50
  출력       :  1,000 × $2.50 / 1M × 1,000     = $2.50
  합계 ≈ $15.26 (일반 호출 $35 대비 약 56% 절감)

Pricing 문서가 *”These multipliers stack with other pricing modifiers, including the Batch API discount and data residency”*라고 명시한 이중 할인 케이스다.

6-4. 시나리오 D — 복잡 추론 소량 (Opus 4.7 직접): 월 $30~40

가정: 입력 5,000 tokens, 출력 3,000 tokens, 일 10회, 30일.

베이스 (캐시 미적용):
  입력 : 5,000 × $5  / 1M × 300 = $7.50
  출력 : 3,000 × $25 / 1M × 300 = $22.50
  합계 = $30.00 / 월

Opus 4.7 토크나이저 보정 (+35% 가정):
  토큰 5,000 → 6,750, 3,000 → 4,050
  합계 ≈ $40.50 / 월

Opus 4.7 캐싱은 입력 4,096 토큰 이상에서 작동한다. 5,000은 충족하나 시스템 프롬프트가 짧으면 미적용 가능.

6-5. 4개 요약

사용 패턴에 따라 Claude API 비용은 월 $15 ~ $200+ 범위에서 움직인다. Claude Code도 API 모드로 쓰면 위 단가가 그대로 적용된다.

7. Pro 구독 vs API — 손익분기점은 어디인가

Claude Pro는 $20/월(연간 결제 시 환산 $17/월)이다. 그런데 Help Center는 분명히 *”A paid Claude subscription enhances your chat experience but doesn’t include access to the Claude API or Console”*라고 못박았다. Pro·Max·Team·Enterprise 모두 chat·Claude Code 한정이고, API 키 사용은 console.anthropic.com에서 별도 가입·별도 결제다.

Pro $20을 API 토큰으로 환산하면 대략:

• Haiku 4.5 input 기준 ≈ 20M tokens
• Sonnet 4.6 input 기준 ≈ 6.7M tokens
• Opus 4.7 input 기준 ≈ 4M tokens
• 출력은 위의 1/5 분량(출력 단가가 5배)

월 1~2시간 가벼운 챗 사용이면 Pro가 압도적으로 싸다. 자체 앱·자동화·SDK 호출이 들어오는 순간부터 API가 정답이다.

한 달 통짜로 굴려본 사례는 아니지만 갈림 지점을 보여주는 단편이 하나 있다. 2026년 2월 며칠간 자동화 스크립트 두 개를 Sonnet 4.5로 돌려봤더니 Usage 대시보드 기준 input 약 16만·output 약 5만 토큰이 찍혔고, 그 기간 단가 환산 청구서는 약 $1.3 수준이었다(그림 4). 같은 호출 패턴을 Pro에서 돌렸다면 자동화가 한도를 갉아먹어 사람이 끼는 작업이 한도 회복까지 멈췄을 것이다. 사용량 절댓값보다 자동화 자유도 — 그게 옮길 이유였다. 단편이라 본격 운용 청구서는 사용 패턴에 따라 달라진다는 점은 미리 둔다.

그림 4. 콘솔 Usage 대시보드 — 필자의 2026-02 단편 API 사용 기록 (Sonnet 4.5, n=1)

Pro 한도 도달 시 자동 API fallback은 없다 — 막히면 그냥 막히고 청구는 별개다.

8. 한국에서 결제·환율·세금 — 무엇이 가능하고 무엇이 미공개인가

한국 사용자가 실무에서 부딪히는 항목을 짧게 정리한다.

• 결제 카드: 신용/직불카드만 공식 지원. 해외결제 가능 비자/마스터/AMEX 권장. 일부 prepaid·gift card는 거절 사례 있음.
• 카카오페이·네이버페이·페이팔: Pro 정책상 PayPal·암호화폐·은행이체·카카오페이·네이버페이 모두 미지원이다. API 결제는 현재 신용카드 위주이며, 그 외 수단 지원 여부는 콘솔에서 직접 확인을 권장한다.
• prepaid credits: 신규 가입자는 콘솔 “Buy credits” → 즉시 사용. 크레딧 1년 만료, 환불 불가, 만료 연장 불가.
• 환율: USD 청구 → 카드사 환율 + 해외결제 수수료(보통 1~3%)가 별도. 인보이스에는 USD만 표시된다.
• 부가세 / 세금계산서: 공식 미공개. 사업자라면 콘솔 빌링에서 세금계산서 옵션을 확인하거나 회계 부서에 사전 확인을 권장한다.
• 무료 크레딧: 신규 가입 $5 / claim 후 14일이 통상이지만 정책 변동이 잦다. 가입 시 console.anthropic.com 배너에서 직접 확인. Haiku 입력 약 5M tokens 또는 Opus 입력 약 1M tokens 분량 — PoC 1~2일치.

9. 비용 절감 베스트 프랙티스

실제 운영에서 비용을 깎는 항목을 체크리스트로 박아둔다.

1. 작업 난이도에 맞는 모델 — 단순 분류·추출은 Haiku, 복잡 추론만 Opus(단가 5배 차이)
2. 반복 시스템 프롬프트는 Prompt Caching 필수 (90% 절감)
3. 비실시간 일괄 작업은 Batch API 50% + 1h 캐시 stack
4. max_tokens 명시 — 출력 단가가 입력의 5배다. 무한 길이 응답 방지
5. Haiku 에스컬레이션 패턴 — 1차 Haiku 분류 → 어려운 케이스만 Sonnet/Opus 라우팅
6. 호출 전 Token Counting API(무료) 로 토큰 사전 측정
7. inference_geo 기본값 유지 — US-only는 1.1x premium, 한국 사용자가 켤 이유 없음

시스템 프롬프트가 길고 호출이 잦은 워크로드라면 cache_control 한 줄로 두 번째 호출부터 입력 비용이 0.1x까지 떨어진다. Haiku 4.5는 4,096 최소 토큰을 넘겨야 적용되니, 시스템 프롬프트 분량을 캐시 임계까지는 채우는 편이 손익분기상 유리하다.

10. 자주 묻는 질문 (FAQ)

Claude API는 한 달에 얼마나 나오나요?

사용 패턴에 따라 다르다. 본문 시뮬레이션 4개 기준으로 코드 어시스턴트 약 $112, 챗봇 약 $189, 문서 요약 배치 약 $17.50, 복잡 추론 $3040이다. 통상 **월 $15$200+ 범위**로 움직인다.

Claude Pro 구독자는 API를 무료로 쓸 수 있나요?

아니다. Pro·Max·Team·Enterprise는 chat·Claude Code 한정이며 API 키는 console.anthropic.com에서 별도 가입·별도 결제다. 공식이 *”subscription doesn’t include access to the Claude API or Console”*로 명시한다.

Prompt Caching은 어떻게 적용하면 비용이 얼마나 줄어드나요?

Cache write는 5분 TTL 1.25x / 1시간 TTL 2x, cache hit는 base input의 0.1x(=90% 할인). 공식 손익분기점은 5분 TTL 1회, 1시간 TTL 2회 재사용에서 흑자다. 반복 시스템 프롬프트라면 거의 항상 이득.

Batch API 할인은 누구나 받을 수 있나요?

가능하다. 모든 active 모델에서 input·output 50% 할인이 적용된다. 단 24시간 처리 보장(실시간 응답 불가)이고 ZDR 비대상이라 보안 민감 데이터는 주의.

Token Counting API는 무엇이고 왜 써야 하나요?

POST /v1/messages/count_tokens로 호출 전 입력 토큰 수를 측정하는 무료 엔드포인트. 견적 정확도와 예산 초과 방지용. 캐싱은 실제 메시지 생성 호출에서만 동작한다.

한국에서 Claude API를 신용카드로 결제할 수 있나요?

가능하다. 해외결제 가능한 비자/마스터/AMEX가 필요하며 USD 청구·환율·해외결제 수수료(보통 1~3%)는 카드사 정산 시점에 반영된다. 카카오페이·네이버페이·PayPal은 현재 미지원이며 콘솔에서 직접 확인을 권장한다.

토큰 100만 개 쓰면 모델별로 얼마인가요?

1M tokens 기준 입력+출력은 Haiku 4.5 $1+$5, Sonnet 4.6 $3+$15, Opus 4.7 $5+$25. cache hit는 입력의 0.1x, Batch는 50%를 곱하면 된다. Opus 4.7은 동일 텍스트가 +35%까지 토큰을 더 쓸 수 있어 단가만으로는 함정.

11. 다음 걸음

다음 걸음 셋 중 하나 — (1) Token Counting API로 자기 콘텐츠 토큰 수를 직접 재 본다, (2) 콘솔 가입 후 $5 무료 크레딧으로 시나리오 A·B 중 가까운 쪽을 1일치만 돌려본다, (3) 반복 시스템 프롬프트가 있다면 cache_control 한 줄부터 붙여본다.

관련 글

• Claude Opus vs Sonnet vs Haiku 차이 완벽 정리 (2026년 4월 최신) — 어떤 모델을 쓸지 정한 뒤 본 비용 계산으로 와야 의미 있다
• Claude Code 설치부터 첫 명령까지 — 2026년 macOS·WSL 기준 입문 — Claude Code도 API 모드에서는 동일 단가 적용
• Claude vs GPT vs Gemini 2026: 한국 사용자가 고른 현답 — 외부 3사 API 단가 비교
• Claude로 코딩 생산성 2배? 매일 쓰는 5가지 활용 패턴 — API 비용을 캐싱·배치로 절감하는 실전 워크플로우 5패턴
• Cursor vs Claude Code 결정 트리: 백엔드 개발자가 6개 축으로 골라봤다 (2026) — Cursor Pro vs Claude Max vs API 종량제 가격 결정 트리
• Ollama로 M3 Pro 맥북에 로컬 LLM 띄우기 — 30분 실측 가이드 — API 단가가 부담되면 같은 토큰을 로컬에서 0원에 돌리는 옵션도 있다. M3 Pro 환경의 현실적 한계까지 함께 확인
• KV 캐시가 뭐길래 — 긴 컨텍스트가 빠르게 비싸지는 이유 — Claude 200K·Gemini 1M 가격 임계점이 왜 그 자리에 있는지 KV 캐시 메모리 구조로 푼 원리 글. prompt caching 단가가 왜 통하는지까지 한국어 직관으로
• 월 $20 AI 구독 비교: ChatGPT Plus·Claude Pro·Gemini Advanced (2026-05) — API 종량제와 정기구독의 분기점. 3사 $20 구독 한 자리 결정 트리