벡터 데이터베이스 완벽 이해 — 임베딩·의미 검색·RAG의 작동 원리

핵심 메시지

• 전통적 데이터베이스는 정확한 단어 일치 검색에 맞춰져 있어, 표현이 다르지만 뜻이 같은 질문에는 답하지 못한다. 벡터 데이터베이스는 이 '의미 기반 검색' 문제를 풀기 위해 만들어졌다.
• 임베딩은 단어·문장·이미지를 의미가 담긴 숫자 목록(벡터)으로 바꾼 것으로, 뜻이 비슷하면 벡터 공간에서 가깝게 위치한다. 'king - man + woman ≈ queen' 같은 연산이 가능한 이유다.
• RAG는 LLM(추론 능력)과 벡터 데이터베이스(교과서 역할)를 결합해, 모델이 관련 문서를 찾아 근거에 기반한 답을 내도록 한다. 도메인 지식에서의 환각을 줄이는 핵심 방식이다.
• 문서를 임베딩하기 전 '청킹'이 품질을 좌우한다. 너무 크면 정밀도가, 너무 작으면 맥락이 떨어진다. 청크당 300~500토큰에 50~100토큰 중첩이 좋은 출발점이다.
• 벡터 데이터베이스는 RAG뿐 아니라 음악·콘텐츠 추천, 이미지 유사 검색, 보안 이상 탐지 등 '유사도 검색'이 필요한 모든 곳에 쓰인다.

쉽게 이해하기

발표자는 회사의 수천 개 내부 문서를 바탕으로 답하는 AI 비서를 예로 든다. 문서를 일반 데이터베이스에 넣고 검색하면, '휴가(vacation)'라는 단어로는 찾아도 '연차가 며칠인가요?'처럼 표현이 다른 질문은 연결하지 못한다. MySQL·PostgreSQL이 정확·부분 일치에 최적화돼 있기 때문이다.

이 한계를 푸는 것이 벡터다. 사람이 'king'을 들으면 왕족·권력·왕관 같은 다차원적 의미망을 떠올리듯, 머신러닝 모델은 데이터를 의미가 담긴 숫자 목록인 임베딩으로 바꾼다. 뜻이 비슷한 단어들은 벡터 공간에서 서로 가깝게 모이며, 잘 학습된 임베딩 모델은 'king - man + woman'이 'queen'에 매우 근접하도록 의미의 차원을 학습한다.

문서를 모두 벡터로 바꿔 저장해 두면, 사용자의 질문도 벡터로 변환해 의미상 가장 가까운 문서를 빠르게 찾을 수 있다. 단어가 하나도 겹치지 않아도 뜻이 통하면 검색되며, 수백만 건 규모에서도 빠르게 작동한다.

가장 중요한 활용처는 RAG(검색 증강 생성)다. 발표자는 이를 시험에 비유한다. RAG가 없는 LLM은 암기한 것만 답하는 '닫힌 책 시험'이라 학습 시점 이후나 회사 내부 정보는 환각하거나 모른다고 한다. RAG는 옆에 교과서를 둔 '열린 책 시험'으로, LLM이 벡터 데이터베이스에서 관련 문서를 찾아 근거에 기반해 답한다.

실전에서는 문서를 임베딩해 벡터 DB에 저장하고, 질문을 벡터로 바꿔 가장 유사한 상위 문서를 찾아 원 질문과 함께 LLM에 넘긴다. 발표자는 청킹의 중요성과 함께, 입문엔 ChromaDB, 자체 호스팅 고성능엔 Qdrant, 관리형 운영엔 Pinecone, 하이브리드 검색엔 Weaviate를 추천한다.

주요 인사이트

• 벡터 데이터베이스의 핵심 가치는 '키워드 일치'가 아니라 '의미 일치'다. 같은 뜻을 다른 말로 물어도 관련 문서를 찾아 주는 것이 전통 DB와의 결정적 차이다.
• RAG에서 LLM은 추론을 담당하는 학생이고 벡터 데이터베이스는 참고할 교과서다. 검색 단계의 품질이 곧 답변의 정확성을 좌우한다.
• 어떤 벡터 DB를 쓰느냐만큼 '청킹 전략'이 중요하다. 청크당 300~500토큰, 경계 중첩 50~100토큰, 가능하면 고정 크기 분할 대신 의미 기반 청커를 쓰는 것이 권장된다.
• 도구 선택은 목적에 맞춘다. 로컬 실험은 ChromaDB, Rust 기반 고성능 자체 호스팅은 Qdrant, 인프라 관리를 피하려면 관리형 Pinecone, 벡터+키워드 결합이 필요하면 Weaviate가 적합하다.
• 데이터를 풍부한 숫자 표현으로 바꿔 유사도 검색을 빠르게 한다는 원리는 동일하므로, Spotify·Netflix 추천이나 Pinterest 이미지 검색, 사이버 보안 이상 탐지에도 그대로 적용된다.

자주 묻는 질문

관련 AI 소식