RAG와 긴 컨텍스트: 100만 토큰이면 검색이 필요 없을까?

Anthropic의 컨텍스트 창 문서에는 이런 문장이 있습니다.

A larger context window allows the model to handle more complex and lengthy prompts, but more context isn't automatically better. As token count grows, accuracy and recall degrade, a phenomenon known as context rot.

같은 문서는 몇 줄 아래에서 최신 Claude 모델 대부분이 100만 토큰 창을 기본으로 쓴다고 안내합니다. 창을 100만 토큰으로 늘려 판매하는 회사가, 토큰이 많아질수록 정확도와 회상률이 떨어진다고 스스로 적어 둔 셈입니다. 이 두 문장이 한 페이지에 나란히 있다는 사실이 이 글의 주제를 거의 다 말해 줍니다.

요즘 자주 듣는 말은 이렇습니다. 컨텍스트 창이 100만 토큰이면 문서를 전부 넣으면 되니, 쪼개고 임베딩하고 검색하는 RAG는 할 일이 끝났다는 것입니다. 저는 이 말이 질문 하나를 다른 질문으로 바꿔치기한다고 봅니다. 긴 창은 "문서가 들어가는가"에 답합니다. 실제로 서비스를 만들 때 묻게 되는 것은 "모델이 그 문서를 제대로 쓰는가, 얼마나 빨리 답하는가, 질문 하나에 얼마가 드는가"이고, 여기에는 창 크기가 답하지 않습니다.

광고된 창과 학습된 길이 사이의 간격

먼저 숫자부터 확인해 두겠습니다. 모델은 빠르게 바뀌므로 아래는 모두 2026년 10월 9일에 각 문서를 열어 확인한 값입니다.

제공사	모델	컨텍스트 창	출처와 날짜
Anthropic	Claude Opus 5.5, Sonnet 5.5, Haiku 5.5 등	100만 토큰 (그 밖의 모델은 20만)	Context windows, 2026-10-09 확인
Google	Gemini 3.1 Pro Preview	입력 1,048,576 토큰, 출력 65,536 토큰	모델 페이지, 2026-08-18 갱신
Meta	Llama 4 Scout	1,000만 토큰	Llama 4 발표 글, 2025-04-05

100만 토큰이 어느 정도인지는 Anthropic 모델 개요가 감을 줍니다. 현재 토크나이저 기준으로 영어 약 55만 5천 단어, 유니코드 문자 약 250만 자라고 적혀 있습니다. 한국어는 토큰당 글자 수가 달라서 이 환산을 그대로 옮기면 안 됩니다.

표에서 눈여겨볼 줄은 Llama 4 Scout입니다. Meta는 같은 글에서 Scout가 "pre-trained and post-trained with a 256K context length"라고 밝히고, 1,000만 토큰은 그 위에서 길이 일반화로 얻었다고 설명합니다. 근거로 든 것은 바늘 찾기(needle in a haystack) 검색과 1,000만 토큰 코드에 대한 누적 음의 로그 우도입니다. 모델이 25만 6천 토큰으로 학습되었고, 그보다 약 40배 긴 입력을 받는다는 뜻입니다. 저는 이 간격이 거짓이라고 보지 않습니다. 다만 "받을 수 있는 길이"와 "그 길이에서 무엇을 잘하는가"가 서로 다른 주장이라는 점은 여기서 분명해집니다.

문서 가운데에서 떨어지는 정답률

입력에 정답이 들어 있어도 모델이 그것을 쓰는지는 위치에 따라 달라집니다. 이 현상을 처음 체계적으로 보인 것이 Liu 등의 Lost in the Middle(TACL 게재)입니다.

실험은 단순합니다. 질문 하나에 검색된 문서 여러 개를 붙이되, 정답이 든 문서는 하나뿐이고 그 문서의 위치를 바꿔 가며 정답률을 잽니다. 결과는 U자 모양이었습니다. 정답 문서가 맨 앞이나 맨 끝에 있으면 잘 맞히고, 가운데로 갈수록 떨어집니다.

부록 표의 숫자를 옮기면 이렇습니다. GPT-3.5-Turbo에 문서 20개를 줬을 때 정답 문서가 첫 번째면 75.8%, 열 번째면 53.8%, 스무 번째면 63.2%였습니다. 문서를 하나도 주지 않고 모델이 기억만으로 답하게 한 closed-book 정답률은 56.1%였습니다. 정답을 손에 쥐여 줬는데 가운데에 두면, 아무것도 주지 않았을 때보다 못한 결과가 나온 것입니다.

같은 논문에서 저는 다른 대목을 더 무겁게 읽습니다. 창이 긴 확장판(GPT-3.5-Turbo 16K, Claude-1.3 100K)이 입력이 양쪽 창에 다 들어가는 조건에서는 원판과 거의 같은 점수를 냈습니다. 창을 늘리는 일과 긴 입력을 잘 쓰는 일이 별개라는 것을 이 숫자가 보여 줍니다.

이 실험의 모델은 이제 낡았습니다. 최신 모델에서 U자가 얼마나 얕아졌는지는 이 논문이 답하지 않고, 저도 모델마다 다를 것이라는 정도만 말할 수 있습니다. 다만 Google의 긴 컨텍스트 문서가 지금도 "질문은 프롬프트 끝, 다른 컨텍스트 뒤에 두라"고 권하는 것을 보면, 위치가 상관없어졌다고 보기는 어렵습니다.

바늘 찾기 점수가 증명하지 않는 것

긴 창을 홍보할 때 가장 자주 보이는 그래프는 바늘 찾기입니다. 긴 무관한 글 사이에 사실 한 줄을 심어 두고 그 줄을 찾아내는지 봅니다. 이 시험이 재는 것은 심어 둔 사실 하나를 되찾는 능력이고, 문서 전체를 엮어 추론하는 능력은 재지 않습니다.

NVIDIA 연구진의 RULER(COLM 2024)는 이 한계를 정면으로 다룹니다. 바늘의 종류와 개수를 늘리고, 여러 단계를 따라가는 추적과 집계 과제를 더해 13개 과제로 17개 모델을 시험했습니다. 초록의 결론은 이렇습니다. 거의 모든 모델이 기본 바늘 찾기에서는 거의 만점이었지만 길이가 늘면 성능이 크게 떨어졌고, 모두 32K 이상을 지원한다고 했지만 32K에서 만족할 만한 성능을 유지한 것은 절반뿐이었습니다.

RULER는 "유효 길이"라는 기준을 씁니다. Llama2-7B가 4K에서 낸 평균 85.6%를 문턱으로 두고, 그 문턱을 넘는 가장 긴 길이를 유효 길이로 봅니다. Table 3에서 몇 줄을 옮깁니다.

모델	주장한 길이	유효 길이	128K 점수
Gemini-1.5-Pro	1M	128K 초과	94.4
GPT-4	128K	64K	81.2
Llama3.1 (70B)	128K	64K	66.6
GLM4 (9B)	1M	64K	83.1
LWM (7B)	1M	4K 미만	65.0

같은 100만 토큰을 주장해도 유효 길이가 128K를 넘는 모델이 있고 4K에도 못 미치는 모델이 있습니다. RULER는 128K까지만 쟀기 때문에 Gemini-1.5-Pro가 100만 토큰 끝까지 버티는지는 이 표로 알 수 없습니다.

2025년의 NoLiMa(ICML 2025)는 한 단계 더 들어갑니다. 기존 바늘 찾기에서는 질문과 바늘이 같은 낱말을 공유하는 경우가 많아서, 모델이 뜻을 이해하지 않고 글자를 맞춰 찾아낼 수 있었습니다. NoLiMa는 질문과 바늘의 낱말 겹침을 최소로 줄여, 연상으로만 바늘에 닿게 만들었습니다. 128K 이상을 지원한다는 13개 모델 가운데 11개가 32K에서 짧은 입력 기준 점수의 절반 아래로 떨어졌습니다. 상위권이던 GPT-4o도 99.3%에서 69.7%로 내려갔습니다.

실제 업무 질문은 대부분 NoLiMa 쪽에 가깝습니다. 사용자는 문서에 적힌 낱말 그대로 묻지 않습니다. "해지하면 위약금이 있나요"라고 묻는데 계약서에는 "중도 종료 시 잔여 기간 이용료의 30%를 청구한다"고 적혀 있는 식입니다. Google도 같은 문서에서 단일 바늘에서는 약 99%가 나오지만 찾을 정보가 여러 개면 같은 정확도가 나오지 않는다고 적고 있습니다.

질문마다 다시 계산되는 50만 토큰의 비용

모델은 대화를 기억하지 않습니다. 매 요청에 들어온 토큰을 처음부터 읽습니다. 그래서 문서 50만 토큰을 넣고 질문을 100번 하면 50만 토큰을 100번 보내고 100번 처리하게 됩니다.

단가로 계산해 보겠습니다. Anthropic 가격 문서(2026-10-09 확인)에서 Claude Sonnet 5.5의 기본 입력 단가는 100만 토큰당 2달러이고, 100만 토큰 창 전체를 같은 단가로 받습니다. Haiku 5.5만은 10만 토큰을 넘는 프롬프트에 더 높은 단가를 매깁니다. Google 가격 문서(2026-10-07 갱신)에서 Gemini 3.1 Pro Preview의 입력 단가는 20만 토큰 이하 프롬프트에 2달러, 20만 토큰 초과 프롬프트에 4달러입니다.

경우 (입력 토큰만, 출력 제외)	Sonnet 5.5	Gemini 3.1 Pro Preview
50만 토큰을 한 번 보냄	1.00달러	2.00달러
같은 50만 토큰으로 질문 100번	100달러	200달러
검색으로 1만 토큰만 골라 질문 100번	2달러	2달러

마지막 줄의 1만 토큰은 계산을 위해 정한 예시이고, 실제로는 청크 크기와 개수에 따라 달라집니다. 그래도 자릿수 차이는 남습니다. 질문 하나에 50만 토큰을 싣는 방식은 1만 토큰을 싣는 방식보다 입력 비용이 50배입니다.

Gemini 쪽은 경계에서 한 번 더 생각할 거리가 있습니다. 표의 문구가 "prompts > 200k tokens"이므로, 문구대로 읽으면 프롬프트 전체가 높은 단가로 계산됩니다. 그렇다면 19만 토큰은 0.38달러, 21만 토큰은 0.84달러로, 토큰이 10% 남짓 늘었는데 값은 두 배를 넘습니다. 실제 청구가 이렇게 되는지는 청구서로 확인해야 할 부분입니다.

프롬프트 캐싱이 깎아 주는 몫과 붙는 조건

이 비용을 줄이는 장치가 프롬프트 캐싱입니다. 앞부분이 똑같은 요청이 반복되면, 그 앞부분을 처리한 결과를 저장해 두고 다시 씁니다.

Anthropic의 프롬프트 캐싱 문서와 가격 문서에 따르면 5분 캐시 쓰기는 기본 입력 단가의 1.25배, 캐시 읽기는 대부분 모델에서 0.1배입니다. Opus 5.5와 Sonnet 5.5는 읽기가 0.05배라 Sonnet 5.5 기준 100만 토큰당 0.10달러입니다. 질문 100번이 5분 간격 안에 이어진다고 보고 앞의 예에 대입하면, 첫 질문에서 50만 토큰을 캐시에 쓰는 데 1.25달러, 이후 질문마다 0.05달러가 들어 질문 100번에 6.20달러입니다. 캐싱 없이 100달러이던 것이 6.20달러로 내려갑니다.

조건이 셋 붙습니다. 첫째, 캐시 수명이 기본 5분입니다. 쓸 때마다 무료로 갱신되지만, 5분 넘게 아무도 묻지 않으면 다음 질문은 다시 쓰기 값을 냅니다. 1시간 캐시도 있지만 쓰기가 기본 단가의 2배입니다. 둘째, 캐시는 접두사가 100% 같을 때만 맞습니다. 문서 앞쪽에 날짜나 사용자 이름처럼 요청마다 바뀌는 값이 한 글자라도 끼면 그 뒤는 전부 새로 계산됩니다. 셋째, Gemini는 캐시된 토큰을 읽는 값(20만 초과 프롬프트에서 100만 토큰당 0.40달러)과 별도로 보관료를 받습니다. 100만 토큰당 시간당 4.50달러이므로 50만 토큰을 한 시간 들고 있으면 2.25달러입니다. 질문이 드문 문서를 오래 캐시에 두면 읽기 값보다 보관료가 커집니다.

캐싱이 바꾸지 않는 것도 있습니다. Anthropic 문서는 캐시된 접두사도 컨텍스트 창을 그대로 차지한다고 적고 있습니다. 캐싱은 그 토큰에 내는 값을 바꿀 뿐, 모델이 50만 토큰 사이에서 정답을 찾아야 하는 문제는 그대로 남습니다. 앞에서 본 위치 효과와 유효 길이 문제는 캐싱으로 풀리지 않습니다.

입력이 길수록 늦어지는 첫 토큰

LLM 추론은 두 단계로 나뉩니다. 입력 전체를 한꺼번에 처리하는 프리필(prefill)과, 답을 한 토큰씩 만드는 디코드입니다. 첫 토큰은 프리필이 끝나야 나오므로 입력이 길수록 첫 토큰까지의 시간(TTFT)이 늘어납니다. Google 문서도 FAQ에서 고정 지연이 있지만 대체로 쿼리가 길수록 첫 토큰까지의 지연이 커진다고 답합니다.

늘어나는 모양이 직선만은 아닙니다. 트랜스포머 원 논문 Attention Is All You Need의 Table 1은 셀프 어텐션의 층당 계산량을 O(n²·d)로 적습니다. n은 시퀀스 길이입니다. 실제 서비스는 여러 최적화를 쓰고 모델 전체 계산에는 길이에 비례하는 부분도 섞여 있어서, 이 식이 곧 응답 시간은 아닙니다. 그래도 어텐션 부분은 입력을 두 배로 늘리면 네 배로 커지는 구조입니다.

메모리도 같이 늘어납니다. 디코드 단계는 앞서 처리한 토큰마다 키와 값을 저장해 둔 KV 캐시를 읽습니다. 이 캐시는 요청 하나의 토큰 수에 비례해 커집니다. 계산은 LLM 추론 GPU 메모리 계산: KV 캐시와 메모리 대역폭에서 따로 다뤘습니다. API를 쓰는 쪽에서는 이 비용이 토큰 단가와 처리량 제한으로 돌아옵니다. 직접 모델을 띄우는 쪽에서는 긴 요청 하나가 GPU 하나에 동시에 받을 수 있는 요청 수를 줄입니다.

창이 아무리 커져도 검색에 남는 일

긴 창이 대신할 수 없는 일부터 적겠습니다.

가장 분명한 것은 크기입니다. 사내 위키, 몇 년 치 고객 문의, 제품 매뉴얼 전체는 100만 토큰을 쉽게 넘습니다. 1,000만 토큰 창도 언젠가는 모자랍니다. 문서가 창보다 크면 무엇을 넣을지 골라야 하고, 고르는 일이 곧 검색입니다.

갱신도 다릅니다. RAG에서는 문서 하나가 바뀌면 그 문서의 청크만 다시 색인합니다. 문서를 통째로 넣는 방식에서 앞쪽 문서 하나가 바뀌면 캐시된 접두사가 깨지고, 그 뒤 전체를 다시 계산합니다. 하루에도 여러 번 바뀌는 자료라면 캐싱의 이득이 거의 남지 않습니다.

저는 권한을 가장 과소평가되는 차이로 봅니다. 문서 1,000개를 컨텍스트에 넣고 "이 사용자는 인사 문서를 보면 안 된다"고 지시하는 것은 접근 제어가 아닙니다. 모델은 이미 그 문서를 읽었고, 지시를 어기게 만드는 질문은 언제든 나올 수 있습니다. 검색 단계에서 사용자 권한으로 먼저 걸러야 모델이 볼 수 없는 문서는 처음부터 입력에 들어가지 않습니다.

출처 추적도 검색 쪽이 쉽습니다. 검색된 청크마다 문서 ID와 위치가 붙어 있으니 답에 근거를 달기가 자연스럽습니다. 50만 토큰을 통째로 넣으면 모델에게 출처를 적으라고 요구할 수는 있어도, 그 출처가 맞는지 다시 확인하는 일은 남습니다.

그리고 질문당 비용이 있습니다. 위의 표처럼 질문이 많아질수록 차이는 질문 수만큼 곱해집니다.

통째로 넣어야 풀리는 질문

반대 방향도 분명히 있습니다. 검색은 질문과 비슷해 보이는 조각을 가져오는 장치라서, 조각 사이의 관계를 묻는 질문에 약합니다.

계약서 하나를 생각해 보면 쉽습니다. "제12조의 예외가 제3조 정의 때문에 이 거래에도 적용되는가" 같은 질문은 두 조항을 함께 읽어야 풀립니다. 제3조는 질문과 낱말이 거의 겹치지 않아서 검색 상위에 올라오지 않을 가능성이 높습니다. 코드도 비슷합니다. 모듈 하나의 함수가 어디서 불리고 어떤 상태를 바꾸는지는 파일 전체를 봐야 압니다.

청크 경계에서 생기는 오류도 사라집니다. 표가 두 청크로 잘리거나, "단, 다음의 경우는 제외한다"는 문장이 앞 청크에 붙고 그 목록은 뒤 청크로 넘어가는 일이 없어집니다. 청크 크기를 어떻게 정할지 고민할 필요도 없습니다.

말뭉치가 작다면 구조가 단순한 쪽이 이깁니다. 문서가 수십 개이고 창의 유효 길이 안에 넉넉히 들어간다면, 임베딩 모델과 벡터 색인과 재순위 단계를 따로 운영할 이유가 약합니다. 고장 날 부품이 하나라도 적은 편이 낫습니다.

검색으로 고르고 긴 창에 통째로 싣는 혼합 방식

실제로는 둘 중 하나를 고르기보다 섞는 경우가 많습니다. 저는 긴 창이 RAG를 없앤다기보다 RAG의 마지막 단계를 바꾼다고 봅니다.

하나는 검색 단위와 전달 단위를 나누는 방식입니다. 검색은 작은 청크로 정확하게 하고, 모델에게는 걸린 청크가 속한 문서 전체나 앞뒤 넓은 구간을 넘깁니다. 창이 작던 시절에는 청크 대여섯 개가 한계였지만 이제는 문서 몇 개를 통째로 넣을 수 있습니다. 앞 절의 계약서 질문처럼 조각 사이의 관계가 중요한 경우에 효과가 큽니다.

다른 하나는 안 바뀌는 것과 바뀌는 것을 나누는 방식입니다. 자주 바뀌지 않는 핵심 자료(제품 정책, 용어 정의, 매뉴얼의 뼈대)는 프롬프트 앞쪽에 고정해 캐시하고, 자주 바뀌거나 사용자마다 다른 자료는 검색으로 가져와 그 뒤에 붙입니다. 캐시가 맞으려면 고정 부분이 바이트 단위로 같아야 하므로, 바뀌는 값은 반드시 고정 부분 뒤에 둡니다.

어느 쪽이든 위치 효과는 염두에 둡니다. 가장 관련성이 높은 문서를 입력의 맨 앞이나 질문 바로 앞에 두고, 질문은 끝에 둡니다. Lost in the Middle의 U자와 Google의 권고가 같은 방향을 가리킵니다.

크기, 갱신, 질문량, 권한으로 가르는 선택

정리된 공식은 없고, 저는 다음 네 가지를 차례로 봅니다.

묻는 것	긴 컨텍스트 쪽으로 기우는 경우	RAG 쪽으로 기우는 경우
말뭉치 크기	모델의 유효 길이 안에 넉넉히 들어감	창을 넘거나 계속 늘어남
갱신 빈도	거의 안 바뀜 (캐시가 오래 맞음)	하루에도 여러 번 바뀜
질문량	적거나, 몰려서 들어와 캐시가 살아 있음	많고 고르게 퍼져 있음
권한과 출처	모든 사용자가 같은 문서를 봄	사용자마다 볼 수 있는 문서가 다름, 근거 제시가 필수

첫 줄에서 저는 광고된 창 크기가 아니라 유효 길이를 기준으로 삼습니다. 그런데 유효 길이는 모델마다, 과제마다 다르고, RULER와 NoLiMa가 잰 모델은 지금 쓰는 모델이 아닙니다. 결국 자기 문서와 자기 질문으로 길이를 바꿔 가며 직접 재 보는 수밖에 없다고 봅니다. 질문과 정답이 낱말을 공유하지 않는 문항을 꼭 섞어야 합니다.

권한 줄은 다른 줄보다 무겁게 봅니다. 크기와 비용은 모델이 좋아지고 값이 내리면 판단이 바뀌지만, 사용자가 보면 안 되는 문서를 입력에 넣지 않는다는 원칙은 창 크기와 상관이 없습니다. 이 조건 하나만 걸려도 저는 검색 단계를 둡니다.

확신이 없는 부분도 적어 둡니다. 이 글의 품질 근거는 2023년에서 2025년 사이의 벤치마크이고, 그 뒤 모델들이 긴 입력을 얼마나 더 잘 쓰게 되었는지는 공개된 독립 측정이 제공사 발표만큼 따라오지 못하고 있습니다. 위의 가격과 창 크기도 몇 달 뒤에는 다른 숫자일 가능성이 큽니다. 그래도 질문마다 입력 전체를 다시 읽는다는 구조와, 권한은 모델 앞에서 걸러야 한다는 원칙은 모델이 바뀌어도 그대로라고 봅니다.