RAG(Retrieval-Augmented Generation)는 「LLM에 사내 문서를 읽히는 메커니즘」 정도로 설명되곤 하지만, 실제로 만들려고 하면 갑자기 막막해집니다.

• 검색한 문서는 모델의 어디에 들어가는가? - 모델의 내부(가중치, weights)는 변하는가?
• 그냥 프롬프트에 붙여넣는 것과 무엇이 다른가? - 벡터 DB(Vector DB)는 필수인가?

이 기사는 그 부분에 대해 **「실제로 무엇이 어떻게 움직이고 있는가」**의 수준에서 정리한 것입니다. 수식은 사용하지 않습니다.

대상 독자: RAG라는 용어는 알고 있지만, 내부에서 어떤 일이 일어나고 있는지는 모호한 분.

내용이 길기 때문에 요점을 먼저 적어둡니다.

RAG는 세 단어로 이루어져 있습니다.

그리고 가장 중요한 성질이 이것입니다.

RAG는 모델을 재학습하지 않는다. 가중치는 1바이트도 변하지 않는다.

IBM, AWS, Google Cloud 등의 공식 해설에서도 RAG는 일관되게 「재학습 없이 LLM을 외부 지식 베이스에 연결하는 메커니즘」으로 설명됩니다. 파인튜닝(Fine-tuning)과의 결정적인 차이가 바로 이 지점입니다.

순서가 반대입니다.

RAG는 Lewis et al. (2020, Meta AI / University College London / New York University)의 논문이 기원이며, 에이전트(Agent)나 ToolUse라는 패러다임보다 이전부터 존재했습니다.

고전적인 RAG는 「반드시 검색한 뒤에 생성하는」 고정 파이프라인(pipeline)이며, LLM이 호출할지 말지를 판단하는 도구가 아닙니다.

고전적 RAG (고정 파이프라인):
질문 → [반드시 검색] → [반드시 연결] → 생성
Agentic RAG (후발 파생형):
...

에이전트의 문맥에서 검색을 도구로 구현하는 형태(Agentic RAG)는 확실히 일반화되고 있지만, 그것은 RAG의 한 형태일 뿐이지 RAG의 정의는 아닙니다.

이 부분을 이해하면 RAG의 전체상이 한눈에 보입니다.

LLM으로의 입력은, 최종적으로는 단 하나의 토큰 열입니다.

그 토큰 열이,

• 당신이 키보드로 직접 입력한 것인지,
• 검색 시스템이 자동으로 가져온 문서를 연결한 것인지,

모델은 구별할 수 없으며, 구별할 필요도 없습니다.

직접 입력: [질문 + 당신이 붙여넣은 자료] ──┐
├──► 동일한 토큰 열로서 모델로 전달
RAG: [질문 + 검색이 가져온 자료] ──┘

「RAG 전용의 특별한 입력 포트」는 존재하지 않습니다. 검색 문서도 직접 붙여넣은 텍스트와 완전히 동일한 입구를 통해 들어갑니다.

즉 —

「RAG인가 직접 입력인가」는 모델 내부의 이야기가 아니라, 입력 토큰 열을 누가 어떻게 준비했느냐 하는 "외부"의 이야기입니다.

틀렸습니다. 프롬프트의 구성은 100% 애플리케이션 측의 처리입니다.

LangChain, LlamaIndex, 혹은 자체 코드가 검색 결과와 쿼리(query)를 문자열로 연결하고 있을 뿐입니다. 실체는 다음과 같습니다.

# 이것이 이른바 "Prompt Builder"의 정체
prompt = f"""다음 컨텍스트에 기반하여 질문에 답해 주세요.
컨텍스트에 답이 없는 경우에는 "모르겠습니다"라고 답해 주세요.
...

LLM이 받는 것은 이 구성된 이후의 문자열(→토큰 열)뿐입니다. LLM은 「어디까지가 검색 결과이고 어디부터가 질문인지」를 텍스트로 적혀 있는 것 이상의 수준으로는 알지 못합니다.

이러한 오해를 가진 채로 있으면, 「RAG는 LLM이 알아서 해주는 기능」이라고 생각하게 되어, RAG의 본질(=외부의 메커니즘)을 정반대로 이해하게 됩니다.

입력이 같다면 결과도 같다. 그렇다면 무엇을 위한 RAG인가.

마지막 점이 가장 중요합니다. RAG의 실패 대부분은 생성 측이 아니라 검색 측에서 일어납니다. 엉뚱한 자료를 건네준다면, 수동으로 잘못된 자료를 붙여넣은 것과 마찬가지로 답변도 그 영향을 받습니다. 생성 프롬프트(Generation Prompt)를 아무리 다듬어도 검색이 어긋나 있으면 고쳐지지 않습니다.

여기서부터 구현 이야기입니다. RAG에는 시간축이 다른 두 가지 페이즈(Phase)가 있습니다. 이 둘을 구분하지 않고 이해하려고 하면 혼란에 빠집니다.

【페이즈 ①】 인덱스 구축 (사전·배치)
문서 → 전처리 → 청크 (Chunk) 분할 → 벡터화 (Vectorization) → DB에 저장
【페이즈 ②】 검색과 생성 (실행 시·사용자의 요청마다)
...

페이즈 ①은 「도서관에 책을 진열하고 색인을 만드는」 작업, 페이즈 ②는 「질문을 받으면 색인을 찾아 책을 가져오는」 작업입니다. ①은 사전에 완료해 둡니다.

┌─ 텍스트 (Markdown/CSV)
├─ PDF / Word / HTML
├─ 이미지 (PNG/JPEG) ┐
...

모든 입력을 텍스트 문자열로 정규화하고, **청크 (Chunk)**라는 단위로 분할합니다.

청크 사이즈 예시: 512 토큰 / 오버랩 (Overlap) 50 토큰

왜 분할하는가: 문서 전체를 벡터화하면 의미가 희석되어 검색 정밀도가 떨어집니다. 또한, LLM의 컨텍스트(Context)에 들어갈 수 있는 양에도 한계가 있습니다.

왜 오버랩(Overlap)하는가: 경계 부분에서 문맥이 끊기는 것을 방지하기 위해서입니다. 「~에 대해서는,」에서 끊겨버리면, 다음 청크만 가져왔을 때 의미가 통하지 않습니다.

청크 설계는 RAG의 정밀도를 가장 크게 좌우하는 파라미터(Parameter) 중 하나입니다. 「일단 512」로 시작해서 나중에 조정하는 것이 실무적입니다.

분할된 청크를 **임베딩 모델 (Embedding Model)**이라는 딥러닝 모델을 통해 고정 길이의 벡터로 변환합니다.

수년 전까지는 대체로 맞는 설명이었습니다 (BERT 계열의 인코더 모델이 주류였기 때문). 하지만 지금은 통하지 않습니다.

MTEB 벤치마크 상위권을 차지하는 NV-Embed-v2, E5-Mistral, SFR-Embedding, gte-Qwen2, Qwen3-Embedding 등은 모두 Mistral이나 Llama, Qwen과 같은 디코더형 LLM을 출발점으로 하여, 풀링 층 (Pooling Layer)을 추가하고 대조 학습 (Contrastive Learning)으로 파인튜닝 (Fine-tuning)한 것입니다. 이 기법이 최근의 성능 향상을 견인했습니다.

정확한 표현은 다음과 같습니다.

Embedding Model은,

답변 생성용 LLM과는 역할이 다른 별개의 모델.

BERT 계열 인코더가 전통적이지만, 최근에는 LLM 기반 모델도 주류.

「LLM이 아니다」가 아니라 「생성용 LLM과는 별개의 모델」이라고 말하면, 전달하고자 하는 취지를 유지하면서 정확해집니다.

내부에서 어떤 일이 일어나는지 열어보면 다음과 같습니다.

텍스트
│
▼
...

짚고 넘어가야 할 2가지 포인트:

• Self-Attention → FFN 블록은 1번이 아니라 N개 층(Layer)이 반복됩니다. 도해에서는 이곳이 1번으로 그려지는 경우가 많지만, 실제로는 12층, 24층 등으로 쌓여 있습니다.
• 층을 흘러가는 것은 토큰이 아니라 히든 스테이트 (Hidden State, 연속값 벡터)입니다. 토큰 ID가 사용되는 것은 가장 아래의 임베딩 층에서 단 한 번뿐입니다. 이후에는 「1토큰 위치당 벡터 1개」가 층을 올라갈 때마다 그 내용을 바꾸며 흘러갑니다.

풀링 (Pooling)이 필요한 이유: Transformer는 「토큰당 1개」의 벡터를 출력하지만, 청크 전체를 1개의 벡터로 만들어 DB에 넣고 싶어 합니다. 그래서 평균을 취하는 등의 방식으로 1개로 압축합니다.

정규화 (Normalization)가 효과적인 이유: 길이를 1로 맞춰두면 코사인 유사도 (Cosine Similarity)와 내적 (Dot Product)이 동일한 순위를 반환하게 되어 계산을 효율화할 수 있습니다 (후술).

「이미지 → OCR → 텍스트」만이 선택지는 아닙니다. 실제로는 3가지 계통이 있습니다.

처음에는 (a)로 충분합니다. "이미지는 OCR하여 텍스트화하고, 원본 이미지로의 링크를 메타데이터(Metadata)로 갖게 한다"는 구성이 구현하기 쉬워 추천합니다.

CREATE TABLE documents (
id uuid PRIMARY KEY,
vector vector(1024), -- 벡터 본체
...

content를 저장하는 것을 잊지 마세요. 벡터만 가지고 있으면, 검색에서 히트한 후에 LLM에게 전달할

텍스트가 없습니다. 벡터는 "검색하기 위한 열쇠"이지, "전달할 내용"이 아닙니다. 이 부분을 놓치는 설계도가 의외로 많습니다.

meta

도 중요하며, 출처 표시(인용 원문 링크)나 필터링(부서별, 기간별)에 사용합니다.

벡터 검색은 RAG의 한 형태에 불과합니다.

키워드 검색 (BM25): 고유명사나 모델 번호의 완전 일치에 강함. 벡터 검색이 취약한 영역 -
하이브리드 검색 (Hybrid Search): 벡터 + BM25를 조합함. 실무에서는 이것이 표준이 되어가는 중 -
지식 그래프 (GraphRAG): 엔티티(Entity) 간의 관계를 추적함

"의미가 가까운 것"을 찾아내는 것이 벡터 검색이고, "그 단어가 있는 것"을 찾아내는 것이 키워드 검색입니다. 모델 번호나 사내 용어가 난무하는 현장에서는 벡터 검색만으로는 놀라울 정도로 찾아내지 못합니다. 하이브리드 방식을 검토하세요.

[1] 사용자의 질문
│
▼
...

이것은 절대 조건입니다. 인덱스(Index) 구축에 사용한 것과 **동일한 임베딩 모델 (Embedding Model)**로 쿼리(Query)를 벡터화해야 합니다.

모델이 다르면 벡터 공간이 달라지며, 거리 비교 자체가 무의미해집니다. "임베딩 모델을 새로운 것으로 교체하고 싶다"면, **기존 인덱스를 전수 재구축 (re-embedding)**해야 합니다. 운영 설계 시 반드시 의식해야 합니다.

코사인(Cosine)이 대표적이지만, 유일한 것은 아닙니다. pgvector는 3가지 종류의 거리를 지원합니다.

정규화된 임베딩 (OpenAI 모델 등)에서는 내적과 코사인은 동일한 순위를 반환합니다. 그 경우 내적이 계산이 더 가볍고 유리합니다.

이것을 모르면 2주를 허비하게 됩니다.

vector_cosine_ops

로 HNSW 인덱스를 만들면서, 쿼리에서 <-> (L2)를 사용하면, PostgreSQL은 묵묵히 인덱스를 무시하고 시퀀셜 스캔 (Sequential Scan)으로 빠집니다. 에러도 경고도 나오지 않습니다. 그저 느려지고, 기대와 다른 순서의 결과가 반환될 뿐입니다.

-- 인덱스와 쿼리의 연산자는 반드시 일치시켜야 함
CREATE INDEX ON documents USING hnsw (vector vector_cosine_ops);
SELECT content FROM documents ORDER BY vector <=> $1 LIMIT 5; -- ← <=> 로 맞춰줌

EXPLAIN ANALYZE에서 Index Scan이 되고 있다면 올바른 것이고, Seq Scan이라면 불일치하는 것입니다.

전수 조사와 전수 비교를 하면 느리기 때문에 근사 최근접 이웃 탐색 (ANN, Approximate Nearest Neighbor)을 사용합니다. pgvector는 HNSW와 IVFFlat을 제공합니다. 약간의 재현율(Recall)을 희생하는 대신, 대폭적인 속도 향상과 맞바꿉니다.

HNSW에서는 ef_search

매개변수가 정확도에 영향을 미칩니다. 기본값에서 높이면 거리 함수(distance function)를 바꾸는 것보다 검색 품질이 개선될 수도 있습니다(당연히 레이턴시(latency)와의 트레이드오프입니다).

Top-k로 가져온 후보를 더 고정밀 모델(Cross-Encoder)로 재정렬하는 공정입니다.

• 벡터 검색: 빠르지만 거칠다 → 넓게 30건을 가져옴
• 리랭커(Reranker): 느리지만 정밀하다 → 그중에서 정말 좋은 5건을 선택

정밀도 개선의 가성비가 매우 좋기 때문에, 정밀도 문제로 고민된다면 청크(chunk) 크기를 조정하기 전에 먼저 시도해 볼 가치가 있습니다.

앞서 언급했듯이, 이 부분은 애플리케이션의 역할입니다. 전형적인 템플릿은 다음과 같은 형태입니다.

다음 컨텍스트(context)에만 기반하여 질문에 답해 주세요.
컨텍스트에 답이 포함되어 있지 않은 경우 "모르겠습니다"라고 답해 주세요.
# 컨텍스트
...

"컨텍스트에 없는 경우에는 모른다고 답하라"라는 지시가 중요합니다. 이것이 없으면 모델은 자신의 내부 지식으로 메우려 합니다(다음 장).

마지막으로, 흔히 하는 오해를 하나 더 말씀드리겠습니다.

통상적인 RAG는 검색한 토큰을 출력에 그대로 복사하는 것이 아닙니다.

LLM은 검색된 문서를 "정보원"으로 읽고, 그 의미와 사실을 근거로 어휘 전체에서 새롭게 토큰을 생성합니다.

고유명사나 수치가 문서와 일치하는 경우가 자주 발생하지만, 그것은 "복사한" 것이 아니라 "읽고, 그것에 기반하여 작성한" 결과입니다.

RAG를 실운영하면 반드시 부딪히게 되는 문제입니다.

모델이 검색 문서를 무시하고 자신의 내부 지식(=가중치가 기억하고 있는 지식)으로 답해 버리는 경우가 있습니다. 이는 지식 충돌(knowledge conflict) 또는 context-unfaithfulness로 연구되고 있는 과제입니다.

서베이 논문의 결론은 명쾌합니다.

문맥과 가중치 중 어느 쪽을 우선할지에 대한 결정적인 규칙은 존재하지 않는다.

다만 모델은 의미적으로 일관되고 논리적이며 설득력 있는 정보를 선택하는 경향이 있다.

더 까다로운 점은, 강력한 모델일수록 올바른 외부 증거가 주어져도 자신의 내부 기억에 집착하는 경우가 있다는 보고도 있습니다.

• 프롬프트에 "컨텍스트에만 기반하여 답하라"고 명시한다
• "컨텍스트에 없는 경우에는 모른다고 답하라"를 넣는다
• 출처를 반드시 병기하여 인간이 검증할 수 있도록 한다
• 평가 데이터셋을 만들어 context-faithfulness를 지속적으로 측정한다

"검색 문서를 전달했으니 반드시 그것을 따를 것이다"라는 전제를 두지 마십시오. 이것이 실무에서 가장 중요한 마음가짐일지도 모릅니다.

지금까지의 이야기는 "프롬프트에 연결하는" 표준적인 RAG였습니다. 사실 검색 결과를 모델의 중간층(intermediate layer)에 직접 주입하는 아키텍처도 존재합니다. 흥미가 있다면 참고하시라는 차원에서 소개합니다.

RETRO가 주목받은 이유는 사전 학습된 모델의 가중치를 동결한 채 cross-attention 층을 추가하는 방식(논문에서는 6번째 층부터 3개 층마다)으로, GPT-3급의 성능을 약 25분의 1의 파라미터 수로 달성했기 때문입니다.

하지만 실무에서 RAG라고 하면 거의 100% 표준적인 "프롬프트에 연결하는" 방식입니다. 우선 그 방식부터 확실히 다지시기 바랍니다.

여담이지만, 표준적인 RAG에서도 검색 문서는 모든 층의 hidden state에 영향을 미칩니다. Transformer의 self-attention이 시퀀스 내의 모든 토큰을 혼합하기 때문에, 질문·답변 위치의 벡터는 각 층에서 검색 문서를 참조하기 때문입니다.

다만 이것은 가중치가 변했기 때문이 아니라, 입력이 변한 것이 attention을 통해 모든 층으로 파급된 것뿐입니다. RETRO 계열과 같은 구조적인 개입과는 원리가 다릅니다.

【설계로서 파악해야 할 점】
□ RAG는 가중치(weight)를 변경하지 않는다. 파인튜닝 (Fine-tuning)과는 별개의 것이다.
□ 프롬프트 (Prompt) 구성은 애플리케이션 측의 역할이다. LLM의 기능이 아니다.
...

한마디로 말하자면, RAG란 —

LLM이라는 '읽고 쓸 줄 아는 유능한 엔진'에, 검색해 온 문서라는 '사실의 소재'를, 프롬프트 (Prompt)를 통해 건네주는 메커니즘.

엔진(가중치)은 변하지 않는다. 소재는 외부에서 온다. 건네주는 작업을 수행하는 것은 당신이 작성하는 애플리케이션 코드입니다.

본 기사의 기술적 주장은 다음을 통해 확인했습니다 (2026년 7월 시점).

• IBM｜What is Retrieval-Augmented Generation (RAG)? — https://www.ibm.com/think/topics/retrieval-augmented-generation

• AWS｜What is RAG? — https://aws.amazon.com/what-is/retrieval-augmented-generation/

• Google Cloud｜What is Retrieval-Augmented Generation (RAG)? — https://cloud.google.com/use-cases/retrieval-augmented-generation

• NVIDIA Blog｜What Is Retrieval-Augmented Generation aka RAG (Lewis et al.의 경위, parameterized knowledge에 대한 설명) — https://blogs.nvidia.com/blog/what-is-retrieval-augmented-generation/

• Pinecone｜Retrieval-Augmented Generation (확장 프롬프트의 구체적인 예시) — https://www.pinecone.io/learn/retrieval-augmented-generation/

• Databricks｜Introduction to RAG in AI development — https://docs.databricks.com/en/generative-ai/tutorials/ai-cookbook/rag-overview

• DataCamp｜What Is RAG? (5단계 파이프라인) — https://www.datacamp.com/blog/what-is-retrieval-augmented-generation-rag

• Lewis et al. (2020) 「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」 (RAG 원 논문)

• NV-Embed: Improved Techniques for Training LLMs as Generalist Embedding Models (arXiv:2405.17428) — 디코더 (Decoder) LLM 기반의 임베딩 (Embedding) 모델

• Alibaba-NLP/gte-Qwen2-7B-instruct (Hugging Face) — 인코더 전용 (Encoder-only) 계열과 디코더 전용 (Decoder-only) 계열의 2개 계통

• MTEB (Massive Text Embedding Benchmark)

• pgvector 공식 리포지토리 — https://github.com/pgvector/pgvector

• AWS Database Blog｜pgvector 인덱싱을 활용한 생성형 AI 애플리케이션 최적화: IVFFlat 및 HNSW 심층 분석 — https://aws.amazon.com/blogs/database/optimize-generative-ai-applications-with-pgvector-indexing-a-deep-dive-into-ivfflat-and-hnsw-techniques/

• Tiger Data Docs｜pgvector를 위한 핵심 벡터 개념 — https://www.tigerdata.com/docs/learn/search/key-vector-database-concepts-for-understanding-pgvector

• Neon｜pgvector와 HNSW 인덱스를 사용한 벡터 검색 및 이해 — https://neon.com/blog/understanding-vector-search-and-hnsw-index-with-pgvector

• pgvector 거리 함수: 코사인 vs L2 vs 내적(Inner Product) (연산자와 인덱스의 불일치 문제) — https://medium.com/@philmcc/pgvector-distance-functions-cosine-vs-l2-vs-inner-product-d5609c7e39b4

• CLIP: Natural Language Supervision을 통한 전이 가능한 시각 모델 학습 (Radford et al., 2021)

• ColPali: Vision Language Model을 활용한 효율적인 문서 검색 (2024)

• Qdrant｜멀티모달 검색 — https://qdrant.tech/documentation/multimodal-search/

• Knowledge Conflicts for LLMs: A Survey (arXiv:2403.08319) — 우선순위에 결정적인 규칙은 존재하지 않는다

• FaithfulRAG: Context-Faithful RAG를 위한 사실 수준 충돌 모델링 (arXiv:2506.08938)

• ConflictBank / FaithEval — 지식 충돌 벤치마크

• Borgeaud et al. (2022)「트릴리언 토큰에서 검색하여 언어 모델 개선」(RETRO, PMLR) — https://proceedings.mlr.press/v162/borgeaud22a/borgeaud22a.pdf

• Khandelwal et al. (2020)「기억을 통한 일반화: 최근접 이웃 언어 모델」(kNN-LM)

• Izacard & Grave (2021)「생성 모델과 결합한 구문 검색으로 개방 영역 질의응답 활용」(FiD)

• LangChain｜처음부터 구현하는 RAG: 개요

※ 본 기사는 초보자에게 그림이나 비유를 우선하여 작성되었으며, 세부 사항(KV 캐시, 인과적 어텐션(causal attention)의 엄밀한 의존 관계, 리랭커의 내부 구조 등)은 간략화했습니다. 정확한 구현이나 최신 연구 동향은 위의 1차 자료들을 참고해 주십시오.