Skip to content
DigitalNeuron
모델·연구

컨텍스트 윈도우가 답변 품질을 좌우하는 이유

컨텍스트 윈도우에는 지시와 대화, 첨부 문서, 답변이 함께 들어간다. 한도를 효율적으로 쓰는 방법과 긴 입력에서 생기는 문제를 정리했다.

DigitalNeuron Desk3분 읽기

한 줄 답

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자이고, 윈도우가 커진다고 완전히 평평해지지 않는다.

세 가지 규칙이 곧바로 따라온다.

  1. 지시는 맨 앞, 지금 묻는 것은 맨 뒤. 모델이 가장 잘 보는 두 자리다.
  2. 채우지 마라. 관련 있는 20쪽이 같은 내용이 든 200쪽을 이긴다.
  3. 실제 길이에서 시험하라. 5,000토큰에서 잘 돌던 프롬프트가 10만 토큰에서 조용히 나빠질 수 있다.

벤더의 «건초더미 속 바늘» 벤치마크 — 긴 문서에 한 문장을 숨기고 찾게 하는 시험 — 는 쉬운 경우를 잰다. 눈에 띄는 사실 하나를 회수하는 일은, 입력 전체에 흩어진 내용을 놓고 추론하는 일보다 훨씬 간단하다.

비용, 지연, 그리고 캐싱

보낸 토큰만큼, 매 요청마다 낸다. 10만 토큰짜리 컨텍스트를 20턴 대화 내내 다시 보내면 사용자가 짧은 질문 20개를 쳤어도 입력은 200만 토큰이다.

날을 무디게 하는 장치가 둘 있다.

  • 프롬프트 캐싱. 요청 앞부분 중 바뀌지 않는 구간 — 시스템 프롬프트, 도구 정의, 긴 문서 — 을 제공자가 캐시해 두고 적중 시 훨씬 싸게 청구한다. 앞부분이 바이트 단위로 동일해야만 걸리므로, 고정된 내용을 앞에, 자주 바뀌는 것(시각, 사용자 이름)을 뒤에 둔다.
  • 배치. 대화형이 아닌 작업이라면, 결과를 늦게 받는 대가로 배치 API 가 대개 훨씬 싸다.

지연도 같은 모양이다. 첫 토큰까지 걸리는 시간은 입력 길이를 따라 늘어난다. 짧은 프롬프트에서 즉각적이던 대화가 큰 파일을 붙이는 순간 굼떠지는 이유다.

한계에 닿았을 때

붙여넣지 말고 검색하라. 문서를 색인하고, 질문과 관계있는 몇 대목만 가져와 보낸다. 요청이 작고 싸고 정확해진다. 검색 증강 생성(RAG)의 논거 전부가 이것이다.

이력을 요약하라. 오래된 턴을 «지금까지 정해진 것과 알아낸 사실»의 압축본으로 바꾼다. 최근 몇 턴은 원문 그대로 둔다 — 당장의 맥락이 거기 있다.

작업을 쪼개라. 초점이 분명한 두 요청이 거대한 한 요청보다 대개 낫다. 추출 후 분석, 문서별 처리 후 통합.

도구를 줄여라. 이번 작업에 세 개만 필요하면 서른 개를 보내지 않는다.

최적화 전에 측정하라. 실제 요청의 토큰을 세어 보라. 사용자의 문서가 아니라 시스템 프롬프트나 쓰지도 않는 도구 스키마가 윈도우 대부분을 먹고 있는 경우가 흔하다.

컨텍스트 윈도우는 최대화할 «기능»이 아니다. 의도를 갖고 써야 할 «예산»이다.

자주 묻는 질문

20만 토큰이면 몇 단어인가?
영어 기준 약 15만 단어, 일반 산문으로 500쪽쯤이다. 한국어·일본어·중국어는 같은 글자 수라도 토큰이 더 들기 때문에 같은 한도에서 훨씬 적은 분량이 들어간다.
윈도우가 커지면 RAG 가 필요 없어지는가?
아니다. 크면 검색이 덜 까다로워질 뿐이다. 매 요청마다 500쪽을 보내는 건 느리고 비싸며, 아주 긴 입력에서는 정확도도 떨어진다. 검색은 요청을 작고 정확하게 유지한다.
대화가 윈도우를 넘으면 어떻게 되나?
애플리케이션이 개입해야 한다 — 오래된 턴을 버리거나, 요약하거나, 검색 저장소로 옮긴다. 모델 자체는 윈도우 밖의 것을 아예 볼 수 없다.
왜 대화가 길어질수록 비싸지는가?
대부분의 API 는 매 턴마다 대화 «전체»를 다시 보낸다. 그래서 입력이 턴마다 불어난다. 프롬프트 캐싱이 반복되는 앞부분의 비용을 낮춰주지만, 토큰이 처리되는 건 마찬가지다.

출처

  1. Lost in the Middle: How Language Models Use Long Contexts — arXiv
  2. Tokenizer — how text becomes tokens — OpenAI
  3. Prompt caching documentation — Anthropic
태그context windowtokensLLMRAG

함께 읽기

파인튜닝·검색(RAG)·프롬프트 — 무엇을 고를 것인가

먼저 «무엇이 실패했는가»를 진단한다. 모델이 «모르는 것»이면 지식 결손이고 검색이 고친다. 알고는 있는데 «모양·어조·형식»이 틀린 것이면 동작 결손이고 프롬프트가 먼저, 파인튜닝이 나중이다. 둘을 다 하고도 «특수한 기술»에서 실패하면 그때 남는 선택지가 파인튜닝이다. 프롬프트가 가장 싸고 되돌리기 쉽고, 검색이 사실에 대한 기본값이며, 파인튜닝이 셋 중 가장 비싸고 가장 되돌리기 어렵다.

5분 읽기

분석: 긴 컨텍스트는 검색(RAG)을 죽이지 않았다 — 검색의 «역할»을 바꿨다

아니다. 다만 역할이 바뀐다. 아주 큰 창을 채우면 «가운데 묻힌 정보»에서 정확도가 떨어지고, 매 요청마다 지연과 비용이 배로 늘며, 답이 어느 출처에서 나왔는지 말하기 어려워진다. 크거나 자주 바뀌는 말뭉치, 인용이나 접근 권한이 필요한 일, 비용에 민감한 대량 경로에서는 검색이 여전히 기본값이다. 긴 컨텍스트는 이제 «문서 전체를 놓고 하는 추론», «한 작업 안에서의 에이전트 작업기억», 그리고 «검색이 후보를 좁힌 뒤의 2단계»에 가장 잘 쓰인다.

7분 읽기

RAG는 언제 필요하고 무엇을 해결하나

검색 증강 생성은 질문과 관련된 대목을 우리 문서에서 찾아 모델의 프롬프트에 넣고, 그것을 근거로 답하게 하는 방식이다. 모델의 가중치는 그대로다. 지식은 요청 시점에 «컨텍스트»로 도착한다.

4분 읽기