Vector DB란 무엇인가?

■ Vector DB의 개념

1. AI가 데이터를 이해하는 방식(숫자 좌표)대로 저장하고 검색해 주는 DB다.

  - 사람은 문자와 의미로 이해하지만, AI는 숫자 벡터(Vector)로 이해한다.

  - Vector DB는 텍스트, 이미지, 음성, 코드 등을 AI가 이해하는 수치 공간(고차원 벡터 공간)으로 변환하여 저장한다.

  - 일반 DB가 "값 저장" 중심이라면, Vector DB는 "의미 기반 검색"에 최적화된 DB다.

  - 보통 벡터 차원은 384, 768, 1024, 1536, 3072 등 수백~수천 차원이다.

  - 즉, 단순 저장소가 아니라 AI 검색을 위한 수학적 공간 관리 시스템이라고 보면 된다.

 

2. 기존 DB는 정확한 글자 찾기라면, Vector DB는 의미 찾기라고 생각하면 된다.

기존DB (정확 매칭 기반)	Vector DB (의미 기반 검색)
WHERE name = '사과'	과일 중에서 빨갛고 달콤한 것
키워드 검색	문장이 달라도 의미가 비슷하면 검색 가능
LIKE 검색	오타가 있어도 검색 가능
Full-text index	번역된 문장도 의미 기반 검색 가능
조건 필터링 중심	이미지 ↔ 텍스트 교차 검색 가능 (멀티모달) 예) 아이폰 배터리 오래가는 법       아이폰 전력 절약 팀 → 단어는 다르지만 의미가 비슷 → Vector 유사 판단 가능

 

3. 작동원리

    3.1. 임베딩(Embedding) 과정

          - 텍스트/이미지를 AI 모델(Embedding Model)에 넣는다.

          - 예: Sentence Transformer, OpenAI Embedding Model 등

          - 출력 결과는 고차원 숫자 배열(Vector)

          예) 사과: [0.1, 0.5, 0.9]

                배: [0.1, 0.6, 0.8] (사과와 숫자가 비슷함 → 거리가 가까움)

                자동차: [0.9, -0.2, 0.1] (사과와 숫자가 완전 다름 → 거리가 멂)

          ※ 실제 환경에서는 3차원이 아니라 1000차원 이상임

    3.2. 벡터 저장

        3.2.1. Vector DB는 다음을 함께 저장한다

                - Vector (숫자 배열)

                - 원본 텍스트/이미지

                - 메타데이터 (작성자, 날짜, 카테고리 등)

        3.2.2. Vector + Metadata + Raw Data를 함께 저장하는 구조

    3.3. 유사도 검색 (Similarity Search)

        3.3.1. 사용자 질문 → 임베딩 → 벡터 생성 → DB 안에 있는 벡터들과 거리 계산 → 가장 가까운 Top-K 개를 반환

        3.3.2. 이때 사용하는 거리 계산 방식

                - 코사인 유사도 (Cosine Similarity)

                - 유클리드 거리 (Euclidean Distance)

                - 내적(Dot Product)

                - Manhattan Distance 등

    3.4. 인덱싱 (속도의 핵심)

        3.4.1. 데이터가 수백만~수억 개가 되면 모든 벡터와 거리 계산은 불가능

        3.4.2. 그래서 사용하는 기술

                - ANN (Approximate Nearest Neighbor, 근사 최근접 탐색)

                - HNSW (그래프 기반 탐색)

                - IVF (Inverted File Index)

                - PQ (Product Quantization)

        3.4.3. Vector DB의 핵심 기술은 사실상 이 고속 근사 탐색 알고리즘이다.

 

4. 결론

  - 데이터는 다차원 공간에 점으로 찍혀 있다.

  - 질문도 점으로 변환된다.

  - 내 질문 점이랑 가장 가까운 점은 무엇인가?

  - 이를 계산해서 가장 의미가 유사한 데이터를 가져온다.

  - 이것이 Vector DB의 핵심 기술인 유사도 검색(Similarity Search)이다.

  - 즉, Vector DB는 의미 공간에서의 거리 계산 엔진이다.

 

■ Vector DB 종류

1. 무료 오픈소스 설치형

    1.1. 종류

          - Milvus(밀버스)

          - ChromaDB(크로마)

          - Weaviate

          - Qdrant

    1.2. 특징

          - 대규모 데이터 처리에 강함

          - 자체 서버 구축 필요

          - ANN 알고리즘 다양

          - 커스터마이징 가능

 

2. 기존 DB의 확장 기능 사용

    2.1. Oracle

          - Oracle Database 23ai

          - 벡터 타입(Vector Data Type) 공식 지원

          - SQL 기반 벡터 검색 가능

          - 기존 Oracle 환경과 통합 용이

    2.2. PostgreSQL

          - pgvector 플러그인 설치

          - SQL로 벡터 검색 가능

          - 기존 RDB와 결합이 쉬움

 

3. 클라우드형 Vector DB (관리형 서비스)

    3.1. 종류

          - Pinecone

          - Amazon (OpenSearch 벡터 검색 지원)

          - Microsoft (Azure AI Search 벡터 검색 지원)

          - Google (Vertex AI Vector Search 지원)

    3.2. 특징

          - 서버 관리 불필요

          - 빠른 도입 가능

          - 비용은 사용량 기반 과금

 

■ Vector DB의 핵심 메커니즘

1. RAG (Retrieval-Augmented Generation, 검색 증강 생성)의 엔진

  - AI(LLM)는 기본적으로 학습 데이터 기반 모델

  - 최신 정보, 사내 문서, 정책 문서 등은 모름

  - 이를 Vector DB에 저장해 두고 필요할 때 꺼내 씀

    1.1. RAG 흐름

          - 문서 → 임베딩 → Vector DB 저장

          - 사용자 질문 → 임베딩

          - 유사 문서 Top-K 검색

          - 검색 결과를 LLM에게 콘텍스트로 전달

          - LLM이 근거 기반 답변 생성

    1.2. Vector DB는 AI의 외부 메모리 (External Memory) 역할

 

2. 유사도 계산 방식

    2.1. 코사인 유사도 (Cosine Similarity)

          - 벡터의 방향 유사도 측정

          - 길이보다 "방향" 중심

          - 문장 의미 비교에 가장 많이 사용

    2.2. 유클리드 거리 (Euclidean Distance)

          - 두 점 사이 직선거리

          - 실제 거리 기반 계산

    2.3. 내적 (Dot Product)

          - 추천 시스템에서 많이 사용

          - 벡터 크기 영향 포함

          - 실제 서비스에서는 대부분 Cosine + HNSW 조합이 많이 사용됨

 

3. Vector DB의 추가 핵심 요소

    3.1. Hybrid Search (하이브리드 검색)

          - 키워드 검색 + 벡터 검색 결합

          - 예: "2024년 작성된 보안 정책 문서"

          - 날짜 필터링 (메타데이터 검색)

          - 의미 검색 (벡터 검색)

    3.2. Chunking (문서 분할 전략)

          - 긴 문서를 통째로 임베딩하면 정확도 저하

          - 보통 500~1000 토큰 단위로 분할

          - Overlap 전략 사용 (겹치게 자르기)

          - RAG 성능은 Chunk 설계에 크게 좌우됨

    3.3. Embedding 모델 선택이 성능을 좌우

          - Vector DB 자체보다 어떤 Embedding 모델을 쓰느냐가 더 중요함

          - 도메인 특화 모델 사용 시 정확도 급상승

    3.4. 한계점

          - 숫자 기반이므로 완벽한 의미 이해는 아님

          - 거리가 가깝다고 항상 정답은 아님

          - 데이터가 많아질수록 품질 관리 필요

          - 임베딩 모델 변경 시 전체 재임베딩 필요