원본 캡처

핵심 개념: 토큰/컨텍스트 · 컨텍스트 엔지니어링 · 추론모델 리서치 원본 — 2026-07-25

불변 캡처. 절대 편집하지 마라. 가공본은 위키 페이지에. 근거 우선순위: Anthropic 1차 문서(platform.claude.com, anthropic.com) = [HIGH]. 학술 원논문(Stanford/TACL) = [HIGH]. 블로그·집계 사이트 = [MED]. 개념 자체는 프로바이더 중립으로 서술하되, API 세부값은 Anthropic 근거를 씀(규격서 §7 대조).

조사 방법

검색어

  1. tokenizer differences between models same text different token count tiktoken Claude
  2. context engineering 2025 replacing prompt engineering compaction context editing memory Anthropic
  3. reasoning models thinking tokens billing adaptive thinking effort when reasoning models not worth it
  4. lost in the middle long context performance degradation research findings KV cache
  5. Anthropic long context pricing tier above 200k tokens premium rate context editing memory tool beta

WebFetch 로 실제 열어본 URL (본문 추출)

  • [HIGH] https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents — Anthropic 엔지니어링 블로그, "Effective context engineering for AI agents"
  • [HIGH] https://platform.claude.com/docs/en/build-with-claude/extended-thinking — Anthropic 공식 docs, Extended thinking
  • [HIGH] https://platform.claude.com/docs/en/build-with-claude/thinking-steering-and-cost — Anthropic 공식 docs, Steering thinking (pricing/cost 포함)
  • [HIGH] https://cs.stanford.edu/~nfliu/papers/lost-in-the-middle.arxiv2023.pdf — Nelson F. Liu 외, "Lost in the Middle: How Language Models Use Long Contexts" (원논문 PDF)
  • [MED] https://dev.to/gabrielanhaia/tokenizer-quirks-claude-gpt-and-gemini-dont-count-the-same-text-the-same-way-1522 — 토크나이저 차이 실측 블로그

검색 결과로만 확인(개별 fetch 안 함, 집계·2차)

  • [MED] https://thenewstack.io/claude-million-token-pricing/ — 롱컨텍스트 프리미엄 요금 변경
  • [MED] OpenAI docs "Reasoning models" (developers.openai.com/api/docs/guides/reasoning) — reasoning 토큰이 output 토큰으로 과금
  • [MED] OpenRouter "Reasoning Tokens" 가이드
  • [MED] 여러 토크나이저 비교 블로그(intuz, tokencalculator, agentwiki 등)

확인된 사실 [신뢰도]

(1) 토큰화 · 컨텍스트 윈도우

토크나이저는 모델마다 다르다 — 같은 텍스트가 모델별 토큰 수가 다름 - [MED] (dev.to) Claude / GPT / Gemini 는 어휘(vocabulary)가 서로 호환되지 않는 근본적으로 다른 토크나이저를 쓴다. 단일 토크나이저(보통 tiktoken)로 세 벤더 비용을 추정하면 실제 청구액과 10~15% 벌어질 수 있다. - [MED] OpenAI: cl100k_base(~100k vocab) = GPT-3.5/GPT-4. o200k_base(~200k vocab) = GPT-4o 및 o-시리즈, GPT-5 계열. - [MED] Gemini: SentencePiece Unigram 모델, 256k vocab. client.models.count_tokens(...) 로 접근(무료, 별도 rate limit). - [MED] Llama: Llama 2 는 32k SentencePiece → Llama 3 이후 tiktoken 스타일 BPE, 128,256 vocab. - [MED] 벤더 간 공통 계열성(BPE 계열 merge, 수십만 vocab)은 있지만 merge 테이블·vocab 크기·코드/공백/비라틴 문자 처리가 전부 다르다.

tiktoken 을 Claude 에 쓰면 틀린다 (핵심 함정) - [MED] (dev.to 인용) "Anthropic does not publish Claude's tokenizer... The supported way to know how many tokens a Claude request will cost is the token counting endpoint." - [MED] Claude 는 공개 토크나이저가 없다. 토큰 수를 아는 지원되는 방법은 POST /v1/messages/count_tokens 엔드포인트 호출뿐이다. - [HIGH] (규격서 §7 대조) 실제 청구는 응답의 usage 필드(input_tokens, output_tokens, output_tokens_details.thinking_tokens)가 authoritative. 로컬 근사 대신 이 값과 reconcile 하라.

토큰 수가 언어·콘텐츠 타입별로 갈리는 지점 - [MED] 영어 산문: 벤더 간 한 자릿수 % 편차(가장 관대). - [MED] 코드 블록: 10~20% 차이(학습 코퍼스에 맞춘 merge 테이블 때문). - [MED] 비라틴/CJK(한중일): cl100k_base 에서 대략 문자당 1토큰 — 같은 인코딩의 영어보다 약 4배 나쁨. (한국어 개발자에게 직접 해당: 한글은 영어보다 훨씬 토큰을 많이 먹는다.)

컨텍스트 윈도우 실제 동작 — Lost in the Middle - [HIGH] (Liu 외, Stanford) 논문 핵심: "language models exhibit degraded performance when relevant information appears in the middle of long documents, while performing better when data is positioned at the beginning or end." → U자형 성능 곡선. - [HIGH] 인용: 모델은 "worse performance when relevant information is in the middle of the input, compared to at the beginning or end." - [HIGH] 테스트한 태스크: (1) multi-document question answering, (2) key-value retrieval. - [HIGH] 실무 함의: 컨텍스트 길이가 성능을 보장하지 않는다. 정보의 "위치"가 정확도에 크게 영향 — 중요한 내용은 프롬프트의 처음이나 끝에 두라. 중간 위치가 병목. - 저자: Nelson F. Liu 등(Stanford). 발표: TACL(Transactions of the ACL) 게재된 것으로 알려진 2023 논문(PDF 파일명 arxiv2023).

컨텍스트 rot (Anthropic 용어) - [HIGH] (Anthropic context engineering 블로그) "context rot" — 토큰 수가 늘어날수록 모델이 정보를 정확히 recall 하는 능력이 떨어진다. "every new token introduced depletes this budget by some amount." LLM 의 "attention budget"은 사람 working memory 처럼 유한하다. - [HIGH] 아키텍처 병목: 트랜스포머는 모든 토큰이 다른 모든 토큰에 attend → n개 토큰에 n² pairwise 관계. 규모가 커지면 attention 이 얇게 퍼진다.

KV 캐시 (프로바이더 중립) - [MED] (검색 결과 종합) 컨텍스트가 커지면 KV(Key-Value) 캐시 성장에 따라 비선형 성능 저하. attention 이 전체 시퀀스에 대해 pairwise 비교 → "prefill" 지연 증가. GPU 가 실제 연산보다 KV 캐시를 HBM↔SRAM 사이로 옮기는 데 시간을 더 쓰는 "memory wall" 발생. - [MED] KV 캐시 압축 기법은 덜 중요한 토큰을 버리는데, 핵심 정보가 버려지면 성능이 크게 떨어질 수 있다. - 주: KV 캐시는 프롬프트 캐싱(Anthropic prompt caching)과 다른 층위 개념. KV 캐시 = 추론 시 attention 재계산 회피용 내부 캐시. 프롬프트 캐싱 = API 과금/재사용 기능.

롱컨텍스트 과금 구조 - [MED] (thenewstack) 과거: 요청이 대략 200,000 토큰을 넘으면 요청 전체가 "long-context" 프리미엄 요금대로 올라갔다(대략 2배 프리미엄). - [MED] 최근 변경: Anthropic 이 Claude Opus 4.6 / Sonnet 4.6 의 1M 토큰 윈도우를 GA 하면서, 임계값 넘으면 붙던 프리미엄 롱컨텍스트 요금을 표준 요금으로 대체했다고 발표. 900K 요청도 9K 요청과 같은 per-token 요금. - ⚠️ 이 집계 기사에 딸린 세부 가격(예: "Opus 4.6 $2.50/$12.50", "Sonnet 4.6 $1.50/$7.50")은 규격서 §7 first-party 표(Opus 4.6 = $5/$25, Sonnet 4.6 = $3/$15)와 충돌. §7 이 우선. 가격 수치는 인용하지 말 것 → "엇갈림" 섹션 참조.

(2) 컨텍스트 엔지니어링

정의 · 프롬프트 엔지니어링과의 차이 - [HIGH] (Anthropic) 컨텍스트 엔지니어링 = "the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference." - [HIGH] 프롬프트 엔지니어링은 "writing effective prompts, particularly system prompts"에 초점. 컨텍스트 엔지니어링은 개별 태스크 최적화 → 에이전트 lifecycle 전반의 반복적 큐레이션으로 이동. - [MED] (Sourcegraph/집계) 2025 중반에 이르러 숙련 AI 엔지니어들은 프롬프트 문구가 더는 주요 병목이 아니라고 파악. 진짜 문제는 매 턴 에이전트에게 올바른 파일·툴 정의·대화 이력 슬라이스·검색된 사실을 주면서 컨텍스트 윈도우가 무너지지 않게 하는 것.

컨텍스트 = 유한 자원 / 예산 배분 - [HIGH] (Anthropic) 지도 원칙: "the smallest set of high-signal tokens that maximize the likelihood of some desired outcome" — 원하는 결과 확률을 최대화하는 최소한의 고신호 토큰 집합을 찾아라. - [HIGH] 모든 새 토큰이 attention budget 을 소모한다는 전제에서 출발.

롱호라이즌(long-horizon) 3대 기법 (Anthropic 이 명시) - [HIGH] Compaction(압축): 컨텍스트 윈도우 한도에 가까워진 대화를 요약하고, 그 요약으로 "reinitiate a new context window with the summary". 이때 "architectural decisions, unresolved bugs, and implementation details"는 보존해야 한다. - [HIGH] Structured Note-Taking(구조화 노트/메모리): 에이전트가 "notes persisted to memory outside of the context window"를 유지 → working context 를 채우지 않고 긴 상호작용에서 일관성 유지. - [HIGH] Sub-Agent Architectures(서브에이전트로 컨텍스트 격리): 전문화된 에이전트가 "clean context windows"로 집중 태스크를 처리하고, "condensed, distilled summary of its work"를 반환. → 서브에이전트가 컨텍스트를 격리하는 메커니즘.

컨텍스트 편집(context editing) - [MED] (집계) Context editing = scaffold 내부에서 규칙 기반 pruning(가지치기)을 적용해 컨텍스트 윈도우를 통제. (compaction=요약 재시작, editing=규칙 기반 제거로 구분)

메모리 · 툴 결과 오프로딩 - [MED] (집계) Memory 툴 = 대화 간 지속 저장/검색. memory 파일의 create/read/update/delete 로 세션을 넘어 유지. - [HIGH] (Anthropic) 툴 결과 오프로딩 = 노트를 컨텍스트 윈도우 "바깥"의 메모리에 두는 것이 핵심(structured note-taking 과 동일 아이디어). 대용량 툴 산출물을 컨텍스트에 다 넣지 말고 외부에 두고 요약/참조만. - [MED] (alternativeto/집계) Anthropic memory 기능은 이전 대화 정보를 참조하게 함. 초기엔 Enterprise/Team/Max 등 특정 티어에만 제공(설정 기반), 이후 확대 예정.

(3) 추론모델(reasoning models)

무엇이 다른가 - [HIGH] (Anthropic) Claude 의 thinking 은 adaptive: 모델이 매 요청마다 스스로 "생각할지 / 얼마나 생각할지"를 판단. 단순 사실 질문은 thinking block 없이 바로 답, 다단계 수학·까다로운 디버깅은 더 깊게 추론. - [HIGH] 결정은 요청 단위(per request). 같은 대화 안에서 thinking 있는 턴과 없는 턴이 섞인다. "모든 assistant 턴이 thinking block 으로 시작한다"고 가정하는 앱 로직을 짜지 마라. - [HIGH] thinking 은 tool use 와 자동으로 interleave(툴 호출 사이에 생각). 베타 헤더나 추가 설정 불필요(현행 adaptive 모델).

thinking / reasoning 토큰 과금 (핵심) - [HIGH] (Anthropic) thinking 토큰은 output 토큰으로 과금된다. - [HIGH] 과금 대상 3가지: (1) 생각하며 쓴 토큰(output 으로), (2) 컨텍스트에 남은 이전 턴 thinking block(preservation 기본값에 따라 — keep-all 모델은 전 턴, 그 외는 마지막 턴만; input 토큰으로 과금), (3) 표준 텍스트 출력 토큰. - [HIGH] ⚠️ 청구 output 토큰 수 ≠ 응답에서 보이는 토큰 수. "You are billed for the full thinking process, not the thinking content visible in the response." display: "summarized" 든 "omitted"든 과금은 동일 — 내부에서 생성한 full thinking 토큰 전부 과금. 요약 생성 자체는 무료. - [HIGH] 관측: usage.output_tokens_details.thinking_tokens 가 내부 추론에 쓴 billed output 토큰 수. output_tokens 이하이며, 스트리밍 시 최종 message_delta 이벤트에만 나타남. 예시 usage: {input_tokens:25, output_tokens:348, output_tokens_details:{thinking_tokens:312}}. - [MED] (OpenAI/OpenRouter) 프로바이더 중립으로도 동일: reasoning 토큰은 output 토큰으로 과금, 사용량을 늘리지만 응답 품질을 크게 개선할 수 있음. - [MED] (aioutlooks 블로그) 500 visible-token 답변이 thinking 포함 시 총 2,000~3,000 토큰 과금으로 불어날 수 있고, 장문 분석은 8,000~16,000 토큰대에 흔히 안착. (정성적 참고, 수치는 예시)

adaptive thinking · effort 개념 (Anthropic) - [HIGH] 현행은 thinking: {type: "adaptive"}. 구식 수동 모드 thinking: {type:"enabled", budget_tokens:N} 는 Claude 4.6 에서 deprecated(요청은 성공), 4.7 이상은 400 에러로 거부. - [HIGH] 수동 모드 budget_tokens 규칙(레거시 모델): 최소 1,024 토큰(더 작으면 거부), max_tokens 보다 작아야 함(interleaved 예외), 실제 사용량은 target 이지 hard cap 아님(hard cap 은 max_tokens). budget 16,000+ 이면 복잡 태스크 권장, 32k 넘으면 batch 처리 권장(타임아웃 회피). - [HIGH] adaptive 로 마이그레이션: budget_tokens 제거 → thinking:{type:"adaptive"} + output_config:{effort: "..."}. 동작 차이: 고정 budget 은 매 요청 생각, adaptive 는 요청마다 생각 여부/양을 결정하고 낮은 effort 에선 쉬운 입력에 생각을 아예 건너뛸 수 있음. - [HIGH] effort 레벨 (output_config.effort, thinking 객체 안이 아님. 기본값 high): - max: 항상 생각, 깊이 제약 없음 - xhigh: 항상 깊게, 확장 탐색 - high(기본): 거의 항상 생각, 복잡 태스크 깊은 추론 - medium: 중간 정도, 단순 쿼리는 생각 건너뛸 수 있음 - low: 생각 최소화, 속도 중요한 단순 태스크는 생각 건너뜀 - [HIGH] effort 는 벤더 표현이지만 개념(추론 노력 다이얼)은 프로바이더 중립적으로 존재. OpenAI 도 reasoning effort 유사 개념.

비용 통제 (Anthropic) - [HIGH] adaptive 에선 thinking 토큰 budget 을 직접 설정하지 않는다. 두 레버: (1) max_tokens = thinking+답변 합친 출력 총량 hard cap, (2) effort = 그 출력 중 얼마를 thinking 에 쓸지 soft 가이드. - [HIGH] thinking 이 max_tokens 에 포함되므로 추론+답변 둘 다 들어갈 만큼 크게 잡아라. thinking 없을 때 기준으로 잡은 max_tokens 는 하드 요청에서 종종 너무 작다. - [HIGH] stop_reason: "max_tokens" 가 뜨면: (a) max_tokens 올리거나 (b) effort 낮춰 thinking 줄이기. 잘린 응답이 추론이 필요했으면 cap 올리고, over-think 였으면 effort 낮춰라. - [HIGH] 프롬프트 캐싱 상호작용: effort 값이 프롬프트에 렌더링되므로 요청 간 effort 변경은 cache breakpoint 를 무효화(레거시 budget_tokens 변경과 동일). 대화 수명 동안 effort 를 고정하라. per-message 프롬프트 steering(최신 user 메시지에 문구 추가)은 캐시를 깨지 않음. (문서 실측 예: effort high→medium 바꾼 3번째 요청이 cache_creation_input_tokens=3546, cache_read=0 로 캐시 재생성)

thinking 조종(steering) — 언제/얼마나 - [HIGH] 1순위 레버는 effort. 생각을 덜 하게 하려면 프롬프트 손대기 전에 effort 를 낮춰라("calibrated control rather than a wording-sensitive instruction"). - [HIGH] 보조: system prompt 가이드("...should only be used when it will meaningfully improve answer quality... When in doubt, respond directly."), per-message steering("Please think hard before responding." / "Answer directly without deliberating.").

언제 추론모델이 손해인가 - [MED] (tianpan.co 블로그) 많은 개발자가 extended thinking 을 켜고 effort 파라미터를 조정하지 않아, thinking 이 이득 없는 요청에도 thinking 토큰을 낸다. "reasoning-effort discipline" 있는 팀은 필요한 쿼리엔 추론 품질을, 불필요한 쿼리엔 비추론 모델의 비용 프로파일을 얻는다. - [MED] 손해 케이스 요약: (a) 단순/사실 조회 대량 트래픽 — 추론이 품질을 안 올리는데 토큰만 배로 냄, (b) 지연(latency) 민감 — thinking 이 응답을 늦춤, (c) effort 를 항상 high 로 방치, (d) 32k 넘는 budget 은 장시간 요청/타임아웃 유발. - [HIGH] (Anthropic) 반대로 이득: trivial+complex 가 섞인 워크로드, 스텝마다 적정 추론량이 달라지는 long-horizon 에이전트 워크플로우에 강함. thinking 을 덜 시키면 추론이 도움 되는 태스크에서 품질이 떨어질 수 있으니 워크로드에서 측정 후 배포.

엇갈리거나 미확인

  • ⚠️ 비Anthropic 프로바이더 가격/토크나이저 세부값: dev.to·집계 블로그 기반 [MED]. cl100k_base/o200k_base vocab 크기, Gemini 256k, Llama 128,256 등은 널리 인용되나 각 프로바이더 공식 페이지로 개별 검증 안 함. 위키에선 [aggregator][MED] 표기 필수.
  • ⚠️ 롱컨텍스트 가격 수치 충돌: thenewstack/집계가 "Opus 4.6 $2.50/$12.50, Sonnet 4.6 $1.50/$7.50, >200K 2배 프리미엄" 언급하나 규격서 §7 first-party 표는 Opus 4.6=$5/$25, Sonnet 4.6=$3/$15. §7 이 맞다. 구체 per-token 가격은 위키에 인용하지 말고 "임계값 넘으면 프리미엄 요금대로 올라가는 롱컨텍스트 과금 구조가 존재/변화해왔다"는 정성적 사실만 사용.
  • "context editing" vs "memory tool" 제품 경계: 개념 설명은 집계 출처 [MED]. Anthropic 이 별도 베타 제품으로 "context editing", "memory tool" 을 어떤 정확한 API 헤더/이름으로 내놨는지는 이번에 1차 확인 못 함. Anthropic 블로그는 compaction/note-taking/sub-agent 3기법만 명시. 위키에서 제품명 단정 금지, "기법(패턴)" 수준으로 서술 권장.
  • KV 캐시 세부 수치("40% 손실", "Gemini 1.5 recall ~60%"): 검색 스니펫에 나왔으나 출처가 미검증 블로그/의심 arxiv. 규격서 §5(벤치 점수 인용 금지)에 따라 수치 인용 금지**. 정성적으로만("길이가 늘면 recall 이 떨어진다").
  • 의심 출처(future-dated arxiv): 검색에 arxiv.org/pdf/2601.*, 2603.*, 2604.*, 2605.* 등 2026년 이후 날짜 프리프린트가 다수 반환됨 — 존재/진위 미검증. 인용 금지(아래 박스).
  • Lost in the Middle 정확한 게재 연도/venue: PDF 파일명이 arxiv2023, TACL 게재로 알려져 있으나 fetch 로 venue 문자열을 직접 확정하진 못함. "2023년 발표, Nelson Liu 외" 정도로만.
  • thinking_tokens 필드가 모든 모델/플랫폼에서 동일하게 채워지는지: Anthropic docs 기준 [HIGH]이나 Bedrock/Vertex 응답 형태 차이는 미확인.

⛔ DO-NOT-CITE (의심 출처)

인용 금지 박스. 아래는 검색에 잡혔으나 진위 미검증 — 위키에 절대 인용하지 마라. - future-dated arxiv 프리프린트: arxiv.org/pdf/2601.11564, 2602.07962, 2602.23047, 2603.09619, 2603.20397, 2604.08426, 2605.08580, 2605.16638, 2605.23296 등. 2026년 이후 날짜 ID 이며 내용 검증 불가. - 위 스니펫의 정량 수치("40% context degradation", "recall ~60%", 특정 per-token 가격) — 미검증 2차/집계. 규격서 §5 벤치·수치 인용 금지 원칙과 겹침.

원문 발췌 (핵심 인용)

Anthropic — context engineering

"the set of strategies for curating and maintaining the optimal set of tokens (information) during LLM inference" "every new token introduced depletes this budget by some amount" "context rot — as tokens increase, models struggle to recall information accurately" "the smallest set of high-signal tokens that maximize the likelihood of some desired outcome" Compaction: "reinitiate a new context window with the summary" (보존: "architectural decisions, unresolved bugs, and implementation details") Note-taking: "notes persisted to memory outside of the context window" Sub-agents: "clean context windows" / "condensed, distilled summary of its work"

Anthropic — steering thinking / pricing

"Thinking incurs charges for: Tokens Claude uses while thinking (billed as output tokens)" "You are billed for the full thinking process, not the thinking content visible in the response." effort 기본값 high. output_config.effort 위치(thinking 객체 밖). "You don't set a thinking token budget. Two controls bound cost: max_tokens ... effort ..."

Anthropic — extended thinking (레거시 수동 모드)

budget_tokens 최소 1,024, max_tokens 미만, target(hard cap 아님). 마이그레이션: remove budget_tokens, set thinking:{type:"adaptive"}, control depth with output_config:{effort:...}. "With adaptive thinking, Claude decides whether and how much to think on each request, and at lower effort settings it may skip thinking entirely on easy inputs."

Liu 외 — Lost in the Middle

"worse performance when relevant information is in the middle of the input, compared to at the beginning or end" 태스크: multi-document QA, key-value retrieval. U자형 곡선.

dev.to — 토크나이저

"Anthropic does not publish Claude's tokenizer... The supported way to know how many tokens a Claude request will cost is the token counting endpoint." CJK on cl100k_base ≈ 1 token/char ≈ 영어의 4배.