RAG vs Long Context 2026 — 10M 토큰 시대, 검색이 여전히 필요한가?

들어가며

2019년, GPT-2의 컨텍스트 윈도우는 1,024 토큰이었다. A4 용지 한 장 반 정도. 이 좁은 창으로 세상을 보는 모델에게 100페이지짜리 계약서를 분석해달라고 할 수는 없었다. 그래서 RAG(Retrieval-Augmented Generation)가 등장했다. 필요한 부분만 찾아서 보여주면 된다는 발상.

7년이 지난 2026년, Llama 4 Scout은 1,000만 토큰을 주장한다. 책 수십 권을 한 번에 읽을 수 있는 분량이다. 컨텍스트 윈도우가 10,000배 커졌다.

그렇다면 질문은 자명하다. "이제 RAG는 필요 없는 것 아닌가? 그냥 모든 문서를 프롬프트에 넣으면 되지 않나?"

2026년 3월 현재, 이 질문에 대한 대답은 "아니오, 하지만 예전과 같은 RAG도 아니다"이다. 이 글에서는 왜 그런지를, 역사부터 최신 연구까지 하나씩 풀어보겠다.

---

제1장: 컨텍스트 윈도우의 폭발적 성장

1,024에서 10,000,000까지

이것을 가능하게 한 기술들

컨텍스트 윈도우가 이렇게 커질 수 있었던 것은 여러 기술 혁신 덕분이다.

RoPE(Rotary Position Embedding): 회전 행렬로 위치 정보를 인코딩하면서 상대적 위치 관계도 유지하는 기법. Llama를 포함한 대부분의 현대 모델이 사용한다. theta 값을 조정해 학습 시보다 긴 컨텍스트로 외삽(extrapolation)할 수 있다.

Ring Attention: 긴 시퀀스의 어텐션 계산을 여러 가속기에 분산하는 기법. 각 장치가 시퀀스의 한 슬라이스를 담당하고 결과를 링 형태로 전달한다. 수백만 토큰의 정확한 어텐션을 가능하게 한다.

Sparse Attention: 모든 토큰 쌍을 계산하는 대신 일부만 계산해 복잡도를 $O(n^2)$에서 $O(n\sqrt{n})$ 또는 $O(n)$으로 줄인다.

iRoPE(Interleaved RoPE): Llama 4 Scout에서 도입. 고정 위치 임베딩이 없는 어텐션 레이어를 교차 배치해 긴 컨텍스트로의 일반화를 개선한다.

10M 토큰의 진실: 숫자와 현실

하지만 중요한 주의사항이 있다. AI 연구자 Andriy Burkov 박사의 분석에 따르면:

"선언된 10M 컨텍스트는 사실상 가상이다. 어떤 모델도 256K 토큰 이상의 프롬프트로 학습되지 않았다. 256K를 넘는 입력을 보내면 대부분의 경우 품질이 낮은 출력이 나온다."

Llama 4 Scout은 256K 토큰으로 학습되었고, 길이 일반화(length generalization)에 의존해 10M까지 외삽한다. 실제 유효 용량은 일반적으로 공칭 최대치의 60-70%다.

---

제2장: RAG — 검색 증강 생성의 진화

RAG의 탄생 (2020)

2020년 5월, Facebook AI Research(현 Meta AI)의 Patrick Lewis 등이 발표한 논문 "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks"가 RAG의 시작이다.

핵심 아이디어는 단순하면서 강력하다:

RAG가 해결한 핵심 문제: LLM의 할루시네이션(환각)과 지식의 정체(학습 데이터 이후 정보 모름). 외부 데이터를 실시간으로 주입함으로써 두 문제를 동시에 완화한다.

2024-2026: RAG의 진화

초기 RAG는 단순했지만, 2024-2026년에 걸쳐 극적으로 발전했다.

GraphRAG (2024, Microsoft): 문서를 엔티티와 관계의 그래프로 인코딩한다. 물리적으로 떨어져 있지만 의미적으로 연결된 정보를 추적할 수 있다. 전통적 청크 기반 RAG의 "의미적 격차" 문제를 해결.

Agentic RAG: AI 에이전트가 검색, 생성, 쿼리 계획, 반복적 추론을 자율적으로 오케스트레이션한다. 데이터 소스를 선택하고, 쿼리를 정제하고, 결과를 검증하는 루프. Google Cloud 2025 보고서에 따르면 GenAI를 사용하는 기업의 52%가 프로덕션에서 AI 에이전트를 운영 중이다.

Corrective RAG (CRAG): 검색된 문서의 품질과 관련성을 LLM에 전달하기 전에 평가하는 경량 평가기를 도입한다.

Self-RAG: 모델 스스로 "검색이 필요한가?"를 판단하고, 자신의 출력을 비판하는 능력을 학습한다.

RAG 시장의 폭발

2025년 엔터프라이즈 RAG 배포는 전년 대비 280% 증가했다. 프로덕션 LLM 애플리케이션의 60%가 RAG를 사용한다. 벡터 DB 시장은 43억 달러 규모이며, Pinecone의 Q4 2025 매출은 전년비 340% 성장했다.

---

제3장: 핵심 연구 — 누가 이기는가

"Lost in the Middle" — 긴 컨텍스트의 아킬레스건 (2023)

2023년 7월, Stanford의 Nelson Liu 등이 발표한 논문은 긴 컨텍스트 모델의 근본적 약점을 드러냈다.

발견: 모델의 성능은 U자 곡선을 그린다. 관련 정보가 컨텍스트의 처음이나 끝에 있을 때는 잘 찾지만, 중간에 있으면 성능이 약 30% 하락한다.

이것은 단순히 "컨텍스트를 키우면 된다"는 가정에 대한 강력한 반론이다. 1M 토큰 컨텍스트가 있어도, 중간 어딘가에 묻힌 정보는 놓칠 수 있다.

Google의 RAG vs Long Context 연구 (2024)

2024년 7월, Google 연구팀(Li et al.)이 Gemini 1.5와 GPT-4를 사용해 수행한 비교 연구의 핵심 발견:

"충분한 리소스가 있을 때, Long Context가 RAG를 평균적으로 일관되게 능가한다. 하지만 RAG의 현저히 낮은 비용은 명확한 이점이다."

이 연구는 Self-Route라는 하이브리드 방법을 제안했다. 모델이 스스로 "이 질문은 전체 컨텍스트가 필요한가, 검색된 조각으로 충분한가"를 판단해 동적으로 경로를 선택한다. Long Context와 동등한 성능을 유지하면서 비용을 크게 절감했다.

13,628개 질문의 대규모 비교 (2025)

2025년 1월, Li et al.이 GPT-4o로 수행한 대규모 비교 연구:

결론: 둘 다 일방적으로 우위에 있지 않다. 과제 유형에 따라 최적의 접근이 다르다.

LaRA 벤치마크의 최종 평결 (2025)

2025년 2월 발표된 LaRA 벤치마크(2,326개 테스트, 11개 모델)의 결론은 명확했다:

"은탄환(Silver Bullet)은 없다 — 최적의 선택은 모델 능력, 컨텍스트 길이, 과제 유형, 검색 특성의 복잡한 상호작용에 달려 있다."

---

제4장: 비용의 진실 — 돈으로 보는 RAG vs Long Context

쿼리당 비용 비교

이론적 성능을 넘어, 현실적인 비용은 기업의 의사결정을 좌우하는 핵심 요소다.

RAG가 Long Context보다 약 15,000배 저렴하다.

기업 규모 시나리오:

물론 이것은 RAG 인프라(벡터 DB, 임베딩 파이프라인, 인덱싱) 비용을 제외한 순수 API 호출 비용이다. RAG 인프라를 포함해도 연간 $200K 이하**로, Long Context 대비 **$4.3M 이상을 절감한다.

2026년 가격 변화: 캐싱의 시대

2026년의 중요한 변화는 프롬프트 캐싱이다.

• Anthropic: 2026년 3월 13일, Claude Opus 4.6/Sonnet 4.6에서 롱 컨텍스트 추가 요금 폐지. 캐시 히트 시 기본 가격의 10%만 과금 (Sonnet 4.6: $0.30/M 토큰)
• OpenAI: GPT-5 캐시 읽기 시 90% 할인
• Google: 컨텍스트 캐싱 시 기본 가격의 10%

이것은 게임 체인저다. 같은 문서를 반복 쿼리하는 경우, Long Context의 비용이 10분의 1로 줄어든다. RAG와의 비용 격차가 크게 좁혀졌다.

지연시간(Latency) 비교

인터랙티브 애플리케이션(2초 이내 응답 필요)에서는 RAG가 압도적으로 유리하다. 다만 CAG(Cache-Augmented Generation)가 중간 지점을 제공한다 — 전체 문서를 컨텍스트에 넣고 KV 캐시를 저장해, 후속 쿼리는 2.3초 만에 처리한다.

---

제5장: 실전 가이드 — 2026년, 언제 무엇을 쓸 것인가

의사결정 트리

각 방식이 최적인 상황

Anthropic의 실무 가이드라인

Anthropic이 2024년 발표한 Contextual Retrieval 블로그에서 제시한 실용적 기준:

"지식 베이스가 200K 토큰 미만(~500페이지)이면, RAG 없이 전부 프롬프트에 넣어라."

200K 이상이면 Contextual Retrieval을 추천한다. 각 청크에 50-100 토큰의 맥락 설명을 붙여 임베딩하면, 검색 실패율을 67% 줄일 수 있다(재순위화 포함). 비용: 문서 100만 토큰당 $1.02 (1회성, 프롬프트 캐싱 사용 시).

Needle-in-a-Haystack: 2026년 실력

"1M 토큰의 긴 컨텍스트 안에서 특정 정보를 정확히 찾는 능력"을 측정하는 Needle-in-a-Haystack 테스트 결과:

Claude Opus 4.6이 1M 토큰 전체에서 거의 균일한 검색 성능을 보이는 반면, 다른 모델들은 256K 이후 급격히 성능이 떨어진다. 모든 모델이 긴 컨텍스트를 똑같이 잘 활용하는 것은 아니다.

---

제6장: 수렴 — RAG + Long Context의 하이브리드

"검색한 다음, 긴 컨텍스트에서 추론"

2026년의 가장 강력한 패턴은 RAG와 Long Context를 결합하는 것이다. ICLR 2025 논문의 발견: 하이브리드 검색(벡터 검색 + 롱 컨텍스트 추론)이 8개 기업 사용 사례 중 7개에서 개별 접근보다 우수했다.

작동 방식:

1. 벡터 검색으로 대규모 문서에서 관련 청크 검색
2. 검색된 청크를 롱 컨텍스트 윈도우에 넣어 깊은 추론
3. 모델이 청크 간 관계를 이해하며 종합적 답변 생성

이것은 RAG의 정밀성과 Long Context의 추론 깊이를 결합한다. 검색이 관련 컨텍스트를 좁혀주고, 긴 컨텍스트가 그 안에서 깊이 추론한다.

Cache-Augmented Generation (CAG)

2024년 12월 발표된 CAG 논문은 흥미로운 중간 지점을 제시한다. 모든 관련 문서를 LLM 컨텍스트에 미리 로드하고 KV 캐시를 저장해두는 방식이다.

첫 쿼리는 느리지만, 이후 쿼리는 검색 지연 0, 검색 오류 0으로 처리된다.

하이브리드 검색: 2026년의 기본값

2026년, 하이브리드 검색(Hybrid Search)이 프로덕션의 기본이 되고 있다. 키워드 검색(BM25)과 시맨틱 검색(벡터 임베딩)을 결합하고, Reciprocal Rank Fusion(RRF)으로 결과를 병합한다.

성능 향상: 단일 방법 대비 Recall@5 +7.2%, MRR +18.5%.

주목할 통계: 초기에 "전부 프롬프트에 넣기(context stuffing)"를 배포한 기업의 71%가 12개월 내에 벡터 검색 레이어를 추가했다. 현실은 이론보다 복잡했던 것이다.

---

제7장: 2026년 가격표와 실무 패턴

주요 모델 가격 비교 (2026년 3월)

핵심 변화: Anthropic이 2026년 3월 13일 롱 컨텍스트 추가 요금을 폐지했다. 900K 토큰 요청이나 9K 토큰 요청이나 동일한 토큰당 가격이 적용된다. 이것은 Long Context 활용의 큰 장벽을 제거한 결정이다.

KV 캐시 메모리: 숨겨진 비용

Long Context의 숨겨진 비용은 KV 캐시 메모리다.

• 1M 토큰: 사용자당 약 15GB KV 캐시
• Llama 3.1 70B, 128K 컨텍스트: 40GB KV 캐시 (전체 모델 메모리의 29%)
• 128K 컨텍스트로 4건 동시 처리: 160GB KV 캐시 — 단일 H200(141GB)을 초과

이것은 인프라 설계에 직접적 영향을 미친다. Long Context를 대규모로 서빙하려면 상당한 GPU 메모리가 필요하다. NVFP4 양자화로 절반, nuq2 압축으로 8배까지 줄일 수 있지만, 여전히 무시할 수 없는 비용이다.

---

제8장: 미래 전망 — 어디로 가는가

시나리오별 확률 (2026-2028)

65%의 전문가가 하이브리드 수렴을 가장 가능성 높은 시나리오로 본다. RAG가 사라지는 것이 아니라, Long Context와 결합하여 더 강력한 시스템으로 진화한다.

RAG가 여전히 이길 수밖에 없는 이유들

Long Context가 무한대가 되더라도 RAG가 필요한 근본적 이유들:

1. "다이어그램은 grep할 수 없다" — 기업 문서의 많은 정보가 표, 차트, 이미지에 있다. 시각 정보는 텍스트 기반 Long Context로 처리할 수 없고, Vision-capable RAG 파이프라인이 필요하다.

2. 접근 제어 — 기업에서는 사용자 역할에 따라 문서 접근을 제한해야 한다. RAG는 검색 단계에서 이를 자연스럽게 구현한다. Long Context에 모든 문서를 넣는 것은 보안 위험이다.

3. 감사 추적(Audit Trail) — 규제 환경에서는 "어떤 문서를 참조해서 이 답변을 생성했는가"를 추적해야 한다. RAG의 검색 로그가 이를 제공한다.

4. 데이터 최신성 — 실시간으로 변하는 데이터(주가, 뉴스, 재고)는 Long Context에 미리 넣어둘 수 없다.

5. 규모 — 수천만 건의 문서를 다루는 엔터프라이즈 시스템에서, 모든 것을 프롬프트에 넣는 것은 물리적으로 불가능하다.

---

마치며

"RAG vs Long Context"는 잘못된 프레이밍이다. 2026년의 정답은 "RAG and Long Context"이다.

컨텍스트 윈도우가 10,000배 커진 것은 놀라운 기술 발전이다. 하지만 그것이 검색을 불필요하게 만든 것이 아니라, 검색된 결과를 더 깊이 추론할 수 있는 공간을 만들어줬다.

"더 많이 보는 것"과 "더 잘 찾는 것"은 경쟁이 아니라 상호 보완이다. 도서관에 비유하면, Long Context는 더 넓은 열람실이고, RAG는 더 정확한 사서(司書)다. 좋은 도서관에는 둘 다 필요하다.

---

참고 논문 및 자료:

• Lewis, P. et al. (2020). "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks." NeurIPS 2020. arXiv:2005.11401.
• Liu, N. et al. (2023). "Lost in the Middle." TACL 2024. arXiv:2307.03172.
• Li, J. et al. (2024). "Retrieval Augmented Generation or Long-Context LLMs?" EMNLP 2024. arXiv:2407.16833.
• Li, K. et al. (2025). "Long Context vs. RAG: An Evaluation and Revisits." arXiv:2501.01880.
• LaRA Benchmark (2025). ICML 2025. arXiv:2502.09977.
• Anthropic (2024). "Introducing Contextual Retrieval."