벡터데이터베이스 pgvector 사용해보기 (with. 랭체인)

https://medium.com/@adarsh.ajay/setting-up-postgresql-with-pgvector-in-docker-a-step-by-step-guide-d4203f6456bd

 

RAG  시스템에 필요한 것들을 개괄적으로 알아봤었다. 그리고 임베딩 모델의 중요성까지 알아봤다.

2025.10.20 - [개발/AI] - RAG 이해하기: Embedding부터 평가 지표까지

 

RAG 시스템에 큰 영향을 주는 요소들은 데이터 전처리, 임베딩, 조회 알고리즘, 그리고 LLM이 대표적이다. 하지만 결국 저장소가 필요한 만큼 벡터 데이터베이스(Vector DB) 역시 간과할 수 없다. 특히 개발자 입장에서는 단순히 빠르기만 한 DB보다는
쓰기 편하고, 조회 알고리즘 옵션이 다양하며, 환경에 맞게 유연하게 쓸 수 있는 도구가 훨씬 중요하다. 그래서 최근 여러 벡터 저장 방식을 테스트하고 있다.

 

그중 첫 번째로 선택한 건 PostgreSQL에서 제공하는 확장 기능인 pgvector였다. 개인적으로 PostgreSQL을 꽤 선호하는 편이기도 하고 현재 만들려는 애플리케이션에서는 어차피 데이터베이스가 필요했기 때문이다 .따라서 굳이 별도의 벡터 DB를 도입하기보다는 PostgreSQL 안에서 벡터 검색을 바로 처리할 수 있다면 효율적이지 않을까 싶었다.

pgvector란?

pgvector는 PostgreSQL에서 벡터 데이터를 다룰 수 있게 해주는 확장(extension)이다. 쉽게 말해, 임베딩 벡터를 테이블 컬럼에 그대로 저장하고, 유사도 검색까지 SQL로 처리할 수 있게 해주는 기능이다.

 

임베딩 모델에서 1536차원짜리 벡터를 생성했다고 가정하자. 기존 PostgreSQL에서는 이걸 단순 JSON이나 배열로 저장할 수는 있어도, “이 벡터와 가장 유사한 항목을 찾아줘” 같은 쿼리를 효율적으로 수행할 방법이 없었다. pgvector는 바로 이 부분을 해결한다.

 

추가되는 부분은 다음과 같다.

 

1. 데이터 타입 추가: vector(n) 형태의 새 컬럼 타입을 제공한다.

예: embedding vector(1536)

 

2. 유사도 계산 지원: 기본적으로 다음 세 가지 거리 계산 방식을 지원한다.

- L2 거리 (Euclidean), 내적 (Inner Product), 코사인 유사도 (Cosine Similarity). 기본 옵션은 코사인 유사도이다.

-- 코사인 유사도 (Cosine Similarity)
SELECT ... ORDER BY embedding <=> query_vector LIMIT n;

-- L2 거리 (Euclidean distance)
SELECT ... ORDER BY embedding <-> query_vector LIMIT n;

-- 내적 (Dot Product)
SELECT ... ORDER BY embedding <#> query_vector LIMIT n;

 

3. 인덱스 구조: 대규모 검색을 빠르게 하기 위해 ivfflat과 hnsw 인덱스를 지원한다. 소규모에서는 인덱스 없이도 충분히 빠르므로 옵셔널한 설정이다.

 

🐳 pgvector 설치

도커를 이용해서 설치하면 편하다.

version: "3.8"

services:
  pgvector:
    image: pgvector/pgvector:pg16
    container_name: rag-pgvector
    restart: unless-stopped
    environment:
      POSTGRES_USER: postgres
      POSTGRES_PASSWORD: 1234
      POSTGRES_DB: ragdb
    ports:
      - "54322:5432"
    volumes:
      - pgvector-data:/var/lib/postgresql/data

volumes:
  pgvector-data:

위 docker-compose.yml 파일을 생헝 후 도커 컴포즈를 실행시키면 된다.

> docker compose up -d

# 확장이 설치 되어있지 않다는 에러가 난다면..
> docker exec -it rag-pgvector psql -U postgres -d ragdb
CREATE EXTENSION vector

확장이 자동설치되어 있지 않은 경우가 있던데 이럴땐 직접 도커에 접속해서 vector 확장을 받아주면 된다. 

 

랭체인에서 사용법

띄워놓은 포스트그레 도커에 접속하기 위한 URL과 임베딩 차원 수, 컬렉션(큰 묶음)을 정해주면 끝이다.

from langchain_postgres import PGVector
from langchain_openai import OpenAIEmbeddings

# ✅ 1. PostgreSQL(pgvector)에 연결
store = PGVector.from_params(
    connection_string="postgresql://postgres:1234@localhost:54322/ragdb",
    embedding_dimension=1536,
    collection_name="documents"
)

# ✅ 2. 사용할 임베딩 모델 지정
embeddings = OpenAIEmbeddings(model="text-embedding-3-small")

# ✅ 3. 예시 문서 삽입
texts = [
    "고양이는 낮잠을 좋아한다.",
    "강아지는 주인을 잘 따른다.",
    "파이썬은 데이터 과학에 자주 사용된다."
]
store.add_texts(texts=texts, embedding=embeddings)

# ✅ 4. 유사도 검색
query = "고양이 관련 문장"
results = store.similarity_search(query, k=2)

for doc in results:
    print(doc.page_content)
    
## 예상 결과 : 고양이는 낮잠을 좋아한다.

사용 후기

pgvector를 직접 써보니, PostgreSQL 안에서 벡터 검색까지 모두 해결할 수 있다는 점이 꽤 매력적이었다. 특히 별도의 벡터 DB 없이도 LangChain과 바로 연동된다는 점 또한 확실한 장점이다. 

 

단순히 SQL 수준에서 실험하려면 SELECT ... ORDER BY embedding <=> query_vector LIMIT n; 형태로 바로 쿼리를 던질 수 있고, LangChain을 통해 자동으로 임베딩과 검색까지 묶으면 코드 양이 확 줄어든다.

 

성능적으로는 소규모 RAG 시스템에서는 다른 벡터데이터베이스와 차이를 느끼기 힘들다. 벤치마크 비교나 GPT와 이야기해본 결과로는 큰 규모의 데이터 기반의 RAG를 구성할 때 그리고 분산 환경에서는 사용하기 불편하고 검색 속도에도 차이를 보인다고 한다.

 

그리고 하이브리드 서치, sparse 검색과 같은 경우에는 API로 제공하지 않아 직접 구현해야하는 부분들이 존재한다. 늘 그렇듯 100% 장점만 있는 건 아니었다.

 

얼마전 긱뉴스에서도 부정적인 글이 올라왔는데, 시작하기 전에 참고해보면 좋을 것 같다.

https://news.hada.io/topic?id=24127

 

마치며

언제나 그렇듯 첫 시작이 가장 힘들다. 임베딩 모델이야 특화된 모델을 가져다 쓰면 되지만, 벡터데이터베이스는 종류도 많고 지원하는 기능도 너무나 다양하다보니 어떤걸 골라야할지 아직도 어려움이 있다.

 

3년전만해도 벡터데이터베이스란 개념은 따로 없었고, 엘라스틱 서치 기반의 벡터 검색, ANN 검색 정도만 존재했었는데 짧은 시간에 다양한 양질의 제품들이 나온 걸 보니 기술의 발전속도가 점점 더 빨라지는 것 같다.

 

짧은 시간 안에 기술이 이렇게 바뀌는 걸 보며, 개발자는 늘 공부해야한다는 걸 또 한번 느꼈다.

 

정리하면 ‘어떤 기술을 쓰느냐’보다 ‘왜, 그리고 어떻게 써야 하는가’를 아는 것 같다.