컨텍스트 윈도우란 무엇이고, 왜 모자라는가
컨텍스트 윈도우는 모델이 한 번에 볼 수 있는 전부다 — 프롬프트·대화·첨부 문서·그리고 자기 답변까지. 어떻게 재는지, 왜 길수록 좋은 게 아닌지, 한계에 닿았을 때 무엇을 해야 하는지.
한 줄 답
AI 모델의 컨텍스트 윈도우란 무엇인가?
컨텍스트 윈도우는 모델이 한 번의 요청에서 고려할 수 있는 텍스트의 최대량이며 토큰 단위로 잰다. 시스템 지시, 지금까지의 대화, 붙여 넣은 문서, 그리고 생성 중인 답변이 모두 그 안에 들어간다. 합이 한도를 넘으면 무언가는 버리거나 요약해야 한다.
핵심 요약
- 단위는 단어가 아니라 토큰이다 — 영어는 토큰당 약 0.75단어, 한국어·일본어는 글자당 토큰이 훨씬 많이 든다.
- 지시·대화 이력·첨부 파일·도구 정의·출력이 «같은 예산»을 나눠 쓴다.
- 긴 입력에서는 처음과 끝을 중간보다 잘 활용한다. 그래서 «어디에 두느냐»가 중요하다.
- 비용과 지연은 실제로 보낸 토큰에 비례한다 — 그래서 전부 붙여넣기보다 캐싱과 검색이 이긴다.
언어모델과의 모든 대화에는 «한 번에 볼 수 있는 양»의 단단한 천장이 있다. 그게 컨텍스트 윈도우다. 사람들이 보고하는 이상 증상 대부분 — 모델이 방금 한 말을 «까먹고», 첨부 파일을 무시하고, 중간에 맥을 놓치는 것 — 이 여기서 온다.
단어가 아니라 토큰
모델은 글자나 단어를 읽지 않는다. 텍스트는 먼저 토큰으로 쪼개진다. 토크나이저가 학습한, 자주 등장하는 조각들이다. 영어에서 토큰은 평균 네 글자쯤이라 1,000토큰이 대략 750단어다.
이 비율은 보편적이지 않다. 토크나이저 학습 분포에서 벗어난 문자 체계는 더 잘게 부서진다.
| 텍스트 | 대략의 토큰 수 |
|---|---|
The quick brown fox (영문 19자) | 약 4 |
안녕하세요 반갑습니다 (한글 11자) | 약 10 |
こんにちは、はじめまして (일본어 12자) | 약 11 |
| 공백 4칸 들여쓴 코드 한 줄 | 들여쓰기 단계마다 1토큰 |
실무적 결론: 같은 «보이는 길이»라면 한국어·일본어 문서가 영어 문서보다 윈도우를 눈에 띄게 많이 먹고, 요청당 비용도 그만큼 더 든다.
무엇이 그 공간을 다투는가
윈도우를 «얼마나 긴 문서를 붙여 넣을 수 있는가»로 생각하기 쉽다. 실제로는 공유 예산이다.
- 시스템 프롬프트 — 어시스턴트의 행동을 규정하는 지시.
- 도구 정의. 모델이 도구를 부를 수 있다면. 상세 스키마를 가진 도구 열두 개면 아직 아무 말도 하기 전에 수천 토큰이다.
- 대화 이력. 보통 매 턴 전부 다시 보낸다.
- 첨부하거나 검색해 온 문서.
- 출력. 대부분의 API 에서 생성 토큰도 같은 예산에서 나간다. 그래서 아주 긴 입력은 긴 답변을 위한 자리를 남기지 않는다.
큰 PDF 를 붙였는데 답이 잘려 나온 경험이 있다면, 이유가 이것이다.
길다고 고르게 좋진 않다
긴 컨텍스트 동작을 다룬 연구 — 가장 널리 인용되는 Lost in the Middle — 는 일관된 패턴을 찾았다. 모델은 긴 입력의 앞과 뒤에 놓인 사실을 중간에 묻힌 사실보다 훨씬 잘 꺼낸다. 곡선은 U자이고, 윈도우가 커진다고 완전히 평평해지지 않는다.
세 가지 규칙이 곧바로 따라온다.
- 지시는 맨 앞, 지금 묻는 것은 맨 뒤. 모델이 가장 잘 보는 두 자리다.
- 채우지 마라. 관련 있는 20쪽이 같은 내용이 든 200쪽을 이긴다.
- 실제 길이에서 시험하라. 5,000토큰에서 잘 돌던 프롬프트가 10만 토큰에서 조용히 나빠질 수 있다.
벤더의 «건초더미 속 바늘» 벤치마크 — 긴 문서에 한 문장을 숨기고 찾게 하는 시험 — 는 쉬운 경우를 잰다. 눈에 띄는 사실 하나를 회수하는 일은, 입력 전체에 흩어진 내용을 놓고 추론하는 일보다 훨씬 간단하다.
비용, 지연, 그리고 캐싱
보낸 토큰만큼, 매 요청마다 낸다. 10만 토큰짜리 컨텍스트를 20턴 대화 내내 다시 보내면 사용자가 짧은 질문 20개를 쳤어도 입력은 200만 토큰이다.
날을 무디게 하는 장치가 둘 있다.
- 프롬프트 캐싱. 요청 앞부분 중 바뀌지 않는 구간 — 시스템 프롬프트, 도구 정의, 긴 문서 — 을 제공자가 캐시해 두고 적중 시 훨씬 싸게 청구한다. 앞부분이 바이트 단위로 동일해야만 걸리므로, 고정된 내용을 앞에, 자주 바뀌는 것(시각, 사용자 이름)을 뒤에 둔다.
- 배치. 대화형이 아닌 작업이라면, 결과를 늦게 받는 대가로 배치 API 가 대개 훨씬 싸다.
지연도 같은 모양이다. 첫 토큰까지 걸리는 시간은 입력 길이를 따라 늘어난다. 짧은 프롬프트에서 즉각적이던 대화가 큰 파일을 붙이는 순간 굼떠지는 이유다.
한계에 닿았을 때
붙여넣지 말고 검색하라. 문서를 색인하고, 질문과 관계있는 몇 대목만 가져와 보낸다. 요청이 작고 싸고 정확해진다. 검색 증강 생성(RAG)의 논거 전부가 이것이다.
이력을 요약하라. 오래된 턴을 «지금까지 정해진 것과 알아낸 사실»의 압축본으로 바꾼다. 최근 몇 턴은 원문 그대로 둔다 — 당장의 맥락이 거기 있다.
작업을 쪼개라. 초점이 분명한 두 요청이 거대한 한 요청보다 대개 낫다. 추출 후 분석, 문서별 처리 후 통합.
도구를 줄여라. 이번 작업에 세 개만 필요하면 서른 개를 보내지 않는다.
최적화 전에 측정하라. 실제 요청의 토큰을 세어 보라. 사용자의 문서가 아니라 시스템 프롬프트나 쓰지도 않는 도구 스키마가 윈도우 대부분을 먹고 있는 경우가 흔하다.
컨텍스트 윈도우는 최대화할 «기능»이 아니다. 의도를 갖고 써야 할 «예산»이다.
자주 묻는 질문
- 20만 토큰이면 몇 단어인가?
- 영어 기준 약 15만 단어, 일반 산문으로 500쪽쯤이다. 한국어·일본어·중국어는 같은 글자 수라도 토큰이 더 들기 때문에 같은 한도에서 훨씬 적은 분량이 들어간다.
- 윈도우가 커지면 RAG 가 필요 없어지는가?
- 아니다. 크면 검색이 덜 까다로워질 뿐이다. 매 요청마다 500쪽을 보내는 건 느리고 비싸며, 아주 긴 입력에서는 정확도도 떨어진다. 검색은 요청을 작고 정확하게 유지한다.
- 대화가 윈도우를 넘으면 어떻게 되나?
- 애플리케이션이 개입해야 한다 — 오래된 턴을 버리거나, 요약하거나, 검색 저장소로 옮긴다. 모델 자체는 윈도우 밖의 것을 아예 볼 수 없다.
- 왜 대화가 길어질수록 비싸지는가?
- 대부분의 API 는 매 턴마다 대화 «전체»를 다시 보낸다. 그래서 입력이 턴마다 불어난다. 프롬프트 캐싱이 반복되는 앞부분의 비용을 낮춰주지만, 토큰이 처리되는 건 마찬가지다.