웹 개발자를 위한 RAG 기초(0) - RAG 관련 용어, 관련 기술 스펙, POC진행시 참고할만한 용어 및 비교표 등 정리)

안녕하세요! 갓대희 입니다. :- )
이번 글은 내 블로그에서 거의 없었던 용어 정리글이다.

 
갑자기 외부 교육을 5주간 진행하게 되었다.
사실 지금까지 내가 하던 업무는 AI와는 전혀 상관없는 일이었다. 그런데 갑자기 회사에서 AI 쪽으로 업무가 엮이게 되면서 AI 전문가들과 대화할 일이 생기고, 구성원들간의 논의할 일도 많아졌다.
 
그동안은 혼자서 AI 공부하고 블로그 쓰는 게 전부였다. AI 관련해서 다른 사람들과 대화하는 경우가 거의 없었다. 회사에서도 AI와는 담을 쌓고 있었는데, 갑자기 AI 쪽으로 업무를 접목시키려다보니 자연스럽게 AI 관련 회의도 하게 됐다.
 
느낀 점은 이거다. AI 분야는 다른 업무와 달리 개개인의 눈높이가 정말 다르다. 빠르게 나아간 사람들도 있고, 이제 시작하는 사람들도 있다. 관심 분야도 가지각색이고, 다양한 곳에서 AI를 써오다보니 배경지식이 천차만별이었다. 나 역시 AI 분야에서는 완전 혼자만의 세계에 있었다고 봐야겠다.
 
팀 과제를 진행하다보니 이런 눈높이 차이가 생각보다 발목을 잡을 것 같았다. 컨센서스를 맞추지 않으면 진도가 나가지 못한다. 따로 놀거나 방치되는 사람이 생기기 마련이다.
 
그래서 이번에는 이런 눈높이를 맞추기 위해 용어 정리부터 시작해서 배경지식이 될 만한 내용들을 5주간 지속적으로 정리해보려고 한다.
 
이 페이지는 생각날때마다 참고 하기위해 만들어놓은 글이며, 실제 개념이해에서 부터 실습과정은 하기 링크에서부터 출발할 예정이다.
2025.08.31 - [AI/Rag(with 202509 AWS교육)] - 웹 개발자를 위한 RAG 기초(1) - Naive RAG 이론(Rag란? Rag 기초, RAG 예시, RAG 챗봇 설계)
 

기본 용어

제로샷(Zero-shot)

정의: 예시(example) 없이 LLM이 문제를 바로 푸는 방식

왜 중요한가: 추가 학습이나 예시 없이도 일반화 능력을 시험·활용

실제 예시: "월간 매출 추세 요약해줘"만 주고도 적절한 분석 텍스트 생성

원샷/퓨샷(One-shot/Few-shot)

정의: 1개(원샷) 또는 소수(퓨샷)의 예시를 프롬프트에 포함시키는 기법

왜 중요한가: 모델의 출력 포맷·톤을 안정화

실제 예시: 원하는 SQL 스타일 예시 2~3개를 함께 제공해 유사한 SQL을 유도

프롬프트(Prompt)

정의: LLM에 주는 입력(지시문+컨텍스트)

왜 중요한가: 모델 동작을 거의 전부 좌우

실제 예시: 역할(assistant role), 제약(guardrails), 출력 포맷(JSON/SQL)을 명시

 

데이터 준비 단계 용어

인덱싱(Indexing)

정의: 문서/스키마를 검색 가능한 구조(역색인·벡터)로 만들어 저장

종류: Sparse(단어 기반), Dense(임베딩 기반), Hybrid(둘 다)

활용 방법 : 메타데이터(출처 URL, 날짜, 태그)도 함께 저장해 필터링을 용이하게 하세요

청킹(Chunking)

정의: 긴 문서를 일정 크기의 조각(chunk)으로 나누는 전처리

왜 중요한가: 검색 정밀도·컨텍스트 품질 직결

활용 방법 : 의미 단위(제목·문단) 기반 가변 크기, 오버랩(Overlap)으로 문맥 손실 완화

청킹 저품질 예시)
처음에는 무조건 512토큰으로 자르다가 맥락이 끊어지는 문제를 겪었다. 지금은 문단이나 제목을 기준으로 의미 단위로 나누고, 앞뒤 50토큰 정도 겹치게(overlap) 해서 문맥 손실을 최소화한다.

임베딩(Embedding)

정의: 텍스트/스키마를 고차원 벡터(숫자 배열)로 변환한 표현

왜 중요한가: 의미 기반 유사도 검색(코사인/내적)을 가능케 함

 

검색 기법 용어들

Sparse 검색 (BM25 등)	단어 빈도 기반 역색인	빠르고 해석 가능	패러프레이즈 약함
Dense 검색 (임베딩 기반)	의미 벡터 유사도	의미 이해 강함	메모리/비용 증가
하이브리드 (Hybrid)	Sparse+Dense 결합	최고 성능	복잡성 증가

실무에서 검증된 조합
BM25 + E5(임베딩 모델) + RRF(순위 융합) 조합이 꽤나 안정적이다. 키워드 매칭의 정확성과 의미 이해의 장점을 모두 가져갈 수 있어서 실무에서 많이 쓰인다.

 

검색 알고리즘 용어들

BM25 (Best Matching 25)

정의: 문서의 관련성을 점수로 매기는 확률적 랭킹 함수

왜 중요한가: 키워드 기반 검색의 표준, Elasticsearch의 기본 알고리즘

실제 작동: 단어 빈도 + 문서 길이 + 전체 말뭉치에서의 희귀도를 종합 계산

활용 방법: 제목이나 첫 문단에 있는 키워드에 더 높은 가중치 부여 가능

TF-IDF (Term Frequency-Inverse Document Frequency)

정의: 단어의 중요도를 측정하는 통계적 수치

계산 방법: (해당 문서에서 단어 빈도) × (전체에서 그 단어가 나오는 문서 수의 역수)

실제 예시: "AI"라는 단어가 한 문서에 많이 나오지만 전체 문서에서도 흔하다면 중요도 낮음

코사인 유사도 (Cosine Similarity)

정의: 두 벡터 간의 각도를 이용해 유사도를 측정하는 방법

범위: -1 ~ 1 (1에 가까울수록 유사, 0에 가까울수록 무관)

장점: 문서 길이에 영향받지 않음 (정규화 효과)

검색 알고리즘 선택 가이드
• 키워드 정확 매칭 중요: BM25
• 의미 유사성 중요: 코사인 유사도 (임베딩과 함께)
• 문서 분류/클러스터링: TF-IDF
• 최고 성능 원함: 하이브리드 (BM25 + 임베딩)

 

데이터 처리 관련 용어

토큰화 (Tokenization)

정의: 텍스트를 의미있는 최소 단위로 분해하는 과정

종류: 단어 단위, 문자 단위, 서브워드 단위 (BPE, WordPiece)

실제 예시: "안녕하세요" → ["안녕", "하세요"] 또는 ["안녕하세", "##요"]

한국어 특징: 교착어 특성상 형태소 분석기 (KoNLPy, Kiwi) 활용 필수

불용어 (Stop Words)

정의: 검색에 도움이 되지 않아 제거하는 단어들

한국어 예시: "은", "는", "이", "가", "를", "에", "의", "와", "과"

영어 예시: "the", "a", "an", "in", "on", "at", "for", "with"

⚠️ 주의: 무작정 제거하면 의미가 달라질 수 있음 ("to be or not to be" → "be be")

정규화 (Normalization)

정의: 텍스트를 일관된 형태로 변환하는 과정

종류: 대소문자 통일, 특수문자 제거, 공백 정리, 인코딩 통일

실제 예시: "AI!!!" → "ai", "　　공백" → " 공백" (전각→반각)

 

성능 평가 핵심 지표

// 성능 지표 실제 계산 예시 ( 보강 필요 / 라가스)

검색 성능 지표 계산 (100개 질문 테스트)

🔸 Precision@5 (정밀도)
상위 5개 결과 중 관련 문서 수 / 5
예시: 관련 문서 3개 → 3/5 = 0.6 (60%)

🔸 Recall@5 (재현율)  
상위 5개 결과 중 관련 문서 수 / 전체 관련 문서 수
예시: 전체 관련 8개 중 3개 찾음 → 3/8 = 0.375 (37.5%)

🔸 MRR (Mean Reciprocal Rank)
첫 번째 정답의 순위 역수의 평균
예시: 정답이 2번째에 있으면 1/2 = 0.5

F1 Score

정의 : 정밀도와 재현율의 조화평균

계산식 : F1 = 2 × (Precision × Recall) / (Precision + Recall)

왜 중요한가 : 정밀도와 재현율의 균형을 한 숫자로 표현

실무 활용: 모델 비교나 하이퍼파라미터 튜닝의 기준 지표로 활용

지연 시간 (Latency)

정의 : 사용자 질문부터 답변 완성까지 소요 시간

측정 단위 : P50, P95, P99 (50%, 95%, 99% 사용자가 경험하는 최대 시간)

일반적 기준 : P95 < 3초, P99 < 5초가 사용자 만족도 기준

 

순위까지 고려하는 고급 지표들

기본 지표로는 한계가 있다. 똑같이 3개를 맞춰도 1,2,3등에 있는 것과 8,9,10등에 있는 건 완전히 다른 의미인데, 이걸 구별하지 못했다. 그래서 순위를 고려하는 지표들을 도입하는 방법도 있다.

NDCG@K 구현 예시

import numpy as np
import math

def dcg_at_k(relevance_scores, k):
    """DCG@K 계산 - 순위가 높을수록 가중치 크게"""
    relevance = np.array(relevance_scores)[:k]
    if relevance.size == 0:
        return 0.0
    
    # DCG = rel_1 + ∑(rel_i / log2(i+1))
    dcg = relevance[0]
    for i in range(1, len(relevance)):
        dcg += relevance[i] / math.log2(i + 2)
    return dcg

def ndcg_at_k(relevance_scores, k):
    """NDCG@K 계산 - 이상적인 순서로 정규화"""
    dcg = dcg_at_k(relevance_scores, k)
    ideal_relevance = sorted(relevance_scores, reverse=True)
    idcg = dcg_at_k(ideal_relevance, k)
    
    if idcg == 0:
        return 0.0
    return dcg / idcg

# 실제 테스트
actual_order = [2, 0, 1, 2, 1]  # 관련도 점수 (0~2)
ndcg_score = ndcg_at_k(actual_order, 5)
print(f"NDCG@5: {ndcg_score:.3f}")  # 0.691

 

지표순위 고려등급별 관련도사용 시점

Precision@K	❌	❌	기본 검증
MRR	✅	❌	첫 정답 중요
NDCG@K	✅	✅	프로덕션

개발 팁
NDCG는 계산이 복잡해 보이지만, scikit-learn에 `ndcg_score` 함수가 있어서 쉽게 쓸 수 있다. 다만 입력 형태가 좀 특이하니 공식 문서를 꼭 확인해보자.

 

Ragas로 RAG 평가하기

검색만 잘하면 되는 게 아니라 생성된 답변의 품질도 중요하고, 실제로 컨텍스트를 얼마나 충실하게 활용했는지도 봐야 한다면, RAG 전용으로 나온 Ragas 프레임워크를 써볼 수도 있다.

Ragas 핵심 메트릭 4개

1. Context Precision : 검색된 컨텍스트의 신호 대 잡음 비율
2. Context Recall : 답변에 필요한 정보를 모두 검색했는지
3. Faithfulness : 생성된 답변이 컨텍스트에 얼마나 충실한지
4. Answer Relevance : 답변이 질문과 얼마나 관련있는지

Ragas 실전 구현

from ragas import evaluate
from ragas.metrics import (
    context_precision,
    context_recall, 
    faithfulness,
    answer_relevancy
)
from datasets import Dataset

# 평가 데이터셋 준비
eval_data = {
    "question": [
        "PyTorch에서 GPU 메모리 부족 에러를 해결하는 방법은?",
        "FastAPI에서 비동기 처리의 장점은 무엇인가요?"
    ],
    "answer": [
        "PyTorch에서 GPU 메모리 부족 시에는 배치 크기를 줄이거나 gradient_accumulation을 사용하고...",
        "FastAPI의 비동기 처리는 I/O 바운드 작업에서 성능 향상을 제공합니다..."
    ],
    "contexts": [
        ["PyTorch GPU 메모리 관리는...", "배치 크기 조정 방법..."],
        ["FastAPI async/await 패턴...", "비동기 성능 벤치마크..."]
    ],
    "ground_truth": [
        "GPU 메모리 부족 시 배치 크기 조정과 gradient accumulation 활용",
        "비동기 처리로 동시 요청 처리 성능 향상"
    ]
}

dataset = Dataset.from_dict(eval_data)

# Ragas 평가 실행
result = evaluate(
    dataset,
    metrics=[context_precision, context_recall, faithfulness, answer_relevancy]
)

print("Ragas 평가 결과:")
for metric, score in result.items():
    print(f"{metric}: {score:.3f}")

# 개별 결과 분석
results_df = result.to_pandas()
print(results_df.head())

 

문제 해결 관련 용어

환각 (Hallucination)

정의: AI가 사실이 아닌 내용을 그럴듯하게 생성하는 현상

RAG에서의 특징: 검색된 문서에 없는 내용을 마치 있는 것처럼 답변

실제 예시: "2023년 삼성 신제품"을 물어봤는데 2024년 제품 정보로 답변

⚠️ 대응 방법: 인용 의무화, 근거 없으면 "모르겠다" 답변 강제

성능 저하 (Degradation)

정의: 시간이 지나면서 모델이나 시스템 성능이 떨어지는 현상

주요 원인: 데이터 변화, 사용자 패턴 변화, 시스템 리소스 부족

실제 사례: 초기 95% 정확도 → 6개월 후 87%로 하락

콜드 스타트 (Cold Start)

정의: 초기 데이터나 사용자 기록이 부족해 성능이 낮은 상태

RAG에서의 의미: 새로운 도메인 도입 시 검색 정확도 낮음

해결 방법: 시드 데이터 확보, 규칙 기반 초기 로직, 점진적 학습

실무에서 겪은 문제들
• 환각: 검색된 문서를 "참고"한다면서 없는 내용 지어냄
• 성능 저하: 처음엔 좋았는데 한 달 뒤 정확도 급락
• 콜드 스타트: 새 카테고리 추가할 때마다 검색 품질 바닥
• 토큰 제한: 컨텍스트가 길어져서 중요한 정보 잘림

 

실무에서 자주 헷갈리는 용어

헷갈리기 쉬운 용어 정리

임베딩 vs 벡터:
임베딩은 변환 "과정", 벡터는 변환된 "결과"

정밀도 vs 정확도:
정밀도는 "찾은 것 중 맞는 비율", 정확도는 "전체 중 맞춘 비율"

토큰 vs 토큰화:
토큰은 "분해된 단위", 토큰화는 "분해하는 과정"

캐싱 vs 인덱싱:
캐싱은 "빠른 재사용", 인덱싱은 "검색 가능하게 정리"

 

RAG 기법 용어

리랭커(Reranker)

정의: 1차 검색 상위 k를 재평가해 최종 순위를 다시 매김

유형: Cross-Encoder(문서+질의를 함께 인코딩), LLM-as-Reranker

효과: 상위 문서 품질 안정화, 환각 억제

HyDE(Hypothetical Document Embeddings)

정의: 실제 문서를 찾기 전, LLM이 가상의 요약/문서를 생성→그 임베딩으로 검색

효과: 초기 정보 부족 시 검색 품질 상승(제로샷 보강)

Self-RAG

정의: 모델이 "검색 필요성·근거 적합성"을 반성 토큰(Reflection Tokens)으로 표시하며 적응적으로 검색·생성

장점: 과·소검색 방지, 인용 정확도 향상

 

평가 지표 용어

핵심 성능 지표

• Recall@k: 정답 문서가 상위 k 결과 중 적어도 하나에 포함될 비율 (누락 방지 관점)
• nDCG@k: 순위에 따른 관련성 점수의 품질 지표 (상위 문서 가중)
• 정확 인용률: 답변의 문장/수치가 실제 근거로 뒷받침되는 비율 (환각 방지)
• 지연/비용: 응답 시간과 토큰·추론/검색 비용

 

학습 방향

1단계: 텍스트 RAG 기본형
청킹→임베딩→하이브리드 검색→리랭커→컨텍스트 주입→생성→출처
👉 BM25+E5+Cross-Encoder로 단순하게 시작

 

2단계: 품질 보강
HyDE로 쿼리 확장, RAG-Fusion으로 RRF 융합, Self-RAG로 과·소검색 제어
👉 비용 증가 대비 캐시·상한(k, 토큰) 튜닝

 

3단계: 운영 안정성
가드레일 설정(llm 입력/출력시에 선택 적용 가능), 감사 로깅, 정책 프롬프트 적용
👉 실서비스 배포 전 필수 단계

 

임베딩 모델 비교 (2025년 09월 04일 기준 작성)

제공자	모델명	차원수	컨텍스트 길이	가격 (per 1M tokens)	다국어 지원	성능 등급	주요 특징
OpenAI	text-embedding-3-large	3,072 축소 가능: 256~3072	8,191	$0.13	제한적	⭐⭐⭐⭐⭐	Matryoshka 지원, 최고 성능
	text-embedding-3-small	1,536 축소 가능: 512~1536	8,191	$0.02	제한적	⭐⭐⭐⭐	비용효율적, Matryoshka 지원
	text-embedding-ada-002	1,536	8,191	$0.10	제한적	⭐⭐⭐	레거시 모델
Azure OpenAI	text-embedding-3-large	3,072 (조정가능)	8,192	Azure 정책 지역별 상이	제한적	⭐⭐⭐⭐⭐	엔터프라이즈급 보안
	text-embedding-3-small	1,536 (조정가능)	8,192	Azure 정책 지역별 상이	제한적	⭐⭐⭐⭐	엔터프라이즈급 보안
	text-embedding-ada-002	1,536	8,000~8,192	Azure 정책 지역별 상이	제한적	⭐⭐⭐	레거시 모델
Google Gemini	gemini-embedding-001	3,072 (기본값, 768/1536 축소가능)	2,048	$0.15	100+ 언어	⭐⭐⭐⭐⭐	다국어 최강, Matryoshka 지원
	embedding-001 (Legacy)	768	2,048	(이관 중)	100+ 언어	⭐⭐⭐	구세대 모델
Google Vertex AI	gemini-embedding-001	3,072 (768/1536 축소가능)	2,048 (배치당 20,000)	Vertex 정책	100+ 언어	⭐⭐⭐⭐⭐	차원 조절 가능
	text-embedding-005	768	2,048 (배치당 20,000)	Vertex 정책	영어 중심	⭐⭐⭐⭐	코드/영어 특화, Gecko 기반
	text-multilingual-embedding-002	768	2,048 (배치당 20,000)	Vertex 정책	100+ 언어	⭐⭐⭐⭐	다국어 특화, Gecko 기반
AWS Bedrock	amazon.titan-embed-text-v2:0	256/512/1,024 (선택가능)	8,192	$0.02	100+ 언어	⭐⭐⭐⭐	차원 선택 가능, AWS 네이티브
	cohere.embed-english-v3	1,024	512	$0.10	영어	⭐⭐⭐⭐	영어 최적화
	cohere.embed-multilingual-v3	1,024	512	$0.10	100+ 언어	⭐⭐⭐⭐	다국어 지원
	amazon.titan-embed-text-v1:0	1,536	8,192	$0.11	영어 중심	⭐⭐⭐	레거시 Titan
Cohere	embed-english-v3.0	1,024	≤512	$0.10	영어	⭐⭐⭐⭐	영어 성능 우수
	embed-multilingual-v3.0	1,024	≤512	$0.10	100+ 언어	⭐⭐⭐⭐	다국어 강점
	embed-english-light-v3.0	384	≤512	$0.10	영어	⭐⭐⭐	경량화, 저지연
	embed-multilingual-light-v3.0	384	≤512	$0.10	100+ 언어	⭐⭐⭐	경량화 다국어
Mistral Cloud	mistral-embed	1,024	8,000	$0.10	다국어	⭐⭐⭐⭐	RAG 최적화, 유럽 중심
Hugging Face Inference	all-MiniLM-L6-v2	384	128~512	엔드포인트 시간 과금	제한적	⭐⭐⭐	경량, 빠른 속도
	BGE-M3	1,024	8,192	엔드포인트 시간 과금	100+ 언어	⭐⭐⭐⭐	다국어·멀티기능
Ollama (로컬)	nomic-embed-text	768 (조정가능)	512±	무료	다국어	⭐⭐⭐⭐	Matryoshka 지원, 완전 무료
	all-minilm	384	512	무료	영어 중심	⭐⭐⭐	초경량, CPU 가능
	bge-m3	1,024	8,192	무료	100+ 언어	⭐⭐⭐⭐	다국어 강력, 무료

 

주요 정보 안내

• 차원수: 높을수록 더 정밀한 의미 표현이 가능하지만, 저장 비용과 계산 시간 증가
• 컨텍스트 길이: 한 번에 처리할 수 있는 최대 토큰 수
• Matryoshka: 차원을 줄여도 성능 손실이 적은 기술
• 성능 등급: MTEB, BEIR 등 벤치마크 기준

선택 가이드

• 최고 성능: OpenAI text-embedding-3-large, Google gemini-embedding-001
• 비용 효율: OpenAI text-embedding-3-small, AWS Titan v2
• 다국어 최강: Google gemini-embedding-001, Cohere multilingual-v3.0
• 무료: Ollama 모델들 (로컬 실행 필요)
• 엔터프라이즈: Azure OpenAI, Google Vertex AI

 

벡터 데이터베이스 비교표 (2025년 09월 4일 기준)

서비스 형태	데이터베이스명	호스팅방식	하이브리드 서치 (벡터+키워드)	메타데이터 필터링	RerankResults	성능등급	특징
완전 관리형	Pinecone	완전 관리형 서버리스	우수 Sparse-Dense	지원	지원	⭐⭐⭐⭐⭐	추천: 개발팀 리소스 부족, 빠른 프로토타이핑, 엔터프라이즈 장점: 운영 부담 제로, 자동 스케일링, 안정성 단점: 높은 비용, 벤더 종속성, 커스터마이징 제한
	OpenSearch (AWS)	관리형 (AWS)	우수 네이티브	지원	부분	⭐⭐⭐⭐	추천: AWS 인프라, 기존 Elasticsearch 사용자 장점: 3.0에서 9.5배 성능 향상, 풍부한 검색 기능 단점: 벡터 전용 DB보다 복잡함, AWS 종속성
오픈소스 +관리형 옵션	Weaviate	Self-host/ Cloud	우수 네이티브	지원	지원	⭐⭐⭐⭐⭐	추천: 복잡한 지식 그래프, GraphQL 사용팀 장점: 모듈러 아키텍처, 지식그래프+벡터, 풍부한 통합 단점: 메모리 사용량 높음, 러닝커브
	Qdrant	Self-host/ Cloud	우수 페이로드 필터	지원	지원	⭐⭐⭐⭐⭐	추천: 고성능 필요, 비용 최적화, Rust 안정성 중시 장점: Rust로 빠른 성능, 정교한 필터링, ACID 트랜잭션 단점: 상대적으로 새로운 생태계
	Milvus (Zilliz Cloud)	Self-host/ Zilliz Cloud	제한적 별도 구성	지원	제한적	⭐⭐⭐⭐⭐	추천: 대용량 데이터(억 단위), 데이터 엔지니어링 팀 보유 장점: 최대 스케일 지원, <10ms 레이턴시, 다양한 인덱스 단점: 복잡한 아키텍처, 높은 운영 복잡도
	ChromaDB	Self-host/ Cloud (예정)	제한적 소규모용	부분	제한적	⭐⭐⭐	추천: 프로토타이핑, 소규모 프로젝트, 개발자 친화적 장점: 설치 간단, LLM 앱 특화, ~20ms 검색 속도 단점: 엔터프라이즈 기능 부족, 스케일 한계
	MongoDB Atlas Vector Search	Atlas (관리형)	우수 Vector+Full-text	지원 Options	지원	⭐⭐⭐⭐	추천: 기존 MongoDB 사용자, OLTP+RAG 통합 장점: Atlas 관리 편의성, 강력한 프리필터링, 파이프라인 단점: 벡터 전용DB보다 복잡함, 비용
	Supabase Vector (pgvector)	Supabase Service	우수 SQL+FTS	지원	지원	⭐⭐⭐⭐	추천: 풀스택 개발, 관계형+벡터 데이터, 빠른 MVP 장점: SQL 친숙함, 통합 환경, Pinecone 대비 1185% QPS 단점: PostgreSQL 스케일 한계 (~100M 벡터)
PostgreSQL 생태계	pgvector (PostgreSQL)	Self-host/ 포함 as-a-Service	우수 RRF	지원	지원	⭐⭐⭐⭐	추천: 기존 PostgreSQL 사용자, 하나의 DB로 통합 장점: ACID, 트랜잭션, JOIN 지원, 익숙한 SQL 단점: 대용량 스케일링 한계, 벡터 전용 최적화 부족
	PGVector (Postgres QL)	Self-host/ 포함 as-a-Service	우수 SQL+검색	지원	지원	⭐⭐⭐⭐	추천: RDS/Aurora 사용자, RDBMS+벡터 통합 장점: 기업 급/장 가능, 관리형 서비스 이용 가능 단점: PostgreSQL과 동일한 제약사항
라이브러리/ 특수목적	FAISS (Facebook)	In-app mem ory(내구)	없음 벡터 전용	—	—	⭐⭐⭐⭐⭐	추천: 연구/실험, 최대 성능 필요, GPU 가속 장점: 최고 raw 성능, 다양한 알고리즘, GPU 지원 단점: 라이브러리만, 영속성/메타데이터 없음
	Redis Search	Self-host/ Enterprise	우수 태그/수치 필터	지원	부분	⭐⭐⭐⭐	추천: 기존 Redis 사용자, 극저지연(<1ms), 캐시+벡터 장점: 매우 빠른 속도, 실시간, 메모리 기반 단점: 메모리 의존, 비용, 데이터 크기 제한
	Zep (deprecated)	Zep Cloud/ 프로젝트스 는 deprecated	—	—	—	⭐	⚠️ 권장하지 않음: n8n 벡터 스토어는 deprecated 새 프로젝트에서는 사용 금지, 대안 고려 필요

 

또다른 기준에서의 정리

Vector DB/서비스	n8n 노드 이름	배포 형태	Hybrid Search(제품/노드)	메타데이터 필터/검색 필터(노드)	Rerank Results(노드)	특성 요약 & 언제 쓰면 좋은지
Simple In-Memory	Simple Vector Store	In-app memory(비영구)	제품: 해당 없음 노드: 외부 Reranker 연계	−	지원	개발/프로토타이핑에 최적. 재시작 시 데이터 유실, 인스턴스 전역 공유 주의. 빠르게 흐름 검증·데모할 때. (n8n Docs)
Pinecone	Pinecone Vector Store	완전관리형 SaaS	제품: Sparse+Dense 단일(또는 조합) Hybrid 지원 노드: Reranker와 조합	Metadata Filter(AND 등)	지원	대규모/운영 환경에 적합. 쉬운 스케일·SLA·지역 분산. 하이브리드(키워드+의미) 품질 필요 시 유리. (n8n Docs, pinecone.io)
Qdrant	Qdrant Vector Store	OSS(Self-host) / Cloud	제품: Sparse/Hybrid·서버사이드 Query API 지원 노드: Reranker와 조합	Metadata Filter(AND)	지원	오픈소스 선호, 비용 절감, 세밀한 제어. 최신 Hybrid(Query API, RRF, BM25) 실험·적용에 유리. (n8n Docs, Qdrant)
Weaviate	Weaviate Vector Store	OSS(Self-host) / Cloud	제품: BM25+Vector Hybrid 기본 제공(가중치/퓨전)·Multitenancy	Search Filters(AND/OR/다양한 연산자)	지원	하이브리드 검색을 표준 기능으로 쓰고 싶을 때. 멀티테넌시(tenant)와 풍부한 필터가 필요한 멀티 고객 시나리오. (n8n Docs, docs.weaviate.io)
Milvus	Milvus Vector Store	OSS(Self-host) / Zilliz Cloud	제품: 대규모 벡터 인덱싱(ANN)·하이브리드 구축 가능(외부 조합)	Metadata Filter(AND)	지원	초대규모 임베딩, 자원 직접 제어. 대량 배치 삽입·낮은 지연이 중요한 자가 호스팅/전용 클러스터. (n8n Docs)
MongoDB Atlas Vector Search	MongoDB Atlas Vector Store	Atlas(관리형 DB 기능)	제품: Vector+Full-text Hybrid 공식 지원(semantic boosting/RRF)	Metadata Filter(노드 Options)	지원	이미 Atlas를 쓰거나 OLTP+RAG를 한 곳에서. 강력한 프리필터링과 파이프라인 집계로 엔드투엔드 구현. (n8n Docs, MongoDB)
PGVector(PostgreSQL)	PGVector Vector Store	Self-host/Postgres-as-a-Service	제품: SQL 기반(하이브리드는 앱/별도 검색과 조합)	Metadata Filter(AND)	지원	RDBMS에 임베딩을 같이 두고 싶은 단일 스택. 규모가 중소/트랜잭션 연동형 애플리케이션. (n8n Docs)
Supabase(pgvector)	Supabase Vector Store	Supabase SaaS(Postgres)	제품: SQL 기반(하이브리드는 앱/별도 검색과 조합)	Metadata Filter(AND)	지원	빠른 MVP/서버리스 구성. 인증/스토리지와 유기적으로 결합해 전반적인 DX가 좋음. (n8n Docs)
Zep	Zep Vector Store	Zep Cloud/온프레미스(노드 deprecated)	제품: 대화 메모리/벡터	−	−	n8n 벡터 스토어 노드는 deprecated(향후 제거). 새 프로젝트에는 권장하지 않음. (n8n Docs)

 

용도별 최적 선택 가이드

빠른 시작 & 프로토타이핑

• ChromaDB: 개발자 친화적, LLM 앱
• Supabase Vector: 풀스택, SQL 친숙
• pgvector: 기존 PostgreSQL 사용자

엔터프라이즈 & 프로덕션

• Pinecone: 완전 관리형, 안정성
• Weaviate: 복잡한 지식 시스템
• OpenSearch: AWS 생태계

고성능 & 대용량

• Qdrant: Rust 성능, 비용 효율
• Milvus: 억 단위 벡터
• FAISS: 최대 성능, 연구

비용 최적화

• Qdrant: 오픈소스 + 성능
• pgvector: PostgreSQL 통합
• ChromaDB: 소규모 무료

주요 용어 설명

• 하이브리드 서치: 벡터 유사도 검색 + 키워드/텍스트 검색 조합
• 메타데이터 필터링: 벡터 검색 전/후 속성 기반 필터링
• Rerank Results: 검색 결과를 추가 로직으로 재순위화
• RRF (Reciprocal Rank Fusion): 여러 검색 결과를 합치는 방식
• HNSW: 고성능 근사 최근접 이웃 알고리즘

성능 참고사항

• Milvus/Zilliz: 저지연 리더 (<10ms)
• Pinecone/Qdrant: 20-50ms 범위
• ChromaDB: ~20ms median (100k 벡터 기준)
• pgvector vs Pinecone: 같은 예산에서 pgvector가 1185% 더 높은 QPS
• OpenSearch 3.0: 이전 버전 대비 9.5배 성능 향상

 

---

 

하기 내용부터는 사전 배경지식을 먼저 쌓은 후 보면 좋을 것 같다.
꼭 기초 개념을 먼저 이해한 후 읽으면 좋은 내용이다.

RAG 기초 개념 이해후 구현하면서 겪게 되는 시행 착오 
RAG 구축 시 마주하는 핵심 선택의 순간들과 각 선택이 미치는 영향을 실무 경험을 바탕으로 정리했습니다. 이론은 알겠는데 실제로는 어떻게 선택해야 할지 고민인 분들을 위한 가이드입니다.

임베딩 모델만 해도 수십 개가 있고, 벡터 DB도 여러 개, 청킹 방법도 다양하다. 어떤 글에서는 A를 추천하고, 다른 글은 B가 좋다고 하지만, 결국 "내 상황에서는 뭐가 맞지?"라는 고민에 빠진다.
 
그래서 다음 내용부터는 RAG 구축 시 반드시 마주하게 고민들에 대해 작성해 보았다.
각 선택이 전체 시스템에 미치는 영향과, 어떤 상황에서 어떤 선택을 해야 하는지 예시를 작성해 보았고, 해당 내용들을 토대로 의견을 나누고 각 팀마다의 전략을 세워 보면 좋을 것 같다.
 

선택 1: 벡터 DB vs 검색엔진

첫 번째 갈림길
RAG를 구축한다고 하면 대부분 "벡터 DB를 써야겠구나"라고 생각한다. 하지만 정말 벡터 DB가 필요한가? 일반 검색엔진으로도 충분할 수도 있다.

구분벡터 DB 방식검색엔진 방식

강점	의미 기반 검색 패러프레이즈 잘 잡음	키워드 정확 매칭 빠른 속도, 저비용
적합한 상황	자연어 질문 중심 의미 유사성 중요	정확한 키워드 검색 기술 문서, 매뉴얼
초기 비용	높음 (임베딩 생성)	낮음 (색인만 생성)
운영 복잡도	중간~높음	낮음

벡터 DB가 무조건일까?
나와 같이 기술 블로그나 문서 중심이라면 Elasticsearch 같은 일반 검색엔진부터 시작하는게 나을 수 있다.
벡터 DB는 정말 의미 검색이 필요할 때 도입해도 늦지 않다. 무작정 복잡한 걸로 시작할 필요 없다.

 

선택 2: 오픈소스 vs 상용 임베딩 모델

성능 비교 (한글 기준)

OpenAI text-embedding-3-large: 가장 무난, 비용 중간, API 의존

sentence-transformers/paraphrase-multilingual: 로컬 구동, 한글 무난

cohere-embed-multilingual: 다국어 강점, 비용 저렴

intfloat/multilingual-e5-large: 오픈소스 최강자, 성능 좋음

 

선택 3: 청킹 전략 - 고정 vs 가변

// 청킹 전략별 실제 결과 비교

🔸 고정 크기 (512토큰)
장점: 구현 간단, 예측 가능한 비용
단점: 문맥 끊어짐, 의미 단위 무시

🔸 의미 기반 가변 크기 (문단/제목 단위)  
장점: 문맥 유지, 검색 정확도 높음
단점: 크기 편차 큼, 구현 복잡

🔸 슬라이딩 윈도우 (overlap 50%)
장점: 문맥 손실 최소화
단점: 저장 공간 2배, 중복 검색 위험
    

개발 팁
처음에는 고정 크기로 시작해서 성능을 측정한 다음, 필요하면 의미 기반으로 개선하는 걸 추천한다. 너무 처음부터 완벽하려고 하면 진도가 안 나간다.

 

선택 4: 검색 결과 몇 개나 가져올까?

Top-K 선택의 딜레마

• Top-3: 빠르고 정확하지만 정보 부족할 수 있음
• Top-5: 균형 잡힌 선택, 대부분 상황에서 무난
• Top-10: 풍부한 정보지만 노이즈 증가, 비용 상승
• Top-20+: 리랭커 필수, 고성능 시스템에서 고려

실제로 겪은 문제
Top-K를 10으로 설정했다가 OpenAI API 비용이 폭증한 경험이 있다. 검색 결과마다 토큰이 추가되니까 비용이 선형적으로 증가한다. 처음에는 3~5개부터 시작해서 성능을 보고 늘리는 게 현명하다.

 

선택 5: 실시간 vs 배치 업데이트

업데이트 방식신선도복잡도비용적합 상황

실시간	최고	높음	높음	실시간 뉴스, 주식
일 단위 배치	보통	낮음	낮음	블로그, 문서
수동 업데이트	낮음	최저	최저	정적 매뉴얼

 

선택 6: 모니터링 vs 비용 최적화

실제 비용 구조 (월 1000회 질의 기준 예시)

• 임베딩 생성: $5-20 (모델에 따라 차이)
• 벡터 DB 운영: $10-50 (저장 데이터량에 따라)
• LLM 추론: $20-100 (토큰 사용량에 따라)
• 모니터링 도구: $0-30 (선택사항)

비용 최적화 팁

• 캐싱 활용: 동일 질문 반복 시 벡터 검색 스킵
• 배치 처리: 임베딩 생성을 한 번에 묶어서 처리
• 토큰 제한: 컨텍스트 길이 상한 설정
• 성능 모니터링: 불필요한 재검색 방지

 

선택 7: 정확성 vs 응답 속도

// 성능 튜닝 측정값 예시

검색 단계별 응답 시간 (평균값)

🔸 벡터 검색: 50-200ms (인덱스 크기에 따라)
🔸 리랭킹: +100-300ms (사용 시)  
🔸 LLM 추론: 1-3초 (모델과 토큰량에 따라)
🔸 전체 파이프라인: 2-5초

⚡ 최적화 적용 후
🔸 캐싱 적용: 50% 케이스 200ms 이하
🔸 병렬 처리: 검색+추론 동시 실행으로 30% 단축
🔸 스트리밍: 체감 속도 70% 향상

속도 최적화 우선순위
1. 캐싱 구현 - 가장 효과 크고 구현 쉬움
2. 스트리밍 응답 - 사용자 체감 속도 대폭 개선
3. 병렬 처리 - 검색과 다른 작업 동시 진행
4. 인덱스 최적화 - 마지막 단계에서 고려

 

정리

• 완벽한 선택은 없다: 모든 상황에 맞는 정답은 없다. 내 상황에 맞는 트레이드오프를 찾는 게 핵심
• 단계별 진화가 답: 처음부터 복잡하게 가지 말고, 간단한 것부터 시작해서 필요에 따라 개선
• 비용 관리가 생각보다 중요: 기술적 완성도도 중요하지만 지속가능한 비용 구조 설계가 필수
• 모니터링부터 해야 최적화 가능: 측정되지 않으면 개선될 수 없다. 기본 메트릭 수집부터
• 한국어는 한국어 모델로: 다국어 모델이나 한국어 특화 모델 필수, 영어 모델로는 한계 명확

초보자가 자주 하는 실수
• 처음부터 최신 기법 다 적용하려다가 복잡도 폭발
• 성능 측정 없이 "이게 더 좋을 것 같다"는 추측으로 선택
• 비용 계산 없이 무작정 고성능 모델 선택
• 한국어 데이터에 영어 특화 모델 사용
• 모니터링 없이 운영해서 문제점 파악 못함

댓글!
이런 선택 기준들이 이번 제 교육과정에서는 필요하다고 생각 하였습니다. 도움이 되셨나요? 실제로 RAG를 구축하면서 어떤 선택에서 가장 고민이 많으셨는지 댓글로 공유해주세요.