벡터 데이터베이스란 무엇인가?

벡터 데이터베이스는 질문 하나에 아주 빠르게 답한다

숫자 목록을 주면 저장된 목록 중 가장 가까운 것을 돌려줍니다. 인터페이스는 그게 전부입니다.

이 숫자 목록이 임베딩입니다. 임베딩 모델은 문단, 상품 설명, 이미지를 수백에서 수천 개의 숫자로 바꾸는데, 비슷한 의미가 서로 가까이 놓이도록 배치합니다. AI에서 임베딩이란 무엇인가에서 그 방식을 다룹니다. 벡터 데이터베이스는 그런 목록이 많이 쌓였을 때 그것들이 머무는 곳입니다. 각 목록을 ID와 메타데이터와 함께 저장하고, 그 위에 인덱스를 만들어 최근접 이웃 검색에 답합니다. "여기 질의 벡터가 있으니, 가장 가까운 열 개를 달라"는 식입니다.

어려운 부분은 '빠르게'라는 단어입니다. 질의를 1,536개 숫자로 이루어진 저장 벡터 백만 개와 비교하면 15억 번의 곱셈이 필요하고, 이걸 입력할 때마다 매번 수행하는 방식은 확장되지 않습니다. 그래서 벡터 데이터베이스는 근사 최근접 이웃 인덱스를 씁니다. 가장 흔한 방식은 HNSW로, Malkov와 Yashunin의 2016년 논문에서 나온 그래프 구조인데, 백만 개 전부가 아니라 수백 개 후보만 살펴보고도 거의 매번 정답을 돌려줍니다. 이 '거의'가 트레이드오프입니다. 약간의 재현율을 내주고 천 배의 속도를 얻는 셈입니다.

기존 데이터베이스는 단어를 맞추고, 벡터 데이터베이스는 의미를 맞춘다

관계형 데이터베이스는 값이 일치하는 행을 찾습니다: WHERE customer_id = 4127. 전문 검색 인덱스는 단어가 포함된 문서를 찾습니다: refund AND policy. 벡터 데이터베이스는 의미가 가까운 항목을 찾습니다. "환불을 받으려면 어떻게 해야 하나요"라는 질의는 두 문장이 단어를 하나도 공유하지 않아도 "반품 및 환불"이라는 제목의 문단을 돌려줍니다.

마지막 행은 이 구분이 얼마나 흐릿한지를 보여줍니다. pgvector는 벡터 컬럼과 HNSW 인덱스를 일반 Postgres에 추가하고, Elasticsearch는 2019년 버전 7.0부터 벡터 필드를, 2022년 버전 8.0부터 HNSW 검색을 지원해왔습니다. "벡터 데이터베이스"는 새로운 제품이라기보다 이미 쓰고 있는 데이터베이스 안의 기능인 경우가 많고, 독립 제품들은 Postgres가 할 수 없는 무언가가 아니라 규모와 운영 완성도로 경쟁합니다.

문서 기반 채팅은 모델이 뒤에 붙은 벡터 검색이다

검색 증강 생성은 검색 단계와 작성 단계로 이루어지며, RAG란 무엇인가에서 그 과정을 다룹니다. 벡터 데이터베이스는 검색 단계입니다.

1. 각 문서를 수백에서 천 토큰 정도의 문단으로 나눕니다.
2. 모든 문단을 임베딩하고, 그 벡터를 문단 텍스트와 출처와 함께 벡터 데이터베이스에 저장합니다.
3. 질문이 들어오면 이를 임베딩해서 데이터베이스에 가장 가까운 문단을 요청합니다.
4. 그 문단들을 질문과 함께 언어 모델에 건네고, 모델이 답을 작성하게 합니다.

1단계와 2단계는 문서가 추가될 때 한 번만 일어납니다. 3단계와 4단계는 질문이 들어올 때마다 일어납니다. 언어 모델은 전체 컬렉션을 보지 못하고 데이터베이스가 고른 대여섯 개 문단만 봅니다. 그래서 답의 품질은 검색의 품질만큼만 좋습니다. 가장 가까운 벡터가 엉뚱한 문단이면 모델은 엉뚱한 질문에 자신 있게 답하는데, AI 환각이란 무엇인가는 이를 지어낸 것이 아니라 검색 실패로 분류합니다.

언제 벡터 데이터베이스가 필요하고, 언제 파일 전체를 보내는 게 나은가

이 결정은 크기의 문제입니다. 모델은 한 번에 자신의 컨텍스트 윈도우만 고려할 수 있고, 그 안의 모든 토큰은 매 턴마다 비용이 듭니다. 벡터 데이터베이스는 모델 앞에 관련된 부분만 놓기 위해 존재합니다. 다 들어가는 문서 한 건이라면 검색 단계를 건너뛸 수 있고, 들어가지 않는 컬렉션이라면 그것이 유일한 선택지입니다.

300,000토큰 분량, 수백 페이지짜리 보고서에 열 개 질문을 던지고 질문당 1,000토큰짜리 문단 다섯 개를 검색한다고 가정하고 두 설계의 비용을 비교해 봅시다. 매번 파일 전체를 보내면 입력 토큰이 300만 개입니다. 질문당 1,000토큰 문단 다섯 개를 검색하면 5만 개입니다. 2026-08-20에 OpenRouter에서 가져온 AI 모델 비용 지수의 정가 입력 요율에서 이 격차는 모든 모델에서 60배입니다. 프롬프트 캐싱을 제공하는 곳에서는 같은 파일을 다시 읽는 비용이 정가의 10분의 1에서 2분의 1로 청구되어 격차가 대략 6배에서 30배로 좁혀집니다. 그래도 검색이 이깁니다, 차이는 줄어들지만요.

파일이 예산 안에 들어올 때는 파일 전체를 보내는 설계가 그 비용에 걸맞은 것을 얻어냅니다. 4만 토큰 안팎의 60페이지짜리 계약서라면, 모델이 문서 전체를 한꺼번에 봐야 답할 수 있는 질문, 예를 들어 "여기에 14조와 모순되는 내용이 있는가" 같은 질문에 답할 수 있습니다. 검색은 14조와 그 모순을 같은 배치에서 보지 못하므로 이런 질문을 던질 수 없습니다. 여기서 나오는 규칙은 이렇습니다. 문서 한 건, 혹은 몇 건은 통째로 넣고, 서재 규모는 벡터 데이터베이스를 거칩니다. 그 중간이라면 업로드를 주제별로 나눠서 모델이 필요한 부분을 받게 하세요.

Whizi는 텍스트 자체를 최대 40,000토큰 한 턴에 보낸다

Whizi는 채팅을 위해 벡터 데이터베이스를 운영하지 않습니다. 파일을 첨부하면 문서 업로드 경로가 텍스트를 추출해서 턴당 최대 4만 토큰 고정 예산 안에서 프롬프트 텍스트로 모델에 보냅니다. 그보다 긴 업로드는 잘리며, 토스트와 메시지 안의 표시로 그 사실을 알립니다. 프로젝트 파일도 같은 방식으로 작동합니다. 프로젝트 기능은 최대 10개 파일을 고정해두고 매 메시지마다 그 텍스트를 프롬프트에 다시 넣는데, 파일당 32,000자, 프로젝트 블록 전체는 120,000자로 제한됩니다.

이 상한선이 설계의 경계입니다. 32,000자를 넘는 고정 파일은 잘리고, 4만 토큰 턴 예산을 넘는 첨부 파일도 잘리며, 프로젝트는 검색 가능한 서재가 아니라 폴더입니다. 이 트레이드오프는 의도된 것입니다. 턴 예산 안에 들어오는 계약서나 논문이라면, 검색하는 것보다 텍스트가 그대로 존재하는 편이 낫고, 모델이 사용한 문단을 인용하게 하는 검증법도 그 문단이 실제로 거기 있기 때문에 통합니다. 문서가 수천 건이라면 벡터 데이터베이스가 맞는 도구이고 채팅 앱은 맞지 않는 도구입니다.

이 구조에서 이어지는 습관이 두 가지 있습니다. 여러 파일이 첨부됐다면 질문에 파일 이름을 한 번 언급하세요. 그러지 않으면 모델이 조용히 하나를 골라버립니다. 그리고 실제로 행동에 옮길 답이라면 인용을 요청하세요. 검색 시스템은 엉뚱한 문단을 돌려줄 수 있고, 파일 전체를 읽는 시스템은 파일 대신 기억에서 답할 수 있습니다. 인용은 두 경우 모두를 잡아냅니다.