RAG도 캐시가 필요하다: 매번 처음부터 검색하는 시스템의 비효율

서민성·2026년 5월 26일
AILLMStateful RAGragrag 논문검색 최적화캐시

RAG도 캐시가 필요하다: 매번 처음부터 검색하는 시스템의 비효율

"어, 이 질문 아까도 했는데..."

여러분이 운영하는 서비스에 RAG 기반 Q&A 챗봇이 있다고 가정해봅시다. 사용자들이 매일 수천 건의 질문을 던집니다. 그런데 로그를 들여다보면 뭔가 이상한 걸 발견하게 됩니다.

09:02:14 - "GPT-4o의 컨텍스트 윈도우 크기는?"
09:17:33 - "GPT-4o 컨텍스트 길이 알려줘"
09:31:45 - "GPT-4o는 몇 토큰까지 처리할 수 있어?"
09:44:02 - "GPT-4o context window가 얼마야?"

네 질문이 사실상 같은 질문입니다. 그런데 여러분의 RAG 시스템은 이 질문들을 처리할 때마다 완전히 동일한 과정을 처음부터 반복합니다. 임베딩을 만들고, 벡터 DB를 뒤지고, 문서를 긁어오고, LLM에 집어넣고, 답변을 생성합니다. 네 번, 똑같이.

데이터베이스 개발자였다면 이 상황에서 바로 이렇게 말했겠죠.

"쿼리 캐시 없어요? 실행 계획이라도 저장해두지."

맞습니다. 수십 년 전 DBMS가 이미 해결한 문제를 RAG 시스템은 아직도 반복하고 있습니다. 매번 처음부터, 기억도 없이, 경험도 없이.

이 글은 이 비효율을 정면으로 겨누는 세 편의 연구를 통해, RAG 시스템이 어떻게 stateless(무상태)에서 stateful(유상태)로 진화하고 있는지 이야기합니다. RAG를 직접 구축하거나 운영하는 분들이라면 꽤 공감할 내용일 겁니다.

1. 왜 RAG는 매번 같은 일을 반복하는가

RAG의 탄생 배경, 그리고 구조적 한계

RAG(Retrieval-Augmented Generation, 검색 증강 생성)가 등장한 이유는 명확합니다. LLM은 학습 데이터에 없는 최신 정보를 모르고, 특정 도메인의 내부 문서를 모르며, 환각(hallucination)을 일으킵니다. 해결책은 간단했죠 — 물어볼 때마다 관련 문서를 검색해서 LLM에게 같이 넘겨주면 된다고.

그래서 전통적인 RAG 파이프라인은 이렇게 생겼습니다.

사용자 질문
    ↓
[쿼리 임베딩] → 벡터화
    ↓
[벡터 검색] → 유사 문서 Top-K 가져오기
    ↓
[컨텍스트 조합] → 질문 + 문서
    ↓
[LLM 생성] → 최종 답변
    ↓
사용자에게 반환 (그리고 모든 것을 잊는다)

마지막 줄에 주목하세요. "모든 것을 잊는다."

이게 핵심 문제입니다. 전통적인 RAG는 완벽한 기억상실증 환자처럼 작동합니다. 방금 전에 같은 질문을 처리했어도, 어떤 문서가 유용했는지 기억하지 못하고, 어떤 추론 경로가 효과적이었는지 축적하지 못합니다.

GAM-RAG 논문은 이 문제를 이렇게 표현합니다.

"Once the index is constructed, its topology remains fixed and does not incorporate feedback from historical retrievals. Consequently, each query is processed independently, and similar or recurring queries often trigger the same traversal and reasoning steps."

번역하자면: 인덱스는 한 번 만들어지면 굳어버리고, 이전 검색에서 뭘 배웠든 전혀 반영되지 않는다는 겁니다. 비슷한 질문이 오면? 똑같은 경로를 다시 걷습니다.

이게 왜 실제로 문제인가

개발자 입장에서 이 비효율이 얼마나 구체적인 손해를 낳는지 정리해보면:

문제 유형실제 영향
반복 검색동일/유사 쿼리마다 벡터 DB 조회 비용 중복 발생
반복 추론Multi-hop 질문에서 같은 추론 체인을 매번 LLM으로 재구성
토큰 낭비이미 처리한 컨텍스트를 다시 프롬프트에 집어넣음
레이턴시캐싱/재사용 없으니 매번 최악의 경우를 가정한 처리 시간
품질 정체과거 실패에서 배우지 못하니 같은 실수 반복

AutoPrunedRetriever 논문도 같은 문제를 날카롭게 짚습니다.

"Most RAG systems treat each query independently. Even when multiple questions are closely related—or arise sequentially in agentic workflows—systems repeatedly re-retrieve overlapping passages and re-reason from scratch. This leads to substantial redundancy in retrieved context, inflated token usage, higher latency, and increased cost."

특히 "agentic workflows"가 언급된 게 흥미롭습니다. 단순 Q&A가 아니라 여러 에이전트가 연쇄적으로 질문을 던지는 복잡한 파이프라인에서는 이 비효율이 기하급수적으로 증폭됩니다.

2. Stateless vs Stateful: 심부름꾼과 전문가의 차이

이 개념을 직관적으로 이해하기 위해 비유를 하나 들어봅시다.

기억 없는 심부름꾼 (Stateless RAG)

당신이 도서관에 심부름꾼을 보냅니다. "GPT-4o 관련 자료 가져와줘." 심부름꾼은 도서관을 뒤지고, 자료를 가져옵니다. 당신이 다음 날 또 보냅니다. "GPT-4o 성능 비교 자료 가져와줘." 심부름꾼은 또 도서관을 처음부터 뒤집니다. 어제 어떤 선반에서 관련 자료를 찾았는지? 전혀 기억 못합니다. 다음 주에 같은 요청이 와도 마찬가지입니다.

이게 stateless RAG입니다. 매번 새로운 심부름꾼이 투입됩니다.

경험 축적하는 전문가 (Stateful RAG)

반면 경험 많은 사서는 다릅니다. "아, GPT-4o요? 지난달에도 비슷한 질문이 있었는데, 그때는 3번 섹션 AI 저널 선반에서 찾았어요. 거기부터 보시면 빠를 거예요." 성공했던 경로를 기억하고, 비슷한 요청이 오면 그 경험을 활용합니다. 처음 찾을 때보다 훨씬 빠르고, 더 관련성 높은 자료를 가져옵니다.

이게 stateful RAG가 지향하는 방향입니다.

Stateless RAG          Stateful RAG
─────────────          ────────────
쿼리 A → 검색 → 답변    쿼리 A → 검색 → 답변
쿼리 B → 검색 → 답변        ↓ (경험 저장)
쿼리 C → 검색 → 답변    쿼리 B → [캐시 확인] → 빠른 답변
(각각 독립, 기억 없음)       ↓ (패턴 축적)
                        쿼리 C → [재사용 확장] → 더 빠른 답변
                        (점점 영리해지는 시스템)

CacheRAG 논문은 이 비유를 DBMS 영역에서 가져옵니다.

"This design mirrors a hypothetical database system that optimizes every query from scratch without a plan cache: an inefficiency that modern DBMSs resolved decades ago through execution plan caching."

MySQL이나 PostgreSQL 같은 DB는 동일한 쿼리가 반복되면 파싱과 최적화 결과를 캐시해서 재활용합니다. 수십 년 된 기술입니다. 근데 RAG는? 아직도 매번 처음부터입니다.

3. 세 가지 "기억" 전략: 논문별 접근법 비교

이제 각 논문이 어떤 방식으로 이 문제를 풀었는지 살펴봅시다. 세 논문은 "기억을 도입한다"는 공통 목표를 갖고 있지만, 무엇을 기억하고, 어떻게 활용하는지가 서로 다릅니다.

논문 1: GAM-RAG — "어떤 문장이 효과적이었는지 기억하라"

핵심 아이디어: 검색이 성공할 때마다 "어떤 문장이 유용했는가"를 메모리에 기록하고, 비슷한 추론 타입의 질문이 오면 그 문장이 더 빨리 활성화되도록 만든다.

GAM-RAG는 신경과학의 헤비안 학습(Hebbian learning)에서 영감을 받았습니다. 뇌에서 같이 발화하는 뉴런들은 연결이 강화됩니다("cells that fire together, wire together"). 비슷한 맥락에서, 함께 검색에 성공한 문장들은 인덱스에서 서로 연결 강도가 높아집니다.

기술적으로 흥미로운 부분은 불확실성 인식 업데이트 규칙입니다. 논문은 칼만 필터(Kalman Filter)에서 영감을 받은 gain rule을 도입합니다.

피드백이 신뢰할 만하다 (새롭고 명확한 신호)
    → 메모리를 빠르게 업데이트 (높은 gain)

피드백이 불안정하다 (노이즈가 많거나 이미 잘 알려진 패턴)
    → 메모리를 보수적으로 업데이트 (낮은 gain)

이 덕분에 잘못된 검색 피드백이 메모리를 오염시키는 걸 방지하면서, 진짜 유용한 새로운 경험은 빠르게 반영할 수 있습니다.

결과: 5턴 메모리 축적 후 기존 대비 평균 8.19% 성능 향상, 추론 비용 61% 감소.

💡 한 줄 요약: GAM-RAG는 "어떤 문장이 어떤 추론 타입에 유용했는지"를 점진적으로 학습하는 문장 수준 경험 메모리를 만든다.

논문 2: AutoPrunedRetriever — "추론 그래프 자체를 저장하라"

핵심 아이디어: 질문에 답하기 위해 구성한 "최소 추론 서브그래프(minimal reasoning subgraph)"를 저장해두고, 다음 관련 질문이 오면 이 그래프를 재사용하거나 점진적으로 확장한다.

전통적인 RAG가 "문서 덩어리"를 가져온다면, AutoPrunedRetriever는 추론 과정에서 실제로 사용된 엔티티-관계 구조만 뽑아서 저장합니다. 마치 수사관이 사건을 정리할 때 전체 증거 박스가 아니라 범인을 특정하는 데 쓰인 핵심 증거 관계도만 따로 보관하는 것처럼요.

구조를 좀 더 풀어보면:

[질문 A 처리 시]
전체 문서 검색 → 추론 실행 → 사용된 엔티티/관계만 추출
                                    ↓
                            [Reasoning Subgraph 저장]
                            Entity A → Relation X → Entity B
                            Entity B → Relation Y → Entity C

[유사 질문 B 처리 시]
저장된 서브그래프 확인 → 겹치는 부분은 재사용
                          새로운 부분만 추가 검색/추론
                                    ↓
                            [서브그래프 점진적 확장]

특히 이 시스템은 두 단계 통합 정책(two-layer consolidation policy)을 씁니다. ANN/KNN 기반 빠른 중복 감지로 같은 엔티티가 여러 이름으로 저장되는 걸 막고, 메모리 임계치에 도달하면 k-means로 비슷한 구조를 병합해서 그래프를 컴팩트하게 유지합니다.

프롬프트 구성도 영리합니다. 저장된 그래프와 새 질문의 겹치는 부분을 대표 요소만 넣고, 진짜 새로운 증거만 추가합니다. 결과적으로 프롬프트 토큰이 극적으로 줄어듭니다.

결과: 복잡한 추론 정확도에서 HippoRAG2 대비 9~11포인트 향상, 토큰 사용량은 그래프 기반 경쟁 시스템 대비 최대 100배 감소.

💡 한 줄 요약: AutoPrunedRetriever는 "이전 질문을 풀면서 만든 추론 구조"를 저장해두고, 다음 질문에 재사용·확장하는 추론 그래프 재활용 전략을 쓴다.

논문 3: CacheRAG — "쿼리 플랜 자체를 캐시하라"

핵심 아이디어: KGQA(Knowledge Graph QA) 환경에서, LLM이 매번 새로 만들어야 하는 "retrieval plan"(검색 계획)을 과거 유사 질문에서 캐시해두고 재활용한다.

CacheRAG의 배경은 조금 다릅니다. 지식 그래프(Knowledge Graph, KG)를 대상으로 하는 QA 시스템은 단순히 문서를 가져오는 게 아니라, SPARQL 쿼리 같은 검색 플랜을 생성해야 합니다. 그리고 이 플랜 생성 과정에서 LLM은 두 가지 고질적인 문제를 일으킵니다.

  1. 스키마 환각(Schema Hallucination): KG에 없는 속성명을 꾸며냅니다 (예: topic이라는 속성이 없는데 쿼리에 넣음).
  2. 불완전한 검색: 관련 속성을 빠뜨려서 답이 엉뚱하게 나옵니다.

CacheRAG의 해결책은 세 가지 핵심 원칙으로 구성됩니다.

① 스키마-독립적 사용자 인터페이스
자연어 질문을 ISR(Intermediate Semantic Representation, 중간 의미 표현)로 파싱하고, 이 ISR을 실제 KG 스키마에 맞게 변환합니다. 사용자는 KG 구조를 몰라도 됩니다.

② 다양성 최적화 캐시 검색
단순히 "가장 비슷한 과거 플랜"을 가져오는 게 아닙니다. 두 계층 인덱스(도메인 → 관점)와 MMR(Maximal Marginal Relevance)를 결합해서, 유사하되 다양한 과거 플랜을 가져옵니다. 비슷한 예시만 잔뜩 가져오면 추론이 특정 패턴에 갇히는 "추론 동질화(reasoning homogeneity)" 문제가 생기거든요.

③ 제한적 휴리스틱 확장
캐시에서 가져온 플랜을 기반으로, 깊이와 너비에 상한이 있는 서브그래프 탐색을 추가 수행합니다. 무한정 확장하면 API 비용이 폭발하니까, 복잡도 보장이 있는 결정론적 확장만 허용합니다.

결과: CRAG 데이터셋에서 기존 최고 성능 대비 정확도 +13.2%, 신뢰성 +17.5%.

💡 한 줄 요약: CacheRAG는 LLM이 매번 새로 짜야 하는 "검색 계획"을 과거 유사 질문에서 빌려오는 DB 플랜 캐시의 AI 버전이다.

4. 세 논문을 한눈에 비교하면

세 논문은 같은 문제(stateless RAG의 비효율)를 공격하지만, 서로 다른 층위에서 접근합니다. 표로 정리해봤습니다.

구분GAM-RAGAutoPrunedRetrieverCacheRAG
기억 대상유용했던 문장추론 서브그래프검색 실행 계획
적용 층위문장/청크 레벨엔티티-관계 레벨쿼리 플랜 레벨
대상 환경일반 Multi-hop QA그래프 기반 RAGKGQA
업데이트 방식칼만 필터 영감 gain rule점진적 그래프 확장 + 병합캐시 저장 + MMR 검색
주요 이득검색 품질 + 비용 감소토큰 절감 + 추론 정확도환각 감소 + 커버리지 향상
핵심 수치비용 61% 감소, 성능 +8.19%토큰 100배 감소, 정확도 +9~11p정확도 +13.2%, 신뢰성 +17.5%
영감 출처신경과학 (Hebbian learning)코드북 + 그래프 알고리즘DBMS 플랜 캐시

흥미로운 점은 세 논문이 서로를 보완하는 계층에 있다는 겁니다.

  • GAM-RAG는 "어떤 문장을 먼저 볼 것인가" 를 학습
  • AutoPrunedRetriever는 "어떤 구조로 추론할 것인가" 를 재사용
  • CacheRAG는 "어떤 검색 계획을 실행할 것인가" 를 캐싱

이론적으로는 세 가지를 모두 결합한 시스템이 가장 강력할 수 있습니다. 검색 계획(CacheRAG), 추론 구조(AutoPrunedRetriever), 유용한 문장(GAM-RAG) — 세 층위에서 모두 경험을 축적하는 거죠.

5. 실제로 어떻게 달라지나: 시나리오로 보기

추상적인 이야기는 충분히 했습니다. 실제 시나리오를 통해 차이를 체감해봅시다.

시나리오: AI 스타트업의 내부 지식베이스 챗봇

여러분이 AI 스타트업의 ML 엔지니어입니다. 사내 문서(기술 스펙, 회의록, 연구 노트 등)를 대상으로 RAG 챗봇을 운영하고 있습니다. 매일 팀원들이 비슷한 질문을 많이 던집니다.

[월요일 오전 - 기존 Stateless RAG]

팀원 A: "우리 모델의 추론 API 레이턴시 SLA가 뭐야?"
  → 벡터 검색: 500ms
  → 문서 3개 가져오기: 200ms
  → LLM 추론: 1,200ms
  → 총 1,900ms
  (사용된 문서: tech_spec_v3.pdf, sla_doc.pdf, api_guide.pdf)

팀원 B: "추론 API 응답 시간 기준이 어떻게 돼?"
  → 벡터 검색: 510ms  ← 거의 동일한 작업
  → 문서 3개 가져오기: 195ms  ← 거의 동일한 문서
  → LLM 추론: 1,180ms  ← 거의 동일한 추론
  → 총 1,885ms
  
팀원 C: "API SLA 문서 좀 요약해줘"
  → 벡터 검색: 490ms  ← 또 같은 작업
  → ...

하루에 이런 패턴이 수백 번 반복됩니다. 비용, 레이턴시, 서버 부하 — 모두 불필요하게 낭비됩니다.

[같은 상황 - Stateful RAG 적용 후]

팀원 A: "우리 모델의 추론 API 레이턴시 SLA가 뭐야?"
  → 캐시 미스 (최초 질문)
  → 전체 파이프라인 실행: 1,900ms
  → [검색 경험 저장: 이 추론 타입에 sla_doc.pdf가 핵심 문서]
  → [추론 서브그래프 저장: Model → SLA → Latency_Threshold]

팀원 B: "추론 API 응답 시간 기준이 어떻게 돼?"
  → 시맨틱 캐시 히트! (의미적으로 동일 질문)
  → 캐시된 답변 + 최신성 검증: 150ms  ← 10배 이상 빠름
  
팀원 C: "API SLA 문서 좀 요약해줘"
  → 캐시 히트 (유사 패턴)
  → sla_doc.pdf 직접 접근 + 요약 생성: 800ms  ← 절반 이하
  
팀원 D: "SLA 기준이 최근에 바뀐 게 있어?"  ← 새로운 질문
  → 부분 캐시 히트 (SLA 관련 그래프 재사용)
  → 새로운 부분만 추가 검색 + 기존 그래프 확장: 1,100ms

누적 효과가 시간이 갈수록 커집니다. 초반에는 캐시 구축 비용이 있지만, 쿼리가 쌓일수록 평균 처리 시간과 비용이 지속적으로 감소합니다.

[멀티홉 추론 시나리오: AutoPrunedRetriever의 진가]

질문 1: "우리 회사가 작년에 인수한 스타트업의 CTO는 누구야?"
  → 추론 체인: 우리 회사 → 인수 → 스타트업 A → CTO → 김XX
  → 서브그래프 저장: [Company --acquired--> StartupA --hasCTO--> 김XX]

질문 2: "그 스타트업 CTO가 이전에 어떤 프로젝트를 했어?"
  → 저장된 서브그래프에서 김XX 바로 참조 (재검색 불필요)
  → 새로 추가: [김XX --worked_on--> Project B, C]
  → 토큰 절감: 이미 알고 있는 "우리 회사 → 스타트업 A → CTO" 체인을 
    다시 검색하고 프롬프트에 넣지 않음

질문 3: "그 사람이 진행한 프로젝트들이 우리 현재 기술 스택과 겹쳐?"
  → 저장된 서브그래프: [김XX --worked_on--> Project B, C] 재사용
  → 새로 추가: 우리 기술 스택 정보만 검색
  → 비교 추론 실행

멀티홉 질문에서 이미 탐색한 연결 고리를 반복 탐색하지 않아도 됩니다. 대화가 길어질수록, 에이전트 체인이 깊어질수록 절감 효과가 커집니다.

6. 실제 시스템에서 기대할 수 있는 이득

세 논문의 실험 결과를 종합해서, 실제 시스템 운영 관점에서 기대할 수 있는 이득을 정리해## 6. 실제 시스템에서 기대할 수 있는 이득

세 논문의 실험 결과를 종합해서, 실제 시스템 운영 관점에서 기대할 수 있는 이득을 정리해봅시다.

레이턴시 (Latency)

가장 직관적인 이득입니다. 캐시 히트가 발생하면 전체 파이프라인을 실행하지 않아도 됩니다.

  • 시맨틱 캐시 히트: 거의 즉각 응답 (수백ms 이내)
  • 부분 재사용 (서브그래프 확장): 전체 파이프라인 대비 40~60% 시간 절감
  • 메모리 기반 우선순위 검색 (GAM-RAG): 불필요한 노드 탐색 제거로 추론 비용 61% 감소

다만 이 수치는 캐시 히트율(cache hit rate) 에 크게 달라집니다. 쿼리 패턴이 반복적일수록(예: 사내 FAQ 챗봇, 고객 지원 봇) 효과가 극대화되고, 매번 완전히 새로운 질문이 들어오는 탐색적 환경에서는 이득이 상대적으로 줄어듭니다.

비용 (Cost)

LLM API를 쓰는 입장에서 토큰 절감은 직접적으로 청구서에 반영됩니다.

[기존 Stateless RAG - 반복 쿼리 10회 처리]
쿼리당 평균 토큰: 2,000 (컨텍스트) + 500 (생성) = 2,500 토큰
10회 합계: 25,000 토큰

[AutoPrunedRetriever - 같은 10회 처리]
최초 쿼리: 2,500 토큰 (동일)
이후 9회: 평균 300~500 토큰 (서브그래프 재사용)
10회 합계: ~7,000 토큰

절감률: 약 72%

물론 이건 이상적인 경우입니다. 하지만 AutoPrunedRetriever 논문은 실제 벤치마크에서 "그래프 기반 경쟁 시스템 대비 최대 2 오더 오브 매그니튜드(100배) 토큰 감소"를 보고했습니다. 실제 운영 환경에서도 반복 쿼리가 많은 시스템이라면 상당한 비용 절감이 가능합니다.

품질 (Quality)

이 부분이 가장 흥미롭습니다. 단순히 빠르고 저렴해지는 게 아니라, 경험이 쌓일수록 더 나은 답변을 낸다는 점입니다.

  • GAM-RAG: 5턴 메모리 축적 후 성능 +8.19%. 같은 추론 타입의 질문에 더 적합한 문장이 먼저 활성화됩니다.
  • CacheRAG: 정확도 +13.2%, 신뢰성 +17.5%. 캐시된 플랜이 스키마 환각을 막고 검색 커버리지를 높입니다.
  • AutoPrunedRetriever: 복잡 추론 정확도 +9~11p. 이전에 검증된 추론 경로를 재활용하니 오류 가능성이 줄어듭니다.

이 세 가지를 정리하면:

성능 지표Stateless RAGStateful RAG (세 논문 종합)
반복 쿼리 레이턴시매번 최대값캐시 히트 시 10배 이상 감소
토큰 사용량쿼리당 고정누적 사용량 최대 70~99% 절감
추론 정확도기준선+8~13% (도메인에 따라 다름)
스키마 환각높음캐시 기반 검증으로 대폭 감소
시스템 개선 곡선수평 (학습 없음)우상향 (경험 축적에 따라 향상)

7. 아직 남은 과제들: 솔직하게 짚어보기

물론 장밋빛 전망만 있는 건 아닙니다. "기억을 도입한다"는 아이디어는 매력적이지만, 실제 시스템에 적용하려면 풀어야 할 문제들이 꽤 있습니다. 연구자들도 솔직하게 인정하는 부분들입니다.

① 캐시 무효화(Cache Invalidation): 영원한 난제

소프트웨어 엔지니어링에서 가장 어려운 두 가지 문제를 아시나요? 캐시 무효화와 이름 짓기입니다. RAG의 semantic cache도 마찬가지입니다.

지식이 업데이트되면 어떻게 될까요?

캐시된 플랜: "GPT-4o 컨텍스트 윈도우 = 128K 토큰"
                ↓
실제 업데이트: OpenAI가 컨텍스트 윈도우를 200K로 확장
                ↓
캐시가 오래된 플랜을 그대로 반환 → 오답!

CacheRAG는 bounded subgraph expansion으로 이 문제를 부분적으로 완화하지만, 완전한 해결책은 아닙니다. GAM-RAG의 칼만 게인 룰도 노이즈에는 강하지만, 지식 자체가 바뀌는 상황에서 언제 메모리를 폐기하고 처음부터 다시 시작할지 판단하는 건 여전히 어렵습니다.

실제 프로덕션 시스템이라면 반드시 고민해야 할 부분입니다.

  • 캐시 TTL(Time-To-Live)을 어떻게 설정할 것인가?
  • 지식 소스가 업데이트될 때 어느 캐시 항목을 자동으로 무효화할 것인가?
  • 잘못된 캐시가 반환되었을 때 이를 감지하고 수정하는 피드백 루프는 어떻게 구성할 것인가?

② 메모리 증가와 검색 오버헤드

경험을 쌓으면 쌓을수록 메모리가 커집니다. AutoPrunedRetriever는 이 문제를 ANN 기반 중복 제거와 k-means 병합으로 해결하려 하지만, 메모리가 충분히 커지면 메모리 자체를 검색하는 오버헤드가 무시할 수 없어집니다.

작은 메모리 (쿼리 100건):
  캐시 검색: 5ms → 이득이 명확

큰 메모리 (쿼리 100만 건):
  캐시 검색: 50~200ms → 이득이 희석될 수 있음

이를 해결하려면 계층적 인덱스, 효율적인 근사 검색, 정기적인 메모리 압축 등이 필요한데, 이건 그 자체로 또 하나의 시스템 엔지니어링 문제가 됩니다.

③ 노이즈 피드백과 메모리 오염

GAM-RAG가 칼만 게인 룰로 이 문제를 완화하긴 하지만, 근본적인 질문이 남습니다. "검색이 성공했다"는 걸 어떻게 판단하는가?

LLM이 답변을 생성했다고 해서 그 답변이 맞는 건 아닙니다. 잘못된 문서를 가져왔는데 LLM이 그럴듯한 답변을 만들어냈다면? 그 검색 경험이 "성공"으로 기록되어 메모리에 들어가면? 시스템은 점점 잘못된 방향으로 최적화될 수 있습니다.

이는 강화학습의 보상 해킹(reward hacking) 문제와 유사합니다. 진짜 품질 신호를 어떻게 얻느냐가 핵심입니다. 사용자 피드백? 자동 평가 모델? 아직 완전한 답은 없습니다.

④ 멀티 테넌트 환경에서의 메모리 격리

사내 챗봇이라면 A팀과 B팀이 서로 다른 문서에 접근 권한이 있을 수 있습니다. 캐시/메모리를 공유하면 A팀이 접근하면 안 되는 정보가 B팀의 캐시 히트를 통해 간접적으로 노출될 위험이 있습니다.

시나리오:
  B팀: "3분기 임원 연봉 정보가 어디 있어?" (기밀 문서 접근 권한 있음)
  → 검색 성공, 메모리에 관련 패턴 저장
  
  A팀: "임원 보상 체계에 대해 알려줘" (해당 문서 접근 권한 없음)
  → 캐시 히트! → 기밀 정보 간접 노출?

이 문제는 세 논문 모두 깊게 다루지 않습니다. 실제 프로덕션에서는 메모리를 사용자/그룹별로 격리하거나, 캐시 히트 시에도 권한 검증을 추가로 수행하는 등의 설계가 필요합니다.

⑤ Cold Start 문제

stateful 시스템의 아이러니는, 처음에는 오히려 stateless보다 느릴 수 있다는 점입니다. 메모리가 비어 있는 상태에서는 캐시 미스가 연속으로 발생하고, 메모리 인덱스 업데이트 오버헤드까지 더해집니다.

실제 배포 시에는 초기 워밍업 전략이 필요합니다. 자주 오는 쿼리 유형을 미리 파악해서 메모리를 사전 구축하거나, cold start 기간에는 stateless 모드로 운영하다가 일정 쿼리 수가 쌓이면 stateful 모드로 전환하는 등의 접근이 현실적입니다.

8. 앞으로의 방향: RAG는 어디로 가는가

이 세 편의 논문이 보여주는 방향성을 종합하면, RAG 시스템의 진화 경로가 꽤 명확하게 그려집니다.

단기: 레이어별 캐싱의 표준화

현재는 각 논문이 각자의 방식으로 메모리를 구현하고 있습니다. 앞으로는 이 아이디어들이 통합되어 RAG 프레임워크의 표준 컴포넌트로 자리 잡을 가능성이 높습니다.

[미래의 RAG 스택]

┌─────────────────────────────────┐
│     사용자 인터페이스 레이어      │
├─────────────────────────────────┤
│   쿼리 플랜 캐시 (CacheRAG식)    │  ← 검색 계획 재활용
├─────────────────────────────────┤
│  추론 그래프 저장소 (APR식)       │  ← 추론 구조 재사용
├─────────────────────────────────┤
│  문장 경험 메모리 (GAM-RAG식)    │  ← 유용 문장 우선화
├─────────────────────────────────┤
│     기존 벡터 인덱스 레이어       │  ← 기존 RAG 기반
└─────────────────────────────────┘

LangChain, LlamaIndex 같은 RAG 프레임워크들이 이런 stateful 컴포넌트를 플러그인 형태로 지원하기 시작하면, 개별 팀이 직접 구현하지 않아도 되는 시대가 올 겁니다.

중기: 적응형 RAG와 개인화

메모리가 쌓이면 단순 효율화를 넘어서 사용자별 검색 패턴 학습이 가능해집니다.

"이 사용자는 기술적 세부사항을 선호하는군. 같은 질문이 와도 더 깊은 문서를 우선 가져오자."

"이 팀은 항상 비용 관련 질문을 마케팅 전략 질문 다음에 하네. 연관 문서를 미리 준비해두자."

이건 단순한 캐싱을 넘어서 예측적 검색(predictive retrieval) 의 영역입니다. Netflix가 여러분의 시청 패턴을 학습해서 다음에 볼 것을 미리 준비하듯, RAG 시스템도 사용자의 쿼리 패턴을 학습해서 다음 질문을 예측할 수 있습니다.

장기: Memory-First RAG 아키텍처

장기적으로는 아키텍처의 패러다임 자체가 바뀔 수 있습니다. 지금은 "검색이 중심이고 메모리가 보조"인 구조인데, 뒤집어서 "메모리가 중심이고 검색은 메모리를 채우는 수단" 이 되는 거죠.

현재 패러다임:
  질문 → [검색] → [메모리 확인] → 답변

미래 패러다임:
  질문 → [메모리 확인] → (히트) → 즉시 답변
                       → (미스) → [검색] → [메모리 업데이트] → 답변

이는 인간의 지식 처리 방식과도 유사합니다. 우리도 익숙한 질문에는 기억에서 바로 꺼내고, 처음 보는 질문에만 "조사"를 합니다. RAG가 진정으로 인간적인 지식 처리를 닮아가는 방향입니다.

마무리: RAG는 더 이상 일회성 검색이 아니다

긴 여정이었습니다. 정리해봅시다.

전통적인 RAG는 완벽한 기억상실증 환자처럼 매 질문마다 처음부터 시작합니다. 이건 단순히 성능 문제가 아니라 설계 철학의 문제입니다. "검색은 일회성 이벤트"라는 가정 위에 세워진 시스템이기 때문입니다.

하지만 세 편의 논문이 보여주는 것처럼, 그 가정은 이미 깨지고 있습니다.

  • GAM-RAG는 문장 수준에서 검색 경험을 축적합니다.
  • AutoPrunedRetriever는 추론 구조를 저장하고 재활용합니다.
  • CacheRAG는 검색 계획 자체를 캐싱합니다.

세 논문이 각각 다른 층위에서, 각각 다른 방식으로 같은 결론에 도달했습니다.

"RAG는 stateless QA가 아니라, 점점 stateful retrieval system이 되고 있다."

이건 단순한 최적화 트릭이 아닙니다. RAG가 "질문에 대답하는 도구"에서 "경험을 축적하는 지식 시스템"으로 진화하고 있다는 신호입니다.

여러분이 지금 RAG 시스템을 구축하거나 운영하고 있다면, 한 가지 질문을 스스로에게 던져보시기 바랍니다.

"우리 시스템은 어제보다 오늘, 오늘보다 내일, 더 똑똑해지고 있는가?"

만약 답이 "아니오"라면 — 지금이 stateful retrieval을 진지하게 고민할 때입니다. DB 개발자들이 수십 년 전에 깨달은 것을 RAG 세계도 이제 받아들이기 시작했습니다. 좋은 시스템은 경험에서 배웁니다. 그리고 RAG도 마찬가지여야 합니다.

참고 논문

  • GAM-RAG: GAM-RAG: Gain-Adaptive Memory for Evolving Retrieval in Retrieval-Augmented Generation (arXiv: 2603.01783)
  • AutoPrunedRetriever: Pruning Minimal Reasoning Graphs for Efficient Retrieval-Augmented Generation (arXiv: 2602.04926)
  • CacheRAG: CacheRAG: A Semantic Caching System for Retrieval-Augmented Generation in Knowledge Graph Question Answering (arXiv: 2604.26176)

이 글이 도움이 되셨다면, 비슷한 주제로 계속 이야기 나눠요. RAG 시스템 설계에 대한 고민이 있으시면 댓글로 남겨주세요.

profile
서민성
기록하는 습관을 기르고 싶습니다
이전 포스트

RAG 평가, 정답률만 보면 망한다

다음 포스트

CUA-Gym: Scaling Verifiable Training Environments and Tasks for Computer-Use Agents

0개의 댓글