일반 DB는 정확히 일치하는 값을 찾습니다. `WHERE name = '이상민'`처럼요. vector DB는 \*\*"의미가 비슷한 것"\*\*을 찾습니다. 작동 원리는 이렇습니다. **1) 임베딩(embedding)** 텍스트를 임베딩 모델에 넣으면 수백\~수천 개의 실수 배열이 나옵니다. ``` "강아지가 뛰어논다" → [0.21, -0.43, 0.88, ...] (1536차원) "개가 달린다" → [0.19, -0.41, 0.85, ...] "주식 시장 폭락" → [-0.77, 0.12, -0.05, ...] ``` 앞의 두 문장은 단어가 하나도 안 겹치는데 벡터가 가깝습니다. 의미가 좌표로 바뀐 겁니다. **2) 유사도 검색** 질문도 같은 방식으로 벡터로 바꾼 뒤, 저장된 벡터 중 가장 가까운 것들을 찾습니다. 거리 측정은 보통 코사인 유사도(벡터 사이 각도)를 씁니다. **3) ANN 인덱싱** 문서가 100만 개면 전부 비교하기엔 느립니다. 그래서 정확도를 조금 포기하고 속도를 얻는 근사 최근접 이웃(ANN) 알고리즘을 씁니다. 대표적으로 HNSW(그래프 기반, 가장 널리 쓰임), IVF(클러스터로 나눠 일부만 탐색), PQ(벡터를 압축해 메모리 절약)가 있습니다. ### RAG에서의 역할 LLM은 학습 시점 이후의 정보나 사내 문서를 모릅니다. RAG는 이 구멍을 메우는 방식입니다. ``` [사전 준비] 문서 → 청킹 → 임베딩 → vector DB 저장 [질의 시점] 질문 → 임베딩 → 유사 청크 top-k 검색 → 프롬프트에 끼워넣기 → LLM 답변 ``` vector DB는 이 흐름에서 "검색" 부분을 담당합니다. 여기서 엉뚱한 문서를 가져오면 LLM이 아무리 좋아도 답이 틀립니다. 그래서 RAG 품질의 절반 이상이 vector DB 설정에서 갈립니다. ### 주요 제품 | 이름 | 특징 | | --- | --- | | **Chroma** | 설치 한 줄, 로컬 파일 기반. 학습·프로토타입용으로 최적 | | **FAISS** | Meta 제작 라이브러리. DB가 아니라 인덱스 엔진. GPU 가속 지원 | | **Qdrant** | Rust 기반. 필터링 성능 좋고 자체 호스팅 편함 | | **Milvus** | 대규모 분산 처리. NVIDIA cuVS와 연동해 GPU 인덱싱 가능 | | **pgvector** | PostgreSQL 확장. 기존 RDB에 벡터 컬럼만 추가 | | **Pinecone** | 완전 관리형 SaaS. 운영 부담 없음 | NVIDIA 과정이라면 실습은 Chroma나 FAISS로 시작하고, GPU 활용을 보여주는 단계에서 Milvus + cuVS 조합을 다룰 가능성이 높습니다. ### 실무에서 진짜 중요한 것 라이브러리 API는 하루면 익힙니다. 정작 결과를 좌우하는 건 이 셋입니다. * **청킹 전략** — 문서를 몇 글자 단위로 자를지, 겹침(overlap)을 얼마나 줄지. 너무 잘게 자르면 문맥이 날아가고, 너무 크면 노이즈가 섞입니다 * **메타데이터 필터링** — 부서·날짜·문서종류로 먼저 걸러낸 뒤 벡터 검색. 이걸 안 하면 엉뚱한 부서 문서가 딸려옵니다 * **하이브리드 검색** — 벡터 검색은 고유명사·제품코드에 약합니다. 키워드 검색(BM25)과 섞어야 실용적입니다 프론트엔드 개발 경험이 있으시니 `pgvector`로 먼저 감을 잡아보시는 것도 좋습니다. 익숙한 SQL 문법에 `<=>` 연산자 하나만 추가된 형태라 진입 장벽이 가장 낮습니다.