벡터 검색(Vector Search)은 텍스트를 숫자 배열인 임베딩 벡터로 바꾼 뒤, 그 좌표 공간에서 의미가 가까운 문서를 찾는 검색 기술입니다. 단어가 겹치지 않아도 뜻이 통하면 찾아냅니다. "강아지 사료"를 검색하면 "반려견 먹이"를 다룬 문서가 나오는 식이에요.
핵심은 세 가지입니다. 벡터 검색은 구현 기술이고, 시맨틱 검색은 그 기술로 만든 검색 경험입니다. 챗GPT와 퍼플렉시티가 답변 자료를 고를 때 쓰는 방식이 바로 벡터 검색입니다. 그래서 원리를 알면 AI에 인용되는 콘텐츠 구조가 보입니다.
서치폴라리스 용어사전에서 임베딩, 시맨틱 검색과 가장 자주 헷갈리는 용어라 별도 항목으로 정리했습니다.
한눈에 보면 이렇습니다.
- 작동 원리는 임베딩, 인덱싱, 유사도 계산 3단계
- 시맨틱 검색은 벡터 검색의 대표 응용 분야
- 실무 표준은 키워드 검색과 섞는 하이브리드 검색
- AI 검색(RAG)의 검색 단계가 벡터 검색, GEO와 직결
좌표 지도 위에서 이웃을 찾는 검색
대부분 검색을 단어 매칭이라고 생각하지만, 벡터 검색은 거리 계산입니다. 키워드 검색이 도서관의 제목 색인 카드라면, 벡터 검색은 내용이 비슷한 책을 지도 위에 가까이 배치하는 방식이에요. 요리책은 요리책끼리, 그중 한식은 한식끼리 모입니다. 검색은 내 질문과 가장 가까운 자리의 책을 꺼내는 일이 됩니다.
검색이 아니라 측량에 가깝습니다.
과정은 3단계로 정리할 수 있어요.
- 임베딩 문장을 숫자 목록으로 바꿉니다. 모델에 따라 수백에서 수천 개의 숫자로 표현하고, 이 목록이 의미의 좌표가 됩니다. 원리는 임베딩 뜻 글에서 자세히 다뤘습니다.
- 인덱싱 문서가 수백만 건이면 전부 비교하기엔 느립니다. 그래서 HNSW 같은 근사 최근접 이웃(ANN) 인덱스로 후보를 좁힙니다. 정확도를 조금 내주고 속도를 크게 얻는 구조입니다.
- 유사도 계산 좁힌 후보와 질문 벡터 사이 거리를 잽니다. 코사인 유사도, 유클리드 거리, 내적이 대표 측정법입니다.
시맨틱 검색과 뭐가 다른가
두 용어를 같은 뜻으로 쓰는 경우가 많지만, 가리키는 대상이 다릅니다. 시맨틱 검색은 "단어가 아니라 의도와 의미로 찾아준다"는 검색 경험의 이름입니다. 벡터 검색은 그 경험을 만들어내는 핵심 기술이에요. 마이크로소프트 문서도 시맨틱 검색을 벡터 검색의 대표 활용 사례로 설명합니다. (Microsoft Learn, 벡터 검색 개요)
전기차에 비유하면 시맨틱 검색은 "조용하고 매연 없는 주행"이라는 경험이고, 벡터 검색은 그걸 가능하게 하는 배터리와 모터입니다.
| 구분 | 키워드 검색 | 벡터 검색 | 시맨틱 검색 |
|---|---|---|---|
| 정체 | 단어 일치 기술 | 의미 거리 계산 기술 | 검색 경험, 개념 |
| 매칭 기준 | 같은 단어 포함 여부 | 임베딩 벡터 사이 거리 | 사용자 의도와 의미 |
| 강점 | 고유명사, 모델명, 정확 문구 | 동의어, 다른 표현, 다국어 | 자연어 질문 대응 |
| 구현 방식 | 역색인, BM25 | 임베딩 + ANN 인덱스 | 주로 벡터 검색으로 구현 |
처음엔 저도 같은 말인 줄 알았습니다. 문서를 파다 보니 하나는 목표고 하나는 수단이었어요.
실무에서는 두 기술을 섞는 하이브리드 검색이 표준으로 자리 잡았습니다. Elasticsearch는 키워드 검색과 벡터 검색을 한 플랫폼에서 함께 돌리는 구성을 공식 지원합니다. (Elastic, 벡터 검색) 고유명사와 제품 모델명은 키워드 쪽이 여전히 정확하기 때문이에요. 개념 연결이 더 궁금하면 시맨틱 검색 뜻 글이 이어집니다.
아직 확실하지 않은 부분도 있어요. 한국어 임베딩은 모델 편차가 커서, 같은 콘텐츠라도 검색기마다 순위가 다르게 나옵니다. 다만 방향 자체는 의미 기반으로 굳어졌다고 봅니다.
AI 검색이 내 콘텐츠를 찾는 경로
AI 인용을 글솜씨 문제라고 생각하기 쉽지만, 절반은 거리 계산 문제입니다. 챗GPT 검색이나 퍼플렉시티가 답변을 만들 때 뒤에서는 RAG 파이프라인이 돕니다. 질문을 임베딩으로 바꾸고, 벡터 저장소에서 가까운 문서 조각을 찾아 언어 모델에 전달하는 구조입니다. (Google Cloud, RAG 개요) 이때 검색 단위는 페이지 전체가 아니라 문단 조각, 즉 청크입니다. 전체 구조는 RAG 뜻 글에서 다뤘습니다.
여기서 GEO 실전 원칙이 나옵니다. 벡터 검색은 질문과 문단 사이 의미 거리를 잽니다. 그래서 헤딩 바로 아래에 직접 답변을 두고, 한 문단이 하나의 질문에 완결되게 쓰면 검색될 확률이 올라갑니다. 서치폴라리스가 고객사 콘텐츠를 진단할 때 첫 번째로 보는 항목도 이 청크 완결성입니다.
~~이 글도 그 원칙대로 썼습니다.~~
마케터가 벡터 데이터베이스를 직접 고를 일은 거의 없습니다. Pinecone, Milvus, pgvector 같은 도구 비교는 개발팀 몫이에요. 우리는 도구 공부보다 문단 구조를 고치는 데 시간을 쓰는 쪽을 추천합니다.
이 섹션을 읽고 스스로 점검해 볼 질문 두 개를 남깁니다.
- 내 글은 헤딩만 보고도 어떤 질문의 답인지 알 수 있나?
- 한 문단만 떼어 읽어도 완결된 답이 되나?
자주 묻는 질문
Q: 벡터 데이터베이스는 무엇인가요?
임베딩 벡터를 저장하고 유사도 검색을 빠르게 처리하는 전용 저장소입니다. Pinecone, Milvus, pgvector가 대표적이에요. 최근에는 일반 데이터베이스도 벡터 기능을 붙이는 추세라 경계가 점점 흐려지고 있습니다.
Q: 키워드 검색은 이제 필요 없나요?
아니요. 고유명사, 모델명, 정확한 문구 검색은 키워드 방식이 더 정확합니다. 그래서 실무 검색 시스템 상당수가 두 방식을 합친 하이브리드 검색을 씁니다.
Q: GEO를 하려면 벡터 검색을 직접 구축해야 하나요?
아닙니다. 벡터 검색은 AI 검색 서비스 쪽에서 이미 돌아가고 있습니다. 콘텐츠 제작자가 할 일은 그 검색에 잘 잡히는 문단 구조를 만드는 것뿐이에요.
검색의 최소 단위가 바뀌었다는 신호
벡터 검색이 알려주는 건 도구 이야기가 아닙니다. 검색의 최소 단위가 페이지에서 문단으로 내려왔다는 사실입니다. 예전 SEO가 페이지 단위 키워드 경쟁이었다면, 지금은 문단 하나하나가 독립된 검색 후보예요. 콘텐츠 전략의 단위도 거기에 맞춰 내려와야 합니다.
AI 검색 노출을 구조부터 점검하고 싶다면 서치폴라리스의 GEO 진단에서 시작해 보세요. 다른 용어가 궁금하면 GEO 용어사전에서 이어서 읽을 수 있습니다.
