LabHub

블로그

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

2026-04-15 · 33 분 읽기 · #rag#llm#ai#vector-db#embedding#fine-tuning#deep-dive#series

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의 근본 문제는 세 가지다.

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

간단한 수식으로:

기본 LLM:    answer = LLM(prompt)
RAG:        docs   = Retriever(query, corpus)
            answer = LLM(prompt + docs)

1.2 RAG의 3세대

세대시기특징대표 스택
Naive RAG2022–2023단일 임베딩 → 단일 검색 → 생성LangChain + FAISS + OpenAI
Advanced RAG2023–2024Rerank, Hybrid, Query RewriteLangChain/LlamaIndex + Cohere Rerank + pgvector
Modular/Agentic RAG2024–2025툴 선택, 반복 검색, 검증 루프LangGraph, DSPy, Claude agent

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 토큰)
OpenAI text-embedding-3-large3072 (축소 가능)균형 좋음, Matryoshka$0.13
OpenAI text-embedding-3-small1536 (축소 가능)저렴하고 빠름$0.02
Cohere embed-v3 (english/multilingual)1024Rerank와 세트로 강력$0.10
Voyage voyage-31024코드/한국어도 준수$0.06
BGE-m3 (오픈소스)1024한국어 포함 다국어, 자체 호스팅전력비만
Upstage Solar embedding4096한국어 특화, 한국어 벤치 톱권별도
KURE / KO-SRoBERTa 등다양한국어 오픈전력비만

2.3 선택 기준

문서가 주로 한국어인가?

예산이 타이트한가?

데이터 유출 리스크?

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

(3) Semantic chunking

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

(5) Late chunking (2024 신기법)

3.3 실전 템플릿

기술 문서(Markdown):

def chunk_markdown(md: str):
    # 1) 헤더 H1/H2 기준으로 섹션 분리
    # 2) 섹션이 1500토큰 초과하면 recursive split
    # 3) 각 청크 앞에 상위 헤더 패스 붙이기 ("헤더 엔리치먼트")
    ...

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

3.4 한국어 청킹 주의점

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

4.1 주요 옵션 비교

DB형태강점약점추천 규모
pgvectorPostgres 확장기존 RDBMS와 통합, 트랜잭션수억 벡터 이상 어려움소–중
PineconeSaaS관리 부담 제로, 매니지드락인, 비용중–대
Weaviate오픈+SaaSGraphQL, 스키마 풍부운영 복잡중
QdrantRust 기반 OSS빠르고 필터링 강력생태계 중간중–대
Milvus대규모 전용샤딩, 빌리언 스케일운영 무거움대–초대
ChromaDB임베디드/서버로컬 개발 편함프로덕션 기능 약함프로토타입
Elasticsearch (dense_vector)풀텍스트+벡터Hybrid 내장, 운영 친숙벡터 전용 대비 느릴 수 있음중
OpenSearch k-NNAWS 기반관리 및 Hybrid 내장튜닝 필요중–대

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

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

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

4.3 대규모 옵션 선택

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

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

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

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

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

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

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:

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

5.4 Query Rewrite

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

패턴들:

실전에서는 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 바꾸는 것

7.2 바꾸지 않는 것

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

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

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

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

8.1 Notion AI

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

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

8.2 Claude Projects / Claude.ai Search

Anthropic의 Projects 기능은:

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

8.3 Perplexity

웹 검색 특화 RAG. 특징:

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

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

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

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

9장 · 한국어 RAG의 특수성

9.1 토큰 효율

9.2 임베딩 품질

9.3 전처리

9.4 현지 제품/용어

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

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

10.1 평가 레이어 3가지

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

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

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

10.2 도구

10.3 평가셋 만들기

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

  1. 실제 유저 질의 로그에서 샘플링(또는 도메인 전문가가 작성)
  2. 각 질의에 대해 정답 문서(들)와 "이 답변이면 OK" 기준 답변 작성
  3. 애매한 질의(답이 여러 개)는 라벨러 간 일치도(Kappa) 측정

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

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

11.1 비용 프로파일

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

항목추정 비용
쿼리 임베딩 1회거의 0
벡터 검색인프라 비용(고정)
Rerank (50개)0.0005–0.0005–0.002
컨텍스트 3–5K 토큰 + LLM 생성 1K0.005–0.005–0.05
합계 (질의당)0.01–0.01–0.06 수준

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

11.2 지연시간 버짓

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

검색: 100ms
Rerank: 200ms
LLM TTFT(첫 토큰): 500ms
스트리밍 시작: 800ms 누적    ← 여기가 체감 지점
전체 완료: 3–5초

최적화 포인트:

11.3 관측성

필수 로그:

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

11.4 장애 시나리오

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

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

12.1 단일 검색의 한계

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

12.2 Agentic RAG 패턴

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

12.3 주의점

"단순한 건 단순하게, 복잡한 건 에이전트로." 이게 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개에 예스를 체크할 때까지는 프로덕션 출시 금지.

15장 · Season 4의 전체 여정

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

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

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

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

Season 4 Ep 2에서는:

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

다음 글에서 만나자.

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

원문 보기: https://www.youngju.dev/blog/culture/2026-04-15-rag-practical-complete-guide-retrieval-embedding-vector-db-finetuning-boundary-deep-dive-guide-2025

댓글

아직 댓글이 없습니다.

로그인하면 댓글을 쓸 수 있습니다