"분명히 우리 문서에 있는 내용인데, AI가 왜 모른다고 하지?"

RAG를 써본 사람이라면 한 번쯤 겪어봤을 이 답답함. 요즘 AI 개발자들 사이에서 "RAG is Dead"라는 말이 돌고 있다. 결론부터 말하면, 반은 맞고 반은 틀리다.

문서를 자르는 순간, 맥락이 죽는다

RAG의 동작 원리는 단순하다. 문서를 잘게 자르고, 숫자(임베딩)로 바꾸고, 질문과 가장 비슷한 조각을 찾아 AI에게 넘긴다. 이론상 완벽하다.

문제는 자르는 그 순간 생긴다.

"마케팅 비용이 전분기 대비 15% 증가했다." 이 조각만 보면 어느 회사인지, 몇 분기인지, 기준이 뭔지 알 수 없다. 책 한 페이지를 찢어서 주는 것과 같다. 앞뒤 문맥이 없으면 그 문장은 쓸모없는 정보가 된다.

그래서 실제로 써보면, 문서에 분명히 있는 내용인데 AI가 엉뚱한 답을 내뱉는다. 이게 1세대 RAG의 근본적 한계다.

RAG의 4세대 — 공존하는 현재

최근 수집된 논문, GitHub 프로젝트, 실무 사례를 종합하면 RAG는 현재 4개의 세대가 동시에 공존하고 있다.

1세대: 단순 RAG (사실상 퇴물)

문서 청킹 + 벡터 검색. 위에서 말한 "맥락 소실" 문제를 피할 수 없다. AI Insider Club의 표현이 정확하다 — "단순 RAG는 진짜 쓰레기입니다."

2세대: Advanced RAG (현재 실무 표준)

단순 벡터 검색의 한계를 보완하기 위해 여러 기법이 쌓인다.

  • Hybrid Search: 의미 검색("매출 증가" → "수익 상승")과 키워드 검색을 동시에 돌린다
  • Reranking: 검색 결과를 전문 AI가 한 번 더 걸러 진짜 관련 있는 것만 골라낸다
  • Contextual Chunking (Anthropic 제안): 조각을 자르기 전에 "이 내용은 A기업 2024년 3분기 실적 보고서의 마케팅 지출 섹션입니다"라는 설명을 붙인다. 검색 실패율이 67% 감소했다

여기에 실용적 팁 하나를 더하면: 요약본으로 검색하고, 원문으로 AI에 전달하는 방식이 있다. 도서관 목록 카드로 책을 찾고, 실제로는 본문을 읽는 원리다. 검색은 빠르고 정확하게, 답변은 깊고 정확하게.

3세대: GraphRAG (성능은 좋지만 비싸다)

문서들 사이의 관계를 그래프로 매핑한다. "A 문서가 B를 인용하고, C와 관련 있다"는 관계를 미리 정리해두는 것이다. 복잡한 질문에 대한 답변 품질이 크게 올라간다.

WildGraphBench라는 벤치마크가 최근 등장해 GraphRAG의 실제 성능을 본격적으로 측정하기 시작했다. 정제되지 않은 실제 데이터에서 GraphRAG가 얼마나 버티는지가 관건이다.

문제는 구축 비용. 문서가 추가되거나 수정될 때마다 관계도를 다시 그려야 한다. 솔직히 스타트업이나 중소기업이 유지보수할 인력이 있을까?

4세대: 에이전틱 / 벡터리스 (급부상 중)

여기서 이야기가 흥미로워진다. RAG 파이프라인 자체를 버리는 접근이 등장했다.

"벡터 없는 RAG"라는 역발상

GitHub에서 트렌딩된 PageIndex(VectifyAI)가 주목할 만하다. 벡터 임베딩 자체를 쓰지 않는다. 대신 AI의 추론 능력으로 문서를 인덱싱한다.

이건 RAG의 근본 가정 — "문서를 벡터로 변환해야 검색 가능" — 을 정면으로 뒤집는 것이다.

왜 중요한가? 벡터 파이프라인은 고정된 시스템이다. 아무리 정교하게 만들어도 그건 만든 시점에 멈춰 있다. 반면 추론 기반은 AI 모델이 똑똑해질수록 자동으로 같이 좋아진다. 인프라 변경 없이.

Claude Code가 RAG를 거부한 이유

Claude Code라는 AI 코딩 도구가 있다. 다른 도구들과 크게 다른 점이 하나 있다. RAG를 안 쓴다.

대신 사람이 문서를 찾을 때 하는 방식 그대로 한다. Read로 파일을 읽고, Glob로 패턴을 찾고, Grep으로 내용을 검색한다. AI가 이 도구들을 직접 조합하면서 탐색한다.

Claude Code 창시자 Boris Cherny의 원래 아이디어가 바로 이거였다고 한다 — "AI에게 도구를 자유롭게 쓰게 해주면 어떻게 될까?"

이일민(Toby Lee) 님이 Claude Code에게 직접 도구 목록을 물어본 적이 있다. Read, Write, Edit, Glob, Grep, Task... 17개 도구를 AI가 상황에 따라 자유롭게 조합한다. RAG 파이프라인이 아니라 도구 사용 능력이 핵심인 것이다.

CodeRLM이 증명한 것

HN에 올라온 CodeRLM 프로젝트가 이 아이디어를 코드 도메인에서 입증했다.

Tree-sitter로 코드베이스의 심볼 테이블을 구축하고, AI가 구조적으로 탐색한다. 같은 프롬프트로 실험한 결과:

에이전틱 탐색 (CodeRLM) 기존 방식 (glob/grep/read)
소요 시간 3분 8분
발견 유형 시맨틱 이슈 (중복 코드, 네이밍 불일치, 고아 코드) 파일 구조 이슈 (파일 정리, 참조 오류)

에이전틱 방식이 시맨틱 이슈 발견에서 압도적으로 우월했다. 그리고 더 빨랐다.

테슬라 vs 웨이모, 그 논쟁의 데자뷰

누군가 이런 비유를 했다.

"이건 자율주행의 카메라 vs 라이다 논쟁과 같다."

테슬라는 카메라만 쓴다. 웨이모는 라이다를 단다. 라이다가 더 정밀한 건 사실이다. 하지만 테슬라는 카메라만으로도 주행 데이터를 쌓으며 점점 따라잡고 있다.

RAG가 라이다다. 정확해 보이지만 복잡하고, 확장하기 어렵고, 한 부품이 고장 나면 전체가 흔들린다.

에이전틱 탐색이 카메라다. 단순하고, AI가 발전할수록 자동으로 좋아진다.

그런데 보안은 괜찮은가?

한 가지 더 짚어야 할 것이 있다. 최근 논문에서 RAG 시스템의 Knowledge-Extraction Attack이 벤치마킹되고 있다. 프롬프트 인젝션뿐 아니라, 검색된 문서의 내용을 역추출하는 공격이 가능하다는 것이다.

기업 내부 문서를 RAG로 연결할수록 공격 표면도 커진다. 편리함과 보안 사이의 트레이드오프를 진지하게 고려해야 할 시점이다.

실무 의사결정 가이드

그래서 뭘 써야 하나? 상황별로 다르다.

상황 추천 이유
문서 50개 미만 Long Context (통째로) 파이프라인 불필요, 정확도 최고
문서 50~1,000개 Contextual RAG 맥락 설명 + Hybrid Search
문서 1,000개+, 관계 중요 GraphRAG 성능 최고, 비용 감수 필요
코드베이스 Agentic (CodeRLM 등) 구조적 탐색이 청킹보다 우월
빠른 MVP 요약 인덱싱 + 원문 전달 도서관 카탈로그 방식

결론: 죽은 건 RAG가 아니라 게으른 RAG다

"RAG is Dead"는 절반만 맞다. 단순 RAG가 퇴물이 되고 있는 것이지, RAG 자체가 죽은 건 아니다.

미래는 두 갈래다. 더 정교해지거나(Contextual/Graph), 아예 AI가 직접 찾게 하거나(Agentic). 어느 쪽을 선택할지는 데이터 규모와 팀 역량이 결정한다.

한 가지 확실한 건, 문서를 무작정 잘라서 벡터 DB에 넣고 "RAG 구축 완료"라고 말하는 시대는 끝났다는 것이다.

이 글은 Contents Hub에서 수집된 8건의 RAG 관련 콘텐츠를 기반으로 작성되었습니다.

Sources: