「RAG」라는 단어, 조금 전까지만 해도 여기저기서 들렸는데, 최근 들어 부쩍 눈에 띄지 않는다고 느끼고 계시지는 않나요?

사실 이것은, RAG가 쇠퇴한 것이 아니라 「당연한 것」이 되어 버려서 화제가 되지 않게 된 것뿐입니다.

사내 챗봇, 검색 UI, 문서 Q&A, AI 코딩 지원, 서포트 bot…. 2026년 현재, 제대로 된 AI 프로덕트의 대부분에는 어떤 형태로든 RAG가組み込まれています(組み込まれています). 화제가 되지 않게 된 것은 「이미 전제」가 되었기 때문이지, 사라졌기 때문이 아닙니다.

그렇게 되면 반대로 곤란해지는 것이, **「RAG라는 말은 어렴풋이 들어봤지만, 내용은 제대로 모르겠다」**는 상태의 사람들입니다. 유행하는 토픽이라면 누군가가 입문 기사를 써주겠지만, 「당연한 것」이 된 것은 다시는 아무도 해설해 주지 않게 됩니다.

• 「RAG라는 단어는 알지만, index라거나 chunk라고 하면 모르겠다」
• 「ChatGPT를 사용하고 있지만, 그 이면에서 무엇이 움직이고 있는지 설명할 수 없다」
• 「최신 AI 설계를 배우려고 하면, RAG가 전제 지식으로 요구되어 곤란하다」

이 기사는 바로 그런 분들을 위해 작성했습니다.

LLM은 Large Language Model(대규모 언어 모델)의 약자입니다. ChatGPT나 Claude, Gemini의 내부에 들어있는 것이 이것입니다.

LLM이 하고 있는 일을 거칠게 말하자면, **「다음에 올 법한 단어를 계속 맞히는 게임을, 엄청나게 방대한 문장으로 연습한 녀석」**입니다. 인터넷상의 문장을 대량으로 읽히고, 뒤를 이어 쓰는 연습을 끊임없이 시키면, 문법적으로 올바를 뿐만 아니라 지식까지 가지고 있는 것처럼 보이는 응답이 돌아옵니다.

다만, LLM은 연습에 사용한 문장 속에 있었던 정보밖에 모릅니다. 구체적으로는 다음 네 가지 측면에서 문제가 발생합니다.

그럴듯하게 거짓말을 함 (hallucination, 하ルシネーション): 모르는 것을 「그럴싸하게」 생성해 버립니다. 완전히 존재하지 않는 논문을 인용하거나, 있을 법하지만 없는 인명을 내뱉기도 합니다.

새로운 정보를 모름 (knowledge cutoff): 「학습을 마친 날」 이후의 뉴스나 개정된 법률은 모릅니다.

당신의 회사 내부 문서를 모름: 사내 매뉴얼도, 자기 회사의 레시피 모음집도 당연히 학습 데이터에 들어있지 않습니다.

「왜 그렇게 답했는지」의 근거를 제시할 수 없음: 「당신 회사의 매뉴얼 p.42에 적혀 있다」와 같은 출처를 포함하여 답하는 기능은 가지고 있지 않습니다.

RAG는 이 네 가지를 「동일한 메커니즘으로」 해결하기 위한 도구 세트입니다. 이것만 기억하고 있다면, 아래 내용을 읽을 준비는 된 것입니다.

RAG는 Retrieval-Augmented Generation의 약자로, 일본어로 번역하면 「검색을 조합한 생성」입니다.

이미지로 비유하자면 다음과 같습니다.

당신이 요리책 편집자이고, 신입 라이터가 「함버그(Hamburg) 만드는 법」 원고를 쓰고 있다고 가정해 봅시다.

신입 라이터는 요리 지식은 있지만, 「우리 회사에서 출간하는 요리책 시리즈」가 어떤 레시피를 권장하고 있는지는 모릅니다.

그래서 원고를 쓰기 전에, 편집자가 「우리 회사 시리즈 중에서 관련이 있을 법한 페이지를 3개 뽑아서 라이터에게 전달하기」로 합니다.

라이터는 전달받은 3페이지를 곁눈질로 보면서, 그 내용에 따라 원고를 작성합니다.

LLM이 라이터, 「검색하는 메커니즘」이 편집자

즉 RAG의 본질은, 「AI의 머릿속 지식」과 「외부에 둔 수정 가능한 문서 집합」을 결합하는 메커니즘, 그뿐입니다.

RAG의 구조는 **「준비하는 페이즈 (Phase)」**와 「사용하는 페이즈 (Phase)」 두 가지로 나뉩니다.

문서를 처음에 딱 한 번, AI가 검색할 수 있는 형태로 정리하여 저장해 두는 작업입니다.

Load (읽기) → Split (분할) → Embed (수치화) → Store (저장)

이것이 순서입니다.

여기서 말하는 「딱 한 번」이라는 것은, 사용자로부터 질문이 올 때마다 매번 실행할 필요는 없다는 의미입니다.

나중에 나올 「사용하는 페이즈」는 질문이 올 때마다 매번 실행되는 처리입니다.

| 언제 실행되나? |
|---|---|
| 준비 페이즈 (Indexing) | 최초 구축 시 1회. 그 후에는 문서가 늘어나거나 업데이트되었을 때만 추가로 실행 |
| 사용하는 페이즈 (Retrieval & Generation) | 질문이 올 때마다 매번 |

이미지로 비유하자면, 도서관에 새로운 책이 입고되었을 때 사서가 하는 일이 준비 페이즈와 닮았습니다.

• 책을 받아서 정리 번호를 붙이고, 어느 선반에 둘지 결정하여 검색 데이터베이스에 등록한다.
• 이것은 책이 입고되었을 때만 하면 되는 일이지, 이용자가 책을 빌리러 올 때마다 매번 다시 하는 작업은 아니니까요.

반면, 「사용하는 페이즈」는 이용자가 왔을 때의 도서관 사원의 응대에 가깝습니다.

• 이용자의 「○○에 대해 쓰인 책이 있나요?」라는 질문을 듣고, 검색 데이터베이스에서 해당할 법한 책을 찾아 선반에서 꺼내 전달한다.
• 이것은 이용자가 올 때마다 매번 하는 작업입니다.

RAG의 Indexing도 마찬가지로, 문서를 받아들여 정리해 두는 일련의 준비 작업을 가리키며, 사용자의 질문과는 독립적으로 실행됩니다.

문서의 업데이트 빈도가 낮을수록 준비 페이즈의 비용 (Embedding 생성 API 요금 등)은 무시할 수 있는 수준이 됩니다. 반대로 뉴스 사이트처럼 매시간 문서가 늘어나는 시스템에서는 「새로 추가된 부분만큼만 Embedding을 만들어 Index에 추가하는」 차분 업데이트 (Incremental Update) 메커니즘이 필요합니다.

사용자로부터 질문이 올 때마다 그때그때 실행되는 처리입니다.

Retrieve (관련 부분 추출) → Generate (그 부분을 보면서 AI가 답변)

이것이 전부입니다.

이제부터 각 단계를 순서대로, 모든 전문 용어를 설명하며 살펴보겠습니다.

PDF, Word, 웹 페이지, 데이터베이스 등 무엇이든 상관없습니다. 어쨌든 「읽어 들여서, 가공되지 않은 텍스트 (문자의 연속)로 변환하는」 공정입니다.

예를 들어 PDF 책이라면, 페이지 단위로 문자를 추출해 옵니다.

이미지로 된 문자 (스캔한 종이책 등)에는 OCR (이미지에서 문자를 읽어내는 기술)이 필요합니다.

여기서 실패하면 나중에 무엇을 해도 되돌릴 수 없습니다. 「표 안의 숫자가 빠졌다」와 같은 일이 발생하면, 그 정보는 두 번 다시 검색 결과에 나오지 않게 됩니다.

여기서 처음으로 **chunk (청크)**라는 용어가 등장합니다.

영어에서 chunk는 「덩어리」, 「한 덩어리」라는 의미입니다. RAG의 문맥에서는 긴 문서를 다루기 쉬운 크기로 분할한, 하나하나의 작은 텍스트 덩어리를 가리킵니다.

책 한 권 (500 페이지)

↓ 분할

500개 정도의 「단락 ~ 몇 단락 정도의 덩어리」 = 「chunk」

피자를 조각내는 이미지입니다. 한 판째로 가지고 있으면 먹기 불편하므로 조각 단위로 자릅니다.

이유는 두 가지가 있습니다.

• AI에게 전달할 수 있는 문장의 길이에 상한이 있음 (나중에 자세히 설명하겠지만, AI에게는 한 번에 읽을 수 있는 글자 수의 한계가 있습니다)
• 나중에 「수치로 바꾸는」 공정에 입력 사이즈의 상한이 있음 (이 또한 후술하겠습니다)

LangChain의 공식 튜토리얼에서는 **「1000자, 200자의 오버랩 (Overlap)」**이 예시로 나옵니다. 「오버랩」이란 인접한 chunk가 일부 겹친다는 의미입니다.

[----- chunk 1 (1000자) -----]
[----- chunk 2 (1000자) -----]
[----- chunk 3 (1000자) -----]
...

왜 겹치게 하느냐 하면, 경계선 부분에서 의미가 끊겨버리는 것을 방지하기 위해서입니다.

「혈액 중의 헤모글로빈은」에서 chunk가 끝나버리면, 이어지는 「산소를 운반하는」 부분이 다음 chunk로 넘어가 버려서, 검색했을 때 한쪽만 히트(hit)되면 의미를 파악할 수 없게 됩니다.

너무 큰 경우: 하나의 chunk에 여러 토픽이 섞입니다. 검색 정확도가 떨어집니다. -
너무 작은 경우: 의미의 덩어리가 깨집니다. 「이것은 ~입니다.」와 같은 짧은 chunk만 가져오면 의미를 알 수 없습니다.

「대략 단락 1~수 단락 분량」을 기준으로 삼고, 도메인(요리책이라면 레시피 1개 단위, 기술서라면 절(section) 단위 등)에 맞춰 조정하는 것이 현실적인 규칙이 됩니다.

이 부분이 RAG에서 가장 추상적인 부분이므로, 차근차근 설명하겠습니다.

Embedding (임베딩) 이란, 문장을 「벡터 (vector)」로 변환하는 것, 또는 그 변환 결과인 벡터 자체를 말합니다.

「함박 스테이크 만드는 법은 소고기 다짐육과 돼지고기 다짐육을 섞어서...」

↓ embedding 모델 (변환하는 AI)을 통과

[0.124, -0.873, 0.456, ..., 0.211] ← 1024개의 숫자 나열 (벡터)

여기서 말하는 벡터 (vector) 는 「숫자를 나열한 것」 이라고 생각해도 무방합니다. 중학교 때 배우는 화살표로서의 벡터와 수학적으로는 같지만, 여기서는 「수치가 나열되어 있다」는 것만 기억하면 충분합니다.

벡터 = [0.12, -0.87, 0.45, ..., 0.21]
↑ 이런 것이 1024개 나열되어 있다는 것뿐

embedding을 만드는 모델은 「의미가 가까운 문장끼리는 벡터로서도 가까워지도록」 훈련되어 있습니다.

이것이 embedding의 핵심입니다. 「가깝다」는 것은 계산을 통해 기계적으로 측정할 수 있는 거리(후술할 코사인 유사도 등)를 의미합니다.

예를 들면 다음과 같습니다.

인간에게 있어의 「의미가 가깝다」를 기계에게 있어의 「숫자 거리」로 변환하는 장치, 이것이 embedding 모델입니다.

실례로 Cohere라는 회사의 embed-multilingual-v3라는 유명한 모델을 살펴보겠습니다. 공식 문서에 따르면,

출력하는 숫자의 개수 (dimensions, 차원 수): 1024개 -
한 번에 넣을 수 있는 텍스트 길이: 최대 512 토큰 (토큰에 대한 설명은 바로 뒤에 이어집니다) -
대응 언어: 100개 이상의 언어 -
거리 측정 방식: cosine (코사인) 유사도 · dot product (내적) · 유클리드 거리

「100개 이상의 언어」라는 점이 강력하여, 일본어로 쓴 문장과 영어로 쓴 문장을 같은 의미라면 가깝게 변환해 줍니다.

여기서 자주 나오는 의문은, 「왜 1024개라는 애매한 숫자인가?」 하는 것입니다. 이는 세 가지 관점에서 답할 수 있습니다.

1. 이것은 「이 모델이 그렇게 설계되었기」 때문입니다

1024라는 숫자는 Cohere의 embed-multilingual-v3 모델 고유의 값이며, embedding 모델 설계자가 학습 시에 결정한 수입니다.

다른 모델이라면 다른 숫자가 나옵니다.

2. 많으면 많을수록 세밀한 의미를 표현할 수 있습니다 (단, 트레이드오프 존재)

차원 수는 「의미를 담는 상자의 수」와 같습니다.

많음 (3072개 등): 세밀한 의미 차이를 표현하기 쉬움. 검색 정확도가 올라가기 쉬움 -
적음 (384개 등): 표현할 수 있는 정밀도는 떨어지지만, 저장 용량과 계산 비용이 가벼워짐

「그럼 많을수록 좋은 것 아닌가」 싶겠지만 꼭 그렇지만은 않습니다.

• 벡터가 커지는 만큼 Vector DB의 스토리지 용량이 늘어남 (1 chunk당 3072개 × 4바이트 = 12KB를 100만 chunk 저장하면 12GB에 달한다는 규모) -
• 검색할 때마다 계산이 무거워져 응답이 느려짐 -
• 경우에 따라서는 과잉이 되어 오히려 정확도가 떨어지는 케이스도 있음

따라서 「적절한 중간 지점」으로서 1024나 1536 정도가 채택되는 경우가 많습니다.

embedding 모델의 입력에는 「최대 512 토큰」과 같이 상한선이 있습니다. 토큰 (Token) 이라는 것은, AI가 문장을 다룰 때의 최소 단위를 의미합니다.

• 영어의 경우, 대략 「단어 1개 ≒ 1 토큰」이지만, 긴 단어는 분할됩니다.
• 일본어의 경우, 「1 글자 ≒ 1~2 토큰」 정도가 기준입니다 (모델에 따라 다름).

예: "running" → "run" + "ning" 처럼 2 토큰으로 잘립니다.

이것 또한 RAG에서는 여기저기서 등장하는 단위이므로, 기억해 두시기 바랍니다.

• 문장을 「숫자의 나열 (벡터 (Vector))」로 변환하는 것 = embedding (임베딩)
• 의미가 가까운 문장은 벡터로서도 가깝습니다.
• 하나의 chunk (청크)마다 하나의 벡터 (예: 1024개의 숫자)를 만듭니다.

chunk를 벡터로 만들었다면, 그것을 어딘가에 저장해야 합니다.

여기서 등장하는 것이 Vector Database (Vector DB) 입니다.

일반적인 데이터베이스 (MySQL 등)는 「문자열로 검색」, 「수치로 범위 지정」 같은 작업을 잘합니다.

Vector DB는 「이 벡터와 가까운 벡터 top 5를 찾아줘」와 같은 쿼리 (Query)에 특화된 특수 데이터베이스가 됩니다.

대표적인 것으로 Chroma, Pinecone, Weaviate, Qdrant 등이 있습니다. Chroma의 공식 문서에서 인용하자면 다음과 같습니다.

Chroma is the open-source data infrastructure for AI.

Store documents and metadata. / Dense, sparse, and hybrid search. / Filter results at query time by metadata conditions.

요컨대 「문서와 메타데이터를 저장하고, 벡터로 검색할 수 있으며, 검색 시 메타데이터로 필터링도 할 수 있다」는 것이 Vector DB의 기본 기능입니다.

메타데이터 (Metadata) = **「데이터 자체가 아니라, 데이터에 붙이는 부가 정보」**를 말합니다.

Vector DB에 chunk를 저장할 때, 벡터뿐만 아니라 다음과 같은 정보도 함께 저장합니다.

메타데이터가 있으면 나중에 **「가정요리대전 안에서만 검색하기」**와 같은 필터링이 가능해집니다. 이것이 있느냐 없느냐에 따라 RAG의 정밀도가 확연히 달라집니다 (후술하겠습니다).

• chunk의 벡터는 Vector DB에 저장한다.
• Vector DB는 「벡터가 가까운 것」을 고속으로 찾을 수 있다.
• 벡터뿐만 아니라 메타데이터 (출처, 장, 페이지 등)도 함께 저장한다.

이것으로 「준비 단계 (Preparation Phase)」는 끝났습니다. 문서가 벡터 + 메타데이터와 함께 Vector DB에 나열되어 있는 상태가 완성되었습니다. 이를 **인덱스 (Index)**가 생성된 상태라고 부릅니다.

「index (인덱스)」는 책의 권말에 붙어 있는 색인과 같은 단어입니다.

일반적인 책이라도 「혈액 → p.42, 87, 153」과 같은 색인이 뒤에 붙어 있으면, 「혈액」이라는 키워드를 통해 관련 페이지로 바로 이동할 수 있습니다.

RAG에서의 index는 **「문서를 나중에 검색하기 쉬운 형태로 정리하여 저장한 상태」**를 의미합니다. Vector DB 안에 chunk의 벡터와 메타데이터가 들어 있는 상태가 「인덱스가 구축된 (Indexed)」 상태가 됩니다.

**Indexing (인덱싱)**이라는 동사는 그 상태를 만드는 작업, 즉 준비 단계 전체 (Load → Split → Embed → Store)를 뜻합니다.

사용자로부터 질문이 들어오는 시점부터 시작하겠습니다.

**Retrieve (리트리브)**는 영어로 「가져오다」, 「회수하다」라는 의미입니다. RAG에서는 「사용자의 질문과 관련이 있어 보이는 chunk를 Vector DB에서 추출하는」 공정을 가리킵니다.

구체적인 흐름은 다음과 같습니다.

• 사용자의 질문 텍스트(예: "함박 스테이크에 양파를 넣는 타이밍은?")를 동일한 embedding (임베딩) 모델로 벡터로 변환합니다.
• 해당 벡터와 Vector DB 안에 있는 모든 chunk (청크)의 벡터 사이의 **거리(유사도)**를 계산합니다.
• 거리가 가까운 순으로 상위 k개를 추출합니다 (k=3 또는 k=5가 일반적입니다).

이 "상위 k개"를 top-k라고 부릅니다. 한국어로는 "상위 k건"입니다.

두 벡터의 "가까움"을 측정하는 대표적인 방법입니다. 내용은 중·고등학교에서 배우는 cosθ (코사인 유사도)이며,

• 완전히 같은 방향 → 1.0
• 직각 (무관함) → 0
• 반대 방향 → -1.0

이 됩니다. 구현상으로는 LangChain이나 Chroma가 내부적으로 계산해주기 때문에, 직접 식을 작성할 일은 거의 없습니다. "숫자가 클수록 가깝다"라고만 기억해 두면 충분합니다.

실제로 Chroma에서 검색하는 처리는 라이브러리를 사용하면 정말 한 줄로 작성할 수 있습니다.

results = store.similarity_search_with_score(
query="함박 스테이크에 양파를 넣는 타이밍은?",
k=3,
...

이렇게 하면 "질문과 유사한 chunk가 가까운 순서대로 3개" 반환됩니다.

여기서 중요한 테크닉을 하나 소개하겠습니다.

벡터 검색은 본질적으로 **"확률적"**입니다. "의미가 가까운 chunk가 상위에 나오길 바란다"는 것은 기계의 판단에 도박을 거는 것과 같습니다. 도박은 빗나갈 때가 있습니다.

도박에 의존하는 범위를 최소화하기 위한 테크닉이 바로 메타데이터를 이용한 사전 필터링 (Pre-filtering) 입니다.

예를 들어, 사용자가 "카레 만드는 법"을 물어봤다고 가정해 봅시다.

**"요리책 시리즈로 한정해서 검색한다"**는 것이 미리 결정되어 있다면, 벡터 검색을 실행하기 전에 book_category = "요리"로 필터링해 두면 됩니다.

results = store.similarity_search_with_score(
query="카레 만드는 법",
k=3,
...

이것만으로도 검색 대상이 100만 chunk에서 1만 chunk로 압축될 수 있습니다.

노이즈가 크게 줄어들어 정확도와 비용을 동시에 개선할 수 있습니다.

"벡터 검색 전에 걸러낼 수 있는 것은 미리 걸러라"라는 것은 화려하진 않지만 매우 효과적인 설계 지침입니다.

여기까지 진행하면 사용자의 질문과 "관련 chunk top-3"가 준비됩니다. 이것을 AI (LLM)에게 전달하여 답을 쓰게 하는 것이 마지막 공정입니다.

사용자가 채팅창에 입력하는 것은 다음과 같은 단순한 질문 한 줄뿐입니다.

함박 스테이크에 양파를 넣는 타이밍은?

실제로 LLM에 전달되는 프롬프트 (Prompt, AI 입력 텍스트)는 훨씬 더 긴 형태가 됩니다. RAG 앱이 백그라운드에서 사용자의 질문에 "지시문"과 "참고 문헌"을 붙여 하나의 커다란 문자열로 합친 후 LLM에 전달합니다.

당신은 요리책 어시스턴트입니다.
다음 참고 문헌을 보고 사용자의 질문에 답해 주세요.
--- 참고 1 (출처: 가정 요리 대전 제3장 p.42) ---
...

이를 받은 LLM이 참고 문헌을 바탕으로 답변을 생성합니다.

이 부분은 오해가 생기기 매우 쉬우므로 명확히 짚고 넘어가겠습니다.

"LLM이 필요에 따라 검색을 수행하고 스스로 프롬프트를 구성하는" 것이 아닙니다.

기본적인 RAG에서는 프롬프트를 구성하는 것은 RAG 앱 (프로그램 측)의 역할이며, LLM은 구성된 문자열을 "읽고 답하는" 것뿐이라는 단순한 역할 분담이 이루어져 있습니다.

시계열로 보면 다음과 같은 흐름입니다.

[사용자] 채팅창에 "함박 스테이크에 양파를 넣는 타이밍은?" 입력 → 전송
↓
[RAG 앱] ① 질문을 벡터화
...

사용자에게 보이는 것은 "자신이 입력한 한 줄의 질문"과 "돌아온 답변"뿐입니다. 중간의 "참고 1은 이 chunk, 참고 2는 저 chunk, ..."와 같은 과정은 모두 프로그램 내부에서 일어나는 무대 뒤의 준비 과정입니다.

ChatGPT를 평소에 사용할 때를 상상해 보면 이해하기 쉽습니다. 사용자가 입력창에 질문을 입력하는 것만으로도, 시스템 프롬프트나 내부 설정들이 사용자 눈에는 보이지 않는 곳에서 AI에게 전달되고 있죠. RAG에서도 이와 같은 과정이 **'Vector DB에서 검색한 chunk를 매번 프롬프트에 삽입한다'**는 형태로 이루어지고 있다는 것입니다.

• 사용자의 질문도 벡터로 변환합니다.
• Vector DB에서 '가장 유사한 chunk' 상위 k개를 가져옵니다 (retrieve).
• 메타데이터로 사전에 필터링하면 정확도와 비용 모두 높아집니다.
• 가져온 chunk를 '참고 문헌'으로 AI에게 전달하여 답변을 작성하게 합니다 (generate).

이 과정을 한 장의 그림으로 나타내면 다음과 같습니다.

─── 준비 단계 (한 번만 실행)───
[원본 문서 (PDF, Web 등)]
↓ Load
...

이것이 RAG의 기본 형태입니다.

**Context Window(컨텍스트 윈도우)**는 AI가 한 번에 읽을 수 있는 글의 길이를 말합니다. 토큰 수로 측정합니다.

2023년경까지는 '수천~수만 토큰'이 일반적이었지만, 2024년부터 2026년에 걸쳐 폭발적으로 늘어나,

• Claude Opus 4.7:
  1M (100만) 토큰 - Gemini 3.5 Flash
  1M 토큰

이러한 수준에 도달했습니다. 일본어 장편 소설 1~2권이나 기술서 여러 권을 통째로 한 번에 읽히게 할 수 있는 규모입니다.

여기서 자연스럽게 궁금증이 생깁니다.

1M 토큰이 들어간다면, 관련 문서를 전부 context에 채워 넣으면 검색 같은 건 필요하지 않을까?

실제로 SNS에서는 'RAG는 끝났다(RAG is dead)'와 같은 자극적인 기사가 주기적으로 돌고 있습니다.

하지만 결론부터 말하자면 RAG는 사라지지 않습니다. 그 이유를 네 가지로 나누어 설명하겠습니다.

2023년 Stanford의 Liu 등이 발표한 논문 *

반면, 전체 텍스트를 통째로 집어넣고 답하게 하면 "답변의 어느 부분이 참고 자료의 어느 페이지에 대응하는가"를 원리적으로 추적할 수 없습니다.

의료, 법률, 교육과 같이 "왜 그렇게 작성했는가?"에 답할 수 없으면 곤란해지는 영역에서는 이것이 결정적인 차이가 됩니다.

2025년 arXiv:2501.01880으로 발표된 비교 연구인 *"Long Context vs. RAG for LLMs: An Evaluation and Revisits"*의 결론을 요약하면 다음과 같습니다.

QA (질의응답)에서는 Long Context가 RAG를 상회하는 경향이 있음 (Wikipedia 계열에서 현저함)

• 단, 대화 기반 및 일반적인 질문에서는 RAG에 이점이 있음 - chunk 기반의 단순한 (naive) RAG는 뒤처지지만,
• 요약 기반의 검색은 long context와 동등함

즉, "전부 넣는 것"보다 "좋은 것을 골라서 넣는 것"이 종종 더 강력하다는 뜻입니다. 이는 직관에 반하지만, 생각해보면 자연스러운 일입니다. 노이즈가 많을수록 AI는 그곳에 주의를 빼앗기기 때문에, retrieval (검색)은 "용량 제약에 따른 타협"이 아니라, "노이즈를 제거하여 시그널을 농축하는" 필터로서도 기능하고 있는 셈입니다.

첨단 팀들이 채택하고 있는 구조는 "둘 중 하나"가 아니라 **"라우팅 (Routing)"**입니다.

단순·국소적인 쿼리 $\rightarrow$ RAG ("이 재료의 대체품은?", "이 용어의 의미는?")
복잡·횡단적인 쿼리 $\rightarrow$ Long Context ("이 자료 전체를 읽고 방침을 정리해줘")

"Long Context가 나왔으니 RAG는 필요 없다"는 주장은,

• 문서 집합이 작고 (1M 이내)
• 인용·출처가 필요 없으며
• 비용과 레이턴시 (Latency)를 신경 쓰지 않는다

라는 세 가지 조건이 모두 충족될 때만 옳다는 의미가 됩니다. 실제 프로덕트에서 이 세 가지가 모두 갖춰지는 경우는 오히려 드뭅니다.