MongoDB 벡터 검색과 자동 임베딩(autoEmbed): 키워드 검색과 무엇이 다를까

핵심 메시지

• 키워드 검색은 입력한 문자열을 문서에서 그대로 대조하기 때문에 'how do I use tools' 같은 자연어 질문에 취약하지만, 벡터(의미) 검색은 개념적으로 가까운 문서를 찾아낸다.
• 임베딩은 단어나 문장을 좌표(벡터) 배열로 바꾼 것으로, 의미가 비슷한 항목일수록 벡터 공간에서 가까이 모인다. 실제 임베딩은 좌표 두 개가 아니라 수천 개의 부동소수점 값으로 이뤄진다.
• 기존에는 벡터 DB, 콘텐츠 DB, 임베딩 모델을 따로 다뤄야 했지만, MongoDB의 autoEmbed 인덱스는 콘텐츠를 넣기만 하면 임베딩을 자동 생성해 이 세 조각을 하나로 합친다.
• MongoDB는 Voyage AI를 통해 임베딩을 만들며, 데이터를 bulkWrite로 적재할 때 임베딩 요청을 자동으로 처리한다.
• 임베딩은 LLM의 문서 검색 도구와 에이전트 메모리의 토대가 되어 그 어느 때보다 중요해지고 있다.

쉽게 이해하기

영상은 TanStack Start로 만든 간단한 검색 앱에 TanStack AI 문서를 MongoDB로 적재해 두고, 같은 질의를 키워드 검색과 벡터 검색으로 나란히 비교하며 시작한다. 키워드 검색은 'tool'이라는 문자열을 대소문자 구분 없이 문서에서 그대로 찾을 뿐이어서, 'how do I use tools' 같은 자연어 질문은 그런 표현이 문서에 없으면 걸리지 않는다. 반면 벡터 검색은 같은 질문에 훨씬 좋은 결과를 돌려주고, 'LLM에 내 데이터 접근 권한을 주려면?'이라는 질문에는 server tools를 두 번째 결과로 제시한다.

벡터 검색의 원리는 임베딩에 있다. 발표자는 Draw.io로 그린 좌표 평면에서 server, tool, serverTool, chat, bot, text 같은 용어가 의미가 가까운 것끼리 군집을 이루는 모습을 보여 준다. 임베딩은 이런 위치를 나타내는 좌표(벡터) 배열이며, 예시에서는 좌표가 두 개뿐이지만 실제로는 수천 개의 부동소수점 값으로 이뤄진다. 검색할 때는 사용자의 질의를 임베딩 모델에 넣어 벡터로 바꾼 뒤, 그 벡터와 좌표가 가장 가까운 문서들을 특수 인덱스로 빠르게 찾는다.

MongoDB에서의 구현은 인덱스 생성에 핵심이 있다. 로컬 MongoDB에 'docs_autoembed'라는 vectorSearch 타입 인덱스를 만들고 content 필드에 autoEmbed를 붙이면, 문서를 넣을 때 그 콘텐츠에 대한 임베딩이 자동으로 생성된다. 원래 임베딩 작업은 벡터 DB, 콘텐츠 DB, 임베딩 모델이라는 세 부분을 각각 다뤄야 하는 수작업이었는데, MongoDB는 이를 한데 모았다. 임베딩 생성에는 MongoDB와 연관된 Voyage AI를 쓰며, 계정을 만들어 API 키를 발급받아 환경 변수로 MongoDB에 넘겨주면 된다.

적재 코드(ingest.ts)는 각 마크다운을 content 필드를 가진 문서로 만들어 bulkWrite로 한 번에 저장하고, 그 뒤 MongoDB가 Voyage AI로 요청을 보내 임베딩을 받아 자동으로 채운다. 검색 코드를 비교하면, 정규식을 이스케이프해 제목과 본문을 대조하는 키워드 검색이 오히려 벡터 검색보다 네 줄 더 길다. 벡터 검색은 앞서 만든 docs_autoEmbed 인덱스에 대상 경로(content)와 질의를 주면 되지만, 이때 질의도 voyage 모델로 임베딩해 좌표로 바꾼 뒤 그 좌표로 인덱스를 조회한다는 점이 중요하다.

마지막으로 이 임베딩을 LLM 채팅에 쓰는 예를 보여 준다. TanStack AI로 만든 채팅에 'How do I use server tools in TanStack AI?'라고 물으면, AI가 searchDocs 도구를 호출하고 그 도구가 임베딩으로 알맞은 문서를 찾아 LLM에 전달해 답을 만든다. 발표자는 LLM이 에이전트 메모리처럼 동작하려면 벡터 검색이 필요하다고 설명한다. 에이전트 메모리는 질의와 관련된 기억을 벡터 검색으로 찾는 방식이어서, 임베딩과 자동 임베딩이 데이터베이스의 점점 더 중요한 기능이 되고 있다.

주요 인사이트

• 벡터 검색은 동일한 단어가 문서에 없어도 개념적으로 관련된 결과를 반환해 자연어 질문에 강하다.
• 수작업이던 임베딩 생성을 인덱스 설정만으로 자동화하면, 오히려 구현 코드가 키워드 검색보다 짧아질 수 있다.
• 검색 시점에도 임베딩이 필요하다. 질의를 같은 임베딩 모델로 벡터화해야 인덱스 조회가 가능하다.
• 별도의 벡터 DB를 운영하지 않고 데이터베이스 안에서 검색과 임베딩을 함께 처리해 인프라를 단순화한다.
• 문서 검색 도구와 에이전트 메모리가 모두 벡터 검색에 의존하므로 임베딩의 중요성이 커진다.

자주 묻는 질문

관련 AI 소식