- Published on
RAG 개념 정리 (1) — 파이프라인 기본기: 청킹, 임베딩, 벡터 DB
- Authors
- Name
- junyeol kim
챗봇을 만들면서 RAG를 계속 써왔는데, 막상 "RAG가 뭔데?"라고 물으면 랭체인이랑 벡터 검색 정도로만 뭉뚱그려 설명하게 되더라고요. 그래서 개념부터 제대로 정리해보기로 했습니다. 시리즈 첫 편은 파이프라인 전체 구조와, 그중에서도 결과물 품질을 가장 크게 좌우하는 청킹·임베딩·벡터 DB 세 가지입니다.
🔄 RAG 파이프라인, 두 갈래로 나눠보기
RAG는 사실 파이프라인이 두 개입니다. 미리 준비해두는 인덱싱 파이프라인과, 질문이 들어올 때마다 도는 쿼리 파이프라인이죠.
인덱싱 파이프라인 (사전 준비, 배치로 미리 돌림)
원본 문서 → 청킹(chunking) → 임베딩(embedding) → 벡터 DB에 저장
쿼리 파이프라인 (사용자 질문마다 실시간으로 돔)
질문 → 질문 벡터화 → 벡터 DB에서 유사 청크 검색 → 검색된 청크를 프롬프트에 조합 → LLM이 답변 생성
문제는 여기서 이미 시작됩니다. "문서를 자르고, 임베딩하고, top-k개 검색해서, 그대로 프롬프트에 넣는" 가장 단순한 형태는 데모로는 잘 돌아가지만, 실무 데이터로 넘어가는 순간 청킹 과정에서 문맥이 잘려서 엉뚱한 청크가 검색되는 문제가 바로 터집니다. Vectara가 NAACL 2025에서 25가지 청킹 설정과 48개 임베딩 모델을 조합해 테스트한 결과, 청킹 설정이 검색 품질에 미치는 영향이 임베딩 모델 선택 못지않게 크다는 게 확인됐습니다. 즉 "일단 좋은 임베딩 모델부터 쓰자"가 아니라 청킹부터 제대로 봐야 한다는 뜻입니다.
✂️ 청킹 전략 7가지
| 전략 | 방식 | 적합한 상황 | 주의점 |
|---|---|---|---|
| 고정 크기 | 512토큰 등 균일하게 자르고 오버랩 추가 | 구조 없는 로그 파일 | 의미 경계 무시, 문맥 훼손 |
| 문장-윈도우 | 문장 단위로 임베딩, 검색 시 주변 문장 확장 반환 | 의료·법률처럼 밀집된 사실 | 중복 제거 필요 |
| 구조-인식 | 마크다운 헤더·DOM 경계로 분할, 상위 계층을 메타데이터로 | 기업 문서, API 문서, 계약서 | 청크 크기가 들쭉날쭉 |
| 의미적(semantic) | 문장 간 임베딩 유사도가 임계값 아래로 떨어지는 지점에서 경계 설정 | 회의록, 음성 전사, 장문 텍스트 | 인덱싱 비용·지연 증가 |
| 계층적 | 256/1024토큰 등 여러 크기를 계층으로 연결 | 질문 범위가 넓게 요동치는 경우 | 부모-자식 관계 관리 복잡 |
| LLM 기반 명제 청킹 | LLM이 읽고 원자적 명제 단위로 추출 | 비동기 배치, 고가치 비정형 데이터 | 비결정적, 환각 위험 |
| 멀티모달 | 표·차트를 텍스트에서 분리해 요약으로 임베딩, 원본은 별도 보존 | 재무 보고서, 논문처럼 표가 많은 문서 | 표와 주변 텍스트 연결 손실 위험 |
대부분의 프로덕션 환경에는 재귀적(recursive) 청킹이 기본값으로 권장됩니다. 문단 경계를 존중하면서도 구현이 단순해서 비용 대비 효과가 가장 좋기 때문입니다. FloTorch가 2026년 2월 50개 논문으로 진행한 벤치마크에서는 512토큰 + 50~100토큰 오버랩 조합이 종단 정확도 69%로 가장 무난한 기본값으로 나타났습니다. 다만 이후 2026년 1월 SPLADE+Mistral-8B로 진행된 별도 분석에서는 "오버랩이 검색 품질에 측정 가능한 이점을 주지 못하고 인덱싱 비용만 늘렸다"는 상반된 결과도 나왔습니다 — 오버랩은 만능이 아니라 데이터셋에 따라 다르니 직접 측정해보는 게 안전합니다.
기술 문서처럼 계층이 뚜렷한 데이터라면 부모-자식 청킹도 실전에서 자주 씁니다. 부모 청크 2,000토큰, 자식 청크 400토큰(오버랩 50토큰)으로 나누면, 검색은 작은 자식 청크로 정밀하게 하고 LLM에는 부모 청크를 통째로 넘겨 충분한 맥락을 확보하는 식입니다.
🧬 임베딩 모델, 뭘 기준으로 고를까
임베딩 모델은 MTEB 평균 점수, 가격, 다국어 지원 세 가지를 같이 봐야 합니다.
| 모델 | MTEB 평균 | 특징 |
|---|---|---|
| OpenAI text-embedding-3-small | - | $0.02/1M 토큰, 저예산에 적합 |
| BGE-M3 | 66.1 | 100개 이상 언어 지원 |
| E5-mistral | 66.6 | 오픈소스, 고성능 |
| Cohere embed-v3 | - | $0.10/1M 토큰, 100개 이상 언어 |
일반적으로 MTEB 평균 66점 이상을 기준선으로 삼는 게 실무에서 통용됩니다. 다국어 챗봇이면 BGE-M3나 Cohere embed-v3처럼 다국어 지원이 명시된 모델을 우선 고려하는 게 좋고, 비용이 민감하면 저렴한 모델로 먼저 붙여보고 리랭킹 단계에서 정확도를 보완하는 전략도 흔히 씁니다.
🗄️ 벡터 DB, 규모와 하이브리드 지원으로 갈린다
| 규모 | 추천 | 비고 |
|---|---|---|
| 수백만 벡터 | Chroma | 인메모리, 하이브리드 검색 미지원 |
| 수십억 벡터 | Pinecone, Milvus, Qdrant | 확장성 우선 |
비용 차이도 꽤 큽니다. 100만 벡터 기준 Pinecone은 월 70달러 선인 반면, Milvus·Qdrant를 자체 호스팅하면 인프라 비용만 듭니다. 대신 자체 호스팅은 운영 부담이 그대로 팀으로 넘어오니 트레이드오프입니다.
챗봇이라면 키워드 검색(BM25)과 벡터 검색을 같이 쓰는 하이브리드 서치를 염두에 두는 게 좋은데, 이때 벡터 DB가 Sparse+Dense를 둘 다 지원하는지가 선택 기준에 들어갑니다. Qdrant와 Pinecone은 둘 다 지원하고, Weaviate는 BM25+Dense 조합을 지원하지만, Chroma는 하이브리드 검색 자체를 지원하지 않습니다. 다음 편에서 다룰 하이브리드 서치·리랭킹을 미리 계획하고 있다면 이 지점에서 DB 선택이 갈립니다.
📚 정리
- RAG는 인덱싱 파이프라인(사전 준비)과 쿼리 파이프라인(실시간)이 분리된 두 개의 흐름
- 청킹이 임베딩 모델 선택 못지않게 검색 품질을 좌우함 (Vectara NAACL 2025) — 재귀적 청킹이 기본값, 계층적 문서면 부모-자식 청킹(2000/400/50) 고려
- 청킹 오버랩은 만능이 아님 — 데이터셋에 따라 도움이 안 될 수도 있으니 직접 측정 필요
- 임베딩 모델은 MTEB 66점 이상을 기준선으로, 다국어 여부와 가격을 같이 고려
- 벡터 DB는 규모(수백만 vs 수십억)와 하이브리드 검색 지원 여부로 선택 — Chroma는 하이브리드 미지원이라 나중에 발목 잡힐 수 있음
다음 편은 검색 정확도를 올리는 하이브리드 서치·리랭킹·쿼리 재작성을 다룰 예정입니다.
참고: Vectara 「NAACL 2025 청킹 벤치마크」, MachineLearningMastery 「7 Chunking Strategies That Decide Whether Your RAG Works」, Chaos and Order 「RAG 파이프라인 프로덕션 구축 가이드」