상위: 06_00_MOC
RAG vs 롱컨텍스트 논쟁 — 검색증강과 초장문맥, 무엇이 언제 우월한가
한 줄 정의
RAG vs 롱컨텍스트 논쟁이란, 작업에 필요한 외부 지식을 (a) 벡터 검색으로 선별해 주입할지(RAG), 아니면 (b) 100K~1M 토큰의 초장문맥 창에 통째로 넣을지를 두고 비용·지연·정확도·신선도(freshness) 네 축에서 벌어지는 설계 논쟁이다. 핵심 결론은 무료 점심이 없다는 것이다. 롱컨텍스트는 충분한 자원이 있을 때 평균 정확도가 높지만, RAG는 압도적으로 싸고 빠르다. 그리고 둘 다 길이가 길어지면 부패와 혼란에 노출된다.
“When resourced sufficiently, LC consistently outperforms RAG in terms of average performance. However, RAG’s significantly lower cost remains a distinct advantage.” — Li et al., 2024 (Google DeepMind, EMNLP)
왜 중요한가
2024년 Gemini 1.5(1M 토큰), 2025년 Gemini 2.5·GPT-4.1(1M)·Claude(200K~1M) 등 초장문맥 모델이 등장하자 “RAG is dead”라는 주장이 업계에 번졌다. 논리는 단순했다. 복잡한 검색 파이프라인을 왜 만드나, 다 넣으면 되지.
컨텍스트 엔지니어 입장에서 이 논쟁은 추상적 종교전쟁이 아니라 프로덕션 아키텍처 결정이다. 잘못 고르면 월 청구서가 수십 배 폭증하거나, 사용자 응답 지연이 1초에서 45초로 늘거나, 컨텍스트 부패로 정확도가 조용히 무너진다. 게다가 06장 네 전략 중 Select의 존재 이유 자체를 건드린다. 롱컨텍스트가 RAG를 대체한다면 Select 전략의 절반이 사라지기 때문이다.
답부터 말하면 둘 다 살아남았고, 2025~2026년 합의는 “에이전트 시대의 하이브리드”로 수렴한다.
flowchart TD Q["외부 지식이 필요한 쿼리"] --> DEC{"어떻게 넣을까?"} DEC -->|"선별 주입"| RAG["RAG / 벡터검색<br/>필요한 청크만"] DEC -->|"통째로"| LC["롱컨텍스트<br/>100K~1M 창"] RAG --> CHEAP["저비용·저지연<br/>신선도 우수"] RAG --> RISK1["검색 누락(miss)<br/>청킹 손실"] LC --> ACC["멀티홉·전역추론<br/>평균 정확도 우위"] LC --> RISK2["[[05_00_MOC|05 부패]]<br/>[[03_00_MOC|03 혼란]]<br/>비용·지연 폭증"] CHEAP --> HYB["하이브리드 / Self-Route<br/>= 2026 합의"] ACC --> HYB
1. 논쟁의 출발점 — “RAG is Dead?“
1-1. 강세론(롱컨텍스트가 RAG를 대체한다)
핵심 주장은 세 가지다.
- 단순성: 검색·청킹·재랭킹 파이프라인은 깨지기 쉽다. 그냥 다 넣으면 엔지니어링 부채가 사라진다.
- 검색 누락 제거: RAG는 관련 청크를 못 찾으면(retrieval miss) 답이 불가능하다. 전부 넣으면 이 실패가 없다.
- 전역 추론: 문서 전체에 흩어진 정보를 종합하는 멀티홉(multi-hop) 질문은 RAG가 약하다. 롱컨텍스트는 전체를 보므로 유리하다.
이 입장을 뒷받침한 실증 연구가 Li et al.(2024)이다. 충분한 자원이 주어지면 LC(Long-Context)가 평균적으로 RAG를 이긴다는 것이 이들의 첫 발견이다.
1-2. 반론(RAG는 죽지 않았다)
“Long context didn’t kill retrieval. Bigger windows add cost and noise, while retrieval focuses attention where it matters.” — LightOn 블로그, 2025
반론의 핵심은 비용·지연·신선도·부패 네 축이다. 롱컨텍스트가 이론적으로 가능한 것과 프로덕션에서 합리적인 것은 다르다. 특히 뒤에서 다룰 컨텍스트 부패(Context Rot)는 “다 넣으면 다 본다”는 강세론의 전제를 정면으로 반박한다.
2. 핵심 논문 ① — Long Context RAG Performance (arXiv:2411.03538)
문제의식
“Can these new long context models improve RAG performance?” — Leng et al., 2024
Databricks 연구팀(Quinn Leng, Jacob Portes, Sam Havens, Matei Zaharia, Michael Carbin)이 검색 문서를 더 많이 넣으면, 즉 컨텍스트를 늘리면 RAG가 좋아지는가를 정면으로 측정했다.
방법
- 모델 20종 (오픈소스 + 상용)
- 컨텍스트 길이: 2,000 → 128,000 토큰 (가능 시 2,000,000까지)
- 데이터셋 3종: Databricks DocsQA, FinanceBench, Natural Questions
수치·핵심 발견
| 발견 | 내용 |
|---|---|
| 문서를 더 검색하면 | 성능이 향상될 수 있다(단조적 아님) |
| 64k 토큰 초과 시 | 극소수 최신 SOTA 모델만 일관된 정확도 유지 |
| 오픈소스 모델 대다수 | 16k~32k 토큰 구간에서 최고 성능, 이후 급락 |
“While retrieving more documents can improve performance, only a handful of the most recent state of the art LLMs can maintain consistent accuracy at long context above 64k tokens.” — Leng et al., 2024 (초록 직접인용)
모델별 고유 실패모드 (이 논문의 백미)
논문은 길이가 길어질 때 모델마다 다른 방식으로 무너진다고 보고한다.
| 모델 | 실패 양상 | 변화 |
|---|---|---|
| Claude 3.5 Sonnet | 저작권 관련 거부(refusal) 급증 | 16k 3.7% → 64k 49.5% |
| DBRX | 지시 따르기(instruction following) 붕괴 | 8k 5.2% → 32k 50.4% |
| Llama-3.1-405B | 32k 부근부터 저하 시작 | — |
| GPT-4 | 64k까지 비교적 유지 | — |
시사점: “롱컨텍스트 모델이니까 다 넣어도 된다”는 가정은 모델에 따라 달라진다. 같은 128K 창이라도 어떤 모델은 32k에서 이미 무너진다. → 05 부패와 직결.
3. 핵심 논문 ② — Context Rot (Chroma, 2025)
문제의식
강세론의 암묵적 전제는 “창 안에 넣으면 모델이 균일하게 잘 본다”이다. Chroma(Kelly Hong, Anton Troynikov, Jeff Huber, 2025-07-14)는 이를 18개 모델(Claude 4 계열, GPT-4.1 계열, o3, Gemini 2.5 계열, Qwen3 계열)로 반박했다.
핵심 발견 — “길이 자체가 성능을 갉아먹는다”
“Model performance degrades as input length increases, often in surprising and non-uniform ways.” — Hong et al., 2025
이것이 컨텍스트 부패(Context Rot)다. 한 가지 구분에 주의해야 한다.
부패 ≠ 창 오버플로우. 200K 창 모델이 50K에서 이미 유의미하게 저하될 수 있다. 부패는 한계에 도달하기 한참 전에 시작된다.
세부 실험과 시사점
| 실험 | 발견 | RAG vs LC 함의 |
|---|---|---|
| Needle-Question 유사도 | 질문과 정답의 의미 유사도가 낮을수록 길이에 따라 더 빨리 저하 | RAG의 정밀 검색이 유사도 높은 청크만 주는 것이 유리 |
| Distractor(방해 문서) | 단 하나의 방해 문서만 있어도 baseline 대비 저하, 영향은 비균일 | ”다 넣기”는 방해 문서를 함께 넣는 셈 → 정밀 검색 우위 |
| Haystack 구조 | 논리적으로 일관된 본문일수록 성능이 더 나쁨(셔플이 오히려 나음) | 반직관적 — 긴 문서 통째 주입의 함정 |
| LongMemEval(대화 QA) | 집중 프롬프트 vs 전체 프롬프트 격차 큼, Claude는 모호성 하에서 보수적 | 대화 메모리는 06_08-MemGPT-Letta-OS형-롱텀메모리식 선별 필요 |
| 반복 단어 과제 | 길어질수록 모든 모델 일관 저하 | 단순 과제조차 길이에 취약 |
시사점: Context Rot는 “RAG is dead” 강세론의 핵심 전제를 무너뜨린다. 더 넣을수록 좋아지기는커녕 방해 문서와 길이 자체가 정밀도를 떨어뜨린다. Select 전략(06_02-Select전략-RAG-하이브리드검색-ToolLoadout)이 단순한 비용 절감이 아니라 정확도 향상 수단임을 보여준다.
4. 핵심 논문 ③ — Self-Route 하이브리드 (arXiv:2407.16833, EMNLP 2024)
문제의식
Li, Li, Zhang, Mei, Bendersky(Google DeepMind)는 RAG vs LC를 이분법이 아닌 라우팅 문제로 재정의했다.
핵심 발견 (2단계)
- 충분한 자원 하에서는 LC가 RAG를 평균적으로 이긴다. (강세론에 일부 동의)
- 그러나 RAG의 저비용은 결정적 이점이다. 두 발견을 결합한 것이 Self-Route다.
방법 — Self-Route
“A simple yet effective method that routes queries to RAG or LC based on model self-reflection.” — Li et al., 2024
모델이 스스로 판단한다. RAG 검색 결과만으로 답할 수 있으면 RAG로 싸게 처리하고, 불충분하다고 자기성찰(self-reflection)하면 LC로 승격해 비싸지만 정확하게 답한다. 평가에 쓴 LLM은 Gemini-1.5-Pro, GPT-4O, GPT-3.5-Turbo 세 종이다.
수치
| 모델 | Self-Route 비용 절감 | 성능 |
|---|---|---|
| Gemini-1.5-Pro | 65% 절감 | LC와 동등 수준 유지 |
| GPT-4O | 39% 절감 | LC와 동등 수준 유지 |
시사점: “RAG냐 LC냐”는 잘못된 질문이다. 옳은 질문은 “이 쿼리는 RAG로 충분한가?”이다. Self-Route는 능동적 검색과 라우팅의 이론적 토대다.
5. 4축 트레이드오프 정리 — 비용·지연·정확도·신선도
다음 표의 수치는 출처별 편차가 크다. 정성적 방향성은 RAG가 싸고 빠르다는 쪽으로 일관되지만, 절대 수치는 워크로드·모델·프롬프트 캐싱 여부에 따라 크게 달라지므로 어림값으로 읽어야 한다.
| 축 | RAG | 롱컨텍스트(LC) | 비고 |
|---|---|---|---|
| 비용 | 입력 토큰을 수천 단위로 압축 → 저렴 | 쿼리당 1M 토큰 주입 시 $2~$15 수준 | 격차 8~80배, 1,000배 이상이라는 추정도 있음 |
| 지연 | 검색 후 짧은 프롬프트 → 빠름(1초 수준) | 수십만 토큰 prefill → 느림(30~60초) | LC는 prefill 자체가 비쌈 |
| 정확도 | 검색이 정확하면 우수, 멀티홉 약함 | 자원 충분 시 평균 우위(Li et al.) | 단 Context Rot로 길이↑ 시 저하 |
| 신선도(freshness) | 인덱스/소스 갱신으로 즉시 반영 | 창에 넣은 시점 정보 고정 | RAG가 최신성에 유리 |
| 부패 노출 | 청크만 넣어 길이 짧음 → 부패 적음 | 길수록 05 부패 심화 | LC의 구조적 약점 |
프롬프트 캐싱이라는 변수
“Prompt caching narrows the cost gap by maybe 5-10x in the best case where every query hits the same prefix, which most production traffic doesn’t.” — Tian Pan, 2026
프롬프트 캐싱(KV-캐시)은 동일 prefix가 반복될 때 LC 비용 격차를 좁힌다. 그러나 대부분의 프로덕션 트래픽은 prefix가 매번 달라 캐시 효과가 제한적이다. → 06_07-Manus-KV캐시-파일시스템-교훈의 KV-캐시 4원칙과 연결.
6. 2025~2026 합의 — 에이전트 시대의 하이브리드
논쟁은 “둘 다 필요하다”로 수렴했다. Anthropic은 이를 just-in-time(적시) 검색으로 정식화한다.
“Rather than pre-processing all relevant data up front, agents maintain lightweight identifiers (file paths, stored queries, web links) and use these references to dynamically load data into context at runtime using tools.” — Anthropic, 2025
사전 적재 vs 적시 검색
| 방식 | 설명 | 약점 |
|---|---|---|
| 사전 적재(pre-retrieval, LC형) | 관련 데이터를 미리 다 컨텍스트에 넣음 | 정보 과부하·부패·stale indexing |
| 적시 검색(just-in-time, 에이전트형) | 경량 식별자(파일 경로·쿼리·링크)만 들고, 런타임에 glob/grep/도구로 그때그때 로드 | 약간의 지연 추가 |
“Hybrid approaches, combining up-front context with runtime retrieval, can further optimize agent performance, especially for tasks requiring both speed and depth.” — Anthropic, 2025
이 적시 검색은 사람이 노트나 북마크를 필요할 때마다 펼쳐보는 습관과 닮았다. 사전 임베딩에 의존하지 않고 에이전트가 환경을 탐색(glob, grep)하게 해 stale indexing을 피한다. → 06_01-Write전략-스크래치패드-파일시스템-크로스세션의 파일시스템 외부화, 06_07-Manus-KV캐시-파일시스템-교훈의 “파일시스템 = 무한 컨텍스트”와 같은 발상이다.
flowchart LR subgraph LC["LC형 (사전 적재)"] A1["모든 문서를<br/>창에 통째로"] end subgraph JIT["에이전트형 (적시 검색)"] B1["경량 식별자만 보유"] B2["런타임 glob/grep/RAG"] B3["필요분만 동적 로드"] B1 --> B2 --> B3 end LC -->|"과부하·부패 위험"| X["[[03_00_MOC|03 혼란]]<br/>[[05_00_MOC|05 부패]]"] JIT -->|"작업기억 집중 유지"| Y["정밀·신선·저비용"]
7. 5대 실패모드와의 연결
| 실패모드 | RAG의 역할 | LC의 위험 |
|---|---|---|
| 01 오염 | 신선한 소스 재검색으로 오염 정보 교체 가능 | 한번 넣은 오염 정보가 창에 잔류 |
| 02 산만 | 관련 청크만 → 산만 최소화 | 100K↑에서 산만 임계 진입 |
| 03 혼란 | 정밀 검색으로 무관 정보 차단 | Context Rot의 distractor 효과 = 혼란 |
| 04 충돌 | 최신·고신뢰 소스 선별로 상충 완화 | 상충 문서를 통째로 넣으면 충돌 유발 |
| 05 부패 | 짧은 컨텍스트 유지로 부패 회피 | LC의 구조적 핵심 약점 |
핵심: RAG는 부패와 혼란을 능동적으로 막는 도구이고, LC는 편의를 주는 대신 부패와 혼란에 취약하다. “다 넣기”가 공짜가 아닌 이유가 바로 이 두 실패모드다.
8. 실무 의사결정 가이드
| 조건 | 권장 |
|---|---|
| 쿼리가 단발·키워드 기반·신선도 중요 | RAG (저비용·저지연·최신성) |
| 문서 전체 종합·멀티홉·자원 충분 | LC (단, 64k·모델별 임계 확인) |
| 트래픽 대량·비용 민감 | Self-Route (모델 자기성찰 라우팅) |
| 장시간 에이전트·도구 사용 | 적시 검색 하이브리드 (식별자+런타임 로드) |
| 동일 prefix 반복 워크로드 | LC + 프롬프트 캐싱 (KV-캐시 활용) |
요약·체크리스트
- “RAG is dead”는 과장. Li et al.(2024) 자신도 LC 우위를 인정하면서 RAG의 저비용을 결정적 이점으로 못 박았다.
- 64k가 1차 임계. arXiv:2411.03538 — 64k 초과에서 일관된 정확도를 유지하는 모델은 극소수 SOTA뿐. 모델별 실패모드도 제각각이다(Claude 거부 급증, DBRX 지시붕괴).
- Context Rot가 강세론의 전제를 반박. Chroma(2025) — 길이 자체가 정밀도를 갉아먹고, distractor 하나로도 저하되며, 일관된 긴 본문이 오히려 더 나쁘다.
- Self-Route = 올바른 질문. “RAG냐 LC냐”가 아니라 “이 쿼리는 RAG로 충분한가”다. Gemini-1.5-Pro 65%, GPT-4O 39% 비용 절감.
- 비용·지연 수치는 어림값. 방향성(RAG가 싸고 빠름)은 견고하지만 절대값은 워크로드와 캐싱에 달려 있다.
- 2026 합의 = 적시 검색 하이브리드. Anthropic의 just-in-time, 경량 식별자에 런타임 동적 로드를 더한 방식. Select 전략의 근거가 된다.
- 부패·혼란이 LC의 구조적 약점. RAG와 Select는 비용 절감을 넘어 정확도를 지키는 수단이다.
참고문헌
- Long Context RAG Performance of Large Language Models — Leng, Portes, Havens, Zaharia, Carbin (Databricks), 2024, arXiv:2411.03538 / NeurIPS 2024 AFM Workshop
- Context Rot: How Increasing Input Tokens Impacts LLM Performance — Hong, Troynikov, Huber (Chroma), 2025, Chroma Research
- Retrieval Augmented Generation or Long-Context LLMs? A Comprehensive Study and Hybrid Approach — Li, Li, Zhang, Mei, Bendersky (Google DeepMind), 2024, arXiv:2407.16833 / EMNLP 2024 Industry Track
- Effective Context Engineering for AI Agents — Anthropic, 2025, Anthropic Engineering
- Will RAG Be Killed by Long-Context LLMs? — Zilliz, 2024, Zilliz Blog
- RAG is Dead, Long Live RAG: Retrieval in the Age of Agents — LightOn, 2025, LightOn Blog
- Long-Context Models vs. RAG: When the 1M-Token Window Is the Wrong Tool — Tian Pan, 2026, TianPan.co (비용·지연 수치)
관련 노트
- 06_02-Select전략-RAG-하이브리드검색-ToolLoadout — 이 논쟁이 정당화하는 Select 전략의 본체
- 06_03-Compress전략-요약-프루닝-KV캐시최적화 — 프롬프트 캐싱·KV-캐시가 비용 격차를 좁히는 메커니즘
- 06_07-Manus-KV캐시-파일시스템-교훈 — “파일시스템 = 무한 컨텍스트”, 적시 검색의 실전 구현
- 06_08-MemGPT-Letta-OS형-롱텀메모리 — 능동적 검색·계층 메모리로 LC 한계를 우회
- 05 부패 — LC의 구조적 약점, Context Rot의 직접 대상
- 03 혼란 — distractor·무관 정보가 일으키는 혼란, RAG가 방어
- 06_09-실패모드-전략-매핑표 — RAG/LC 선택이 막거나 유발하는 실패모드 전체 매핑