💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

> **Season 4 시작: Applied AI & LLM Systems**

> Season 3 13편(개발자 문화·커리어·AI 전망)을 마치고, Season 4는 "LLM을 제품에 녹여내는 실전"으로 들어갑니다. Ep 1은 RAG(Retrieval-Augmented Generation). 2023년 "Embeddings + Vector DB"로 시작했던 이 기술 스택이 2025년에는 얼마나 성숙했는지, 그리고 Long context·Fine-tuning과 어떻게 경계를 나누고 있는지 정리합니다.

Prologue — "RAG는 죽었다"는 소리가 매년 나오는 이유

GPT-4 32K가 나왔을 때도, Claude 100K·200K가 나왔을 때도, Gemini 1M이 나왔을 때도 같은 말이 반복됐다. **"이제 다 Context에 넣으면 되니 RAG는 필요 없다."**

2025년 현실: 상용 LLM 제품의 80% 이상은 여전히 RAG를 쓴다. 이유는 간단하다.

1. **비용**: 100K 토큰 한 번 호출 = 평균 3K 토큰 호출 30번 값

2. **지연시간**: Long context는 프리필(prefill) 단계가 선형적으로 늘어난다

3. **정확도**: "Lost in the middle" — 긴 컨텍스트 중간의 정보는 실제로 잘 안 쓰인다

4. **신선도**: 모델이 학습한 날짜 이후 정보는 무조건 외부에서 가져와야 한다

5. **권한/보안**: 사용자가 접근 가능한 문서만 답변 재료로 써야 한다

즉, "RAG가 안 죽은 이유"는 기술적 한계가 아니라 **제품 경제학**이다. 이 글에서는 RAG의 원리, 구성 요소별 선택 기준, 그리고 2025년 현장의 최신 패턴을 차근차근 풀어본다.

1장 · RAG의 기본 원리와 진화

1.1 왜 RAG인가

LLM의 근본 문제는 세 가지다.

- **Hallucination**: 모르는 것도 그럴듯하게 답한다

- **Knowledge cutoff**: 학습 시점 이후 정보 없음

- **Context window**: 무한하지 않고, 비싸고, 중간 정보 손실

RAG의 해결책: **질문이 들어오면 관련 문서를 먼저 찾아서, 그걸 컨텍스트에 넣고, 그 범위 안에서만 답하게 한다.**

간단한 수식으로:

기본 LLM: answer = LLM(prompt)

RAG: docs = Retriever(query, corpus)

answer = LLM(prompt + docs)

1.2 RAG의 3세대

| 세대 | 시기 | 특징 | 대표 스택 |

|------|------|------|-----------|

2025년 현재 진지한 제품은 대부분 **Advanced RAG + 선택적 Agentic 루프** 조합이다.

1.3 전체 파이프라인

[문서 수집]

↓

[전처리 + 청킹]

↓

[임베딩 + 인덱싱] ← 벡터 DB

↓ ────────────────────

[쿼리] → [쿼리 재작성] │

↓ │ (오프라인 인덱스)

[검색 (Hybrid)] │

↓ │

[Rerank] │

↓ ────────────────────

[컨텍스트 조립]

↓

[프롬프트 + LLM]

↓

[후처리 (인용, 가드레일)]

↓

[응답]

이 파이프라인의 각 단계가 모두 조절 가능한 "노브(knob)"다. 이 글은 각 노브를 어떻게 돌릴지 안내한다.

2장 · 임베딩 모델 선택

2.1 임베딩이란

텍스트를 고정 길이 벡터로 변환하는 것. "의미가 가까운 텍스트는 벡터 공간에서도 가깝다"가 전부다.

"강아지" → [0.12, -0.45, 0.88, ...]

"개" → [0.14, -0.42, 0.87, ...] (매우 가까움)

"자동차" → [0.92, 0.30, -0.11, ...] (멀다)

2.2 주요 임베딩 모델 2025

| 모델 | 차원 | 특징 | 비용 (1M 토큰) |

|------|------|------|----------------|

| Cohere embed-v3 (english/multilingual) | 1024 | Rerank와 세트로 강력 | $0.10 |

| Voyage voyage-3 | 1024 | 코드/한국어도 준수 | $0.06 |

| Upstage Solar embedding | 4096 | 한국어 특화, 한국어 벤치 톱권 | 별도 |

2.3 선택 기준

**문서가 주로 한국어인가?**

- 그렇다 → Upstage Solar, Voyage, 또는 BGE-m3부터 시작

- 다국어 → OpenAI 3-large / Cohere multilingual

**예산이 타이트한가?**

- 극도로 타이트 → text-embedding-3-small (차원을 512로 줄여도 품질 유지됨)

- 보통 → text-embedding-3-large + Matryoshka(축소)

**데이터 유출 리스크?**

- 외부 API 금지 → BGE-m3, E5-mistral 자체 호스팅

- 가능 → 상용 API가 운영 부담 적음

2.4 벤치마크만 믿지 마라

MTEB 같은 공개 벤치마크는 **당신의 도메인과 다르다.** 사내 문서, FAQ, 법률 문서 등 특수 도메인은 반드시 자체 평가셋(100–500 쌍)을 만들어야 한다.

간단한 평가:

queries = [("사내 휴가 규정은?", ["HR-POL-014"]), ...] # 정답 doc_id 매핑

for model in candidates:

hits_at_5 = 0

for q, gold in queries:

top5 = retrieve(q, model=model, k=5)

if any(d in gold for d in top5):

hits_at_5 += 1

print(model, hits_at_5 / len(queries))

Hit@5, MRR, NDCG@10 중 하나면 충분하다. **비싼 모델이 항상 이기지 않는다.**

3장 · 청킹 전략 — "쪼개는 법이 RAG를 결정한다"

청킹(chunking)은 문서를 어떤 단위로 쪼개서 임베딩할지 결정하는 과정이다. RAG에서 가장 저평가된 노브.

3.1 청크 크기의 트레이드오프

- **너무 작으면**: 문맥이 잘려서 모델이 이해 못 함

- **너무 크면**: 불필요한 정보가 섞여서 검색 정확도 떨어짐

일반적 권장: **512–1024 토큰, 50–100 토큰 오버랩**. 하지만 문서 종류에 따라 달라진다.

3.2 청킹 전략 5가지

**(1) Fixed-size (고정 길이)**

- 장점: 단순, 빠름

- 단점: 문단 경계를 무시

- 쓸 곳: 일단 베이스라인

**(2) Recursive Character Splitter**

- 줄바꿈 → 문장 → 단어 순으로 단계적으로 쪼갬

- LangChain 기본, 대부분 괜찮음

**(3) Semantic chunking**

- 임베딩 유사도가 급변하는 지점에서 분리

- 구현: 문장 단위로 임베딩해서 코사인 거리가 threshold 이상 벌어질 때 split

- 장점: 자연스러운 의미 경계

- 단점: 느림

**(4) Structure-aware (문서 구조 기반)**

- Markdown이면 헤더별, HTML이면 `<section>` 단위, PDF면 페이지/섹션 단위

- 기술 문서·위키·API 레퍼런스에 최고

**(5) Late chunking (2024 신기법)**

- 전체 문서를 먼저 임베딩한 후(긴 컨텍스트 임베딩 모델 필요) 토큰 범위별로 평균/풀링해 청크 벡터를 만든다

- 장점: 앞쪽 헤더의 문맥이 뒤쪽 청크까지 전달됨

- 구현 복잡하지만 긴 문서에서 품질 이득 큼

3.3 실전 템플릿

기술 문서(Markdown):

def chunk_markdown(md: str):

1) 헤더 H1/H2 기준으로 섹션 분리

2) 섹션이 1500토큰 초과하면 recursive split

3) 각 청크 앞에 상위 헤더 패스 붙이기 ("헤더 엔리치먼트")

...

**헤더 엔리치먼트**: 청크 본문 앞에 `[문서제목 > 섹션 > 소섹션]` 같은 계층 경로를 붙여서 임베딩한다. 단순하지만 검색 정확도가 눈에 띄게 오른다.

3.4 한국어 청킹 주의점

- `kss`, `soynlp` 등 한국어 문장 분리기 사용

- 마침표 없는 구어체, 이모지, 줄바꿈 많은 대화 로그는 fixed-size + overlap이 오히려 안정적

- 조사·어미 분절은 임베딩 모델이 알아서 함. 형태소 분석까지 할 필요는 보통 없음

4장 · 벡터 DB 선택 완전 가이드

4.1 주요 옵션 비교

| DB | 형태 | 강점 | 약점 | 추천 규모 |

|----|------|------|------|-----------|

4.2 pgvector가 2025년에 다시 주목받는 이유

"따로 벡터 DB 운영할 필요가 정말 있나?"가 화두다. pgvector는:

- Postgres 안에서 `vector` 타입으로 저장

- HNSW, IVFFlat 인덱스 지원

- 메타데이터·권한·트랜잭션이 "공짜로 딸려옴"

- 스케일은 리드 레플리카 + 파티셔닝으로 수천만 벡터까지 OK

초기 ~ 중간 규모(문서 수천만 건 이하)에선 대부분 pgvector로 충분하다. Supabase, Neon, 자체 Postgres 다 가능.

4.3 대규모 옵션 선택

수억 이상 벡터, QPS 수천이 필요하면:

- 관리 부담 회피 → Pinecone

- 비용 최적화 + 컨트롤 → Qdrant 자체 호스팅

- 초대형(수십억) → Milvus

4.4 인덱스 알고리즘: HNSW vs IVF

- **HNSW** (Hierarchical Navigable Small World): 쿼리 빠르고 정확도 높음. 기본 선택.

- **IVF/IVF-PQ**: 메모리 적게 쓰지만 튜닝 필요. 초대형에서만 의미.

pgvector·Qdrant·Weaviate 모두 HNSW를 기본 제공한다. `m=16`, `ef_construction=64`가 합리적 시작점.

5장 · 검색 품질 — Hybrid, Rerank, Query Rewrite

"벡터 검색만으로는 부족하다." 이 문장을 이해하는 순간부터 RAG 실력이 는다.

5.1 왜 순수 벡터 검색은 부족한가

- 고유명사, 제품 코드, 버전 번호: 의미적 유사도가 안 통함

- 최신 용어: 임베딩 모델이 모르는 단어

- Exact match 요구 질의: "2024년 3분기 매출" 같은 것

5.2 Hybrid Search

**BM25(키워드) + 벡터 검색의 결합.**

두 가지 결합 방식:

**(a) RRF (Reciprocal Rank Fusion)**

score(doc) = Σ 1 / (k + rank_i(doc)) # k=60 보통

두 검색기에서 받은 순위를 합친다. 점수 스케일이 달라도 OK. **프로덕션 기본값.**

**(b) Weighted Sum**

final = α * bm25_norm + (1-α) * vector_norm

정규화 필요하고 α 튜닝해야 함. 세밀하게 가능하지만 귀찮음.

OpenSearch, Elasticsearch, Weaviate, Qdrant는 Hybrid를 네이티브로 지원한다. pgvector는 BM25 부분을 `tsvector`로 만들어서 RRF를 앱 레벨에서 처리한다.

5.3 Rerank — 2단계 검색의 위력

**구조:**

Stage 1: Hybrid로 top-50 빠르게 가져옴

Stage 2: Cross-encoder Reranker로 top-50을 재정렬해 top-5만 LLM에 전달

Cross-encoder는 쿼리와 문서를 **함께** 인코딩해서 유사도를 계산한다. 느리지만 정확하다. 50개 정도면 지연시간 100–300ms로 관리 가능.

**주요 Reranker 2025:**

- Cohere Rerank v3 (multilingual): 한국어 포함 강력

- Jina Reranker v2: 오픈, 작고 빠름

- BGE-reranker-v2-m3: 오픈, 다국어

- Voyage rerank-2

Rerank만 붙여도 NDCG@10이 10–30% 오르는 경우가 흔하다. **가성비 최고의 업그레이드.**

5.4 Query Rewrite

사용자 질문이 검색에 그대로 좋은 경우는 드물다.

**패턴들:**

- **HyDE (Hypothetical Document Embedding)**: LLM에게 "이 질문에 대한 가상 답변"을 먼저 쓰게 한 후 그걸 임베딩해서 검색. 질문-답변의 임베딩 공간 차이를 좁힌다.

- **Query Expansion**: 동의어, 하위 개념을 LLM으로 생성해서 OR 검색

- **Decomposition**: 복합 질문을 여러 하위 질문으로 쪼개서 각각 검색한 후 병합

- **Step-back prompting**: "이 질문을 더 일반화하면?"으로 추상화된 쿼리 하나를 추가

실전에서는 **HyDE와 Decomposition의 조건부 적용**이 가장 가성비 좋다. LLM 호출이 추가되므로 간단한 질문은 그냥 통과시키고, "여러 주제가 섞인 질문"만 Decompose.

6장 · Fine-tuning vs RAG vs Prompt Engineering — 언제 뭘 쓰나

6.1 3개의 경계선

| 니즈 | 최적 접근 |

|------|-----------|

| 최신 지식, 사실 기반 답변 | **RAG** |

| 특정 스타일·포맷·톤 (JSON, 특정 말투) | **Fine-tuning** 또는 Few-shot |

| 특정 태스크 성능 극대화 (분류, 추출) | **Fine-tuning** (소형 모델) |

| 빠른 실험, 프로토타입 | **Prompt Engineering** |

| 민감한 사내 지식 답변 | **RAG** (자체 호스팅 포함) |

| 복잡한 추론 체인 | **Prompt + Agentic** |

6.2 오해들

**"Fine-tuning하면 사실을 '주입'할 수 있다."** — 틀렸다. LLM은 사실을 저장하는 데 최적화돼 있지 않다. 지식 주입은 RAG가 훨씬 안정적이다.

**"RAG는 구식이고 Fine-tuning이 진짜다."** — 정반대. 2025년 대형 제품(Notion AI, Glean, Perplexity 등) 전부 RAG 중심이고, Fine-tuning은 **스타일·툴 사용·포맷**에 제한적으로 쓴다.

**"Prompt만 잘 쓰면 RAG 필요 없다."** — Context window가 유한한 한 틀림.

6.3 조합이 정답

사내 지식 봇 =

Retrieval (RAG) ← 지식 최신성

+ Fine-tuned 응답 포맷 모델 ← JSON 구조, 인용 형식

+ Prompt 기법 (Plan-Execute) ← 추론 체인

7장 · Long Context가 바꾸는 것, 바꾸지 않는 것

Claude 200K, Gemini 1M–2M, GPT-4.1 1M. 2025년은 "Long context 시대"다.

7.1 바꾸는 것

- **단일 긴 문서 Q&A**: 하나의 50페이지 PDF를 통째로 넣는 게 현실적이 됨 → RAG 없이도 가능

- **대화 역사**: 수백 턴 대화를 요약 없이 유지 가능

- **코드 전체 읽기**: 중간 크기 레포를 통째로 넣어 리뷰 가능

7.2 바꾸지 않는 것

- **대규모 코퍼스 (수천 문서)**: 여전히 RAG 필수

- **비용**: 1M 컨텍스트는 한 번에 $5–$20대. 매 질의마다 이건 감당 못 함

- **지연시간**: 프리필이 수 초~수십 초

- **권한 필터**: 사용자별 접근 가능 문서만 넣으려면 어차피 검색 단계 필요

7.3 새로운 패턴: "Context Caching + RAG"

Anthropic prompt caching, Gemini context caching 같은 기능이 나오면서:

- 자주 쓰는 큰 문서(메뉴얼, 정책)는 **캐시에 상주**시키고

- 나머지 관련 문서는 RAG로 동적으로 끌어오는

**하이브리드 전략**이 2025년 주류가 되어간다. Anthropic 캐시는 5분 TTL(기본), 1시간(확장)이므로 활성 세션에서만 효과가 크다.

8장 · 실전 RAG 아키텍처 해부

8.1 Notion AI

Notion은 수천만 워크스페이스의 페이지를 다룬다. 공개된 엔지니어링 블로그·컨퍼런스 토크 기반 추정:

- **Postgres + pgvector** 기반으로 추정되는 하이브리드 저장소

- 페이지 블록 단위 청킹(Notion의 블록 모델 그대로)

- 권한 필터가 핵심: 쿼리할 때 `user_id`와 페이지 ACL을 필터에 명시

- Rerank 단계에서 "최근 수정", "내가 소유", "팀 공유" 시그널 가중치

**교훈**: 엔터프라이즈 RAG의 진짜 난제는 "벡터 검색 품질"이 아니라 **권한과 멀티테넌시**다.

8.2 Claude Projects / Claude.ai Search

Anthropic의 Projects 기능은:

- 사용자가 업로드한 문서를 프로젝트 단위 컨텍스트로

- 작은 프로젝트는 그냥 Long context에 전부 주입 (캐시 활용)

- 큰 프로젝트는 내부 검색으로 relevant chunk만

**교훈**: 규모에 따라 RAG를 껐다 켰다 한다. 일정 규모 이하면 검색 인덱스 만드는 비용조차 아깝다.

8.3 Perplexity

웹 검색 특화 RAG. 특징:

- 실시간 웹 검색 (Bing/Google API 혹은 자체 크롤) + 벡터 재정렬

- 결과 페이지를 즉시 요약·임베딩해서 질의에 맞는 조각만 추출

- 출처 인라인 인용 (`[1]`, `[2]`) 포맷 고정 — Fine-tuned 모델일 가능성 높음

**교훈**: "검색 엔진 + LLM"은 단순한 조합이 아니라, **검색 결과 품질에 특화된 후처리·인용·갱신 시스템**이 전부를 결정한다.

8.4 Glean, Elastic AI Assistant (엔터프라이즈)

사내 SaaS(Google Workspace, Slack, Jira, Confluence, GitHub)를 Connect해서 통합 검색 + LLM 답변.

- 커넥터별 크롤/동기화 파이프라인

- 권한 매핑(사용자 ↔ 원본 시스템의 ACL)이 가장 어려운 부분

- Rerank에서 "최근성", "저자 신뢰도", "해당 팀" 시그널

**교훈**: 엔터프라이즈 RAG의 엔지니어링 예산의 60–70%는 **커넥터, 동기화, 권한**에 들어간다. 검색 품질 튜닝은 나머지.

9장 · 한국어 RAG의 특수성

9.1 토큰 효율

- OpenAI tokenizer 기준 한국어는 영어보다 토큰을 1.5–2배 소비

- GPT-4o·Claude 3.5/4의 개선된 한국어 토크나이저가 상황을 크게 개선

- 그래도 비용·컨텍스트 한도 계산 시 "한국어는 더 들어간다" 전제로

9.2 임베딩 품질

- 영어 최강 모델이 한국어에선 중상위권인 경우가 흔함

- Upstage Solar embedding, Voyage, BGE-m3, Cohere multilingual이 검증된 옵션

- 도메인이 한국어 사내 문서라면 작은 오픈 모델 파인튜닝 + Cohere Rerank 조합이 가성비 좋음

9.3 전처리

- 한국어 OCR 품질 검증 필수 (PDF가 많다면)

- 줄바꿈·공백 정규화, 숫자/영어 혼용 처리 규칙 명확히

- 존댓말/반말 혼재: 임베딩엔 영향 적으나 생성 단계 프롬프트에선 톤 가이드 필수

9.4 현지 제품/용어

- 대한민국 고유 용어, 조직명, 법령명 등은 약어 사전(dictionary)을 만들어 BM25 강화

- 벡터만 믿으면 "국민연금"과 "국민건강보험"을 헷갈릴 수 있다 → Hybrid가 훨씬 안전

10장 · 평가(Evaluation) — "숫자 없는 RAG 개선은 미신"

"뭔가 좋아진 것 같아요"는 평가가 아니다.

10.1 평가 레이어 3가지

**(1) Retrieval 평가** (재료가 맞았는가)

- Hit@k, MRR, NDCG@k

- 정답 문서(또는 문서 집합) 라벨이 필요

**(2) Generation 평가** (요리가 맞았는가)

- Faithfulness: 답변이 검색된 문서 내용에 충실한가

- Answer Relevancy: 질문에 실제로 답했는가

- Context Relevancy: 불필요한 문서가 덜 딸려왔는가

**(3) End-to-end 평가** (손님이 만족했는가)

- 사람 라벨러, 또는 LLM-as-a-judge

- 현업 사용 로그에서 "유용했다" 클릭률 등

10.2 도구

- **RAGAS**: 오픈, Faithfulness·Answer Relevancy 등 자동 평가

- **TruLens**: 관측성 + 평가

- **LangSmith / LangFuse / Phoenix (Arize)**: 전체 트레이스 + 평가

10.3 평가셋 만들기

처음엔 100–300개면 충분하다. 만드는 법:

1. 실제 유저 질의 로그에서 샘플링(또는 도메인 전문가가 작성)

2. 각 질의에 대해 정답 문서(들)와 "이 답변이면 OK" 기준 답변 작성

3. 애매한 질의(답이 여러 개)는 라벨러 간 일치도(Kappa) 측정

**평가셋 없이 RAG 튜닝은 곧바로 미신이 된다.** 회고 때 "왜 좋아졌는지 설명 못 함" → 다음 회귀 때 원인 불명 → 팀 피로.

11장 · 운영 — 비용, 지연시간, 관측성

11.1 비용 프로파일

일반적인 질의 하나의 비용 구성(예: 사내 지식 봇, 2025년 중반 가격 기준):

| 항목 | 추정 비용 |

|------|-----------|

| 쿼리 임베딩 1회 | 거의 0 |

| 벡터 검색 | 인프라 비용(고정) |

| Rerank (50개) | $0.0005–$0.002 |

| 컨텍스트 3–5K 토큰 + LLM 생성 1K | $0.005–$0.05 |

| **합계 (질의당)** | **$0.01–$0.06** 수준 |

월 100만 질의 = $1–6만. Fine-tuning 한 번과 비슷하거나 더 싼데 지식 최신성까지 얻는다.

11.2 지연시간 버짓

사용자는 3초 안에 "뭔가 시작되어야" 만족한다. 버짓 예시:

검색: 100ms

Rerank: 200ms

LLM TTFT(첫 토큰): 500ms

스트리밍 시작: 800ms 누적 ← 여기가 체감 지점

전체 완료: 3–5초

최적화 포인트:

- 임베딩·검색은 캐싱 (자주 묻는 질문)

- Rerank를 비동기로 시작 (스트리밍 중단 없이)

- 프리필 긴 경우 Context caching 활용

11.3 관측성

필수 로그:

- 쿼리, 재작성된 쿼리들

- 검색된 top-k 문서 ID + 점수

- Rerank 후 선택된 문서

- 최종 프롬프트(길이 기준), LLM 응답

- 사용자 피드백(thumbs up/down)

**이 로그가 있어야 나중에 "왜 이상한 답을 했지?"를 디버그할 수 있다.** LangFuse, Langsmith, Phoenix 중 하나는 처음부터 붙여라.

11.4 장애 시나리오

- 임베딩 API 장애 → 캐시된 임베딩만 사용, 실시간 인덱싱 일시 큐잉

- 벡터 DB 장애 → BM25 검색 단독 모드로 폴백

- LLM 장애 → "원문을 그대로 보여주고 '검색 결과' 모드로" 폴백

**가용성이 답변 정확도보다 먼저다.** "답을 못 주면 제품이 사라진다."

12장 · Agentic RAG — 2025년의 새 경계

12.1 단일 검색의 한계

복잡한 질의는 한 번의 검색으로 안 풀린다. "우리 회사 2024년 3분기 매출을 작년 동기와 비교해서 분석해줘"는:

- 2024 Q3 매출 → 검색 1

- 2023 Q3 매출 → 검색 2

- 비교 및 분석 → LLM 추론

12.2 Agentic RAG 패턴

- **ReAct**: Reasoning + Acting. "생각 → 툴 호출 → 관찰 → 생각" 반복

- **Plan-and-Execute**: 먼저 계획 세우고, 각 단계 실행

- **Self-RAG**: 모델이 스스로 "지금 검색이 필요한가?"를 판단

구현 스택: LangGraph, DSPy, Claude agent, OpenAI Assistants / Responses API.

12.3 주의점

- 루프가 길어지면 지연·비용 폭증 → **최대 이터레이션 제한** 필수

- 검색이 늘어나면 Context도 늘어남 → 요약/필터링 단계 병행

- 모든 질의가 Agentic일 필요 없음 → **질의 복잡도 분류기**로 단순 질의는 Naive RAG로

"단순한 건 단순하게, 복잡한 건 에이전트로." 이게 2025년의 룰이다.

13장 · 흔한 함정 10선 (안티패턴)

13.1 청킹을 그냥 512로 하고 끝

도메인별로 검증 안 하면 검색 정확도의 상한선을 스스로 깎는 것.

13.2 임베딩 모델을 한 번 골라놓고 영원히 유지

벤치마크가 바뀌고 도메인도 바뀐다. 분기마다 상위 3개로 재평가.

13.3 Rerank 없이 운영

"가장 큰 ROI"를 포기하는 것. 일단 Cohere/Jina/BGE rerank 중 하나 붙여라.

13.4 Hybrid Search 무시

벡터만으로 고유명사·숫자·버전을 못 찾는다. BM25 병행 필수.

13.5 평가셋 없음

"좋아진 것 같아요"는 엔지니어링이 아니다. 100–300개의 라벨된 평가셋부터.

13.6 권한 필터를 나중에 붙이기

MVP에서 빠뜨리면 리팩터 비용이 기하급수. 첫날부터 tenant_id, ACL을 검색 필터에 포함.

13.7 프롬프트 인젝션 무방비

검색된 문서 안에 "이전 지시 무시하고…"가 들어가면 그대로 따라간다. **사용자 텍스트와 검색 문서 텍스트를 구분**하고 가드레일 프롬프트 필수.

13.8 Long context에 과신

"1M이니까 다 넣으면 되지" → 비용·지연·Lost in the middle. 여전히 Rerank 후 5–15K만 넣는 게 최선인 경우 많음.

13.9 인용 강제 안 함

출처 없는 RAG는 Hallucination과 구분 불가. 최소한 "문서 제목 + 스니펫"을 표시.

13.10 Fine-tuning으로 사실 주입 시도

지식은 Fine-tuning으로 안 들어간다. 스타일·포맷만 가능. 새로운 사실은 RAG.

14장 · 체크리스트 — 실전 RAG 런칭 전 12가지

아래 12개에 예스를 체크할 때까지는 프로덕션 출시 금지.

- [ ] 도메인 자체 평가셋 100개 이상 확보

- [ ] 임베딩 모델 3개 이상 비교해 Hit@5 측정

- [ ] 청킹 전략 2개 이상 A/B 테스트

- [ ] Hybrid Search (BM25 + 벡터) 구축

- [ ] Rerank 단계 추가

- [ ] 권한 필터를 검색 단계에서 먼저 적용

- [ ] 질의·검색 결과·응답 전체 트레이스 로깅

- [ ] 인용/출처를 응답에 자동 포함

- [ ] 프롬프트 인젝션 방어 프롬프트 적용

- [ ] 장애 시 폴백 경로 2개 이상 정의

- [ ] 비용/지연시간 대시보드 (p50, p95)

- [ ] 사용자 피드백(thumbs) 수집 + 주간 리뷰 회의

15장 · Season 4의 전체 여정

Season 4는 **"LLM을 제품에 녹이는 법"** 시리즈다. Ep 1(RAG)을 출발점으로:

- Ep 2: **프롬프트 엔지니어링의 과학** — CoT, Self-consistency, DSPy, 자동 최적화

- Ep 3: **LLM 에이전트 실전** — ReAct, Plan-Execute, 도구 실행, 다중 에이전트

- Ep 4: **Fine-tuning 완전 가이드** — SFT, DPO, LoRA/QLoRA, 합성 데이터

- Ep 5: **MCP (Model Context Protocol) 완전 해부**

- Ep 6: **LLM 평가 & 관측성** — Eval harness, LLM-as-judge, 회귀 방지

- Ep 7: **로컬 LLM 시대** — Llama, Qwen, Mistral, vLLM, 하드웨어

- Ep 8: **멀티모달** — Vision, Audio, 문서 이해

- Ep 9: **Voice AI** — STT, TTS, 실시간 파이프라인

- Ep 10: **LLM 보안** — 인젝션, 탈옥, 데이터 누출, Red team

- Ep 11: **LLMOps** — 배포, 버전 관리, 카나리, 비용 통제

- Ep 12: **AI 제품 디자인** — UX, 피드백 루프, 온보딩

- Ep 13: **생성형 AI 시대의 비즈니스 모델**

검색을 먼저 이해해야, 에이전트·평가·운영이 의미가 있다. 그래서 Ep 1은 RAG.

16장 · 다음 글 예고 — Season 4 Ep 2: "프롬프트 엔지니어링의 과학"

RAG가 "무엇을 보여줄까"의 문제라면, 프롬프트는 "어떻게 지시할까"의 문제다.

Season 4 Ep 2에서는:

- Chain-of-Thought, Self-consistency, Tree-of-Thoughts

- Few-shot 선택의 과학 (유사도 검색 기반 few-shot)

- Structured Output (JSON mode, Tool use, Pydantic)

- System / User / Assistant 메시지 설계

- 프롬프트 자동 최적화 (DSPy, TextGrad, APO)

- 프롬프트 버저닝과 CI

- 모델별 프롬프트 이관 (GPT → Claude → Gemini)

- 프롬프트 캐싱 전략

- 한국어 프롬프트의 특수성

- 실무 안티패턴 10선

**"RAG로 재료를 잘 모아도, 프롬프트가 시원찮으면 결과는 평범하다."** 검색과 지시, 두 축이 모두 날카로워야 제품이 날아오른다.

다음 글에서 만나자.

> **요약**: RAG는 죽지 않았다. 2025년의 RAG는 단일 검색이 아니라 **Hybrid + Rerank + Query Rewrite + 조건부 Agentic**이 세트다. 임베딩 모델은 도메인별로 평가하고, 청킹은 문서 구조를 살리고, 벡터 DB는 규모에 맞게 pgvector에서 시작해 필요할 때 확장하며, 권한·인용·관측성을 첫날부터 설계에 넣는다. Fine-tuning은 스타일, RAG는 지식, Prompt는 지시 — 세 축의 역할을 헷갈리지 말 것. 그리고 평가셋 없는 RAG 개선은 미신이다.