LLM의 Context Window는 빠르게 커지고 있습니다. 이제 100만 토큰 이상의 컨텍스트를 지원하는 모델도 등장하면서 긴 문서나 대규모 코드베이스를 한 번에 다룰 수 있는 범위가 크게 넓어졌습니다.
그런데 최근 LLM 연구에서는 이와 반대처럼 보이는 움직임도 활발합니다. 불필요한 컨텍스트를 덜어내고, 긴 작업 기록을 압축하고, 중요도가 낮은 토큰에는 연산을 덜 쓰는 방식입니다. 처리할 수 있는 토큰은 늘리면서 실제 처리 과정에서는 토큰을 줄이는, 일종의 ‘토큰 다이어트(Token Diet)’입니다.
토큰 다이어트는 하나의 정식 기술을 가리키는 용어는 아닙니다. 실제로는 Context Pruning, Context Compression, Prompt Caching, Token Pruning, KV Cache Compression처럼 서로 다른 최적화 기술이 활용되고 있습니다. 이 기술들이 향하는 방향은 정보를 무작정 줄이기보다 현재 작업에 필요한 정보에 연산을 집중하는 것입니다.
짧은 프롬프트가 적은 토큰을 의미하지는 않습니다
AI Coding Agent에게 “이 오류의 원인을 찾아서 수정해 줘”라고 요청했다고 가정해 보겠습니다. 사용자가 입력한 문장은 한 줄이지만 실제 모델이 처리하는 정보는 훨씬 많습니다.
사용자의 요청 외에도 System Prompt와 프로젝트 규칙, 이전 대화, 관련 소스 코드, RAG 검색 결과, Tool Definition과 실행 결과 등이 함께 전달됩니다. 여러 Agent가 협업하는 구조라면 각 Agent가 만든 결과까지 다시 컨텍스트에 들어옵니다.
User Prompt + Rules + History + Code + RAG + Tools + Agent Results
작업이 길어지면 이 정보도 계속 쌓입니다. 처음에는 필요했던 검색 결과가 몇 단계 뒤에는 의미를 잃기도 하고, 이미 해결된 오류의 로그가 그대로 남아 있기도 합니다. 도구가 반환한 수백 줄의 결과 가운데 실제 판단에 필요한 내용은 몇 줄뿐인 경우도 있습니다.
이 때문에 Agent 환경의 토큰 최적화는 사용자가 입력하는 프롬프트 몇 줄을 줄이는 것만으로는 충분하지 않습니다. 오히려 모델이 작업 과정에서 계속 들고 다니는 컨텍스트를 어떻게 관리할 것인지가 더 큰 영향을 미칩니다.
100만 토큰을 넣을 수 있어도, 모두 넣을 필요는 없습니다
Context Window가 커지면서 대규모 문서나 코드베이스를 한 번에 전달하기는 쉬워졌습니다. 하지만 모델이 처리할 수 있는 최대 범위와 실제 작업에 적합한 컨텍스트 크기는 다릅니다.
LLM은 답변을 생성하기 전에 입력된 컨텍스트를 처리하는 Prefill 과정을 거칩니다. 이후 생성 단계에서는 앞서 계산한 Attention의 Key와 Value를 KV Cache에 저장해 재사용합니다. 입력이 길어지면 Prefill에서 처리할 연산이 늘어나고, 긴 컨텍스트를 유지할수록 KV Cache가 차지하는 메모리도 커집니다.
실제 가격 정책에서도 이런 차이가 나타납니다. OpenAI GPT-5.6은 100만 토큰 이상의 Context Window를 제공하지만, 27만 2천 토큰을 초과하는 긴 입력에는 일반 요청보다 높은 요율을 적용합니다.
결국 중요한 것은 Context Window를 얼마나 크게 확보했느냐보다 그 공간을 어떤 정보로 채우느냐입니다. 현재 작업과 관계없는 정보까지 계속 유지하면 넓어진 Context Window가 오히려 불필요한 연산 공간이 될 수 있습니다.
모든 토큰을 끝까지 처리할 필요가 있을까요?
최근 연구는 컨텍스트를 구성하는 단계뿐 아니라 모델 내부에서 토큰을 처리하는 방식까지 최적화하고 있습니다.
2026년 AAAI에 발표된 SlimInfer는 Long Context 추론 과정에서 토큰의 중요도를 동적으로 평가하고, 중요도가 낮은 토큰을 제거하는 Dynamic Token Pruning 방식을 제안했습니다. LongBench 성능을 유지하면서 Time to First Token(TTFT)은 최대 2.53배, 전체 응답 지연시간은 최대 1.88배 개선했습니다.
ACL 2026의 FastKV는 초기 레이어에서 전체 컨텍스트를 처리한 뒤 중요도가 높은 토큰을 선별해 이후 레이어로 전달합니다. 모든 토큰을 마지막까지 동일하게 처리하지 않는 방식으로 Prefill은 최대 1.82배, Decoding은 최대 2.87배 빨라졌습니다.
두 연구 모두 이미 확보한 Long Context 안에서도 정보의 중요도에 따라 연산 자원을 다르게 배분할 수 있다는 점에 초점을 둡니다.
이는 토큰 다이어트를 ‘프롬프트 길이 줄이기’ 정도로 설명하기 어려운 이유이기도 하며,실제 최적화는 모델에 정보를 넣기 전부터 추론이 끝날 때까지 여러 단계에서 이루어지고 있는 것을 알 수 있습니다.
토큰 다이어트는 어떻게 이루어질까요?
토큰이 낭비되는 지점이 서로 다른 만큼 최적화 방법도 구분해서 볼 필요가 있습니다.
1) 필요 없는 컨텍스트를 덜어내는 Context Pruning
Agent가 장시간 작업하면 이전 검색 결과와 Tool Output, 대화 기록이 계속 쌓입니다. 이 가운데 현재 작업과 관련성이 낮아진 정보를 골라 컨텍스트에서 제외하는 방식이 Context Pruning입니다.
예를 들어 이미 해결된 작업의 상세 로그나 현재 판단과 관계없는 검색 결과까지 계속 유지할 이유는 없습니다. 필요한 정보를 일괄적으로 줄이는 것이 아니라 작업이 진행되면서 가치가 낮아진 정보를 정리하는 방식입니다.
2) 긴 기록의 정보 밀도를 높이는 Context Compression
정보 자체는 필요하지만 원문 전체를 유지할 필요가 없는 경우에는 Context Compression을 활용합니다.
Agent가 수행한 수십 단계의 작업 기록을 그대로 가져가는 대신 어떤 방법을 시도했고, 무엇이 실패했으며, 어떤 결정을 내렸고, 현재 상태가 어디까지 진행됐는지를 중심으로 압축합니다.
이후 작업에 필요한 상태와 판단 근거를 남겨야 하기 때문에 단순 요약과도 조금 다릅니다. 장시간 수행되는 Agent에서는 과거 기록 전체보다 다음 행동을 결정하는 데 필요한 정보가 무엇인지가 더 중요합니다.
3) 필요한 정보만 가져오는 RAG
처음부터 모든 정보를 컨텍스트에 넣어두지 않고 필요할 때 외부 데이터에서 검색하는 방법도 있습니다.
대규모 코드베이스에서 특정 함수의 오류를 분석한다면 저장소 전체보다 해당 함수와 호출 관계, 관련 데이터 구조, 테스트 코드와 문서를 찾아 전달하는 편이 효율적입니다.
다만 RAG를 적용했다고 토큰이 자동으로 줄어드는 것은 아닙니다. 검색 범위를 지나치게 넓히거나 관련성이 낮은 문서를 함께 가져오면 오히려 컨텍스트가 커집니다. 토큰 효율 측면에서는 얼마나 많은 자료를 검색했는지보다 얼마나 관련성 높은 자료를 가져왔는지가 중요합니다.
4) 반복되는 컨텍스트를 재사용하는 Prompt Caching
시스템 프롬프트나 조직 정책, 공통 문서처럼 여러 요청에서 반복되는 정보도 있습니다. Prompt Caching은 이런 공통 Prefix를 다시 처리하지 않고 기존 연산 결과를 재사용합니다. 같은 정보를 계속 사용해야 한다면 매번 새로 계산하지 않는 방식입니다.
OpenAI GPT-5.6 Sol의 경우 2026년 9월 기준 일반 입력은 100만 토큰당 4달러, Cached Input은 0.40달러입니다. 반복되는 컨텍스트가 많은 서비스에서는 무엇을 없앨지뿐 아니라 무엇을 재사용할지도 비용 최적화에 큰 영향을 줍니다.
5) 추론 과정의 메모리를 줄이는 KV Cache Compression
최적화는 모델에 정보를 전달한 이후에도 이어집니다. LLM은 이전 토큰의 Attention 정보를 KV Cache에 저장해 다음 토큰을 생성할 때 활용하는데, Long Context에서는 이 KV Cache가 GPU 메모리의 주요 병목 가운데 하나가 됩니다.
Microsoft Research가 2026년 발표한 VeriCache는 압축된 KV Cache로 토큰을 생성하고 원본 KV Cache를 이용해 결과를 검증하는 방식을 제안했습니다. 전체 KV Cache를 사용하는 방식과 동일한 출력을 유지하면서 최대 4배 높은 처리량을 기록했습니다.
Context Pruning이 모델에 무엇을 보여줄지 결정한다면 KV Cache Compression은 들어온 정보를 모델이 어떻게 효율적으로 유지할지 다룹니다. 모두 토큰 효율과 관련돼 있지만 실제로 작동하는 단계는 다릅니다.
프롬프트 엔지니어링보다 컨텍스트 엔지니어링?
생성형 AI 초기에는 좋은 답변을 얻기 위해 프롬프트를 어떻게 작성할지가 주요 관심사였다면, AI Agent가 등장하면서는 모델에 어떤 지시를 내릴지뿐 아니라 작업에 필요한 정보를 어떻게 구성해서 전달할지가 중요해졌습니다.
이런 접근을 컨텍스트 엔지니어링이라고 합니다. 특히 Agent는 작업 과정에서 새로운 정보를 계속 만들어냅니다. 검색 결과와 코드, 도구 실행 결과, 다른 Agent가 만든 결과까지 모두 컨텍스트 후보가 됩니다. 이 정보를 전부 유지할 수도 없고, 오래됐다는 이유로 무작정 버릴 수도 없습니다.
어떤 정보는 그대로 유지하고, 긴 기록은 압축하며, 반복되는 부분은 캐시하고, 필요할 때 다시 검색하는 식으로 컨텍스트의 흐름을 설계해야 합니다.
AI Coding에서는 전체 코드보다 관련 코드가 중요합니다
이 차이는 AI Coding에서 더욱 분명하게 드러납니다. 규모가 큰 프로젝트에는 소스 코드뿐 아니라 요구사항, API 명세, 테스트, 코딩 규칙, 기술 문서와 Git 이력까지 AI가 참고할 수 있는 정보가 방대합니다. 따라서 Context Window가 충분히 크더라도 이 모든 정보를 매번 전달하는 방식은 효율적이지 않습니다.
또한 특정 오류를 분석하는 데 실제로 필요한 범위는 문제가 발생한 함수와 호출 관계, 관련 데이터 구조, 의존 코드와 테스트 정도일 수 있습니다.
사용자 질문 → 관련 코드 탐색 → 의존 관계 분석 → 필요한 코드·문서 선별 → Context 구성 → LLM
이 구조에서는 Context Window의 최대 크기보다 코드 구조를 얼마나 정확하게 파악하고 관련 정보를 찾아내느냐가 중요합니다. 관련 없는 코드가 많이 들어가면 컨텍스트만 비대해지고, 반대로 필요한 의존 관계를 놓치면 긴 컨텍스트를 제공해도 분석 품질을 확보하기 어렵습니다.
그래서 AI Coding에서의 토큰 다이어트는 문제를 해결하는 데 필요한 코드를 더 정확하게 읽게 만드는 과정에 가깝다고 볼 수 있습니다.
토큰 다이어트, 적게 쓰는 것보다 잘 쓰는 것
2026년의 LLM 기술을 보면 흥미로운 두 흐름이 동시에 나타납니다. 한쪽에서는 Context Window가 계속 커지고 있고, 다른 한쪽에서는 Token Pruning과 Context Compression, KV Cache 최적화가 활발하게 연구되고 있습니다.
서로 반대되는 방향은 아닙니다. 더 많은 정보를 다룰 수 있는 기반을 확보하면서, 실제 작업에서는 필요한 정보에 연산을 집중하는 방향으로 발전하고 있습니다.
AI Agent가 복잡한 업무를 맡을수록 프롬프트 몇 줄을 줄이는 것만으로 얻는 효과는 제한적입니다. 어떤 정보를 유지하고, 어떤 정보는 압축하고, 무엇을 다시 검색하며, 반복되는 정보는 어떻게 재사용할지까지 함께 설계해야 합니다.
