“RAG는 죽었다!” — AI 업계에서 이 주장은 2023년 말부터 새로운 대형 컨텍스트 윈도우가 발표될 때마다 반복되어 왔습니다. 100만 토큰 윈도우에 모든 걸 넣으면 되는데, 왜 복잡한 검색 파이프라인을 유지하느냐는 논리죠. Sebastian Raschka도 2025년 말 연례 리포트에서 “고전적 RAG가 기본 솔루션으로서 서서히 사라질 것”이라 전망했습니다. 하지만 현실은 이 선언보다 조금 더 복잡합니다.
Sebastian Raschka의 전망
2025년 12월 30일 발표된 “The State of LLMs 2025” 리포트에서 Raschka는 2026년 주요 예측 중 하나로 이를 내놓았습니다.
“고전적 RAG는 문서 쿼리의 기본 솔루션으로서 서서히 사라질 것이다. 모든 문서 관련 쿼리에 검색을 사용하는 대신, 개발자들은 더 나은 긴 컨텍스트 처리에 더 많이 의존할 것이며, 특히 더 나은 ‘소형’ 오픈 웨이트 모델이 등장할 것이기 때문이다.”— Sebastian Raschka, “The State of LLMs 2025” (2025.12.30)
흥미로운 것은, 2025년 초에는 Raschka 자신도 “RAG가 긴 컨텍스트 옵션에도 불구하고 여전히 큰 주제라는 것이 놀랍다”고 했다는 점입니다. 1년 사이에 풍경이 바뀐 거죠.
출처: Raschka — The State of LLMs 2025 (2025.12.30)
“RAG는 죽었다” 논쟁의 역사
이 논쟁은 컨텍스트 윈도우 경쟁과 함께 시작되었습니다.
- 2023년: 컨텍스트 윈도우 4K~8K 시절 → RAG가 필수 기본 패턴
- 2024년 2월: Gemini 1.5 Pro 1M 토큰 출시 → “RAG is Dead” 논쟁 본격화
- 2024년 11월: Anthropic MCP 출시 → “MCP가 RAG를 죽였다!” (실은 MCP 자체가 검색 메커니즘인데 말이죠)
- 2025년 2월: Claude Code가 벡터 검색 없이 grep만으로 출시 → “최종 확인 사살”이라는 반응
하지만 이 “RAG 킬러”들 중 실제로 검색(retrieval)을 죽인 것은 없었습니다. 검색이 진화한 것이죠.
출처: LightOn — RAG is Dead, Long Live RAG
Claude Code의 RAG 포기: 에이전틱 검색의 탄생
RAG 논쟁에서 가장 상징적인 전환점은 Claude Code가 벡터 DB 기반 RAG를 포기한 사건입니다.
Claude Code 개발 리드 Boris Cherny는 Latent Space 팟캐스트(2025년 5월)에서 이렇게 밝혔습니다.
“우리는 실제로 RAG와 로컬 벡터 DB를 사용한 초기 버전을 시도했다. 결국 에이전틱 검색이 일을 하는 방식으로 결정했다. 두 가지 이유가 있었다. 하나는 그것이 모든 것을 능가했다는 것이다. 크게. 이것은 놀라웠다.”— Boris Cherny, Anthropic (2025.05)
Claude Code의 작동 방식은 놀라울 정도로 단순합니다. 벡터 데이터베이스도, 임베딩도, 사전 인덱스도 없습니다. 함수가 어디서 정의되었는지 물으면, 터미널에서 grep하듯 레포를 검색합니다. 다만 수십 개의 검색을 연쇄적으로 실행하고, 경로를 수정하며, 필요한 것을 찾을 때까지 계속하죠.
깊은 조사가 필요할 때는 Haiku 모델 기반의 Explore 서브에이전트를 생성해서 자체 격리된 컨텍스트 윈도우에서 탐색하고, 결과만 메인 대화에 반환합니다. 이렇게 하면 메인 에이전트의 컨텍스트가 오염되지 않습니다.
이것이 바로 “에이전틱 검색(Agentic Search)”입니다. 전통 RAG의 “청크 → 임베딩 → 벡터 DB → 검색 → 생성”이라는 무거운 파이프라인 대신, LLM 자체가 검색 알고리즘이 되는 셈이죠.
출처: Vadim Nicolai — Claude Code Doesn’t Index Your Codebase (2026) / PageIndex — From Claude Code to Agentic RAG
그런데… RAG가 정말 죽었을까?
데이터는 정반대를 말해줍니다.
- RAG 프레임워크 사용량: 2024년 이후 400% 급증
- 프로덕션 LLM 앱의 60%가 RAG 사용 중
- 기업들의 지식 집약적 워크플로우에서 30~70% 효율성 향상 보고
비용 비교도 RAG에 유리합니다.
| 지표 | RAG | 긴 컨텍스트 |
|---|---|---|
| 비용 | 8~82배 저렴 | 기준 |
| 응답 시간 | ~1초 | 30~60초 (360K+ 토큰) |
| 토큰 사용 | 347 토큰 (관련 3개 문서) | 834 토큰 (전체 10개 문서) |
| 정확도 | 일관적 | 중간 위치 정보 시 10~20%p 하락 |
핵심 차이를 한 문장으로 요약하면: “컨텍스트 윈도우는 모델이 얼마나 많이 볼 수 있는지를 정의하고, RAG는 모델이 무엇을 봐야 하는지를 결정한다.” 큰 윈도우는 용량을 늘리지만 관련성을 높이지는 않습니다.
출처: LightOn — RAG to Riches (비용 비교) / byteiota — RAG vs Long Context 2026
업계의 합의: “단순한 RAG는 죽었다, 정교한 RAG는 번성 중”
2025년 말, 업계의 실질적 합의는 이것으로 수렴하고 있습니다.
“‘RAG는 죽었다’는 클릭베이트이다. ‘항상 RAG를 사용하라’는 카고 컬트 엔지니어링이다. 정답은 지루하다: 요구사항을 평가하고, 트레이드오프를 이해하고, 제약 조건을 충족하는 가장 단순한 솔루션을 선택하라.”
사용 사례별 판단 기준이 명확해졌습니다.
긴 컨텍스트가 좋은 경우: 데이터셋이 정적이고, 문서가 100개 미만이며, 총 토큰이 100K 이하이고, 30~60초 응답 시간을 허용할 수 있을 때. 프로토타이핑이나 일회성 분석에 적합합니다.
RAG가 좋은 경우: 1,000개 이상의 대규모 문서, 정밀도와 비용 효율이 중요할 때, 실시간 데이터 업데이트가 필요할 때, 속도가 핵심일 때 (1초 vs 30~60초).
RAG의 세 가지 진화 방향
1. 에이전틱 RAG (Agentic RAG)
2023년의 “항상 k개 청크를 검색”에서, 2025년에는 모든 쿼리가 검색을 필요로 하지 않으며, 검색할지 여부 자체를 에이전트가 판단하는 조건부 시스템으로 진화했습니다. 쿼리 유형, 최신성 요구, 현재 지식의 충분성 등을 고려한 결정 스택이 된 것이죠.
2. RAG에서 “컨텍스트 플랫폼”으로
투자 회사 Theory Ventures가 제시한 비전인데, 기술 중심의 검색 엔진(Retrieval Engine)을 컨텍스트 엔진(Context Engine)으로 업그레이드하는 것입니다. 단순히 관련 문서를 찾아주는 것이 아니라, AI 에이전트가 필요로 하는 정보를 적시에 효율적으로 검색·필터·검증·정리하는 통합 플랫폼이 되는 것이죠.
3. 벡터리스(Vectorless) 추론 기반 검색
Claude Code가 보여준 것처럼, LLM 자체의 추론 능력을 검색 알고리즘으로 활용하는 접근입니다. PageIndex 같은 프로젝트는 문서를 계층적 트리 구조로 표현하고, LLM이 이 인덱스를 보고 스스로 “어디에 답이 있을지” 추론한 뒤 해당 부분만 읽는 방식을 구현하고 있습니다. 청킹도, 임베딩도, 벡터 DB도 없이, 구조와 추론만으로 검색하는 것이죠.
출처: RAGFlow — From RAG to Context (2025.12.22) / PageIndex — From Claude Code to Agentic RAG
Cursor vs Claude Code: RAG 논쟁의 축소판
이 논쟁의 축소판이 Cursor와 Claude Code의 대비입니다.
Cursor는 처음부터 코드베이스 인덱싱에 투자했습니다. 레포를 의미 있는 청크로 분해하고, 벡터로 임베딩하고, AI가 필요할 때 시맨틱 검색을 합니다. 교과서적 RAG를 코드에 적용한 것이죠.
Claude Code는 정반대입니다. 인덱스도, 임베딩도 없이 grep과 glob만 사용합니다. 대신 모델이 스스로 “무엇을 검색할지, 어떻게 정제할지, 언제 멈출지” 결정합니다.
둘 다 장단점이 있습니다. grep은 “createD1HttpClient” 같은 정확한 함수명을 찾을 때는 완벽하지만, “인증 프로세스가 어디서 처리되는가?” 같은 의미론적 질문에는 약합니다. 반면 시맨틱 검색은 이런 질문에 강하지만 인프라 복잡성이라는 대가를 치릅니다.
현실적 최적점은 아마 “가벼운 로컬 인덱싱 + 모델 주도 쿼리 정제”의 하이브리드일 것입니다.
출처: Alberto Roura — Vector RAG? Agentic Search? Why Not Both? / Milvus — Why I’m Against Claude Code’s Grep-Only Retrieval
마무리
Raschka의 전망은 실현되고 있습니다. 하지만 그것은 RAG 자체의 죽음이 아니라 진화입니다.
2023년식 “청크 → 임베딩 → 벡터 DB → 검색 → 생성”의 단순 파이프라인은 퇴조하고 있고, 그 자리를 에이전틱 검색, 조건부 RAG, 컨텍스트 엔지니어링이 채우고 있습니다.
이 변화의 핵심 교훈은 단순합니다. “더 큰 컨텍스트 윈도우”도 “더 나은 RAG”도 만능이 아니며, 과제의 특성에 맞는 올바른 검색 전략의 선택이 진짜 실력이다.”
한 논평자의 말이 이 논쟁의 본질을 가장 잘 요약합니다.
“돌이켜보면, RAG는 보조 바퀴처럼 보일 것이다. 유용하고, 필요했지만, 일시적이었다.”
하지만 지금 당장은, 그 “보조 바퀴”가 기업 AI의 60%를 지탱하고 있습니다. 보조 바퀴를 벗기 전에, 새로운 균형 감각이 충분히 갖춰졌는지 확인하는 것이 현명할 것 같습니다.
📚 주요 출처
- Raschka — The State of LLMs 2025 (2025.12.30)
- RAGFlow — From RAG to Context (2025.12.22)
- LightOn — RAG is Dead, Long Live RAG
- Vadim Nicolai — Claude Code Doesn’t Index Your Codebase
- Pinecone — Beyond the hype: Why RAG remains essential
- Nicolas Bustamante — The RAG Obituary
- Alberto Roura — Why Not Both?
- LightOn — RAG to Riches (비용 비교)
- byteiota — RAG vs Long Context 2026