개념
시맨틱 검색(semantic search)은 질의와 문서를 각각 임베딩 벡터로 바꾼 뒤, 벡터 공간에서 가까이 있는 것을 관련 있는 문서로 판단하는 검색 방식이다. 기존의 키워드 검색이 "같은 단어가 들어 있는가"를 물었다면, 시맨틱 검색은 "같은 뜻을 담고 있는가"를 묻는다.
이 차이는 표현이 어긋날 때 드러난다. "출장비 정산은 어떻게 하나요"라는 질문에 대해 키워드 검색은 그 단어들이 그대로 등장하는 문서만 찾지만, 시맨틱 검색은 "여비 청구 절차"라는 제목의 문서도 함께 찾아낸다. 같은 개념을 다른 말로 적어 둔 문서, 줄임말이나 외래어 표기가 다른 문서도 걸린다.
실제 구현에서는 문서를 적당한 크기의 조각으로 나눠 각각을 벡터로 만들어 벡터 데이터베이스에 저장해 둔다. 검색 시점에는 질의도 같은 모델로 벡터화한 다음, 코사인 유사도 같은 척도로 가장 가까운 조각 몇 개를 꺼낸다. 문서 수가 많으면 모든 벡터를 일일이 비교하지 않고 근사 최근접 이웃 탐색으로 후보를 좁힌다.
주의할 점은 질의와 문서가 반드시 같은 임베딩 모델로 변환되어야 한다는 것이다. 모델이 다르면 벡터가 놓이는 공간 자체가 달라져 거리 계산이 의미를 잃는다. 그래서 임베딩 모델을 교체할 때는 저장된 벡터 전체를 다시 만들어야 하며, 이 재색인 비용이 모델 선택을 되돌리기 어렵게 만드는 요인이 된다.
쓰임새
가장 흔한 무대는 검색 증강 생성(RAG)이다. 사용자의 질문으로 사내 문서를 시맨틱 검색해 관련 조각을 찾고, 그 내용을 프롬프트에 담아 모델이 근거를 갖고 답하게 만든다. 고객 문의를 과거 응대 기록과 연결하거나, 유사 사례·중복 문서를 찾아내는 용도로도 쓰인다.
실무에서는 키워드 검색과 함께 쓰는 하이브리드 구성이 흔하다. 제품 코드나 사번처럼 정확히 일치해야 하는 문자열은 키워드 검색이 강하고, 풀어 쓴 질문은 시맨틱 검색이 강하기 때문에 둘의 결과를 합쳐 순위를 다시 매기는 방식이 안정적이다. 여기에 부서나 작성일 같은 조건으로 후보를 먼저 걸러 내는 필터를 얹으면, 오래된 문서가 상위에 올라오는 문제를 줄일 수 있다.
한국어 환경에서는 표기 흔들림이 특히 문제가 된다. 같은 개념을 한글로도 쓰고 영문 약어로도 쓰는 문서가 섞여 있으면 키워드 검색만으로는 절반을 놓친다. 시맨틱 검색이 이 간극을 메워 주기 때문에, 사내 문서 검색에서 체감 효과가 큰 편이다.
자주 하는 오해
시맨틱 검색이 키워드 검색보다 항상 나은 것 아닌가?
정확한 식별자나 고유명사를 찾을 때는 오히려 뒤진다. 의미가 비슷한 것을 잘 찾는다는 성질은 곧 "약간 다른 것도 비슷하다고 판단한다"는 뜻이라, 정밀한 일치가 필요한 자리에서는 약점이 된다.
유사도 점수가 높으면 정답이 들어 있는 것 아닌가?
유사도는 질의와 문서가 비슷한 화제를 다룬다는 신호일 뿐, 그 문서가 답을 담고 있다는 보장은 아니다. 관련은 있지만 정작 답은 없는 문서가 상위에 오르는 일이 흔하다.
검색 품질은 임베딩 모델이 결정하지 않나?
문서를 어떻게 잘라 두었는지가 결과를 크게 좌우한다. 조각이 지나치게 크면 관련 없는 내용이 섞이고, 너무 작으면 맥락이 잘려 의미가 흐려진다. 모델을 바꾸기 전에 자르는 방식부터 손보는 편이 대체로 효과가 빠르다.