컨텍스트 윈도우: 왜 100만 토큰 모델은 20만 토큰밖에 제대로 쓰지 못하는가

컨텍스트 윈도우(Context Window)의 크기는 GPT-3 시절의 2,048토큰에서 라마 4 스카우트(Llama 4 Scout)의 1,000만 토큰에 이르기까지, 불과 5년 사이에 5,000배나 폭증했다. 이제 최첨단 모델들은 단 한 번의 프롬프트에 전체 코드베이스, 수십 권 분량의 서적, 심지어 몇 시간짜리 오디오와 비디오까지 통째로 집어넣을 수 있다고 선전한다.

하지만 모델의 스펙 시트 그 어디에도 적혀 있지 않은 공공연한 비밀이 있다: 광고되는 컨텍스트 용량과 실제로 유효하게 작동하는 컨텍스트 용량은 결코 같지 않다는 점이다. 100만 토큰을 지원한다고 광고하는 모델도 실제로는 20만~60만 토큰 언저리에서부터 신뢰성이 급격히 무너지기 시작한다. 이 간극을 이해하느냐 못 하느냐가 실전 프로덕션 시스템과, 핵심 정보를 조용히 누락해 버리는 실패한 시스템을 가르는 결정적 차이다.

컨텍스트 윈도우가 실제로 어떻게 동작하는지, 어떤 기술적 도약이 이러한 거대한 확장을 가능하게 했는지, 그리고 그 간극을 메우기 위해 실무에서 무엇을 해야 하는지 짚어본다.

컨텍스트 윈도우의 본질

컨텍스트 윈도우란 LLM이 단 한 번의 순방향 연산(forward pass)에서 처리할 수 있는 입력 토큰과 출력 토큰의 총합이다. 시스템 프롬프트, 개발자 지침, 대화 기록, RAG로 검색된 문서, 도구 정의 및 실행 결과, 멀티모달 첨부 파일, 현재 사용자의 입력, 그리고 모델 자신이 생성해야 할 응답 공간까지 모든 것이 이 한도 안에 들어맞아야 한다.

이것은 모델의 장기 기억이 아니다. 학습 데이터도 아니다. 영구적인 지식 또한 아니다. 이것은 오직 GPU 메모리에 상주하며 현재 활성화된 모든 토큰의 키(Key)와 값(Value) 벡터를 보관하는 **활성 KV 캐시(active KV cache)**일 뿐이다. 토큰이 이 윈도우 바깥으로 밀려나는 순간, 모델은 해당 생성 단계에서 그 토큰의 존재 자체를 물리적으로 인지하지 못한다.

반드시 구분해야 할 세 가지 개념이 있다:

컨텍스트 윈도우(Context Window) — 모델이 시야에 담을 수 있는(see) 최대 범위.
주의 집중 폭(Attention Span) — 시야에 담긴 텍스트 중 실제로 활용할 수 있는(use) 범위.
수학적 한계(Mathematical Boundary) — 연산량과 GPU VRAM이 허용하는 절대적인 상한선.

윈도우는 “바라볼 수 있는가”를 뜻하고, 집중 폭은 “제대로 이해했는가”를 뜻하며, 한계선은 “GPU가 그 연산 비용을 감당할 수 있는가”를 뜻한다.

글자가 아닌 토큰의 세계

윈도우의 단위는 글자나 단어가 아니라 토큰이다. 대략적인 기준은 다음과 같다:

영어 기준 1토큰 ≈ 약 0.75단어
1토큰 ≈ 약 4글자 (한국어는 토크나이저에 따라 단어당 토큰 수가 더 많이 소모된다)
1,000토큰 ≈ 750단어 ≈ A4 용지 1~2장
500페이지짜리 두꺼운 책 한 권 ≈ 약 15만~20만 토큰
톨스토이의 전쟁과 평화 전체 ≈ 약 75만 토큰

프로그래밍 소스 코드, 법률 문서, 표, JSON, XML은 일반적인 산문보다 단어당 훨씬 더 많은 토큰을 생성한다. 비디오 1시간 분량은 멀티모달 인코더를 통과할 때 약 50만 토큰을 소모한다.

모든 요소가 예산에 포함된다

대부분의 사람들은 사용자의 질문만이 컨텍스트를 차지한다고 생각한다. 그렇지 않다. 전체 예산에는 다음의 모든 것이 포함된다:

+--------------------------------------------------+
| 시스템 프롬프트 (System Prompt)                  |
+--------------------------------------------------+
| 개발자 및 시스템 운영 지침                       |
+--------------------------------------------------+
| 이전 대화 기록 (Conversation History)            |
+--------------------------------------------------+
| RAG로 검색된 외부 문서들                         |
+--------------------------------------------------+
| 도구 정의(Tools) 및 도구 실행 결과값             |
+--------------------------------------------------+
| 멀티모달 첨부 파일 (이미지, 오디오 등)           |
+--------------------------------------------------+
| 현재 사용자의 프롬프트                           |
+--------------------------------------------------+
| 모델이 출력할 예약 공간 (Reserved Output)        |
+--------------------------------------------------+

출력 예약 공간은 입력 예산보다 훨씬 작게 설정되는 경우가 많다. 100만 토큰 입력을 지원하는 모델이라도 한 번에 생성할 수 있는 출력은 12만 8천 토큰으로 제한되는 식이다.

병목의 실체: O(n²) 연산과 KV 캐시

현대 LLM의 근간인 트랜스포머는 모든 토큰에 대해 쿼리(Q), 키(K), 밸류(V) 세 가지 벡터를 계산하고 다음 어텐션을 수행한다:

$$\text{Attention}(Q, K, V) = \text{softmax}!\left(\frac{QK^\top}{\sqrt{d_k}}\right)V$$

이 과정에서 모든 토큰과 다른 모든 토큰 간의 상관관계를 나타내는 $n \times n$ 어텐션 행렬이 만들어진다. 즉, 컨텍스트 길이가 2배로 늘어나면 어텐션 연산량은 4배로 폭증한다.

여기에 훨씬 더 현실적인 제약이 따른다: 바로 **KV 캐시(KV Cache)**다. 텍스트를 한 토큰씩 생성할 때마다 이전 토큰들의 연산을 매번 처음부터 다시 하지 않으려면, 이미 처리된 모든 토큰의 Key와 Value 벡터를 메모리에 캐싱해 두어야 한다:

$$\text{KV Cache} \approx 2 \times \text{layers} \times \text{num_kv_heads} \times \text{head_dim} \times \text{seq_len} \times \text{bytes_per_param}$$

실제 크기를 가늠해 보자: 70B 모델이 FP16 정밀도로 12만 8천 토큰의 컨텍스트를 처리하려면, 사용자 단 한 명당 약 40~80GB의 KV 캐시 메모리가 필요하다. 훈련 단계의 문제를 해결하고 난 뒤에도 롱 컨텍스트 서비스를 프로덕션에 배포하는 비용이 천문학적인 이유가 바로 여기에 있다. 진짜 자원의 병목은 추상적인 윈도우 스펙이 아니라 이 흉포한 KV 캐시다.

4K에서 1,000만 토큰으로: 엔지니어링 혁신들

이 거대한 도약은 단순히 GPU 덩치를 키워서 이룬 것이 아니다. 세 가지 독립적인 혁신이 층층이 결합된 결과다.

1. 외삽(Extrapolation)이 가능한 위치 인코딩

트랜스포머는 토큰들을 병렬로 처리하기 때문에 토큰의 순서(위치) 정보를 명시적으로 주입해 주어야 한다. 초기의 절대 위치 임베딩은 한계가 명확했다. 0~2047번 위치로 학습된 모델에게 2048번 위치를 보여주면 연산이 그대로 깨져버렸다.

**RoPE(Rotary Position Embeddings)**는 복소수 공간에서 토큰 임베딩을 회전시킴으로써 상대적 위치를 인코딩한다:

$$q_m = R_m W_q x_m$$

토큰 사이의 상대적 거리는 내적 연산($q_m^\top k_n$) 속에서 자연스럽게 드러난다. 우아한 방식이지만, 예를 들어 4K 거리까지만 학습된 모델에게 갑자기 10만 토큰 거리를 보여주면 회전 각도가 너무 빨라져 표현력이 무너지는 한계가 있었다.

이를 해결한 것이 RoPE 스케일링 기법들이다:

위치 보간 (Positional Interpolation, PI): 모든 위치 인덱스를 스케일 계수로 나눈다. 단순하지만 고해상도 정보가 뭉개진다.
NTK-aware 스케일링: 원거리의 저주파는 과감하게 압축하고, 국소적인 세부 사항을 담은 고주파는 그대로 보존한다.
YaRN: 주파수 대역별로 어텐션 가중치를 정교하게 보정한다. Llama 2의 4K 모델을 약간의 미세조정만으로 128K까지 늘려놓은 주역이다.
LongRoPE / PoSE: 윈도우 내부의 위치를 건너뛰며 시뮬레이션함으로써 극단적으로 긴 위치를 학습시킨다.

2. 어텐션 엔지니어링 (수학은 그대로, 속도는 극대화)

**FlashAttention (v1 → v3)**은 수학적 어텐션 공식을 전혀 바꾸지 않는다. 여전히 정확한(exact) 어텐션을 계산한다. 달라진 것은 메모리 접근 방식이다. GPU의 메모리 계층 구조를 인식하여 연산을 타일링(tiling)함으로써, 거대한 $n \times n$ 행렬이 느린 HBM(고대역폭 메모리)에 통째로 적재되는 것을 막는다. 연산 데이터는 초고속 온칩 SRAM 안에서만 맴돈다. 메모리 입출력 트래픽을 $O(N^2)$에서 선형 $O(N)$으로 줄여버린 결과, 롱 컨텍스트 속도가 2~4배 빨라졌다. FlashAttention-3는 H100 GPU에서 약 1.3 PFLOPs/s의 성능을 뿜어낸다.

**GQA(Grouped-Query Attention)**는 여러 쿼리 헤드가 소수의 KV 헤드를 공유하게 만들어 KV 캐시 용량을 4~8배 절감한다. **MLA(Multi-Head Latent Attention)**는 한 걸음 더 나아가 KV를 잠재 공간으로 압축하여 캐시 크기를 극단적으로 줄인다.

**PagedAttention (vLLM)**은 OS의 가상 메모리 페이징 기법을 KV 캐시에 도입하여 메모리 조각화를 사실상 0으로 만들고 요청 간 캐시 공유를 가능하게 했다.

Ring Attention / 블록 단위 병렬 어텐션은 긴 시퀀스를 링(ring) 형태로 연결된 여러 GPU에 분산시킨다. 각 GPU가 시퀀스의 일부를 쥐고 통신과 어텐션 연산을 완벽하게 겹쳐서 수행함으로써, 시퀀스 수용 용량을 GPU 대수에 비례해 선형적으로 확장한다.

**슬라이딩 윈도우 어텐션(Sliding Window Attention)**은 각 토큰이 고정된 주변 이웃 토큰들만 참조하게 하여 연산량을 $O(n)$으로 낮춘다. 여러 레이어가 쌓이면서 CNN의 수용 영역처럼 정보가 전체 컨텍스트로 퍼져나간다.

KV 캐시 양자화는 캐시된 값을 INT8이나 INT4로 내려 메모리를 2~4배 아낀다. StreamingLLM은 프롬프트 맨 앞의 토큰 몇 개를 일종의 ’어텐션 싱크(attention sink)’로 활용하여 영구적인 스트리밍 대화를 가능케 한다.

3. 대안 아키텍처

**상태 공간 모델(State-Space Models: Mamba, RWKV, RetNet)**은 $O(n^2)$ 어텐션을 완전히 우회한다. 과거의 모든 대화 기록을 순환 상태(recurrent state)로 압축하여 $O(n)$의 연산과 일정한 메모리 점유율을 유지한다. 극단적으로 긴 시퀀스에 매우 유리하지만, 프롬프트 내부의 특정 세부 정보를 정밀하게 다시 찾아내는 능력(retrieval)은 트랜스포머보다 떨어지는 경향이 있다. 때문에 2026년 현재 대다수 프론티어 모델은 여전히 순수 트랜스포머이거나 Mamba와 어텐션을 결합한 하이브리드 형태(Jamba 방식)를 취하고 있다.

문맥 중간에서의 실종 (Lost in the Middle)

공식 윈도우 크기 안이라 하더라도 모델이 모든 토큰에 균등한 주의를 기울이는 것은 아니다. 검색 및 인지 성능은 뚜렷한 U자형 곡선을 그린다: 앞부분(초두 효과)과 뒷부분(최신 효과)은 기가 막히게 기억하지만, 그 긴 문맥의 한가운데 파묻힌 정보는 심각할 정도로 놓친다.

그 하락 폭은 실로 뼈아프다: 중간에 묻힌 내용에 대한 정확도는 30~40%까지 추락한다. 심지어 4K 수준의 짧은 컨텍스트에서도 75%였던 정확도가 55~60%로 곤두박질치는 일이 비일비재하다.

주된 원인으로는 두 가지가 꼽힌다:

10만 개가 넘는 토큰에 걸쳐 소프트맥스(softmax)를 취하다 보면 어텐션 가중치가 지나치게 희석되어 신호가 노이즈 속에 묻혀버린다.
사전 학습에 사용된 대다수 데이터가 실제로 10만 토큰에 걸친 긴 추론을 요구하는 구조가 아니었으며, 상당 부분이 무의미한 패딩이었기 때문이다.

이 현상은 멀티턴 대화에서도 고스란히 재현된다. 긴 대화 기록의 앞이나 중간 단계에서 사용자가 내렸던 지침을 모델이 은근슬쩍 까먹고 지나치는 이유가 바로 여기에 있다.

스펙 시트와 유효 용량 사이의 괴리

가장 흔히 쓰이는 벤치마크는 **건초더미 속 바늘 찾기(Needle-In-A-Haystack, NIAH)**다: 50만 토큰의 노이즈 텍스트 속에 팩트 하나를 숨겨두고 찾아내게 하는 시험이다. 현재의 프론티어 모델들은 전체 윈도우에 걸쳐 95% 이상의 점수를 기록하며 단일 바늘 찾기 문제는 사실상 정복했다.

그러나 텍스트 전반에 흩어져 있는 여러 단서를 종합해 결론을 도출해야 하는 RULER(다단계 추론) 테스트로 넘어가면 이야기가 완전히 달라진다.

2026년 기준, 광고된 용량과 실제 유효 용량의 실상은 다음과 같다:

모델	광고된 스펙	실제 유효 용량	특징 및 평가
Claude Sonnet 4.x	100만	~60만–70만	롱 컨텍스트 환경에서 매우 견고한 검색력
Gemini 3.0 Pro	200만	~120만–140만	멀티모달 롱 컨텍스트에서 최강의 성능
Llama 4 Scout	1,000만	~600만–700만	업계 최대 수준의 압도적인 윈도우
GPT-5.2	40만	~25만–30만	출력 생성 윈도우가 넉넉함

모델들은 통상 제조사가 공표한 한계치의 30~40% 전부터 오동작을 일으킨다. KV 캐시 조각화, 어텐션 수치 불안정, 위치 인코딩의 표류, 그리고 토큰 노이즈의 누적이 복합적으로 작용하기 때문이다.

임계점을 넘어서면 모델은 컨텍스트 부패(Context Rot) 현상을 보인다. 사전 학습된 지식을 활용하지 못하고 눈앞의 프롬프트에 병적으로 집착하거나, 이전에 했던 말을 무의미하게 반복하며 복잡한 추론의 일관성을 상실한다.

토큰의 양보다 중요한 것은 토큰의 질이다. 18개 프론티어 모델을 비교 분석한 결과, 문서의 명확성, 계층적 구조, 시맨틱 밀도가 단순한 윈도우 크기보다 최종 정확도에 훨씬 더 결정적인 영향을 미쳤다. 엉망으로 작성된 업무 매뉴얼(SOP)은 100만 토큰 윈도우에 집어넣어도 엉망인 답을 낼 뿐이다.

롱 컨텍스트 vs RAG: 대체재가 아닌 상호 보완재

“100만 토큰 시대가 왔으니 RAG는 이제 끝났다”는 주장은 실무를 모르는 소리다. 두 기술은 쓰임새가 완전히 다르다.

비교 항목	대규모 컨텍스트 윈도우	RAG (검색 증강 생성)
가장 적합한 용도	전체 코드베이스 분석, 복잡한 종합 추론, 다수 문서 비교	방대한 지식 베이스, 실시간 최신 데이터, 정밀한 사실 확인
비용 구조	쿼리당 높은 비용 (전체 시퀀스를 매번 연산)	쿼리당 매우 낮은 비용 (상위 K개 청크만 처리)
맥락적 뉘앙스	탁월함 (문서 간의 모든 유기적 관계를 모델이 직접 파악)	청킹(chunking)에 의존적이어서 문서 간 연결고리 유실 위험
데이터 최신성	프롬프트마다 매번 새로 텍스트를 밀어넣어야 함	데이터베이스 업데이트 즉시 반영
감사 가능성 / 결정론	어려움 (추론 과정과 참조 문서가 복잡하게 얽힘)	명확함 (도출된 결론이 어떤 출처에서 왔는지 인용 가능)

2026년의 표준적인 해법은 하이브리드다: RAG를 통해 후보군 문서를 좁혀내고 → 롱 컨텍스트를 활용해 그 후보 문서들을 깊이 있게 교차 추론한다. 정밀함과 비용 통제에는 RAG가 이기고, 무엇을 검색해야 할지조차 모호한 상태에서 전체를 종합할 때는 롱 컨텍스트가 이긴다.

규제가 엄격한 환경(GxP, SOP, CAPA, 일탈 보고서 등)에서는 결론의 근거를 입증할 수 있어야 하므로 하이브리드 파이프라인이 필수적이다:

사용자 질문 접수
      │
      ▼
메타데이터 필터링
(제품군, 공장 위치, 공정 단계, 문서 버전)
      │
      ▼
하이브리드 검색
(키워드 기반 BM25 + 시맨틱 벡터 검색)
      │
      ▼
재순위화 (Reranking)
      │
      ▼
상위 5~15개 핵심 근거 청크 선별
      │
      ▼
컨텍스트 빌더
  • 관련 SOP 발췌문
  • 연관 CAPA 문서
  • 과거 일탈 상세 내역
  • 용어집(Glossary)
  • 사용자 원래 질문
  • 명확한 지침 및 제약사항
      │
      ▼
LLM 추론 수행
      │
      ▼
명확한 출처 인용이 포함된 답변 도출

이 방식은 수만 페이지에 달하는 품질 관리 시스템(QMS) 전체를 통째로 모델에 밀어 넣는 것보다 훨씬 더 높은 정확도를 보장하며, 명확한 감사 추적(audit trail)을 제공한다.

컨텍스트 엔지니어링: 실전 플레이북

윈도우는 유한하고 모델의 주의력은 불균등하기 때문에, 무작정 텍스트를 욱여넣는 것은 최악의 전략이다. **컨텍스트 엔지니어링(Context Engineering)**은 다음을 설계하는 규율이다: 어떤 정보를, 어떤 순서로, 어느 정도의 세밀함으로 넣을 것인가? 무엇을 요약하고, 무엇을 생략하며, 무엇을 즉각 검색하게 만들 것인가?

1. 배치 (Placement)

가장 중요한 지침은 프롬프트의 맨 앞이나 맨 뒤에 배치하라. 8만 토큰 분량의 문서 한가운데에 결정적인 지침을 숨겨두지 마라. 에이전트 워크플로에서는 최근 실행된 도구의 요약본을 프롬프트의 맨 끝에 두어야 모델의 최신성 편향(recency bias)을 가장 강력하게 활용할 수 있다.

2. 구조화 (Structure)

구조화된 텍스트가 날것의 줄글을 압도한다. XML이나 마크다운 태그를 활용해 모델이 문맥을 구획할 수 있도록 도와주어라:

<documents>
  <doc id="1"> ... </doc>
  <doc id="2"> ... </doc>
</documents>

이렇게 명확히 구분해 주는 것만으로도 검색 정확도가 눈에 띄게 올라간다. 도구 실행 결과 역시 명확한 경계선을 그어주어 “이것은 도구 3의 출력값”이고 “이것은 사용자의 입력”임을 모델이 헷갈리지 않게 해야 한다.

3. 압축 (Compression)

지나간 대화 턴들은 결정 사항, 아직 해결되지 않은 질문, 핵심 제약 조건만을 추려 구조화된 메모로 압축하라. 대규모 문서를 다룰 때는 ’전체 문서 → 챕터별 요약 → 섹션별 요약 → 최종 요약본’으로 이어지는 계층적 요약(hierarchical summarization)을 거치고, 구체적인 원문은 필요할 때만 선별적으로 파고들어야 한다.

4. 무조건 넣지 말고 똑똑하게 검색하라

무조건 많이 넣는다고 좋은 것이 아니다. 개별 청크가 질문과 관련이 있더라도 청크의 개수가 지나치게 많아지면 모델의 추론력은 분산된다. LLM에 들어가기 전 단계에서 반드시 리랭커(reranker)를 거치도록 하라.

5. 프롬프트 캐싱 (Prompt Caching)

시스템 프롬프트, 도구 정의, 정적 참조 문서처럼 호출마다 변하지 않는 고정 영역은 캐싱을 적극 활용하라. 반복되는 프리픽스 토큰에 대해 KV 캐시를 재연산하지 않음으로써 비용과 지연 시간을 최대 **90%**까지 아낄 수 있다.

6. 토큰 낭비 제거

도구 출력값에 불필요한 메타데이터나 장황한 JSON({"status": "success", "data": ...})이 포함되어 있다면 사전에 전처리하여 핵심 텍스트만 남겨라. 중복되는 시스템 지침은 캐싱하고, 에이전트 간의 무의미한 잡담으로 128K 윈도우를 낭비하지 마라.

7. 컨텍스트 거버넌스

프로덕션 시스템에서는 컨텍스트를 엄격하게 관리되는 자산으로 다루어야 한다:

워크플로 단계별 명확한 토큰 예산 배정
우선순위 규칙 수립: 필수(Critical) → 중요(High) → 참고(Low)
오래되고 쓸모없어진 토큰에 대한 자동 퇴출(eviction) 메커니즘
토큰 품질 점수화

멀티 에이전트 아키텍처에 시사하는 점

오늘날 AI 에이전트가 쏟는 시간의 대부분은 사실 컨텍스트를 관리하는 일이다. 허브-앤-스포크(Hub-and-Spoke) 구조는 컨텍스트 관리를 시스템의 일급 시민으로 다룬다.

연산 최적화로서의 컨텍스트 격리

허브-앤-스포크 멀티 에이전트 시스템에서 각각의 서브 에이전트는 자신만의 깨끗하고 독립된 컨텍스트 윈도우를 부여받는다. 하나의 거대한 단일 컨텍스트가 모든 대화와 도구 실행 기록을 끌어안고 가다가 $O(n^2)$의 연산 페널티와 중간 실종 문제를 맞는 대신, 각 에이전트는 자신이 맡은 몫의 작업에 대해서만 어텐션 비용을 지불한다.

오케스트레이터의 컨텍스트는 희소 자원이다

중앙 허브의 윈도우는 서브 에이전트들의 날것 그대로의 대화 로그가 아니라, 고도로 정제된 요약 보고서로 채워져야 한다. 허브의 유효 컨텍스트를 작게 유지하고 고신호(high-signal) 정보만을 남기기 위한 의도적인 압축이다. 서브 에이전트들끼리 허브를 거치지 않고 직접 통신하게 만드는 것은 안티패턴이다. 압축 지점을 우회하여 시스템 전체로 컨텍스트 팽창과 노이즈가 급속히 전염되기 때문이다.

좁은 컨텍스트가 보장하는 감사 가능성

파이프라인의 각 단계가 좁고 명확하게 한정된 컨텍스트를 가질 때 추론의 전 과정을 명확히 역추적할 수 있다. 온갖 SOP와 이전 대화, 도구 실행 로그가 뒤엉킨 20만 토큰짜리 컨텍스트 속에서 “모델이 대체 왜 이런 결론을 내렸는가?“를 사후 분석하는 것은 거의 불가능하다. 반면 결정의 순간에 모델의 시야에 정확히 무엇이 들어 있었는지 통제된 좁은 컨텍스트는 감사(audit)가 매우 쉽다.

에이전트의 내부 의사결정 루프

현대의 에이전트는 실행 중에 끊임없이 자문한다:

지금 외부 문서를 검색해야 하는가?
지금까지의 대화를 요약해야 하는가?
메모리 시스템을 호출해야 하는가?
과거 정보를 지워야(forget) 하는가?
검색된 결과들의 순위를 다시 매겨야 하는가?

결국 에이전트 오케스트레이션의 본질은 정교한 컨텍스트 관리다.

2020년부터 2026년까지의 진화 궤적

GPT-1 / GPT-2 시절: 수백에서 약 2,000토큰 수준
GPT-3 (2020년): 2,048토큰
초기 ChatGPT (2022~2023년): 약 4,000토큰
2023년: 32K에서 100K로 급격한 팽창 (Claude 100K, GPT-4 32K)
2023년 말: GPT-4 Turbo의 128K 도입
2024년: Gemini 1.5 Pro가 100만 토큰(실험적 200만 토큰) 시연
2025년: 100만 토큰이 최첨단 모델들의 기본 스펙으로 안착
2026년 중반: 프론티어 모델들이 100만~1,000만 토큰 범위 진입 (Llama 4 Scout의 1,000만 토큰)

앞으로 나아갈 방향

계층형 메모리 구조

작고 빠른 128K 윈도우와, 모델이 명시적으로 읽고 쓸 수 있는 거대하고 느린 벡터 저장소를 결합하는 방식이다. 모델은 학습된 외부 메모리를 자유자재로 탐색하는 정교한 추론 엔진으로 기능하게 된다.

순환 메커니즘을 통한 무한 컨텍스트

KV 캐시를 CPU나 디스크로 오프로드하고 필요에 따라 스트리밍 방식으로 되돌려 받는 기법이다. 어텐션 싱크를 적용한 StreamingLLM 같은 기술은 치명적인 망각 현상 없이 영구적인 대화 스트림을 가능하게 한다.

네이티브 멀티모달

이제 100만 토큰은 텍스트만의 영역이 아니다. 1시간 분량의 동영상은 약 50만 토큰을 소모한다. 컨텍스트 윈도우는 텍스트, 이미지, 오디오, 비디오가 하나의 공간에서 유기적으로 호흡하는 진정한 멀티모달 작업장으로 진화하고 있다.

무식한 스케일링을 넘어

업계는 단순히 물리적인 윈도우 크기를 늘리는 무식한 스케일링에서 벗어나, 외부 메모리 아키텍처를 결합한 무한 컨텍스트로 무게중심을 옮겨가고 있다. 미래의 지향점은 LLM이 신경망 데이터베이스, 벡터 저장소, 에이전트 메모리를 동적으로 쿼리하는 하이브리드 시스템이다. 네이티브 윈도우의 물리적 한계를 우회하면서도 완벽한 정확도와 회상률을 유지하는 방식이다.

일각에서는 2030년경 컨텍스트 윈도우가 수십억 토큰에 달해 셰익스피어 전집, 해리포터 전권, 위키피디아 전체를 단 하나의 프롬프트에 집어넣게 될 것이라 전망한다. 그러나 진짜 승부처는 용량의 크기가 아니라 정밀도에 있다.

결론

컨텍스트 윈도우가 2,000토큰에서 1,000만 토큰으로 확장된 것은 단순한 용량 증가가 아니다. 인공지능이 국소적인 문장 완성기에서 컨텍스트 기반 학습과 실행이 일어나는 온전한 컴퓨팅 환경으로 진화했음을 의미한다. FlashAttention, GQA, MLA, PagedAttention, RoPE 스케일링, Ring Attention과 같은 기술적 도약들이 이 거대한 윈도우를 실질적으로 가동 가능한 영역으로 끌어올렸다.

하지만 단순히 크다고 해서 무조건 더 똑똑한 것은 아니다. 윈도우 안에 어떤 정보를 밀어 넣을지, 어떻게 구조화할지, 무엇을 남기고 무엇을 버릴지 시스템이 판단하는 지적 능력이 단순한 토큰 숫자보다 훨씬 중요하다. 배치, 구조화, 압축, 선별적 검색, 캐싱, 거버넌스를 아우르는 ’컨텍스트 엔지니어링’의 숙련도가 취미 수준의 LLM 장난감과 실제 프로덕션 시스템을 가르는 진짜 기준이다.

과거 4K 시절의 모델이 단기 기억상실증에 시달렸다면, 지금의 100만 토큰 모델은 완벽한 기억력을 가졌지만 정보의 홍수에 압도당해 허우적대는 상태에 가깝다. 다음 세대의 모델들에게 진정으로 필요한 것은 ’무엇을 잊어야 하는지’를 배우는 능력이다.

기술의 최전선은 이제 “컨텍스트를 얼마나 길게 늘릴 수 있는가”에 있지 않다. “광활한 입력값 속에서 모델이 얼마나 정확하게 주의를 집중하고, 추론하며, 종합해 낼 수 있는가”에 있다. 이것은 모델의 아키텍처, 훈련 방법론, 평가 지표가 모두 함께 진화해야만 풀 수 있는 훨씬 더 깊고 본질적인 문제다.