사내 문서 검색 서비스를 만든다고 해 봅시다. 인사팀 규정과 영업팀 제안서가 있고 제품 사진도 검색되면 좋겠고 업계 뉴스는 매일 수백 건씩 들어옵니다. 벡터 DB를 골랐다면 다음 질문은 “이 데이터를 컬렉션 하나에 넣을까, 여러 개로 나눌까”입니다.

벡터 DB에서는 컬렉션을 나누는 기준이 서비스의 성능과 운영을 좌우합니다. 관계형 데이터베이스(RDB)에서 테이블을 나누는 기준과 같은 역할입니다. 벡터 차원이나 샤드 수는 컬렉션을 만들 때 한 번 정하면 나중에 바꾸기 어려운 제품이 많습니다(7·8절). 이 때문에 처음 설계할 때 따져 볼 것을 미리 알아 두는 편이 좋습니다.

2편에서는 제품을 고르는 기준을 비교했습니다. 이 글은 제품을 고른 뒤 그 안에 데이터를 어떤 모양과 단위로 담을지를 다룹니다.

이 글에서 알 수 있는 것

• 벡터 DB 레코드를 이루는 네 가지(ID·벡터·원문·메타데이터)와 RDB 테이블과의 대응
• 컬렉션을 나누는 다섯 가지 기준과, 컬렉션 대신 파티션·테넌트·필터로 나누는 방법
• 업무 문서, 텍스트와 이미지, 매일 쌓이는 뉴스 기사에서 컬렉션을 정하는 방법
• 여러 컬렉션을 함께 검색하는 방법과, 그때 벡터 공간을 맞춰야 하는 이유
• 컬렉션을 나누는 것과 컬렉션 안에서 샤드를 나누는 것의 차이

이 글의 문서 조사 기준일은 2026년 10월 7일입니다. Milvus는 v3.0.x 문서, Pinecone은 API 버전 2026-07 문서, pgvector는 README에 표시된 0.8.7을 기준으로 합니다. 예제의 컬렉션 이름과 데이터는 설명을 위해 만든 것입니다.

1. 먼저 알아 둘 용어는 무엇일까요

이 글에 자주 나오는 용어를 먼저 정리합니다. 제품마다 이름이 다른 개념은 2절의 표에서 다시 대응시킵니다.

2. 벡터 DB의 레코드는 무엇으로 이루어질까요

벡터 DB 제품은 저장 단위를 부르는 이름이 서로 다릅니다. 그래도 레코드 한 건을 열어 보면 대부분 네 가지로 이루어져 있습니다.

• ID: 레코드를 구별하는 고유 값입니다. RDB의 기본 키(primary key)에 해당합니다.
• 벡터: 원문을 임베딩한 숫자 배열입니다. 유사도 검색은 이 값으로 합니다.
• 원문: 벡터를 만든 원래 텍스트입니다. 검색 결과로 사용자에게 보여 주거나 대규모 언어 모델(LLM)에 넘길 때 씁니다.
• 메타데이터: 작성일·부서·카테고리처럼 검색 범위를 좁히는 데 쓰는 값입니다.

Chroma의 레코드는 이 네 가지 구성을 그대로 따릅니다. Chroma에서 컬렉션은 저장과 질의의 기본 단위입니다. 레코드마다 고유한 문자열 id가 필요하고 원문(documents)과 벡터(embeddings) 중 하나 또는 둘 다를 넣습니다. 메타데이터(metadatas)는 언제나 선택 사항입니다. 컬렉션마다 임베딩 함수를 지정하며 기본값은 sentence transformer 모델입니다.¹

RDB 테이블과는 어떻게 대응할까요

컬렉션을 RDB 테이블, 레코드를 행으로 보면 이해하기 쉽습니다. pgvector는 이 대응이 실제 구조 그대로입니다. pgvector는 PostgreSQL 확장이므로 별도의 컬렉션 개념 없이 일반 테이블에 vector 타입 열을 추가합니다.²

-- 테이블 = 컬렉션, 행 = 레코드
CREATE TABLE doc_chunks (
  id        bigserial PRIMARY KEY,  -- ID
  content   text,                   -- 원문
  metadata  jsonb,                  -- 메타데이터
  embedding vector(768)             -- 벡터(768차원)
);

-- 주어진 벡터와 L2 거리가 가까운 순서로 5건 조회
SELECT id, content
FROM doc_chunks
ORDER BY embedding <-> '[0.12, -0.03, ...]'
LIMIT 5;

앞 SQL의 '[0.12, -0.03, ...]'는 자리 표시입니다. 실제 질의에는 768개 값을 모두 넣습니다. <->는 pgvector의 L2 거리 연산자입니다.

Milvus는 RDB와 어떻게 대응하는지를 문서에서 직접 설명합니다. 문서는 컬렉션을 고정된 열과 가변적인 행으로 이루어진 2차원 표로 소개합니다. 행 하나를 엔티티(entity), 열 하나를 필드(field)라고 부릅니다. 기본 키 필드(primary field)의 값은 엔티티 하나를 고유하게 가리키며 Int64 또는 VARCHAR만 받습니다.³

Milvus 스키마(schema)는 기본 키 필드, 하나 이상의 벡터 필드, 선택적인 스칼라 필드(숫자·문자열 같은 일반 값)로 구성됩니다. 벡터 필드에는 dim 파라미터로 차원을 지정합니다.⁴ Milvus에는 컬렉션 위에 데이터베이스(database)라는 논리 단위도 있습니다. 한 데이터베이스에 컬렉션을 여러 개 두며 기본 데이터베이스는 삭제할 수 없습니다.⁵

제품마다 부르는 이름은 어떻게 다를까요

Qdrant에서 컬렉션은 point(payload가 붙은 벡터)를 모은 집합이며 컬렉션마다 이름이 있습니다. 검색은 이 집합을 대상으로 합니다. point의 ID로는 64비트 부호 없는 정수와 UUID를 쓸 수 있습니다.⁶ Weaviate는 모든 객체에 UUID를 부여하며 이 UUID는 모든 컬렉션에 걸쳐 고유합니다.⁷

Pinecone에서는 프로젝트 안에 인덱스가 있고 인덱스 안을 namespace로 나눕니다. 레코드는 ID와 벡터 하나(하이브리드 검색용 인덱스는 dense·sparse 두 종류), 선택적인 메타데이터로 이루어집니다.⁸ sparse 벡터는 차원 수는 매우 많지만 그 가운데 0이 아닌 값은 적은 벡터이고 dense 벡터는 대부분의 값이 0이 아닌 일반적인 벡터입니다. Elasticsearch는 인덱스의 dense_vector 필드에 벡터를 저장하고 나머지 필드에 원문과 메타데이터를 둡니다.⁹

Qdrant의 point 하나는 JSON으로 다음과 같이 생겼습니다. payload의 키와 값은 예시입니다.

{
  "id": 129,
  "vector": [0.1, 0.2, 0.3, 0.4],
  "payload": {"department": "hr", "created_at": "2026-10-01"}
}

한 컬렉션 안의 레코드는 모양이 모두 같아야 할까요

꼭 그렇지는 않습니다. Chroma는 원문만 있는 레코드, 벡터만 있는 레코드, 둘 다 있는 레코드를 한 컬렉션에 받습니다. 메타데이터도 레코드마다 있을 수도 없을 수도 있습니다.¹ Milvus는 동적 필드를 켜면 스키마에 정의하지 않은 필드를 $meta라는 예약된 JSON 필드에 키-값 쌍으로 저장합니다. 동적 필드는 enable_dynamic_field=True로 켭니다.¹⁰

다만 벡터의 차원과 거리 측정 방식은 컬렉션 안에서 같아야 합니다. Qdrant 문서는 한 컬렉션에 있는 모든 point의 벡터가 차원이 같고 하나의 거리 측정으로 비교된다고 명시합니다.¹¹ 유연한 메타데이터와 달리 벡터에는 엄격한 규칙이 적용되는 구조입니다. 이 규칙은 7절에서 여러 컬렉션을 함께 검색할 때 다시 중요해집니다.

3. 컬렉션은 어떤 단위로 만들까요

컬렉션을 도출하는 방법은 RDB 테이블을 도출하는 방법과 크게 다르지 않습니다. 비슷한 데이터의 묶음이자 비슷한 서비스를 제공하는 단위가 컬렉션 후보입니다. 그 후보를 다시 나눌지 합칠지는 다음 다섯 가지 기준으로 판단합니다.

다섯 기준은 서로 당기는 방향이 다릅니다. 생명주기와 속성은 나누는 쪽으로 기웁니다. 운영 용이성은 반대로 합치는 쪽을 가리킵니다. 다섯 기준을 함께 놓고 가장 단순한 구조를 찾는 것이 출발점입니다.

컬렉션 말고도 나누는 방법이 있습니다

데이터를 나눠야 한다고 해서 꼭 컬렉션을 새로 만들 필요는 없습니다. 대부분의 제품은 컬렉션보다 가벼운 분리 수단을 함께 제공합니다. 나누는 수준을 위에서부터 놓으면 다음과 같습니다.

공식 문서는 테넌트나 사용자마다 컬렉션을 만드는 방식을 기본값으로 권하지 않습니다.

Qdrant는 대부분의 경우 컬렉션 하나를 쓰고 payload(메타데이터)로 데이터를 나누라고 안내하며 이 방식을 멀티테넌시라고 부릅니다. 문서에 따르면 컬렉션을 여러 개 만드는 방식은 유연하지만 컬렉션이 많아지면 리소스 오버헤드로 비용이 커질 수 있습니다. 여러 컬렉션은 사용자 수가 적고 격리가 필요할 때 쓰는 방법으로 둡니다. 테넌트마다 컬렉션을 따로 만드는 방식은 가장 효율적인 경우가 드물다고도 적습니다.¹¹¹²

Qdrant에서 테넌트를 구분하는 keyword payload 인덱스에 is_tenant=true(v1.11.0+)를 주면, 같은 테넌트의 벡터를 저장소에서 가까이 모아 둡니다. 문서는 이렇게 하면 순차 읽기를 활용해 성능이 크게 좋아질 수 있다고 적습니다.¹²

Milvus는 멀티테넌시를 네 수준으로 나눠 비교합니다.¹³

같은 문서의 비교표에서 검색 성능은 Database·Collection 수준이 더 높고 파티션 계열은 중간으로 정리돼 있습니다. 역할 기반 접근 제어(RBAC, Role-Based Access Control)는 Database·Collection 수준에서만 쓸 수 있습니다. 대신 Partition·Partition key 수준에서는 테넌트를 하나씩 질의할 수도, 여러 파티션에 걸쳐 함께 질의할 수도 있어 테넌트를 가로지르는 집계에 맞습니다. 자주 쓰는 데이터와 드물게 쓰는 데이터를 나눠 다루는 hot·cold 처리는 Partition key 수준에서 아직 지원하지 않습니다.¹³ Milvus의 한도 문서에는 클러스터당 컬렉션 65,536개, 컬렉션당 파티션 1,024개가 적혀 있습니다.¹⁴

Weaviate는 네이티브 멀티테넌시를 제공합니다. 테넌트마다 별도의 샤드에 저장하며 한 테넌트의 데이터는 다른 테넌트에게 보이지 않습니다. 문서는 여러 사용자에게 서비스하는 애플리케이션에서는 멀티테넌시로 데이터가 분리되고 DB 작업도 효율적이라고 정리합니다.¹⁵ 테넌트마다 전용 벡터 인덱스를 가지며 쓰지 않는 테넌트는 비활성 상태로 두거나 S3로 내보낼 수 있습니다.⁷

Pinecone은 테넌트마다 namespace를 하나씩 두라고 안내합니다. namespace는 따로 저장되므로 테넌트 간 데이터가 물리적으로 분리됩니다. 읽기와 쓰기는 언제나 namespace 하나를 대상으로 하므로 한 테넌트의 사용량이 다른 테넌트에 영향을 주지 않습니다. 테넌트가 서비스를 떠나 데이터를 없앨 때는 해당 namespace를 지우면 됩니다. 문서에 따르면 이 작업은 가볍고 거의 즉시 끝납니다. 서버리스 인덱스당 namespace 수는 요금제에 따라 Starter 100개에서 Enterprise 1,000,000개까지입니다.¹⁶

같은 문서는 테넌트를 모두 namespace 하나에 넣고 메타데이터 필터로 나누는 방식의 비용도 짚습니다. 이 경우 필터와 관계없이 namespace 전체를 훑으므로 비용과 지연이 커진다는 취지입니다.¹⁶

컬렉션은 스키마·임베딩 모델·접근 권한까지 달라야 할 때 나누는 무거운 경계입니다. 같은 스키마에서 검색 범위만 나누면 된다면 파티션·테넌트·namespace를, 그보다 가벼운 조건이라면 메타데이터 필터를 먼저 검토합니다. 2편의 필터와 멀티테넌시 비교에 제품별 권장 방식을 표로 정리했습니다.

4. 업무가 다른 비슷한 문서는 한 컬렉션에 둘까요

인사 규정, 영업 제안서, 기술 매뉴얼은 모두 문서입니다. 같은 임베딩 모델로 벡터를 만들 수 있고 형식도 비슷해서 흔히 컬렉션 하나에 넣을 생각부터 합니다. 데이터가 많지 않다면 실제로 그 방법이 가장 단순합니다(데이터가 아주 많을 때는 이 절 마지막 소절에서 다룹니다). 다만 쓰임새가 다르면 나누는 편이 검색 정확도나 운영에 유리한 경우가 있습니다.

한 컬렉션과 메타데이터로 충분한 경우

다음 조건을 모두 만족하면 컬렉션 하나에 넣고 업무 구분은 메타데이터로 둡니다.

• 모든 문서에 같은 임베딩 모델·차원·거리 측정을 씁니다.
• 업무를 가로질러 함께 검색할 일이 있습니다. 예를 들어 전사 통합 검색입니다.
• 보관 기간과 삭제 규칙이 비슷합니다.
• 접근 권한을 메타데이터 필터나 테넌트 수준에서 나눠도 됩니다.

다음은 업무 구분을 메타데이터로 담은 레코드 예시입니다(특정 제품의 API 형식은 아닙니다).

{
  "id": "hr-policy-0012#3",
  "document": "연차휴가는 입사일을 기준으로 산정합니다. ...",
  "metadata": {
    "business": "hr",
    "doc_type": "policy",
    "updated_at": "2026-09-01"
  }
}

인사팀 화면에서는 business = "hr" 조건을 걸어 검색하고 통합 검색에서는 조건 없이 검색합니다. 업무가 하나 늘어나도 컬렉션을 새로 만들 필요 없이 business 값만 추가하면 됩니다. 업무별로 검색 범위를 물리적으로 나누고 싶다면 3절의 파티션이나 테넌트를 같은 방식으로 씁니다.

컬렉션을 나누는 편이 나은 경우

반대로 다음과 같은 차이가 있으면 컬렉션을 나누는 쪽을 검토합니다.

데이터가 아주 많으면 어떻게 할까요

대용량 데이터를 컬렉션 하나에 두면 구조는 단순합니다. 대신 한 컬렉션이 커질수록 색인·검색·갱신의 부담이 한곳에 몰리고 컬렉션 단위로 하는 백업과 복구도 오래 걸립니다. 업무 유형이나 기간을 기준으로 컬렉션을 나누면 이 부담이 컬렉션마다 나뉘어 성능과 관리에 유리할 수 있습니다.

다만 규모 문제만 있다면 컬렉션을 나누기 전에 샤드부터 검토합니다. 샤드는 컬렉션 하나를 여러 노드에 나눠 담는 기능이므로 애플리케이션이 다루는 컬렉션은 그대로 두고 용량을 늘릴 수 있습니다(8절). 컬렉션을 여러 개로 나누면 생성·삭제와 검색 대상 관리를 자동화해야 하므로 그에 맞는 도구와 절차가 함께 필요해집니다. 컬렉션을 가로지르는 검색이 필요해지면 7절의 제약도 따라옵니다.

5. 텍스트와 이미지를 한 컬렉션에 담을 수 있을까요

멀티모달(multimodal)은 텍스트·이미지·오디오·비디오처럼 종류가 다른 데이터를 함께 이해하고 분석하는 방식입니다. “해변에서 서핑하는 사람”이라는 텍스트로 사진이나 영상을 찾는 검색이 대표적입니다. 영상에 설명을 붙이거나 이미지와 음성을 함께 넣어 질문하는 서비스도 같은 범주에 듭니다.

종류가 다른 데이터도 한 컬렉션에서 관리할 수 있습니다. 방법은 크게 두 가지입니다.

공유 임베딩 공간을 쓰는 방법

첫째는 텍스트와 이미지를 같은 벡터 공간에 놓는 모델을 쓰는 방법입니다. 대표적인 예가 CLIP(Contrastive Language-Image Pre-training)입니다. CLIP은 이미지 인코더와 텍스트 인코더를 함께 학습합니다. 학습 배치 안에서 실제로 짝인 이미지·캡션 N쌍은 임베딩의 코사인 유사도를 높이고 짝이 아닌 N²−N개 조합은 유사도를 낮추도록 학습합니다. 그 결과 이미지와 텍스트가 하나의 멀티모달 임베딩 공간을 공유합니다.¹⁷

공간을 공유하므로 사진의 벡터와 “해변에서 서핑하는 사람”이라는 문장의 벡터를 바로 비교할 수 있습니다. 컬렉션 하나, 벡터 필드 하나에 이미지와 텍스트를 함께 넣고 텍스트 질의로 이미지를 찾을 수 있습니다. CLIP 논문에 따르면 사전 학습 뒤 자연어로 시각 개념을 가리킬 수 있어 별도 학습 없이 다른 작업에 옮겨 쓸 수 있습니다.¹⁷

레코드 하나에 벡터를 여러 개 두는 방법

둘째는 모달리티마다 다른 모델로 벡터를 만들고 레코드 하나에 이름 붙인 벡터를 여러 개 두는 방법입니다.

Qdrant는 named vector로 point 하나에 크기와 종류가 다른 벡터 여러 개를 둡니다. 이름마다 다른 임베딩 모델·차원·거리 측정을 쓸 수 있고 dense·sparse·multivector(같은 크기의 벡터 여러 개를 한 묶음으로 저장하는 형식)를 섞을 수도 있습니다.¹⁸ 벡터를 넣을 때는 이름별로 값을 줍니다.⁶

{
  "id": 129,
  "vector": {
    "image": [0.9, 0.1, 0.1, 0.2],
    "text": [0.4, 0.8, 0.0]
  },
  "payload": {"title": "해변 서핑 사진"}
}

이 예시에서 image 벡터는 4차원, text 벡터는 3차원으로 차원이 서로 다릅니다. 이름이 다른 벡터끼리는 차원이 달라도 되지만 같은 이름의 벡터는 컬렉션 안에서 차원이 같아야 합니다.

Milvus는 한 컬렉션에 벡터 필드를 여러 개 두고 여러 필드를 함께 검색하는 하이브리드 검색(hybrid search)을 제공합니다. 텍스트 설명과 이미지 임베딩을 함께 쓰는 멀티모달 검색이 문서의 용례입니다. 필드별 결과는 RRF Ranker(순위를 기준으로 결합)나 Weighted Ranker(필드별 점수에 가중치를 주어 결합)로 합칩니다.¹⁹

Weaviate도 컬렉션에 named vector를 여러 개 둘 수 있습니다. 벡터 공간마다 인덱스·압축·vectorizer(데이터를 벡터로 바꾸는 모듈)를 따로 설정하며 v1.31부터는 기존 컬렉션에 새 named vector를 추가할 수 있습니다. 이미 만든 named vector의 설정은 바꿀 수 없습니다.⁷²⁰

어느 쪽을 고를까요

복합 정보를 벡터 하나로 표현하면 검색 한 번으로 끝나고 결과를 합칠 필요가 없습니다. 벡터를 여러 개 두면 저장할 값과 계산이 늘어납니다. 어느 쪽 검색 품질이 나은지는 데이터와 질의에 따라 다르므로 대표 질의를 정해 두 구성을 직접 비교해 보고 정합니다.

6. 매일 쌓이는 뉴스 기사는 어떻게 나눌까요

이번에는 뉴스 기사를 저장하는 경우를 생각해 봅시다. 데이터와 사용 방식에는 다음과 같은 특징이 있습니다.

• 데이터 특성: 기사가 매일 생기고 날짜별 양이 많습니다. 주제·카테고리·작성자 같은 속성이 다양합니다.
• 접근 패턴: 최신 기사를 자주 검색하고 오래된 기사는 덜 검색합니다. 특정 주제나 카테고리로 좁혀 검색하는 일이 많습니다.

이 특징을 바탕으로 세 가지 설계안을 세울 수 있습니다.

세 안 모두 “컬렉션 이름에 조건을 넣는” 방식입니다. 3절의 공식 권고를 따르면 넷째 안도 있습니다. 컬렉션은 news 하나로 두고 날짜와 주제를 메타데이터나 파티션 키로 담는 방식입니다. 주제별로 데이터를 물리적으로 모으고 싶다면 Milvus의 partition key나 Qdrant의 is_tenant를 씁니다. 이때 오래된 기사는 바로 다음 소절에서 다루는 만료·삭제 기능으로 정리합니다.

시간 순으로 쌓이는 데이터에는 어떤 기능이 있을까요

날짜별로 컬렉션을 직접 만들고 지우는 작업을 대신해 주는 기능이 제품마다 있습니다.

Elasticsearch의 data stream은 여러 인덱스 위에 놓인 추상 계층으로, append-only(추가만 하는) 시계열 데이터를 저장하도록 최적화돼 있습니다. 실제 데이터는 자동으로 만들어지는 숨은 백킹 인덱스(backing index)에 들어갑니다. 모든 문서에는 @timestamp 필드가 있어야 합니다.²¹

rollover는 새 백킹 인덱스를 만들어 data stream의 새 쓰기 인덱스로 지정합니다. 백킹 인덱스 이름은 .ds-<data-stream>-<yyyy.MM.dd>-<generation> 형식입니다.²¹ 인덱스 하나에 계속 쓰면 성능과 리소스 사용에 나쁠 수 있으므로, 샤드 크기(예: 50GB), 인덱스의 나이(예: 7일), 샤드당 문서 수 같은 조건으로 rollover합니다.²²

ILM(Index Lifecycle Management, 인덱스 생명주기 관리)은 오래된 백킹 인덱스를 더 저렴한 하드웨어로 옮기고 필요 없는 인덱스를 삭제합니다. 인덱스는 Hot(활발히 갱신·조회) 단계에서 Delete(더 이상 필요 없어 삭제 가능) 단계까지 차례로 이동합니다. 다음 단계로 넘어가려면 현재 단계의 작업이 모두 끝나고 인덱스가 다음 단계의 최소 나이를 넘어야 합니다.²³ 날짜별 컬렉션 이름을 직접 짓는 대신 data stream이 날짜가 붙은 인덱스를 만들고 정리하는 셈입니다.

data stream은 로그·이벤트·메트릭처럼 계속 생성되고 갱신·삭제보다 새 문서 색인이 대부분인 데이터에 맞습니다.²¹ 기사 수정이 잦다면 data stream이 맞는 데이터인지 함께 따져 봅니다. 별칭(alias)은 인덱스나 data stream 하나 이상을 가리키는 이름이며 대부분의 Elasticsearch API가 인덱스 이름 자리에 alias를 받습니다. 여러 인덱스를 한 이름으로 검색하고 is_write_index로 쓰기 대상을 정할 수 있습니다.²⁴

Milvus의 컬렉션 TTL(Time-to-Live)은 엔티티를 자동으로 만료시킵니다. 만료된 엔티티는 질의·검색 결과에서 즉시 빠지고 다음 compaction(작은 데이터 조각을 합치고 삭제된 데이터를 정리하는 백그라운드 작업) 주기에 저장소에서 물리적으로 삭제됩니다. Milvus 문서는 이 물리 삭제가 보통 24시간 안에 이뤄진다고 적습니다. TTL은 컬렉션 속성 collection.ttl.seconds에 초 단위 정수로 지정하며 기존 컬렉션에는 alter_collection_properties()로 설정합니다.²⁵

Weaviate도 컬렉션 수준의 TTL 설정으로 일정 기간이 지난 객체를 자동으로 삭제할 수 있습니다. 만료된 객체는 백그라운드 프로세스가 주기적으로 지웁니다. 조건으로 지울 때는 컬렉션과 where 필터를 지정하며 한 번에 지울 수 있는 객체 수에는 설정 가능한 상한(QUERY_MAXIMUM_RESULTS, 기본 10,000)이 있습니다.²⁶

Qdrant는 ID 대신 필터로 삭제할 point를 지정할 수 있습니다.⁶ 아래는 published_month payload가 2024-05인 기사를 지우는 요청입니다. 컬렉션 이름과 payload 키는 예시입니다.

POST /collections/news/points/delete
{
  "filter": {
    "must": [
      { "key": "published_month", "match": { "value": "2024-05" } }
    ]
  }
}

이 요청은 조건에 맞는 point를 모두 지웁니다. 운영 컬렉션에서는 같은 filter로 대상 point를 먼저 조회해 확인한 뒤 실행합니다.

Chroma는 id나 where 필터로 컬렉션의 항목을 삭제하며 이 작업은 되돌릴 수 없습니다.²⁷ Pinecone은 ID(요청당 최대 1,000개), 메타데이터 필터, namespace 단위로 레코드를 삭제합니다.²⁸

설계 단계에서 실제 질의로 시험해 봅니다

어느 안이 나은지는 데이터 특성, 접근 패턴, 성능 요구, 운영 편의를 함께 봐야 정할 수 있습니다. 같은 뉴스 데이터라도 서비스가 최신 속보 검색 위주인지, 주제별 아카이브 검색 위주인지에 따라 답이 달라집니다. 분석·설계 단계에서 후보 구성을 작게 만들어 먼저 시험해 보기를 권합니다.

시험할 때는 다음을 확인합니다.

1. 대표 질의를 정합니다. 최신 기사 검색, 특정 주제 검색, 기간과 주제를 함께 건 검색처럼 실제 화면에서 나올 질의를 고릅니다.
2. 후보 구성마다 같은 질의를 실행합니다. 검색 결과의 품질과 응답 시간을 함께 기록합니다.
3. 정리 작업을 실제로 해 봅니다. 한 달 치 기사를 지우거나 옮기는 데 드는 시간과, 그동안 검색에 주는 영향을 봅니다.
4. 1년 뒤를 계산합니다. 컬렉션 수, 컬렉션당 데이터 양, 자동화해야 할 작업을 적어 봅니다.

7. 여러 컬렉션을 한 번에 검색할 수 있을까요

날짜별이나 주제별로 컬렉션을 나눴다면 여러 컬렉션에 걸쳐 유사도 검색을 해야 할 때가 생깁니다. 여러 컬렉션을 함께 검색하는 기능은 제품마다 지원 방식이 다릅니다.

Elasticsearch는 URL 경로에 인덱스를 나열합니다

Elasticsearch는 검색 API의 요청 경로에 인덱스 이름을 쉼표로 나열해 여러 인덱스를 한 번에 검색합니다. my-index-* 같은 와일드카드와 alias도 쓸 수 있습니다. 경로에서 인덱스를 생략하거나 *·_all을 쓰면 모든 data stream과 인덱스를 검색합니다.²⁹³⁰ 특정 인덱스의 결과에 가중치를 주려면 indices_boost 파라미터를 씁니다.²⁹

아래는 두 인덱스에서 게시된 문서만 골라 질의 벡터와의 코사인 유사도로 점수를 매기는 예입니다. 인덱스 이름과 필드 이름, 벡터 값은 예시입니다.

GET /collection1,collection2/_search
{
  "query": {
    "script_score": {
      "query": {
        "bool": {
          "filter": { "term": { "status": "published" } }
        }
      },
      "script": {
        "source": "cosineSimilarity(params.query_vector, 'my_vector_field') + 1.0",
        "params": { "query_vector": [0.1, 0.2, 0.3] }
      }
    }
  }
}

검색 대상 인덱스는 요청 본문이 아니라 첫 줄의 경로에 적습니다. 본문의 바깥 query는 점수를 매길 문서를 고르고 script는 고른 문서마다 점수를 계산합니다.

cosineSimilarity(...) 뒤에 + 1.0을 붙이는 이유는 점수가 음수가 될 수 없기 때문입니다. Elasticsearch 문서는 script_score 질의의 최종 점수가 음수일 수 없으며 검색 최적화를 위해 Lucene이 점수를 양수나 0으로 요구한다고 설명합니다.³¹ 코사인 유사도는 -1에서 1 사이의 값이므로 1.0을 더하면 0에서 2 사이로 옮겨집니다. 순위는 그대로 유지됩니다.

이 방식은 조건에 맞는 문서를 모두 하나씩 비교합니다. Elasticsearch 문서에 따르면 벡터 함수를 계산할 때 대상 문서를 모두 선형으로 훑으므로 질의 시간이 대상 문서 수에 비례해 늘어납니다.³¹ 이런 정확한(brute-force) kNN(k-최근접 이웃, 질의 벡터와 가장 가까운 벡터 k개를 찾는 검색) 검색은 작은 데이터셋이나 필터로 미리 좁힌 집합에 맞습니다. Elasticsearch는 지연 시간과 규모가 중요한 대부분의 운영 환경에 knn 섹션을 쓰는 근사(approximate) kNN 검색을 권장합니다.³² 근사 kNN은 인덱스로 후보를 좁혀 정확도를 조금 양보하는 대신 빠르게 찾는 방식입니다.

다른 제품은 검색 요청이 컬렉션 하나를 받습니다

Milvus의 검색 요청은 컬렉션 이름 하나와 파티션 이름 목록을 받습니다. 검색 요청에 파티션 이름을 넣어 범위를 좁힐 수 있으며 검색에 참여하는 파티션 수를 줄이면 성능이 좋아집니다.³³ 3절에서 본 것처럼 Partition·Partition key 수준으로 나눈 데이터는 여러 파티션에 걸쳐 함께 질의할 수 있습니다.¹³

Qdrant는 lookup_from 파라미터로 다른 컬렉션에 있는 point의 벡터를 질의 벡터로 가져올 수 있습니다.³⁴ 이 기능은 질의에 쓸 벡터를 빌려 오는 것이며 여러 컬렉션을 한 번에 검색하는 기능은 아닙니다. Pinecone의 읽기와 쓰기는 언제나 namespace 하나를 대상으로 합니다.¹⁶ Weaviate는 컬렉션마다 고유한 벡터 공간을 가지므로 같은 객체라도 컬렉션마다 다른 임베딩을 가질 수 있습니다.⁷

함께 검색할 일이 잦은 데이터라면 처음부터 한 컬렉션 안에서 파티션·테넌트·메타데이터로 나누는 편이 낫습니다. 이렇게 하면 앞에서 본 제품별 검색 범위 제약을 피할 수 있습니다. 컬렉션을 나누는 결정은 “이 데이터를 함께 검색할 일이 있는가”를 먼저 물은 뒤에 내립니다.

벡터 공간이 일관돼야 합니다

여러 컬렉션을 함께 검색할 수 있더라도 점수를 서로 비교하려면 벡터 공간의 일관성(consistent vector space)이 필요합니다. 서로 다른 항목을 벡터로 바꿀 때 차원 수를 같게 하고 의미 해석도 같게 맞춰야 한다는 뜻입니다. 같은 모델로, 같은 방식으로 벡터화해야 두 벡터의 거리가 의미를 가집니다.

차원은 모델 구조가 정합니다. BERT 논문에서 BERT-base는 층 12개, 은닉 크기(hidden size) 768, 어텐션 헤드 12개, 파라미터 1억 1,000만 개이고 BERT-large는 은닉 크기가 1024입니다.³⁵ Hugging Face의 bert-base-uncased 설정 파일에도 "hidden_size": 768이 적혀 있습니다.³⁵ 따라서 BERT-base로 만든 임베딩은 768차원이고 컬렉션의 벡터 필드도 768차원으로 맞춰야 합니다.

차원은 컬렉션을 만들 때 정해집니다

대부분의 제품은 컬렉션이나 벡터 필드를 정의할 때 차원을 고정합니다.

• Qdrant: 같은 컬렉션 안의 모든 벡터는 같은 차원을 가지며 컬렉션 설정에서 벡터 크기가 고정됩니다.¹¹¹⁸
• Milvus: 벡터 필드의 dim으로 차원을 정합니다.⁴ 컬렉션을 만든 뒤 바꿀 수 있는 필드 속성은 VarChar의 max_length, Array의 max_capacity, mmap.enabled이며 기본 키 필드는 생성 후 바꿀 수 없습니다.³⁶
• pgvector: vector(768)처럼 열 타입에 차원을 씁니다. 차원 없는 vector 열도 만들 수 있지만 인덱스는 차원이 같은 행에만 만들 수 있습니다(표현식·부분 인덱스 사용). vector 타입은 16,000차원까지 저장하고 HNSW·IVFFlat 인덱스는 2,000차원까지 지원합니다.²
• Elasticsearch: dense_vector 필드에 dims를 지정하지 않으면 처음 추가한 벡터의 길이로 정해집니다.⁹ 기존 필드의 타입은 바꿀 수 없으며 원하는 매핑으로 새 인덱스를 만들어 데이터를 재색인(reindex)해야 합니다.³⁷
• Pinecone: 인덱스를 만들 때 차원과 거리 측정을 지정하며 차원은 임베딩 모델의 출력에 맞춥니다. 예를 들어 multilingual-e5-large는 1024차원입니다.³⁸

임베딩 모델을 바꾸면 다시 색인합니다

벡터 값은 그 벡터를 만든 모델의 공간 안에서 의미를 가집니다. CLIP이 텍스트와 이미지를 한 공간에 놓기 위해 두 인코더를 함께 학습한 것도 이 때문입니다(5절). 따로 학습한 모델이 만든 벡터는 차원이 우연히 같더라도 같은 공간에 있다고 볼 수 없습니다. 임베딩 모델을 바꾸면 기존 데이터를 새 모델로 다시 임베딩해야 합니다.

제품 문서도 이 작업을 새 컬렉션을 만드는 방식으로 안내합니다. Weaviate 문서에는 vectorizer를 바꿀 수 없으며 새 컬렉션을 만들어 데이터를 옮기라고 나와 있습니다. distance나 efConstruction 같은 변경 불가 설정도 같은 방법으로 바꿉니다.²⁰ Elasticsearch에서는 앞 소절(차원은 컬렉션을 만들 때 정해집니다)에서 설명한 재색인 절차를 따릅니다.³⁷ alias를 쓰면 새 인덱스로 검색 대상을 바꾸는 작업을 중단 없이 할 수 있습니다.²⁴

거리 측정과 정규화도 맞춥니다

같은 모델로 만든 벡터라도 거리 측정이 다르면 점수의 척도가 달라집니다. 벡터를 단위 길이로 맞추는 정규화(normalization)는 코사인 유사도와 내적의 관계를 바꿉니다.

• Qdrant: 코사인 거리를 쓰면 벡터를 컬렉션에 넣을 때 한 번 정규화하고 비교할 때는 내적으로 계산합니다. 문서에 따르면 내적은 SIMD(한 명령으로 여러 값을 동시에 계산하는 CPU 기능) 덕분에 매우 빠른 연산입니다.³⁴
• Milvus: 실수 벡터에 L2·IP(내적)·COSINE을 지원합니다. 정규화한 임베딩에 IP를 쓰면 코사인 유사도를 계산한 것과 같습니다.³⁹
• Elasticsearch: dot_product는 float 벡터일 때 문서와 질의 벡터가 모두 단위 길이여야 합니다. cosine은 색인할 때 벡터를 자동으로 단위 길이로 정규화합니다. max_inner_product는 정규화를 요구하지 않습니다.⁹
• pgvector: <->는 L2 거리, <#>는 내적, <=>는 코사인 거리입니다. PostgreSQL 인덱스 스캔이 오름차순만 지원하므로 <#>는 내적에 음수를 붙여 돌려줍니다. 벡터가 길이 1로 정규화돼 있다면 내적을 쓰는 것이 성능상 가장 좋습니다.²
• Pinecone: euclidean·cosine·dotproduct 중에서 임베딩 모델을 학습할 때 쓴 거리 측정을 고르라고 안내합니다.³⁸

8. 컬렉션을 나누는 것과 샤드를 나누는 것은 무엇이 다를까요

컬렉션을 날짜별로 나누고 그 안을 다시 주제별로 나누는 그림을 그리다 보면 컬렉션 분리와 샤드 분할을 같은 도구로 생각하기 쉽습니다. 두 가지는 목적이 다릅니다.

Milvus에서 샤드는 컬렉션의 수평 조각이며 샤드마다 데이터 입력 채널이 하나씩 대응합니다. 기본값은 1개이고 컬렉션을 만들 때 지정합니다. 파라미터 이름은 SDK마다 달라 Python은 num_shards, Node.js는 shards_num, Java는 numShards입니다. 문서는 엔티티 2억 개마다 샤드 하나를 두는 것이 일반적이고 stream node가 여러 대라면 샤드를 여러 개 쓰라고 권합니다.⁴⁰ 컬렉션당 샤드는 최대 16개입니다.¹⁴

Qdrant는 수평 확장을 위해 컬렉션의 point를 여러 샤드에 분산합니다. shard_number를 지정하지 않으면 컬렉션을 만들 때의 클러스터 노드 수로 정해집니다. Qdrant Cloud에서는 리샤딩으로 기존 컬렉션의 샤드 수를 바꿀 수 있고 셀프 호스팅에서는 컬렉션을 다시 만들어야 합니다.⁴¹

Elasticsearch의 index.number_of_shards는 인덱스의 primary 샤드 수입니다. 기본값은 1이며 인덱스를 만들 때만 설정할 수 있습니다. 클러스터를 불안정하게 만드는 실수를 막기 위해 인덱스당 1,024개로 제한합니다. 복제본 수 index.number_of_replicas는 운영 중에 바꿀 수 있는 동적 설정이며 기본값은 1입니다.⁴²

주제별로 데이터를 모으고 싶다면

“날짜별 컬렉션 안에 스포츠 기사는 샤드 1, 경제 기사는 샤드 2”처럼 샤드를 주제에 맞춰 나누고 싶을 수 있습니다. 하지만 샤드 수 설정은 데이터를 어떤 값으로 모을지를 정하는 기능이 아닙니다. 특정 값으로 데이터를 물리적으로 모으는 기능은 따로 있습니다.

• Milvus partition key: 파티션 키 값에 따라 데이터를 물리적으로 분리된 파티션에 자동으로 나눠 넣습니다.¹³
• Qdrant is_tenant: 같은 테넌트 값을 가진 벡터를 저장소에서 가까이 모읍니다.¹²
• Qdrant user-defined sharding: 테넌트별로 샤드를 지정하는 방식입니다. 작은 테넌트는 공유 샤드에 두고 커지면 전용 샤드로 옮기는 tiered multitenancy도 안내합니다.¹²

뉴스 예제라면 주제는 partition key나 테넌트 값으로 나누고 샤드 수는 전체 데이터 양과 노드 수에 맞춰 따로 정하는 구성이 각 기능의 목적에 맞습니다.

정리

벡터 DB의 레코드는 ID·벡터·원문·메타데이터로 이루어지고 컬렉션은 RDB의 테이블에 해당합니다. 컬렉션을 나누는 기준도 RDB와 비슷하게 데이터의 크기, 접근 패턴, 생명주기, 속성, 운영 용이성입니다. 다만 공식 문서는 컬렉션을 늘리기보다 파티션·테넌트·namespace·메타데이터 필터로 나누는 방법을 먼저 안내합니다. 컬렉션은 스키마나 임베딩 모델, 권한이 다를 때 나누는 무거운 경계로 두는 편이 좋습니다.

자기 서비스에 적용할 때는 아래 질문을 차례로 확인해 봅니다.

어느 구성이 나은지는 데이터를 저장하고 쓰는 방식에 따라 달라집니다. 후보 구성을 작게 만들어 실제 질의로 결과 품질, 응답 시간, 정리 작업을 비교해 봅니다.

참고 자료

직접 측정해 보니 실제로 이런 일이 일어났습니다. 같은 Aurora MySQL 클러스터에 연결한 애플리케이션들이 같은 페일오버(failover)를 겪었습니다. 어떤 구성은 약 2초 만에 쓰기가 다시 성공했고 어떤 구성은 약 30분이 걸렸습니다. 오래 멈춘 구성은 읽기 인스턴스(reader)로 강등된 옛 writer에 다시 연결해 그 연결을 계속 사용하고 있었습니다.¹

제목의 “1초”가 무엇을 잰 값인지부터 구분해야 합니다. 이 기록에서 1초 미만이었던 것은 페일오버 명령이 반환되기까지의 시간이었습니다. DB 내부 전환이나 서비스 복구가 1초 안에 끝났다는 뜻은 아닙니다. 이 글에서 애플리케이션의 복구는 새 writer가 생긴 뒤 애플리케이션이 그 writer에서 실제 쓰기에 다시 성공하는 것입니다.

이 글은 두 가지 질문에 답합니다. 페일오버가 끝났는데 애플리케이션은 왜 쓰지 못할까요? 운영 중인 서비스에서는 무엇을 확인해야 할까요?

이 글에서 알 수 있는 것(수동 페일오버 S1 기준)

• AWS Advanced JDBC Wrapper(기존 드라이버를 감싸 새 writer를 직접 찾는 AWS 드라이버, 이하 Wrapper)를 쓴 구성은 약 2초 만에 새 writer에서 쓰기에 다시 성공했습니다.
• DNS·타임아웃을 조정한 일반 드라이버는 약 10초 만에 새 writer로 돌아왔습니다.
• 기본값 일반 드라이버는 옛 writer에 남아 길게 관찰한 반복에서 약 30분 뒤에야 쓰기가 복구됐습니다. 커넥션 풀은 그 연결을 고장으로 보지 않았습니다.

JDBC URL에 따라 페일오버 복구 시간이 달라진다는 사례를 보고 드라이버·DNS·커넥션 풀(connection pool) 설정을 바꿔 가며 직접 측정했습니다.

가벼운 JDBC 부하를 걸고 수동 페일오버 10회(S1), reader 삭제 2회(S2), Blue/Green 전환(S3)을 관찰했습니다. Blue/Green 전환은 DB 사용자(probe·admin)별로 1회씩입니다. 반복별 요약 자료는 11절에 CSV로 공개합니다.

이 실측 결과로 참고 사례의 복구 시간이나 운영 환경의 문제를 설명하지는 않습니다. 장기 트랜잭션, 네트워크 단절, 높은 동시성, ORM·Spring Boot 설정 바인딩, RDS Proxy는 측정 범위에 없습니다. reader 삭제는 2회, Blue/Green은 사용자별 1회뿐이어서 그 결과는 복구 시간을 일반화할 근거가 되지 않습니다.

이 글의 측정일과 문서 조사 기준일은 2026년 9월 28일입니다.

1. 먼저 알아 둘 개념은 무엇일까요

이 글은 DB 서버 내부보다 애플리케이션과 DB 사이의 연결 경로를 따라갑니다. 이 경로에 나오는 용어부터 정리합니다.

Aurora 클러스터에는 쓰기를 받는 writer와 읽기만 받는 reader가 있습니다. 애플리케이션은 보통 인스턴스 주소를 직접 쓰지 않고 클러스터가 제공하는 DNS 이름(endpoint)으로 연결합니다. 페일오버가 일어나면 이 이름이 가리키는 인스턴스가 바뀝니다.

비교한 구성은 모두 19개입니다. 구성 이름은 접두어와 번호로 이뤄집니다.

시나리오 이름도 세 가지입니다.

• S1: 수동 페일오버를 10회 반복했습니다. 이 글의 중심 결과입니다.
• S2: reader를 삭제하는 시험을 2회 했습니다. 결과는 9절 끝에 있습니다.
• S3: Blue/Green 전환을 사용자별로 1회씩 관찰했습니다.

2. 페일오버가 끝났다는 시간은 무엇을 뜻할까요

“페일오버에 걸린 시간”은 무엇을 쟀는지에 따라 값이 다릅니다. 시작점과 끝점이 서로 다르기 때문입니다.

실험에서는 aws rds failover-db-cluster 명령으로 페일오버를 요청했습니다. 명령은 0.4~0.5초 만에 반환됐고 RDS의 페일오버 시작·완료 이벤트는 이와 별도로 기록됐습니다.

S1 페일오버에서는 명령이 반환된 직후를 사건 종료 시각으로 기록했습니다. 공개 자료의 CLI 반환 시간은 CLI를 호출한 시각과 이 종료 시각의 차이입니다. 이 값을 “DB 페일오버가 0.5초에 끝났다”고 읽으면 안 됩니다. RDS 이벤트 간격도 DB의 모든 읽기·쓰기가 멈춘 시간과 같다고 볼 수 없습니다.¹⁰

표의 네 값은 시작점과 종료 조건이 서로 다릅니다. 그래서 RDS 이벤트가 약 9초 간격으로 남았는데 Wrapper의 쓰기 공백이 약 2초였다고 해도 모순이 아닙니다. 반대로 RDS의 완료 이벤트가 남았다는 사실만으로는 애플리케이션이 복구됐는지 가리지 못합니다.

3. 같은 페일오버를 어떻게 관찰했을까요

구성마다 결과를 공정하게 비교하려면 모든 구성이 같은 사건을 겪어야 합니다. 그래서 비교 구성 19개를 각각 별도 JVM으로 동시에 실행하고 그 상태에서 페일오버를 10회 반복했습니다.¹

이 글에서는 측정 JVM을 실행한 이 EC2를 runner라고 부릅니다.

쓰기 루프는 풀에서 연결을 빌린 뒤, 그 연결로 응답한 노드의 정보를 조회하고 INSERT를 실행했습니다. 읽기 루프는 다음 쿼리로 응답한 노드와 연결 상태를 남겼습니다.

-- 응답한 인스턴스, 물리 연결, Aurora의 읽기 전용 상태를 함께 기록합니다.
SELECT @@aurora_server_id,
       @@hostname,
       CONNECTION_ID(),
       @@innodb_read_only;

결과를 읽으려면 용어 두 개가 필요합니다.

• 쓰기 공백: 성공한 쓰기와 다음 성공한 쓰기 사이의 간격 가운데 가장 긴 값입니다. 사건 직전의 마지막 성공부터 관찰 종료까지를 봅니다. 중간에 성공 한 건이 끼면 장애 구간이 나뉠 수 있습니다.¹¹
• 미복구: 관찰이 끝날 때까지 쓰기가 한 번도 다시 성공하지 않은 반복입니다.

이 두 값을 해석할 때의 주의점(정상 상태의 간격, 미복구 값의 의미, 부하의 한계)은 11절에 모았습니다.

4. 같은 DB에서 쓰기 복구는 얼마나 갈렸을까요

결론부터 말하면 같은 DB 사건인데도 쓰기가 다시 성공하는 시점이 구성마다 크게 달랐습니다. 아래 표는 기본값 구성과 튜닝 구성(DNS·타임아웃·커넥션 풀을 조정한 구성)을 비교한 결과입니다.

표의 수치는 복구된 반복의 중앙값(최솟값~최댓값)이고 단위는 초입니다. 미복구로 표시한 칸을 뺀 나머지 칸은 각각 10회 결과입니다. 미복구 칸에 함께 적은 2,100초 관찰 값은 2회의 최솟값~최댓값입니다.¹¹

표 위쪽 세 줄의 기본값 구성은 360초 관찰에서 8회 모두 복구되지 않았습니다. 관찰을 2,100초로 늘린 나머지 두 반복에서는 모두 복구됐습니다. 세 구성의 장기 관찰 결과 6건은 1,761.7~1,803.2초, 약 29~30분이었습니다. 짧게 관찰한 24건의 미복구 결과는 이 범위나 중앙값에 넣지 않았습니다. 관찰 길이별 값과 나머지 7개 구성의 결과는 11절에 있습니다.

같은 세 드라이버의 튜닝 구성은 중앙값이 약 10초였습니다. Wrapper를 쓴 구성은 기본값에서도 약 2초였습니다.

여기서 말하는 튜닝에서는 maxLifetime 외에 다른 값도 함께 바꿨습니다. 튜닝 구성에 공통으로 적용한 값은 다음과 같습니다.

• JVM DNS TTL 5초
• 드라이버 connectTimeout 3초·socketTimeout 10초
• HikariCP connectionTimeout 5초·validationTimeout 2초·maxLifetime 50초·keepaliveTime 30초·최대 풀 크기 4

기본값 구성의 최대 풀 크기는 10이었습니다.

드라이버별 추가 설정은 공개 자료에 있습니다.¹²

여러 값을 한꺼번에 바꿨으므로 이 표만으로 어느 설정 하나가 차이를 만들었다고 단정할 수는 없습니다. 다만 같은 DB 사건을 겪어도 클라이언트 구성에 따라 쓰기가 다시 성공하는 시점이 크게 달랐다는 사실은 확인할 수 있습니다.

5. 새 writer가 생겼는데 왜 옛 writer에 연결될까요

페일오버 뒤의 여러 단계가 동시에 끝나지 않기 때문입니다. 그 틈에 새 연결이 옛 writer의 주소로 향할 수 있습니다.

cluster endpoint는 현재 writer를 가리키는 DNS 이름입니다. 페일오버로 writer가 바뀌면 이 이름이 가리키는 대상도 바뀝니다. AWS 문서도 커넥션 풀을 사용할 때는 캐시된 DNS 정보를 갱신하거나 그 TTL을 줄이도록 안내합니다.²

그런데 페일오버 뒤에는 네 가지 일이 따로 진행됩니다.

• 서버의 역할이 바뀝니다(옛 writer는 reader가 되고 reader 하나가 writer가 됩니다).
• cluster endpoint의 DNS가 갱신됩니다.
• JVM이 주소를 다시 조회합니다.
• JDBC 드라이버가 새 연결을 맺습니다.

새 연결을 시작할 때 받은 주소가 옛 writer의 주소라면 DNS가 나중에 갱신돼도 그 연결 시도는 옛 노드로 향할 수 있습니다. Wrapper의 초기 연결 플러그인(initialConnection)도 이 상황을 다룹니다.¹³

첫 번째 페일오버의 기록에 이 흐름이 드러납니다. 아래 시간은 일반 MariaDB 2.7 튜닝 구성(t03)에서 첫 실패 연산이 시작된 시각을 기준으로 맞춘 값입니다.

기본값 구성은 연결이 끊긴 직후 다시 연결을 시도했고 약 10초 뒤 reader가 된 옛 writer에 연결됐습니다. 첫 반복에서 이후의 쓰기는 계속 같은 물리 연결 98 하나에서 거부됐습니다. 물리 연결은 DB 서버와 맺은 실제 연결 하나이며 CONNECTION_ID() 값으로 구분합니다. 로그의 핵심 필드를 추리면 다음과 같습니다.¹⁴

server_id = jdbc-test-1
conn_id   = 98
read_only = 1
sql_state = HY000
err_code  = 1836
err_msg   = (conn=98) Running in read-only mode

server_id는 응답한 인스턴스, conn_id는 물리 연결 번호입니다. read_only = 1과 오류 코드 1836은 이 노드가 읽기 전용이어서 쓰기를 거부했다는 기록입니다.

일반 드라이버 기본값 구성 세 개(d01·d02·d04)는 30회 모두, JVM DNS를 무기한 캐시한 구성(v01, 6절)은 10회 모두 옛 writer에 연결된 채 머물렀습니다. 그동안 읽기는 성공하고 쓰기는 거부됐습니다.

반면 DNS·타임아웃을 조정한 일반 드라이버 세 구성에서는 30회 모두 새 writer로 복구됐고 옛 writer에 닿은 쓰기는 없었습니다. 성공 시점은 runner에서 DNS 변경을 관찰한 뒤였습니다.

재시도하는 동안 짧은 DNS TTL이 지나 새 주소를 얻었다고 해석할 수는 있습니다. 하지만 DNS TTL과 두 연결 타임아웃을 하나씩 떼어 본 대조 실험은 없습니다. 어느 값이 결정적이었는지는 이 결과만으로는 가릴 수 없습니다. runner의 DNS 조회도 약 1초 간격의 표본이며 각 JVM이 실제로 사용한 DNS 캐시를 직접 읽은 기록은 아닙니다.

6. 커넥션 풀은 왜 읽기 전용으로 계속 연결할까요

커넥션 풀이 보기에는 read-only가 된 옛 writer와의 연결에 아무 문제가 없기 때문입니다. 실패한 것은 쓰기 쿼리이고 연결 자체에는 오류가 없습니다.

응답하는 옛 writer와의 연결은 커넥션 풀의 기본 연결 검증(연결이 살아 있는지 확인하는 검사)을 통과할 수 있습니다. HikariCP 7.1.0은 이 검증에 JDBC의 Connection.isValid()를 사용합니다. 이 검사를 통과했다고 해서 현재 노드가 writer라는 보장은 없습니다.¹⁵

HikariCP는 SQL 예외가 났다고 해서 매번 그 연결을 폐기하지는 않습니다. 기본 설정에서는 SQLState와 일부 오류 코드로 연결이 고장 났는지 판정합니다. SQLState가 08로 시작하는 연결 오류이거나 미리 정해 둔 SQLState·오류 코드 목록에 해당하면 그 연결을 폐기합니다. 이번에 반복된 HY000·오류 코드 1836 조합은 이 기본 폐기 조건에 해당하지 않습니다.¹⁶

이번 기록에서는 다음 과정이 되풀이됐습니다.

1. 애플리케이션이 풀에서 연결을 빌립니다.
2. 연결된 옛 writer가 노드 조회에 응답합니다.
3. INSERT는 read-only 오류로 실패합니다.
4. 연결은 풀로 반환되고 다시 사용됩니다.

기본값 구성이 쓰기를 복구하기까지 걸린 약 30분은 HikariCP의 기본 maxLifetime=1800000(30분)과 비슷합니다. 연결 수명이 끝나 새 연결로 교체되면서 복구됐을 가능성이 있습니다. 다만 수명 만료로 연결을 닫았다는 로그는 이번 기록에 없으므로 이 설명은 추정입니다.

maxLifetime을 복구 시간의 상한으로 볼 근거는 없습니다. 이 값은 연결의 최대 수명을 정할 뿐이고 애플리케이션이 빌려 쓰고 있는 연결은 수명이 다 돼도 풀이 바로 끊지 않습니다.¹⁷

DNS 캐시를 고정하면 연결이 새로 갱신되어도 쓰기에 연결되지 않습니다.

연결을 새로 만들어도 새 연결이 옛 주소로 향하면 소용이 없습니다. 이를 확인하려고 일반 MariaDB 2.7 튜닝 구성에서 JVM DNS TTL만 -1, 즉 무기한 캐시로 바꾼 구성(v01)도 실행했습니다. maxLifetime은 50초로 유지했습니다.

이 구성은 10회 모두 관찰 종료까지 쓰기가 복구되지 않았습니다. 장기 관찰 두 번에서 쓰기 공백은 각각 2,088.0초·2,088.2초 이상이었습니다. 그동안 응답한 물리 연결은 각각 164개·153개였지만 새로 만든 연결에서도 응답한 노드는 모두 같은 옛 writer였습니다.¹⁸

JVM이 DNS 조회 결과를 캐시하는 시간은 Java 보안 속성 networkaddress.cache.ttl로 정합니다. AWS의 JVM DNS 가이드는 이 값을 5초로 설정하는 방법을 안내합니다. 이 실험에서는 JVM이 처음 DNS를 조회하기 전에 Security.setProperty()로 이 속성을 설정했습니다. 설정하지 않았을 때의 기본 TTL 값은 이번 기록에 없습니다.⁶

maxLifetime만으로 복구 시간을 계산할 수는 없었습니다

일반 MariaDB 2.7 튜닝 구성에서 다른 값은 그대로 두고 maxLifetime만 바꾼 결과입니다. 각 구성은 10회씩 측정했습니다.

수명 값을 바꿔도 결과는 거의 같았습니다. 이 구성들은 옛 writer에 연결되지 않고 연결 수명보다 짧은 시간 안에 새 writer로 복구됐습니다. “쓰기 공백은 항상 연결 수명에 몇 초를 더한 값”이라는 공식을 만들 근거는 없습니다. 옛 writer에 남은 구성과 새 writer를 찾은 구성은 복구 경로부터 달랐습니다.

20초 설정이 30분으로 바뀐 것은 HikariCP 7.1.0의 설정값 검사 규칙 때문입니다. 이 버전은 0이 아닌 maxLifetime이 30초보다 작으면 기본값으로 되돌립니다. 10회 모두 기동 로그에 아래 메시지가 남았고 풀의 런타임 값도 1,800초였습니다.⁵

maxLifetime is less than 30000ms, setting to default 1800000ms.

설정 파일에 적힌 값뿐 아니라 실제로 생성된 풀의 값을 확인해야 하는 이유입니다.

7. Wrapper는 새 writer를 어떻게 찾을까요

Wrapper의 failover2 플러그인은 cluster endpoint의 DNS 변경만 기다리지 않습니다. 별도 토폴로지 모니터링 구성 요소로 클러스터 구성을 확인해 새 writer를 찾고 그 writer로 연결을 다시 맺습니다.⁷

이번 S1 실험에서 기반 드라이버만 다른 두 Wrapper 구성은 중앙값이 기본값에서 2.0초·1.8초, 튜닝에서 1.8초·1.6초로, 두 경우 모두 0.2초 차이였습니다.

MariaDB Connector/J 2.7의 aurora 스킴도 비교했습니다. 하지만 그 결과를 모든 MariaDB 드라이버에 적용할 수는 없습니다. 3.0.3 릴리스 노트에 Aurora 전용 지원을 제거했다고 적혀 있기 때문입니다. URL을 바꾸기 전에 실제 드라이버와 버전을 확인해야 합니다.⁹

Wrapper도 URL만 바꾼다고 기존 애플리케이션의 장애 처리가 모두 끝나지는 않습니다. 두 가지가 더 필요합니다.

• Wrapper 아래에서 실제로 DB와 통신할 기반 JDBC 드라이버가 필요합니다.
• 재연결 뒤 애플리케이션에 전달되는 예외를 처리해야 합니다.

이번 Wrapper 구성에서 주로 나온 예외는 FailoverSuccessSQLException이었습니다. 연결이 다른 노드로 전환됐음을 알리는 예외이며 방금 실행하던 업무의 성공 여부와는 별개입니다.¹⁹

Wrapper를 HikariCP와 함께 쓰려고 튜닝 구성에는 AWS 예제의 다음 값을 적용했습니다.²⁰

# HikariCP 속성: Wrapper의 페일오버 예외를 처리하는 구현체입니다.
exceptionOverrideClassName=software.amazon.jdbc.util.HikariCPSQLException

업무 재시도는 따로 설계해야 합니다. 트랜잭션 도중 연결이 끊기면 그 처리가 성공했는지 알 수 없는 경우가 생길 수 있습니다. 이때 연결이 복구됐다는 이유만으로 쓰기를 무조건 다시 실행할 수는 없습니다. 중복 실행을 막는 식별자와 처리 결과 확인이 필요합니다. 이 측정의 쓰기는 짧은 자동 커밋이며 업무 트랜잭션의 재시도는 측정 범위에 없습니다.

8. 에러가 0건인데도 쓰기가 멈출 수 있을까요

멈출 수 있습니다. 예외가 발생하지 않은 채 한 연산이 오래 걸리면 에러 건수에는 아무것도 나타나지 않습니다.

t02는 MariaDB 2.7의 aurora 스킴에 cluster endpoint와 cluster-ro를 함께 넣은 튜닝 구성입니다. 이 구성은 10회 중 8회에서 쓰기·읽기 에러가 모두 0건이었습니다.

그런데 이 8회에서 DB에 기록된 연속 행 사이의 최대 시각 간격은 중앙값 8.4초, 범위 3.3~14.2초였습니다. 200ms마다 쓰도록 만든 루프인데 모든 반복에서 1초가 넘는 공백이 생겼습니다.²¹

예외 없이 연산 하나가 최대 약 14초 걸리는 동안, 다음 쓰기 시도도 진행되지 않았습니다. 예외가 나지 않았으므로 예외 카운터에는 이 대기 시간이 나타나지 않았습니다.

이 실험에서는 예외 건수와 함께 연산 지연, 성공 쓰기의 간격, DB에 저장된 행의 시각을 확인했습니다. DB 행의 시각은 클라이언트 완료 시각과 함께 봐야 기록 사이의 공백과 응답 지연을 구분할 수 있습니다.

반대로 Wrapper 구성에서는 페일오버 예외가 났어도 더 짧은 시간 안에 다음 쓰기가 성공했습니다. 에러 건수만 비교하면, 에러가 0건인 반복에서 쓰기가 최대 약 14초 멈춘 구성이 에러를 내고 더 빨리 복구한 구성보다 나아 보입니다.

9. Blue/Green 전환 뒤에는 어느 클러스터에 썼을까요

Blue/Green 전환은 같은 클러스터 안에서 writer를 바꾸는 페일오버와 다릅니다. 서비스 대상이 아예 다른 클러스터로 옮겨 가고 전환 뒤에도 옛 blue 환경이 남습니다.⁸ 옛 blue에 남은 애플리케이션이 어떻게 동작하는지가 중요합니다.

이 실험에서는 비특권 사용자 probe와 마스터 사용자 admin으로 Blue/Green 전환을 한 번씩 관찰했습니다. 두 전환은 서로 다른 배포에서 진행했으므로 사용자 권한만 바꾼 대조 실험으로 보지는 않습니다.

probe 실행: 옛 blue에서 읽기만 계속 성공했습니다

probe 실행에서는 기본값 구성 6개와 JVM DNS 무기한 캐시 구성(v01) 1개가 옛 blue에 남았습니다. 이 7개 구성은 600초 관찰 종료까지 쓰기가 복구되지 않았습니다. 읽기는 전환 완료 이후에도 구성마다 약 2,668건이 옛 blue에서 성공했습니다. 이 6개 기본값 구성에는 Wrapper를 사용하되 bg(Blue/Green 전환을 처리하는 플러그인)를 추가하지 않은 구성도 포함됩니다.²²

같은 실행의 MariaDB aurora 튜닝 구성에서는 쓰기가 green으로 옮겨 간 뒤에도 옛 blue reader에서 10건의 읽기가 1.8초에 걸쳐 성공했습니다. 여기서 측정한 것은 옛 blue가 응답했다는 사실입니다. 읽기 쿼리는 노드 정보를 조회했으므로 업무 데이터가 실제로 얼마나 오래된 값이었는지는 측정하지 않았습니다.

admin 실행: 옛 blue에 쓰기가 성공했습니다

admin 실행에서는 더 눈여겨봐야 할 결과가 나왔습니다. 옛 blue에 남은 7개 구성은 전환 완료 이후 각각 2,672~2,673행을 옛 blue에 기록했습니다. 같은 구간에 이 구성들이 green에 기록한 행은 없었습니다. 클라이언트에서는 쓰기가 다시 성공했지만 서비스가 옮겨 간 클러스터에 기록된 것은 아니었습니다.²³

당시 옛 blue의 관찰값은 read_only=1, super_read_only=0, innodb_read_only=0이었고 admin에는 CONNECTION_ADMIN 권한이 있었습니다. MySQL 문서상 이 권한을 가진 사용자는 read_only의 쓰기 제한을 받지 않습니다. 이 조건은 옛 blue에서 실제로 쓰기가 성공한 결과와 맞아떨어집니다.²⁴

따라서 복구를 확인할 때는 응답한 노드·클러스터가 어디인지, 실제로 어디에 기록됐는지를 봐야 합니다. 읽기 성공, 쓰기 성공, @@innodb_read_only=0만으로는 애플리케이션이 새 운영 환경으로 옮겨 갔는지까지 알 수 없습니다.

Blue/Green의 메타데이터 권한도 양쪽에서 확인해야 합니다. Wrapper 문서는 비특권 사용자에게 필요한 권한을 blue와 green 모두에 준비하도록 안내합니다. Wrapper 튜닝 구성(t05·t06)의 쓰기 공백은 probe 실행 35.7초, admin 실행 4.1초였습니다(11절 표). 이번 기록에는 배포 생성 후 blue에 mysql.rds_topology 조회 권한을 부여한 사실이 남아 있습니다. 하지만 green의 권한을 직접 검증한 기록은 없습니다. 사용자별 Wrapper 전환 시간 차이를 권한 하나 때문이라고 볼 근거는 없습니다.²⁵

reader 삭제는 페일오버와 다르게 진행됐습니다

reader 삭제(S2)도 따로 두 번 시험했습니다. 이때는 cluster-ro를 함께 넣지 않은 MariaDB aurora 구성(v05)도 읽기 에러가 0건이었습니다.

삭제 요청을 받은 reader는 요청 뒤 약 400초까지 응답했습니다(마지막 성공 읽기 기준). 구성마다 남은 reader로 읽기를 옮긴 시점은 달랐습니다. t02·v07은 요청 뒤 25~72초에, v05·v06은 약 390~400초에 남은 reader로 읽기를 옮겼습니다. 한 장애 시나리오의 결과만으로는 모든 토폴로지 변경을 예측하지 못합니다.²⁶

10. 운영에서는 복구가 멈춘 지점을 어떻게 찾을까요

복구가 멈춘 지점을 찾으려면 DB 이벤트, 주소 조회, 연결 재사용, 실제 쓰기를 단계별로 따로 봐야 합니다. 이번 측정 결과를 기준으로 먼저 살펴볼 항목은 다음과 같습니다.

타임아웃 설정은 이름이 비슷해도 기다리는 대상이 다릅니다.²⁷

이번 일반 드라이버 구성에서 최초 실패 연산은 0.3초 이내에 연결이 끊겼음을 알리는 오류(connection reset·EOF·socket 오류)로 끝났습니다. 이 0.3초는 실패한 연산의 소요 시간일 뿐 DB 장애 발생부터 감지까지를 따로 잰 값과는 다릅니다. 관찰한 10초대 복구를 socketTimeout=10000이 발동한 결과라고 해석할 근거는 없습니다.

실험에 쓴 3초·5초·10초를 그대로 운영의 정답으로 삼지 않습니다. 각 서비스의 정상 쿼리 시간과 요청 제한 시간에 맞춰 값을 정하고 그 값으로 다시 측정해야 합니다.

11. 측정 자료는 어떻게 읽을까요

본문의 수치는 아래 공개 자료의 반복별 요약에서 나왔습니다. 구성 이름의 접두어는 1절에서 설명한 대로 d가 기본값, t가 튜닝, v가 비교용 변형 구성입니다. 측정 행을 넣은 테이블과 데이터베이스의 이름도 probe지만 사용자 probe와는 별개입니다.

s3-bluegreen-rows-after-switchover.csv의 행 수는 DB에서 집계했습니다. probe 실행은 옛 blue 행이 모두 0이고 green 행 수는 집계하지 않아 비어 있습니다.

S1·S2·S3의 반복별 지표 파일(*-iterations.csv)은 같은 열을 씁니다. 주요 열의 뜻은 다음과 같습니다.

연산마다 한 줄씩 남긴 원시 연산 로그(약 570MB)는 공개하지 않고 반복별 요약만 공개합니다.

수치를 읽을 때 주의할 점

쓰기 공백은 순수한 DB 정지 시간이 아닙니다. 쓰기 공백은 연속한 두 성공 쓰기의 완료 시각 사이에서 가장 긴 간격입니다. 계산 범위는 사건 직전 마지막 성공부터 관찰 종료까지입니다. 정상 상태에도 약 0.2초의 간격이 있습니다. DB에 저장된 ts의 연속 행 간격도 함께 기록했습니다. ts는 측정 테이블에 행을 넣을 때 NOW(6)으로 남긴 시각이라 커밋 완료 시각과는 다릅니다.

미복구 값은 하한입니다. 관찰 종료까지 쓰기가 돌아오지 않은 반복은 미복구로 표시했습니다. 예를 들어 “360초 관찰에서 미복구”는 쓰기 공백이 정확히 360초였다는 뜻이 아닙니다. 실제 실패는 페일오버 요청보다 늦게 시작됐고 관찰을 끝낸 뒤 언제 복구됐는지도 알 수 없기 때문입니다.

부하는 가볍습니다. 측정 루프는 한 연산이 오래 걸리면 다음 실행을 늦추고 밀린 실행은 건너뜁니다. 운영 서비스처럼 요청이 계속 쌓일 때의 대기열이나 사용자 응답 시간까지 측정한 실험은 아닙니다.

구성별 결과

S1 페일오버의 쓰기 공백(초)을 관찰 길이별로 나눈 표입니다. 값은 중앙값(최솟값~최댓값)입니다. “미복구 8회 ≥337.8”은 8회 모두 관찰 종료까지 복구되지 않았고 그중 가장 짧은 공백 하한이 337.8초라는 뜻입니다.

S2 reader 삭제 2회의 읽기 공백(초)과 회차별 읽기 에러 수입니다. 표에 실은 구성은 두 종류입니다. reader로 읽기를 보낸 구성(t02·v05·v06의 읽기 전용 풀, v07의 cluster-ro)과, 비교를 위해 cluster endpoint로 읽은 d03·t05입니다. 나머지 구성도 읽기 공백 0.2초, 읽기 에러 0건이었습니다.

S3 Blue/Green 사용자별 1회의 쓰기 공백(초)과, probe 실행에서 스위치오버 완료부터 관찰 종료까지 옛 blue가 응답한 읽기 수입니다. admin의 d01~d06·v01 값은 옛 blue에 쓰기가 다시 성공할 때까지의 공백이며 green으로 복구된 시간과는 별개입니다.

측정 코드는 어떻게 동작했을까요

측정 코드는 구성마다 JVM 하나를 띄우고 그 안에 HikariCP 풀을 만들어 200ms 주기의 쓰기·읽기 루프를 돌립니다. 연결을 쓸 수 있는지는 드라이버로 보낸 실제 쿼리가 성공했는지로 확인합니다. 쓰기는 응답 노드를 조회한 뒤 INSERT를 실행하고 읽기는 3절의 노드 조회 쿼리를 실행합니다. 페일오버·reader 삭제·Blue/Green 전환 같은 사건은 AWS CLI로 일으킵니다.

정리

같은 Aurora MySQL 페일오버에서 쓰기 복구는 약 2초에서 약 30분까지 갈렸습니다. Wrapper 구성은 약 2초, DNS·타임아웃을 조정한 일반 드라이버는 약 10초, 기본값 일반 드라이버는 옛 writer에 남아 약 30분이 걸렸습니다.

오래 걸린 구성에서 애플리케이션이 DB를 못 찾은 것은 아니었습니다. 애플리케이션은 reader로 강등된 옛 writer에 정상적으로 연결돼 읽기는 성공하고 쓰기만 거부당하는 상태에 머물렀습니다. 커넥션 풀의 기본 연결 검증과 예외 판정은 그 연결을 고장으로 보지 않았습니다. JVM DNS를 무기한 캐시로 바꾼 구성(v01, 10회 시험)에서는 연결을 새로 만들어도 옛 주소로 돌아갔습니다.

복구를 판정할 때는 명령 반환 시간이나 RDS 이벤트, 에러 건수만 보지 않습니다. 애플리케이션의 복구 완료 조건에는 새 writer에서 의도한 쓰기가 성공했는지, 기대한 데이터가 새 운영 환경에 기록됐는지를 포함해야 합니다. DB 이벤트부터 주소 조회, 연결 재사용, 실제 쓰기까지 이어서 보면 같은 페일오버가 어떤 애플리케이션에는 2초이고 다른 애플리케이션에는 30분이 된 이유를 찾을 수 있습니다. 운영 중인 서비스에서는 다음을 먼저 확인합니다(전체 항목은 10절 표).

• 실제 드라이버·URL·플러그인(Wrapper 여부)
• JVM DNS TTL
• 풀의 런타임 값(HikariCP 7.1.0에서 0이 아닌 maxLifetime이 30초 미만이면 30분으로 바뀜, 6절)
• 쓰기 공백과 실제 기록 위치

참고 자료

관련 글 · 벡터 DB의 개념과 제품 · 선택 기준과 기능 비교 · AWS 전용 벡터 검색

사내 운영 문서를 검색하는 챗봇에 사용자가 “야간에 DB 장애가 나면 어디에 먼저 알려야 하나요?”라고 물었다고 해 봅시다. 답변이 틀렸다면 검색이 필요한 근거를 놓쳤는지, 가져온 근거를 모델이 잘못 읽었는지 구분할 수 있어야 고칠 곳을 찾을 수 있습니다.

앞선 글에서는 이 챗봇에 넣을 데이터의 범위와 요건, 전처리, 피처 설계를 정리했습니다. 이번에는 그 데이터로 만든 서비스가 제대로 동작하는지 확인할 평가 데이터셋을 만들고, 검색 품질과 답변 품질을 나눠 평가하는 방법을 살펴봅니다. 앞선 글에서 구분했듯이 검색 문서 집합(corpus), 모델을 학습할 데이터, 결과를 평가할 데이터는 목적이 다릅니다. 이미 학습된 임베딩 모델과 LLM을 사용하는 일반적인 RAG는 별도의 모델 학습 없이 구성할 수 있고, 필요에 따라 모델 학습을 추가할 수 있습니다.¹ 이 글은 세 가지 데이터 가운데 평가 데이터를 중심으로 다룹니다.

이 글의 조사 기준일은 2026년 9월 27일입니다. 평가 레코드 JSON의 운영 지침은 설명을 위해 만든 가상 예시이며, 평가 지표의 수치는 계산 예시입니다. 실제 서비스의 성능을 측정한 결과는 아닙니다.

1. Gold 데이터와 QA는 어떻게 만들까요

업무 전문가가 중요한 원천 자료를 골라 검토하고, 이를 바탕으로 LLM이 질문과 답변을 확장한 뒤 전문가가 다시 확인하는 흐름으로 질문·답변(QA)을 만들 수 있습니다. 실제 사용자 질문을 활용하고, 데이터 생성 전체를 검토 없이 자동화하지 않는다는 점이 핵심입니다.

이 글에서는 업무 전문가가 골라 검토한 중요한 원천 자료를 Gold 데이터, 정답 근거와 참고 답변까지 확정한 질문·답변을 평가 문항이라고 부르고 둘을 구분합니다. 원천 문서가 정확하더라도 그 문서에서 생성한 질문이 모호하거나 답변이 틀릴 수 있으므로, 문서를 승인한 것만으로 QA까지 승인된 것은 아닙니다.

대표 사례와 놓치면 안 되는 사례를 함께 고릅니다

자료를 업무별로 분류하고, 질문의 빈도와 실패했을 때의 영향을 함께 봅니다. 벡터 유사도로 비슷한 자료를 묶어 대표 사례를 찾는 방법은 선별을 도울 수 있습니다. 다만 중심에 가까운 문서만 고르면 드문 예외나 특이한 형식이 빠질 수 있으므로, 아래와 같은 사례를 별도로 넣는 편이 좋습니다.

• 자주 묻는 용어·절차와 실제 Help Desk 질문
• 표·그림·각주를 읽어야 답할 수 있는 질문
• 둘 이상의 근거를 조합해야 하는 질문
• 개정 전후의 내용이 달라지는 질문
• 자료에 답이 없거나 추가 조건을 물어야 하는 질문
• 사용자 권한에 따라 제공 가능한 정보가 달라지는 질문

RAG 평가 도구인 Ragas도 단일 근거로 답하는 질문과 여러 출처를 연결해야 하는 질문을 구분합니다. 질문의 말투만 바꾸는 것에 더해, 어떤 근거와 추론이 필요한지 달라지는 문항을 만드는 데 참고할 수 있습니다.²

질문 생성과 답변 작성 모두에 근거를 제공합니다

QA 작성 순서는 다음과 같이 잡을 수 있습니다.

1. 근거를 고릅니다. 원천 문서의 버전과 답에 필요한 부분을 지정합니다.
2. 질문을 만듭니다. 실제 질문을 우선 활용하고, 빈 유형은 LLM으로 보충합니다.
3. 답변을 작성합니다. 질문과 함께 근거를 제공해 참고 답변과 필수 사실을 만듭니다.
4. 형식을 맞춥니다. 요약, 목록, 절차, 출처 표기 등 서비스의 출력 요구를 반영합니다.
5. 전문가가 확인합니다. 업무상 타당성, 원문과의 일치, 누락된 조건, 답변 가능 여부를 검사합니다.
6. 이력을 남깁니다. 원본·생성 모델·프롬프트·검토 상태를 기록하고, 중복 문항을 정리합니다.

질문만 LLM에 주고 답을 만들게 하면 근거 밖의 지식으로 그럴듯한 정답을 만들어 낼 수 있습니다. 질문을 만드는 단계와 답변을 만드는 단계 모두에 승인된 자료를 연결하는 것이 좋습니다.

Few-shot 방식은 검토한 예제를 프롬프트에 넣어 새 QA의 형태와 수준을 안내하는 데 사용할 수 있습니다. 이때는 같은 질문의 표현만 바뀐 문항과 새로운 업무 상황을 다루는 문항을 구분합니다. QA 1개를 비슷한 질문 100개로 늘려도 서로 다른 업무 100개를 검증한 것은 아닙니다.

학습용이라면 Instruction·Input·Output 형태로 정리할 수 있습니다. 다만 이것은 자료를 정리하는 한 가지 형식이고, 실제 학습에 넣을 때는 학습 대상이 요구하는 스키마에 맞춰야 합니다. 평가용 레코드에는 이 세 값 외에 정답 근거와 기대 동작이 필요합니다.

2. 평가 데이터셋에는 무엇을 담을까요

평가 문항은 “질문 하나, 정답 문장 하나”보다 조금 더 풍부해야 합니다. 질문에 어떤 자료가 필요한지 알아야 검색 실패와 생성 실패를 구분할 수 있습니다. 다음은 특정 제품의 API 형식이 아닌, 직접 관리할 수 있는 평가 레코드의 예시입니다.

{
  "case_id": "ops-night-001",
  "question": "야간에 DB 장애를 발견하면 어디에 먼저 알려야 하나요?",
  "question_type": "single_hop",
  "as_of": "2026-09-27",
  "actor_groups": ["db-oncall"],
  "expected_behavior": "answer",
  "reference_answer": "발견 후 10분 이내에 당직 채널에 등록하고 담당 DBA를 호출합니다.",
  "required_facts": [
    "발견 후 10분 이내 당직 채널 등록",
    "담당 DBA 호출"
  ],
  "evidence": [
    {
      "document_id": "db-incident-runbook",
      "document_version": "v3",
      "section": "2.1 야간 장애 접수",
      "text": "야간 DB 장애 발견자는 발견 후 10분 이내에 당직 채널에 등록하고 담당 DBA를 호출한다."
    }
  ],
  "split": "test",
  "origin": "illustrative_example"
}

이 예시의 10분과 연락 절차는 가상의 규정입니다. 실제 문항에는 원문 근거를 넣고 검토자·검토 상태·평가 데이터셋 버전도 관리합니다. actor_groups는 테스트에서 설정하는 사용자 조건이며, 서비스에서는 클라이언트가 보낸 문자열을 그대로 신뢰하지 않고 인증된 신원으로 결정해야 합니다.³

reference_answer와 required_facts, evidence는 평가기가 사용할 기준입니다. 평가 실행 때 서비스에 정답을 함께 전달하지 않습니다. 서비스에는 질문과 필요한 사용자 조건을 넣고, 실제 검색 결과·LLM에 전달한 컨텍스트·생성 답변을 별도의 실행 결과로 저장합니다. question_type에는 질문 유형을 적습니다. 예시의 single_hop은 1절에서 본 단일 근거 질문입니다. as_of는 질문의 기준일을, split은 이 문항이 3절의 어느 데이터 구분에 속하는지를 적는 필드입니다.

정답 근거는 청크 ID에만 묶지 않습니다

청크 분할 방식을 바꾸면 청크 ID와 경계가 달라질 수 있습니다. 그러므로 문서 ID·버전·절·근거 구절을 기준으로 정답을 남기고, 실행 시점의 청크가 그 근거를 포함하는지 대응시키는 방식을 제안합니다. 문서 단위 평가라면 같은 문서의 여러 청크를 중복 정답으로 세지 않는 규칙도 필요합니다.

이 방식은 평가 질문을 특정 검색기의 결과에 종속시키지 않기 위한 것입니다. Microsoft도 합성 질문 생성에 쓰는 일회성 분할과 실제 솔루션의 청크 분할을 구분하도록 안내합니다.⁴

현재 검색기의 Top-k에서만 근거를 고르고 질문을 역으로 만들면, 현재 검색기가 놓치는 자료는 평가 문항에도 나타나지 않을 수 있습니다. 검토한 원문에서 질문·근거를 만들고, 각 검색기가 그것을 찾아내는지 비교하는 편이 이 편향을 줄이는 데 도움이 됩니다.

질문에 필요한 근거 수와 검색할 k도 구분합니다. 청크를 여러 개 가져왔다고 모두 정답 근거인 것은 아니며, 비슷한 문단을 모았다는 것만으로 여러 근거를 연결해야 하는 질문이 만들어지는 것도 아닙니다.

답하지 않아야 하는 질문도 평가합니다

답이 없는 문항에는 reference_answer: null, expected_behavior: "abstain"(답변 유보)처럼 의미를 명시할 수 있습니다. 서비스 범위에 따라 확인 질문은 clarify, 접근 제한은 deny 등으로 나눌 수 있습니다. 이름 자체보다 기대 동작과 통과 기준을 합의하는 것이 중요합니다.

외부 문서에 들어 있는 지시가 모델의 행동을 바꾸는 것은 간접 프롬프트 인젝션의 한 형태입니다. OWASP는 문서·웹페이지 등의 외부 입력과 시스템 지시를 구분하고 권한을 제한하도록 안내합니다.⁵ 따라서 보안 문항은 최종 답변뿐 아니라, 제한된 자료가 LLM에 전달됐는지와 허용하지 않은 도구 호출이 발생했는지도 확인해야 합니다.

3. 학습·개발·최종 평가 데이터는 어떻게 나눌까요

데이터를 나누는 목적은 새 질문에 대한 성능을 평가하는 데 있습니다. 모델을 학습하지 않는 RAG라도 프롬프트, 청크 크기, 검색 파라미터를 같은 문항에 반복해서 맞추면 그 문항에 유리한 설정을 고를 수 있습니다. 최종 평가 데이터를 설정 선택에 계속 사용하지 않는다는 원칙이 필요합니다.⁶

나누는 단위도 중요합니다. 원문 하나에서 만든 질문 20개를 무작위로 나누면, 학습·개발 쪽과 최종 평가 쪽에 사실상 같은 내용이 들어갈 수 있습니다. 같은 문서 계열이나 티켓, 거의 같은 질문에서 파생된 문항은 그룹으로 묶는 방식을 고려합니다. 그룹 구조가 있는 데이터는 그룹별로 나눠야 새로운 그룹에 대한 성능을 평가할 수 있습니다.⁶ 앞의 그룹 묶기는 이 원칙을 RAG의 QA에 적용한 것입니다.

다만 최종 평가 질문의 근거 문서를 검색 문서 집합에서 무조건 빼라는 뜻은 아닙니다. 검색형 QA에서는 근거가 검색 대상에 있어야 정상적으로 답할 수 있습니다. 분리해야 하는 것은 평가 질문·참고 답변을 학습이나 설정 조정에 사용하는 경로입니다. 처음 보는 문서에 대한 일반화까지 평가하려면 문서 그룹도 나눕니다. 최종 평가용 문항은 학습·개발에 쓰지 않은 문서 그룹에서 만들고, 평가할 때는 그 문서를 검색할 수 있게 구성합니다.

시간에 따라 바뀌는 업무라면 질문의 기준일과 당시 사용 가능한 문서 버전도 맞춥니다. 과거 질문을 재현하면서 당시에는 없었던 후속 보고서를 근거로 제공하면 실제보다 쉬운 시험이 됩니다. 시간 순서가 있는 데이터의 평가에서 미래 정보를 섞지 않는 원칙을 문서 스냅샷에도 적용하는 것입니다.⁶

4. 검색과 답변을 어떻게 따로 평가할까요

최종 답변만 보면 왜 틀렸는지 알기 어렵습니다. 도입부의 야간 장애 질문처럼 답이 틀렸다면, 검색이 근거를 놓쳤는지 모델이 근거를 잘못 읽었는지부터 나눠 봐야 합니다. Amazon Bedrock도 검색만 평가하는 작업과 검색·생성을 함께 평가하는 작업을 나눕니다.⁷

검색 평가: 필요한 근거를 얼마나, 어떤 순서로 찾았나요

아래는 사람이 관련성을 판정한 문서나 근거 단위를 기준으로 한 지표입니다. MRR은 Mean Reciprocal Rank, nDCG는 normalized Discounted Cumulative Gain의 약자입니다.⁸

예를 들어 정답 근거가 A, B, C이고, 검색 순서가 X, A, Y, B, Z라면 다음과 같습니다. X, Y, Z는 관련 없는 결과라고 가정합니다.

Precision@5 = 2 / 5 = 0.40
Recall@5    = 2 / 3 ≈ 0.667
RR@5        = 1 / 2 = 0.50

마지막 값은 이 질문 하나의 reciprocal rank(RR)입니다. 여러 질문의 RR을 평균한 것이 MRR입니다. 상위 k개 안에 관련 결과가 없으면 해당 질문의 RR은 0으로 계산합니다.

이 글의 Precision@k는 분모를 k로 두고, k개를 채우지 못한 자리는 관련 결과가 없는 것으로 계산하는 규칙을 사용합니다. 도구를 사용할 때는 실제 반환 수를 분모로 쓰는지, 관련성을 판정하지 않은 결과(미판정 결과)를 제외하는지 확인해야 합니다. 정답 근거가 없는 문항의 Recall은 분모가 0이므로 일반 검색 Recall 평균에서 제외하고, 별도의 답변 유보 평가에 포함합니다.

정답 목록에 없는 검색 결과를 모두 오답으로 확정하는 것도 조심해야 합니다. 새로 찾은 문서가 실제로 유효한 근거일 수 있습니다. 미판정 결과를 구분하고 검토한 뒤 동일한 평가 데이터셋 버전으로 다시 비교하는 것이 좋습니다.⁸

여기서의 Recall@k와 근사 최근접 이웃(ANN) 검색의 recall@k는 기준이 다릅니다. ANN recall은 정확한 최근접 이웃 검색 결과를 얼마나 재현했는지를 보고, 업무 검색 Recall은 사람이 관련 있다고 판정한 근거를 얼마나 찾았는지를 봅니다. 가까운 벡터를 잘 찾는 것과 업무상 필요한 문서를 잘 찾는 것은 구분해야 합니다.⁹

Context 지표는 이름보다 정의를 확인합니다

Ragas의 LLM 기반 Context Recall은 참고 답변의 주장 가운데 검색한 컨텍스트로 뒷받침되는 비율을 봅니다. 같은 문서의 ID를 찾았다는 것과 필요한 내용을 실제로 포함했다는 것은 다르므로, ID 기반 Recall과 구분해서 읽어야 합니다.¹⁰

Ragas의 순위 기반 Context Precision도 앞의 단순한 Precision@k와 다릅니다. 관련 청크가 나타난 각 순위까지의 precision을 이용하므로 순서가 점수에 영향을 줍니다. Ragas의 ID 기반 구현은 반환한 ID 가운데 관련 ID가 차지하는 비율을 사용합니다. 결과표에는 지표 이름과 함께 구현·입력·버전을 남기는 것이 좋습니다.¹¹

답변 평가: 근거를 바르게 사용했나요

답변은 다음 항목을 나눠 확인할 수 있습니다. Bedrock의 평가 지표 역시 정확성·완전성·근거 충실성·인용을 구분합니다.⁷

예를 들어 구버전 지침에 “30분 이내 보고”라고 쓰여 있고 모델이 그대로 답했다면, 제공된 컨텍스트에는 충실할 수 있습니다. 하지만 현재 승인된 지침이 “10분 이내 보고”라면 업무상으로는 틀린 답입니다. 근거 충실성 점수가 높아도 원천 자료의 최신성이나 사실성을 보증하지는 않습니다. Ragas의 정의도 답변과 제공된 컨텍스트 사이의 일관성을 측정합니다.¹²

LLM 채점도 검증 대상입니다

LLM-as-a-judge는 많은 답변을 평가하는 데 사용할 수 있지만, 채점 모델의 판정이 곧 정답은 아닙니다. MT-Bench 연구는 답변 순서, 장황함, 자기 답변 선호 등의 편향을 다룹니다. 이 연구의 결과를 특정 한국어 업무 RAG의 채점 정확도로 그대로 적용할 수는 없습니다.¹³

사람이 판정한 일부 문항으로 채점 기준을 점검하고, 사람과 모델의 판단이 다른 사례를 검토하는 방법을 권합니다. 문서 ID·권한·출력 형식처럼 명확한 조건은 규칙으로 확인하고, 의미 판단이 필요한 부분에 LLM 평가를 사용합니다. 같은 모델로 QA를 만들고 답변하고 채점한 점수만으로 품질을 확정하지 않습니다.

5. 작은 평가 데이터셋으로 시작해 어떻게 운영할까요

평가는 개발이 끝난 뒤로 미루지 않는 편이 좋습니다. 초기의 작은 평가 데이터셋으로 문제를 찾으면서 테스트·이행 단계로 갈수록 범위를 넓혀 가는 방식입니다. 초기 문항 수를 일률적으로 정하기보다는 지원할 업무와 문서 유형을 얼마나 포함했는지 확인합니다.

이 원칙을 적용한 작업 순서는 다음과 같습니다.

평균 점수와 함께 질문 유형별 점수와 표본 수를 봅니다. 예를 들어 100문항 중 90문항이 통과했어도, 실패한 10문항이 모두 권한 제한이나 문서 개정에 관한 질문이면 통과율 90%만으로 합격으로 보기 어렵습니다. 일반 질문의 품질 목표와 별개로 권한 위반처럼 허용하지 않을 실패 조건을 정해야 합니다.

실패한 문항은 데이터 경로를 따라 확인합니다

아래는 문서 추출, 검색, 컨텍스트 구성, 답변 생성 순서로 데이터 경로를 따라가는 진단표입니다. 관찰한 현상에서 먼저 확인할 지점을 정하는 용도이며, 원인을 하나로 단정하는 표는 아닙니다.

비교 실행에는 문서 스냅샷, 파서·청크 설정, 임베딩·재순위화·생성 모델, 검색 설정, 프롬프트와 평가 데이터셋·평가기의 버전을 남깁니다. 검색 결과와 실제 전달한 컨텍스트도 기록해야, 같은 질문에서 결과가 달라졌을 때 어느 단계가 바뀌었는지 확인할 수 있습니다.

문서 갱신은 적재 완료 표시만 보고 끝내지 않습니다. 실제 질의에서 새 내용이 검색되고, 삭제된 내용이 사라지는지 확인합니다. 예를 들어 Bedrock Knowledge Bases는 원천 자료의 추가·수정·삭제 뒤 동기화가 필요하며, 저장소에 따라 동기화 완료와 검색 가능 시점 사이에 지연이 생길 수 있다고 안내합니다.¹⁴

권한 변경도 별도로 검증해야 합니다. 인덱스에 저장한 권한 정보를 이용한다면 원천 권한이 바뀌어도 동기화 전에는 이전 값으로 판단할 수 있습니다. Azure AI Search의 권한 문서도 이 동기화 경계를 명시합니다.³ 긴급한 접근 철회가 필요한 서비스라면 검색 시 현재 권한을 다시 확인하는 등 서비스 요구에 맞는 보완 방법을 정합니다.

정리

평가 데이터셋은 질문과 정답 문장만으로 끝나지 않고, 정답 근거와 기대 동작을 함께 담습니다. 질문에 필요한 근거를 알아야 검색 실패와 생성 실패를 나눠서 확인할 수 있고, 최종 평가 문항을 설정 조정에 쓰지 않아야 새 질문에 대한 성능을 잴 수 있습니다.

처음에는 대표 질문과 정답 근거가 연결된 작은 평가 데이터셋으로 시작할 수 있습니다. 그 평가 데이터셋으로 문서 추출, 검색, 컨텍스트 구성, 답변 생성을 차례로 확인하면 다음에 고칠 지점이 드러납니다. 문항 수를 늘릴 때도 같은 질문을 반복하기보다, 새로운 업무 유형과 실제 실패 사례를 추가하는 것이 좋습니다.

참고 자료

관련 글 · 벡터 DB의 개념과 제품 · 선택 기준과 기능 비교 · AWS 전용 벡터 검색

사내 운영 문서를 검색하는 챗봇을 만든다고 생각해 봅시다. 사용자가 “야간에 DB 장애가 나면 어디에 먼저 알려야 하나요?”라고 물었습니다. 검색 결과에는 개정 전 대응 지침과 현재 지침이 함께 나오고, 정작 당직 연락 절차가 있는 PDF의 표는 텍스트로 제대로 추출되지 않았습니다. 모델이 매끄러운 문장을 만들어도 이 상태에서는 올바른 답을 기대하기 어렵습니다.

앞선 글에서는 벡터 DB 제품과 AWS의 벡터 검색 서비스를 비교했습니다. 이번에는 저장소에 넣을 데이터를 어떻게 준비하고, 그 데이터로 만든 서비스가 제대로 동작하는지 어떻게 확인할지 두 편으로 나눠 살펴봅니다. 데이터 범위·유형 분석 → 요건 정의 → 피처 설계 → 학습·평가 데이터셋 확보라는 흐름을 바탕으로, 문서 검색과 RAG에 필요한 작업을 구체화합니다. 이 글은 데이터 범위·요건·전처리·피처 설계까지 다루고, 평가 데이터셋과 평가 방법은 다음 글에서 다룹니다.

이 글의 조사 기준일은 2026년 9월 27일입니다. 도입부의 챗봇 사례와 표의 업무 상황은 설명을 위해 만든 가상 예시이며, 용량 수치는 계산 예시입니다. 실제 서비스의 성능을 측정한 결과는 아닙니다.

1. 검색 문서와 학습·평가 데이터는 어떻게 다를까요

프로젝트에서 “데이터셋을 만든다”고 할 때 가리키는 일부터 구분해야 합니다. 검색할 원본 문서를 준비하는 일, 모델을 학습시키는 일, 결과를 평가하는 일은 목적이 다릅니다.

이미 학습된 임베딩 모델과 LLM을 사용하는 일반적인 RAG는 별도의 모델 학습 없이 구성할 수 있습니다. 문서를 벡터로 변환해 색인하는 작업이 곧 LLM의 파라미터를 학습시키는 것은 아닙니다. RAG는 검색한 외부 자료를 질문과 함께 모델에 전달하는 방식이며, 필요에 따라 모델 학습을 추가할 수 있습니다.¹

질문·답변(QA) 데이터도 사용 목적에 따라 역할이 달라집니다. 같은 형식의 QA를 파인튜닝에 넣으면 학습 데이터이고, 생성 결과를 채점하는 기준으로 쓰면 평가 데이터입니다. 평가용 정답을 서비스의 프롬프트 예제나 학습 자료에 넣은 뒤 같은 문항으로 성능을 재면, 새로운 질문에 얼마나 잘 답하는지 제대로 평가하기 어렵습니다.²

따라서 시작할 때는 “학습 데이터 몇 만 건이 필요하다”보다 어떤 질문에 답할 것이며, 어떤 문서를 근거로 답하고, 무엇을 맞히면 성공으로 볼 것인지부터 정하는 편이 좋습니다.

2. 데이터 범위와 규모는 어떻게 조사할까요

먼저 시스템과 업무 영역을 나누고, 각 영역의 데이터 유형과 건수를 조사합니다. 이 목록이 수집 범위와 일정·인력 산정의 출발점이 됩니다. RAG 프로젝트에서는 여기에 수집 경로, 갱신 방식, 문서 소유자와 권한을 함께 적으면 실제 구현으로 연결하기 쉽습니다.

다음은 운영 문서 챗봇을 위한 조사표 예시입니다.

파일 수와 페이지 수, 테이블 수와 행 수는 서로 다른 단위입니다. PDF 300개라는 숫자만으로 OCR과 표 추출의 작업량을 알 수 없고, RDB 테이블 20개라는 숫자만으로 검색할 레코드 수를 알 수 없습니다. 업무 범위에 포함되는 데이터인지 담당자와 합의한 뒤, 유형별 대표 자료를 실제로 열어 수집·변환 가능성을 확인해야 합니다.

Microsoft의 RAG 준비 가이드도 업무 분류, 파일 형식, 보안 제약, 문서 구조를 함께 조사하도록 안내합니다. 파일 안의 이미지와 표, 문서에 연결된 외부 자료도 조사 대상입니다.³

파일 수를 벡터 수로 바꿔 봐야 합니다

청크마다 벡터를 하나씩 만든다면 예상 벡터 수는 다음과 같이 계산할 수 있습니다.

예상 벡터 수 = 문서 수 × 문서당 평균 청크 수
벡터 값의 크기 = 벡터 수 × 차원 수 × 차원당 바이트 수

예를 들어 문서 10,000개가 평균 12개 청크로 나뉘고, 청크마다 1,024차원 float32 벡터 하나를 만든다고 가정해 보겠습니다. 벡터는 120,000개이고, 벡터 값만 491,520,000바이트, 즉 491.52MB(468.75MiB)입니다.

이 값에는 원문, 메타데이터, 인덱스 구조, 복제본, 백업이 들어 있지 않습니다. 이미지와 본문에 벡터를 각각 만들면 벡터 수도 달라집니다. 먼저 대표 자료에서 청크 수를 측정하고, 그 결과로 전체 용량을 추정해야 합니다. 초기 적재량과 별개로 하루에 추가·수정·삭제되는 양도 조사표에 남깁니다.

3. 데이터 요건은 검증할 수 있게 적습니다

요건은 데이터 변환, 서비스, 보안, 품질로 나눌 수 있습니다. “잘 변환한다”, “정확하게 답한다”처럼 해석이 갈리는 문장을 실제로 확인할 수 있는 조건으로 바꾸는 것이 좋습니다. 아래 표는 네 범주에 들어 있는 입력·출력, 성능, 최신성을 따로 떼어 일곱 범주로 나눈 예시입니다.

“응답 시간 2초 이내”라고만 적으면 첫 토큰이 나오는 시점인지, 답변이 끝나는 시점인지 알 수 없습니다. 평균인지 p95인지에 따라서도 뜻이 달라집니다. p95는 측정한 요청의 약 95%가 해당 시간 안에 끝났다는 뜻입니다.⁴ 동시 요청 수, 입력·출력 길이, 캐시 사용 조건과 함께 목표를 적어야 같은 조건에서 확인할 수 있습니다.

“정확도 90% 이상”도 마찬가지입니다. 어떤 문항을 몇 개 평가했는지, 완전 정답과 부분 정답을 어떻게 나눴는지, 답하면 안 되는 질문을 어떻게 채점했는지도 함께 적어야 합니다. 다음 글에서 다룰 검색 Recall과 답변 정확성을 하나의 정확도라는 이름으로 합치지 않는 것이 좋습니다.

암호화와 접근 권한은 각각 확인해야 합니다

저장 데이터를 암호화해도, 검색 시스템이 다른 팀의 문서를 가져와 LLM에 전달하면 권한 문제가 남습니다. 문서 권한을 청크에 연결하고, 서버가 확인한 사용자·그룹 정보로 검색 결과를 제한해야 합니다. Azure AI Search의 보안 필터도 호출자 신원과 문서에 저장한 권한 정보를 비교하는 방식입니다.⁵

질문·답변 기록의 보관 범위와 열람 권한도 정해야 합니다. 원문에서 개인정보를 가렸더라도 검색 로그, 평가 데이터, 답변 기록에 같은 정보가 남을 수 있기 때문입니다. 외부 OCR·임베딩·LLM 서비스에 전달할 수 있는 자료인지도 수집 단계에서 확인할 항목입니다.³

4. 전처리는 무엇을 지우고 무엇을 남길까요

문서를 Markdown으로 바꾸거나 특수문자를 제거했다고 해서 검색에 적합한 데이터가 되는 것은 아닙니다. 전처리의 목표는 답에 필요한 의미와 근거 위치를 보존하는 것입니다.

주석·목차·특수문자 제거 같은 전처리 규칙은 문서의 성격에 따라 적용해야 합니다. 예를 들어 max_connections의 밑줄이나 >=의 비교 기호를 없애면 기술 문서의 의미가 바뀝니다. 본문 아래의 각주에 적용 제외 조건이 적혀 있다면 각주도 답의 근거입니다. Microsoft의 준비 가이드 역시 각주·주석·머리말 등을 일괄 삭제하기보다 관련성이 있는지 판단하도록 설명합니다.³

표를 HTML이나 Markdown으로 바꿀 때도 변환 후 관계가 남는지 확인해야 합니다. 긴 표를 나눈다면 각 조각에서 열 머리글과 단위를 알 수 있게 합니다. 이미지 설명을 LLM으로 생성했다면 원본에서 추출한 텍스트와 생성한 설명을 구분해 두어야 합니다. 그래야 설명에 오류가 생겼을 때 되짚을 수 있습니다.⁶

전처리된 텍스트만 남기기보다 원본과 그 위치 정보를 함께 보관하는 편이 좋습니다. 원본 문서 ID, 문서 버전, 페이지·절·문자 범위 등을 연결해 두면 청크를 다시 나누거나 파서를 바꿀 때도 이전 결과와 대조할 수 있습니다.

청크 크기는 평가 질문으로 결정합니다

작은 청크는 문맥을 놓칠 수 있고, 큰 청크는 무관한 내용과 토큰 비용을 늘릴 수 있습니다. 어떤 크기가 적절한지는 문서 구조와 질문에 따라 다릅니다.⁶

예를 들어 “야간 장애의 최초 연락 대상”을 답하려면 짧은 절 하나로 충분할 수 있습니다. “장애 등급별 보고 대상과 보고 기한”을 비교하려면 표 전체나 여러 절이 필요할 수 있습니다. 분할 방식을 비교할 대표 질문을 먼저 만들고, 필요한 근거가 검색·재순위화·컨텍스트 구성 뒤에도 남는지 보면서 분할 방식을 비교합니다.

청크 길이는 사용할 모델의 토큰 제한에 맞춰 확인합니다. “500글자”와 “500토큰”을 같은 것으로 다루지 않습니다. 검색할 후보 수와 LLM에 최종 전달할 청크 수도 따로 정합니다. 검색 후보를 많이 가져왔다고 그 내용을 모두 모델에 넣어야 하는 것은 아닙니다.

5. 피처 설계는 RAG에서 어떻게 달라질까요

피처 설계(feature engineering)는 중요한 피처를 선택하고, 새 피처를 만들고, 모델이 사용할 형태로 변환하는 작업입니다. 데이터 엔지니어링이 수집·처리·저장의 흐름을 만든다면, 피처 설계는 그 데이터에서 모델에 필요한 표현을 만드는 작업으로 볼 수 있습니다.

일반적인 머신러닝에서는 상관관계나 모델의 중요도로 피처를 고르거나, 날짜에서 요일을 만들고, 수치에 스케일링·로그 변환을 적용할 수 있습니다. 피처 선택은 모델의 정확도나 계산 성능을 개선하기 위해 사용하는 방법이며, 효과는 데이터와 모델에 따라 확인해야 합니다.⁷

문서 RAG에서는 이를 다음과 같이 적용할 수 있습니다. 아래 표는 정형 데이터의 피처 기법을 그대로 옮긴 규칙이 아니라, 검색 설계에 맞춰 바꾼 예시입니다.

의미 검색에 넣을 본문과 정확하게 비교해야 하는 메타데이터도 나눕니다. 제품 버전, 적용일, 문서 상태, 테넌트와 접근 권한은 문장에만 섞어 넣기보다 명시적인 필드로 관리할 수 있습니다. 특히 접근 권한은 LLM이 추측해서 만든 업무 분류로 결정하지 않고 원천 권한 체계와 연결해야 합니다.⁵

임베딩 차원을 일반 열처럼 지우면 안 됩니다

기존 임베딩 벡터의 일부 차원을 임의로 버리는 것을 일반적인 피처 선택과 동일하게 보면 안 됩니다. 보통의 밀집 임베딩은 정해진 차원으로 출력됩니다. Matryoshka처럼 차원을 줄여도 유용하도록 학습한 모델이 있지만, 그 경우에도 지원하는 방법과 검색 품질을 확인해야 합니다.⁸

질문과 문서는 호환되는 벡터 공간에 있어야 합니다. 짧은 질문으로 긴 문서를 찾는 비대칭 검색에서는 모델에 따라 질문용·문서용 인코딩 경로와 프롬프트가 다를 수 있습니다. Sentence Transformers도 이러한 구분을 안내합니다.⁹

스케일러나 차원 축소처럼 데이터에서 변환 규칙을 학습한다면 최종 평가 데이터를 그 학습에 포함하지 않습니다. scikit-learn은 피처 선택·스케일링·PCA 등의 전처리도 데이터 누수를 일으킬 수 있다고 설명합니다.²

정리

벡터 DB를 위한 데이터 준비는 파일을 변환하고 임베딩을 만드는 것보다 범위가 넓습니다. 어떤 업무를 지원할지 정하고, 답의 근거가 되는 자료를 찾아 구조·출처·버전·권한을 보존해야 합니다. 모델을 학습할 데이터와 서비스의 품질을 평가할 데이터도 구분해야 합니다.

평가 데이터셋을 만들고 검색 품질과 답변 품질을 나눠 평가하는 방법은 다음 글에서 이어집니다.

참고 자료

AWS에서 사내 문서 RAG를 만든다고 생각해 봅시다. Bedrock Knowledge Bases로 지식 베이스를 만들 때 대신 만들어 주는 벡터 저장소는 S3 Vectors, OpenSearch Serverless, Aurora PostgreSQL Serverless, Neptune Analytics 네 가지입니다. 이미 운영하는 DynamoDB, MemoryDB, ElastiCache, DocumentDB에도 벡터 검색 기능이 있습니다. 모두 벡터 검색을 지원하지만 질의당 결과 수와 필터 방식, 확장 단위, 과금 단위는 서비스마다 다릅니다.

1편에서는 벡터 DB의 개념과 제품의 종류, 공개 사용 지표를, 2편에서는 어디서나 쓸 수 있는 오픈소스·상용 제품 12종의 기능과 한도를 다뤘습니다. 이 글은 AWS 관리형으로만 쓸 수 있는 벡터 검색 서비스를 2편과 같은 기준으로 비교합니다. 비교 대상은 S3 Vectors, OpenSearch Serverless, DynamoDB, MemoryDB, ElastiCache, DocumentDB, Neptune Analytics입니다. 엔진이 오픈소스인 OpenSearch Service 도메인과 Aurora·RDS for PostgreSQL(pgvector)은 2편과 달라지는 AWS 고유 기능만 다룹니다. Bedrock Knowledge Bases는 이 가운데 S3 Vectors, OpenSearch, Aurora PostgreSQL, Neptune Analytics를 저장소로 쓰면서 수집과 검색을 맡는 계층이라 따로 봅니다.

Amazon Kendra와 Amazon Q Business는 각각 2026년 7월 30일과 7월 31일부터 신규 고객을 받지 않아 비교 대상이 아닙니다. RDS for SQL Server·MariaDB·Oracle의 벡터 기능은 엔진 공급사의 기능이고, Bedrock AgentCore Memory의 의미 검색은 에이전트 메모리 전용이라 역시 비교 대상이 아닙니다.¹

기능과 한도는 2026년 9월 27일 기준 AWS 공식 문서와 가격 페이지, 출시 발표에 적힌 내용을 따릅니다. AWS의 한도는 자주 바뀝니다. S3 Vectors의 질의당 최대 결과 수도 2026년 6월에 100에서 10,000으로 늘었습니다. 이 글은 성능을 측정해 비교하지 않으므로 속도 수치는 싣지 않고, 문서가 서비스 특성으로 밝힌 지연 범위만 인용합니다.

1. AWS의 벡터 검색은 어디에 들어 있을까요

AWS의 벡터 검색은 세 곳에 들어 있습니다. 벡터만 담는 저장소(S3 Vectors), 검색 엔진의 벡터 기능(OpenSearch Serverless·OpenSearch Service), 기존 데이터베이스에 붙은 벡터 기능(DynamoDB·MemoryDB·ElastiCache·DocumentDB·Neptune Analytics·Aurora)입니다.

문서가 서비스 특성으로 밝힌 지연도 자릿수가 다릅니다. S3 Vectors는 드물게 들어오는 질의에 1초 미만, 자주 들어오는 질의에 100밀리초 수준을 제시합니다. DynamoDB와 MemoryDB 문서는 한 자릿수 밀리초, ElastiCache 문서는 마이크로초 수준을 적습니다.²⁴⁵⁶

2. 인덱스와 차원은 어떻게 다를까요

인덱스 알고리즘은 사용자가 직접 고르는 곳과 그렇지 않은 곳으로 나뉩니다. MemoryDB와 ElastiCache는 FLAT과 HNSW 가운데서, DocumentDB는 HNSW와 IVFFlat 가운데서 고릅니다. S3 Vectors와 DynamoDB는 근사 최근접 이웃(ANN) 검색이라고만 밝히며 알고리즘 이름은 문서에 없습니다. OpenSearch Serverless의 NextGen 컬렉션은 엔진과 구성을 서비스가 자동으로 정합니다.

7종 가운데 사용자가 고르는 압축 선택지를 문서에 적은 곳은 OpenSearch Serverless뿐입니다. NextGen 컬렉션은 모든 인덱스를 기본 32배로 압축하고, 압축 수준을 1x·2x·8x·16x·32x 가운데서 다시 고르게 합니다. Classic 컬렉션은 FP16 스칼라 양자화, 이진 벡터, 디스크 기반 검색을 지원합니다. S3 Vectors와 MemoryDB는 float32 벡터만 받고, DynamoDB는 인덱스에 float32 정밀도로 저장합니다. S3 Vectors는 벡터 데이터를 자동으로 최적화한다고 설명하지만, 그 방식은 문서에 없습니다. 대부분의 데이터셋에서 평균 recall이 90% 이상이라고 하면서도, 대표 데이터로 직접 시험해 보라고 권합니다.³²⁴⁵

메모리 계획에서는 MemoryDB와 ElastiCache의 차이도 봐야 합니다. ElastiCache는 인덱스가 벡터 사본을 하나 더 두므로 그만큼 공간을 계획하라고 안내합니다. MemoryDB는 인덱스가 벡터 데이터의 중복 사본을 없앤다고 설명합니다.⁶⁵

생성한 뒤에 바꿀 수 없는 설정도 많습니다. S3 Vectors 인덱스의 차원·거리 척도·필터 불가 메타데이터 키와 MemoryDB HNSW의 M·EF_CONSTRUCTION은 바꿀 수 없습니다. Neptune Analytics는 그래프를 생성할 때만 벡터 인덱스를 둘 수 있고, 차원도 그때 고정됩니다. MemoryDB는 기존 클러스터에서 벡터 검색을 켤 수 없어, 검색을 켠 설정으로 새 클러스터를 만들어야 합니다. 검색을 끈 클러스터의 스냅샷으로 검색을 켠 새 클러스터를 만들 수는 있습니다.²⁵⁸

3. 한 번에 몇 개까지 받을 수 있을까요

비교 대상 7종과 Bedrock Knowledge Bases 가운데 질의당 결과 수(k)의 상한을 문서에 밝힌 곳은 S3 Vectors(10,000개)와 DynamoDB·Bedrock Knowledge Bases(100개)입니다. 나머지 서비스의 문서에는 k 상한이 없고, DocumentDB처럼 함께 묶인 파라미터가 사실상 한도가 되는 곳도 있습니다.

S3 Vectors를 직접 질의할 때와 OpenSearch Service를 거칠 때는 한도가 다릅니다. S3 Vectors의 QueryVectors는 topK를 10,000까지 받지만, OpenSearch Service 도메인의 s3vector 엔진으로 같은 벡터를 질의하면 k는 최대 100입니다. S3 Vectors의 페이지네이션 토큰은 질의 뒤 몇 분 동안 유효하고, 페이지를 받는 사이에 들어온 쓰기는 그 질의 세션에 반영되지 않습니다.²⁹

DocumentDB의 $vectorSearch는 두 조건을 합치면 ANN 결과가 최대 1,000개입니다(limit ≤ numCandidates ≤ 1,000으로 계산한 값). Bedrock Knowledge Bases의 numberOfResults는 최대값일 뿐이라 실제 결과는 더 적을 수 있고, 계층형 청크를 쓰면 검색한 자식 청크를 부모 청크로 바꿔 돌려줍니다.⁷¹⁰

4. 필터와 하이브리드 검색, 테넌트 격리는 어떻게 다를까요

2편에서 본 필터 시점(사전 필터, 사후 필터, 필터 인지 탐색)으로 보면 AWS 문서의 설명 방식이 제각각입니다. S3 Vectors는 벡터 탐색과 필터 평가를 함께 한다고 설명하고, MemoryDB와 ElastiCache 문서는 조건을 만족하는 벡터에만 KNN을 적용한다고 적습니다. DocumentDB 문서에는 벡터 질의와 메타데이터 필터를 결합하는 방법이 없습니다. 아래 표는 2편의 분류에 끼워 맞추지 않고 각 문서의 설명 방식대로 적습니다.

7종 가운데 하이브리드 검색을 문서에 적은 곳은 OpenSearch Serverless와 ElastiCache입니다. OpenSearch Serverless는 2025년 8월부터 키워드·neural·k-NN 질의를 검색 파이프라인의 정규화 프로세서로 결합합니다. 이 기능은 11개 리전에서 제공되고 서울 리전은 목록에 없으며, 임베딩 모델은 커넥터로 연결한 원격 모델만 쓸 수 있습니다. ElastiCache는 Valkey 9.0부터 전문 검색과 벡터 검색을 한 질의로 결합합니다. AWS 예시는 텍스트로 먼저 거른 뒤 KNN으로 순위를 매깁니다. S3 Vectors는 하이브리드 검색·집계·다면 검색이 필요한 워크로드에 OpenSearch 연동을 안내합니다.³⁶²

테넌트 격리 방식은 서비스 구조를 따라갑니다. S3 Vectors는 테넌트마다 벡터 인덱스를 두고 IAM·버킷 정책으로 접근을 제한하는 방식을 안내하며, 인덱스마다 고객 관리형 KMS 키를 따로 지정할 수 있습니다. OpenSearch Serverless의 collection group은 KMS 키가 다른 컬렉션끼리 컴퓨팅 자원을 함께 쓰게 하는 기능이고, AWS 발표는 테넌트마다 컬렉션을 두는 멀티테넌트 앱을 주요 용례로 듭니다. NextGen은 그룹 하나에 컬렉션을 10,000개까지 둘 수 있습니다. ElastiCache는 사용자별 에이전트 메모리를 @user_id 같은 TAG로 먼저 거른 뒤 KNN 검색을 실행하는 방식을 권합니다.²³⁶

5. 규모 한도는 어디서 막힐까요

문서화된 규모 한도는 서비스 구조를 드러냅니다. S3 Vectors는 인덱스당 벡터 수와 요청률로, OpenSearch Serverless와 DynamoDB는 인덱스 수와 용량·전송률 상한으로, 노드 기반 서비스는 인덱스 수와 샤드·노드 구성으로 한도를 적습니다.

1억 건 × 768차원이면 무엇이 달라질까요

2편과 같은 조건(벡터 1억 개, 768차원, float32)으로 크기를 계산하려 해도, 공식 산정식을 둔 곳은 S3 Vectors뿐입니다. S3 가격 페이지는 벡터 한 개의 크기를 벡터 값(차원당 4바이트), 키(글자당 1바이트), 메타데이터의 합으로 셉니다. 1억 개 × 768차원이면 벡터 값만 307.2GB입니다(계산값).

질의 요금도 이 크기를 기준으로 합니다. S3 Vectors의 질의 요금은 요청 수, 처리한 데이터(TB), 반환한 데이터(GB)로 매기고, 처리한 데이터는 인덱스의 벡터 수에 평균 벡터 크기(벡터 값·키·필터 가능 메타데이터)를 곱해 계산합니다. 이 인덱스라면 질의 한 번마다 벡터 값만으로 약 0.31TB가 처리한 데이터로 잡힙니다(계산값). 처리한 데이터의 TB당 단가는 인덱스의 벡터 10만 개·1,000만 개를 경계로 구간이 나뉘고, 벡터가 많은 구간일수록 낮습니다. 한편 문서는 질의 성능을 위해 벡터를 여러 인덱스로 나누라고 권합니다.²¹¹

DynamoDB는 검색 요금을 매기는 기준 가운데 처리한 데이터가 항목 수에 비례하지 않는다고 설명합니다. 검색 한 번에 처리하는 데이터는 항목 수의 로그 함수 꼴로 커져, 항목 수가 10,000배가 되어도 1.5배 미만입니다. 처리하는 데이터에는 항목 수보다 차원 수가 더 크게 작용합니다.¹¹

다른 서비스는 벡터 수·메모리 산정식을 문서에 두지 않습니다. MemoryDB는 벡터 1,000만 개 × 1,536차원(M=16, 비벡터 데이터 0GB)을 데이터와 인덱스 1개로 담는 데 104.9GB가 든다는 예시와 콘솔 계산기를 제시하고, ElastiCache는 에이전트 메모리 항목 하나에 약 4~6KB(차원 × 4바이트 + 메타데이터)라는 어림값을 적습니다. OpenSearch Serverless는 OCU 하나가 메모리 6GiB라는 구성만, Neptune Analytics는 그래프의 모든 데이터를 담을 수 있는 m-NCU를 골라야 한다는 조건만 밝힙니다.⁵⁶³⁸

6. 확장과 과금은 어떻게 다를까요

확장 단위와 과금 단위는 함께 봐야 합니다. 서버리스 서비스는 쓴 만큼 과금하는 대신 요청률과 용량 단위에 상한이 있습니다. MemoryDB, ElastiCache, DocumentDB는 벡터 검색에 추가 요금을 받지 않고 기존 요금 체계(노드·인스턴스 시간, 서비스별 저장·I/O 요금)를 그대로 적용합니다.^234567811

수평 확장은 MemoryDB와 ElastiCache에서 갈립니다. 같은 Valkey 계열이지만 MemoryDB의 벡터 검색은 단일 샤드로 제한되어 샤드를 늘릴 수 없고, ElastiCache는 수평·수직·복제본 확장을 모두 지원합니다. ElastiCache 문서는 샤드를 늘리면 적재 처리량은 선형으로 늘지만 질의 처리량은 줄 수 있으니, 질의 처리량은 복제본이나 CPU로 늘리라고 안내합니다. DocumentDB도 샤딩하는 Elastic 클러스터에서는 벡터 검색을 쓸 수 없습니다.⁵⁶⁷

OpenSearch Serverless의 NextGen은 최소 OCU를 0으로 둘 수 있습니다. 그룹의 모든 컬렉션에 10분 동안 요청이 없으면 0 OCU로 내려가 과금이 멈추고, 다시 요청이 오면 첫 요청에 10~30초의 지연이 생길 수 있다고 문서가 밝힙니다. Classic은 최소 OCU를 0으로 둘 수 없습니다.³

Neptune Analytics는 그래프를 일시 중지하면 컴퓨팅 요금의 10%만 내고 데이터와 설정을 유지합니다.¹¹ 벡터 임베딩 변경은 원자적이지 않아서, 질의가 나중에 실패해도 이미 쓴 임베딩은 남습니다.⁸

7. OpenSearch Service와 Aurora에서는 무엇이 달라질까요

두 서비스의 엔진 기능은 2편과 같습니다. AWS 관리형에서 쓸 때는 여기에 AWS 고유 기능과 제약이 더해집니다.

OpenSearch Service 도메인

s3vector 엔진은 벡터를 S3 Vectors 인덱스에 두고 나머지 필드는 도메인에 둡니다. OpenSearch 2.19 이상, OpenSearch Optimized 인스턴스, 최신 패치 버전이 조건이고, 가격 페이지는 벡터 1억 개를 이 엔진의 단일 샤드 k-NN 인덱스에 담는 예를 듭니다. 다만 다음 제약이 있습니다.⁹¹¹

• 질의: k는 최대 100이고, 필터는 사후 필터에 오버샘플링을 더해 적용합니다.
• 인덱스: 차원은 4,096까지, 거리 척도는 l2·cosinesimil만 지원합니다. 엔진은 인덱스를 만들 때만 지정할 수 있습니다.
• 기능: 스냅샷, UltraWarm 이동, 교차 클러스터 복제, split·shrink·clone을 쓸 수 없습니다.
• 운영: 엔진을 켜거나 끄면 도메인에 blue/green 배포가 일어납니다.

S3 Vectors의 벡터를 OpenSearch에서 검색하는 방법은 하나 더 있습니다. OpenSearch Serverless 컬렉션으로 한 번 내보내는 방식입니다. OpenSearch Ingestion 파이프라인이 데이터를 복사하며, 복사한 뒤에는 동기화되지 않습니다. 데이터가 두 곳에 있는 동안은 두 서비스 요금이 함께 나옵니다.²³

도메인의 메모리 배분은 OpenSearch Service가 정합니다. 인스턴스 RAM의 절반을 JVM 힙에 쓰고, k-NN은 기본으로 나머지 절반의 50%까지 씁니다(2편 6절의 메모리 계산에 쓴 규칙). 힙은 기본으로 32GiB까지 잡고, r7g와 OpenSearch Optimized 인스턴스는 Auto-Tune이 필요하다고 판단하거나 지원 요청을 하면 더 큰 힙을 쓸 수 있습니다.⁹

GPU 가속 인덱스 빌드는 OpenSearch 3.1 이상 도메인의 Faiss HNSW 인덱스에 쓰고, OCU 시간으로 따로 과금합니다. Bedrock Knowledge Bases의 벡터 저장소로 쓰려면 VPC 안에 있지 않은 퍼블릭 액세스 도메인이어야 합니다.⁹¹⁰

Aurora·RDS for PostgreSQL

pgvector 버전은 엔진 마이너 버전에 묶여 있습니다. 2026년 9월 기준으로 Aurora PostgreSQL 18.4·17.10·16.14·15.18·14.23과 RDS for PostgreSQL의 최신 마이너 버전이 pgvector 0.8.2를 제공합니다. 엔진을 업그레이드해도 확장 버전은 자동으로 올라가지 않습니다. 설치된 pgvector가 0.8.0 미만이라면 2편에서 다룬 iterative scan을 쓰기 전에 pgvector 확장 버전을 직접 올려야 합니다.¹²

Aurora에만 있는 기능도 벡터 검색에 쓰입니다. Optimized Reads는 NVMe를 단 R6gd·R6id(Aurora PostgreSQL 14.9·15.4·16.1 이상)와 R8gd(14.12·15.7·16.3·17.4 이상) 인스턴스에서 계층 캐시(tiered cache)로 캐시 용량을 인스턴스 메모리의 최대 5배까지 넓히며, 문서는 pgvector로 수백만 개의 임베딩을 검색하는 생성형 AI 앱을 용례로 듭니다. 계층 캐시는 I/O-Optimized 클러스터에서만 쓰입니다. Aurora ML의 aws_ml 2.0은 SQL에서 Bedrock 임베딩 모델을 호출하는 함수를 제공하지만, 결과는 vector가 아니라 float8[] 형식입니다. Aurora PostgreSQL Limitless Database도 pgvector 확장을 지원합니다.¹²

Bedrock Knowledge Bases는 Aurora PostgreSQL 클러스터를 저장소로 쓸 수 있습니다. 같은 계정의 Aurora PostgreSQL 16.1·15.4·14.9·13.12·12.16 이상 클러스터여야 하고, pgvector 0.5.0 이상과 RDS Data API, Secrets Manager 자격 증명이 필요합니다. id·embedding·chunks·metadata 열과 embedding의 HNSW 인덱스, chunks의 GIN 전문 인덱스도 미리 만들어야 합니다. 이 필드 매핑은 지식 베이스를 만든 뒤 바꿀 수 없고, Data API의 응답은 1MiB로 제한됩니다. RDS for PostgreSQL 인스턴스를 저장소로 쓰는 방법은 Bedrock 문서에 없습니다.¹²¹⁰

Aurora의 zero-ETL 통합(Redshift·SageMaker로 복제)이 지원하는 데이터 타입 목록에는 pgvector의 vector 타입이 없습니다. 지원하지 않는 타입이 있는 테이블은 동기화가 끊겨 대상에서 쓸 수 없습니다.¹²

8. Bedrock Knowledge Bases는 어디까지 대신해 줄까요

Bedrock Knowledge Bases는 벡터 저장소가 아니라, 문서를 파싱·청크 분할·임베딩해 저장소에 넣고 질의 때 검색해 주는 RAG 계층입니다. 지식 베이스는 Customer-managed와 Managed 두 종류입니다. Customer-managed는 고객이 벡터 저장소를 고르고 운영하며, Managed는 저장·색인·검색 인프라를 Bedrock이 운영합니다. Managed 지식 베이스는 2026년 6월에 정식 출시(GA)됐습니다.¹⁰

Customer-managed 지식 베이스에서는 파서, 청크 전략, 임베딩 모델, 벡터 저장소를 고른 뒤 동기화로 문서를 수집합니다. 동기화는 수동으로 시작하며, 지난 동기화 뒤에 추가·수정·삭제된 문서만 처리합니다. 청크는 기본(약 300토큰), 고정 크기, 계층형, 의미 기반, 청크 없음 가운데 고릅니다. 임베딩 모델과 저장소 설정은 지식 베이스를 만든 뒤에, 청크 설정은 데이터 소스를 만든 뒤에 바꿀 수 없습니다.¹⁰

저장소는 여덟 가지입니다. 아래 표의 빠른 생성(quick create)은 지식 베이스를 만들 때 Bedrock이 벡터 저장소를 대신 만들어 주는 콘솔 옵션입니다.¹⁰

Bedrock 사용자 가이드와 2025년 4월 발표는 위 표처럼 하이브리드 검색 지원 저장소를 적지만, API 레퍼런스는 OpenSearch Serverless만 적습니다. 빠른 생성은 콘솔에서만 쓸 수 있고, 이진 임베딩은 OpenSearch Serverless와 OpenSearch Service 도메인(OpenSearch 2.16 이상)에만 저장할 수 있습니다.¹⁰

지식 베이스의 검색 결과 수 상한은 S3 Vectors의 topK나 OpenSearch Service 도메인의 k 상한(10,000)보다 작습니다. 한도는 다음과 같습니다.¹⁰

• 검색: Retrieve는 numberOfResults를 1~100(기본 5)으로 받고, 리전별 초당 20회로 제한됩니다(조정 불가).
• 구성: 지식 베이스는 계정당 100개, 지식 베이스당 데이터 소스는 5개까지입니다(조정 불가).
• 필터: andAll·orAll로 최대 5개씩 묶을 수 있고, startsWith는 OpenSearch Serverless 저장소에서만 쓸 수 있습니다.

Managed 지식 베이스는 저장소를 고르지 않습니다. 사용자 지정 임베딩 모델은 float32·1024차원 모델만 쓸 수 있고, 관리형 재순위화가 기본으로 들어 있습니다.¹⁰ 검색은 하이브리드 방식이며, Kendra 이전 안내에 따르면 의미 검색만 하는 모드는 없습니다.¹

과금 단위는 원본 데이터 GB-월과 검색 호출 1,000회입니다. Agentic 검색은 Agentic 호출과 그 아래에서 실행된 Retrieve 호출을 각각 세고, 임베딩·재순위화 모델을 직접 고르면 그 모델 요금이 더해집니다. 지식 베이스 하나에 10TB까지 저장할 수 있습니다.¹⁰¹¹

Confluence·SharePoint·Salesforce 데이터 소스는 OpenSearch Serverless만 저장소로 쓸 수 있습니다. 그런데 Customer-managed 지식 베이스에서는 2026년 9월 30일부터 Confluence, SharePoint, Salesforce, Web Crawler 커넥터를 새로 만들 수 없습니다. 이미 만든 커넥터는 수집과 검색을 계속하며, AWS는 이 커넥터가 필요한 앱에 Managed 지식 베이스를 권합니다.¹⁰

9. 상황별로 어떤 서비스부터 볼까요

아래는 앞의 비교에서 나온 먼저 검토할 후보입니다. 순위가 아니며, 후보를 좁힌 뒤에는 1편의 순서대로 같은 데이터와 recall 목표에서 측정해야 합니다.

서울 리전(ap-northeast-2)에서 쓸 계획이라면 기능별 제공 리전을 먼저 확인해야 합니다.^2398105674

정리

AWS의 벡터 검색은 기존 데이터 서비스 안에도 들어 있습니다. 새 저장소를 고르기 전에, 이미 쓰는 서비스의 벡터 기능이 질의당 k, 필터, 확장 방식에서 요구사항을 채우는지부터 확인하면 선택지가 줄어듭니다.

서비스마다 막히는 지점이 다릅니다. S3 Vectors는 인덱스당 요청률에서 막히고, 인덱스가 클수록 늘어나는 질의 요금도 따져야 합니다. DynamoDB와 Bedrock Knowledge Bases는 질의당 결과 100개에서, MemoryDB는 단일 샤드에서 막힙니다. OpenSearch Serverless는 NextGen과 Classic 가운데 어느 세대인지에 따라 기능과 쓰기 반영 시간이 달라집니다. 서울 리전에서는 기능별 제공 여부도 함께 봐야 합니다.

참고 자료

사내 문서 조각 1억 개 가운데 사용자가 볼 수 있는 문서만 골라 관련도가 높은 50개를 가져와야 한다고 생각해 봅시다. 제품 소개의 “빠르다”는 문장보다 먼저 확인할 것이 있습니다. 권한 필터를 걸어도 50개가 다 나오는지, 인덱스가 메모리에 들어가는지, 데이터가 두 배로 늘었을 때 샤드를 늘릴 수 있는지입니다.

1편에서는 벡터 DB가 무엇을 검색하는지와 오픈소스·상용 제품의 종류, 공개 사용 지표를 읽는 법을 다뤘습니다. 이 글은 같은 제품군 12종을 기능과 한도 기준으로 비교합니다. 대상은 pgvector, Milvus, Qdrant, Weaviate, Chroma, LanceDB, Pinecone, OpenSearch, Elasticsearch, Vespa, MongoDB Vector Search, Redis입니다.

기능과 한도는 2026년 9월 27일 기준 각 제품의 공식 문서와 저장소에 적힌 내용을 따릅니다. 이 글은 성능을 측정해 비교하지 않으므로 속도 수치는 싣지 않습니다. 6절의 메모리 크기는 공식 문서의 산정식이나 사이징 안내에 값을 넣어 계산한 결과이며, 해당 절에서 계산값이라고 밝힙니다.

1. 무엇부터 정해야 할까요

제품을 비교하기 전에 요구사항을 숫자로 적어 두면 비교할 항목이 분명해집니다. 아래 항목의 순서가 이 글의 절 순서와 같습니다.

비교한 제품과 기준 버전은 다음과 같습니다. 문서가 버전을 따로 표기하지 않는 제품은 조회일의 최신 안정 릴리스를 적었습니다.

2. 인덱스와 압축은 어떻게 다를까요

벡터 인덱스는 크게 세 갈래입니다. HNSW는 메모리에 근접 그래프를 두고 탐색하므로 속도와 recall의 균형이 좋지만 메모리를 많이 씁니다. IVF 계열은 벡터를 군집으로 나누고 일부 군집만 탐색합니다. 디스크 기반 인덱스는 그래프나 군집의 대부분을 SSD나 오브젝트 스토리지에 두고, 메모리에는 압축된 부분만 올립니다.

압축(양자화)은 인덱스와 따로 봐야 합니다. float32 벡터를 8비트 정수로 바꾸는 스칼라 양자화는 크기가 4분의 1로, 차원당 1비트로 바꾸는 이진 양자화는 32분의 1로 줄어듭니다. 줄어든 정확도는 후보를 더 뽑은 뒤 원본 벡터로 다시 점수를 매기는 재채점(rescoring)으로 보완합니다.

기본 설정이 제품마다 달라서 기본값끼리 비교하면 서로 다른 압축 수준을 비교하게 됩니다. Elasticsearch는 float 벡터의 기본 인덱스로, 라이선스가 허용하면 bbq_disk를, 그렇지 않으면 384차원 이상에서 bbq_hnsw, 미만에서 int8_hnsw를 씁니다. OpenSearch의 디스크 기반 모드는 기본 압축률이 32배입니다. Weaviate의 기본 양자화는 none입니다. Milvus 문서는 AUTOINDEX를 쓰라고 안내하지만, 오픈소스 문서에는 그때 고르는 알고리즘이 나와 있지 않습니다. 1편에서 다룬 것처럼 같은 recall 목표를 정해 두고 비교해야 합니다.⁹⁸⁴²

Redis의 SVS 압축 가운데 LVQ·LeanVec은 Intel의 비공개 최적화로, Intel 플랫폼에서만 씁니다. Redis Open Source의 기본 빌드와 Intel이 아닌 플랫폼에서는 그 대신 8비트 스칼라 양자화를 쓰며, 빌드 조건은 8절에서 다룹니다.¹²

3. 한 번에 몇 개까지 받을 수 있을까요

k는 질의 한 번에 돌려받는 최근접 이웃의 수입니다. 재순위화 모델에 넘길 후보를 넉넉히 뽑거나 추천 후보를 한꺼번에 만들 때는 k가 커집니다. k에 직접 상한을 두는 제품도 있고, k와 함께 움직이는 탐색 파라미터나 응답 크기가 실제 한도가 되는 제품도 있습니다.

검색 엔진 계열은 k를 샤드마다(Vespa는 content node마다) 적용한다는 점을 기억해야 합니다. OpenSearch는 최종 개수를 size로 따로 정하고, Vespa의 targetHits는 첫 단계 랭킹에 넘길 개수입니다.⁸⁹¹⁰

pgvector는 LIMIT 500을 줘도 iterative scan을 켜지 않으면 HNSW 결과가 hnsw.ef_search 개수를 넘지 않습니다. 기본값 40이면 최대 40행입니다. ef_search를 올리거나(최대 1,000) 0.8.0부터 생긴 iterative scan을 켜야 합니다. MongoDB는 numCandidates 상한이 10,000이고 문서가 limit의 20배 이상을 권하므로, 권장 비율을 지키면 limit은 500까지입니다(10,000 ÷ 20으로 계산한 값).¹¹¹

k를 키우면 탐색 후보와 응답 크기도 함께 커집니다. 결과를 대량으로 꺼내야 한다면 페이지 단위 조회 API를 쓰는 편이 맞습니다. Weaviate는 전체를 순회할 때 cursor를 쓰라고 안내하고, Milvus 문서는 SDK의 search iterator에는 16,384 제한이 없다고 밝힙니다.⁴²

4. 필터와 멀티테넌시는 어떻게 다를까요

메타데이터 필터는 벡터 탐색과 어느 시점에 결합하느냐에 따라 결과가 달라집니다. 제품마다 부르는 이름이 다르므로, 조건을 언제 확인하는지로 나눠 보면 비교가 쉽습니다.

• 탐색 전(사전 필터): 조건에 맞는 후보 집합을 먼저 정하고 그 안에서만 찾습니다. 조건에 맞는 후보가 아주 적으면 인덱스 대신 남은 후보를 모두 비교하는 정확 검색으로 바꾸는 제품도 있습니다.
• 탐색 후(사후 필터): ANN으로 후보를 먼저 찾고 조건으로 거릅니다. 조건에 맞는 후보가 적으면 결과가 k개보다 적습니다. 그래서 k개가 찰 때까지 인덱스를 더 탐색하는 기능을 두는 제품이 있습니다.
• 탐색 중(필터 인지 탐색): 그래프를 따라가며 이웃마다 조건을 확인하고, 맞는 노드만 결과에 넣습니다. 조건에 걸려 빠지는 이웃이 많으면 따라갈 경로가 줄어듭니다. Qdrant와 Weaviate는 이때 걸러진 이웃의 이웃까지 살피는 ACORN 방식을 제공합니다.

멀티테넌시 권장 방식은 제품 구조를 따라갑니다. Qdrant는 테넌트마다 컬렉션을 만들지 말고 한 컬렉션에 모은 뒤 is_tenant 인덱스로 나누라고 안내합니다. MongoDB도 테넌트별 컬렉션·DB를 권하지 않습니다. 반대로 Weaviate는 테넌트마다 샤드를 두는 네이티브 멀티테넌시를, Pinecone은 테넌트마다 namespace를 권합니다. Pinecone 문서는 메타데이터 필터로 테넌트를 나누면 필터와 관계없이 namespace 전체를 스캔하므로 모든 테넌트의 데이터만큼 비용이 든다고 설명합니다.³¹¹⁴⁷

5. 하이브리드 검색은 어디까지 될까요

의미 검색은 표현이 달라도 관련 문서를 찾지만, 제품 코드나 약어처럼 글자가 정확히 맞아야 하는 질의에는 약합니다. 하이브리드 검색은 벡터 검색과 키워드 검색의 결과를 합쳐 이 약점을 보완합니다.

결과를 합치는 방식은 크게 두 가지입니다. RRF(Reciprocal Rank Fusion)는 점수 대신 각 목록의 순위로 1 ÷ (상수 + 순위)를 계산해 더합니다. 점수 분포가 달라도 바로 합칠 수 있고, 여러 제품이 상수 60을 기본으로 씁니다. 점수 기반 결합(선형 결합)은 두 점수를 같은 범위로 정규화한 뒤 가중합합니다. 가중치로 한쪽을 강조할 수 있지만, 정규화 방법에 따라 결과가 달라집니다. 재순위화는 결합한 뒤에 상위 후보의 순서를 모델로 다시 매기는 단계입니다.

세부 조건에서도 차이가 납니다. MongoDB의 $rankFusion·$scoreFusion은 페이지네이션을 지원하지 않고 하위 파이프라인을 차례로 실행합니다. Chroma의 Search API는 Chroma Cloud에서만 쓸 수 있습니다. Weaviate는 결합하기 전에 양쪽에서 각각 최소 offset + QUERY_HYBRID_MAXIMUM_RESULTS(기본 100)개의 후보를 가져옵니다.¹¹⁵⁴

6. 1억 건이 넘으면 무엇이 달라질까요

문서화된 한도와 대규모용 기능

셀프 호스팅 제품의 문서는 벡터 수 상한을 거의 두지 않습니다. 실제 한계는 메모리와 샤드 수, 관리형 플랜의 할당량에서 나옵니다.

1억 건 × 768차원이면 메모리는 얼마나 필요할까요

아래는 벡터 1억 개, 768차원, float32, 사본 1개(복제본 없음)를 공식 문서의 산정식에 넣어 계산한 값입니다. HNSW의 m은 여러 제품의 기본값인 16을 넣었습니다. 측정값이 아니며 메타데이터, 필터용 인덱스, 운영체제, JVM 힙은 빠져 있습니다.

원본 벡터만 300GB를 넘고, HNSW 그래프는 m=16에서 6.4~15GB 정도라서 전체 크기는 양자화가 좌우합니다. 같은 1억 건이라도 float32 HNSW는 300GB대, 8비트 양자화는 80~90GB대, 이진 양자화는 10~25GB대입니다. pgvector 값은 테이블 저장 크기이며, pgvector 문서는 HNSW 인덱스 크기의 산정식을 따로 두지 않습니다.^8934111

여기에 곱하고 더할 것이 있습니다. primary와 복제본을 합친 사본마다 같은 메모리가 필요하므로 사본 수만큼 곱합니다. Qdrant는 합계에 약 20% 여유를, MongoDB는 인덱스 전체보다 10% 이상 큰 RAM을 권합니다. JVM 기반 검색 엔진은 힙도 따로 떼어야 합니다. AWS 문서에 따르면 OpenSearch Service는 인스턴스 RAM의 절반을 JVM 힙에 쓰고, k-NN은 기본으로 나머지 절반의 50%까지 씁니다. 그래서 RAM 32GiB 인스턴스에 담을 수 있는 그래프는 8GiB입니다(32 × 0.5 × 0.5). JVM 힙은 최대 32GiB까지만 잡습니다.³¹¹⁸

관리형 서비스와 단일 노드의 사이징 안내에 1억 건을 넣으면 다음과 같습니다.⁵¹³²

Chroma 문서는 단일 노드를 보통 1천만 건 미만의 중소 규모용 배포 형태로 설명하므로, 1억 건은 이 범위를 넘습니다.

공개 벤치마크로 알 수 있는 것

1억 건 이상에서 이 12개 제품을 같은 조건으로 비교하면서, 비교 대상 벤더가 운영하지도 않는 공개 벤치마크는 찾기 어렵습니다. 공개된 대규모 벤치마크는 대부분 알고리즘 비교이거나 벤더가 만든 도구입니다.¹⁴

1억 건 이상에서는 결국 우리 데이터로 직접 재 보고 골라야 합니다. VectorDBBench의 1억 건 케이스는 시작점으로 쓸 수 있지만, 비교 대상 가운데 하나를 만든 회사가 후원하는 도구라는 점을 감안해야 합니다. 1편에서 정리한 대로 같은 데이터·필터·recall 목표에서 p95·p99 지연과 비용을 함께 기록합니다.

7. 수평 샤딩과 수직 확장은 얼마나 쉬울까요

수평 확장은 두 갈래입니다. 데이터를 샤드로 나눠 여러 노드에 분산하면 담을 수 있는 규모가 커지고 적재 속도가 빨라지며, 복제본을 늘리면 읽기 처리량이 늘어납니다. 비교할 때 가장 중요한 질문은 샤드 수를 나중에 바꿀 수 있는가입니다. 샤드 수가 생성 시점에 고정되는 제품은 처음 잡은 값이 이후의 확장 여지를 결정합니다.

Qdrant 문서는 샤드 수를 처음에 넉넉히 잡으라고 안내합니다. 노드당 샤드를 2개 이상 두고, 크게 늘어날 예정이면 12개로 시작하라고 권합니다. 12개면 노드를 1, 2, 3, 6, 12대로 늘릴 때 리샤딩 없이 고르게 나눌 수 있기 때문입니다. OpenSearch와 Elasticsearch의 split은 새 인덱스를 만들며, 목표 샤드 수는 원래 샤드 수의 배수여야 합니다.³⁸⁹

수직 확장에서는 메모리가 먼저 막힙니다. MongoDB는 인덱스 전체를, Redis는 데이터와 인덱스를 메모리에 둡니다. Weaviate 문서는 메모리가 데이터셋 크기의 상한을, CPU가 질의·적재 속도를 정한다고 설명합니다. Vespa Cloud에서 노드의 vCPU·메모리·디스크를 바꾸면 보통 새 노드를 할당해 클러스터의 노드를 모두 교체하고 문서를 재분배합니다.^1112410

8. 라이선스와 비용은 어떻게 볼까요

코어 라이선스는 1편에서 정리했습니다. 선택에 더 직접 걸리는 것은 기능 단위의 조건입니다. 같은 제품이라도 에디션이나 배포 형태, 추가 모듈에 따라 쓸 수 있는 기능이 다릅니다.

• Elasticsearch: 디스크 친화 인덱스 bbq_disk에는 Enterprise 구독이 필요하고, 기본 인덱스 종류도 라이선스에 따라 달라집니다.⁹
• Qdrant: 기존 컬렉션의 샤드 수를 바꾸는 리샤딩은 Qdrant Cloud에서만 지원합니다.³
• Chroma: RRF 하이브리드를 포함한 Search API는 Chroma Cloud 전용입니다.⁵
• MongoDB: 재순위화 단계 $rerank는 Atlas에서만 쓰는 Preview 기능이고, 전용 Search Nodes도 Atlas 기능입니다.¹¹
• Redis: LVQ·LeanVec 압축은 Intel 플랫폼 전용이고, Redis Open Source에서는 RSALv2 배포판을 Intel SVS 옵션으로 빌드해야 쓸 수 있습니다. query performance factor는 Redis Software(7.4.2-54 이상)와 Redis Cloud Pro(Redis 7.2 이상)에서 제공합니다.¹²
• LanceDB: 인덱스 자동 관리, 기본 strong consistency, 여러 노드로 나눈 구성은 Enterprise의 기능입니다.⁶
• Pinecone: 관리형 전용입니다. Dedicated Read Nodes는 Standard·Enterprise 플랜, BYOC는 Enterprise 플랜에서 씁니다.⁷
• Weaviate: 비활성 테넌트를 클라우드 스토리지로 내리는 offload에는 S3 offload 모듈이 필요합니다.⁴

관리형 서비스는 과금 단위가 서로 다릅니다. 금액은 자주 바뀌므로 단위만 정리합니다.¹⁵

과금 단위는 설계에도 영향을 줍니다. Pinecone은 질의 비용이 namespace 크기에 비례하므로(1GB당 1 RU), 테넌트를 namespace로 나누면 질의 한 번이 훑는 데이터가 줄어듭니다. Weaviate Cloud는 저장한 벡터 차원 수를, Chroma Cloud는 조회한 데이터 양을 과금 단위로 씁니다. 같은 데이터라도 차원 수와 테넌트 분할, 질의 패턴에 따라 비용 구조가 달라집니다.⁷¹⁵

9. 상황별로 어떤 후보부터 볼까요

아래는 앞의 비교에서 나온 먼저 검토할 후보입니다. 순위가 아니며, 후보를 좁힌 뒤에는 1편의 순서대로 같은 조건에서 측정해야 합니다.

정리

벡터 DB 12종은 이름보다 한도와 조건에서 더 크게 갈립니다. 필터를 언제 적용하는지, 질의당 k가 어디서 막히는지, 샤드 수를 나중에 바꿀 수 있는지, 대규모 기능이 어느 에디션에 있는지를 먼저 확인하면 후보가 줄어듭니다.

1억 건 규모에서는 제품보다 양자화와 디스크 인덱스 선택이 필요한 메모리를 좌우합니다. 같은 1억 건이 float32 HNSW로는 300GB대, 이진 양자화로는 10~25GB대가 됩니다. 중립적인 대규모 제품 벤치마크를 찾기 어려우므로, 마지막 판단은 우리 데이터와 목표 recall에서 잰 결과로 내리는 것이 좋습니다.

참고 자료

기술 문서에서 “DB 연결이 몰릴 때 응답이 느려지는 이유”를 검색한다고 생각해 봅시다. 찾고 싶은 문서의 제목은 “커넥션 풀 포화와 대기 시간 분석”일 수 있습니다. 검색어와 문서의 표현이 달라도 관련 있는 내용을 찾는 것이 의미 검색의 목표입니다.

벡터 DB는 숫자 벡터로 표현한 데이터를 저장하고 벡터 사이의 유사도로 관련 항목을 찾도록 설계된 데이터베이스입니다. 벡터와 원본 식별자, 메타데이터를 함께 관리하고 검색·필터링·갱신 기능을 제공합니다. 벡터를 만드는 임베딩은 외부 모델에 맡기기도 하고 제품에 통합된 기능을 쓰기도 합니다.¹²

RAG와 AI 에이전트가 늘면서 이 검색 기능을 서비스에 붙일 일도 많아졌습니다. 이때 후보는 전용 벡터 DB만이 아닙니다. 기존 DB의 벡터 기능, 검색 엔진, 관리형 검색 서비스까지 함께 살펴봐야 합니다.

제품·라이선스·인기도 정보는 2026년 9월 25일 기준이고 지표마다 자료 시점은 다릅니다. 사용 경험은 Stack Overflow 2025년 조사를, 인기도는 DB-Engines 2026년 9월 표를, GitHub 별 수는 2026년 9월 25일 조회값을 씁니다.

1. 벡터 DB는 무엇을 검색하나요

임베딩은 데이터를 비교할 수 있게 만든 숫자 표현입니다

임베딩(embedding)은 모델이 텍스트·이미지 같은 데이터를 숫자 배열로 바꾼 표현입니다. 검색용으로 학습된 모델은 서로 관련 있는 항목이 벡터 공간에서 가깝게 놓이도록 표현을 만듭니다. 그래서 질문을 벡터로 바꿔 문서 벡터와 비교하면, 단어가 정확히 겹치지 않아도 관련 문서를 찾을 수 있습니다.¹

예를 들어 검색 항목 하나는 다음 정보로 이루어집니다. 벡터 값은 구조를 보여 주려고 넣은 임의의 숫자입니다.

문서 조각 ID: article-42-chunk-3
벡터:        [0.12, -0.35, 0.81, ...]
원본 위치:   기술 문서 42번의 세 번째 조각
메타데이터:  tenant_id, 문서 분류, 수정 시각, 접근 권한 정보

검색할 때는 질문 벡터와 가장 가까운 항목 k개, 즉 Top-k를 가져옵니다. 가까움을 재는 척도로는 코사인 유사도, 내적, 유클리드 거리를 주로 씁니다. 척도는 임베딩 모델의 특성에 맞춰 고릅니다.³

차원 수가 같다고 해서 서로 다른 모델의 벡터를 섞어 검색할 수 있는 것은 아닙니다. 질문 벡터와 문서 벡터는 서로 호환되는 공간에 있어야 합니다. two-tower 구조처럼 질문과 문서에 서로 다른 인코더를 쓰도록 학습한 모델도 있으니, 필요한 조건은 “같은 인코더”가 아니라 “호환되는 공간”입니다. 모델·전처리·버전을 바꾸면 기존 벡터와 호환되는지 확인하고 벡터를 다시 생성할지 정해야 합니다.⁴

가까운 벡터와 좋은 검색 결과를 구분해야 합니다

거리 계산을 정확히 했다고 해서 사용자가 원하는 문서를 찾았다는 뜻은 아닙니다. 임베딩이 한국어, 사내 약어, 코드, 상품명 등을 제대로 표현하지 못하면 수학적으로 가까운 결과도 업무에는 쓸모가 없을 수 있습니다.

검색 품질은 두 가지로 나눠 평가해야 합니다.

• 검색 알고리즘의 품질: 정확한 최근접 이웃 결과를 얼마나 잘 재현하는가.
• 서비스 검색의 품질: 사람이 관련 있다고 판단한 문서를 얼마나 잘 찾아내는가.

검색 알고리즘의 품질을 높여도 서비스 검색의 품질은 임베딩 모델과 문서 분할 방식에 따라 달라집니다. 이 구분이 제품 벤치마크를 해석하는 출발점입니다.³⁴

2. 데이터가 많아지면 왜 ANN 인덱스가 필요할까요

모든 벡터와의 거리를 계산해 정렬하면 정확한 최근접 이웃을 구할 수 있습니다. 데이터가 작거나 필터로 후보가 충분히 줄어들었다면 이 방법이 맞을 수 있습니다. pgvector도 기본 동작은 정확 검색이고 인덱스를 추가하면 근사 검색을 씁니다.⁵

벡터 수와 차원, 동시 요청이 늘면 전체를 비교하는 비용이 커집니다. 이때 근사 최근접 이웃 검색(Approximate Nearest Neighbor, ANN)으로 탐색할 후보를 줄입니다. 정확 검색과 대표적인 ANN 방식을 비교하면 다음과 같습니다.⁶⁵³

ANN에서는 속도와 재현율(recall)이 맞물려 있습니다. 탐색 범위를 줄일수록 빨라지지만 정확 검색이 찾는 이웃을 놓칠 가능성도 커집니다. 정확 검색의 상위 10개 중 ANN이 9개를 찾았다면 이 질문의 ANN recall@10은 90%입니다. “정답률 90%인 챗봇”이라는 뜻이 아닙니다.⁴

제품을 비교할 때는 이 절충 때문에 같은 데이터·거리 척도·필터·recall 목표에서 잰 지연 시간을 봐야 합니다. 탐색 후보를 줄여 빨라진 설정과 후보를 늘려 정확해진 설정의 QPS를 나란히 놓으면 잘못된 결론을 내릴 수 있습니다.

3. 벡터 DB는 왜 중요해졌을까요

RAG는 검색한 자료를 모델 입력에 넣습니다

RAG(Retrieval-Augmented Generation)는 질문과 관련된 자료를 먼저 검색하고 그 자료를 질문과 함께 생성 모델에 입력하는 방식입니다. 2020년에 발표된 RAG 논문(Lewis 외)도 언어 모델에 Wikipedia의 밀집 벡터 인덱스를 결합했습니다.⁷

기술 문서 챗봇을 만든다면 다음과 같은 흐름을 생각할 수 있습니다.

색인 경로는 원본 문서를 조각으로 나눠 임베딩한 뒤 벡터·원본 ID·메타데이터를 저장합니다. 질의 경로는 질문을 임베딩해 사용자가 접근할 수 있는 문서 범위 안에서 Top-k를 찾습니다. 필요하면 키워드 검색 결과와 합쳐 순위를 다시 매깁니다. 마지막으로 관련 문서를 질문과 함께 LLM에 넘겨 답변을 생성합니다.

이 구조에서는 검색 대상 자료를 갱신하면 새 문서를 답변의 근거로 쓸 수 있습니다. 사내 규정, 제품 설명서, 장애 대응 기록처럼 조직마다 다르고 계속 바뀌는 자료에 적용할 수 있습니다. 다만 검색기가 부정확한 자료를 가져오거나 모델이 자료를 잘못 해석할 수 있으므로, RAG를 쓴다고 답변의 정확성이 보장되지는 않습니다.⁷

벡터 검색은 RAG의 검색기를 구현하는 한 가지 방법입니다. 질문에 따라 키워드 검색, SQL, API 조회를 함께 씁니다. 현재 주문 상태처럼 정확한 최신 값이 필요한 질의라면 원천 시스템을 직접 조회하는 편이 맞습니다.

텍스트 외의 데이터와 추천에도 적용됩니다

같은 검색 구조는 이미지 검색, 유사 상품 추천, 중복에 가까운 이미지 탐지 등에도 쓰입니다. 텍스트와 이미지를 함께 검색하려면 두 종류의 데이터를 호환되는 공간에 표현하는 모델이 필요합니다. 벡터로 저장했다는 이유만으로 모든 데이터 종류(모달리티)끼리 검색되는 것은 아닙니다.²⁸

검색을 지속적으로 운영해야 합니다

서비스에서는 문서 추가·삭제, 사용자별 접근 범위, 장애 복구, 검색 지연을 함께 다룹니다. 벡터 검색이 제품 기능으로 자리 잡으면서 이런 운영 작업을 DB나 관리형 서비스에 맡길 필요가 커졌다고 볼 수 있습니다. 이 요구는 임베딩 알고리즘의 발전과는 별개로 제품 선택에 영향을 줍니다.¹

4. 어떤 오픈소스와 상용 제품이 있나요

먼저 두 기준을 나눕니다. 라이선스는 소프트웨어를 쓸 수 있는 조건이고 배포 형태는 서버와 운영을 누가 맡는지에 따른 구분입니다. 오픈소스 프로젝트에도 유료 관리형 서비스가 있을 수 있습니다.

아래 표는 대표 제품을 추린 것으로, 전체 목록이나 성능 순위가 아닙니다.

오픈소스 또는 오픈소스 코어가 있는 주요 선택지

도입할 때는 사용할 릴리스와 배포판의 조건을 따로 확인해야 합니다. 아래 표의 라이선스는 2026년 9월 25일 기준 공식 저장소 기본 브랜치의 표기입니다.

2026년 9월 25일 기준 Weaviate 저장소의 LICENSE는 wl 디렉터리 밖의 코드에 BSD-3-Clause를, 그 안의 코드에 별도 Weaviate License를 적용한다고 밝힙니다. 예전 자료처럼 저장소 전체를 단일 BSD 라이선스로 표시하면 정확하지 않습니다.¹¹

FAISS는 따로 구분하는 편이 좋습니다. MIT 라이선스의 유사도 검색·클러스터링 라이브러리로, 인덱스 알고리즘을 직접 조합하거나 검색 엔진 내부를 구현할 때 활용할 수 있습니다. 인증·운영 API·데이터 관리 계층까지 갖춘 DB 제품과는 비교 범위가 다릅니다.³

주요 상용·관리형 서비스

Elasticsearch와 Redis도 벡터 검색을 제공합니다. 이 두 제품과 MongoDB는 라이선스가 버전·배포판·서비스에 따라 달라서 어느 기준의 조건인지부터 확인해야 합니다.

• Elasticsearch: 무료 소스 코드 영역에는 AGPLv3 선택지가 추가됐지만 기본 배포판의 ELv2와는 다른 조건입니다. Elastic Cloud와 상용 구독도 별개입니다.²⁰
• Redis 8 이상: AGPLv3·RSALv2·SSPLv1 중 하나를 고르는 구조입니다. 이전 버전의 BSD나 2024년의 두 가지 라이선스 체계를 그대로 적용하면 안 됩니다.²¹
• MongoDB Community Server: SSPL을 쓰는 소스 공개 모델이며 MongoDB도 SSPL이 OSI 승인을 받은 오픈소스 라이선스가 아니라고 설명합니다. Atlas 서비스 이용 조건은 이와 별개입니다.²²

5. 전 세계에서 가장 많이 쓰는 벡터 DB는 무엇일까요

공개 자료만으로는 전 세계 운영 환경의 벡터 DB 사용량 1위를 확정할 근거가 부족합니다. 설치 수, 운영 중인 클러스터 수, 이용 조직 수를 같은 기준으로 집계한 시장 전체 자료를 찾기 어렵기 때문입니다.

대신 성격이 다른 공개 지표 세 가지를 나눠 볼 수 있습니다.

사용 경험: Stack Overflow 2025 조사

Stack Overflow 2025년 조사의 AI 에이전트 데이터 저장 도구 문항은 AI 에이전트를 사용하거나 개발하는 응답자가 지난 1년간 에이전트 메모리·데이터 관리에 쓴 도구를 물었습니다. 이 문항의 응답자는 3,398명으로 전체 응답자의 6.9%입니다. 아래 표는 벡터 검색과 관련된 선택지만 발췌한 것입니다. 선택지 이름 ChromaDB는 Chroma를 가리킵니다.²³

같은 문항 전체로 보면 Redis가 42.9%, GitHub MCP Server가 42.8%로 1·2위입니다. 벡터 검색 도구가 아닌 GitHub MCP Server가 상위에 있을 만큼 이 문항의 범위는 벡터 DB보다 넓습니다. 그래서 Redis 응답률을 벡터 검색 사용률로 읽을 수는 없습니다. 한 사람이 여러 도구를 고를 수 있으므로 표의 비율을 시장 점유율처럼 더해서도 안 됩니다. Supabase(20.9%)와 pgvector처럼 사용 경로가 겹칠 수 있는 선택지를 더하면 같은 사용자를 두 번 셀 수도 있습니다.²³

전체 조사는 177개국 49,009명의 응답을 분석했고 참여자는 주로 Stack Overflow 자체 채널에서 모았습니다. 그러니 전체 조사 규모를 이 문항의 표본 수로 인용하거나, 자발적으로 응답한 표본을 세계 전체 사용자의 분포로 일반화하면 안 됩니다.²⁴

이 자료로 말할 수 있는 것은 “2025년 조사의 에이전트 데이터 관리 문항에서, 위에 발췌한 벡터 검색 도구 중 ChromaDB의 사용 경험 응답률이 가장 높았다”까지입니다.

인기도: DB-Engines 2026년 9월 자료

DB-Engines는 웹 언급, 검색 관심, 기술 토론, 채용 공고 같은 신호로 인기도를 계산합니다. 방법론 문서는 이 점수가 설치 수나 실제 사용량을 측정하지 않는다고 밝힙니다.²⁵

벡터 DBMS 목록(기본 표 26개 제품)에서 데이터 모델이 Vector 하나로만 표시된 주요 제품을 추리면 다음과 같습니다. 표의 순위는 벡터 DBMS 원표의 순위를 그대로 옮긴 것입니다.²⁶

이 조건에서는 Pinecone이 가장 높은 점수를 받았습니다. 같은 목록에서 Elasticsearch는 95.50점으로 1위, OpenSearch는 22.11점으로 2위입니다. 두 제품의 점수는 벡터 기능을 포함한 제품 전체의 인기도이므로 그 기능의 사용량으로 읽을 수 없습니다.²⁶

개발자 관심: GitHub 저장소 별 수

Stack Overflow 설문 표에 나온 오픈소스 프로젝트 6개의 별 수는 다음과 같습니다. 2026년 9월 25일 GitHub REST API로 조회한 stargazers_count 값이며 GitHub 웹 화면은 이 값을 반올림해 보여 줄 수 있습니다.

이 중에서는 Milvus가 가장 많습니다. 같은 시각에 조회한 값으로 보면 라이브러리인 FAISS는 40,978개, 검색 플랫폼인 OpenSearch와 Vespa는 각각 13,775개와 7,110개입니다. GitHub의 별은 관심 있는 저장소를 저장하거나 프로젝트에 지지를 표시하는 기능이라서 설치 수나 운영 사용, 유료 고객 수를 뜻하지 않습니다.²⁷

세 지표에서 앞선 제품은 모두 다릅니다.

세 지표는 서로 다른 질문에 답하므로 하나의 “전 세계 점유율 순위”로 합칠 수 없습니다.

6. 제품을 고를 때 무엇을 확인해야 할까요

제품 순위와 별개로, 도입 전에 다음 항목을 확인합니다.

특히 메타데이터 필터는 직접 재 봐야 합니다. pgvector 문서는 ANN 인덱스를 스캔한 뒤에 필터를 적용하는 경로를 설명하고 이때 결과가 모자라면 iterative scan으로 보완하는 방법도 안내합니다. Qdrant 문서는 payload index를 검색 그래프와 결합하는 방식을 설명합니다. 필터 문법이 비슷해도 실행 방식과 결과 특성은 다를 수 있습니다.⁵¹

저장량은 대략 계산해 볼 수 있습니다. 1,536차원 벡터 100만 개를 float32(4바이트)로 저장하면 숫자 배열만 1,000,000 × 1,536 × 4 = 6,144,000,000바이트, 약 6.14GB입니다. 단순 산술값이라 실제 DB 용량이나 RAM 요구량과는 다릅니다. 원문·메타데이터·인덱스·복제본·운영 여유 공간은 따로 더해야 합니다.

후보를 고르는 순서

후보를 비교하기 전에 평가 세트부터 준비합니다. 우리 문서를 대상으로 질의를 만들고 질의마다 관련 있는 문서를 사람이 판정해 둡니다. 같은 임베딩·차원·거리 척도로 정확 검색 결과도 구해 두면 ANN의 recall을 잴 기준이 됩니다.

이미 PostgreSQL을 운영한다면 pgvector로 요구사항을 충족할 수 있는지부터 측정해 봅니다. 검색 엔진을 운영한다면 그 엔진의 벡터·하이브리드 기능을 후보에 넣습니다. 검색 부하를 따로 확장해야 하거나 전용 기능이 필요하면 전용 벡터 DB를, 운영 부담을 줄여야 하면 관리형 서비스를 후보에 더합니다. 새 후보는 기존 스택과 같은 데이터·recall 목표로 비교합니다.

정리

벡터 DB가 중요해진 이유는 AI 서비스가 필요한 자료를 찾아 쓰는 과정에서 검색의 비중이 커졌기 때문입니다. 공개 지표는 서로 다른 것을 재므로 제품 순위도 지표마다 달라지고 어느 지표도 운영 환경의 점유율을 보여 주지 않습니다. 최종 선택은 우리 데이터에서의 검색 품질, 갱신과 권한의 정확성, 운영 가능한 성능과 비용으로 정하는 것이 좋습니다.

참고 자료