벡터 데이터베이스와 LLM 활용법: 기억·RAG·유사도 검색 핵심 정리

핵심 메시지

• LLM은 그 자체로는 상태(state)를 저장하지 못해, 대화 이력·최신 정보·사내 데이터를 외부에 둬야 한다.
• 벡터 데이터베이스는 영구 기억 저장, 학습 컷오프 보완, 사내 데이터 연결(RAG)이라는 세 가지 용도로 쓰인다.
• 벡터 검색은 키워드 일치가 아니라 의미적 유사도를 찾는 방식이라, 질문의 맥락과 뜻에 맞는 결과를 돌려준다.
• 관계형 DB도 벡터를 담을 수 있지만 유사도 검색에 최적화된 인덱싱이 없어 대규모에서는 전수 스캔이 되어 확장되지 않는다.
• 벡터 DB는 유사도 검색 내장, 벡터 전용 인덱싱, 분산 확장, 압축·캐싱으로 ML·LLM 시스템에 적합하다.

쉽게 이해하기

대규모 언어모델(LLM)은 강력하지만 본질적으로 '무상태(stateless)'다. 모델 자체는 사용자와 주고받은 대화를 기억하지 못하기 때문에, 대화의 연속성을 유지하려면 이전 대화 내용을 어딘가에 보관했다가 다시 전달해야 한다. 가장 단순한 방법은 채팅 클라이언트가 매 요청마다 지난 대화를 함께 보내는 것이지만, 벡터 데이터베이스를 서버 쪽에 두고 대화 이력을 저장하는 방법도 있다.

두 번째 용도는 '컷오프 문제'를 보완하는 것이다. 사전학습된 LLM은 학습 데이터의 특정 시점까지만 알고 있어, 그 이후의 최신 정보는 답에 반영하지 못한다. 최신 문서를 벡터 데이터베이스에 넣어두면, 사용자가 질문할 때 의미적으로 관련 있는 새 문서를 찾아 프롬프트에 함께 실어 보낼 수 있고, 그 결과 모델은 더 시의성 있는 답을 만든다.

세 번째는 조직의 자체 데이터를 LLM 시스템에 연결하는 RAG(검색 증강 생성, Retrieval Augmented Generation)다. 먼저 사내 문서들을 임베딩(embedding)으로 변환해 벡터 DB에 저장한다. 사용자가 질문하면 그 질문도 전용 임베딩 모델로 벡터화한 '쿼리 임베딩'으로 바꾼 뒤, 벡터 DB에서 의미적으로 비슷한 문서를 찾아 원래 질문과 묶어 모델에 전달한다. 임베딩은 텍스트뿐 아니라 오디오·이미지·영상에도 만들 수 있어, 구글 등의 이미지·음성·영상 검색도 같은 유사도 검색 원리로 작동한다.

그렇다면 익숙한 관계형 데이터베이스에 벡터를 저장하면 안 될까? 기능적으로는 가능하다. 그러나 관계형 DB에는 유사도 검색 알고리즘을 위한 기본 질의 지원이나 벡터 최적화 인덱싱이 없다. 그래서 입력 벡터와 비슷한 벡터를 찾으려면 전체 테이블을 훑어 모든 벡터를 꺼낸 뒤 하나씩 비교해야 하는데, 이는 데이터가 수백만·수십억 개로 늘면 응답 시간과 비용 모두 감당하기 어려운 O(n) 연산이 된다.

벡터 DB가 ML·LLM에 적합한 이유는 분명한 기능들 때문이다. 코사인 유사도·유클리드 거리·내적 같은 거리 측정 기반의 유사도 검색을 기본 지원하고, IVF(역파일 인덱스), 곱 양자화(product quantization), HNSW(계층적 탐색 가능 소형 세계) 같은 벡터 전용 인덱싱을 제공한다. 또 노드를 추가해 수평 확장하는 분산 설계, 벡터 압축, 자주 읽는 벡터에 대한 인메모리 캐싱을 갖춰 대규모에서도 빠르게 동작한다.

주요 인사이트

• LLM의 '기억'은 모델 안이 아니라 외부 저장소(벡터 DB)와 매 요청에 끼워 넣는 컨텍스트로 구현된다는 점을 이해하면 챗봇 설계가 쉬워진다.
• RAG의 본질은 '질문을 벡터로 바꿔 의미가 비슷한 문서를 찾아 함께 넣어주는 것'이며, 이는 키워드 검색과 근본적으로 다르다.
• 관계형 DB로도 소규모 개인 프로젝트나 개념 증명(PoC)은 가능하지만, 운영 규모의 확장성은 벡터 전용 DB가 필요하다.
• Pinecone·Milvus·Chroma·Weaviate 같은 전용 벡터 DB뿐 아니라 Redis·Elasticsearch·PostgreSQL도 확장 기능으로 벡터를 지원해, 선택지는 계속 늘고 있다.

자주 묻는 질문

관련 AI 소식