Vector Search in Modern Databases

1. AI 시대, 데이터베이스의 새로운 패러다임

생성형 AI 의 등장은 기술 전문가뿐만 아니라 일반 대중에게도 인공지능의 경이로운 잠재력을 명확히 보여주었습니다. 텍스트, 이미지, 코드를 생성하는 AI 의 능력은 이제 단순한 기술적 호기심을 넘어 실질적인 비즈니스 애플리케이션으로 빠르게 통합되고 있습니다. 이러한 변화의 물결 속에서, 현대 데이터베이스는 중대한 전환점을 맞이하고 있습니다. 과거 데이터베이스의 핵심 역할이 데이터를 안정적으로 저장하고 정해진 규칙에 따라 검색하는 것이었다면, 이제는 복잡한 AI 애플리케이션의 두뇌 역할을 지원해야 하는 새로운 시대적 요구에 직면했습니다. 이는 단순히 새로운 기능을 추가하는 것을 넘어, 데이터베이스 아키텍처의 근본적인 진화를 요구하는 중요한 전략적 변화이며, 모든 데이터베이스 전문가가 주목해야 할 핵심 과제입니다.

데이터베이스 분야는 전통적으로 보수적이고 점진적인 변화를 선호하지만, Vector 검색 시장은 지난 5년간 폭발적인 성장을 기록했습니다. 2019년을 기점으로 주요 데이터베이스들이 Vector 검색 기능을 앞다투어 도입하기 시작했으며, 2021년에서 2023년 사이에는 그 수가 폭발적으로 증가했습니다. 이제 Vector 검색은 RDBMS 와 NoSQL 모두에게 선택이 아닌 필수적인 핵심 기능으로 자리 잡았습니다.

이러한 중요성은 시장의 주요 플레이어들의 전략에서도 명확히 드러납니다.

• ElasticSearch 는 자사의 GitHub 저장소에서 전통적인 강점인 Full-text search 보다 Vector 검색을 더 상위에 노출하며 “세계에서 가장 많이 다운로드된 Vector 데이터베이스”라고 홍보하고 있습니다.
• PostgreSQL 분야의 강자인 EnterpriseDB(EDB) 역시 ‘PostgreSQL AI’를 전면에 내세우며 AI 지원 기능을 핵심 마케팅 포인트로 삼고 있습니다.
• MongoDB 또한 AI 호환성 확보를 위해 막대한 투자를 이어가고 있습니다.

 

2. Vector 검색의 핵심 개념 이해

모든 AI 및 머신러닝 시스템의 연산은 근본적으로 Vector 와 행렬의 수학적 처리에 기반합니다. 따라서 Vector 검색의 가장 기본적인 구성 요소인 Embedding을 이해하는 것은 이 기술을 파악하는 데 있어 전략적으로 매우 중요합니다.

Embedding 은 이미지, 텍스트, 오디오와 같은 비정형 데이터를 AI 모델이 이해할 수 있는 고차원의 숫자 (Vector)로 변환하는 과정 또는 그 결과물을 의미합니다. 이 변환 작업은 수조 개의 파라미터를 가진 거대하고 복잡한 AI 모델에 의해 수행됩니다. 여기서 중요한 점은 Vector 의 각 차원이 인간이 직관적으로 해석할 수 있는 ‘색상’, ‘크기’ 와 같은 특정 의미를 갖지 않는다는 것입니다.

Embedding 의 가장 핵심적인 속성은 ‘의미적으로 유사한 개념은 Vector 공간에서 서로 가깝게 위치한다’ 는 것입니다. 예를 들어, ‘소녀’ 와 ‘여성’ 이라는 단어의 Embedding Vector 는 ‘자동차’ 라는 단어의 Vector보다 훨씬 더 가까운 거리에 존재하게 됩니다. 데이터베이스는 이 거리 값을 기반으로 의미적으로 유사한 데이터를 찾아냅니다.

다만, 한 가지 실질적인 고려사항이 있습니다. Embedding 은 그것을 생성한 AI 모델에 종속적입니다. 만약 사용하던 AI 모델을 변경하거나 업데이트하면, 기존의 모든 데이터를 새로운 모델을 사용해 Embedding 으로 다시 생성해야 하는 번거로움이 발생할 수 있습니다.

Vector 검색의 핵심 연산은 두 Vector 가 Vector 공간에서 얼마나 ‘가까운지’ 또는 ‘유사한지’를 측정하는 것입니다. 이를 위해 다양한 수학적 측정법이 사용되며, 가장 대표적인 세 가지는 다음과 같습니다.

• Cosine Similarity(코사인 유사도) : 두 Vector 간의 각도를 측정하여 방향성의 일치도를 평가합니다. Vector 의 크기는 무시하고 오직 방향만을 고려하기 때문에, 개념의 ‘강도’ 보다 ‘의미’ 자체가 중요한 시맨틱 검색에 특히 효과적입니다.
• Euclidean Distance(유클리드 거리) : 두 Vector 의 끝점을 잇는 가장 짧은 직선거리를 계산합니다. 우리가 공간에서 거리를 인식하는 방식과 가장 유사합니다.
• Dot Product(내적) : 두 Vector 의 크기와 그 사이각의 코사인 값을 모두 곱한 값입니다. 크기와 방향성을 동시에 고려합니다.

이 중에서 코사인 유사도는 Vector 의 크기보다는 방향성에 초점을 맞추기 때문에 가장 보편적으로 사용되며, OpenAI 에서도 권장하는 방식입니다.

 

3. 데이터베이스에 Vector 검색 통합하기

Vector 검색을 위해 왜 새로운 데이터베이스 아키텍처가 필요한지에 대한 근본적인 이유는 전통적인 인덱스의 한계에서 찾을 수 있습니다. 데이터베이스의 성능을 좌우하는 인덱스는 특정 데이터를 빠르게 찾기 위한 기술이지만, 기존의 인덱스 구조는 Vector 검색에 전혀 적합하지 않습니다.

B-Tree 와 같은 전통적인 인덱스는 숫자나 문자열 같은 스칼라(Scalar) 값의 ‘같음(equality)’, ‘큼(greater than)’, ‘작음(less than)’을 비교하는 연산에 고도로 최적화되어 있습니다. 하지만 수백, 수천 차원의 Vector 간 거리를 계산하는 연산에는 이러한 인덱스를 활용할 수 없습니다. 결국 데이터베이스는 인덱스를 사용하지 못하고 테이블의 모든 데이터를 하나씩 비교하는 Full Table Scan 을 수행할 수밖에 없습니다. 데이터의 양이 조금만 많아져도 성능이 끔찍하게 느려지는 결과를 초래합니다. 이는 실시간 응답성이 요구되는 AI 애플리케이션에서는 서비스 장애로 직결될 수 있는 치명적인 한계입니다.

그래서 전통적인 인덱스의 한계를 극복하기 위해, Vector 검색에 특화된 새로운 유형의 인덱스들이 개발되었습니다. 이 인덱스들은 근사 근접 이웃(Approximate Nearest Neighbor, ANN) 탐색 알고리즘을 기반으로 합니다. ANN 은 가장 정확한 ‘최근접 이웃’을 찾는 대신, 약간의 오차를 허용하면서도 훨씬 빠른 속도로 ‘거의 가장 가까운’ 이웃들을 찾는 방식입니다.

현재 가장 널리 사용되며 매우 인기 있는 Vector 인덱스 유형은 HNSW(Hierarchical Navigable Small World)입니다. 그 외에도 k-d trees, Annoy 등 다양한 알고리즘 기반의 인덱스들이 존재하며, 더 빠르고 효율적인 알고리즘을 개발하기 위한 연구가 활발히 진행되고 있습니다.

Vector 검색의 도입은 데이터베이스 쿼리에 대한 근본적인 패러다임 전환을 의미합니다.

• 전통적인 SQL 쿼리 : 동일한 데이터에 대해 동일한 쿼리를 실행하면 항상 100% 동일한 결과를 반환하는 ‘정확성(Exactness)’ 을 추구합니다.
• Vector 검색 쿼리 : 100% 정확한 결과를 포기하는 대신, 약간의 오류를 허용하여 검색 속도를 극적으로 높이는 ‘근사(Approximate)’ 방식을 채택합니다.

이때 성능을 측정하는 중요한 지표로 ‘리콜(Recall)’ 이 사용됩니다. 예를 들어, ‘리콜 95%’ 는 검색 결과 집합의 95% 는 실제로 쿼리와 가장 유사한 정확한 데이터이지만, 나머지 5% 는 관련성이 떨어지는 데이터일 수 있음을 의미합니다. 이러한 확률적 특성은 질문할 때마다 조금씩 다른 답변을 생성하는 LLM 애플리케이션의 본질과 잘 부합합니다.

 

4. AI 애플리케이션에서의 전략적 활용

Vector 검색의 진정한 가치는 키워드 기반 검색의 한계를 돌파하는 Semantic 검색(의미 기반 검색) 을 구현하는 데서 드러납니다. 키워드의 정확한 일치에만 의존했던 과거와 달리, Semantic 검색은 사용자가 입력한 쿼리의 ‘의미’ 와 ‘의도’ 를 파악하여 결과를 도출합니다.

AI 모델이 단어의 의미를 이해하고 있기 때문에 동의어, 철자 오류, 단어의 여러 형태(형태론) 등을 별도의 처리 없이 자동으로 처리할 수 있습니다. 더 나아가, 언어의 장벽을 넘어 다국어 검색을 지원하고, 텍스트와 이미지 등 서로 다른 형태의 데이터를 넘나드는 다중 모드 검색까지 가능하게 합니다.

• GitHub 검색 사례: 사용자가 ‘memory leak’라는 키워드를 직접 입력하지 않았음에도, 메모리 관리와 관련된 문제에 대한 게시글을 정확하게 찾아냅니다. 이는 모델이 키워드가 아닌 ‘메모리 문제’라는 개념 자체를 이해하고 있기에 가능합니다.
• 이미지 검색 사례: 이미지 컬렉션에서 ‘formal shoes(정장 구두)’라는 텍스트 쿼리를 입력하면, AI 모델이 텍스트의 의미를 이해하고 그에 맞는 신발 이미지를 정확하게 찾아 반환합니다.

Retrieval-Augmented Generation(RAG, 검색 증강 생성) 은 엔터프라이즈 환경에서 각광받는 핵심적인 AI 활용 사례입니다. 대부분의 기업은 자사의 민감한 내부 데이터를 외부에 있는 공개 LLM 모델에 직접 노출시키는 것을 꺼리면서도, LLM 이 가진 강력한 언어 능력을 활용하고 싶어 합니다.

RAG는 이러한 요구를 해결하는 아키텍처입니다. 그 과정은 다음과 같습니다.

1. 사용자가 질문을 입력합니다.
2. 시스템은 이 질문을 Vector 로 변환하여, 사내 문서, 데이터베이스 등 내부 지식 베이스에서 Vector 유사도 검색을 수행합니다.
3. 검색을 통해 질문과 가장 관련성이 높은 문서를 찾습니다.
4. 이 문서의 내용(맥락)을 사용자의 원래 질문과 함께 LLM 에 전달합니다.
5. LLM 은 주어진 내부 데이터와 자신의 일반 지식을 결합하여, 기업의 맥락에 맞고 사실에 기반한 안전한 답변을 생성합니다.

이 방식을 통해 기업은 데이터 보안을 유지하면서 최신 AI 기술의 이점을 누릴 수 있습니다.

 

5. Vector 검색 생태계와 성능 분석

오픈 소스 데이터베이스 진영에서 AI 애플리케이션 지원의 ‘리더’ 는 단연 PostgreSQL 입니다. PostgreSQL 의 강점은 강력한 확장 기능 생태계를 바탕으로 한 계층적 AI 지원 구조에 있습니다.

• 1단계(PGVector) : Vector 데이터 타입과 유사도 검색 기능을 추가하는 기본적인 확장 기능입니다.
• 2단계(PGVectorize) : pgvector 위에 구축되며, LLM 과의 연동 및 Embedding 생성 자동화와 같은 편의 기능을 추가로 제공합니다.
• 3단계(PostgresML) : PostgreSQL을 기반으로 완전한 AI/ML 애플리케이션을 구축할 수 있도록 돕는 통합 플랫폼입니다.

또한, pgvector 외에도 더 나은 성능을 주장하는 vectorcove 와 같은 경쟁 확장 기능이 존재하는 것은 PostgreSQL 생태계가 얼마나 활발하게 발전하고 있는지를 보여주는 증거입니다.

PostgreSQL 이 선두에 있지만, 다른 데이터베이스들 역시 치열한 경쟁을 벌이고 있습니다. MariaDB 는 Vector 검색 기능 개발에 많은 투자를 하고 있으며, 저명한 데이터베이스 성능 전문가인 Mark Callaghan 의 벤치마크에서 매우 우수한 성능을 보여주며 강력한 경쟁자로 부상했습니다.

반면, MySQL 은 Vector 검색 기능을 독점 버전에서만 제공하여, 오픈 소스 개발자 커뮤니티에서는 이를 ‘적대적(hostile)’인 정책으로 간주합니다. 이러한 정책은 MySQL 커뮤니티의 AI 애플리케이션 개발 활성화를 저해하는 요인으로 작용할 수 있습니다.

 

6. Vector 검색의 미래와 전망

Vector 검색 기술은 효율성과 접근성을 높이는 방향으로 진화하고 있으며, 그 중심에는 ‘양자화(Quantization)’ 가 있습니다.

양자화는 Vector 를 구성하는 고정밀도 숫자(예: 32비트 부동소수점)를 더 낮은 정밀도의 숫자(예: 8비트 정수 또는 1비트)로 압축하는 기술입니다. 이를 통해 Vector 데이터셋의 전체 크기를 수십 배까지 획기적으로 줄일 수 있습니다. 양자화 기술의 발전은 약간의 품질 저하만으로 메모리 사용량과 연산 비용을 크게 절감시켜, 과거에는 고가의 전문 하드웨어가 필요했던 고성능 AI 모델을 저렴한 일반 서버에서도 실행할 수 있게 만듭니다. 이는 AI 기술의 접근성을 크게 높여 더 많은 애플리케이션에 Vector 검색이 도입되는 기폭제가 될 것입니다.

AI 모델의 발전은 데이터베이스 아키텍처에도 새로운 가능성을 제시하고 있습니다. 최근 주목받는 트렌드는 LLM 의 Large Context Window 를 활용하는 것입니다. 이는 RAG의 대안이 될 수 있습니다.

만약 AI 가 참조해야 할 기업의 내부 지식 베이스의 전체 크기가 충분히 작다면, RAG 처럼 검색을 통해 관련 문서를 찾는 복잡한 과정을 거치는 대신, 모든 문서 데이터를 LLM 의 Context Window 에 직접 입력하는 방식이 가능해집니다. 일부 사례에서는 이 방식이 RAG 보다 더 정확하고 맥락에 맞는 결과를 제공하는 것으로 나타났습니다. 앞으로 LLM 의 Context 처리 용량이 계속해서 커짐에 따라, 이 아키텍처는 더 많은 주목을 받게 될 것입니다.

AI 애플리케이션 지원은 미래 데이터베이스의 선택 사항이 아닌 필수 불가결한 핵심 기능이 될 것이며, 그 중심에는 Vector 검색 기술이 자리할 것입니다.

앞으로 데이터베이스 시장은 두 가지 방향으로 함께 발전할 것으로 예측됩니다. 첫째, PostgreSQL 과 같은 범용 데이터베이스는 AI 지원 기능을 지속적으로 강화하여 대부분의 개발자들이 손쉽게 AI 애플리케이션을 구축할 수 있도록 지원할 것입니다. 둘째, 동시에 극도의 성능과 특화된 기능이 필요한 고급 사용 사례를 위해 전문 Vector 데이터베이스 시장 또한 함께 성장할 것입니다.

궁극적으로, 과거에 다른 모든 데이터베이스 기능들이 그래왔던 것처럼 Vector 검색 기술 역시 성능, 효율성, 그리고 사용 편의성 측면에서 끊임없는 혁신을 거듭하며 데이터 기술의 새로운 지평을 열어갈 것입니다.

블로그 원문 : https://www.youtube.com/watch?v=hGduvEE2Uxg

 

 

자유롭게 댓글을 달아주세요! 언제나 환영합니다.
기타 문의:  info@neoclova.co.kr
네오클로바 기술블로그 홈 바로가기: https://neoclova.net
네오클로바 홈페이지: http://neoclova.co.kr