검색 증강 생성(retrieval-augmented generation, RAG)은 질문에 필요한 문서만 골라 모델에 넣는 방식이고, 긴 컨텍스트는 문서 전체를 통째로 밀어 넣는 방식이다. 컨텍스트 창이 100만 토큰까지 커져도 모델은 그 창을 끝까지 읽어내지 못하며, 그런데도 RAG가 확실히 밀리는 코퍼스는 따로 있다.
컨텍스트 창이 커질 때마다 도는 말
컨텍스트 창이 100만 토큰까지 늘었다. 새 모델이 나올 때마다 이 숫자가 갱신되고, 그때마다 업계에는 같은 말이 돈다. 이제 검색 같은 건 필요 없고 문서를 통째로 밀어 넣으면 된다는 말이다. 무엇을 넣을지 고르는 파이프라인은 창이 좁던 시절의 임시방편이었다는 이야기다.
이 말은 하나를 전제한다. 창에 들어가면 모델이 그걸 읽는다는 전제다. 창의 크기는 사양서에 적힌 숫자로 확인되지만, 그 안을 실제로 읽어내는 능력은 따로 재야 한다. 둘이 같다는 것은 아무도 증명한 적이 없다. 그런데 업계의 말은 둘을 늘 붙여서 쓴다.
그래서 이 글은 논문 세 편의 실측으로 그 전제를 쪼갠다. 긴 컨텍스트가 어디서부터 무너지는지(NoLiMa), 많이 넣는 것이 왜 최선이 아닌지(OP-RAG), 그럼에도 검색을 걷어내도 되는 코퍼스는 어떤 모양인지(CAG)를 차례로 확인한다. OP-RAG와 CAG의 수치는 그 기법을 제안한 연구팀의 자가평가다. NoLiMa는 성격이 조금 다르다. 기법이 아니라 시험지를 내놓은 쪽이 남의 모델을 채점한 것이다. 그 성격을 매번 같이 적어 둔다.
컨텍스트 창이 크다고 다 읽는 건 아니다
창을 읽어내는 능력을 재는 표준 시험은 이미 있다. 건초더미에서 바늘 찾기(needle-in-a-haystack, NIAH)다. 긴 문서 어딘가에 한 문장을 심어 두고 그 문장이 담은 사실을 모델에게 묻는다. 심은 위치와 문서 길이를 바꿔 가며 정답률을 재면 창의 어느 구간이 약한지 지도가 나온다.
문제는 이 시험이 너무 쉽다는 데 있다. 심어 둔 문장과 질문이 대개 같은 단어를 공유한다. 모델은 문맥을 이해하지 않고 그 단어가 있는 자리만 찾아도 정답을 맞힌다.
질문과 바늘 문장이 같은 고유명사를 품고 있으면, 모델은 그 단어가 있는 자리 하나만 짚어도 답을 만든다. 이때 재는 능력은 긴 문맥의 이해보다 문자열 대조에 가깝다. NoLiMa 저자들이 지적하는 지점이 여기다.
NoLiMa는 이 겹침을 걷어낸 벤치마크다. 바늘 문장과 질문이 단어를 공유하지 않도록 만들어, 모델이 뜻으로 연결해야만 답에 닿게 했다. 문서도 모델도 그대로 두고 시험지의 난도만 바꾼 셈이다.
NoLiMa — 32K에서 이미 절반 아래로 떨어진다
결과는 뚜렷하게 갈렸다. 1K 이하의 짧은 문맥에서 99.3점을 받은 GPT-4o가 32K에서는 69.7점으로 내려앉는다. 32K에서 기준선의 절반 이상을 지킨 모델은 13개 중 둘뿐이었다. GPT-4o와 Gemini 1.5 Pro다. 나머지 11개는 절반 아래로 내려갔고, Command R+는 90.9에서 7.4로, Mistral Large 2는 87.9에서 18.8로 떨어진다. 이 점수들은 기법을 파는 쪽이 아니라 시험지를 만든 저자들이 잰 것이고, 채점은 모델 내부를 볼 수 없는 블랙박스 상태에서 이뤄졌다.
그림 1를 세로로 훑으면 감쇠가 특정 모델의 사정이 아니라는 게 보인다. 기준선 점수가 높든 낮든 오른쪽으로 갈수록 색이 빠진다. 논문은 여기서 유효 길이(effective length)라는 지표를 쓴다. GPT-4o의 유효 길이는 8K인데, 같은 모델이 광고하는 창은 128K다.
추론에 특화된 모델은 어떨까. 논문은 최난도 10문항으로 추린 NoLiMa-Hard도 함께 잰다. GPT-o1은 99.9에서 시작해 4K 92.0, 8K 78.0, 16K 60.1, 32K 31.1로 내려가고, DeepSeek R1-Distill-Llama-70B는 99.9에서 32K 20.7까지 떨어진다. 추론 단계를 더 밟는 모델도 32K에서 기준선의 절반을 지키지 못한다. 창이 크다는 것과 창을 읽어낸다는 것은 역시 다른 능력이다.
많이 넣을수록 좋다는 건 틀렸다 — OP-RAG의 역U자
두 번째 실측은 반대편을 잰다. 창을 다 읽지 못한다면 검색은 남는데, 그다음 질문은 얼마나 많이 골라 넣느냐다. 조각을 많이 넣을수록 정답에 필요한 문장이 창 안에 들어올 확률은 올라간다. 그러니 예산이 허락하는 만큼 넣는 것이 상식처럼 보인다.
OP-RAG는 검색해 온 조각을 관련도 순서가 아니라 원문에 나온 순서대로 배치한다. 바꾼 것은 배치 규칙 하나뿐이다. 그 하나로 EN.QA F1이 38.40에서 44.43으로 올랐다(둘 다 128개 조각, 약 16K 토큰). EN.QA는 긴 문서를 읽고 질문에 답하는 영어 과제이고, F1은 모델이 낸 답이 정답과 얼마나 겹치는지를 재는 점수다. 관련도 순으로 줄을 세우면 문서의 앞뒤 맥락이 흐트러진다. 원문 순서를 지키면 그 손실이 사라진다.
그림 2의 모양이 이 절의 핵심이다. 검색 토큰을 늘리면 F1이 16K에서 44.43, 24K에서 45.45, 48K에서 47.25까지 오른다. 그리고 그 뒤로 꺾인다. 같은 생성 모델(Llama3.1-70B)에 117K 전량을 그냥 넣으면 34.26이다.
정점이 아니라 가장 작은 조건만 봐도 결론은 같다. 16K 검색 토큰으로 44.43인데 117K 전량은 34.26이다. 토큰을 약 7분의 1만 쓰고도 앞선다(117K를 16K로 나눈 값이며 논문에 그렇게 적힌 표현은 아니다 — 글쓴이 종합). 넣을 수 있다는 것과 넣는 것이 이득이라는 것은 별개다. 이 수치들도 OP-RAG 연구팀의 자가평가다.
RAG가 정말 지는 곳 — 바운디드 코퍼스와 CAG
여기까지만 보면 검색이 늘 이기는 것 같지만, 그렇지 않은 영역이 분명히 있다. CAG(cache-augmented generation)는 검색 단계를 아예 없앤다. 대상 문서가 창에 들어갈 만큼 작고 잘 안 바뀐다면, 전체를 한 번 미리 넣어 키-값(KV) 캐시를 만들어 두고 질문마다 그 캐시를 재사용한다. 키-값 캐시는 한 번 처리한 문맥의 중간 계산을 저장해 둔 것이라, 같은 문맥을 다시 물어볼 때 그 계산을 처음부터 되풀이하지 않아도 된다. 검색기도, 순위 매기기도, 조각 나누기도 필요 없다. 대신 코퍼스의 경계가 미리 정해져 있어야 한다.
그림 3가 그 경계를 그대로 보여 준다. HotPotQA에서 CAG는 small 분할 0.7951, medium 0.7821로 검색 방식들을 앞선다. 점수는 BERTScore다. 생성한 답과 정답이 뜻으로 얼마나 가까운지를 재는 지표라고 보면 된다. 그런데 가장 큰 분할에서는 CAG 0.7407이 sparse 검색 top-5의 0.7535에 뒤진다.
여기서 sparse 검색은 단어가 겹치는 정도로 문서를 고르는 방식(BM25 계열)을 말한다. 뜻을 벡터로 견주는 dense 검색과 대비되는 축이다. 그 오래된 방식에 뒤집힌 large 분할이 논문의 최대 실험이고, 규모는 64문서 85K 토큰이다. 100만 토큰 창에 한참 못 미치는 지점에서 우위가 사라진다.
이 수치는 개정판(v2) 기준이다. 초판(v1)에서는 같은 large 분할에서도 CAG가 앞섰다. 원저자가 최신판에서 스스로 경계선을 좁힌 셈이니, 초판 수치를 인용한 글을 볼 때는 버전을 먼저 확인하는 편이 좋다. 함께 자주 인용되는 "약 40배 빠르다"도 비교 대상을 봐야 한다. 그건 캐시 없이 매번 전체를 다시 계산하는 방식과의 비교이지 RAG와의 비교가 아니다. sparse 검색 top-3의 생성 시간(0.67~0.74초)은 CAG보다도 짧다.
CAG의 이득은 절대 속도 1위가 아니다. 검색 파이프라인을 통째로 지우고도 전체 문맥을 그대로 유지한다는 점이 이득이다. 그리고 그 이득이 살아 있는 구간은 논문 자신의 실험 안에서 이미 닫히기 시작한다. 이 수치들 역시 CAG를 제안한 연구팀의 자가평가다.
비용도 같은 방향을 가리킨다
정확도만 놓고 보면 판단이 애매한 구간이 남는데, 비용을 얹으면 방향이 분명해진다. 창에 넣은 토큰은 첫 응답이 나오기 전에 한 번씩 전부 처리된다. 이 단계를 프리필(prefill)이라고 부른다. 100만 토큰을 밀어 넣었다면 100만 토큰어치 프리필 값이 질문마다 붙는다는 뜻이다. 아래는 2026년 8월 기준 공식 단가다.
| 모델 | 입력 단가/100만 토큰 | 100만 토큰 프리필 1회 | 캐시 히트 시 |
|---|---|---|---|
| Claude Opus 5 | $5 | $5.00 | $0.50 (0.1배) |
| Claude Sonnet 5 | $2 | $2.00 | $0.20 (0.1배) |
| Gemini 2.5 Pro | $1.25 (20만 이하) / $2.50 (초과) | $2.50 | $0.25 (0.1배) |
| GPT-5.6-Sol | $5.00 | $5.00 | $0.50 (0.1배) |
| GPT-4.1 | $2.00 | $2.00 | $0.50 (0.25배) |
100만 토큰을 한 번 밀어 넣는 데 회당 2~5달러가 들고, 캐시가 맞으면 0.2~0.5달러로 내려간다(단가에 100만을 곱한 산술 — 글쓴이 종합). 네 배(GPT-4.1)에서 열 배(나머지 네 모델)에 이르는 이 차이는 캐시를 다시 쓰느냐에서 갈린다. 같은 문서를 계속 물어보며 캐시를 재사용하면 싼 쪽이고, 질문마다 새로 밀어 넣으면 비싼 쪽이다. 프롬프트 캐싱은 CAG 같은 접근의 경제성을 받치는 장치이지 긴 컨텍스트 자체를 싸게 만드는 장치가 아니다.
Gemini는 캐시 유지에 별도 보관료가 붙는다(100만 토큰 기준 시간당 4.50달러). 상주 캐시를 계획한다면 프리필 단가만 보지 말고 유지 시간을 곱해 볼 것. Anthropic은 캐시 쓰기가 5분 유지 1.25배, 1시간 유지 2배다.
비용 다음으로 따라오는 질문은 얼마나 기다리느냐다. 첫 토큰까지 걸리는 시간(time to first token, TTFT)의 절대값은 공식 문서에 수치가 없어 단정하지 않는다. 지연 축에서 댈 수 있는 근거는 앞 절의 CAG 실측(85K 규모)뿐이고, 그 값을 100만 토큰으로 늘려 잡는 외삽은 하지 않는다.
그래서 RAG를 걷어내도 되는 조건
세 편의 실측을 한 줄씩 놓으면 이렇다. 창이 커져도 모델이 다 읽지는 못하고(NoLiMa), 골라 넣은 소수 토큰이 전량 투입을 이기며(OP-RAG), 그럼에도 작고 고정된 코퍼스에서는 검색을 지워도 된다(CAG). 실무에서 먼저 물을 것은 세 번째가 언제 성립하느냐다. 질문 세 개로 나누면 이렇게 된다.
| 조건 | 확인 질문 | 근거 |
|---|---|---|
| 경계가 뚜렷한가 | 답에 필요한 문서 목록을 미리 적을 수 있나 | 캐시를 미리 만들려면 대상이 고정돼야 한다 |
| 창보다 충분히 작은가 | 전체가 수만 토큰 규모인가 | 85K 분할에서 이미 sparse 검색에 역전당했다 |
| 갱신이 드문가 | 문서가 바뀌는 주기가 질문 주기보다 긴가 | 바뀔 때마다 캐시를 다시 만들면 비용 이점이 사라진다 |
세 칸 모두 예라면 검색기를 두는 대신 캐시 프리로드를 검토할 만하다. 하나라도 아니오라면 RAG가 남는 이유는 두 가지로 좁혀진다. 긴 문맥에서 생기는 성능 열화를 피하는 것, 그리고 토큰 예산을 아끼는 것이다. 검색기를 둘지 말지는 창의 크기가 아니라 코퍼스의 모양이 정한다.
더 읽기
- NoLiMa: Long-Context Evaluation Beyond Literal Matching (ICML 2025) — https://arxiv.org/abs/2502.05167
- In Defense of RAG in the Era of Long-Context Language Models (OP-RAG, NVIDIA) — https://arxiv.org/abs/2409.01666
- Don’t Do RAG: When Cache-Augmented Generation is All You Need (WWW Companion ’25) — https://arxiv.org/abs/2412.15605