컨텍스트 윈도우와 롱컨텍스트 - 길다고 다 좋을까

"이번 모델은 컨텍스트 100만 토큰!" 같은 홍보를 자주 봅니다. 그래서 "문서를 통째로 넣으면 RAG 같은 거 필요 없는 거 아냐?"라는 생각이 들기도 합니다. 하지만 컨텍스트가 길다고 무조건 좋은 것은 아닙니다. 길이에는 대가가 따르고, 길다고 잘 읽는 것도 아닙니다.

이 글에서는 컨텍스트 윈도우가 무엇인지, 왜 길이가 만능이 아닌지, 그리고 컨텍스트를 어떻게 관리해야 하는지 정리합니다.

1. 컨텍스트 윈도우란

컨텍스트 윈도우(context window) 는 모델이 한 번의 요청에서 볼 수 있는 토큰의 총량입니다. 여기에는 시스템 프롬프트, 대화 이력, 사용자 질문, 그리고 모델이 생성할 답변까지 전부 포함됩니다.

비유하자면 모델의 책상 넓이입니다. 책상이 넓으면 참고 자료를 많이 펼쳐 둘 수 있지만, 책상 밖에 있는 것은 아예 보지 못합니다. 그리고 답을 쓸 공간도 이 책상 위에서 나눠 써야 합니다.

핵심은 이것이 하드 리밋이라는 점입니다. 넘으면 잘리거나(truncation) 에러가 납니다.

2. 토큰 한계와 계산

토큰은 단어보다 작은 단위입니다. 영어는 대략 1토큰 ≈ 4글자, 한국어는 더 잘게 쪼개져 글자당 토큰 수가 더 많습니다.

입력과 출력이 같은 예산을 나눠 쓴다는 점을 놓치기 쉽습니다.

컨텍스트 윈도우 = 시스템 프롬프트
               + 대화 이력
               + 검색 문서(RAG)
               + 사용자 질문
               + 생성될 답변(출력)   ← 이 공간도 남겨둬야 함

그래서 긴 문서를 입력에 꽉 채우면, 정작 답변을 쓸 공간이 부족해 답이 잘리는 일이 생깁니다. 실무에서는 입력을 윈도우의 일부만 쓰도록 여유를 둡니다.

// 개략적인 예산 관리
const MAX = 128_000;
const reserveForOutput = 4_000;
const budgetForInput = MAX - reserveForOutput;
// budgetForInput 안에서 프롬프트 + 이력 + 문서를 배분

3. Lost in the Middle - 길다고 다 읽는 게 아니다

컨텍스트를 길게 넣을 수 있다는 것과, 모델이 그 안의 모든 내용을 고르게 잘 활용한다는 것은 다른 얘기입니다.

연구와 실무 경험 모두, 모델은 긴 컨텍스트의 처음과 끝은 잘 참조하지만 중간에 있는 정보는 놓치는 경향을 보입니다. 이를 lost in the middle(중간 소실) 현상이라고 부릅니다.

비유하자면, 두꺼운 보고서를 받았을 때 앞부분과 결론은 보지만 중간 페이지는 대충 넘기는 사람과 비슷합니다.

실무적 함의:

정말 중요한 정보는 프롬프트의 앞이나 뒤에 배치합니다.
관련 없는 문서를 잔뜩 넣으면, 정답이 중간에 묻혀 오히려 성능이 떨어질 수 있습니다.
"많이 넣기"보다 "관련 있는 것만 정확히 넣기" 가 이깁니다.

4. 비용과 지연

긴 컨텍스트는 공짜가 아닙니다. 두 가지 대가가 있습니다.

비용: 대부분의 API는 입력 토큰 수에 비례해 과금합니다. 매 요청마다 10만 토큰을 넣으면, 사용자당 요청 하나가 비싸집니다. 대화가 길어질수록 이력이 누적돼 비용이 눈덩이처럼 불어납니다.
지연(latency): 입력이 길수록 처리 시간이 늘어 첫 응답까지 더 오래 걸립니다. 실시간 챗봇에서는 체감 품질을 크게 떨어뜨립니다.

즉, 컨텍스트를 무작정 채우는 것은 느리고 비싼 답을, 심지어 더 부정확하게 만드는 길일 수 있습니다.

5. 롱컨텍스트 vs RAG

그럼 긴 컨텍스트와 RAG 중 무엇을 써야 할까요? 대립이 아니라 역할 분담으로 보는 것이 맞습니다.

상황	유리한 쪽
지식 베이스가 크고 계속 늘어남	RAG (필요한 부분만 검색해 주입)
문서 하나를 통째로 분석·요약	롱컨텍스트
출처·인용이 중요	RAG (어느 문서에서 왔는지 추적)
비용·지연에 민감	RAG (넣는 양을 최소화)
정보가 문서 전체에 흩어져 상호참조	롱컨텍스트

정리하면, "모든 지식을 매번 다 넣는" 방식은 대체로 비효율적입니다. 롱컨텍스트는 RAG를 없애는 게 아니라, RAG가 근거를 더 넉넉히 넣을 수 있게 보완하는 관계입니다. 실무에서는 "검색으로 좁히고, 넓어진 윈도우에 여유 있게 담는" 조합이 흔합니다.

6. 컨텍스트 관리 전략

윈도우가 아무리 커도, 넣는 것을 관리하지 않으면 결국 위 문제들에 부딪힙니다. 특히 긴 대화형 애플리케이션에서 중요합니다.

6-1. 요약(summarization)

대화가 길어지면 오래된 이력을 통째로 들고 다니지 말고, 요약으로 압축합니다. 최근 몇 턴은 원문 그대로, 그 이전은 요약본으로 둡니다.

[시스템] 지금까지의 대화 요약: 사용자는 결제 오류를 겪고 있고,
         카드 재등록을 안내받았으나 실패함. 현재 환불을 원함.
[최근 3턴 원문]
...

6-2. 정리·선별(pruning)

관련 없는 이력은 버립니다. 모든 걸 기억할 필요는 없습니다.
RAG 결과는 점수 임계값으로 걸러 관련 낮은 청크를 제외합니다.
중복되는 문서·문단은 합칩니다.

6-3. 구조화·배치

중요한 지시와 핵심 근거는 앞/뒤에 배치해 lost-in-the-middle을 피합니다.
시스템 프롬프트, 문서, 질문을 명확한 구분자로 나눠 모델이 역할을 헷갈리지 않게 합니다.

마무리

컨텍스트 윈도우가 커진 것은 분명 좋은 일입니다. 하지만 "길다 = 좋다"는 아닙니다.

입력과 출력은 같은 예산을 나눠 쓴다.
모델은 중간 내용을 놓치기 쉽다(lost in the middle).
긴 컨텍스트는 느리고 비싸다.

그래서 핵심 원칙은 하나입니다. "많이 넣기"가 아니라 "필요한 것만 잘 넣기". 검색으로 좁히고, 요약으로 압축하고, 중요한 것을 앞뒤에 배치하는 컨텍스트 관리가, 큰 윈도우를 제대로 활용하는 진짜 실력입니다.