RAG INFRA · VECTOR SEARCH · ENTERPRISE SECURITY
RAG의 검색 엔진은 무엇을 써야 할까?
Azure AI Search부터 Bedrock, pgvector, Elasticsearch까지
RAG를 처음 만들 때는 검색 계층이 단순해 보인다. 문서를 쪼개고, 임베딩하고, Vector DB에 넣고, 질문과 가까운 청크를 몇 개 가져오면 끝. 그런데 실제 금융권 서비스까지 가면 검색 엔진 선택은 곧 보안 모델·권한 체계·메타데이터 설계·운영 비용·장애 대응·평가 방법을 선택하는 일이 된다. 이 글에서는 Azure AI Search, Amazon Bedrock Knowledge Bases와 OpenSearch, PostgreSQL/pgvector, Elasticsearch, 그리고 Google Cloud의 Vector Search/AlloyDB까지 같은 보험 RAG 시나리오에 올려놓고 기술적으로 비교해본다.
비교에 사용할 하나의 현실적인 보험 RAG 시나리오
추상적으로 비교하면 결국 “각 제품마다 장점이 있습니다”로 끝난다. 그래서 보험 약관 RAG를 하나 가정해보자. 동일한 상품명이라도 가입일자와 개정 시점에 따라 약관이 다르고, 특약마다 보장 조건이 다르며, 고객이 가입한 계약의 상품 코드와 판매 채널까지 알아야 정확한 문서를 찾을 수 있는 상황이다.
# 검색 전에 이미 알고 있는 고객/계약 context
retrieval_context = {
"tenant_id": "life-korea",
"product_code": "WL-2024-A",
"rider_codes": ["CI01", "SURG03"],
"contract_date": "2024-03-18",
"sales_channel": "FC",
"customer_acl_groups": ["policy-holder", "customer-app"],
"query": "암 진단을 받으면 얼마를 보장받나요?"
}이 경우 검색은 “암 진단”과 의미가 비슷한 청크를 찾는 것만으로 끝나지 않는다. 상품 코드 → 가입일에 유효한 약관 버전 → 가입 특약 → 사용자 권한을 먼저 만족한 문서 안에서 의미 검색을 해야 한다. 이처럼 structured filter가 강할수록 검색 제품의 차이가 크게 드러난다.
RAG 검색 품질은 사실 5단계 문제다
ACL · Tenant · 상품 자격
가입일 · 상품 · 버전
BM25 + Vector
Semantic/Cross Encoder
근거 · 날짜 · 원문
검색 엔진은 주로 1~3단계를 담당한다. 그런데 제품마다 강한 위치가 다르다. Azure AI Search와 Elastic은 2~3단계의 search relevance 기능이 강하고, PostgreSQL은 0~1단계의 relational filtering과 데이터 일관성이 매우 강하다. Bedrock Knowledge Bases는 전체 과정을 managed pipeline으로 단순화하는 데 강하다.
1. Amazon Bedrock Knowledge Bases — AWS의 Managed RAG 계층
Amazon Bedrock Knowledge Bases는 AWS가 제공하는 managed RAG 계층이다. 다만 이 서비스는 Azure AI Search와 정확히 같은 검색 엔진이 아니다. Bedrock Knowledge Bases는 data source를 연결하고 chunking·embedding·vector store·retrieve·rerank를 관리해주는 RAG orchestration layer다.
Managed KB와 Customer-managed KB의 차이
2026년 Bedrock은 Managed Knowledge Base와 Customer-managed Knowledge Base를 구분한다. Managed 쪽은 connector, smart parsing, auto scaling, document ACL awareness, agentic retrieval, observability 같은 기능을 더 많이 제공한다. 반대로 Customer-managed는 Aurora/OpenSearch 같은 underlying vector DB를 직접 선택·운영해 데이터 모델과 index 구성을 더 통제한다.
# Bedrock Knowledge Bases: boto3 Retrieve 개념 예시
response = bedrock_agent_runtime.retrieve(
knowledgeBaseId=KB_ID,
retrievalQuery={"text": "암 진단 보장 금액"},
retrievalConfiguration={
"vectorSearchConfiguration": {
"numberOfResults": 30,
"overrideSearchType": "HYBRID",
"filter": {
"andAll": [
{"equals": {"key": "product_code", "value": "WL-2024-A"}},
{"lessThanOrEquals": {"key": "effective_from", "value": "2024-03-18"}},
{"greaterThan": {"key": "effective_to", "value": "2024-03-18"}}
]
},
"rerankingConfiguration": {
# Bedrock reranker configuration
}
}
}
)중요한 제약이 하나 있다. Customer-managed Knowledge Base에서 `HYBRID` search override는 모든 vector store에서 똑같이 가능한 것이 아니다. AWS API 문서상 filterable text field를 둔 OpenSearch Serverless 구성이 hybrid를 지원하는 대표 경로이고, 다른 vector store 구성은 semantic-only인 경우가 있다. 즉 Bedrock이라는 상위 abstraction이 있어도 underlying store 선택이 retrieval behavior를 바꾼다.
Bedrock Managed KB의 ACL: 편하지만 authorization은 아니다
Managed KB는 SharePoint, Confluence, Google Drive 등 connector에서 document ACL을 ingest하고 query-time에 사용자 context로 filtering할 수 있다. 하지만 AWS 공식 문서도 명확히 경고한다. 이 기능은 ACL-aware filtering이지 end-user authentication 자체가 아니다. 애플리케이션이 사용자를 인증하고 검증된 identity context를 Bedrock에 전달해야 한다.
Bedrock KB의 사용감
빠르게 RAG를 만들 때는 매우 편하다. S3를 연결하고 embedding model과 vector store를 정하면 ingestion pipeline을 상당 부분 줄일 수 있다. 반대로 청킹, metadata normalization, custom reindex strategy, chunk lineage, 특수 reranking을 세밀하게 제어하려는 팀은 추상화가 답답할 수 있다. 금융권처럼 “왜 이 청크가 이 고객에게 검색됐는가?”를 추적하려면 managed convenience와 explainability 사이의 균형을 봐야 한다.
2. Azure AI Search — 검색 엔진 중심의 Managed RAG
Azure AI Search는 원래 엔터프라이즈 검색 서비스였고, 지금은 full-text, vector, hybrid, semantic ranking, integrated vectorization, document-level access control, agentic retrieval까지 RAG 기능이 깊게 들어와 있다. Azure 환경에서 이미 Entra ID, Private Link, Azure OpenAI를 사용하는 조직이라면 인프라와 보안 체계를 일관되게 묶기 쉬운 선택지다.
BM25 + HNSW + RRF
Keyword와 Vector 검색을 한 요청에서 병렬 실행하고 Reciprocal Rank Fusion으로 합친다. 상품 코드·고유명사와 자연어 의미 검색을 함께 가져가기 좋다.
Semantic Ranker
1차 retrieval 결과를 의미 기반으로 다시 순위화할 수 있다. Hybrid + semantic ranker 조합이 Azure RAG의 대표적인 강점이다.
Integrated Vectorization
Indexer + Skillset으로 문서 읽기, chunking, embedding, index projection을 서비스 안에서 자동화할 수 있다.
Private + RBAC + CMK
Private Endpoint, Entra/RBAC, Managed Identity, CMK, 문서 권한 필터를 Azure 생태계 안에서 조합하기 쉽다.
Hybrid Search가 실제로 어떻게 동작하나
Azure의 hybrid query는 text query와 vector query를 한 요청에 넣는다. text 쪽은 BM25, vector 쪽은 HNSW 또는 exhaustive kNN을 사용하고 결과를 RRF로 병합한다. 보험처럼 “CI03”, “무배당 2024 종신보험”, “2024-03-01” 같은 exact term과 자연어 질문이 섞인 데이터에는 pure vector보다 훨씬 안정적인 경우가 많다.
# Azure AI Search: Python 개념 예시
results = search_client.search(
search_text="암 진단 보장 금액",
vector_queries=[
VectorizedQuery(
vector=query_embedding,
k_nearest_neighbors=50,
fields="contentVector"
)
],
filter=(
"tenant_id eq 'life-korea' and "
"product_code eq 'WL-2024-A' and "
"effective_from le 2024-03-18T00:00:00Z and "
"effective_to gt 2024-03-18T00:00:00Z"
),
vector_filter_mode="preFilter",
query_type="semantic",
semantic_configuration_name="policy-semantic",
top=8
)금융권에서 정말 중요한 vectorFilterMode
Azure AI Search는 vector filter를 preFilter, postFilter, 그리고 preview인 strictPostFilter로 나눠 제어한다. 금융권의 eligibility·권한·상품 버전 필터라면 기본적으로 preFilter가 안전하다. preFilter는 각 shard의 HNSW traversal 중 조건을 적용해, 조건을 만족하는 문서 안에서 top-k를 찾는다.
| Azure Filter Mode | 장점 | 리스크 | 금융 RAG |
|---|---|---|---|
| preFilter | 필터 조건 안에서 top-k 보장에 유리 | 선택도가 높으면 HNSW 탐색량 증가 | 권장 |
| postFilter | latency 예측이 상대적으로 쉬움 | 필터 일치 정답을 놓칠 수 있음 | 신중 |
| strictPostFilter | unfiltered global top-k의 부분집합 보장 | 선택적 필터에서 0건 가능 | 자격/보장 검색에는 비추천 |
Integrated Vectorization: 편하지만 ‘통제권’과 맞바꾼다
Azure AI Search의 indexer는 Blob, SQL, Cosmos DB 등의 source에서 문서를 읽고 skillset을 거쳐 chunking과 embedding을 수행한 뒤 index로 보낼 수 있다. 최근에는 Text Split뿐 아니라 Document Layout/Content Understanding 계열로 구조를 보존하는 ingestion도 가능하다. 개발자가 ingestion worker, retry, vectorization queue를 직접 만들지 않아도 된다는 것이 큰 장점이다.
하지만 금융 문서에서 “청킹이 검색 정확도의 절반”이라고 생각하면 얘기가 달라진다. 상품 약관의 조-항-호 구조, 표, 부칙, 개정일, 보장표를 사업 규칙에 맞춰 보존하려면 custom ingestion pipeline이 더 낫다. 특히 chunk-level metadata를 LLM이 생성하거나, 원문 version lineage를 별도 테이블에서 관리하고 싶다면 push indexing 방식이 관리하기 편하다.
Azure 보안: PaaS 중 금융권 설계가 비교적 자연스럽다
- Inbound: Private Endpoint를 사용해 search endpoint를 VNet 내부 private IP로 노출 가능
- Outbound: Azure OpenAI 등 Azure 서비스로 shared private link 연결 가능
- Identity: API key 대신 Entra ID/RBAC + Managed Identity 구성 가능
- Encryption: 기본 AES-256 service-managed encryption + 추가 CMK layer 구성 가능
- Document-level security: security trimming field 패턴과 최신 ACL/RBAC permission enforcement 기능 존재
- Logging: diagnostic logs와 Azure Monitor 연동
2026년의 Azure: Search에서 Agentic Retrieval로
Azure AI Search는 이제 knowledge base를 top-level object로 두고 LLM query planning, sub-query decomposition, parallel retrieval, semantic rerank, answer synthesis를 묶는 agentic retrieval 기능을 제공한다. 최신 기능 중 일부는 preview API에 있으므로 금융 production에서는 기능의 GA 여부와 region·compliance boundary를 따로 확인해야 한다.
장점: Azure OpenAI, Blob, Managed Identity, Private Link와 연결할 때 전체 경험이 매끄럽고 RAG 검색의 기본기가 이미 많이 들어 있다.
단점: 검색 엔진 내부 튜닝은 Elasticsearch/OpenSearch보다 추상화되어 있고, DB처럼 복잡한 relational join을 retrieval 중 직접 수행할 수 없다. Index schema 변경도 관계형 DB migration만큼 자유롭지 않다.
3. Amazon OpenSearch Service / Serverless — AWS에서 ‘검색 엔진’을 직접 고른다면
OpenSearch는 Elasticsearch에서 갈라져 나온 Lucene 기반 검색 엔진으로, AWS에서 full-text와 vector를 한 엔진에서 다루고 싶을 때 핵심 선택지다. Bedrock KB의 vector store로도 자주 연결된다.
Vector engine 선택지가 많다
OpenSearch의 `knn_vector`는 HNSW 기반 ANN을 지원하고 Lucene, Faiss, JVector 등 engine에 따라 filtering·memory·index build 특성이 달라진다. dimension도 고차원을 지원하며, neural search pipeline을 통해 Bedrock/SageMaker embedding model과 연결할 수 있다.
PUT /policy-chunks
{
"settings": {
"index": { "knn": true }
},
"mappings": {
"properties": {
"tenant_id": { "type": "keyword" },
"product_code": { "type": "keyword" },
"content": { "type": "text" },
"embedding": {
"type": "knn_vector",
"dimension": 1536,
"method": {
"name": "hnsw",
"space_type": "cosinesimil",
"engine": "lucene"
}
}
}
}
}Hybrid Search는 Azure와 철학이 조금 다르다
OpenSearch Serverless의 hybrid search는 keyword BM25와 neural/vector query를 함께 실행하고 search pipeline에서 score normalization과 combination을 구성한다. `min_max`, `l2` normalization과 arithmetic/geometric/harmonic mean 같은 조합을 선택할 수 있어 relevance tuning 자유도가 크다. Azure의 RRF처럼 “좋은 기본값”에 가까운 경험보다 더 검색 엔지니어링스럽다.
Filtering은 engine 선택까지 영향을 받는다
OpenSearch의 efficient k-NN filtering은 Lucene HNSW, Faiss HNSW/IVF 등에서 검색 중 필터를 적용한다. 조건의 선택도에 따라 approximate graph traversal과 exact search fallback을 섞기도 한다. 즉 “filter가 있으면 무조건 vector 후보를 뽑은 뒤 거른다”가 아니다.
검색 자체를 하나의 전문 영역으로 보고 analyzer, shard, ranking pipeline, vector engine, filter behavior를 직접 튜닝할 팀. AWS-native이면서 Bedrock과 검색 계층을 느슨하게 분리하고 싶은 팀.
OpenSearch 보안
- VPC Domain: 인터넷 gateway 없이 VPC 내부 통신 가능
- Fine-Grained Access Control: cluster/index/document/field 수준 권한
- Encryption: Serverless collection은 at-rest encryption 필수, KMS CMK 선택 가능
- PrivateLink: Serverless data/control plane private access 구성 가능
- Audit: fine-grained access control과 함께 audit log를 CloudWatch Logs로 보낼 수 있음
보안 기능은 강력하지만 IAM policy, data access policy, network policy, fine-grained access control이 겹치면 처음에는 복잡하다. Azure의 “Entra + Private Endpoint + RBAC”에 익숙한 팀이라면 AWS OpenSearch의 여러 security plane이 체감상 더 손이 갈 수 있다.
4. PostgreSQL + pgvector — Vector DB가 아니라 ‘업무 데이터와 검색을 한 SQL에 넣는’ 선택
pgvector는 PostgreSQL에 vector type과 distance operator, HNSW/IVFFlat index를 추가한다. 검색 전문 엔진과 가장 큰 차이는 벡터가 관계형 데이터와 같은 transaction·schema·SQL planner 안에 있다는 점이다. 보험처럼 metadata와 business rule이 retrieval의 핵심이라면 이 특성이 매우 강력하다.
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE policy_chunks (
chunk_id bigserial PRIMARY KEY,
tenant_id text NOT NULL,
product_code text NOT NULL,
rider_code text,
effective_from date NOT NULL,
effective_to date NOT NULL,
document_id uuid NOT NULL,
section_path text,
content text NOT NULL,
metadata jsonb NOT NULL DEFAULT '{}',
embedding vector(1536) NOT NULL,
search_tsv tsvector GENERATED ALWAYS AS (
to_tsvector('simple', content)
) STORED
);
CREATE INDEX policy_vector_hnsw
ON policy_chunks USING hnsw (embedding vector_cosine_ops);
CREATE INDEX policy_business_filter
ON policy_chunks (tenant_id, product_code, effective_from, effective_to);
CREATE INDEX policy_text_gin
ON policy_chunks USING gin (search_tsv);HNSW vs IVFFlat
| pgvector Index | 장점 | 단점 | 실무 감각 |
|---|---|---|---|
| HNSW | 좋은 speed/recall trade-off, training 불필요 | build 느림, memory 사용 큼 | 대부분 production 기본 후보 |
| IVFFlat | build 빠르고 memory 적음 | training/list/probe tuning 필요, recall 불리 | 대규모 batch 구축/특정 workload |
| Exact | perfect recall | 전체 후보 distance 계산 | hard filter 후 후보가 작으면 매우 유용 |
pgvector의 핵심 함정: ANN + WHERE
pgvector 공식 문서가 강조하는 부분이다. approximate index를 사용할 때 일반적인 filtering은 index scan 이후 조건에 의해 결과가 줄 수 있다. 예를 들어 전체 데이터의 10%만 filter에 맞고 HNSW가 40개 후보를 탐색한다면 평균적으로 실제 filter match가 몇 개 안 남을 수 있다. 최신 pgvector는 iterative index scan을 통해 필요한 결과가 채워질 때까지 더 탐색할 수 있지만, 매우 선택적인 금융 filter는 처음부터 데이터 구조를 설계하는 편이 낫다.
BEGIN;
SET LOCAL hnsw.iterative_scan = strict_order;
SET LOCAL hnsw.ef_search = 120;
SELECT chunk_id, document_id, content,
1 - (embedding <=> :query_vector) AS similarity
FROM policy_chunks
WHERE tenant_id = :tenant_id
AND product_code = :product_code
AND effective_from <= :contract_date
AND effective_to > :contract_date
ORDER BY embedding <=> :query_vector
LIMIT 30;
COMMIT;상품별 데이터가 충분히 크다면 partial HNSW index나 partitioning도 고려할 수 있다. pgvector 문서는 multitenancy에서 tenant를 공유 ANN index 하나에 섞으면 다른 tenant의 vector가 recall과 speed에 영향을 줄 수 있으므로 partition/separate table을 고려하라고 안내한다. 이건 금융 multi-tenant 플랫폼에서 매우 중요한 포인트다.
PostgreSQL Hybrid Search는 “직접 만들 자유”가 장점이자 단점
PostgreSQL은 `tsvector`/`tsquery` 기반 full-text search를 기본 제공한다. vector score와 text rank를 별도로 계산한 뒤 RRF 또는 weighted fusion을 SQL에서 직접 만들 수 있다. 하지만 Azure/Elastic처럼 ready-made semantic ranker가 따라오는 것은 아니다.
WITH eligible AS MATERIALIZED (
SELECT *
FROM policy_chunks
WHERE tenant_id = :tenant
AND product_code = :product
AND effective_from <= :contract_date
AND effective_to > :contract_date
),
vector_rank AS (
SELECT chunk_id,
row_number() OVER (
ORDER BY embedding <=> :qvec
) AS r
FROM eligible
ORDER BY embedding <=> :qvec
LIMIT 50
),
text_rank AS (
SELECT chunk_id,
row_number() OVER (
ORDER BY ts_rank_cd(search_tsv, websearch_to_tsquery('simple', :query)) DESC
) AS r
FROM eligible
WHERE search_tsv @@ websearch_to_tsquery('simple', :query)
LIMIT 50
)
SELECT e.chunk_id, e.content,
COALESCE(1.0 / (60 + v.r), 0) +
COALESCE(1.0 / (60 + t.r), 0) AS rrf_score
FROM eligible e
LEFT JOIN vector_rank v USING (chunk_id)
LEFT JOIN text_rank t USING (chunk_id)
WHERE v.chunk_id IS NOT NULL OR t.chunk_id IS NOT NULL
ORDER BY rrf_score DESC
LIMIT 20;금융권에서 pgvector가 유독 강해지는 순간: RLS
PostgreSQL Row-Level Security는 query마다 애플리케이션이 security filter string을 잘 조립하기를 기대하는 대신, DB table 자체에 “이 role/session은 어떤 row를 볼 수 있는가”를 policy로 걸 수 있다.
ALTER TABLE policy_chunks ENABLE ROW LEVEL SECURITY;
CREATE POLICY tenant_isolation
ON policy_chunks
FOR SELECT
USING (
tenant_id = current_setting('app.tenant_id', true)
);물론 RLS가 만능은 아니다. connection pool의 session context 설정, table owner/superuser bypass, policy test를 엄격하게 다뤄야 한다. 하지만 authorization과 business filter가 검색의 핵심일수록 “retrieval query와 data permission이 같은 SQL planner 안에 있다”는 건 강력하다.
Cloud PostgreSQL 선택지
- Azure Database for PostgreSQL Flexible Server: pgvector + Entra authentication + Private Link + azure_ai extension/Managed Identity 조합
- Amazon Aurora PostgreSQL: pgvector를 Bedrock Knowledge Base의 vector store로 직접 사용 가능. RDS Data API/Secrets Manager와 연동
- Google AlloyDB: pgvector compatibility에 Google ScaNN vector index를 추가해 relational + 고성능 vector 검색을 노림
5. Elasticsearch — 검색 품질을 가장 깊게 파고들고 싶을 때
Elasticsearch는 Lucene 기반 full-text search의 역사가 길다. analyzer, BM25, synonym, field boosting, query DSL, aggregation에 vector search가 결합되면서 “검색팀이 정말 검색을 튜닝한다”는 상황에서는 여전히 매우 강력하다.
Dense vector뿐 아니라 sparse semantic도 중요하다
Elastic은 `dense_vector` 기반 kNN뿐 아니라 ELSER라는 learned sparse encoder를 제공한다. sparse retrieval은 query/document를 가중 term space로 확장하기 때문에 keyword search의 explainability와 semantic matching 사이에서 흥미로운 위치를 차지한다. 다만 Elastic 공식 문서상 ELSER는 영어 문서에 특히 권장되고, 비영어에는 E5 같은 multilingual dense model이 더 적합한 경로로 안내된다.
PUT policy-index
{
"mappings": {
"properties": {
"tenant_id": { "type": "keyword" },
"product_code": { "type": "keyword" },
"content": { "type": "text" },
"embedding": {
"type": "dense_vector",
"dims": 1536,
"similarity": "cosine",
"index": true
}
}
}
}approximate kNN은 HNSW를 사용하며 `num_candidates`가 대표적인 speed/recall knob다. 후보를 더 넓게 보면 recall이 좋아지지만 latency가 늘어난다. quantized vector에서는 oversampling 후 original float vector로 rescore하는 전략도 제공한다.
Elastic의 필터도 위치가 중요하다
Elasticsearch kNN query 내부의 `filter`는 approximate kNN 중 pre-filter로 적용돼 k개의 filter-matching result를 확보하도록 동작한다. 반면 Query DSL tree 바깥의 일반 filter는 post-filter가 될 수 있다. 코드가 비슷해 보여도 결과 의미가 다르기 때문에 금융 eligibility filter는 반드시 retrieval stage 내부에서 적용되는지 확인해야 한다.
POST policy-index/_search
{
"knn": {
"field": "embedding",
"query_vector": [/* embedding */],
"k": 30,
"num_candidates": 200,
"filter": {
"bool": {
"must": [
{ "term": { "tenant_id": "life-korea" } },
{ "term": { "product_code": "WL-2024-A" } }
]
}
}
}
}`semantic_text`: 편의성 방향으로도 진화했다
과거 Elastic semantic search는 inference endpoint, ingest pipeline, vector mapping을 직접 맞춰야 했다. 현재 `semantic_text` field는 model에 맞는 mapping과 embedding generation, chunking을 상당 부분 자동화한다. 즉 Elastic도 점점 Azure integrated vectorization이나 managed RAG 제품처럼 개발자 경험을 단순화하고 있다.
Elastic 보안: search 자체의 세밀함은 강하지만 라이선스를 확인해야 한다
role 기반 index 권한에 더해 document-level security와 field-level security를 지원한다. audit logging도 가능하다. 다만 특정 security/ML 기능은 subscription tier에 따라 달라질 수 있으므로 “기술적으로 지원한다”와 “우리 라이선스에서 쓸 수 있다”를 분리해 확인해야 한다.
장점: 검색 품질을 실험할 수 있는 knob가 많고 BM25·dense·sparse·RRF·rerank를 하나의 search stack에서 다루기 좋다.
단점: shard/segment/memory/index lifecycle까지 이해하기 시작하면 플랫폼 운영 난도가 빠르게 올라간다. 금융권에서 self-managed라면 patching·audit·backup·capacity planning도 모두 책임져야 한다.
6. Google Cloud도 보면 그림이 완성된다 — Vector Search 2.0 / Agent Search / AlloyDB
Google Cloud도 단일 “AI Search” 하나가 아니라 계층이 나뉜다. 2026년 Vector Search 2.0은 collection, auto-embedding, vector + full-text hybrid search, built-in semantic reranking을 하나의 retrieval engine으로 묶는 방향으로 진화했고, 상위에는 Agent Search/RAG 계열, 관계형 쪽에는 AlloyDB AI가 있다.
AlloyDB: PostgreSQL을 유지하면서 ScaNN을 추가
AlloyDB AI는 pgvector의 HNSW 호환성을 유지하면서 Google의 ScaNN vector index를 추가한다. 즉 pgvector의 SQL 데이터 모델을 좋아하지만 vector workload를 더 크게 가져가고 싶은 팀에게 흥미로운 선택지다. Private Service Connect와 IAM, Google Cloud security boundary를 함께 설계할 수 있다.
VPC Service Controls는 금융권에서 독특하게 강한 기능
Google Cloud의 VPC Service Controls는 IAM과 별개로 managed service 주변에 service perimeter를 만들어 data exfiltration risk를 줄이는 보안 계층이다. 단순 “private IP”를 넘어 credential이 탈취되더라도 허용되지 않은 perimeter 밖 리소스로 데이터를 복사하는 동작을 막는 것이 목적이다. 대규모 금융 데이터 플랫폼에서는 꽤 매력적인 control이다.
7. 가장 궁금한 비교: 한 표로 보면?
| 항목 | Azure AI Search | Bedrock KB | OpenSearch | PostgreSQL/pgvector | Elasticsearch |
|---|---|---|---|---|---|
| 정체성 | Managed search PaaS | Managed RAG layer | Search engine | Relational DB + vector | Search engine/platform |
| Vector | HNSW/eKNN | Underlying store 의존 | HNSW/IVF 등 | HNSW/IVFFlat/Exact | HNSW/quantized variants |
| Keyword + Vector | 매우 쉬움, RRF | store/config 의존 | 강력, pipeline 조정 | 직접 SQL/RRF 구현 | 매우 강력 |
| Reranking | Semantic Ranker | Bedrock reranker | pipeline/model 조합 | 외부 model 직접 | retriever/rerank 기능 풍부 |
| Structured Filter | 좋음, preFilter 지원 | metadata filter | 좋음, engine별 효율 필터 | 최강, SQL/JOIN | 좋음, kNN pre-filter |
| Document ACL | security trimming + native preview 기능 | Managed KB ACL-aware | FGAC document/field | RLS/custom schema | DLS/FLS |
| Ingestion 자동화 | 높음 | 매우 높음 | 중간 | 낮음, 직접 구현 | 중~높음 |
| 검색 튜닝 자유도 | 중간 | 낮~중 | 높음 | SQL 쪽 높음 | 매우 높음 |
| 운영 부담 | 낮음 | 가장 낮음 | 중간 | 중~높음 | 중~높음 |
| Cloud Lock-in | 높음 | 높음 | 중간 | 낮음 | 중간 |
| 폐쇄망/자체호스팅 | PaaS 중심 | AWS managed | 가능 | 매우 유연 | 가능 |
※ 위 표는 제품의 절대 점수가 아니라 “RAG retrieval layer를 직접 설계하는 관점”의 비교다. Bedrock KB는 underlying vector store에 따라 일부 특성이 달라진다.
8. 보안만 따로 비교하면 금융권의 우선순위가 달라진다
보안은 4층으로 봐야 한다
많은 RAG 설계가 ①과 ②만 보고 “private하니까 안전하다”고 결론낸다. 하지만 실제 정보 유출은 ③에서 발생하기 쉽다. 한 index 안에 영업직원용 문서, 고객용 문서, 내부 underwriting 문서가 섞여 있는데 retrieval이 사용자 권한을 모르고 top-k를 만든다면 private endpoint는 아무 도움이 되지 않는다.
9. 검색 품질: Vector DB 이름보다 Retrieval Recipe가 더 중요하다
실무에서 Azure AI Search → PostgreSQL로 옮겼다고 갑자기 정확도가 올라가거나, Elasticsearch를 쓴다고 hallucination이 사라지는 일은 없다. RAG 품질은 검색 엔진보다 아래 조합의 영향을 더 크게 받는 경우가 많다.
- 문서를 어떻게 파싱하고 구조를 보존했는가
- chunk boundary가 의미 단위를 보존하는가
- embedding model이 한국어 금융 용어를 얼마나 잘 표현하는가
- metadata가 실제 업무 규칙을 표현하는가
- keyword와 vector를 어떻게 fusion하는가
- top-k를 얼마나 넓게 잡고 reranker가 몇 개를 다시 보는가
- query rewrite가 약어, 상품코드, 동의어를 잘 처리하는가
- gold set이 실제 현업 질문을 반영하는가
논문 관점: 왜 Hybrid + Rerank가 계속 살아남나
RAG 원 논문은 parametric memory와 non-parametric memory를 결합하는 틀을 제시했고, HNSW는 대규모 approximate nearest neighbor search의 기반이 됐다. 이후 BEIR 같은 heterogeneous retrieval benchmark는 어떤 단일 dense retriever도 모든 도메인에서 압도적이지 않다는 사실을 보여주는 방향의 연구를 강화했다. ColBERT 계열은 하나의 문서를 단일 vector 하나로 압축하기보다 token-level late interaction으로 더 세밀한 matching을 수행한다.
실무적인 메시지는 단순하다. “Dense vector 하나가 검색의 최종형”이 아니다. exact lexical signal, sparse semantic, dense vector, structured filter, reranking이 서로 다른 오류를 보완한다. 그래서 Azure·Elastic·OpenSearch가 모두 hybrid를 중요한 1급 기능으로 두는 것이다.
10. 사용감: 개발자가 실제로 느끼는 차이
| 상황 | 가장 편한 선택 | 왜? |
|---|---|---|
| Azure 기반 사내 문서 챗봇을 빨리 출시 | Azure AI Search | Blob/AOAI/Managed Identity/Private Link와 자연스러운 연결 |
| AWS 기반, ingestion부터 최대한 managed | Bedrock Managed KB | connector·parsing·retrieval·agentic 기능을 서비스가 관리 |
| 검색 relevance를 전문적으로 튜닝 | Elasticsearch / OpenSearch | analyzer, ranking, vector engine, sparse/dense 조합 자유도 |
| 보험 약관 + 가입정보 + 날짜/상품 필터가 핵심 | PostgreSQL/pgvector 또는 Azure AI Search preFilter | structured eligibility가 semantic similarity보다 먼저이기 때문 |
| 폐쇄망/온프레미스 portability | PostgreSQL / OpenSearch / Elasticsearch | cloud-specific managed service 의존을 줄일 수 있음 |
11. 비용은 단순히 “Vector DB 가격”으로 보면 안 된다
가격표의 월 비용만 비교하면 pgvector가 싸고 managed search가 비싸 보일 수 있다. 하지만 실제 TCO에는 검색 cluster의 replica, ingestion compute, embedding API, semantic reranker, network egress, backup, monitoring, 운영 인력이 모두 들어간다.
12. 금융권이라면 제품보다 먼저 결정할 Architecture Decision
Decision 1 — “문서 검색”인가, “업무 규칙이 들어간 검색”인가?
단순 사내 규정·매뉴얼 검색이면 Azure AI Search나 Bedrock KB 같은 managed service가 생산성이 높다. 반대로 “이 계약이 이 약관의 적용 대상인가?”를 판단해야 한다면 PostgreSQL처럼 업무 데이터와 가까운 곳이 유리해진다.
Decision 2 — Authorization source of truth는 어디인가?
Entra group, IAM identity, SharePoint ACL, DB row ownership 등 어느 시스템이 최종 권한을 갖는지 먼저 정한다. 그 다음 Search index가 그 permission을 복제할지, query-time에 원본을 검증할지 선택한다.
Decision 3 — Index는 원본 데이터인가, 파생 캐시인가?
금융 시스템에서 검색 index를 source of truth로 만들면 reconciliation과 감사가 어려워진다. 원본 문서/계약 DB가 source of truth이고 vector/search index는 재생성 가능한 derived serving layer로 보는 편이 운영상 안전하다.
Decision 4 — Approximate search가 정말 필요한가?
사용자 계약 정보로 먼저 3,000개 청크까지 좁혀진다면 HNSW를 쓸 이유가 크지 않을 수 있다. exact cosine search는 recall 100%이고 운영 knob가 줄어든다. “Vector DB를 쓰니까 ANN”이 아니라 후보 집합 크기와 latency SLO로 판단해야 한다.
Authorization → Eligibility → Retrieval → Rerank → Generation 순서를 바꾸지 않는다. 검색 engine의 semantic score가 아무리 높아도 권한·상품·기간 조건보다 우선할 수 없다.
13. 그래서 무엇을 고를까 — 현실적인 추천
Azure AI Search + Azure OpenAI는 우선 검토할 만한 조합이다. Hybrid + semantic ranker + preFilter + Private Endpoint + Managed Identity를 기본선으로 두고, ingestion은 처음부터 custom pipeline 여부를 검토한다.
Amazon Bedrock Managed Knowledge Bases는 우선 검토할 만하다. 다만 document ACL은 application authentication을 대체하지 않는다는 점을 architecture review에 명시한다. 검색을 더 세밀하게 통제해야 하면 Customer-managed KB + OpenSearch/Aurora로 내려간다.
PostgreSQL/pgvector를 진지하게 검토할 가치가 크다. 특히 product/version/date/tenant 조건이 semantic retrieval보다 강한 경우. 단, ANN filtered recall과 index memory를 benchmark하고 외부 reranker를 붙인다.
Elasticsearch 또는 OpenSearch. lexical analyzer, sparse/dense retrieval, score fusion, shard/index 전략을 직접 실험할 수 있는 자유도가 크다.
14. 벤치마크는 이렇게 해야 공정하다
제품 비교 POC에서 가장 흔한 오류는 Azure는 hybrid+semantic ranker를 켜고 pgvector는 pure cosine top-5만 돌린 뒤 “Azure가 정확하다”고 결론내는 것이다. 또는 반대로 PostgreSQL은 정교한 metadata filter를 쓰고 Azure에는 filter 없이 vector only를 보내는 식이다.
| 평가축 | 반드시 측정할 것 |
|---|---|
| Retrieval Quality | Recall@k, nDCG@k, MRR, answer-support coverage |
| Filter Correctness | 권한/상품/날짜 조건 위반 0건, selective filter에서 결과 누락률 |
| Latency | P50/P95/P99 retrieval, rerank 포함 end-to-end TTFT |
| Ingestion | documents/s, reindex time, failed chunk retry, schema migration |
| Operations | backup/restore, scale-out, index rebuild, monitoring, 장애 시 복구시간 |
| Security | public path 존재 여부, secretless auth, CMK, auditability, document authorization |
공식 문서 / 논문
- Microsoft — Azure AI Search Hybrid Search
- Microsoft — Azure AI Search Vector Query Filters
- Microsoft — Integrated Vectorization
- Microsoft — Azure AI Search Security Overview
- Microsoft — Document-level Access Control
- Microsoft — Azure AI Search Agentic Retrieval Knowledge Base
- AWS — Amazon Bedrock Knowledge Bases
- AWS — KnowledgeBaseVectorSearchConfiguration
- AWS — Amazon OpenSearch Vector Search
- AWS — OpenSearch Serverless Neural/Hybrid Search
- AWS — Fine-grained Access Control
- AWS — Aurora PostgreSQL as Bedrock Knowledge Base
- pgvector — Official Repository / HNSW, IVFFlat, Filtering
- PostgreSQL — Full Text Search
- PostgreSQL — Row Level Security / CREATE POLICY
- Elastic — Vector Search
- Elastic — Hybrid Search
- Elastic — kNN Query / Pre-filter vs Post-filter
- Elastic — Document & Field Level Security
- Google Cloud — Vertex AI / Vector Search Release Notes
- Google Cloud — AlloyDB Vector Search
- Google Cloud — VPC Service Controls
- Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
- Malkov & Yashunin — Efficient and Robust Approximate Nearest Neighbor Search Using HNSW
- Thakur et al. — BEIR: A Heterogeneous Benchmark for Zero-shot Evaluation of Information Retrieval Models
- Khattab & Zaharia — ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction
※ 이 글은 2026년 9월 기준 공식 문서의 현재 기능을 토대로 작성했다. Preview 기능, region 지원, 보안/규정 준수 범위, 라이선스와 가격은 변경될 수 있으므로 실제 금융 production 도입 전에는 해당 리전의 GA 상태와 계약 조건을 다시 확인해야 한다. 특히 검색 성능 비교는 동일한 embedding·chunking·filter·candidate size·reranking 조건에서 자체 gold set으로 검증해야 한다.
※ 근데 정말, 다른 금융권 분들 혹시 계시면 뭘로 구현하고 계신지 제발 알려주세요!!! 너무 궁금함. (특히 Azure 사용하시는 현업분들!!!!)