---
title: "RAG 논문 백엔드 관점으로 읽기"
slug: "llm-backend-09-rag-paper-backend-perspective"
canonicalUrl: "https://moonshotnotes.com/posts/llm-backend-09-rag-paper-backend-perspective/"
sourceUrl: "https://moonshotnotes.com/posts/llm-backend-09-rag-paper-backend-perspective/"
markdownUrl: "https://moonshotnotes.com/agent/posts/llm-backend-09-rag-paper-backend-perspective.md"
language: "ko"
category: "AI Backend"
updatedAt: "2026-05-12"
agentTokenEstimate: 1084
---

# RAG 논문 백엔드 관점으로 읽기

Retrieval Augmented Generation 논문을 백엔드 개발자 관점에서 읽고, parametric memory, non parametric memory, retriever, generator를 서비스 아키텍처로 해석합니다.

## Agent metadata

- Source: https://moonshotnotes.com/posts/llm-backend-09-rag-paper-backend-perspective/
- Markdown: https://moonshotnotes.com/agent/posts/llm-backend-09-rag-paper-backend-perspective.md
- Language: ko
- Category: AI Backend
- Tags: LLM, Backend, RAG, Paper Review, Retrieval
- Updated: 2026-05-12
- Estimated tokens: 1084

## 검색과 생성을 결합하면 서비스 구조가 어떻게 달라질까

이 글에서는 RAG 원전 논문인 “Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks”를 백엔드 개발자 관점에서 읽어봅니다.

RAG를 처음 접하면 보통 “벡터 검색해서 LLM에 넣는 것” 정도로 이해합니다. 틀린 말은 아니지만, 실서비스를 만들기에는 부족합니다. RAG는 단순 기능이 아니라 지식의 저장 위치를 바꾸는 아키텍처입니다.

모델이 내부 파라미터에 가진 지식만 쓰는 것이 아니라, 외부 문서 저장소를 검색해서 답변에 반영합니다. 백엔드 관점에서는 “LLM이 모르는 지식을 어떻게 저장하고, 검색하고, 근거로 연결할 것인가”의 문제입니다.

분석 기준일: 2026-05-12
실습 기준 환경: PostgreSQL, pgvector, embedding model, LLM API
주요 참고자료: RAG Paper, pgvector Docs, OpenAI Evals Docs

## 핵심 요약

- RAG는 parametric memory와 non-parametric memory를 결합하는 접근이다.
- 백엔드 관점에서 RAG는 문서 저장소, 검색기, 생성기, 평가기의 조합이다.
- RAG의 핵심은 “검색했다”가 아니라 “근거 있는 답변을 안정적으로 제공한다”이다.
- 검색 품질과 생성 품질은 분리해서 평가해야 한다.
- citation, 권한, 최신성, 재색인은 RAG 운영의 핵심 문제다.

## 1. RAG를 왜 봐야 하는가

LLM은 많은 지식을 알고 있지만, 모든 것을 최신 상태로 알지는 못합니다. 조직 내부 문서, 최신 정책, 제품 매뉴얼, 장애 보고서, 코드베이스 문서는 모델의 학습 데이터에 없을 수 있습니다.

RAG는 이런 문제를 해결하기 위한 대표적인 구조입니다.

```text
# 예시입니다.
사용자 질문
→ 관련 문서 검색
→ 검색된 문서를 context로 구성
→ LLM이 context 기반 답변 생성
→ 출처와 함께 응답
```

## 2. 논문의 문제의식

RAG 논문은 대형 사전학습 모델이 factual knowledge를 파라미터에 저장하지만, 지식을 정확하게 접근하거나 업데이트하거나 출처를 제공하는 데 한계가 있다고 봅니다.

백엔드 관점으로 바꾸면 이렇습니다.

```text
# 예시입니다.
모델 내부 지식만으로는
- 최신 문서 반영이 어렵다.
- 출처 제공이 어렵다.
- 조직별 지식 반영이 어렵다.
- 잘못된 답변을 추적하기 어렵다.
```

그래서 외부 지식 저장소가 필요합니다.

## 3. Parametric Memory와 Non-parametric Memory

| 개념 | 논문 관점 | 백엔드 관점 |
|---|---|---|
| Parametric Memory | 모델 파라미터에 저장된 지식 | LLM 자체가 알고 있는 일반 지식 |
| Non-parametric Memory | 검색 가능한 외부 지식 | 문서 DB, vector index, search engine |
| Retriever | 관련 문서 검색 | embedding search, hybrid search |
| Generator | 답변 생성 | LLM API 또는 자체 모델 |

실무에서는 non-parametric memory가 매우 중요합니다. 문서가 바뀌면 모델을 다시 학습시키는 것이 아니라 index를 갱신할 수 있기 때문입니다.

## 4. Retriever와 Generator

RAG는 검색기와 생성기의 결합입니다.

```text
# 예시입니다.
Retriever:
질문과 관련 있는 문서 chunk를 찾는다.

Generator:
검색된 chunk를 근거로 답변을 생성한다.
```

둘 중 하나만 좋아서는 충분하지 않습니다. 검색기가 잘못된 문서를 가져오면 generator가 아무리 좋아도 답변이 틀릴 수 있습니다. 반대로 좋은 문서를 가져와도 generator가 근거를 무시하면 품질이 떨어집니다.

## 5. 백엔드 아키텍처로 해석하기

RAG 서비스를 백엔드 구조로 그리면 다음과 같습니다.

```text
# 예시입니다.
Document Source
→ Ingestion Worker
→ Chunking
→ Embedding
→ Vector Store
→ Retrieval API
→ Prompt Builder
→ LLM
→ Response Validator
→ Citation Renderer
→ Eval Logger
```

이 구조에서 중요한 운영 포인트는 다음입니다.

| 레이어 | 운영 질문 |
|---|---|
| Ingestion | 문서 변경을 어떻게 감지할 것인가? |
| Chunking | 검색 품질에 맞는 chunk 크기는? |
| Embedding | 모델 변경 시 재색인할 것인가? |
| Vector Store | metadata filter와 권한을 어떻게 적용할 것인가? |
| Prompt Builder | 검색 결과를 얼마나 넣을 것인가? |
| LLM | 근거 없는 답변을 어떻게 막을 것인가? |
| Eval | 검색 실패와 생성 실패를 어떻게 분리할 것인가? |

## 6. RAG의 실패 유형

| 실패 유형 | 설명 | 대응 |
|---|---|---|
| Retrieval miss | 관련 문서를 못 찾음 | query rewrite, hybrid search |
| Retrieval noise | 관련 없는 문서가 섞임 | reranking, metadata filter |
| Context overflow | 문서가 너무 많음 | token budget, compression |
| Citation hallucination | 없는 출처를 만듦 | citation은 chunk_id에서만 선택 |
| Permission leak | 권한 없는 문서가 검색됨 | 서버 측 ACL filter |
| Stale index | 오래된 문서로 답변 | reindex trigger, versioning |

RAG에서 가장 위험한 것은 답변이 그럴듯하지만 근거가 틀린 경우입니다.

## 7. 검색 품질과 답변 품질 평가

RAG 평가는 두 단계로 나눠야 합니다.

| 평가 | 질문 |
|---|---|
| Retrieval Quality | 정답 문서가 검색 결과에 들어왔는가? |
| Answer Quality | 검색된 근거를 바탕으로 올바르게 답했는가? |

예시 지표:

```text
# 예시입니다.
retrieval_precision@k
retrieval_recall@k
answer_correctness
citation_accuracy
groundedness
```

검색이 실패했는지, 생성이 실패했는지 분리해야 개선 방향이 보입니다.

## 8. 실무 적용 체크리스트

```text
# 예시입니다.
[ ] 문서 source와 version을 저장하는가?
[ ] chunk_id가 citation과 연결되는가?
[ ] embedding model 변경 시 재색인 계획이 있는가?
[ ] vector search에 metadata filter를 적용하는가?
[ ] 사용자 권한이 retrieval 단계에서 강제되는가?
[ ] 검색 품질과 답변 품질을 분리해 평가하는가?
[ ] stale index를 감지할 수 있는가?
[ ] RAG 실패 케이스를 eval dataset으로 축적하는가?
```

## 9. Q&A

### Q1. RAG는 fine-tuning을 대체하나요?

항상 그렇지는 않습니다. 최신 외부 지식, 조직 내부 문서, 출처 제공이 중요하면 RAG가 유리합니다. 특정 스타일이나 태스크 패턴을 학습시키는 데는 fine-tuning이 더 적합할 수 있습니다.

### Q2. vector search만 쓰면 충분한가요?

초기에는 충분할 수 있습니다. 하지만 키워드가 중요한 문서, 숫자, 코드, 고유명사가 많은 경우 hybrid search가 필요할 수 있습니다.

### Q3. RAG 품질은 어떻게 올리나요?

검색 쿼리, chunking, embedding, metadata filter, reranking, prompt, eval을 함께 개선해야 합니다. 하나만 바꿔서는 원인을 놓치기 쉽습니다.

## 10. 참고자료와 불확실성

### 참고자료

- RAG Paper: https://arxiv.org/abs/2005.11401
- pgvector: https://github.com/pgvector/pgvector
- OpenAI Evals: https://platform.openai.com/docs/guides/evals

### 불확실성

- RAG 논문의 구조와 현재 프로덕션 RAG 구현은 다를 수 있습니다.
- chunking, embedding, reranking의 최적 조합은 데이터셋마다 다릅니다.

---