기존의 게시판 검색이나 이커머스 상품 검색에 익숙한 개발자는 반사적으로 관계형 데이터베이스(RDB)의 LIKE '%keyword%' 쿼리나, 인덱스를 활용한 조회를 떠올릴 것입니다. 조금 더 고도화된 시스템을 다루어보았다면 역인덱스(Inverted Index) 기반의 풀텍스트 검색(Full-text Search) 엔진을 고려할 수도 있습니다. 하지만 단어의 철자가 전혀 다르더라도 '문맥적 의미'가 같은 데이터를 찾아야 하는 상황에서, 전통적인 RDB와 텍스트 검색 엔진은 치명적인 한계를 드러냅니다.

이러한 문제를 해결하기 위해 등장한 개념이 바로 벡터 데이터베이스(Vector Database)입니다. 처음 이 용어를 접한 백엔드 개발자라면 기존 데이터베이스와 무엇이 다르고, 언제 이 기술을 도입해야 하는지 막막할 수 있습니다. 이 블로그 포스트에서는 컴퓨터 과학의 자료구조와 디스크 I/O 관점에서 기존 RDB의 한계를 수학적으로 분석하고, Vector DB가 어떻게 유사도 검색(Similarity Search)을 구현하는지 깊이 있게 파헤쳐 보겠습니다.

(안내: 본 포스트의 후반부에 설명되는 최신 고차원 벡터 임베딩 및 ANN 인덱싱 구현체 등은 제공된 전통적 데이터베이스 문헌 외의 최신 컴퓨터 과학 지식을 바탕으로 보완되었습니다. 도입 시 개별 시스템의 공식 문서를 추가로 교차 검증하시기 바랍니다.)

2. 기존 RDB 및 풀텍스트 검색의 아키텍처적 한계

Vector DB의 필요성을 이해하려면, 먼저 우리가 친숙하게 사용하는 기존 시스템들이 데이터를 어떻게 탐색하는지 원리를 되짚어보아야 합니다.

B-Tree 인덱스의 수학적 맹점

MySQL, PostgreSQL 등 대부분의 RDBMS는 데이터 검색 속도를 높이기 위해 B+-Tree(Balanced Tree) 자료구조를 사용합니다 [1, 2]. B-Tree는 루트 노드에서 리프 노드까지 모든 경로의 길이가 같은 균형 트리로, 데이터가 특정 기준(예: 숫자 크기, 알파벳 순서)에 따라 엄격하게 정렬되어 저장됩니다 [2].

데이터가 1차원적으로 정렬되어 있기 때문에 동등 비교(=)나 범위 검색(<, >, BETWEEN)에서는 압도적인 성능을 자랑합니다. 하지만 사용자가 입력한 자연어 문장과 '의미가 비슷한' 데이터를 찾는 작업에는 B-Tree를 사용할 수 없습니다. 의미적 유사성이라는 개념은 다차원적인 특성을 가지므로, 단일 컬럼을 기준으로 크기를 비교하고 정렬하는 B-Tree의 분기(Branching) 메커니즘을 적용할 수 없기 때문입니다 [2]. 결국 RDB로 유사도를 구하려면 전체 테이블 스캔(Full Table Scan)을 통해 모든 레코드와 연산을 수행해야 하며, 이는 디스크 헤드를 무작위로 움직이는 치명적인 랜덤 I/O 비용을 발생시킵니다.

역인덱스와 TF-IDF의 의미론적 한계

그렇다면 텍스트 검색을 위해 설계된 Lucene, Sphinx 기반의 검색 엔진은 어떨까요? 이들은 주어진 키워드를 문서의 식별자 리스트에 매핑하는 역인덱스(Inverted Index) 구조를 사용합니다 [3, 4]. 특정 단어가 포함된 문서를 빠르게 찾기 위해, 단어의 출현 빈도(Term Frequency)와 역문서 빈도(Inverse Document Frequency)를 곱하는 TF-IDF나 BM25 같은 알고리즘을 통해 검색어와 문서 간의 관련성(Relevance)을 평가합니다 [5, 6].

이 방식은 문서 내에 검색어와 '정확히 일치하는 철자'가 존재해야만 작동합니다. 즉, 사용자가 "사과"라고 검색했을 때 문서에 "애플"이라는 단어만 존재한다면, 두 단어의 문맥적 의미가 같더라도 시스템은 관련성을 0으로 계산합니다 [3, 5]. 이는 키워드 매칭 방식의 근본적인 한계입니다.

3. Vector DB란 무엇인가? 다차원 공간과 임베딩의 이해

벡터 데이터베이스는 텍스트, 이미지, 오디오 등의 비정형 데이터를 인공지능 모델(Neural Network 등)을 통해 고차원의 실수 배열로 변환한 값, 즉 '임베딩(Embedding) 벡터'를 저장하고 검색하는 데 특화된 시스템입니다.

고차원 공간으로의 매핑

임베딩 모델은 "사과"와 "애플"이 문맥상 비슷한 환경에서 자주 쓰인다는 것을 학습하고, 이 두 단어를 수백~수천 차원의 수학적 공간에서 매우 가까운 좌표에 위치하도록 변환합니다. 공간 데이터베이스나 지리정보시스템(GIS)에서 두 좌표 간의 거리를 계산하여 특정 위치와 가장 가까운 지점을 찾는 최근접 이웃 쿼리(Nearest-Neighbor Query)의 개념이 수천 차원의 공간으로 확장된 형태라고 이해하면 쉽습니다 [7].

유사도 검색 (Similarity Search)

Vector DB의 핵심 기능은 B-Tree처럼 값을 크기순으로 찾아가는 것이 아니라, 벡터 간의 수학적 거리를 계산하여 가장 가까운 이웃을 찾는 것입니다. 이를 위해 주로 코사인 유사도(Cosine Similarity)나 유클리디안 거리(Euclidean Distance) 같은 수학적 공식을 사용하여 벡터 좌표 간의 거리를 측정합니다. 사용자가 질문을 입력하면, 시스템은 그 질문을 즉시 벡터로 변환한 뒤 데이터베이스 내의 수많은 벡터 중 거리가 가장 짧은(가장 의미가 유사한) 데이터를 반환합니다.

4. 백엔드 관점: RDB와 Vector DB의 차이점 및 트레이드오프

백엔드 개발자가 아키텍처를 설계할 때, 이 두 데이터베이스는 설계 철학과 트레이드오프(Trade-off)에서 극명한 차이를 보입니다.

4.1. 데이터 모델과 스키마 (Data Model)

•

RDB: 정규화(Normalization)를 통해 데이터의 중복을 제거하고 제1정규형(1NF)부터 BCNF 등 엄격한 스키마 구조를 따릅니다 [8]. 모든 속성은 사전 정의된 타입(INT, VARCHAR 등)을 가져야 하며, 외래 키(Foreign Key)를 통해 테이블 간의 무결성을 강제합니다.

•

Vector DB: 본질적으로 스키마리스(Schemaless)이거나 매우 유연한 구조를 가집니다. 핵심 데이터는 [0.14, -0.05, 0.88, ...]과 같은 고차원 실수 배열이며, 이를 필터링하기 위한 메타데이터(예: 작성자, 날짜 등)를 JSON 형태로 함께 저장하는 방식(Document store와 유사)을 취합니다.

4.2. 인덱싱 구조 (Indexing Structure)

•

RDB: 디스크 I/O를 최소화하기 위해 B-Tree 계열이나 쓰기에 최적화된 LSM-Tree(Log-Structured Merge Tree), SSTable 등을 사용합니다 [1]. 기존 DB에서도 다차원 데이터를 다루기 위해 k-d-B Tree와 같은 구조가 제안되었으나 [9], 차원이 커질수록 성능이 급락하는 '차원의 저주'를 극복하지 못합니다.

•

Vector DB: 벡터 공간에서 완벽하게 정확한 최근접 이웃(Exact NN)을 찾는 것은 데이터가 많아질수록 연산 비용이 폭증합니다. 따라서 최신 Vector DB들은 허용 가능한 오차(Allowable errors) 내에서 공간/시간 효율을 극대화하는 ANN(Approximate Nearest Neighbor) 알고리즘을 인덱싱에 사용합니다 [10]. HNSW(Hierarchical Navigable Small World)나 IVF-PQ 같은 해싱/그래프 기반 알고리즘을 통해 탐색 공간을 비약적으로 줄입니다.

4.3. 트랜잭션과 일관성 (Consistency)

•

RDB: 금융 데이터나 재고 관리처럼 1원의 오차도 허용되지 않는 시스템을 위해 원자성, 일관성, 격리성, 지속성을 보장하는 ACID 트랜잭션 모델을 철저히 준수합니다 [11].

•

Vector DB: AI 기반의 의미 검색은 본질적으로 확률적인 작업입니다. 따라서 금융권 수준의 엄격한 동시성 제어(Concurrency Control)나 직렬화(Serializability)보다는, 분산 환경에서의 높은 가용성(Availability)과 궁극적 일관성(Eventual Consistency)을 확보하는 데 더 무게를 둡니다.

5. 요약: 언제 무엇을 선택해야 할까?

결론적으로 Vector DB는 기존 RDB를 대체하는 기술이 아니라, 서로의 약점을 보완하는 상호 보완적인 인프라입니다.

사용자의 결제 정보, 회원 가입 데이터, 상태 값 변화 등 정확한 상태 전이와 무결성이 중요한 시스템의 마스터 데이터는 무조건 RDB에 저장해야 합니다. 반면, 챗봇이 사내 문서를 기반으로 답변을 생성하는 RAG(Retrieval-Augmented Generation) 시스템을 구축하거나, 이미지/오디오 기반의 시맨틱 추천 엔진을 만들어야 한다면 Vector DB를 도입하는 것이 필수적입니다.

일반적인 현대 백엔드 아키텍처에서는 RDB에 원본 데이터를 저장하고, 비동기 파이프라인(Message Queue 등)을 통해 해당 데이터를 임베딩 모델로 전달하여 생성된 고차원 벡터만을 Vector DB에 색인(Index)하는 하이브리드 방식을 주로 채택합니다.

이러한 두 시스템의 수학적 원리와 디스크 접근 한계를 명확히 이해한다면, 무작정 최신 기술을 도입하는 것을 넘어 비즈니스 요구사항에 딱 맞는 견고한 데이터 레이어 아키텍처를 설계할 수 있을 것입니다.

참고문헌

[1] designing-data-intensive-applications — Summary 63 3. Storage and Retrieval. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 Data Structures That Power Your D…

[2] designing-data-intensive-applications — 80 | Chapter 3: Storage and Retrieval ii. Inserting a new key into a B-tree is reasonably intuitive, but deleting one (while keeping the tree balanced) is somewhat more involved [2]. Eventually we get down to a page containing individual keys (a leaf page), which either contains the value for each k…

[3] Database-System-Concepts-7th-Edition — Note 15.1 Answering Keyword Queries Keyword search on documents is widely used in the context of web search. In its simplest form, a keyword query provides a set of words K1, K2,… , Kn, and the goal is to find documents di from a collection of documents D such that di con-tains all the keywords in t…

[4] designing-data-intensive-applications — 78 | Chapter 3: Storage and Retrieval log-structured filesystems [11]. Storage engines that are based on this principle of merging and compacting sorted files are often called LSM storage engines. Lucene, an indexing engine for full-text search used by Elasticsearch and Solr, uses a similar method f…

[5] Database-System-Concepts-7th-Edition — 384 Chapter 8 Complex Data Types 8.3.2.1 Ranking Using TF-IDF The word term refers to a keyword occurring in a document, or given as part of a query. The first question to address is, given a particular term t, how relevant is a particular document d to the term. One approach is to use the number of…

[6] O'Reilly.High.Performance.MySQL.3rd.Edition.Mar.2012 (1) — We covered some of these features earlier. This section covers a few of the remaining features. Phrase Proximity Ranking Sphinx remembers word positions within each document, as do other open source full-text search systems. But unlike most other ones, it uses the positions to rank matches and retur…

[7] Database-System-Concepts-7th-Edition — Geometric data Geographic information system Computer-aided-design (CAD) Polyline Linestring Practice Exercises 397 Triangulation Spatial network Spatial graph Raster data Tiles Vector data Topographical information Triangulated irregular network (TIN) Overlays Nearness queries Nearest-neighbor quer…

[8] Database-System-Concepts-7th-Edition — Dependency-preserving decomposi-tion Boyce–Codd normal form (BCNF) BCNF decomposition algorithm Practice Exercises 353 Third normal form (3NF) 3NF decomposition algorithm 3NF synthesis algorithm Multivalued dependency ° Equality-generating dependencies ° Tuple-generating dependencies ° Embedded mult…

[9] Database-System-Concepts-7th-Edition — [Knuth (1973)] D. E. Knuth, The Art of Computer Programming, Volume 3, Addison Wesley, Sorting and Searching (1973). [O’Neil and Quass (1997)] P. O’Neil and D. Quass, “Improved Query Performance with Variant Indexes”, In Proc. of the ACM SIGMOD Conf. on Management of Data (1997), pages 38–49. [O’Nei…

[10] designing-data-intensive-applications — [13] Deepak Kandepet: “Hacking Lucene—The Index Format,” hackerlabs.org, Octo‐ ber 1, 2011. [14] Michael McCandless: “Visualizing Lucene’s Segment Merges,” blog.mikemccand‐ less.com, February 11, 2011. [15] Burton H. Bloom: “Space/Time Trade-offs in Hash Coding with Allowable Errors,” Communications…

[11] designing-data-intensive-applications — [53] Kyle Kingsbury: Jepsen blog post series, aphyr.com, 2013–2016. [54] Michael Jouravlev: “Redirect After Post,” theserverside.com, August 1, 2004. [55] Jerome H. Saltzer, David P. Reed, and David D. Clark: “End-to-End Arguments in System Design,” ACM Transactions on Computer Systems, volume 2, nu…