pgvector로 포스트그레스에서 벡터 검색 구현하기: 임베딩 저장, HNSW 색인, 코사인 거리 검색까지

핵심 메시지

• pgvector 확장은 포스트그레스에 고차원 벡터 자료형을 추가해, 벡터를 저장하고 색인하고 조회하게 해 준다.
• 추천, 유사도 검색, 검색 증강 생성(RAG) 같은 기능을 전용 벡터 데이터베이스 없이 기존 데이터베이스 안에서 구현할 수 있다.
• 구현은 스키마 초기화, 임베딩 생성과 저장, 코사인 거리 기반 유사도 검색이라는 세 단계로 나뉜다.
• 벡터 컬럼의 차원 수는 임베딩 모델이 내놓는 차원 수와 정확히 일치해야 하고, 색인할 때와 검색할 때 같거나 호환되는 모델을 써야 한다.
• 근사 최근접 이웃 검색을 위해 HNSW 색인을 만들어 두면 질의 응답이 100밀리초 수준으로 돌아온다.

쉽게 이해하기

영상은 포스트그레스가 왜 강력한 데이터베이스인지를 pgvector 확장을 통해 보여준다. 이 확장을 설치하면 고차원 벡터를 담는 새로운 자료형이 생기고, 벡터를 저장·색인·조회할 수 있게 된다. 덕분에 유사도 검색이나 추천, 검색 증강 생성 같은 기능을 위해 별도의 특수한 데이터베이스를 도입하지 않아도 된다.

닷넷에서는 pgvector 조직이 제공하는 라이브러리를 쓴다. 기본 구현은 포스트그레스용 네이티브 클라이언트인 Npgsql을 기반으로 하고, 그 위에 Dapper와 EF Core, F# 지원이 얹혀 있다. 영상에서는 Dapper를 사용하며, 임베딩 생성은 Ollama로 돌리는 Qwen3 임베딩 0.6B 모델이 맡는다. 이 모델은 1,024차원 벡터를 내놓는다.

환경 구성은 Aspire로 오케스트레이션한다. Ollama 리소스와 포스트그레스 컨테이너를 각각 등록하되, 재시작할 때마다 모델을 다시 받지 않도록 지속 수명과 데이터 볼륨을 지정한다. 포스트그레스 이미지는 기본 이미지에 확장이 들어 있지 않으므로 pgvector가 미리 설치된 이미지를 쓴다. 클라이언트 쪽에서는 Npgsql 데이터소스에 벡터 매핑을 활성화하고, Dapper를 쓸 때는 벡터 타입 핸들러를 등록해야 한다.

실제 작업은 세 단계다. 먼저 확장을 활성화하고 타입 캐시를 다시 읽은 뒤, 임베딩 컬럼을 벡터 자료형으로 선언한 테이블과 근사 최근접 이웃 검색용 HNSW 색인을 만든다. 다음으로 사이트맵에 담긴 180개 남짓한 글의 제목과 본문을 가져와 임베딩을 생성하고 데이터베이스에 넣는다. 이 과정은 몇 분이 걸리므로 보통은 API 엔드포인트가 아니라 백그라운드 작업으로 돌린다.

마지막 단계인 검색은 질의 문자열을 같은 모델로 임베딩한 뒤, 거리 연산자로 저장된 벡터와의 코사인 거리를 계산해 가까운 순으로 정렬하고 개수를 제한하는 SQL 한 문장으로 끝난다. 실제로 분산 메시징의 신뢰성 패턴을 배우고 싶다는 문장을 넣자 아웃박스 패턴, 멱등 컨슈머, 사가 패턴, 분산 시스템의 메시지 순서 문제를 다룬 글들이 돌아왔다. CQRS를 묻는 질의는 약 100밀리초 만에 관련 글만 골라냈다.

주요 인사이트

• 벡터 검색의 원리는 단순하다. 저장해 둔 임베딩과 질의 임베딩 사이의 거리를 재고, 거리가 가까울수록 의미가 비슷하다고 본다.
• 키워드가 정확히 겹치지 않아도 의미가 통하면 찾아준다는 점이 핵심이다. '소프트웨어 아키텍처를 배우고 싶다'는 질의에 스크리밍 아키텍처나 클린 아키텍처를 다룬 글이 상위에 올라온 것이 그 예다.
• 임베딩은 결국 숫자 배열이다. 영상에서 다루는 1,024개의 부동소수점 숫자가 글 내용의 의미를 담고 있으며, 데이터베이스에는 이 배열이 그대로 들어간다.
• 색인 시점과 검색 시점의 임베딩 모델이 다르면 거리 계산이 의미를 잃는다. 같은 모델을 쓰거나 최소한 호환되는 모델을 써야 한다.
• 분산 추적으로 들여다보면 질의 임베딩 생성, 데이터베이스 연결, 벡터 검색 순으로 구간이 나뉘는데 검색 자체는 매우 빠르게 끝난다.

자주 묻는 질문

관련 AI 소식