RAG 실전 완전 가이드: 검색, 임베딩, 벡터 DB, Fine-tuning의 경계 (2025)

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는 죽었다"는 소리가 매년 나오는 이유
• 1장 · RAG의 기본 원리와 진화
  • 1.1 왜 RAG인가
  • 1.2 RAG의 3세대
  • 1.3 전체 파이프라인
• 2장 · 임베딩 모델 선택
  • 2.1 임베딩이란
  • 2.2 주요 임베딩 모델 2025
  • 2.3 선택 기준
  • 2.4 벤치마크만 믿지 마라
• 3장 · 청킹 전략 — "쪼개는 법이 RAG를 결정한다"
  • 3.1 청크 크기의 트레이드오프
  • 3.2 청킹 전략 5가지
  • 3.3 실전 템플릿
  • 3.4 한국어 청킹 주의점
• 4장 · 벡터 DB 선택 완전 가이드
  • 4.1 주요 옵션 비교
  • 4.2 pgvector가 2025년에 다시 주목받는 이유
  • 4.3 대규모 옵션 선택
  • 4.4 인덱스 알고리즘: HNSW vs IVF
• 5장 · 검색 품질 — Hybrid, Rerank, Query Rewrite
  • 5.1 왜 순수 벡터 검색은 부족한가
  • 5.2 Hybrid Search
  • 5.3 Rerank — 2단계 검색의 위력
  • 5.4 Query Rewrite
• 6장 · Fine-tuning vs RAG vs Prompt Engineering — 언제 뭘 쓰나
  • 6.1 3개의 경계선
  • 6.2 오해들
  • 6.3 조합이 정답
• 7장 · Long Context가 바꾸는 것, 바꾸지 않는 것
  • 7.1 바꾸는 것
  • 7.2 바꾸지 않는 것
  • 7.3 새로운 패턴: "Context Caching + RAG"
• 8장 · 실전 RAG 아키텍처 해부
  • 8.1 Notion AI
  • 8.2 Claude Projects / Claude.ai Search
  • 8.3 Perplexity
  • 8.4 Glean, Elastic AI Assistant (엔터프라이즈)
• 9장 · 한국어 RAG의 특수성
  • 9.1 토큰 효율
  • 9.2 임베딩 품질
  • 9.3 전처리
  • 9.4 현지 제품/용어
• 10장 · 평가(Evaluation) — "숫자 없는 RAG 개선은 미신"
  • 10.1 평가 레이어 3가지
  • 10.2 도구
  • 10.3 평가셋 만들기
• 11장 · 운영 — 비용, 지연시간, 관측성
  • 11.1 비용 프로파일
  • 11.2 지연시간 버짓
  • 11.3 관측성
  • 11.4 장애 시나리오
• 12장 · Agentic RAG — 2025년의 새 경계
  • 12.1 단일 검색의 한계
  • 12.2 Agentic RAG 패턴
  • 12.3 주의점
• 13장 · 흔한 함정 10선 (안티패턴)
  • 13.1 청킹을 그냥 512로 하고 끝
  • 13.2 임베딩 모델을 한 번 골라놓고 영원히 유지
  • 13.3 Rerank 없이 운영
  • 13.4 Hybrid Search 무시
  • 13.5 평가셋 없음
  • 13.6 권한 필터를 나중에 붙이기
  • 13.7 프롬프트 인젝션 무방비
  • 13.8 Long context에 과신
  • 13.9 인용 강제 안 함
  • 13.10 Fine-tuning으로 사실 주입 시도
• 14장 · 체크리스트 — 실전 RAG 런칭 전 12가지
• 15장 · Season 4의 전체 여정
• 16장 · 다음 글 예고 — Season 4 Ep 2: "프롬프트 엔지니어링의 과학"

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

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 주요 옵션 비교

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개의 경계선

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년 중반 가격 기준):

월 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 개선은 미신이다.