← 글 목록

notes

RAG vs CAG

8 min read

RAG와 CAG의 검색·컨텍스트 구성 방식과 적용 상황 차이 비교.

Kim mr.

프론트엔드 · 기술 블로그

날짜: 2026-09-15 · AI 탭 학습 노트

🧠 RAG vs CAG — 긴 컨텍스트 시대에 지식을 어떻게 먹일까

LLM이 답을 잘하게 하려면, 모델 안에 들어 있는 ‘기억’만으로는 부족한 경우가 많다. 사내 문서, 어제 올린 노션, 우리 레포 코드… 이런 건 학습 때 없던 정보다. 그래서 답을 만들기 직전에 외부 지식을 맥락(context)에 실어 주는 방법을 쓴다.

그 방법이 하나가 아니다. 대표 축이 두 개다.

  • 🔍 RAG — Retrieval-Augmented Generation (검색해서 붙이기)
  • 🗄️ CAG — Cache-Augmented Generation (미리 올려두고 캐시로 쓰기)

이름만 비슷해 보이는데, 지식을 언제·어떻게·얼마나 창에 넣는가가 근본적으로 다르다. 이 글은 “뭐가 무조건 낫다”가 아니라, 내가 이해한 차이와 팀을 붙잡는 고민을 정리한 학습 노트다.

0. 🌱 공통 전제 — 모델은 매 호출마다 상태를 안 가진다

LLM API 한 번은 대체로 stateless다. 그 호출에 넣어 준 토큰(시스템 지시 + 대화 + 문서 조각)만 보고 답을 만든다.

그래서 “대화가 길어지면 멍청해진다”, “문서가 많아지면 헷갈린다”는 체감은 종종 모델이 나빠진 것이 아니라 우리가 컨텍스트를 어떻게 조립했는지 문제다.

RAG와 CAG는 이 조립 전략의 두 가지 철학이다.

1. 🤔 사람들이 실제로 고민하는 지점

정의를 외우기 전에, 팀이 붙잡는 질문은 보통 아래다.

1️⃣ 지식의 크기와 수명

  • 문서가 GB급으로 계속 늘어나는가, 아니면 매뉴얼 한 묶음처럼 유한한가?
  • 하루에도 여러 번 갱신되는가, 분기 단위로 바뀌는가?

👉 크면 RAG, 작고 고정이면 CAG가 후보.

2️⃣ 질문이 ‘국소적’인가 ‘전역적’인가

  • 🪡 “이 함수가 어디서 호출돼?” → 바늘 찾기 → 검색(RAG)이 잘 맞음
  • 🗺️ “이 설계 문서 전체를 전제로 아키텍처를 논해” → 넓은 배경 → 조각만 가져오는 RAG가 맥락을 끊을 수 있음 → CAG(통째로)가 매력적

3️⃣ ⏱ 지연시간 · 💰 비용

  • RAG: 매 질문마다 검색 + 재조립 + 생성. 검색·리랭크 비용이 붙음
  • CAG: 처음 긴 컨텍스트 프리필(prefill) 비용이 크지만, 이후는 KV 캐시 재사용으로 체감이 빨라질 수 있음. 다만 캐시를 깨는 변경(지식 교체, 세션 종료)이 잦으면 이점이 사라짐

4️⃣ 정확도 vs 최신성

  • RAG: 인덱스를 갱신하면 비교적 쉽게 최신 반영
  • CAG: 창/캐시에 넣은 스냅샷이라 오래된 복사본이 되기 쉬움 → “언제 무효화할까”가 운영 고민

5️⃣ 💥 실패 모드가 다르다

“다 넣었으니 안전하다”가 항상 성립하지 않는다.

6️⃣ 대화 · 에이전트와의 결합

코딩 에이전트·챗봇은 문서만이 아니라 대화 히스토리, 툴 결과, plan, 메모리까지 창을 다툰다. 고민은 “지식만 RAG/CAG”가 아니라 세션 전체를 어떻게 윈도우에 재구성할 것인가로 확장된다. (요약, compaction, memory extraction 등)

이 고민이 정리되지 않은 채 “우린 RAG다/CAG다”만 정하면, 나중에 증상(환각, 느림, 비쌈, 답 흔들림)만 남는다.

2. 🔍 RAG란 무엇인가

한 줄로

생성 직전에 외부 저장소에서 관련 조각을 검색(retrieve)해, 프롬프트에 증강(augment)한 뒤 생성(generate)한다.

사용자 질문
    → (선택) 질의 재작성 / 하이브리드 검색
    → 벡터DB·키워드·그래프에서 Top-K 청크 검색
    → (선택) 리랭킹으로 순서·개수 정제
    → [시스템 지시 + 검색 결과 + 질문 (+ 짧은 대화)] 조립
    → LLM 생성

핵심은 매 요청(또는 매 턴)마다 “지금 필요한 것만” 고른다는 점이다. 지식 본체는 모델 밖(인덱스)에 두고, 컨텍스트 창은 빌리는 자리로 쓴다.

풀려던 문제

  • 학습 이후·비공개 정보를 쓰게 하기
  • 무한에 가까운 코퍼스를 유한 창에 억지로 넣지 않기
  • 근거 문서를 가져와 환각을 줄이고 출처를 남기기 (완벽하진 않음)

구성 요소 (개념만)

실무 감각 — 장단점

👍 장점

  • 코퍼스 스케일에 강함
  • 인덱스만 갈아끼우면 지식 갱신이 상대적으로 쉬움
  • 잘 검색되면 불필요한 문서를 안 넣음

👎 단점

  • 파이프라인이 김 (검색 품질 = 답 품질의 상한)
  • “관련 있어 보이는 잘못된 문서” 문제
  • 전역 이해가 필요한 질문에 취약할 수 있음
  • 매 턴 검색 비용·지연
  • 대화가 길어지면 검색 결과 + 히스토리가 겹쳐 창이 더러워질 수 있음

내가 정리한 감각: RAG는 “똑똑한 모델” 이야기라기보다 정보 검색 시스템을 LLM 앞에 붙인 것에 가깝다.

3. 🗄️ CAG란 무엇인가

한 줄로

(상대적으로) 필요한 지식 묶음을 미리 긴 컨텍스트에 올려 두고, KV 캐시 등을 활용해 이후 질의에서 반복 검색 없이 재사용한다.

이름에 Cache가 들어가는 이유: 단순한 “긴 프롬프트에 문서 붙여넣기”를 넘어 한 번 프리필한 표현(캐시)을 여러 생성에 재사용하는 쪽에 초점이 있다. (벤더·구현마다 디테일은 다르지만, 개념의 중심은 여기다.)

[세션/작업 시작]
지식 묶음(매뉴얼, 스펙, 관련 파일 세트)을 컨텍스트에 로드
    → 프리필 + (가능하면) KV 캐시 워밍

[이후 질문들]
추가 검색 최소화
    → 캐시된 지식 + 새 질문만으로 생성

핵심 질문: “찾을까?”보다 “이미 앉아 있게 할까?”

긴 컨텍스트 창이 커지고, 프리필/캐시 인프라가 현실화되면서 “가끔은 검색보다 통째로가 낫다”는 선택지가 생긴 것이다.

가능해진 배경

  • 🪟 컨텍스트 창의 실질적 확장 (수십만~백만 토큰 얘기가 나오는 시대)
  • 🪡 긴 문맥에서 단서 찾기(Needle) 성능 개선 (완벽하진 않음)
  • ♻️ 동일 prefix에 대한 캐시 재사용이 비용·속도에서 의미 있어짐

즉 CAG는 “RAG를 이긴 대체재”라기보다 긴 컨텍스트 + 캐시라는 새 런타임 조건이 만든 옵션이다.

실무 감각 — 장단점

👍 장점

  • 지식 크기가 창 안일 때, 검색 누락 실패를 줄일 수 있음
  • 같은 지식 위 연속 Q&A에서 latency/비용 구조가 유리할 수 있음
  • “문서 전체를 전제로 한 추론”에 유리한 편

👎 단점

  • 지식 상한이 컨텍스트/메모리에 묶임
  • 최초 프리필 비용·시간이 큼
  • 지식 갱신 시 캐시 무효화·재적재
  • 다 넣어도 Lost in the Middle / context rot으로 주의가 흐려질 수 있음
  • 권한·보안: “이 세션 캐시에 무엇을 올려도 되는가”

내가 정리한 감각: CAG는 “검색을 없앤 마법”이 아니라 검색을 앞단으로 옮기거나(사전 선정), 검색 대신 통째 로드를 선택한 전략이다.

4. 📊 한눈에 비교

5. ✅ “어느 쪽이 맞나”보다 “어떤 가설을 검증하나”

팀에 남기기 좋은 의사결정 체크.

  • 코퍼스가 컨텍스트에 들어가는가?
  • ❌ No → RAG (또는 계층적 요약 + RAG)
  • ✅ Yes → CAG 실험 가치 있음
  • 질문이 같은 지식 위를 여러 번 도는가?
  • ✅ Yes → CAG / 세션 캐시 이득
  • ❌ No (매번 다른 영역) → RAG
  • 갱신 빈도는?
  • 🔥 높음 → RAG 또는 “짧은 TTL의 CAG”
  • 🧊 낮음 → CAG 후보
  • 전역 맥락이 필요한가?
  • ✅ Yes → 순수 Top-K RAG만으로 부족한 구간 → 요약 문서 + RAG, 또는 CAG
  • ❌ No → RAG로 충분한 경우 많음
  • 관측 지표는?
  • 정답률·근거 인용률뿐 아니라 p95 latency, 토큰 비용, 캐시 히트율, 재프리필 횟수

6. 🌈 현실 — 둘은 적대가 아니라 스펙트럼

실무에서는 순수 RAG / 순수 CAG보다 아래가 흔하다.

  • 🔍로 후보를 줄인 뒤, 그 묶음을 세션 동안 🗄️처럼 고정해 반복 질문
  • 사전 큐레이션된 워킹셋(이 티켓에 필요한 파일 20개)을 CAG로 올리고, 부족하면 RAG로 보강
  • 대화가 길어지면 히스토리는 요약(compaction) 하고, 지식은 RAG/CAG로 다시 채움

브랜드 이름보다 본질은 한 문장이다.

지금 이 답변을 위해 모델 창에 ‘무엇을’, ‘얼마나’, ‘얼마나 오래’ 앉혀 둘 것인가?

7. 🔗 “프롬프트 쌓이면 멍청해짐”과 연결하면

초기 챗이 대화를 한 덩어리에 계속 append하던 방식은, 지식 측면에서도 비슷했다. “일단 다 붙여 보자”는 조잡한 CAG에 가깝고, 창이 작고 긴 문맥이 약하던 시절엔 독이었다.

  • 🔍 RAG는 그 반동으로 필요한 것만 붙이자
  • 창이 커진 지금은 잘 고른 묶음을 캐시해 두자(🗄️ CAG) 가 다시 합리적으로 보이는 구간이 생김

다만 CAG가 돌아왔다고 해서 “다시 다 쌓아도 된다”는 뜻은 아니다. 선택적으로, 세션 단위로, 무효화 가능하게 쌓는가가 차이다.

8. ✏️ 마치며 — 내 한 문장 정리

  • 🔍 RAG: 지식은 밖에 두고, 질문할 때마다 빌려 쓴다.
  • 🗄️ CAG: 지식은 창/캐시에 두고, 한동안 앉아 있게 한다.

고민은 “유행하는 약어를 쓰느냐”가 아니라 지식의 크기·갱신·질문 형태·비용·실패 모드를 팀에 맞게 맞추는 일이다.

창이 커질수록 CAG의 영토는 넓어지지만, 세상의 문서는 보통 그보다 더 빨리 는다. 당분간 솔직한 기본 태도:

RAG를 기본값으로 두고, CAG는 선택적 가속.

📎 참고 키워드

Retrieval-Augmented Generation · Cache-Augmented Generation · KV cache · prefill · Lost in the Middle · context rot · chunking · hybrid search · context window · working set