Chapter 08

무엇을 언제 쓸까

네 가지를 모두 배웠다. 실제로는 “어느 것이 최고인가”보다 “내 자료와 내 질문에는 무엇이 맞나”가 중요하고, 하나만 고르기보다 섞어 쓰는 경우가 많다.

자료가 작고 고정 → CAG. 자료가 크거나 자주 바뀜 → RAG. 여러 사실을 이어야 하고 정확한 관계가 중요 → KAG. 답이 글이 아니라 프로그램이 쓸 결정이어야 함 → Jev를 앞의 것들 위에 얹는다.

네 방식 비교표

기준RAGCAGKAGJev
한 줄 비유사서가 관련 쪽을 찾아 줌얇은 노트를 미리 외움탐정의 관계도OMR 카드
미리 하는 일조각내기·임베딩·저장자료 전체 prefill → KV 캐시트리플 추출·그래프 구축·정렬(없음) 선택지 설계
질문마다 하는 일검색 + 프롬프트 조립 + 생성캐시 불러오기 + 생성계획 + 그래프 탐색 + 생성선택지별 확률 계산
자료 크기거의 무제한컨텍스트 창 이하크게 가능 (구축 비용 비례)요청당 입력 제한 안
자료 갱신쉬움 (바뀐 조각만)캐시 재생성 필요그래프 갱신 필요해당 없음
다단계 질문약함가능 (다 보고 있음)강함질문 하나 = 결정 하나
응답 속도보통 (검색 포함)빠름느린 편 (여러 단계)매우 빠름 (회사 발표)
설명 가능성출처 조각약함 (전체를 봄)추론 경로 + 출처확률 (근거는 따로)
구축 난이도보통쉬움어려움쉬움 (API 호출)
출력글글글확률·선택

상황별 추천 마법사

내 상황을 고르면 점수와 이유가 바로 바뀐다. 점수는 이 교재의 경험 규칙을 숫자로 옮긴 것으로, 정답이라기보다 생각의 출발점이다.

SIMULATOR

내 프로젝트에는 무엇이 맞을까

① 자료의 양은?

② 자료가 얼마나 자주 바뀌나?

③ 주로 어떤 질문인가?

④ 결과를 누가 쓰나?

⑤ 가장 중요한 것은?

섞어 쓰기: 한 서비스 안의 네 방식

실제 사내 도우미를 만든다면 이렇게 될 수 있다. 질문이 들어오면 Jev가 종류를 가르고, 종류에 맞는 길로 보낸 뒤, 마지막에 다시 Jev가 답을 검사한다. 질문 칩을 바꿔 가며 길이 어떻게 달라지는지 보자.

기억할 경험 규칙

먼저 CAG를 의심하라

자료가 창에 들어가고 잘 안 바뀐다면, 검색 시스템을 만들기 전에 통째로 넣어 보자. 상용 API의 프롬프트 캐싱으로 비용도 줄일 수 있다.

크고 변하면 RAG

대부분의 실무 출발점. 4장의 손잡이(조각·k·하이브리드·재순위화)를 차근차근 맞춘다.

관계가 핵심이면 KAG

“누가 누구의 무엇”을 여러 번 따라가야 하고 틀리면 곤란한 분야라면, 그래프를 만드는 비용을 감수할 가치가 있다.

결정은 Jev 방식으로

분기·분류·점수가 필요하면 긴 글 대신 확률을 받고, 보정과 임계값으로 사람과 일을 나눈다.

핵심 정리

  1. RAG·CAG·KAG는 ‘무엇을 어떻게 읽힐까’, Jev는 ‘결과를 어떤 모양으로 받을까’의 선택이다.
  2. 자료 크기와 갱신 빈도가 RAG vs CAG를, 질문의 연결 깊이가 KAG 여부를 가른다.
  3. 실무에서는 조합이 흔하다: 핵심 자료 캐시 + 검색, 그래프 + 검색, Jev 라우팅·검사.

확인 퀴즈