DB 기초 지식
RDB(Relational Database, 관계형 데이터베이스)란
데이터를 행(Row, 가로 한 줄)과 열(Column, 세로 한 칸)로 이루어진 2차원 표(Table)에 저장하고, 표 사이의 논리적 연결을 수학의 집합론으로 정의해 관리하는 시스템이다.
- 일상 비유: 엑셀 시트 여러 장을 “학번” 같은 공통 키로 묶어둔 구조
- 예:
users테이블과orders테이블을user_id로 이어 “누가 뭘 주문했는지” 조회 가능
RDB는 왜 존재하나
데이터 중복을 원천 차단하고 무결성(Integrity, 값이 정확하고 일관된 상태)을 엄격히 보장하기 위해 존재한다.
- 한 사실을 한 곳에만 저장하고 필요할 때 Join(논리적으로 이어붙이기)으로 조회
- 값이 바뀌어도 여러 곳에서 따로 놀 일이 없음 → 업데이트/삭제 시 불일치 제거
한마디 요약: 중복 없이 한 곳에만 저장하고 그때그때 이어붙여 쓰는 게 RDB의 본질.
포함 관계 한눈에 보기
데이터베이스
├─ RDB (관계형)
│ ├─ PostgreSQL ← 오픈소스 서버형 RDB
│ │ └─ pgvector ← PostgreSQL용 벡터 확장
│ │ └─ Supabase ← pgvector를 얹은 BaaS(Backend as a Service)
│ └─ SQLite ← 파일 한 개로 동작하는 초경량 RDB
│ └─ sqlite-vec ← SQLite용 벡터 확장
└─ 벡터 전용 DB
├─ Qdrant ← 서버형 벡터 DB (AI 검색 특화)
└─ LanceDB ← 파일/객체스토리지 기반 임베디드 벡터 DB
벡터 DB는 크게 두 갈래로 나뉜다. “기존 RDB에 벡터 기능을 얹은 형태”와 “처음부터 벡터 검색만을 위해 만든 형태”.
SQLite (초경량 파일형 데이터베이스)
파일 하나로 동작하는 초소형 RDB다. 서버를 띄울 필요가 없다.
- 흔한 서버형 DB(MySQL, Oracle, PostgreSQL 등)와 달리
.db파일 하나가 곧 데이터베이스 - 스마트폰 앱, 웹 브라우저 내부 저장소, 소규모 데스크탑 프로그램(예: Cursor, Claude Code 같은 로컬 도구)에서 가장 많이 쓰인다
- 실제 파일 크기: 보통 수백 KB ~ 수십 MB 수준의 경량 용도
AI/시맨틱 검색과의 관계
원래는 텍스트/숫자만 저장했지만, sqlite-vec 확장(Extension, 기본 기능에 덧붙이는 플러그인)을 설치하면 AI가 문장을 변환한 숫자 배열(Vector, 의미를 수치로 나타낸 좌표)을 저장하고 유사도 검색이 가능해진다.
비용
- 완전 무료(Public Domain)
- 서버 비용도 없고 구독료도 없음. 파일 생성하면 끝
직접 확인
# Python 표준 라이브러리에 이미 들어있음
python -c "import sqlite3; print(sqlite3.sqlite_version)"Qdrant (전문 AI 벡터 데이터베이스)
AI 시맨틱 검색(Semantic Search, 의미가 비슷한 문서를 찾는 검색)만을 위해 특화된 서버형 DB다.
- 일상 비유: 도서관 사서가 “책 제목 일치” 대신 “내용 의미가 비슷한 책”을 골라주는 전담 창구
- 수백만 ~ 수천만 건의 문서/코드에서 “이 질문과 의미가 가장 비슷한 것”을 찾아내는 RAG(Retrieval-Augmented Generation, 검색 증강 생성) 용도로 설계됨
- 속도가 빠르고 대규모 처리에 강함
AI/시맨틱 검색과의 관계
Claude Code, Cursor 같은 AI 에이전트에 회사 전체 코드베이스나 수만 장의 문서를 “기억”시킬 때 메인 엔진으로 쓴다.
비용
| 구분 | 가격 | 조건 |
|---|---|---|
| 자체 호스팅(Self-hosted) | 평생 무료 | 오픈소스이므로 내 서버에 직접 설치. 전기세/호스팅 비만 발생 |
| Qdrant Cloud Free | 평생 무료 | 1GB 용량 클러스터 제공. 수십만 줄 이하 소규모는 충분 |
| Qdrant Cloud 유료 | 시간당 약 $0.01부터 | 사용한 서버 자원/용량만큼 과금 |
직접 확인
# Docker로 로컬에서 바로 띄워보기
docker run -p 6333:6333 qdrant/qdrant
# 브라우저에서 http://localhost:6333/dashboard 열면 관리 UI가 뜬다3대 선택지 한눈에 비교
| 관점 | Qdrant | LanceDB | Supabase(pgvector) |
|---|---|---|---|
| 정체 | 전문 벡터 DB (서버형) | 임베디드 벡터 DB (파일/S3) | RDB(PostgreSQL) + 벡터 확장 |
| 실행 방식 | 별도 서버 프로세스 | 라이브러리 호출 (서버 없음) | RDB 서버 내부에서 동작 |
| 아이들(Idle) 메모리 | 전체를 RAM에 적재 | 약 4MB 수준 | PostgreSQL 기본 점유 |
| 하이브리드 검색(BM25 + Dense) | 네이티브 지원 | FTS(Full-Text Search) 내장 | 제한적, 우회 필요 |
| RDB 기능(트랜잭션/Join) | 없음 | 없음 | 완전 지원 |
| 최적 상황 | 프로덕션 RAG, 고품질 검색 | 로컬 AI 도구, 저비용 검색 | 유저/결제 데이터와 통합 관리 |
1. Qdrant: “검색 품질과 하이브리드가 최우선일 때”
오직 벡터 검색과 AI 애플리케이션을 위해 깎아 만든 전문 벡터 DB다.
장점
- 완벽한 하이브리드 검색(Hybrid Search, 키워드 검색과 의미 검색을 섞는 방식) 지원: 내부적으로 Sparse Vector(BM25 역할, 특정 키워드 매칭용 희소 벡터)와 Dense Vector(의미 기반 밀집 벡터)를 동시에 네이티브로 지원한다. 점수 병합(Score Fusion)까지 DB 단에서 처리되므로 별도 Python 랭킹 로직이 필요 없음
- 메타데이터 필터링(Payload Filtering) 속도: 페이로드 기반 필터링이 강력해서 특정 사용자/폴더 내 코드만 뽑아 검색할 때도 속도 저하가 없다
단점
- 데이터를 RAM에 적재하는 구조라 메모리 비용이 든다
- 단, 1GB 무료 클라우드가 있어 소규모는 무방
추천 상황
- Claude Code에 고품질 MCP(Model Context Protocol) 검색을 붙일 때
- 실무 프로덕션 RAG 구축할 때
2. LanceDB: “로컬 에이전트 / 서버리스 비용 절감이 최우선일 때”
별도 서버 없이 파일 형태로 동작하는 임베디드 벡터 DB. 흔히 “벡터계의 SQLite”라 불린다.
장점
- 압도적으로 가볍다: RAM을 상시 점유하는 Qdrant와 달리 디스크(S3 같은 객체 스토리지 포함)에 두고 필요할 때만 연산한다. 아이들 상태 메모리 약 4MB
- Python/로컬 AI 생태계 궁합: pandas DataFrame이나 Apache Arrow(컬럼형 인메모리 데이터 포맷)와 바로 호환됨. 로컬에서 도는 Claude Code 커스텀 도구 만들 때 셋업이 0초 수준
- FTS(Full-Text Search, 전문 검색) 내장
단점
- 트랜잭션 관리나 복잡한 관계형 쿼리는 불가능함
추천 상황
- 내 PC에서 가볍게 도는 로컬 AI 도구
- 수백만 건 데이터를 비용 없이 S3에 올려두고 검색하고 싶을 때
3. Supabase (pgvector): “기존 RDB와 통합 관리가 최우선일 때”
PostgreSQL 기반 RDB에 pgvector 확장을 얹은 형태다.
pgvector가 제공하는 거리 연산자
| 연산자 | 의미 | 용도 |
|---|---|---|
<-> | L2 거리 | 유클리드 거리 |
<#> | 음의 내적(Inner Product) | 정규화된 벡터 유사도 |
<=> | 코사인 거리 | 임베딩 비교 표준 |
<+> | L1 거리 | 맨해튼 거리 |
인덱스 방식 비교
| HNSW(Hierarchical Navigable Small World) | IVFFlat(Inverted File with Flat) | |
|---|---|---|
| 검색 속도 | 빠름 | 보통 |
| 빌드 시간 | 오래 걸림 | 빠름 |
| 메모리 사용 | 많음 | 적음 |
| 적합 규모 | 대규모 프로덕션 | 중소규모, 빈번한 재빌드 |
장점
- 백오피스 데이터(유저 정보, 결제 내역)와 벡터 데이터를 SQL JOIN 한 방에 처리할 수 있다
- 아키텍처가 단순해진다 (관리할 DB 서버 개수가 하나)
단점
- 전문 검색 엔진이 아니라서 규모가 커지거나 정교한 하이브리드 검색(BM25 결합 등)이 필요하면 확장이 막히거나 직접 Python으로 우회해야 하는 병목이 생긴다
추천 상황
- DB를 하나 더 늘리기 싫은 경우
- 이미 Supabase에 유저 데이터가 모여 있는 풀스택 앱
한마디 요약
“품질 우선은 Qdrant, 비용 우선은 LanceDB, 통합 우선은 pgvector”로 정리됨. 세 가지는 대체재라기보다 우선순위가 다른 도구.