pgvector와 Pinecone, 480만 문서에서 비용은 3.4배 갈렸다

한 90일 운영 보고는 약 480만 문서와 하루 평균 11만400건의 검색을 다룬 구성에서 월비용을 Pinecone 1,887달러, pgvector 기반 Neon 548달러로 제시했다. 약 3.4배 차이는 이 보고에 적힌 두 구성의 결과다. 제품의 일반적인 가격 차이나 다른 RAG 서비스의 예상 청구액으로 옮겨 쓸 수는 없다.

이미 PostgreSQL을 운영하고 문서 집합이 작거나 안정적이며 검색 결과를 업무 데이터와 즉시 결합해야 한다면 pgvector가 유력하다. 문서와 검색량의 증가를 예측하기 어렵고, 선택적인 메타데이터 필터와 인덱스 운영 부담이 핵심이라면 Pinecone이 유리할 수 있다. 두 선택의 경계는 문서 수만으로 정해지지 않는다. 같은 검색 품질에서 지연과 새 문서 반영 시간을 맞추고, 기존 데이터베이스에 추가되는 비용과 별도 검색 서비스의 비용을 비교해야 한다.

보고된 비용 차이는 어떤 구성에서 나왔나

보고의 pgvector 쪽은 PostgreSQL 확장을 사용한 Neon 구성이다. Pinecone 쪽은 검색 인덱스와 문서 메타데이터를 보관하는 데이터베이스를 함께 계산했다. 벡터를 어디에 두든 원본 문서와 업무 데이터가 계속 필요하다면 그 저장 비용은 남는다. 반대로 기존 PostgreSQL의 자원이 부족해 인스턴스를 키워야 한다면 pgvector의 추가 컴퓨트와 인덱스 저장 공간도 비용에 들어간다.

보고에는 재현에 영향을 주는 설정상의 모순도 있다. Pinecone 구성을 ‘serverless’라고 부르면서 인덱스 규격을 ‘p1.x1’로 적었는데, Pinecone SDK 설명에서 p1.x1은 pod 기반 인덱스 유형이다. 따라서 제시된 청구액을 현재 서버리스 요금표에 대입해 검산하기 어렵다. 공개된 글만으로 실제 청구 내역과 인덱스 구성을 독립적으로 확인할 수도 없다. 이 수치는 특정 운영자의 보고값으로 읽되, 구매 예산의 기준 단가로 사용하기에는 근거가 부족하다.

비용의 차이를 만드는 항목도 서로 다르다. PostgreSQL에서는 검색을 위해 늘린 컴퓨트와 저장 공간을 얼마나 사용할지가 중요하다. Pinecone에서는 별도 인덱스의 저장량과 읽기·쓰기 사용량이 더해지고, 원본 데이터베이스를 유지하는 비용도 고려해야 한다. 비교 기간과 포함 항목을 맞추지 않으면 한쪽 구성에만 공통 비용을 얹는 계산이 된다.

PostgreSQL 안에 둘 때 얻는 것과 조정할 것

pgvector 공식 문서에 따르면 이 확장은 PostgreSQL에서 정확 최근접 검색과 근사 최근접 검색을 제공하며 HNSW와 IVFFlat 인덱스를 지원한다. 벡터와 문서의 게시 상태, 접근 권한, 거래 데이터를 같은 데이터베이스에서 관리할 수 있다. 행과 벡터를 같은 트랜잭션으로 갱신하거나 검색 결과를 SQL 조인으로 연결해야 하는 서비스에는 별도 인덱스로 데이터를 복제하지 않아도 되는 이점이 있다.

그 대신 벡터 검색은 기존 데이터베이스의 메모리와 CPU를 사용한다. HNSW는 검색 품질과 속도를 조정할 수 있지만 인덱스를 만드는 시간과 메모리가 필요하다. IVFFlat은 목록을 구성하고 그중 일부를 탐색하므로 목록 수와 탐색 범위가 결과 품질에 영향을 준다. 이미 운영 중인 PostgreSQL이라도 평균 사용률에 여유가 있다는 사실만으로 검색을 추가할 수 있다고 판단하기는 어렵다. 바쁜 시간에 일반 SQL 작업과 벡터 검색이 자원을 나눠 쓰는 상황을 봐야 한다.

메타데이터 필터가 선택적일수록 근사 검색의 결과 개수도 중요해진다. pgvector의 근사 인덱스에서는 후보를 탐색한 뒤 조건을 적용하므로, 특정 고객에게 공개된 문서처럼 전체의 일부만 남기는 필터는 요청한 개수보다 적은 결과를 돌려줄 수 있다. 반복 인덱스 스캔은 후보를 더 찾도록 하고, 필터 열의 일반 인덱스나 부분 인덱스, 파티셔닝은 다른 검색 경로를 마련한다. 다만 어느 방법이 적합한지는 필터 값의 분포와 쿼리 계획에 달려 있으며, 탐색 범위를 늘리면 지연과 자원 사용도 함께 변한다.

별도 검색 서비스가 유리해지는 조건

Pinecone의 공식 비교 설명은 작고 변화가 적은 데이터 집합과 트랜잭션 조인에는 pgvector가 적합하고, 예측하기 어려운 성장과 선택적인 필터에는 자사 서비스가 유리하다고 정리한다. 같은 설명에서 Pinecone은 자체 벤치마크의 월비용이 더 낮았다고 주장하지만, 그 시험은 공개 운영 보고와 데이터셋, 클라우드 구성, 요청 패턴이 다르다. pgvector의 반복 인덱스 스캔이 추가되기 전 버전을 측정했다는 점도 결과를 그대로 맞대기 어렵게 한다.

Pinecone을 쓰면 애플리케이션은 벡터와 검색에 필요한 메타데이터를 별도 인덱스에 보낸다. 인덱스의 용량과 검색 인프라 운영을 서비스에 맡길 수 있으므로 문서 수와 검색 요청이 빠르게 늘어나는 팀에는 그 관리 부담의 차이가 클 수 있다. 반면 원본 레코드와 검색 인덱스의 동기화는 애플리케이션에 남는다. 문서가 삭제되거나 접근 권한이 바뀐 뒤 검색 결과에 예전 상태가 남는다면, 원본을 다시 조회해도 불필요한 결과가 검색 경로에 들어올 수 있다.

테넌트마다 검색 범위가 다르고 필터 조합이 자주 바뀌는 서비스라면 평균 검색 시간보다 드문 조건에서 충분한 결과가 돌아오는지가 더 중요하다. 분류나 언어처럼 필터가 단순하고 문서 집합도 안정적이라면 PostgreSQL의 기존 인덱스와 쿼리 계획으로 요구사항을 충족할 가능성이 있다. 어느 쪽이든 별도 서비스의 관리 편의와 데이터 복제·동기화 작업을 함께 놓고 운영 부담을 판단해야 한다.

지연 시간은 검색 품질과 함께 비교한다

RAG 응답에는 벡터 검색 외에도 임베딩 생성, 원문 조회, 재정렬, 생성 모델 호출이 이어질 수 있다. 따라서 검색 단계의 p95와 사용자가 답을 받기까지의 전체 p95를 구분해야 한다. 벡터 검색만 빨라져도 다른 단계가 대부분의 시간을 차지한다면 전체 응답에서 얻는 이익은 작다. 반대로 검색이 전체 지연의 큰 부분을 차지하는 서비스라면 두 구성의 차이가 사용자 경험에 직접 나타난다.

지연을 비교할 때는 같은 질의, 같은 필터와 같은 결과 품질이 전제돼야 한다. 근사 검색의 탐색 범위를 줄이면 응답은 빨라질 수 있지만 필요한 근거 문서를 놓칠 수 있다. 사람이 평가한 정답 집합이나 정확 검색 결과를 기준으로 상위 결과의 재현율을 맞춘 뒤 p95를 비교해야 속도 차이를 해석할 수 있다. RAG 검색 단계의 품질이 낮으면 생성 모델이 참조할 근거부터 빠진다.

갱신이 잦은 서비스에는 검색 반영 지연도 별도 목표가 된다. 게시·수정·삭제한 문서의 새 상태가 실제 검색 결과에 나타날 때까지의 시간이다. PostgreSQL 내부에서는 원본 행과 벡터 갱신을 같은 트랜잭션으로 묶을 수 있다. 분리된 검색 인덱스에는 전송과 반영 과정이 더해지므로, 새 문서를 빨리 찾아야 하는 서비스일수록 응답 지연과 구분해 살펴야 한다.

같은 범위로 계산하는 선택 기준

Pinecone의 요금 안내는 데이터베이스의 저장 공간과 읽기·쓰기 사용량을 과금 항목으로 제시하고 요금제별 최소 사용액도 구분한다. PostgreSQL 쪽에는 검색 때문에 추가되는 인스턴스 컴퓨트, 저장 공간, 백업과 운영 시간이 들어간다. 양쪽에서 똑같이 필요한 원본 데이터베이스와 임베딩·재정렬 비용은 함께 포함하거나 함께 제외해야 한다.

실질적인 비교 대상은 서비스 전체 청구서보다 검색 방식을 바꾸면서 늘어나는 비용이다. 기존 PostgreSQL의 기본 비용을 모두 pgvector에 배분하면 내부 검색이 과도하게 비싸 보인다. Pinecone을 쓰면서도 유지해야 하는 원본 데이터베이스를 계산에서 빼면 분리 검색이 과도하게 저렴해 보인다. 공통 비용을 고정한 뒤 각 구성의 추가 비용을 같은 기간과 같은 트래픽으로 환산해야 선택 경계가 드러난다.

• 데이터 규모: 문서 수와 함께 임베딩 차원, 메타데이터 크기, 증가 속도를 넣는다. pgvector에서는 인덱스와 다른 SQL 작업이 함께 쓸 메모리를, Pinecone에서는 저장량과 별도 인덱스에 보관할 속성을 계산한다.
• 필터 선택도: 조건을 적용한 뒤 남는 문서의 비율과 필요한 결과 개수를 적는다. 드문 조건에서 결과가 모자라거나 탐색 비용이 늘어나는지 확인한다.
• 갱신 빈도: 게시·수정·삭제가 얼마나 자주 발생하고 어느 시점까지 검색에 반영돼야 하는지 정한다. 별도 인덱스의 동기화와 실패 복구에 드는 시간을 운영 비용에 넣는다.
• p95 목표: 같은 품질의 결과를 반환하도록 맞춘 뒤 검색 단계와 전체 RAG 경로의 지연을 각각 비교한다. 평균 지연만으로 바쁜 시간의 성능을 대신하지 않는다.
• 운영 인력: PostgreSQL 인덱스 조정과 용량 관리에 쓸 시간, 별도 서비스의 통합과 동기화에 쓸 시간을 나란히 계산한다. 이미 보유한 데이터베이스 운영 역량에 따라 같은 구성의 추가 비용도 달라진다.

작고 안정적인 RAG에서는 기존 PostgreSQL 자원을 활용하는 편이 경제적일 수 있다. 성장 폭이 크고 필터가 선택적이며 인덱스를 관리할 인력이 부족하다면 별도 검색 서비스의 비용을 감수할 이유가 생긴다. 결정에 필요한 값은 어느 제품의 평균적인 우열보다 해당 서비스의 추가 청구액, 필터를 적용한 결과 품질, p95와 검색 반영 시간이다.

함께 읽기:

• RAG가 틀렸다면 모델보다 검색 단계를 먼저 의심하라
• ChatGPT가 EU에서 검색엔진이 됐다…4개월 안에 달라질 책임
• Claude가 문서와 슬라이드를 직접 만든다…유료 플랜부터 순차 적용