[컴퓨터월드] 생성형 인공지능(Gen AI)이 전 세계 모든 산업분야에서 혁신을 일으키고 있다. 하지만 해결해야 할 문제점도 많다. 엉뚱한 답변을 제시하는 환각(Hallucination) 현상, 학습 데이터에 따른 결과물 편향 등이 대표적이다. 최근 이러한 문제를 해결할 수 있도록 해주는 검색 증강 생성(RAG, Retrieval Augmented Generation) 기술이 부상하고 있다. 이런 상황에서 RAG를 위한 저장소로 사용되는 데이터베이스(DB)인 벡터 DB(Vector DB) 역시 떠오르고 있다. 벡터 DB는 비정형 데이터를 수치화해 벡터 형태로 저장해 빠르게 검색할 수 있고 최신화된 데이터를 언제든 연동할 수 있다는 점에서 각광받고 있다.

딥러닝 일종인 ‘LLM’

특정 데이터가 특정 공간에 있다는 것을 나타내는 위치정보(좌푯값, 실수로 나열된 값)를 의미하는 벡터. 이를 저장하는 데이터베이스인 벡터 DB는 생성형 AI가 떠오르면서 함께 주목받고 있다. 물론 벡터 DB는 새로운 데이터베이스(DB)가 아니다. 2012년 딥러닝(Deep Learning)이 본격적으로 발전하던 때부터 존재했었다.

인공 신경망을 이용해 데이터를 학습하고 분석하는 기술인 딥러닝은 머신러닝(Machine Learning)과는 달리 피처 엔지니어링(Feature Engineering)을 거치지 않는다. 피처 엔지니어링은 머신러닝 모델의 성능을 높이고자 머신러닝 모델이 이해하기 쉬운 형태로 인간이 개입해 피처(특징, Feature)값을 지정하는 과정이다. 이와 달리 딥러닝은 피처를 지정하지 않고 데이터를 읽어 스스로 벡터화해 자연스럽게 피처를 갖는 구조다.

머신러닝 모델의 경우 ‘노란색의 길죽한 과일은 바나나’라는 피처를 입력해야 바나나 사진을 보고 바나나라는 결과를 도출하는 데 반해 딥러닝은 바나나 사진을 주고 ‘노란색’, ‘길죽하다’, ‘과일’이라는 피처를 스스로 도출하게끔 한다. 또한 딥러닝은 별도의 피처를 지정하지 않아도 딥러닝 모델에 데이터를 입력하면 스스로 벡터화하고 유사한 피처를 가진 벡터값끼리 모여 군집을 구성한다.

이렇게 유사한 벡터값끼리 군집을 형성한 딥러닝 모델을 학습시키기 위해선 벡터 데이터에 특화된 데이터 저장소가 필요하다. 이러한 요구에 따라 정형화된 데이터가 아닌 비정형 데이터를 빠르게 벡터화(임베딩, Embedding)해 저장하고 읽을 수 있는 벡터 DB가 등장했다.

최근 LLM 기반 생성형 AI가 떠오르면서 벡터 DB가 조명받고 있다. 딥러닝의 일종인 LLM은 대규모 텍스트 데이터를 학습해 자연어를 이해하고 생성하는 언어 모델이다. 즉 LLM은 딥러닝의 한 종류로 벡터 데이터로 이루어진 언어모델이라는 것이다.

실제 벡터 데이터로 이뤄진 LLM에는 이미 데이터들을 저장하는 벡터 DB가 내장돼 있다. 다만 데이터 최신화를 위해 재학습을 할 경우에는 처음 LLM을 도입할 때와 비슷한 비용이 들어간다. 때문에 LLM에 내장된 벡터 DB는 그대로 두고 외부에 별도에 벡터 DB를 구축해 연결하는 방식을 취하고 있다.

4가지 특장점 보유

생성형 AI가 발전함에 따라 백터 데이터를 효과적으로 다룰 수 있는 DB의 필요성이 제기됐다. 그 해답으로 과거 딥러닝 모델 학습에 쓰이던 벡터 DB가 부상하기 시작한 것이다.

벡터 DB는 △벡터 데이터 처리 △벡터 검색 및 유사성 분석 △대용량 벡터 데이터 처리 △벡터 데이터 갱신 등에 특화된 장점을 갖고 있다.

먼저 벡터 데이터를 처리하는 데 특화돼 있다. 생성형 AI에서는 주로 벡터 데이터가 이용된다. LLM 내 토큰이 벡터화돼 내장된 벡터 DB에 저장돼 있기 때문이다. 생성형 AI에서는 주로 이미지, 음성, 텍스트 등 비정형 데이터가 벡터 형태로 변환돼 처리되는데, 벡터 DB는 벡터 데이터를 효과적으로 저장하고 관리할 수 있다.

다음으로는 벡터 검색 및 유사성 분석에 특화된 기능을 제공한다는 점이다. 이에 대해 EDB 측 관계자는 “생성형 AI에서는 벡터 데이터 간의 유사성을 분석하거나 벡터 데이터 검색이 필요한 경우가 많다. 벡터 DB는 이러한 요구사항에 특화된 기능을 제공해 벡터 데이터 간 유사성을 효과적으로 계산하고 검색할 수 있다. 따라서 생성형 AI에서는 벡터 DB를 통해 빠르고 정확한 벡터 검색 및 유사성 분석이 가능하다”고 설명했다.

네이버클라우드 허창현 클라우드 솔루션 아키텍트는 “벡터 DB는 사실 타 DBMS와 큰 차이가 없다. 다만 다루는 데이터의 성격과 처리 방법이 다르다. 벡터 DB는 주로 실수(Real Number) 형태의 데이터가 포함된다. 또 실수 형태의 데이터를 기반으로 유사도가 높은 결과를 추출하기 위해 다양한 방법을 제공할 수 있다”면서 “벡터화된 데이터 간의 유사도를 측정하는 데에는 주로 ‘코사인 유사도(Cosine Similarity)’와 ‘유크리드 거리(Euclidean Distance)’ 등의 측정 방법이 활용된다. 코사인 유사도는 두 벡터 사잇각을 통해 벡터 데이터가 얼마나 유사도가 있는지 측정하는 방법이며, 유크리드 거리는 평면에서의 두 벡터값 사이의 직선거리를 측정해 값 사이의 유사도를 파악하는 방법이다”라고 설명했다.

이어 그는 “벡터 DB는 의미 기반의 쿼리를 가능하게 한다. 기존 DBMS는 각 스키마의 관계를 통해 데이터를 효율적으로 추출하는 데 중점을 두지만, 벡터 DB는 수치화된 벡터의 의미를 효과적으로 추출하는 데 중점을 둔다. 수치화된 데이터 저장과 유사도 측정을 위한 다양한 알고리즘을 제공하는 DB가 바로 벡터 DB다”라고 덧붙였다.

세 번째로는 대용량 벡터 데이터 처리가 가능하다는 점이다. 생성형 AI 모델은 대용량의 벡터 데이터를 다룬다. 벡터 DB는 대용량의 벡터 데이터를 효과적으로 저장하고 처리할 수 있는 기능을 제공하기 때문에 생성형 AI 모델의 대규모 데이터에 대응할 수 있다. 널리 쓰이는 관계형 데이터베이스(RDB)는 벡터 데이터의 길이나 형태의 다양성, 쿼리 및 인덱싱, 데이터 모델 무결성 제약 등 때문에 벡터 데이터를 저장하기에 적합하지 않다.

엔코아 김범 사업부문장은 “벡터 DB는 정형 데이터부터 비정형 데이터까지 모두 임베딩해 벡터 형태로 저장하고 검색하는 데 사용된다. 널리 이용되는 RDB가 정형 데이터를 저장하고 검색하는 데 최적화돼 있다면, 벡터 DB는 이미지나 문서 등 데이터 구조가 부재해 쿼리 프로세싱(Query Processing)을 할 수 없는 비정형 데이터의 저장과 검색에 용이하다”고 부연했다.

벡터 DB는 벡터 데이터의 갱신 및 쿼리에 대한 기능을 제공한다. 벡터 DB는 일반적으로 단독으로 쓰이지 않는다. 대부분의 경우 LLM을 벡터 DB가 연결된 랭체인(LangChain)이라는 언어 데이터를 수집하고 저장하는 플랫폼을 연결해 이용하는 구조다. 데이터 소스. 단어 임베딩, 벡터 DB 등을 LLM과 연결하는 매개라고 볼 수 있다. 개별로 구축된 벡터 DB에 최신의 데이터를 임베딩해 저장하면 LLM 재학습 하지 않고도 최신 데이터를 LLM에 적용할 수 있게 된다.

오라클 장성우 전무는 “생성형 AI의 치명적인 문제로 꼽히는 환각 현상은 상당 부분 데이터 최신화 문제 때문에 발생한다. LLM은 특정 시점까지 학습된 데이터로 구축된다. 때문에 학습 데이터를 꾸준히 최신화해야 한다. 그러나 학습 데이터를 최신화 하기 위해서는 인프라 비용, GPU 비용, 인력 투입 등 많은 비용과 시간이 필요하다. 이런 문제의 상당부분을 벡터 DB로 해결할 수 있다”고 설명했다.

[인터뷰] “벡터 DB 구축 시 고려사항 철저히 파악해야”

Q. 벡터 DB를 구축 과정에서 주의해야 할 사항은.
A. 일반적으로 LLM의 환각을 없애기 위한 RAG 구현 용도로 벡터 DB를 고려하곤 한다. 이때 벡터 DB 구축 시 중요한 것은 벡터 DB의 크기와 LLM이 갖고 있는 콘택스트 크기가 동일해야 한다.

구체적으로 LLM은 문장을 구성하는 개별 단어 또는 문자인 ‘토큰(Token)’으로 구성된다. 또 이 토큰들의 조합인 콘택스트(Context)의 크기가 LLM의 성능을 좌우한다. 가령 ‘안녕하세요. 오늘 날씨가 좋네요’라는 문장에서 토큰은 ‘안녕하세요’, ‘.’, ‘오늘’, ‘날씨가’, ‘좋네요’라는 5개의 토큰으로 구성된다. 토큰은 벡터화된다. 이때 콘택스트는 ‘오늘’이라는 시간과 ‘날씨가 좋다’는 정보를 의미한다. 이 콘택스트는 언어모델이 문장의 의미를 파악하는 역할을 하며 곧 LLM 성능과 직결된다. 벡터화된 토큰, 콘택스트의 크기는 곧 LLM이 수용할 수 있는 벡터의 크기다. 벡터 DB의 크기는 매핑된 LLM이 보유한 콘택스트 크기와 동일해야 한다. 그래야 벡터 DB에서 불러온 실수로 표시되는 벡터 데이터를 LLM이 이해하고 자연어로 치환할 수 있다.

Q. 오라클의 DB 23c를 이용한다면 어떠한 장점이 있는가.
A. 시중에 존재하는 벡터 DB 제품 및 기능은 대동소이하다. 하지만 오라클 23c 벡터 기능의 특장점은 하나의 DBMS 서버에 동시에 접속해 데이터를 이용할 수 있도록 하는 기술인 ‘RAC(Real Active Clustering)’와 DB를 여러 개의 작은 조각(샤드)으로 분할해 각각의 서버에서 처리하는 기술인 ‘샤딩(Sharding)’, DB 서버, 스토리지, 네트워크를 하나의 시스템으로 통합한 어플라이언스 형태의 ‘엑사데이터(Exadata)’ 등을 벡터 타입에서도 그대로 이용할 수 있다는 점이다. 이 3가지 기술은 오라클이 DB 업계를 주도할 수 있도록 만들어 준 요소들이다. 사용자가 보유한 데이터가 많을수록, 이에 따라 벡터 DB의 크기가 클수록 더욱 안정적이고 높은 성능을 발휘한다.

Q. 벡터 DB를 구축하고자 하는 기업 및 조직에게 조언한다면.
A. 벡터 DB 구축과정을 설계할 때 데이터 범위와 규모를 사전에 잘 설정해야 한다는 점과 보안관리에 중점을 둬야 한다는 점 등 2가지를 강조하고 싶다. 먼저 벡터 DB를 구축할 때 향후 벡터 DB의 크기를 미리 고려해야 한다는 점이다. 얼마나 많은 데이터(지식)를 벡터화할 것인지에 따라 하위 인프라를 구축해야 한다. 이를 위해선 벡터 DB로 구축하고자 하는 전체 데이터 범위와 규모를 잘 설정해야 한다. 전체 데이터 범위를 설정한 이후에 내·외부 LLM을 쓸 것인지, 할루시네이션을 없애기 위한 메커니즘은 어떻게 구성할 것인지, 어떤 벡터 DB를 쓸 건지 등을 결정해야 한다. 데이터 규모 외에도 어떤 LLM인지에 따라 콘택스트 사이즈와 프롬프트 사이즈가 모두 상이하다. 이러한 일련의 과정이 모두 데이터 범위와 규모를 설정한 이후부터 연결되기 때문에 구축 첫 단계에서 충분히 큰 그림을 그려보고 벡터 DB를 설계할 필요가 있다.

아울러 설계 시 보안에 무게를 둬야 한다는 점도 강조하고 싶다. 벡터화돼 벡터 DB에 저장되는 데이터는 모두 회사의 자산이다. 보안이 중요하기 때문에 LLM을 학습시키지 않는 것이다. LLM의 파인튜닝을 하지 않고 벡터 DB를 구축하기 때문에 접근관리, 권한관리 등 보안도 초기부터 검토해야 한다. 벡터 DB와 매핑되는 LLM과의 상관관계(물리적인 요소)를 감안해 설계 시 보안사항도 검토해야 한다.

데이터 저장 및 읽기까지 9단계 과정 필요

통상 벡터 DB에 데이터를 저장하고 이를 읽어오기까지는 9단계 과정이 필요하다. 기업이 자체적으로 작성한 신입사원 백서 파일을 벡터 DB에 저장하고 신입사원이 기업 전용 생성형 AI 챗봇에 질의하고 받기까지 과정을 예로 들어 보자. 먼저 구축된 벡터 DB에 덩어리(청크, Chunk) 형태로 백서 파일을 변환해야 한다. 청크는 의미 있는 단위로 나누는 것을 의미한다. 이후 청크 형태로 바뀐 신입사원 백서 데이터를 임베딩 모델에 넣어 벡터화한다. 이렇게 벡터화된 신입사원 백서 데이터를 벡터 DB에 넣기 전 인덱싱(Indexing)을 통해 정렬하고 벡터 DB에 저장한다. 여기까지가 신입사원 백서 파일을 벡터화하고 벡터 DB에 저장하는 과정으로 볼 수 있다. 이때 사내 규정 및 거버넌스가 바뀌면서 백서가 수정될 경우 벡터 DB에 실시간으로 반영할 수 있어야 한다.

이후 신입사원이 기업용 생성형 AI 챗봇에 입사 첫해 여름휴가를 최대 며칠까지 사용할 수 있는지 질의한다면, LLM과 연동된 랭체인을 통해 쿼리를 임베딩 모델에 넣어 벡터화한다. 이후 벡터화된 질의문을 벡터 DB 내 인덱스에서 유사 벡터 군집(휴가에 대한 정보들) 및 벡터 데이터(입사 첫해 여름휴가 정보)를 찾고 이를 다시 LLM에 보내 사용자가 이해할 수 있는 답변으로 치환해 보여주는 방식이다. 이러한 과정은 타 DB와 별다른 차이점이 없다.

핵심은 ‘임베딩과 인덱싱’

그러나 벡터 DB에 데이터를 저장하고 읽는 데는 중요한 과정이 있다. 바로 임베딩과 인덱싱이다. 임베딩이라는 단어는 인공지능(AI) 모델을 학습시키기 위해 사용되는 데이터를 의미하기도 한다. 하지만 벡터 DB에서는 ‘데이터의 벡터화’라는 의미를 내포하고 있다. 대용량의 데이터를 벡터 공간에 표현하는 기술로, 데이터 간 유사도를 계산하거나 특성을 분석하는 등의 작업을 수행할 수 있다.

오라클 장성우 전무에 따르면, 임베딩은 ‘벡터 공간 생성’, ‘데이터의 벡터화’, ‘벡터 저장’ 등으로 구분된다. 장성우 전무는 “먼저 벡터 DB에 저장할 데이터의 특성을 고려해 적절한 차원의 벡터 공간을 생성해야 한다. 이때 벡터 공간의 차원은 데이터의 특성과 저장 공간의 크기 등을 고려해 결정해야 한다. 이어 생성한 벡터 공간에 데이터를 벡터화(Vectorization)한다. 데이터의 특성을 최대한 반영할 수 있도록 다양한 벡터화 방법을 사용하는데, 대표적으로 정보검색과 텍스트 마이닝에서 이용하는 단어에 대한 중요도를 계산할 수 있는 ‘TF-IDF(Term Frequency-Inverse Document Frequency)’와 지역적 문맥을 고려해 딥러닝으로 단어를 벡터화하는 대표적인 자연어 임베딩 방법 ‘워드투벡(Word2Vec)’, 카운트 기반과 예측 기반을 모두 이용하는 단어 임베딩 방법론 ‘글로브(GloVe)’ 등이 있다”고 설명했다.

임베딩 외에도 인덱싱 역시 벡터 DB에 데이터를 저장하는 중요한 과정이다. 인덱싱이란 벡터 DB 내에 저장된 벡터 데이터를 빠르게 검색하기 위해 데이터의 위치를 기록하는 기술이다. 쉽게 말해 사전처럼 구성한다는 의미다. 가령 사전에서 ‘호랑이’라는 정보를 찾기 위해 ‘ㅎ’ 범주로, 다음은 ‘ㅗ’ 부분으로, 이후 ‘ㄹ’ 순서로 단어를 찾아 나간다. 이와 비슷한 방식으로 무수히 쌓인 벡터 데이터 중 찾고자 하는 데이터를 잘 정리해 놓은 사전을 보고 쉽게 원하는 데이터를 찾고 읽어올 수 있도록 한다는 얘기다.

네이버클라우드 허창현 클라우드 솔루션 아키텍트는 “인덱싱은 RDB에서도 쓰인다. 데이터를 효율적으로 구성하는 하나의 프로세스이며, 대규모 데이터셋에서 시간이 많이 소요되는 쿼리를 빠르게 실행해 검색을 유용하게 만드는 역할을 한다. 데이터의 크기나 컴퓨팅 자원에 따라 인덱스를 선택하는 기준은 달라질 수 있다”고 설명했다.

현재 널리 쓰이는 인덱싱 알고리즘은 비-트리(B-Tree), 알-트리(R-Tree), LSH, KD-트리(Tree), ANN 알고리즘 등이다.

비-트리 알고리즘은 가장 널리 사용되는 인덱싱 알고리즘중 하나로, 데이터를 계층적으로 저장하고 검색한다. 데이터의 삽입, 삭제, 검색이 빠르다. 알-트리 알고리즘은 B-트리를 개선한 알고리즘으로, 공간을 효율적으로 사용하고 검색 속도를 높일 수 있다. 다차원 데이터를 인덱싱하는 데 적합하다. K-D 트리 알고리즘은 R-트리를 2차원 공간에 맞게 변형한 알고리즘으로, 2차원 데이터를 인덱싱하는 데 적합하다. 공간을 효율적으로 사용하고 검색 속도를 높일 수 있다.

인덱싱에 널리 이용되는 기법도 존재한다. 대표적으로 ‘플랫 인덱스(Flat Index)’, ‘IVF 인덱스(IVF Index)’, ‘HNSW 인덱스’ 등이 있다. 플랫 인덱스은 벡터를 그대로 저장하는 기법으로 구현은 쉽지만, 속도가 느리다. 높은 정확도가 필요하고 속도를 고려하지 않아도 되는 상황에서는 플랫 인덱스 기법이 적합하다. 주로 상대적으로 작은 데이터셋에서 사용된다.

IVF 인덱스 기법은 클러스터링을 이용해 벡터 데이터를 작은 클러스터로 분할하고, 각 클러스터의 대표 벡터를 이용해 인덱스를 구성하는 방식이다. 플랫 방식보다 많은 데이터가 저장된 벡터 DB에서 쿼리 성능을 높일 수 있는 인덱스다.

HNSW는 가장 널리 이용되는 기법으로 플랫 인덱스와 IVF 인덱스 기법에 비해 빠르고 효율적이다. 그러나 많은 메모리가 필요해 리소스를 유연하게 조절해야 한다.

통상적으로 저장 공간이 제한적이라면 플랫 인덱스나 IVF 인덱스를, 검색 속도가 중요한 경우에는 HNSW 인덱스를 사용하는 것이 좋다.

엔코아 김범 사업부문장은 “인덱싱 알고리즘과 인덱싱 기법은 서로 다른 개념이다. 인덱싱 알고리즘은 데이터를 인덱싱하기 위한 절차나 방법을 의미한다. 데이터를 저장하고 검색하는 데 필요한 알고리즘으로, 데이터의 특성과 요구사항에 따라 다양한 알고리즘이 사용된다. 인덱싱 기법은 인덱싱 알고리즘을 구현하기 위한 기술이나 방법을 의미한다. 인덱싱 알고리즘을 효율적으로 구현하기 위해 사용되는 기술로 데이터의 저장 방식, 검색 방식, 데이터의 압축 방식 등을 포함한다. 인덱싱 알고리즘은 인덱싱 기법을 이용해 구현되고, 인덱싱 기법은 인덱싱 알고리즘의 성능을 개선하는 데 중요한 역할을 한다”며 알고리즘과 기법을 구분했다.

[인터뷰] “벡터 DB와 지식그래프 역량 결합해 AI 기업으로 거듭난다”

Q. 지식그래프와 벡터 DB를 함께 사용한다는 것은 어떠한 의미인가.
A. 환각을 최소화할 수 있는 RAG라는 기술을 구현할 수 있다는 의미다. 먼저 RAG는 LLM과 별도의 저장소를 연결하는 기술이다. 이를 통해 답변의 정확도를 높일 수 있다. 하지만 RAG는 저장소와 연결하는 기술이기에 별도의 저장소가 필요하다. 이때 주로 쓰이는 저장소가 벡터 DB다. 지식그래프, 그래프 DB의 경우도 마찬가지다. 특정 노드와의 상관관계가 명확하게 제시되는 구조를 갖고 있는 지식그래프를 벡터 DB, LLM 등과 RAG로 연결할 경우 환각 가능성을 낮출 수 있다.

가령 교통사고가 발생해 ‘상대방의 과실이 80%일 경우 내 보험료는 얼마나 오르는지’를 질문한다면, 벡터 DB나 LLM만 이용하면 ‘상대방 과실에 따라 보험료는 몇 %가 상승한다’라는 답을 한다. 하지만 지식그래프를 벡터 DB, LLM과 RAG로 연동해 이용할 경우 ‘상대방 과실이 80%이니 보험료는 정확히 A원 오른다’와 같이 명확한 답변을 할 수 있다는 것이다. 또 이러한 답변의 근거도 함께 확인할 수 있다.

Q. 본격적인 벡터 DB 및 지식그래프 비즈니스는 언제부터인가.
A. 엔코아는 그간 데이터 전문기업으로 데이터 특화 비즈니스를 영위해왔다. 데이터를 관리하고 활용하기 위한 기반 컨설팅 서비스부터 솔루션까지 다양하게 제공해왔다. 엔코아는 단순 데이터 전문기업이 아닌 AI 전문기업으로 거듭나고자 한다. 이를 위해 벡터 DB와 지식그래프, LLM에 대한 역량 확보는 필수적이라고 판단하고 있다. 실제로 컨설팅 조직을 솔루션 중심 R&D 조직으로 전환하고 있다. 기존 인력의 교육과 외부 영입을 적극적으로 추진 중이다.

올해부터 엔코아는 벡터 DB와 지식그래프 기반 사업을 구체화할 것이다. 고객들이 벡터 DB와 지식그래프를 도입하는 과정에서 데이터와 관련된 여러 복잡한 작업을 수행해야 하는데 이를 자동화할 수 있는 솔루션도 준비하고 있다. 하반기에 출시할 것이다. 현재 몇몇 고객사와 자체 시스템을 벡터 DB 및 지식그래프를 기반으로 구성하기 위한 논의를 진행 중이다.

Q. 벡터 DB와 지식그래프가 LLM 기반 생성형 AI에 어떤 가치를 줄 수 있다고 보는가.
A. 비즈니스 혁신의 명확한 근거를 제시할 수 있을 것으로 본다. 생성형 AI가 가져올 혁신은 부정확한 것들이 많았다. 하지만 벡터 DB와 지식그래프라는 보조장치, RAG라는 기술을 LLM 기반 생성형 AI에 적용하기 시작한다면 근거가 부족한 혁신이 아닌 확실한 혁신의 기회를 줄 수 있을 것으로 본다. 다만 준비 역시 철저해야 할 것이다. 중요한 데이터와 중요하지 않은 데이터를 잘 구분해 임베딩·저장하는 것, 벡터 DB를 꾸준히 유지하고 데이터를 최신화하는 것 등에도 많은 노력을 기울여야 할 것이다.

벡터DB 기능 지원하는 ‘오픈소스 및 상용 DB’

LLM 기반 생성형 AI의 쓰임새가 다양해지고, 이용하는 기업 및 조직이 늘어날수록 벡터 DB에 대한 인기가 높아가고 있다. 현재 벡터 DB를 이용하는 대다수 고객은 벡터 전용 DB를 이용하거나 상용 RDB 및 NoSQL DB 제품 내 플러그인 형태로 벡터 검색을 제공하는 기능을 활용하곤 한다.

대표적인 벡터 전용 DB 제품은 밀버스(Milvus), 큐드란트(Qdrant), 파인콘(Pinecone), 크로마(Chroma) 등을 들 수 있다. 이 중 파인콘을 제외하고 모두 오픈소스 제품이다. 포스트그레SQL(PostgreSQL), 오픈서치(OpenSearch), 엘라스틱서치(Elasticsearch), 싱글스토어(SingleStore) 등의 솔루션도 벡터 검색 기능을 지원하고 있다.

최근 많은 인기를 끌고 있는 오픈소스 RDB인 포스트그레SQL는 ‘PG벡터(PGVector)’라는 익스텐션(Extention)을 통해 벡터 DB 기능을 지원하고 있다. 이에 대해 EDB 측 관계자는 “PG벡터는 포스트그레SQL에서 벡터 데이터를 효과적으로 다룰 수 있도록 지원하는 확장 기능이다. 포스트그레SQL DB 내에서 벡터 연산과 유사성 검색을 가능하게 만들어 다차원의 벡터 데이터를 저장하고 검색하는 데 사용할 수 있다. PG벡터는 다양한 데이터 유형의 벡터를 지원하며, 벡터 데이터에 대한 쿼리 및 인덱싱 기능도 제공한다. 특히 유사성 검색과 최근접 이웃 검색과 같은 벡터 데이터의 특수한 요구에 적합한 유클리드 거리 및 코사인 거리와 같은 함수 및 연산자도 지원한다”고 설명했다.

RDB 절대강자인 오라클 역시 벡터 DB 기능을 지원한다. 오라클은 곧 출시될 ‘오라클 데이터베이스 23c’에 벡터 형태의 데이터를 저장할 수 있는 기능을 탑재할 예정이다. 이에 대해 오라클 장성우 전무는 “오라클 DB를 이용하는 수많은 고객이 벡터 형태의 데이터를 쉽게 저장하고 읽어올 수 있도록 오라클 23c에서 이를 지원하고자 한다. 기존 오라클 19c를 많이 이용하는데 DB 라이선스 하나를 23c로 변경하고 벡터 DB 전용으로 구축한다면 별도로 벡터 DB를 구축하는 것보다 저렴하게 이용할 수 있다”고 첨언했다.

국내 대표 클라우드 서비스 제공사(CSP)인 네이버클라우드 역시 포스트그레SQL과 오픈서치를 기반으로 완전 관리형 벡터 DB 서비스를 제공하고 있다. 벡터 검색을 위해 인덱싱과 검색 알고리즘 등을 제공하며, 자동 페일오버와 멀티존 기능을 통해 이러한 기능들을 안정적으로 운영할 수 있도록 한다. 대표적으로 완전 관리형 벡터 검색 시스템 ‘클라우드 DB 포 포스트그레SQL(Cloud DB for PostgreSQL)’, ‘서치 엔진 서비스(Search Engine Service)’ 등 서비스로 벡터 DB를 이용할 수 있다.

NoSQL 대표 오픈소스 제품인 몽고DB 역시 벡터 기능을 지원한다. 몽고DB는 자사의 개발자 데이터 플랫폼인 ‘아틀라스(Atlas)’의 구성 요소인 ‘몽고DB 아틀라스 벡터 서치(MongoDB Atlas Vector Search)’를 통해 벡터 DB 기능을 제공한다.

몽고DB 측은 “자사의 아틀라스 벡터 서치는 벡터 검색 작업에서 단일 통합 API를 제공해 쿼리를 간소화하고 개발 시간을 단축할 수 있다. 벡터 데이터 저장만 지원하는 타사와 달리 아틀라스 벡터 서치는 조직의 모든 데이터를 저장 및 처리할 수 있어 세계적으로 분산된 운영 DB와 통합된다. 이를 통해 고성능의 확장 가능한 벡터 DB로서의 역할이 가능하다”고 말했다. 또한 “아틀라스 벡터 서치를 통해 익숙한 단일 통합 플랫폼에서 개발자 간의 마찰을 최소화하며 시맨틱 검색, 이미지 비교, 고도로 개인화된 추천 등 AI 기반 기능을 신속하게 구축, 배포 및 확장할 수 있다. 벡터 데이터, 분석 집계, 텍스트 기반 검색, 지리공간 데이터, 시계열 데이터에 대한 광범위한 쿼리를 쉽게 결합해 검색 증강 생성(RAG)을 강화하고, 엔드 유저 요청에 대한 응답을 한층 세밀하게 조정할 수 있다”고 설명했다.

한편, 대부분 업계 관계자들은 기업 및 조직에서 벡터 DB를 구축할 때 별도의 벡터 DB를 구축하거나 타 종류 DB에서 제공하는 벡터 DB 기능을 이용할 것을 권고한다. 단순히 벡터 DB를 테스트하기 위한 용도로 오픈소스 벡터 DB를 잠시 이용하는 것은 괜찮지만, 비즈니스에 활용하는 단계에서 오픈소스 벡터 DB를 구성하게 되면 직접 관리 및 운영해야 하는 부담이 높아 상용 벡터 DB 및 기능으로 제공되는 벡터 DB를 고려하는 것이 좋다는 설명이다.

[인터뷰] “완전 관리형 벡터 DB로 운영·관리 효율성 향상”

Q. 향후 클라우드 기반 벡터 DB 시장을 전망한다면.
A. 향후 벡터 DB 시장은 생성형 AI의 확산, 검색 및 유사성 분석의 요구 확대, 비즈니스 인텔리전스 통합, 보안 및 규정 준수에 대한 강화 등의 요인들로 성장이 확실시된다. 특히 이미 많은 종류의 DB가 클라우드에서 구성·운영되고 있다. 계속해서 클라우드를 통해 다양한 DM 및 검색 시스템이 제공될 것이다. 벡터 DB 역시 많은 오픈소스와 상용 솔루션들이 존재하는 가운데, 이러한 솔루션들이 클라우드를 통해 제공되면서 보다 탄력적이고 효율적으로 사용할 수 있는 환경이 마련될 것이다.

아울러 벡터 DB는 LLM과 함께 상호보완 관계 속에서 지속적으로 성장할 것으로 보이며, 클라우드를 기반으로 LLM과 DB를 구성하려는 요구사항도 계속해서 늘어날 것으로 전망된다.

Q. 네이버클라우드에서 제공하는 벡터 DB 서비스는 무엇이 있는가.
A. 네이버클라우드는 완전 관리형 데이터베이스를 제공하고 있다. 이러한 DB 시스템에서 벡터 검색을 쉽게 사용할 수 있도록 다양한 기능을 지원하고 있다. 벡터 검색을 위해 인덱싱과 검색 알고리즘 등을 제공하며, 이러한 기능들이 안정적으로 동작할 수 있도록 자동 페일오버와 멀티존 기능이 제공된다. 대표적으로 포스트그레SQL과 오픈서치를 완전 관리형 벡터 검색 시스템으로 이용하도록 서비스하고 있다. 포스트그레SQL의 경우 ‘클라우드 DB 포 포스트그레SQL(Cloud DB for PostgreSQL)’을, 오픈서치의 경우 2.7 버전을 추가해 데이터를 검색, 분석, 시각화할 수 있는 완전 관리형 ‘서치 엔진 서비스(Search Engine Service)’를 제공 중이다. 벡터 DB를 완전 관리형으로 사용하면 데이터의 자동 백업·보관이 가능하다. 시점 복원이나 모니터링, 알람 기능을 함께 이용할 경우 효율성이 높다는 장점이 있다.

Q. 향후 완전 관리형 벡터 DB 서비스 고도화 계획은.
A. 네이버클라우드는 AI 라인업을 구축하는 동시에 생성형 AI 활용에 대한 기업들의 고민을 해결하기 위해 벡터 데이터 저장 및 활용에 대한 최신 기술을 반영한 다양한 기능을 지속적으로 추가할 예정이다. 물론 기존에 제공하던 완전 관리형 서비스의 기능 및 성능, 안정성은 더욱 개선될 것이며, 여러 종류의 DB에서 다양한 형태의 데이터를 관리할 수 있는 기능도 추가할 것이다.