토큰과 컨텍스트 윈도우

"이 프롬프트/대화가 토큰을 얼마나 먹나", "컨텍스트가 1M 인데 왜 정확도가 떨어지나", "롱컨텍스트 요금이 왜 튀나" 를 실무에서 확인할 때 여는 문서.

한 줄 정리

토큰은 모델이 텍스트를 자르는 단위이고, 토크나이저는 모델마다 다르다. 컨텍스트 윈도우가 크다는 건 "넣을 수 있다"는 뜻이지 "다 잘 쓴다"는 뜻이 아니다. 토큰 수는 로컬 라이브러리로 추측하지 말고 각 프로바이더의 카운팅 방법으로 세라.

토큰 세는 올바른 방법 (함정 1순위)

로컬 라이브러리로 추정하면 벤더가 다를 때 실제 청구와 벌어진다. 프로바이더별 정답:

프로바이더	토큰 세는 법	비고
Anthropic (Claude)	`POST /v1/messages/count_tokens`	공개 토크나이저 없음. 이 엔드포인트가 유일한 지원 방법 [HIGH]
OpenAI	`tiktoken` (로컬)	`cl100k_base`=GPT-3.5/4, `o200k_base`=GPT-4o·o-시리즈 [aggregator][MED]
Google (Gemini)	`client.models.count_tokens(...)`	SentencePiece 계열 [aggregator][MED]

⛔ tiktoken 을 Claude/Gemini 에 쓰면 틀린다. 어휘(vocabulary)가 호환되지 않는 다른 토크나이저다. 같은 코드가 토크나이저에 따라 토큰 수가 거의 2배까지 갈린다 [aggregator][MED].
진짜 authoritative 한 값은 언제나 응답의 usage 필드 (input_tokens, output_tokens). 카운팅은 사전 추정이고, 청구는 usage 로 reconcile 하라 [HIGH].

한글은 영어보다 토큰을 훨씬 먹는다 (한국어 개발자 직접 해당)

영어 산문: 벤더 간 한 자릿수 % 편차 (가장 관대).
코드: 대략 10~20% 벤더 간 차이 (텍스트 종류 의존, 단일 수치 확정 불가).
CJK/한글: cl100k_base 기준 대략 문자당 1토큰 — 같은 인코딩의 영어보다 약 4배 [aggregator][MED]. 한글 프롬프트/문서를 컨텍스트에 넣을 때 예산을 4배로 잡아라. 시스템 프롬프트를 영어로 쓰면 토큰이 크게 준다.

컨텍스트 윈도우가 크다 ≠ 다 쓸 수 있다

윈도우 크기는 "담을 수 있는 상한"이지 성능 보장이 아니다. 길이가 늘수록 정확도는 절벽이 아니라 점진적으로 떨어진다.

Context rot (Anthropic 용어) [HIGH]: 토큰이 늘수록 모델이 정보를 정확히 recall 하는 능력이 떨어진다. 트랜스포머는 모든 토큰이 다른 모든 토큰에 attend 하므로 n개 토큰에 n² pairwise 관계 → "attention budget" 이 토큰마다 소진된다.
Lost in the Middle (Nelson Liu 외, Stanford, 2023) [HIGH]: 관련 정보가 입력 중간에 있으면 성능이 나빠지고 처음(primacy)·끝(recency) 에서 최고 → U자형 곡선. multi-document QA·key-value retrieval 에서 확인됨.
실무 규칙: 중요한 내용은 프롬프트의 맨 앞이나 맨 끝에. 중간이 병목이다.
여러 모델을 걸친 후속 리서치도 "단순 태스크에서조차 입력 길이가 늘면 성능이 유의미하게 변한다"고 관측 (distractor 가 있으면 하락 가중) [aggregator][MED]. 구체 하락 수치는 실험 세팅 의존이라 정성적으로만.

→ 컨텍스트를 채우지 말고 줄여라. 관련 심화는 context-engineering 참고.

KV 캐시 vs 프롬프트 캐싱 (헷갈리는 두 층위)

이름이 비슷하지만 완전히 다른 것이다.

	KV 캐시	프롬프트 캐싱
무엇	추론 시 이전 토큰 key/value 벡터 저장 → attention 재계산 회피	API 과금/재사용 기능
층위	모델 내부 (GPU 메모리)	서비스 계층 (요금 청구)
왜 중요	롱컨텍스트가 비싼 근본 원인 (prefill 연산 + KV 메모리)	반복 프리픽스 비용 절감
제어	직접 못 함	breakpoint 로 명시 제어

KV 캐시는 토큰·레이어에 선형이지만 긴 시퀀스의 총 메모리는 대략 quadratic 으로 커진다 → "memory wall" [aggregator][MED]. (구체 수치는 조건부라 인용 안 함.)
프롬프트 캐싱은 별개 기능이고 최소 길이·TTL·요금이 모델마다 다르다 → prompt-caching 에서 값 확인.

롱컨텍스트 과금 함정

임계값(대략 200K 토큰)을 넘으면 요청 전체가 롱컨텍스트 프리미엄 요금대로 붙는 구조가 존재/변화해왔다 [aggregator][MED]. 900K 요청 1건이 표준 요금 대비 크게 뛸 수 있다.
이 과금 구조는 시기·모델마다 바뀌었다 (프리미엄 → 표준 요금 대체 발표도 있었음). 구체 per-token 가격은 여기 적지 않는다 — 집계 기사 값이 first-party 와 충돌한다. 최신 값은 models-overview / prompt-caching 의 first-party 표로 확인하라.
thinking(추론) 토큰은 output 토큰으로 과금된다 — 보이지 않아도 청구된다. 롱컨텍스트 + 추론모델이면 비용이 곱으로 튄다. 상세는 reasoning-models.

함정 정리 (gotcha)

tiktoken 으로 모든 모델 토큰을 세는 습관 — Claude/Gemini 에서 틀린다.
"컨텍스트가 1M 이니 다 넣자" — 중간 정보는 묻히고(Lost in the Middle) recall 이 떨어진다.
한글 문서를 영어 기준 토큰 예산으로 잡기 — 약 4배 초과.
KV 캐시 ≠ 프롬프트 캐싱 혼동 — 전자는 못 만지고, 후자만 API 로 제어.
롱컨텍스트 요금 임계값 무시 — 한 큰 요청이 요금대를 통째로 올릴 수 있다.
thinking 토큰이 안 보인다고 공짜라 착각 — output 으로 과금된다.

언제 이걸 신경 쓰나 / 안 쓰나

상황	판단
짧은 단발 프롬프트 (수백 토큰)	토큰 최적화 신경 끄기. 그냥 usage 만 확인
긴 문서/대화 반복 처리	count_tokens 로 사전 예산 + 프롬프트 캐싱 검토
한글 대량 입력	예산 4배 + 시스템 프롬프트 영어화 고려
100K+ 컨텍스트 필요	Lost in the Middle 배치 + 롱컨텍스트 요금 확인
정확한 청구 대사(reconcile)	로컬 추정 버리고 응답 usage 사용

참고

context-engineering — 컨텍스트를 최소 고신호 토큰으로 큐레이션하는 전략 (compaction·note-taking·sub-agent)
reasoning-models — thinking 토큰이 output 으로 과금되는 구조와 effort 다이얼
prompt-caching — 프롬프트 캐싱의 최소 길이·TTL·요금 (KV 캐시와 다른 층위)
models-overview — 모델별 컨텍스트 크기·최대출력·요금 first-party 표
glossary — 토큰·컨텍스트 윈도우 용어 정의

출처: 개념은 프로바이더 중립. Anthropic 사실 = [HIGH] (context rot·과금), Lost in the Middle = [HIGH] (학술), 토크나이저/vocab/가격 세부 = [aggregator][MED] (공식 페이지 개별검증 전). 롱컨텍스트 가격 수치는 규격서 §7 first-party 우선 원칙에 따라 인용 생략. 원본 → 2026-07-25-concepts-core