파인콘 vs Qdrant vs Weaviate vs Milvus vs pgvector: 2026 최신 벡터 데이터베이스 비교 완전 가이드

2026년 8월 현재, RAG(검색 증강 생성) 파이프라인과 AI 에이전트의 품질을 실질적으로 결정하는 것은 모델이 아니라 검색 계층입니다. 아무리 좋은 LLM을 붙여도 근거 문서를 제대로 못 찾아오면 답변은 무너집니다. 그래서 2026년의 벡터 데이터베이스 비교는 “어떤 게 빠른가”가 아니라 “우리 조직의 데이터 위치·운영 인력·하이브리드 검색 요구에 어떤 게 맞는가”라는 질문으로 바뀌었습니다. 이 글은 파인콘(Pinecone), Qdrant, Weaviate, Milvus(Zilliz), pgvector 5종을 공식 문서·공식 요금 페이지 기준으로만 정리한 실무 가이드입니다.

특히 지금은 타이밍이 묘합니다. Milvus 3.0이 2026년 7월 27일에 발표되고 7월 29일에 릴리스 태그가 붙었습니다. 이 글을 쓰는 시점 기준 채 일주일이 안 된 소식이고, 컨셉은 “Lake-Native” — 오브젝트 스토리지에 이미 쌓여 있는 Parquet·Iceberg·Lance·Vortex 테이블을 벡터 DB로 복사하지 않고 그대로 검색한다는 접근입니다. 데이터 레이크를 이미 운영 중인 조직이라면 “적재 파이프라인부터 새로 만든다”는 전제 자체가 사라지는 변화입니다.

같은 시기에 pgvector 쪽에서는 훨씬 급한 뉴스가 있었습니다. CVE-2026-3172 — 병렬 HNSW 인덱스 빌드에서 정수 wraparound로 버퍼 오버플로가 발생하는 취약점으로, 0.6.0부터 0.8.1까지 전 버전이 영향을 받고 0.8.2에서 수정되었습니다. 그리고 여러 블로그가 “pgvector 0.9”라고 쓰고 있지만 0.9는 존재하지 않습니다. 2026년 8월 2일 기준 최신은 **0.8.6(2026-07-29)**입니다. 이 글에서는 이런 잘못 퍼진 수치를 하나씩 공식 값으로 바로잡습니다.

아래에서는 5종의 종합 비교표부터 시작해 제품별 기능 딥다이브, 성능을 정직하게 다루는 법, 공식 요금 완전 비교, 사용자 유형별 추천, 실전 팁과 흔한 실수, FAQ까지 순서대로 다룹니다. 벤치마크 숫자를 그럴듯하게 나열하는 대신, 검증된 것만 숫자로 쓰고 검증되지 않은 것은 검증되지 않았다고 말하는 방식으로 갑니다. 그게 실제로 도입 결정을 내릴 때 훨씬 쓸모 있기 때문입니다.

1. Executive Summary: 2026년 8월 5대 벡터 데이터베이스 한눈에 보기

시간이 없는 AI 엔지니어와 테크 리더를 위해, 5종의 설계 철학·최신 버전·가격 구조·무료 티어·장단점을 한 표로 압축했습니다.

📊 2026년 8월 최신 5대 벡터 DB 종합 비교표

이 표에서 가장 먼저 눈에 들어와야 하는 건 마지막 줄입니다. 5종은 경쟁 제품이라기보다 서로 다른 조직 상태에 대응하는 선택지입니다. Postgres를 이미 쓰고 벡터가 1천만 개 이하라면 pgvector가 사실상 기본값이고, 별도 벡터 DB를 도입한다는 건 운영 인력과 동기화 파이프라인이라는 새로운 비용을 스스로 만드는 일입니다.

2. 5대 벡터 데이터베이스 핵심 기능 딥다이브

🌲 1) 파인콘 (Pinecone) - 완전관리형 서버리스의 기준점

• 서버리스가 완전한 기본: 과거의 파드(pod) 기반 인덱스는 레거시가 되었고, 지금은 서버리스가 표준 경로입니다. 노드 사이징·샤딩·리밸런싱을 고민할 필요가 없다는 점이 파인콘의 존재 이유입니다. 인프라 엔지니어가 없는 팀에게는 이 한 줄이 다른 모든 비교 항목을 압도합니다.
• 인덱스 3종을 전부 서버리스에서: dense / sparse / full-text 세 가지 인덱스 타입을 모두 지원하며, full-text는 BM25와 Lucene 쿼리 문법을 씁니다. “sparse는 파드 전용”이라는 오래된 정보가 아직도 돌아다니는데, 이는 사실이 아닙니다. 셋 다 서버리스에서 동작합니다.
• 자체 임베딩·리랭킹 모델 제공: sparse 임베딩용 **pinecone-sparse-english-v0**를 자체 제공하고, 리랭커로 **bge-reranker-v2-m3**를 씁니다. 무료·Builder 플랜은 이 리랭커만 쓸 수 있고, Standard 이상에서 전체 모델을 쓸 수 있습니다.
• 알아두면 사고를 막는 하드 제한 ① 일반 인덱스: 레코드당 메타데이터 40KB, top_k 최대 10,000, 쿼리 결과 크기 최대 4MB, 메타데이터 필터 $in/$nin은 연산자당 최대 10,000개 값입니다. dense 인덱스로 후보를 넉넉히 뽑아 리랭킹하는 파이프라인이라면 여유는 생각보다 큽니다.
• 알아두면 사고를 막는 하드 제한 ② sparse 인덱스 전용: sparse 인덱스에는 훨씬 빡빡한 별도 한도가 붙습니다. non-zero 값 최대 1,000개(일반 sparse 벡터 한도는 2,048개), top_k 최대 1,000, 업서트 10/초, 쿼리 100 QPS입니다. 여러 비교 글이 이 sparse 전용 숫자를 파인콘 전체의 한도인 것처럼 옮겨 적는데, top_k 1,000은 sparse 인덱스에만 해당하고 일반 한도는 10,000입니다. 대량 초기 적재 일정은 sparse 쪽 속도를 전제로 잡아야 합니다.
• 2026년의 변화: 기존 Starter와 Standard 사이의 간극을 메우는 Builder $20/월 정액 티어가 신설되었습니다. 무료로는 부족하지만 사용량 과금은 무서운, 딱 그 구간의 개인 개발자·소규모 팀을 겨냥한 플랜입니다.

🦀 2) Qdrant - Rust 기반, 메모리 효율에 진심인 엔진

• TurboQuant으로 메모리를 반으로: **v1.18.0(2026-05-11)**에서 도입된 TurboQuant은 Google Research가 개발한 양자화 기법입니다. 벡터에 빠른 Hadamard 회전을 적용해 값을 좌표 전반에 고르게 재분포시킨 뒤 압축하는 방식으로, 스칼라 양자화(SQ) 대비 메모리를 2배 절약하면서 비슷한 recall과 속도를 낸다는 것이 Qdrant 자체 측정치입니다. 최대 8배 압축까지 가능합니다. 벡터 DB 비용의 상당 부분이 RAM이라는 걸 감안하면 이건 그냥 기능이 아니라 청구서에 직결되는 변화입니다.
• 운영자를 위한 관측성 강화: 같은 v1.18에서 컬렉션의 디스크·RAM·페이지캐시 사용량을 벡터/페이로드/인덱스 컴포넌트별로 분해해서 보여주는 메모리 모니터링 Web UI와 API가 추가됐습니다. “왜 메모리가 이만큼 쓰이지”를 추측 대신 확인할 수 있게 된 겁니다. 감사로그 조회 API와 요청 추적 ID도 함께 들어왔습니다.
• 무중단 스키마 변경: 컬렉션 재생성 없이 named vector를 추가·삭제할 수 있습니다. 임베딩 모델을 교체하거나 멀티벡터 실험을 하는 팀에게는 재적재 비용을 통째로 아끼는 기능입니다.
• 하이브리드 검색이 1급 시민: v1.7부터 네이티브 sparse 벡터를 지원해, 하나의 컬렉션에 dense와 sparse를 함께 두고 Query API에서 **RRF 또는 가중 선형 융합(linear fusion)**으로 단일 쿼리 처리가 가능합니다.
• 벤더 존속성: 2026년 3월 12일 Series B $50M을 유치해 누적 $87.8M이 되었습니다(Advance Venture Partners 주도, Bosch Ventures 신규 참여). 오픈소스 프로젝트의 지속 가능성을 따질 때만 의미 있는 정보이고, 제품 우열의 근거는 아닙니다.
• 그래서 뭘 포기하게 되나 — Qdrant의 트레이드오프: 강점이 단일 노드 효율에 몰려 있는 만큼, 1억 벡터를 넘어가는 분산 스케일아웃에서는 Milvus 쪽의 운영 사례와 아키텍처가 더 두텁습니다. 또 공식 요금 페이지에 단가 숫자가 없어 도입 결재 전에 정확한 월 비용을 산정하기 어렵고, 콘솔에서 스펙을 구성해 보거나 영업 견적을 받아야 합니다. 예산 승인 절차가 빡빡한 조직에서는 이게 생각보다 큰 마찰입니다.
• 그 이전 릴리스도 실속: v1.17(2026년 2월)에서 Relevance Feedback 쿼리와 검색 지연시간 개선이, v1.16에서 계층형 멀티테넌시(tenant promotion)와 ACORN 기반 필터링 벡터 검색 개선이 들어왔습니다. 최신 패치는 **v1.18.3(2026-07-17)**입니다.

🕸️ 3) Weaviate - 하이브리드 검색이 가장 오래 검증된 곳

• alpha 하나로 조절하는 하이브리드: 네이티브 BM25 모듈과 dense 벡터를 쿼리의 alpha 파라미터 하나로 융합합니다. 키워드 쪽에 무게를 줄지 의미 검색 쪽에 줄지를 코드 한 글자로 바꿀 수 있다는 건, 튜닝을 반복해야 하는 실무에서 생각보다 큰 이점입니다. 5종 중 하이브리드 검색을 가장 오래 운영해 온 제품입니다.
• 멀티테넌시가 1급 기능: 테넌트 분리와 하이브리드 검색의 조합이 강점이라, 고객사별로 데이터를 격리해야 하는 B2B SaaS에 자연스럽게 맞습니다.
• v1.35에서 들어온 실무 기능들: Object TTL(객체 수명 자동 만료)로 오래된 문서를 자동 정리할 수 있고, zstd 압축, flat index + RQ 양자화 GA(1.34에서 프리뷰였던 것), 런타임 설정 가능한 OIDC 인증서, operational modes(노드별로 처리 가능한 작업 종류를 제어)가 추가됐습니다.
• 문서 이미지를 그대로 임베딩: v1.35의 multi2multivec-weaviate 모듈은 문서 이미지를 임베딩해 텍스트 쿼리로 검색하는 멀티모달 문서 임베딩을 지원합니다. OCR 파이프라인을 거치지 않고 스캔 PDF·표·레이아웃이 있는 문서를 다루려는 팀이라면 눈여겨볼 만합니다.
• 지원 정책은 빡빡한 편: 최신 3개 마이너 버전(1.36 / 1.37 / 1.38)만 버그·보안 패치를 받습니다. 최신은 **v1.38.x(2026-06-05)**이고, 그 앞으로 v1.37.x(2026-04-16), v1.36.x(2026-02-24), v1.35.x(2025-12-17), v1.34.x(2025-11-05)가 이어집니다. 버전을 오래 묵히는 운영 습관은 여기서 통하지 않습니다.

🐦 4) Milvus / Zilliz - 대규모 분산과 “레이크 네이티브”의 등장

• Milvus 3.0, 컨셉은 Lake-Native: 2026년 7월 27일 발표, 7월 29일 릴리스. 핵심은 레이크 네이티브 인덱싱입니다. 오브젝트 스토리지의 오픈 테이블 포맷(Parquet / Lance / Iceberg / Vortex)에 있는 데이터를 벡터 DB로 복사하지 않고 검색할 수 있는 “zero-copy external collections”를 제공합니다. ETL로 수십 TB를 복제해 넣던 관행을 건너뛴다는 뜻입니다.
• Loon: 새 스토리지 엔진: 매니페스트 기반의 새 스토리지 엔진으로, 오브젝트 스토리지에서 저지연 포인트 액세스를 할 때 발생하는 read amplification을 크게 줄이는 것이 목표입니다. 기본 저장 포맷은 Vortex입니다.
• 검색·랭킹을 엔진 안으로: 단순 최근접 이웃 검색을 넘어 리치 랭킹, 집계, sparse 검색, 멀티벡터 검색을 엔진 내부에서 처리합니다. learned-sparse 벡터를 위한 SINDI, 서버사이드 MinHash 생성, nullable 벡터 필드, 전문 검색용 커스텀 사전, Faiss 호환 인덱스 확대 지원도 함께 들어왔습니다. 스냅샷(무복사 시점 컬렉션 뷰)과 Spark 연동도 제공됩니다.
• 여전히 현역인 Milvus 2.6: Woodpecker라는 자체 클라우드 네이티브 WAL로 Kafka·Pulsar 의존을 걷어냈습니다. zero-disk 설계라 모든 로그를 S3·GCS·MinIO 같은 오브젝트 스토리지에 영속화하며, 2.6부터 WAL은 선택적입니다. Streaming Node가 신설되어 Query Node·Data Node와 협력하고, 계층형 스토리지와 RaBitQ 양자화, 전문 검색·멀티테넌시가 강화됐습니다. 벤더는 메모리 72% 절감(recall 유지), Elasticsearch 대비 4배 성능을 주장하는데, 이는 Milvus(Zilliz) 자체 측정치라는 점을 감안해서 봐야 합니다.
• 관리형 Zilliz Cloud의 최근 변화: 2026년 1월 1일부로 스토리지 요금을 AWS·Azure·GCP 3사 모두 $0.04/GB/월로 통일했습니다. 크로스 리전·크로스 클라우드 데이터 전송이 도입되면서 전송 비용은 마크업 없이 공급자 원가 그대로 전가됩니다. Milvus 2.6.x는 2026년 1월 20일 Zilliz Cloud에서 GA되었고, 다층 스토리지가 프로덕션에서 캐시 히트율 90% 이상, 스토리지 비용 최대 87% 절감을 낸다는 것이 Zilliz 자체 측정 주장입니다.
• 운영 도구도 개편 중: Attu 3.0 Beta(2026년 7월)가 나오면서 멀티 클러스터 관리, AI 에이전트, 콘솔 전면 재작성이 이뤄졌습니다.

🐘 5) pgvector - “새 DB를 도입하지 않는다”는 가장 강력한 선택지

• 먼저 버전부터 확인하세요: 최신은 **0.8.6(2026-07-29)**입니다. “pgvector 0.9”는 존재하지 않습니다. 여러 기술 블로그가 이렇게 잘못 표기하고 있으니 사내 문서에 복붙하기 전에 확인하시기 바랍니다.
• 🔴 CVE-2026-3172 — 지금 당장 확인해야 할 것: 병렬 HNSW 인덱스 빌드에서 정수 wraparound로 인한 버퍼 오버플로가 발생합니다. 영향 버전은 0.6.0 ~ 0.8.1, 수정은 0.8.2입니다. HNSW 인덱스를 병렬 워커로 생성하거나 REINDEX할 수 있는 DB 사용자가 다른 릴레이션의 민감 데이터를 유출하거나 DB 서버를 크래시시킬 수 있습니다. 즉시 패치가 어렵다면 임시 완화책으로 **max_parallel_maintenance_workers = 0**을 설정해 병렬 HNSW 빌드를 비활성화하십시오.
• 2026년 릴리스가 촘촘합니다: 0.8.3(2026-06-17)에서 HNSW 배큐밍 중 인덱스 손상 가능성과 PostgreSQL 18에서의 거리 계산 성능 저하가 수정됐고, 0.8.4(2026-06-30)에서 HNSW 배큐밍 오류 메시지와 유지보수 중 삽입 문제, IVFFlat 빌드 메모리 과할당이 잡혔습니다. 0.8.5(2026-07-08)는 소규모 데이터셋의 IVFFlat 인덱스 구축 메모리 요구량을 줄였고, 0.8.6은 32비트 시스템의 IVFFlat 빌드 버퍼 오버플로, array→sparsevec 변환 시 non-zero 개수 제한, 중첩 루프 조인 시 IVFFlat 스캔 메모리를 손봤습니다. 버그 수정이 이렇게 이어진다는 건 실제 프로덕션 사용량이 많다는 신호이기도 합니다.
• 인덱스는 HNSW와 IVFFlat 둘: HNSW는 속도-recall 트레이드오프가 우수하지만 빌드가 느리고 메모리를 더 씁니다. IVFFlat은 빌드가 빠르고 가볍습니다. 병렬 HNSW 빌드에서 maintenance_work_mem을 올린다면 공유 메모리 크기도 최소 그만큼 잡아야 오류가 나지 않습니다. PostgreSQL 18 지원은 0.8.1(2025-09-04)부터입니다.
• 가장 큰 약점은 하이브리드: 하이브리드 검색이 내장되어 있지 않습니다. tsvector 전문 검색과 벡터 거리를 각각 구한 뒤 애플리케이션 코드에서 직접 융합(RRF 등)해야 합니다. 5종 중 손이 가장 많이 가는 부분이고, 이 항목 하나가 전용 벡터 DB로 넘어가는 가장 흔한 이유입니다.
• 성능을 더 짜내고 싶다면: Timescale의 pgvectorscale 0.9.0은 pgvector 위에 얹는 별도 확장으로, PG18 지원이 추가되고 PG13 지원이 제거되었으며 동시(concurrent) 인덱스 빌드를 지원합니다. Postgres 자체의 선택지가 궁금하다면 PostgreSQL·MySQL·MongoDB 데이터베이스 비교 글을 함께 보시면 스택 전체 그림이 잡힙니다.

3. 성능 벤치마크 대결: 정직하게 말하면 “직접 재보세요”

이 섹션에서 화려한 QPS 표를 기대하셨다면 미리 말씀드립니다. 2026년 8월 기준, 이 5종을 동일 조건에서 비교한 신뢰할 만한 교차검증 벤치마크는 공개되어 있지 않습니다. 그래서 저희는 표를 만들지 않습니다. 만들면 그건 거짓말이 되기 때문입니다.

실제로 떠도는 수치들이 얼마나 충돌하는지 보시면 이해가 빠릅니다. 같은 문단 안에서 Qdrant 5,000만 벡터가 41.47 QPS로 적힌 출처가 pgvectorscale은 471 QPS라고 씁니다. 10배 차이인데 하드웨어도 인덱스 파라미터도 명시되지 않았습니다. p99 지연시간도 “1,000만 벡터에서 Qdrant 약 12ms / Weaviate 약 16ms / Milvus 약 18ms”라는 출처와 “Qdrant 8ms 미만”이라는 출처가 나란히 존재합니다. “Pinecone 10억 벡터 50ms p95 / 10,000 QPS vs Qdrant 20ms p95 / 15,000 QPS” 같은 인상적인 문장은 출처를 따라가면 SEO 블로그 하나로 수렴하고, 조건은 어디에도 없습니다.

[아키텍처 강점 기반 정성 평가 — 수치가 아니라 성향입니다]
Qdrant   : ⭐⭐⭐⭐⭐ 단일 노드 지연시간 (Rust + SIMD 최적화 HNSW)
Milvus   : ⭐⭐⭐⭐⭐ 초대규모 처리량 (1억+ 벡터 분산 아키텍처)
Weaviate : ⭐⭐⭐⭐☆ 하이브리드 워크로드 최적화 (무거운 필터 시 QPS 저하)
Pinecone : ⭐⭐⭐⭐☆ 운영 부담 없이 얻는 안정적 성능 (튜닝 여지는 적음)
pgvector : ⭐⭐⭐☆☆ 100만 규모까지는 전용 DB와 실용적으로 대등

그래서 숫자 대신 아키텍처의 성향으로 이야기하는 편이 정확합니다. Qdrant는 Rust 기반 HNSW에 SIMD 최적화를 얹어 단일 노드 지연시간에 강점이 있다고 알려져 있습니다. Milvus는 분산 아키텍처라 1억 개 이상 규모의 처리량에서 유리합니다. Weaviate는 하이브리드 워크로드에 최적화되어 있지만 메타데이터 필터가 무거워지면 QPS가 떨어지는 경향이 보고됩니다. pgvector는 HNSW 인덱스를 쓰면 100만 규모에서는 전용 벡터 DB와 실용적으로 대등하다는 평가가 일반적입니다.

벤더 자체 벤치마크는 출처를 명시하면 참고 가치가 있습니다. Milvus 2.6의 메모리 72% 절감·Elasticsearch 대비 4배는 Zilliz 자체 측정이고, Zilliz Cloud 다층 스토리지의 캐시 히트율 90%+·스토리지 비용 최대 87% 절감 역시 마찬가지입니다. Qdrant TurboQuant의 SQ 대비 메모리 1/2·최대 8배 압축도 Qdrant 자체 측정입니다. 세 수치 모두 “제조사 발표 연비” 정도로 읽으시면 됩니다. 참고로 Milvus 3.0은 발표 1주일 차라 독립 벤치마크가 아직 존재하지 않습니다. 지금 3.0의 성능 수치를 제시하는 글이 있다면 출처를 의심하셔도 좋습니다.

결론적으로 이 항목의 실무 답은 하나입니다. 여러분의 임베딩, 여러분의 차원 수, 여러분의 필터 조건, 여러분의 하드웨어로 ANN-Benchmarks나 VectorDBBench를 직접 돌리세요. 1536차원과 384차원은 완전히 다른 게임이고, 메타데이터 필터가 붙는 순간 순위가 뒤집히는 일도 흔합니다. 남의 벤치마크로 결정한 아키텍처는 대개 프로덕션 첫 달에 후회로 돌아옵니다.

4. 요금제 · 가격 완전 비교

가격은 이 벡터 데이터베이스 비교에서 가장 오해가 많은 영역입니다. 특히 파인콘의 Read/Write Unit 단가는 여기저기서 인용되는 값이 공식 페이지와 약 2배 차이가 납니다. 아래는 전부 공식 요금 페이지 기준입니다.

[유료 진입 장벽 — 월 최소 비용 순]
pgvector        : $0        (오픈소스, Postgres 호스팅비만 부담)
Pinecone Builder: $20/월     (정액, 10GB 스토리지 포함)
Weaviate Flex   : $45/월~    (PAYG, 2025-10 개편으로 $25에서 인상)
Pinecone Standard: $50/월    (최소 사용액 — 정액 아님)
Weaviate Premium : $400/월~  (선불 계약)
Pinecone Enterprise: $500/월 (최소 사용액, 99.95% SLA)
Qdrant / Zilliz  : 사용량 기반 — 공식 단가 미공개, 직접 문의 필요

💰 파인콘(Pinecone) 공식 요금표

여러 비교 글이 파인콘 Read Unit을 $8.25/100만, Write Unit을 $2.00/100만으로 적고 있습니다. 공식 값은 Standard 기준 RU $1618, WU $44.50입니다. 예산 모델을 이 잘못된 숫자로 짰다면 실제 청구서는 예상의 두 배가 됩니다. 언제 인상되었는지는 공식적으로 확인되지 않으므로 “올랐다”고 단정하기보다 현재 공식가가 이렇다고 기억하시는 편이 안전합니다.

💰 Weaviate 공식 요금표

Weaviate에서 반드시 짚어야 할 건 **과금 단위가 “100만 차원(dimension)“**이라는 점입니다. 벡터 개수가 아니라 벡터 수 × 차원 수로 계산되므로, 1536차원 임베딩 모델을 쓰면 384차원 모델을 쓸 때보다 같은 문서 수에서 비용이 4배로 뜁니다. 임베딩 모델 선택이 곧 인프라 비용 결정이 되는 구조입니다. 또한 2025년 10월 요금제가 전면 개편되면서 기존 Serverless/Enterprise 티어가 폐기되고 Flex/Premium 체계로 바뀌었고, 시작가가 $25에서 $45로 인상되었습니다. 참고로 일부 글이 언급하는 “Plus $280” 티어는 공식 페이지에 존재하지 않습니다. 무료 Sandbox는 객체 10만 개 / 메모리 1GB / 디스크 10GB / 컬렉션 1개 / 테넌트 최대 3개이며, Dedicated는 주요 클라우드 약 40개 리전을 지원하고 하위 티어는 리전이 제한됩니다.

💰 Qdrant · Zilliz · pgvector

숨은 비용 이야기를 하겠습니다. 첫째, 5종 모두 한국 원화(KRW) 공식 가격표가 없습니다. 전부 USD 청구이므로 환율 변동이 그대로 예산에 반영되고, 어딘가에서 본 “월 O만 원” 표기는 누군가의 임의 환산일 뿐 공식 가격이 아닙니다. 둘째, “최소 사용액”과 “정액”은 완전히 다릅니다. 파인콘 Standard의 $50은 정액 요금이 아니라 최소 사용액이라, 트래픽이 늘면 RU/WU 과금이 그 위로 쌓입니다. 반면 Builder의 $20은 정액이라 예측이 쉽습니다. 셋째, 셀프호스팅의 “무료”는 인건비가 빠진 숫자입니다. Qdrant나 Milvus를 직접 운영하면 라이선스 비용은 0이지만 백업·모니터링·업그레이드·장애 대응이 팀의 시간을 먹습니다. 인프라 담당이 없다면 관리형 $50이 셀프호스팅보다 저렴한 경우가 많습니다. 클라우드 계정 자체의 비용 구조가 궁금하다면 AWS·GCP·Azure 클라우드 제공업체 비교 글을 함께 참고하시면 총소유비용(TCO) 계산이 훨씬 정확해집니다.

5. 사용자 유형별 최종 추천 가이드

🎯 1) 이미 PostgreSQL을 운영 중이고, 벡터가 1천만 개 이하인 팀

• 최적의 선택: pgvector
• 이유: 새 데이터베이스를 도입한다는 건 동기화 파이프라인과 운영 대상 하나를 새로 만드는 일입니다. 트랜잭션 안에서 원본 레코드와 임베딩을 함께 커밋할 수 있다는 것만으로도 정합성 버그의 절반이 사라집니다. HNSW 인덱스를 쓰면 이 규모에서는 전용 DB와 실용적으로 대등하다는 평가가 일반적입니다. 단, 시작 전에 버전이 0.8.2 이상인지 반드시 확인하세요.

🎯 2) 인프라 엔지니어가 없는 초기 스타트업 / 1인 개발자

• 최적의 선택: 파인콘(Pinecone) Builder 또는 Qdrant Free
• 이유: 파인콘 Builder는 $20/월 정액으로 10GB 스토리지와 500만 WU·200만 RU를 주기 때문에 청구서가 튀지 않습니다. 예산이 0원이라면 Qdrant의 영구 무료 티어(0.5 vCPU / 1GB RAM / 4GB 디스크)가 시간 제한 없이 계속 쓸 수 있어 프로토타입 단계에 적합합니다.

🎯 3) 고객사별 데이터 격리가 필수인 B2B SaaS

• 최적의 선택: Weaviate
• 이유: 멀티테넌시 자체는 Weaviate만의 것이 아닙니다. Qdrant도 v1.16에서 계층형 멀티테넌시(tenant promotion)를 넣었고 Milvus 2.6도 멀티테넌시를 강화했습니다. Weaviate를 고르는 진짜 이유는 테넌트 분리와 네이티브 BM25 하이브리드가 한 제품 안에서 결합된다는 점입니다. B2B 문서 검색은 계약번호·SKU처럼 정확 일치가 필요한 쿼리가 많아 테넌트별 하이브리드가 사실상 필수인데, 여기에 Object TTL로 계약상 데이터 파기 기한까지 자동 처리됩니다. 이 세 가지가 한꺼번에 필요한 게 아니라 격리만 필요하다면 Qdrant가 충분한 차선책입니다. 다만 Weaviate는 차원 수 기반 과금이므로 고차원 임베딩을 쓴다면 비용 시뮬레이션을 먼저 하셔야 합니다.

🎯 4) 데이터 레이크(Iceberg/Parquet)를 이미 운영 중인 대기업

• 최적의 선택: Milvus 3.0
• 이유: 레이크 네이티브 인덱싱으로 Parquet·Lance·Iceberg·Vortex 테이블을 복사 없이 검색할 수 있습니다. 수십 TB를 벡터 DB로 복제해 넣는 ETL과 그 이중 저장 비용이 통째로 사라집니다. 다만 발표된 지 일주일 차라 먼저 스테이징에서 검증하시고, 안정성이 최우선이라면 GA된 2.6 계열을 병행 고려하세요.

🎯 5) 비용에 민감하면서 프로덕션 RAG 품질도 포기 못 하는 팀

• 최적의 선택: Qdrant
• 이유: TurboQuant이 스칼라 양자화 대비 메모리를 절반으로 줄인다는 점이 결정적입니다. 벡터 DB 비용의 큰 부분이 RAM이기 때문에 이 절감은 곧바로 인프라 청구서로 이어집니다. 네이티브 sparse + RRF 융합으로 하이브리드 검색도 코드 몇 줄이면 끝납니다.

🎯 6) 벡터 1천만~1억 개, 데이터 레이크도 없고 Postgres도 아닌 중간 규모 팀

• 최적의 선택: 운영 인력이 있으면 Qdrant, 없으면 파인콘 Standard
• 이유: 이 구간이 사실 가장 흔한 프로덕션 RAG인데, 앞의 기준들 사이에 끼어 답이 없어 보이기 쉽습니다. pgvector는 1천만 개 부근에서 인덱스 빌드 시간과 메모리가 급격히 부담스러워지고, Milvus 3.0의 레이크 네이티브는 레이크가 없으면 가치가 발휘되지 않은 채 분산 운영 복잡도만 남습니다. 그래서 판단 기준은 규모가 아니라 “이걸 굴릴 사람이 있는가” 하나입니다. 백업·모니터링·업그레이드를 감당할 인프라 담당이 있다면 Qdrant가 메모리 효율(TurboQuant)과 네이티브 하이브리드로 비용 대비 가장 유리하고, 그 사람이 없다면 파인콘 Standard가 운영 인건비를 통째로 없애 줍니다. Standard는 정액이 아니라 월 최소 사용액 $50 위에 RU/WU가 쌓이는 구조라는 점만 예산에 반영하세요.

🎯 7) 규제 산업(금융·의료)이라 SLA와 감사 요건이 먼저인 조직

• 최적의 선택: 파인콘 Enterprise, Zilliz Cloud Business Critical, 또는 Qdrant Private Cloud
• 이유: 여기서 SLA 숫자만으로 줄을 세우면 오히려 판단을 그르칩니다. 최상위 티어 기준으로는 파인콘 Enterprise 99.95%, Qdrant Standard 멀티 AZ 99.95%, Zilliz Cloud Business Critical 99.99%(멀티 리플리카)로 가용성 자체는 서로 비슷하거나 Zilliz가 더 높습니다. 실제 차별점은 계약·감사 쪽입니다. 파인콘 Enterprise는 HIPAA·감사로그·BYOC를 한 번에 제공하고 BYOC는 고객 클라우드 계정에 zero-access로 배포됩니다. Zilliz Cloud의 Business Critical은 공식 문서가 의료·금융·미션크리티컬 시스템을 대상으로 명시한 플랜이고 BYOC(99.95%)도 함께 제공되므로, 규제 요건이 있다면 반드시 후보에 넣으십시오. 데이터가 물리적으로 외부에 나갈 수 없다면 Qdrant의 Private Cloud(완전 격리 전용 배포)나 셀프호스팅이 현실적인 답입니다.

🎯 8) 사내 문서 검색·지식베이스를 빠르게 만들어야 하는 팀

• 최적의 선택: Weaviate 또는 파인콘
• 이유: 사내 문서는 제품명·사번·규정 번호처럼 정확히 일치해야 하는 키워드가 많아 순수 벡터 검색만으로는 실패합니다. Weaviate의 alpha 융합이나 파인콘의 full-text(BM25 + Lucene 문법) 인덱스처럼 하이브리드가 기본으로 제공되는 쪽이 개발 기간을 크게 줄여줍니다. 어떤 LLM을 붙일지 고민 중이라면 ChatGPT·Claude·Gemini AI 모델 비교 글이 도움이 됩니다.

6. 실전 활용 팁 & 흔한 실수

✅ 팁 1) pgvector 버전 점검을 오늘 하세요

SELECT extversion FROM pg_extension WHERE extname = 'vector';를 실행해보십시오. 0.8.2 미만이면 CVE-2026-3172에 노출되어 있습니다. HNSW 인덱스를 병렬 워커로 만들 수 있는 사용자가 다른 릴레이션의 데이터를 유출하거나 서버를 크래시시킬 수 있는 취약점입니다. 관리형 Postgres를 쓴다면 제공자가 언제 0.8.2 이상으로 올렸는지 확인하고, 당장 올릴 수 없다면 **max_parallel_maintenance_workers = 0**으로 병렬 HNSW 빌드를 막아두는 것이 임시 방어책입니다. 가능하면 최신 0.8.6까지 올리는 것이 좋습니다. 0.8.3에서 HNSW 배큐밍 중 인덱스 손상 가능성까지 수정되었기 때문입니다.

✅ 팁 2) 하이브리드 검색은 이제 선택이 아닙니다

2026년 프로덕션 RAG에서 하이브리드 검색(BM25 + 벡터)은 기본값이 되었습니다. 지식 집약 코퍼스에서 순수 벡터 검색만으로는 고유명사·코드·숫자 같은 정확 일치 쿼리를 놓치기 때문입니다. 문제는 제품별 성숙도 차이가 여기서 가장 크게 벌어진다는 점입니다.

pgvector로 하이브리드를 하려면 RRF 같은 융합 로직을 직접 짜야 합니다. 만들 수는 있지만, 이 코드는 튜닝과 유지보수가 계속 필요한 자산이 됩니다. **“하이브리드가 필수인가”**가 pgvector에 남을지 떠날지를 가르는 가장 실용적인 질문입니다.

✅ 팁 3) 임베딩 차원 수를 비용 관점에서 다시 보세요

Weaviate는 100만 차원 단위로 과금합니다. 100만 개 문서를 1536차원으로 임베딩하면 15억 3,600만 차원이지만, 384차원 모델을 쓰면 3억 8,400만 차원입니다. 검색 품질이 견딜 만하다면 차원 축소나 저차원 모델이 곧바로 4배 절감이 됩니다. Weaviate가 아니더라도 차원 수는 메모리 사용량을 통해 모든 벡터 DB의 비용에 영향을 줍니다. 여기에 Qdrant의 TurboQuant이나 Weaviate의 RQ 양자화, Milvus의 RaBitQ 같은 양자화를 얹으면 절감 폭은 더 커집니다.

✅ 팁 4) 파인콘의 하드 리밋을 설계 단계에서 반영하세요

운영에 들어간 뒤 부딪히면 아픈 제한들이 있습니다. 레코드당 메타데이터 40KB — 문서 원문을 메타데이터에 통째로 넣는 설계는 여기서 막힙니다. top_k는 일반 인덱스 기준 최대 10,000, 쿼리 결과 최대 4MB — 리랭커에 넘길 후보를 넉넉히 뽑는 파이프라인이라면 헤드룸은 충분한 편이고, 실제로는 결과 4MB 제한에 먼저 걸리는 경우가 많습니다. 다만 sparse 인덱스에서 리랭킹한다면 top_k 상한이 1,000으로 떨어집니다. 이 1,000이라는 숫자를 파인콘 전체의 한도로 오해해 dense 후보군을 불필요하게 줄이는 설계가 흔하니 주의하세요. $in/$nin은 연산자당 최대 10,000개 값 — 사용자 권한 필터를 ID 목록으로 넘기는 방식은 조직이 커지면 터집니다. 그리고 sparse 인덱스는 업서트 10/초, 쿼리 100 QPS 제한이 있어, 대량 초기 적재는 이 속도를 전제로 일정을 잡아야 합니다.

✅ 팁 5) Weaviate는 버전을 묵히면 안 됩니다

Weaviate는 최신 3개 마이너 버전(1.36/1.37/1.38)만 버그·보안 패치를 받습니다. 릴리스 주기가 대략 두 달이므로, 반년만 방치해도 지원 범위 밖으로 밀려납니다. 분기마다 업그레이드하는 일정을 팀 캘린더에 아예 박아두시는 편이 좋습니다.

✅ 팁 6) Milvus 3.0 도입은 “레이크가 있는가”로 판단하세요

3.0의 레이크 네이티브 인덱싱은 오브젝트 스토리지에 오픈 테이블 포맷 데이터가 이미 있는 조직에게만 판을 바꿉니다. 데이터가 애초에 Postgres나 애플리케이션 DB에 있다면 3.0의 핵심 가치는 발휘되지 않고, 분산 아키텍처의 운영 복잡도만 떠안게 됩니다. 또한 발표 1주일 차라 독립 벤치마크가 아직 없습니다. 스테이징에서 여러분의 데이터로 검증한 뒤 넘어가시고, 안정성이 최우선이라면 2026년 1월 20일 Zilliz Cloud에서 GA된 2.6.x 계열도 충분히 합리적인 선택입니다.

✅ 팁 7) “나중에 옮기면 되지”의 실제 비용을 미리 계산하세요

이 글의 결론은 “먼저 pgvector로 시작하라”인데, 그 조언이 성립하려면 넘어가는 단계의 비용을 알고 있어야 합니다. 좋은 소식부터: 대개 재임베딩은 필요 없습니다. 벡터는 원본 실수 배열 그대로 export/import하면 되므로 임베딩 API 비용을 다시 낼 일은 없습니다. 모델을 함께 바꾸는 경우에만 전체 재임베딩이 발생합니다.

실제로 돈과 시간이 드는 건 나머지 네 가지입니다. 첫째, 인덱스 재빌드 시간 — HNSW는 빌드가 느리고 메모리를 많이 먹기 때문에, 규모가 커질수록 이주 자체보다 “새 쪽에서 인덱스가 다 서기까지” 걸리는 시간이 일정의 주인공이 됩니다. 둘째, ID·메타데이터 스키마 매핑 — 제품마다 ID 타입 제약과 메타데이터/페이로드 모델, 필터 문법이 달라서 필터 쿼리를 사실상 다시 쓰게 됩니다. 셋째, 이중 쓰기(dual-write) 기간 — 무중단으로 넘기려면 한동안 양쪽에 동시에 쓰면서 결과를 비교해야 하고, 이 기간에는 두 시스템 비용을 모두 냅니다. 넷째, 검색 품질 회귀 검증 — 엔진이 바뀌면 같은 쿼리의 순위가 달라지므로 골든셋 평가를 다시 돌려야 합니다.

§1 표에서 파인콘의 최대 단점으로 적은 “락인”의 실체가 바로 이겁니다. 파인콘은 셀프호스팅 경로가 없어서(BYOC는 별도 계약), 떠나기로 결정한 순간 대체 인프라를 처음부터 세우고 위 네 단계를 전부 치러야 합니다. 반대로 Qdrant·Milvus·pgvector는 최소한 “같은 엔진을 우리 서버에서 계속 돌린다”는 퇴로가 있습니다. 도입 시점에 데이터를 빼내는 스크립트를 한 번 짜서 돌려보는 것만으로도, 이 비용이 감당 가능한 수준인지 미리 알 수 있습니다.

❌ 흔한 실수 1) 남의 벤치마크로 아키텍처를 결정하기

앞서 봤듯 공개 수치들은 10배씩 어긋납니다. 차원 수·필터 조건·하드웨어가 다르면 순위 자체가 뒤집힙니다. 후보를 2개로 좁힌 뒤 여러분의 데이터로 직접 측정하는 반나절이, 잘못된 선택으로 날리는 반년보다 훨씬 쌉니다.

❌ 흔한 실수 2) 셀프호스팅을 “무료”로 계산하기

Apache 2.0 라이선스는 라이선스비가 0원이라는 뜻이지 운영비가 0원이라는 뜻이 아닙니다. 백업·복구 테스트·모니터링·버전 업그레이드·장애 대응이 전부 팀 시간입니다. 인프라 담당이 없는 조직에서는 관리형 요금이 대체로 더 쌉니다.

❌ 흔한 실수 3) 인용된 가격을 검증 없이 예산에 넣기

파인콘 RU/WU 단가는 널리 인용되는 값이 공식가와 약 2배 차이 나고, Weaviate 시작가는 2025년 10월에 $25에서 $45로 바뀌었으며, pgvector “0.9”는 아예 존재하지 않습니다. 예산 문서에 넣기 전에 공식 요금 페이지를 한 번 여는 습관이 나중에 회의에서 곤란해지는 일을 막아줍니다.

7. 자주 묻는 질문 (FAQ)

Q. 벡터 데이터베이스 비교에서 가장 먼저 던져야 할 질문은 무엇인가요?

“우리가 이미 PostgreSQL을 쓰고 있는가”입니다. 쓰고 있고 벡터가 1천만 개 이하라면 pgvector가 기본값이고, 전용 벡터 DB 도입은 운영 대상과 동기화 파이프라인이라는 새 비용을 스스로 만드는 일입니다. 그다음 질문이 “관리형에 돈을 낼 것인가, 직접 운영할 것인가”, 마지막이 “하이브리드 검색이 필수인가”입니다. 이 세 질문이면 5종 중 2개로 후보가 좁혀집니다.

Q. pgvector로 프로덕션 RAG를 돌려도 괜찮나요?

규모와 요구사항에 따라 다릅니다. HNSW 인덱스를 쓰면 100만 규모에서는 전용 벡터 DB와 실용적으로 대등하다는 평가가 일반적이고, 원본 데이터와 같은 트랜잭션 안에서 관리된다는 장점은 큽니다. 다만 하이브리드 검색이 내장되어 있지 않아 tsvector와 벡터 거리를 앱 코드에서 직접 융합해야 합니다. 이 구현·유지보수 부담을 감당할 수 있는지가 판단 기준입니다.

Q. pgvector 최신 버전은 0.9인가요?

아닙니다. 0.9는 존재하지 않습니다. 2026년 8월 2일 기준 최신은 **0.8.6(2026-07-29)**입니다. 여러 기술 블로그가 0.9로 잘못 표기하고 있으니 주의하세요. 그리고 0.8.2 미만은 CVE-2026-3172에 취약하므로, 버전 확인은 정보 정확성 문제가 아니라 보안 문제입니다.

Q. 무료로 시작하려면 어디가 가장 좋나요?

용도에 따라 다릅니다. Qdrant Free는 시간 제한 없는 영구 무료로 0.5 vCPU / 1GB RAM / 4GB 디스크를 주고 일부 모델의 클라우드 추론도 무료라 프로토타입에 좋습니다. Weaviate Sandbox는 객체 10만 개 / 메모리 1GB / 디스크 10GB / 컬렉션 1개 / 테넌트 최대 3개로 하이브리드 검색을 실험하기에 적합합니다. 파인콘 Starter는 2GB 스토리지와 월 200만 WU·100만 RU에 임베딩 500만 토큰까지 포함됩니다. Zilliz Cloud도 무료로 시작할 수 있는 티어를 제공하는데, 한도 수치가 공식 요금 페이지에 노출되지 않으므로 콘솔에서 직접 확인한 뒤 비교하십시오. 인프라를 직접 굴릴 수 있다면 pgvector와 셀프호스팅 Qdrant·Milvus는 완전 무료입니다.

Q. 파인콘 가격이 비싸다는 말이 많은데, 실제로 얼마나 드나요?

공식 기준 Standard는 읽기 100만 RU당 $1618, 쓰기 100만 WU당 $44.50, 스토리지는 $0.33/GB/월이며 월 최소 사용액 $50이 붙습니다. Enterprise는 RU $2427, WU $66.75에 최소 $500/월입니다. 인터넷에 도는 “RU $8.25” 같은 수치는 공식과 다르니 예산 계산에 쓰지 마세요. 트래픽이 크지 않다면 $20/월 정액인 Builder가 비용 예측 면에서 가장 안전합니다.

Q. Milvus 3.0으로 지금 바로 넘어가야 하나요?

데이터 레이크를 이미 운영 중이라면 검토할 가치가 큽니다. Parquet·Lance·Iceberg·Vortex 테이블을 복사 없이 검색하는 레이크 네이티브 인덱싱과, read amplification을 줄이는 새 스토리지 엔진 Loon이 핵심입니다. 다만 2026년 7월 29일 릴리스로 아직 일주일 차이고 독립 벤치마크가 없습니다. 스테이징에서 검증한 뒤 옮기시고, 안정성이 우선이라면 2026년 1월 Zilliz Cloud에서 GA된 2.6.x도 충분히 좋은 선택입니다.

Q. Weaviate 가격이 예상보다 많이 나오는 이유가 뭔가요?

과금 단위가 **벡터 개수가 아니라 “100만 차원”**이기 때문입니다. 벡터 수 × 차원 수로 계산되므로 1536차원 모델을 쓰면 384차원 모델 대비 같은 문서 수에서 비용이 4배가 됩니다. 여기에 2025년 10월 요금제 개편으로 시작가가 $25에서 $45로 인상된 것도 겹칩니다. 임베딩 모델을 저차원으로 바꾸거나 양자화를 적용하는 것이 가장 직접적인 절감책입니다.

Q. 한국 원화로 결제할 수 있나요?

5종 모두 공식 KRW 가격표가 없습니다. 전부 USD로 청구되므로 환율 변동이 그대로 비용에 반영됩니다. 다른 비교 글에서 보이는 “월 O만 원” 같은 표기는 임의 환산일 뿐 공식 가격이 아니니, 예산 승인 문서에는 USD 기준으로 적고 환율 변동 여지를 따로 잡아두시는 편이 안전합니다.

Q. Qdrant Cloud의 정확한 요금은 어디서 확인하나요?

Qdrant는 공식 요금 페이지에 구체적인 단가 숫자를 노출하지 않습니다. 과금 항목이 컴퓨트(vCPU)·메모리(GB)·스토리지(GB)·백업 스토리지·유료 추론 토큰이고 시간당 계산된다는 구조만 공개되어 있습니다. 인터넷에 도는 “$0.078/GB-hour”, “월 $25부터” 같은 수치는 공식 확인이 안 되므로 그대로 믿지 마시고, 실제 예산이 필요하다면 콘솔에서 원하는 스펙으로 구성해 보거나 영업에 문의하시는 것이 정확합니다.

8. 결론: 2026년 벡터 데이터베이스 비교의 진짜 결론

2026년 8월의 벡터 DB 시장은 “누가 제일 빠른가”라는 질문에서 이미 벗어났습니다. Milvus는 데이터가 있는 곳에서 바로 검색하는 레이크 네이티브로, Qdrant는 같은 recall을 절반의 메모리로 내는 양자화로, Weaviate는 하이브리드와 멀티테넌시로, 파인콘은 운영 부담을 0으로 만드는 완전관리형으로, pgvector는 아예 새 인프라를 도입하지 않는다는 노선으로 각자 다른 문제를 풀고 있습니다. 서로를 대체하는 관계가 아니라, 조직의 상태에 따라 답이 갈리는 구조입니다.

그래서 이 벡터 데이터베이스 비교의 실질적인 결론은 이렇습니다. 먼저 pgvector로 시작할 수 있는지 따져보고, 하이브리드 검색이나 규모 때문에 안 된다는 것이 확인된 뒤에 전용 벡터 DB로 넘어가십시오. 처음부터 화려한 전용 DB를 도입한 팀 중 상당수가 결국 운영 부담과 동기화 버그로 시간을 씁니다. 반대로 하이브리드가 필수인데 pgvector를 고집하는 팀은 검색 품질에서 대가를 치릅니다. 판단 기준은 취향이 아니라 요구사항이어야 합니다.

마지막으로 오늘 안에 하실 일이 하나 있습니다. pgvector를 쓰고 계시다면 버전을 확인하세요. 0.6.0~0.8.1은 CVE-2026-3172의 영향을 받고 0.8.2에서 수정되었습니다. 이 글에서 얻어가실 게 하나뿐이라면 그건 벤치마크 표가 아니라 이 한 줄입니다.

[요약: 내 상황에 맞는 최종 추천]

이미 PostgreSQL 사용 + 벡터 1천만 개 이하
  → pgvector (단, 0.8.2 이상 필수 / 최신 0.8.6)

인프라 인력 없음 + 비용 예측 가능성이 최우선
  → 파인콘 Builder ($20/월 정액, 10GB, 500만 WU·200만 RU)

예산 0원으로 프로토타입부터
  → Qdrant Free (영구 무료, 0.5 vCPU / 1GB RAM / 4GB 디스크)

고객사별 데이터 격리가 필요한 B2B SaaS
  → Weaviate (멀티테넌시 + BM25 alpha 하이브리드 / 차원 과금 주의)

데이터 레이크(Iceberg·Parquet) 보유 대기업
  → Milvus 3.0 (레이크 네이티브, 복사 없이 검색 / 스테이징 검증 후)

메모리 비용을 줄이면서 프로덕션 RAG 품질 유지
  → Qdrant (TurboQuant: SQ 대비 메모리 1/2, 최대 8배 압축)

벡터 1천만~1억 개 · 레이크 없음 · Postgres도 아님
  → 운영 인력 있으면 Qdrant, 없으면 파인콘 Standard (최소 $50/월)

HIPAA · 감사로그 · 데이터 소재지가 계약 조건
  → 파인콘 Enterprise (최소 $500/월) / Zilliz Business Critical (99.99%)
     / Qdrant Private Cloud — SLA만 보면 셋 다 99.95% 이상

⚠️ 공통: 5종 모두 KRW 공식 가격 없음(USD 청구),
   공개 벤치마크는 조건이 제각각 — 반드시 직접 측정할 것

여러분의 데이터, 여러분의 차원 수, 여러분의 필터 조건으로 후보 2개만 직접 재보세요. 그 반나절이 이 글 전체보다 정확한 답을 줍니다. 🚀