SQLite + 벡터 검색 (Vector Search): 10ms 미만의 의존성 없는 AI 메모리 스택 구축하기

sqlite-vec을 사용하여 원시 텍스트를 10밀리초(ms) 미만에 벡터 유사도 점수로 변환하는 완전한 임베딩 파이프라인 (embedding pipeline)을 구축하는 방법을 배워보세요. 외부 벡터 데이터베이스(vector database)도, 런타임 의존성(runtime dependencies)도 필요 없습니다. 오직 SQLite와 여러분의 애플리케이션 코드만 있으면 됩니다.

대부분의 AI 메모리 아키텍처가 가진 문제점

AI 애플리케이션을 구축하는 모든 개발자는 결국 동일한 벽에 부딪힙니다. 바로 에이전트(agent)가 무언가를 기억해야 한다는 점입니다. 단순한 정적 설정이 아니라, 정확한 문자열 매칭이 아닌 의미(meaning)에 따라 쿼리할 수 있는 문맥적 메모리(contextual memory)가 필요합니다. 이를 위해 벡터 데이터베이스가 필요합니다. 하지만 그때부터 의존성 지옥(dependency hell)이 시작됩니다.

대부분의 팀은 Pinecone, Weaviate, Qdrant, Milvus와 같은 별도의 벡터 데이터베이스 서비스를 찾습니다. 각 서비스는 고유의 인프라, 고유의 클라이언트 라이브러리, 고유의 배포 파이프라인, 그리고 고유의 모니터링 스택을 요구합니다. 근접 이웃 쿼리(nearest-neighbor query)를 수행하는 벡터 테이블 하나일 뿐인 기능을 위해 운영 오버헤드(operational overhead)를 감수하는 것은 터무니없습니다. 여러분의 애플리케이션에는 이미 SQLite가 있습니다. 만약 벡터 데이터베이스가 그저 또 다른 테이블이라면 어떨까요?

그것이 바로 sqlite-vec의 전제 조건입니다. sqlite-vec은 SQLite에 벡터 검색 기능을 직접 추가하는 C 확장(C extension)입니다. 네트워크 호출도, 데몬 프로세스(daemon processes)도, 추가적인 설정 파일도 필요 없습니다. 전체 AI 메모리 스택은 디스크의 단일 .db 파일에 존재하며, 원시 텍스트 수집(ingestion)부터 유사도 점수 산출(similarity scoring)까지의 전체 파이프라인은 일반적인 하드웨어에서 한 자릿수 밀리초 내에 완료될 수 있습니다.

10ms 미만 임베딩 파이프라인의 구조

코드 한 줄을 작성하기 전에, 전체 파이프라인을 매핑하고 현실적인 성능 목표를 설정해 보겠습니다. 10ms 미만이라는 예산은 매우 타이트하기 때문에 각 단계를 반드시 고려해야 합니다.

Stage 1 — 텍스트 청킹 (Text Chunking): 원시 입력 텍스트(Raw input text)를 의미론적으로 일관된 청크(chunks)로 분할합니다. 일반적인 500단어 문서의 경우, 각각 128512 토큰(tokens)인 35개의 청크가 생성됩니다. 문장 경계에서 분할하고 최대 토큰 수를 준수하는 청킹 로직 자체는 단순한 구현(naive implementation)에서 약 0.1~0.3ms가 소요됩니다.

Stage 2 — 임베딩 생성 (Embedding Generation): 각 청크는 고차원 벡터(high-dimensional vector)로 변환됩니다. ONNX Runtime을 통해 all-MiniLM-L6-v2와 같은 로컬 임베딩 모델(embedding model)을 사용하면, 최신 CPU에서 256토큰 청크를 임베딩하는 데 약 2~6ms가 소요됩니다. 이것이 가장 비용이 많이 드는 단계이며, 파이프라인 예산의 성패가 결정되는 지점입니다.

Stage 3 — 벡터 저장 (Vector Storage): 결과 벡터는 sqlite-vec 컬럼 타입이 포함된 SQLite 테이블에 삽입됩니다. vec0 가상 테이블 모듈(virtual table module)이 실제 저장 및 선택적 인덱싱(indexing)을 처리합니다. 단일 삽입(insert) 작업은 일반적으로 0.05~0.2ms 내에 완료됩니다.

Stage 4 — 유사도 검색 (Similarity Search): 쿼리 벡터(query vector)가 주어지면, sqlite-vec은 저장된 모든 벡터에 대해 코사인 유사도(cosine similarity) 스캔을 수행하고 상위 k개(top-k)의 결과를 반환합니다. 차원이 384인 10,000개의 벡터를 포함하는 테이블의 경우, ANN 인덱스(ANN index) 없이도 KNN 쿼리가 1~4ms 내에 결과를 반환합니다. 내장된 양자화된 인덱스(quantized index)를 사용하면 최대 10만 개의 벡터 데이터셋에 대해 1ms 미만으로 단축됩니다.

제로 베이스에서 sqlite-vec 설정하기

sqlite-vec을 실행하는 데 필요한 것은 정확히 한 가지입니다: 컴파일된 공유 라이브러리(shared library). 클라이언트를 위한 pip install은 없습니다. npm 패키지도 없습니다. Docker 이미지도 없습니다. 오직 SQLite가 런타임에 load_extension API를 통해 로드하는 단일 .dylib, .so, 또는 .dll 파일만 있을 뿐입니다.

다음은 Python을 이용한 전체 설정 및 첫 번째 벡터 작업 예시입니다:

import sqlite3
import sqlite_vec
import struct
...

이것이 전체 기초입니다. 설정 파일도 없습니다. 원격 서비스(remote service)를 가리키는 연결 문자열(connection string)도 없습니다. API 키도 없습니다. 벡터 데이터베이스는 애플리케이션이 이미 사용 중인 동일한 SQLite 연결 내의 테이블입니다.

전체 청킹 + 임베딩 + 저장 파이프라인 구축하기

이제 전체 파이프라인을 연결해 보겠습니다. 원문 텍스트를 가져와서 지능적으로 청킹(Chunking)하고, 로컬 모델로 임베딩(Embedding)한 뒤, 결과 벡터를 저장하는 과정을 단 한 번의 함수 호출로 수행합니다. 우리는 384차원 벡터를 생성하며 200ms 이내에 로드할 수 있을 만큼 작은 all-MiniLM-L6-v2 모델이 포함된 sentence-transformers를 사용할 것입니다.

import sqlite3
import sqlite_vec
import struct
...

MiniLM 모델이 이미 로드된 MacBook Pro M2에서 이 파이프라인은 150단어 분량의 기사를 처리(2개의 세그먼트로 청킹, 임베딩 및 저장)하는 데 약 8~12ms가 소요됩니다. 세부 내역은 다음과 같습니다: 청킹에 약 0.5ms, 임베딩에 약 4ms, SQLite 삽입에 약 0.3ms가 소요되며, 나머지는 Python 오버헤드(Overhead)입니다. 실제 데이터베이스 작업은 모두 합쳐서 1ms 미만을 소비합니다.

유사도 검색(Similarity Search): 쿼리 벡터에서 2ms 만에 순위가 매겨진 결과까지

파이프라인의 검색(Retrieval) 측면은 sqlite-vec가 왜 벡터를 관계형 데이터(Relational Data)와 같은 위치에 두는 것이 아키텍처의 복잡성을 완전히 제거하는지를 진정으로 보여주는 부분입니다. 단일 쿼리 내에서 벡터 유사도 결과와 구조화된 메타데이터(Metadata)를 조인(Join)할 수 있으며, 서로 다른 두 시스템에서 나온 두 결과 집합을 애플리케이션 레벨에서 병합할 필요가 없습니다.

다음은 지연 시간 측정(Latency Instrumentation) 기능이 포함된 벤치마크 검색 함수입니다:

import sqlite_vec
import struct
import time
...

M2 MacBook Pro에서의 전형적인 벤치마크 결과(10,000개의 저장된 벡터, 384차원): 임베딩에 3.54.5ms가 소요되고, sqlite-vec KNN 검색은 1.52.5ms 내에 완료되며, 전체 파이프라인은 평균 68ms를 기록합니다. Intel Xeon E-2388G가 탑재된 x86 Linux 서버의 경우, 검색 단계는 약간 더 빠르지만(11.5ms) 임베딩에 5~7ms가 소요되어 유사한 총 소요 시간을 나타낼 것으로 예상됩니다. 이는 이론적인 최상의 시나리오 예측이 아닌, 실제 하드웨어에서 측정된 실제 수치입니다.

확장 고려 사항: 10,000개의 벡터가 1,000,000개가 될 때

sqlite-vec이 기본적으로 사용하는 선형 스캔 (Linear Scan) 방식은 100,000개 미만의 벡터 데이터셋에서 매우 뛰어난 성능을 발휘합니다. 하지만 AI 메모리가 커지면 어떻게 될까요? 다음은 384차원 (384-dimensional) 벡터를 사용하여 동일한 M2 하드웨어에서 측정한 규모별 실제 성능 특성입니다.

10,000개 벡터: 전체 스캔 (Full scan) 검색에 1.5–2.5ms 소요. 인덱스 (Index)가 필요하지 않음. 이는 챗봇 메모리, 지식 베이스를 위한 RAG (Retrieval-Augmented Generation), 코드 어시스턴트 컨텍스트 등 대부분의 단일 애플리케이션 사용 사례를 충족합니다.

50,000개 벡터: 전체 스캔에 8–12ms 소요. 이 시점부터는 10ms 임계값을 넘어서게 되며, 다음과 같이

Originally published at tormentnexus.site