벡터 검색(Vector Search)은 문서와 검색어를 각각 의미를 담은 숫자 배열로 바꾼 뒤, 그 배열 사이의 거리가 가까운 순서로 결과를 찾는 검색 방식이다.
숫자 배열을 임베딩이라고 부른다. 같은 뜻을 가진 글은 서로 가까운 좌표에, 상관없는 글은 먼 좌표에 놓이도록 학습된 값이다.
글자가 하나도 겹치지 않아도 뜻이 통하면 찾아낸다는 것이 키워드 검색과 갈리는 지점이다.
임베딩 생성, 유사도 측정, 근사 탐색의 세 단계로 움직인다.
세 번째 단계가 이 기술의 성격을 결정한다. Databricks는 “대부분의 프로덕션 시스템은 대신 근사 최근접 이웃(ANN) 검색을 사용합니다”라고 정리한다 (Databricks, 벡터 검색이란 무엇인가요?).
효과는 검색 연구에서 수치로 확인됐다. 밀집 벡터 검색을 제안한 논문은 자체 검색기가 강력한 Lucene BM25 시스템보다 상위 20개 문단 검색 정확도에서 9~19%포인트 앞섰다고 보고했다 (Karpukhin 외, Dense Passage Retrieval for Open-Domain Question Answering, 2020).
규모도 문제가 되지 않는다. 구글은 자사 벡터 검색이 ScaNN 알고리즘을 기반으로 “밀리초 지연 시간으로 수십억 개의 벡터로 확장”한다고 밝히며, 이 알고리즘이 구글 검색과 유튜브와 구글 플레이를 지원하는 것과 같은 기술이라고 설명한다 (Google Codelabs, 벡터 검색 2.0 소개).
대조하는 대상이 다르다. 키워드 검색은 글자를 맞추고 벡터 검색은 좌표의 거리를 잰다.
| 구분 | 키워드 검색 | 벡터 검색 |
|---|---|---|
| 색인에 담기는 것 | 단어와 등장 위치 | 고차원 숫자 배열 |
| 점수 계산 | BM25 같은 어휘 통계 | 코사인 유사도, 유클리드 거리 |
| 잘하는 것 | 제품 코드, 고유명사, 정확 일치 | 동의어, 문장형 질문, 비정형 데이터 |
| 못하는 것 | 다른 말로 적은 같은 뜻 | 학습에 없던 신조어와 코드 |
| 결과의 성격 | 결정적 | 근사적 |
구글도 이 한계를 그대로 적는다. 시맨틱 검색은 “SKU-12345와 같은 제품 코드에서는 실패하고, 임베딩 모델이 본 적이 없는 신조어나 브랜드 이름에서는 어려움을 겪는다”는 것이다.
이미지, 음성, 영상처럼 애초에 단어가 없는 데이터를 다룰 수 있다는 점도 벡터 검색만의 영역이다.
시맨틱 검색이 목표라면 벡터 검색은 그 목표를 이루는 수단이다. 둘은 층이 다르다.
의미를 맞추는 방법에는 동의어 사전, 엔티티 인식, 지식 그래프 참조도 있다. 벡터는 그중 지금 가장 널리 쓰이는 구현일 뿐이다.
| 개념 | 층 | 답하는 질문 |
|---|---|---|
| 시맨틱 검색 | 목표 | 뜻이 맞는 문서를 찾았는가 |
| 벡터 검색 | 구현 | 임베딩 거리로 어떻게 찾을 것인가 |
| 벡터 데이터베이스 | 인프라 | 그 임베딩을 어디에 저장하고 조회할 것인가 |
반대로 벡터 검색이 시맨틱 검색에만 쓰이는 것도 아니다. 추천과 이상 탐지처럼 검색어가 아예 없는 곳에도 같은 계산이 들어간다.
AI 답변의 근거 문서를 찾는 단계가 지금 가장 큰 용처다.
RAG는 질문을 받으면 문서를 먼저 찾고 그 문서를 근거로 답을 만든다. 이 앞 단계가 대부분 벡터 검색이고, 그래서 문서를 청킹해 조각마다 임베딩을 만들어 둔다.
IBM과 Elastic이 정리한 용처도 이 범위와 겹친다 (Elastic, 벡터 검색은 무엇인가요?).
충분하지 않다. 속도를 얻는 대가로 정확도를 일부 내주고, 필터와 함께 쓸 때 예상과 다르게 동작한다.
근사 탐색은 이름 그대로 근사다. SK의 기술 블로그는 ANN을 두고 “검색 속도를 크게 향상시키기 위해 정확도를 다소 희생(trade-off)한다”고 설명한다 (DEVOCEAN, 벡터 유사도 검색이 무엇인가요?).
실제 서비스에서 이 대가가 어떻게 드러나는지 기록한 사례가 있다. 우아한형제들은 실시간 추천에 벡터 검색을 도입하면서 HNSW와 IVFFlat이 “recall(재현율)을 합리적으로 희생하면서도 검색 성능을 올리는 알고리즘”이라고 짚고, 상위 1,000개를 뽑은 뒤 배달 가능 여부로 거르면 남는 결과가 크게 줄어드는 문제를 겪었다고 밝혔다 (우아한형제들 기술블로그, 실시간 반응형 추천 개발 일지 2부).
한국어 검색 결과에서 이런 기록은 드물다. 2026년 8월 23일 구글 한국어 “벡터 검색” 검색 1페이지 9건을 전수 확인한 결과, 실제 서비스에 도입하며 겪은 제약을 담은 문서는 이 한 건뿐이었고 나머지 8건은 벤더의 설명 문서이거나 개념 정리 글이었다.
구글도 도입의 어려움을 네 가지로 정리한다. 임베딩 파이프라인 운영, 상품 데이터를 따로 보관하는 저장소, 지연 시간과 재현율의 균형을 맞추는 색인 조정, 그리고 하이브리드 검색 구성이다.
결론은 조합이다. 정확 일치가 필요한 질의는 키워드 쪽이 받고 의미가 필요한 질의는 벡터 쪽이 받는 하이브리드 검색이 프로덕션의 기본값에 가깝다.
정확도를 그대로 지키는 방식은 모든 벡터를 비교하는 kNN이고, 실제 서비스에서 더 많이 쓰는 방식은 후보를 추려 보는 ANN이다.
ANN 계열에서 이름이 자주 나오는 것은 HNSW, IVFFlat, 그리고 구글이 쓰는 ScaNN이다. 셋 다 얼마나 많이 훑을지를 조절해 속도와 재현율의 균형점을 옮길 수 있다.
색인만 필요하면 라이브러리로 충분하다. 페이스북이 공개한 Faiss가 대표적이고, 벡터 양자화와 역색인으로 정확도와 속도의 균형을 조절한다.
서비스 규모가 커지면 라이브러리 대신 벡터 데이터베이스나 관리형 검색 제품으로 옮겨 가는 경우가 많다. 색인 갱신, 필터링, 이중화까지 직접 만들어야 하기 때문이다.
서치폴라리스가 AI 검색 가시성을 진단하고 GEO 실행까지 대행합니다.