RAG를 넘어서 — 8가지 RAG 변형과 에이전트 메모리 설계

두괄식 요약

Naive RAG(질문 → 검색 → 생성)는 실전에서 일곱 가지 한계에 부딪힌다. 이를 극복하려는 시도가 Graph RAG·RAPTOR·Agentic RAG 등 여러 변형을 낳았지만, 2025년 시점의 정답은 단일 은탄환이 아니라 도메인에 맞는 하이브리드 조합이다.

먼저 핵심 명제 셋.

• Retrieval 품질이 전체 시스템 품질의 기반이다. Noise는 LLM이 정리할 수 있지만, Missing Evidence(정답 문서 누락)는 회복 불가능하다. 그래서 Recall@k가 Precision@k보다 우선이다.
• RAG와 Memory는 다르다. RAG는 외부 지식(교과서), Memory는 자기 경험(진료 기록)이다. 서로 대체할 수 없다.
• 변형 선택은 문제의 성격에 달렸다. 관계 추론은 Graph RAG, 다단계 추상화는 RAPTOR, 복잡·다양한 질문은 Agentic RAG다.

1. Naive RAG와 그 7가지 한계

RAG란

RAG(Retrieval-Augmented Generation)는 LLM이 답변하기 전에 외부 지식 베이스에서 관련 정보를 먼저 검색해 컨텍스트로 주입하는 기법이다. 전통 RAG는 네 단계로 동작한다.

1. Ingestion — 문서를 chunk로 분할하고 벡터 임베딩으로 변환
2. Storage — 임베딩을 벡터 DB에 저장
3. Retrieval — 질문도 임베딩한 뒤 코사인 유사도로 유사 chunk 검색
4. Generation — 검색된 chunk를 컨텍스트로 LLM에 주입

RAG를 쓰는 이유는 Fine-tuning과의 트레이드오프에서 나온다. 최신 정보·사내 비공개 문서·실시간 데이터가 필요하면 RAG가, 특정 스타일·도메인 언어 패턴 학습이 목적이면 Fine-tuning이 맞다. RAG는 비용이 낮고(벡터 DB + 검색), 문서만 추가하면 즉시 업데이트되며, 출처 문서 기반이라 환각 위험이 낮다.

7가지 근본 한계

Naive RAG는 다음 일곱 지점에서 무너진다.

1. 관계 모름   — chunk가 독립적이라 서로 연결 못함
2. 문맥 손실   — 청킹하면 맥락이 사라짐
3. 1회 검색    — 복잡한 질문에 한 번의 검색으론 부족
4. 중간 누락   — Lost in the Middle (긴 컨텍스트 중간 정보 무시)
5. 추상화 X   — 세부 chunk만 있고 전체 요약이 없음
6. 시간 모름   — 최신 정보를 구분 못함
7. 모순 처리 X — 상충하는 정보를 판단 못함

벡터 DB 자체의 구조적 한계도 있다. 인프라 부담(벡터 DB + 임베딩 모델 + API), chunk 경계에서의 컨텍스트 손실, "유사도 ≠ 관련성"(코사인 유사도가 실제 의미 관련성을 항상 잡진 못함), 블랙박스(사람이 저장소를 직접 열람·감사하기 어려움), 재인덱싱 부담이다.

이 한계들이 이후의 모든 RAG 변형을 낳았다.

2. RAG의 3세대 진화

RAG는 세 세대로 진화했다.

1세대 Naive     질문 → 검색 → 생성 (단순)
2세대 Advanced  검색 전후 품질 개선
3세대 Agentic   Agent가 검색 전략을 자율 결정

2세대: Advanced RAG

Advanced RAG는 검색 전후를 최적화한다.

Pre-Retrieval(검색 전). Query Rewriting("그거 알려줘" → "AI Agent 정의 알려줘"), Query Expansion("에이전트" → "에이전트 OR AI agent OR 자율 시스템"), HyDE(질문으로 가상 답변을 생성한 뒤 그 답변으로 검색)다.

Post-Retrieval(검색 후). Reranking(관련성 순 재정렬), Filtering(관련성 낮은 문서 제거), Compression(긴 문서에서 핵심만 추출)이다.

여기에 Anthropic의 Contextual Retrieval이 인덱싱 단계를 개선한다. chunk에 문맥을 추가하는 방식이다.

원본: "회사 수익이 3% 증가"
+ 문맥: "ACME사 2023년 Q2 SEC 공시에서..."
→ "ACME사 2023 Q2... 수익 3% 증가" (이 상태로 임베딩)
 
성능: 검색 실패율 67% 감소 (Reranking 포함)
비용: 프롬프트 캐싱으로 69% 절감

3세대: Agentic RAG

Agentic RAG는 Agent가 검색 전략을 자율 결정한다. "복잡하니 두 번 검색하자"고 판단하고, 첫 결과를 평가해 검색어를 바꾸며, 재검색 후 답변에 자체 검증까지 붙인다. 유연하지만 여러 추론을 거치므로 느리고 비용이 높다.

3. 8가지 구조별 변형

3세대 진화와 별개로, 구조에 따른 8가지 변형이 있다.

몇 가지를 자세히 보자.

Graph RAG — 벡터 대신 지식 그래프를 쓴다. [김철수] ─소속→ [보안팀] ─팀장→ [박영희]처럼 엔티티와 관계를 명시하므로 관계 추론과 멀티홉 질문에 강하다.

Self-RAG — LLM이 스스로 "검색이 필요한가?", "관련이 있나?", "근거가 있나?"를 판단해 할루시네이션을 줄인다.

Corrective RAG(CRAG) — 평가기가 검색 결과를 판정해 정확하면 사용, 모호하면 재검색, 틀리면 웹검색으로 대체한다.

Adaptive RAG — 질문 복잡도에 따라 전략을 자동 선택한다. 단순하면 LLM만, 보통이면 Single RAG, 복잡하면 Multi-hop + Self-RAG를 쓴다.

RAG-Fusion — 질문을 여러 변형으로 확장해 각각 검색한 뒤 합산한다. "Python 비동기" → "asyncio", "concurrent.futures", "threading vs async"로 나눠 검색하고 Reciprocal Rank Fusion으로 통합한다.

RAPTOR — 문서를 트리로 요약한다. [전체] → [섹션] → [chunk] 계층에서, 세부는 리프에서 개요는 루트에서 가져온다.

4. Beyond RAG — 6가지 극복 접근법

앞의 7가지 한계를 직접 겨냥한 여섯 접근법을 성능·비용과 함께 정리한다.

1. Graph RAG — 관계 명시

문서에서 엔티티와 관계를 추출해 그래프를 구축하고, 커뮤니티 클러스터를 사전 요약해 관계 기반으로 검색한다. 멀티홉 질문에서 약 20% 향상, 증거 출처가 명확하다는 장점이 있지만 구축 비용이 높고 실시간 업데이트가 어렵다.

2. CAG (Cache-Augmented) — 검색 제거

검색 자체를 없앤다. 전체 지식을 캐시로 로드해두고 LLM이 직접 생성한다.

RAG = 도서관에서 책 찾아 읽기 (검색 오류 가능)
CAG = 모든 책을 책상에 펼쳐놓기 (검색 없음)

검색 오류가 사라지고 캐싱으로 90% 비용 절감, 매우 빠른 응답이 장점이다. 단, 지식 크기가 약 1M 토큰으로 제한되고 실시간 업데이트가 불가능하다.

3. RAPTOR — 다단계 추상화

앞서 본 트리 요약 구조. 복잡 추론에서 약 20% 향상되지만 트리 구축 비용과 동적 업데이트 어려움이 단점이다.

4. RAG-Fusion — 다중 쿼리

Recall이 약 40% 향상되고 구현이 단순하지만, 검색 횟수가 늘고 Reranking 이후 실제 이득은 5~10% 수준이다.

5. Long Context — RAG를 아예 안 씀

100만 토큰을 청킹·검색하는 대신 전부 컨텍스트에 넣는다. 아키텍처가 단순하고 검색 오류가 없지만, 비용이 토큰에 비례하고 Lost in the Middle 문제가 남는다.

6. Agentic RAG — 자율 전략

앞서 설명한 3세대. 유연하고 에러를 자동 복구하며 여러 도구를 활용하지만, 느리고 비용이 높으며 구현이 복잡하다.

선택 가이드와 2025 최적: Hybrid

지식 고정·작음?    → CAG
관계 추론 핵심?    → Graph RAG
질문 복잡·다양?    → Agentic RAG
빠른 구현?         → Long Context / RAG-Fusion
최고 성능?         → 조합 (Hybrid)

은탄환은 없다. 2025년 최적 전략은 도메인 특성에 맞춘 하이브리드다.

[1] Agentic Layer     — "검색이 필요한가? 어떤 방식으로?"
[2] Retrieval Layer   — 벡터(의미) + BM25(키워드) + GraphRAG(관계)
[3] Integration Layer — Reciprocal Rank Fusion + Reranking
[4] Generation Layer  — 고정 지식은 CAG / 긴 문서는 Long Context / 복잡 추론은 RAPTOR

5. 실전 검색 설계 — 임베딩·청킹·하이브리드

변형 선택 위에, 실제 파이프라인을 굴리려면 세 가지 결정을 잘해야 한다. 임베딩 차원, 청킹, 하이브리드 검색이다. 여기서는 규격 문서(IEC 62443-4-2 등) 같은 의미 층위가 깊은 도메인을 예로 든다.

임베딩 차원 선택

임베딩 벡터는 텍스트 의미를 고차원 공간의 좌표로 표현한다. 차원 수는 "의미를 저장할 공간의 용량"이다. 차원이 작으면 Semantic Collision이 생긴다 — 표현 공간이 부족해 서로 다른 의미가 같은 차원을 공유한다. 예를 들어 "악성코드 방지 EDR 3.2"와 "악성코드 방지 HDR 3.2"의 벡터가 너무 가까워져 엉뚱한 조항이 함께 검색된다.

경험칙은 "1536으로 시작하고, 정밀도가 부족하면 3072로 전환"이다. 다만 1536 + 고급 Retrieval Pipeline으로 3072에 근접한 품질을 낼 수도 있다.

청킹 전략

가장 위험한 실수는 **Semantic Fragmentation(의미 단절)**이다. 문자열 단위로 자르면 "장기간"이 "장기 / 간"으로 쪼개져 LLM이 "장기(Organ) + 간(Liver)"로 오해한다.

나쁜 예 (고정 토큰 분할):
  청크1: "...보안 패치 적용 방법은 다음과 같다. 첫 번째"
  청크2: "단계는 시스템 업데이트를 실행하는 것이다..."
  → "첫 번째" + "단계는" 이 분리됨
 
좋은 예 (문장 경계 + 오버랩):
  청크1: "...적용 방법은 다음과 같다. 첫 번째 단계는..."
  청크2: "첫 번째 단계는... 두 번째 단계는..."
  → 오버랩으로 컨텍스트 보존

권장은 한 청크 = 25문장, overlap = 2030%다. 규격 문서라면 조항 세부 항목(3~5문장) 단위가 가장 안정적이다.

top-k에도 트레이드오프가 있다. k를 늘리면 Recall@k는 오르지만 Precision@k는 떨어지고(노이즈·비용 증가), 줄이면 정답 문서를 놓칠 위험이 있다(Cross-Encoder Reranking도 소용없다). 실무 sweet spot은 k = 5~10, 규격 문서는 k = 7이다.

하이브리드 검색: BM25 + Vector

BM25와 Vector는 약점이 상호 보완적이다.

Vector 단독은 "502 / 500 / 504"를 유사하게 인코딩하거나 "EDR 3.2" vs "HDR 3.2"를 너무 가깝게 만든다. BM25 단독은 "악성 코드 방지" vs "malware protection"을 못 잡는다. 그래서 Hybrid = BM25 × α + Vector × (1-α)로 결합한다(보통 α = 0.5로 시작).

전체 파이프라인은 이렇게 정리된다.

1. Query 정규화         — "악성 코드" → "악성코드" 용어 표준화
2. BM25 1차 필터        — 번호·약어·키워드로 후보 제한
3. Vector top-k 검색    — 의미 기반 후보 (k = 7)
4. Metadata Filtering   — type/FR/topic 등 메타데이터 필터
5. Cross-Encoder ReRank — 후보 사이 최종 순서 정밀 조정
6. 선택된 청크만 LLM 컨텍스트로 전달

Cross-Encoder Reranking이 2단계 검색의 핵심이다. 1단계 Bi-Encoder는 빠르지만 정밀도가 낮아 상위 20개 후보를 뽑고, 2단계 Cross-Encoder는 질문과 각 문서를 함께 입력해 정밀하게 상위 5~7개를 고른다. 느린 Cross-Encoder를 20개 후보에만 적용하므로 속도를 유지한다.

Recall@k가 최우선인 이유

"LLM은 정답 문서가 없으면 가짜 정답을 말할 수 있지만, Noise는 LLM이 정리할 수 있다."

이 한 문장이 RAG 설계 우선순위를 결정한다. Recall@k(top-k 안에 정답이 포함될 확률)가 최우선이고, Precision@k(top-k 중 실제 관련 비율)가 차순위다. 정답 문서를 못 가져오면 LLM은 근거 없이 환각을 생성하지만, 노이즈는 LLM이 걸러낼 수 있기 때문이다.

Self-Healing이 필요한 이유

에이전트 파이프라인은 단계가 길다. 단계별 성공률이 95%라도, 단계가 20개면 전체 성공률은 약 35%로 떨어진다.

단계 1개:  95%
단계 5개:  77%
단계 10개: 60%
단계 20개: 35%   ← 복잡한 에이전트 작업

Self-Healing은 국소 실패(Local Failure)를 전체 실패(Global Failure)로 확산시키지 않고 중간에서 흡수하는 안정성 레이어다. 네트워크/API 실패는 backoff 재시도로, 검색 실패는 Query Rewriting + 다른 전략으로, 잘못된 파라미터는 에러 분류 후 수정으로, 논리 오류는 Re-planning으로 대응한다. 벡터 검색이 실패하면 BM25로, BM25도 실패하면 키워드 직접 검색으로 폴백하고, 전역적으로는 Orchestrator가 감지해 "검색 없이 일반 지식으로만 응답" 모드로 전환한다.

6. RAG vs Memory — 외부 지식과 자기 경험

마지막으로 RAG와 자주 혼동되는 Memory를 구분한다. Memory는 Agent가 정보를 저장·회수하는 능력이다.

RAG:    "외부 문서에서 검색"  (남이 만든 지식)
Memory: "자기 경험을 저장"    (자기가 만든 지식)

에이전트 메모리 3레벨

Memory는 사람의 기억 체계에 대응한다.

단기는 컨텍스트 윈도우로 가장 빠르나 크기 제한이 있고, 중기는 대화 간 유지되어 다음 대화에서 참조되며, 장기는 영구적으로 모든 대화에 적용된다.

RAG와 Memory의 차이

의사의 비유가 명확하다. RAG는 의학 교과서·논문 DB로 "이 증상의 일반 치료법?"에 답하고, Memory는 이 환자의 진료 기록으로 "이 환자는 페니실린 알레르기"를 기억한다. 둘 다 정보지만 성격이 다르며, 교과서를 진료 기록에 넣거나 그 반대를 하지 않는다.

실질 구분도 단순하다. 모든 사람에게 유용하고 양이 많으면 RAG(공유 지식, 벡터 검색), 나만 알면 되고 핵심만이면 Memory(개인 경험, 파일 읽기)다.

Long-term Memory의 올바른 저장 전략

주의할 점 하나. 과거 대화를 전부 벡터 DB에 쌓으면 데이터가 폭증하고 중복·노이즈가 늘어 Recall과 Precision이 동시에 하락한다. 올바른 전략은 과거 대화를 의미 단위로 요약한 뒤 벡터화하는 것이다. 이렇게 하면 의미 밀도(semantic density)가 높아지고 중복·노이즈가 줄어 검색 품질·속도·비용이 모두 개선된다.

종합

RAG는 "질문 → 검색 → 생성"이라는 단순한 출발점에서, 일곱 가지 한계를 하나씩 극복하며 여덟 가지 변형과 여섯 가지 확장으로 갈라졌다. 하지만 실전의 결론은 화려한 단일 기법이 아니다.

• Retrieval 품질이 전부의 기반이다. Recall@k를 최우선으로, Missing Evidence를 막아야 한다.
• 은탄환은 없다. Graph RAG·RAPTOR·CAG·Agentic RAG를 도메인에 맞게 조합한 하이브리드가 2025년의 답이다.
• RAG와 Memory를 섞지 마라. 외부 지식(교과서)과 자기 경험(진료 기록)은 다른 저장소, 다른 전략이다.
• 긴 파이프라인엔 Self-Healing이 필수다. 단계가 20개면 성공률이 35%로 떨어진다. 국소 실패를 흡수하는 레이어 없이는 복잡한 에이전트가 굴러가지 않는다.

RAG를 넘어선다는 것은 벡터 검색을 버린다는 뜻이 아니다. 문제의 성격을 정확히 진단하고, 그에 맞는 검색·추상화·메모리 전략을 조합하는 설계 감각을 갖춘다는 뜻이다.

참고 자료

• RAG 원조: Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (NeurIPS 2020, arXiv 2005.11401)
• REALM (PMLR 2020), Dense Passage Retrieval (EMNLP 2020)
• Anthropic — Contextual Retrieval
• 프레임워크: LangChain, LlamaIndex, Unstructured