컨텍스트 윈도우와 롱컨텍스트 - 길다고 다 좋을까
"이번 모델은 컨텍스트 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만 토큰을 넣으면, 사용자당 요청 하나가 비싸집니다. 대화가 길어질수록 이력이 누적돼 비용이 눈덩이처럼 불어납니다.