【2026년 여름 최신판】 여러분에게 Google Cloud에서의 RAG·Embedding 최강 조합을 알려드리고 싶었습니다.

안녕하세요, 주식회사 FP16의 니노미야입니다.

지난번에는 일본어 RAG의 Embedding 모델을 6가지 구성·2000문항으로 비교했습니다.

이번에는 그 후속편입니다.

Embedding 모델 단독의 정밀도는 어느 정도 파악되었습니다. 그렇다면, 실제로 Google Cloud에서 RAG를 만들 때, 구성으로는 무엇을 선택해야 할까요?

Cloud SQL + pgvector로 충분할까요? AlloyDB로 해야 할까요? Vertex AI Search, 지금은 Agent Search라고 불리는 것에 전부 맡기는 것이 좋을까요? Document AI는 넣어야 할까요? Reranking은 필요한가요? 그리고 은근히 매우 중요한 이야기로, 나중에 구성을 변경했을 때 Embedding을 전부 다시 만들어야 하는가 하는 점도 있습니다.

이 부분들이 생각보다 정리되어 있지 않았습니다.

그래서 이 기사에서는 Google Cloud에서 RAG를 만들 때의 구성을 상당히 실무적인 관점에서 정리합니다.

참고로, Google Cloud의 AI / Agent 계열 서비스는 명칭·SKU·가격이 빈번하게 변경되기 때문에, 본 기사의 가격과 서비스명은 2026-05-26 시점의 공식 문서를 기준으로 하고 있습니다. 견적을 낼 때는 반드시 최신 Pricing page와 SKU를 확인해 주세요.

TL;DR

먼저 결론부터 말씀드립니다.

소~중규모로 저렴하게 시작한다면, 우선 Cloud SQL for PostgreSQL + pgvector가 가장 이해하기 쉽습니다.
PostgreSQL 호환성을 유지하면서, 더 높은 부하·저지연(Low Latency)·장기 운용에 맞춘다면, 다음 마이그레이션 대상은 AlloyDB + AlloyDB AI / ScaNN이 자연스럽습니다. Cloud SQL이 운영 환경(Production)에서 안 된다는 뜻이 아니라, 성능·스케일·운용 여력을 어디까지 고려하느냐의 문제입니다.
검색·생성 답변·Managed Indexing을 통째로 맡기고 싶다면 Agent Search입니다. 다만 쿼리(Query) 과금이 적용되므로, 대량 이용 시 비용이 높아지기 쉽습니다.
높은 QPS·저지연·대규모 Vector Serving이 필요하다면 Vertex AI Vector Search / Agent Retrieval입니다. Classic Vector Search에서는 소스 DB(Source DB)와의 동기화 설계가 필요해지기 쉬운 반면, Vector Search 2.0 / Agent Retrieval에서는 페이로드(Payload) 통합 관리도 진행되고 있으므로, 데이터의 진실의 원천(Source of Truth)을 어디에 둘지를 요건에 따라 결정합니다.
BigQuery에 데이터가 이미 있는 분석계 RAG나 평가 기반이라면 BigQuery vector search가 적합합니다.
Firestore 내의 문서를 가볍게 시맨틱 검색(Semantic Search)하고 싶을 뿐이라면 Firestore vector search도 방법입니다. 다만 범용 RAG 기반으로서는 한정적입니다.
실제로 FAQ·PDF 매뉴얼·화면 슬라이드를 포함하는 업무 매뉴얼 계열 코퍼스(Corpus)로 18문항 벤치마크를 실시했습니다. FAQ를 포함했을 때 A/B/C 모두 Source Hit@3는 100%, B/C는 MRR 1.000이었으나, C는 p95 latency가 33.375s까지 늘어났습니다.

개인적인 기본값(Default)은 현재 이렇습니다.

처음에는 Cloud SQL + pgvector로 만들고, 평가와 쿼리량을 보면서 필요하다면 AlloyDB로 옮길 수 있는 설계로 해둔다.

Cloud SQL + pgvector가 운영 환경에서 사용할 수 없다는 뜻은 아닙니다. 소~중규모 RAG에서 QPS나 지연 시간 요건이 그렇게 엄격하지 않은 경우에는 Cloud SQL + pgvector로도 충분히 현실적입니다. 반면, RAG가 프로덕트의 중심이 되고 청크(Chunk) 수·동시 접속·지연 시간 요건·필터링 포함 검색이 무거워지면, 인덱스 설계 및 DB 부하 튜닝이 중요해집니다. 그 단계에서는 PostgreSQL 호환성을 유지하면서 벡터 검색이나 AI 기능에 더 강력한 AlloyDB + AlloyDB AI / ScaNN을 검토할 가치가 있습니다.

갑자기 전부를 Agent Search에 맡기는 것은 사내 검색이나 웹사이트 검색으로는 상당히 좋습니다. 반면, 독자적인 청킹(Chunking), 평가, Rerank, DB 설계를 세밀하게 다루고 싶은 RAG에서는 Cloud SQL / AlloyDB 계열이 설명하기 쉬운 상황이 많을 것이라 생각합니다.

이 기사에서 다루는 내용

RAG는 "Embedding 모델은 뭐가 좋지?"만으로는 결정되지 않습니다.

적어도, 이것만큼은 결정해야 합니다.

문서를 어떻게 읽을 것인가
어떻게 청크 (chunk)로 나눌 것인가
어떤 임베딩 (Embedding) 모델을 사용할 것인가
어디에 벡터 (vector)를 저장할 것인가
어떤 인덱스 (index)로 검색할 것인가
메타데이터 필터링 (metadata filtering)을 어떻게 할 것인가
리랭킹 (Reranking)을 넣을 것인가
어떤 LLM으로 답변을 생성할 것인가
인용 (citation)을 어떻게 출력할 것인가
평가 데이터를 어떻게 만들 것인가
나중에 구성을 변경했을 때, 무엇을 다시 만들어야 하는가

이 마지막인 "무엇을 다시 만들어야 하는가"가 특히 고객과의 대화에서 중요해집니다.

"지금은 A안으로 저렴하게 시작하고 싶습니다. 하지만 나중에 B안으로 바꾸고 싶어지면 전부 버려야 하나요?"

이 질문에 대답할 수 없는 구성은, 아무리 정밀도가 높아도 제안하기 어렵습니다.

Google Cloud의 RAG 선택지

먼저 전체 모습입니다.

선택지	대략적인 용도	장점	주의점
Cloud SQL + pgvector	소~중규모 RAG	저렴함, 이해하기 쉬움, PostgreSQL로 완결	대규모 벡터 (vector) 검색은 튜닝이 필요
...
여기서부터 각각 살펴보겠습니다.

Cloud SQL + pgvector

Cloud SQL for PostgreSQL에서는 PostgreSQL 확장 기능 (extension)으로서 pgvector를 사용할 수 있습니다.

이 구성의 장점은 매우 단순합니다.

PostgreSQL에 문서 청크 (document chunk), 메타데이터 (metadata), 테넌트 (tenant) 정보, 임베딩 (embedding)을 전부 둘 수 있습니다. 앱 측면에서 보면 일반적인 DB입니다. RAG 전용의 별도 서비스를 늘리지 않아도 됩니다.

예를 들어, 다음과 같은 테이블을 가질 수 있습니다.

CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE rag_chunks (
id UUID PRIMARY KEY,
...

pgvector에서 HNSW / IVFFlat 인덱스 (index)를 사용할 경우, vector 타입의 인덱스 차원 상한에 주의해야 합니다. 이 기사에서는 text-only인 Gemini Embedding, 주로 gemini-embedding-001 상당을 전제로 하고 있습니다. gemini-embedding-001은 기본값이 3072차원이지만, Cloud SQL + pgvector로 다루는 예시에서는 output_dimensionality를 통해 1536 등으로 낮추어 저장 및 인덱싱 (index)하는 구성으로 하고 있습니다. 1536으로 설정한 이유는 복사해서 붙여넣기 쉬운 안전한 예시로 만들기 위함입니다. 실제 프로젝트에서는 채택할 Cloud SQL / AlloyDB의 PostgreSQL 버전, pgvector 버전, vector / halfvec의 대응 상황을 최신 문서에서 확인하고, 3072차원을 유지할 수 있다면 굳이 낮추지 않는 판단도 있습니다. 3072차원을 유지하고 싶다면, Cloud SQL / AlloyDB 측의 pgvector 버전이 대응하는지 확인한 후 halfvec(3072) + halfvec_cosine_ops를 검토합니다.

검색은 다음과 같습니다.

SELECT
id,
title,
...

이것으로 충분한 케이스가 많습니다.

특히 첫 MVP나 소~중규모의 RAG라면, Cloud SQL + pgvector는 상당히 강력합니다. 저렴하고, 이해하기 쉬우며, 나중에 AlloyDB로 옮겨갈 수 있는 길도 있습니다.

하지만 만능은 아닙니다.

데이터가 커지거나, QPS가 올라가거나, 메타데이터 필터링 (metadata filtering)이 복잡해지면 인덱스 설계 (index design)나 쿼리 설계 (query design)가 중요해집니다. pgvector의 HNSW나 IVFFlat을 어떻게 사용할지, 필터 (filter)와 벡터 검색 (vector search)을 어떻게 양립할지, VACUUM이나 인덱스 재구축 (index rebuild)을 어떻게 관리할지. 이 영역은 일반적인 DB 운영의 세계입니다.

그래서 저라면 이렇게 생각하겠습니다.

우선 Cloud SQL + pgvector로 만든다. 단, 나중에 AlloyDB로 도망갈 수 있도록 스키마 (schema) · 청킹 (chunking) · 임베딩 메타데이터 (embedding metadata)를 깔끔하게 관리해 둔다.

이것이 가장 현실적입니다.

AlloyDB + AlloyDB AI / ScaNN

다음은 AlloyDB입니다.

AlloyDB는 PostgreSQL 호환 managed database입니다. Google Cloud 상에서 PostgreSQL 계열의 운영(Production) DB를 강력하게 사용하고자 한다면, Cloud SQL의 상위 선택지로 고려됩니다.

RAG 관점에서 중요한 것은 AlloyDB AI와 vector search 관련 기능입니다.

AlloyDB에서는 ScaNN, HNSW, IVF 등의 vector index 전략을 선택할 수 있습니다.

간략히 말하자면, HNSW / IVF / ScaNN은 모두 "전체 데이터를 전수 조사하지 않고, 유사한 벡터를 고속으로 찾는 것을 위한 근사 최근접 이웃 검색 (Approximate Nearest Neighbor Search) 인덱스"입니다.

HNSW: 그래프 구조를 사용하여 가까운 벡터를 찾아가는 방식. pgvector에서도 자주 사용됩니다.
IVF: 벡터를 클러스터(Cluster)로 나누어, 유사한 클러스터만 탐색하는 방식입니다.
ScaNN: Google이 개발한 대규모 근사 최근접 이웃 검색용 방식으로, AlloyDB AI 등에서 이용할 수 있습니다.

모두 "정확도를 조금 허용하면서 검색 속도를 높이기" 위한 메커니즘입니다. RAG에서는 청크(Chunk) 수가 늘어났을 때의 레이턴시 (Latency) 대책으로서 중요합니다.

특히 ScaNN은 Google의 대규모 근사 최근접 이웃 탐색 문맥에서도 등장하는 기술입니다. AlloyDB 상에서 PostgreSQL 호환성을 유지하면서 vector 검색 성능을 높이고 싶을 때 고려할 수 있는 후보입니다.

Cloud SQL과 비교하면, AlloyDB는 고성능인 만큼 최소 구성에서도 고정비가 높아지기 쉽습니다. 따라서 검증 단계, 소규모 MVP, 또는 월간 쿼리 (Query) 수가 아직 적은 단계에서 처음부터 반드시 AlloyDB를 선택해야 한다고 생각하지는 않습니다. 우선 Cloud SQL + pgvector로 시작하고, 정말로 RAG가 프로덕트의 중심이 된 단계에서 AlloyDB로 이행하는 방식도 현실적입니다.

하지만 다음과 같은 경우라면 처음부터 AlloyDB를 선택할 가치가 있습니다.

RAG가 프로덕트의 핵심 기능이다
코퍼스 (Corpus)가 크다
쿼리 (Query)량이 많다
레이턴시 (Latency) 요구사항이 엄격하다
PostgreSQL 호환성을 유지하고 싶다
Cloud SQL + pgvector로 성능이 불안하다
향후 DB 이행을 피하고 싶다

Cloud SQL로 시작해서 AlloyDB로 옮기는 것도 방법입니다.

다만, 그 경우에는 DB 마이그레이션 (Migration)이 필요합니다.

A안에서 B안으로 바꿀 때, DB 마이그레이션이 필요한가

이 부분은 매우 중요합니다.

예를 들어, A안을 Cloud SQL + pgvector, B안을 AlloyDB + ScaNN이라고 가정해 봅시다.

이 경우, A에서 B로 변경할 때 DB 마이그레이션이 필요합니다.

Cloud SQL과 AlloyDB는 서로 다른 managed service입니다. 따라서 같은 PostgreSQL 계열이라고 할지라도, 아무런 조치 없이 바로 전환할 수 있는 것은 아닙니다.

공식 문서에도 Cloud SQL for PostgreSQL에서 AlloyDB로 이행하는 문서가 있습니다.

Database Migration Service를 사용하는 이행 경로도 있습니다.

하지만 여기서 중요한 점은, 이것이 "RAG를 새로 만드는 것"과는 다르다는 사실입니다.

스키마 (Schema)가 깔끔하고, 임베딩 벡터 (Embedding vector)도 DB에 저장되어 있으며, 청킹 (Chunking)이나 메타데이터 (Metadata)를 제대로 관리하고 있다면, 기본적으로는 PostgreSQL에서 PostgreSQL로의 이행입니다.

물론 AlloyDB 측에서 ScaNN 인덱스를 생성할 필요는 있습니다. 검색 SQL이나 연산자 (Operator), 인덱스 전략 (Index strategy)의 재검토도 필요합니다. 하지만 애플리케이션 전체를 버려야 하는 이야기는 아닙니다.

따라서 제안할 때는 다음과 같이 설명하는 것이 좋다고 생각합니다.

"Cloud SQL에서 AlloyDB로 옮길 경우, DB 이행과 인덱스 재생성이 필요합니다. 하지만 임베딩 (Embedding)을 반드시 전수 다시 만들어야 하는 것은 아닙니다."

임베딩은 언제 다시 만들어야 하는가

RAG 운영에서 혼란을 겪기 쉬운 부분이 바로 여기입니다.

DB를 옮기면 임베딩도 다시 만들어야 하나요?

기본적으로는 아닙니다.

임베딩 (Embedding)은 특정 텍스트를 임베딩 모델 (Embedding model)에 통과시켜 얻은 벡터 (Vector)입니다. 따라서 다음 사항들이 변하지 않는다면, DB를 옮기더라도 임베딩 자체는 재사용할 수 있습니다.

원본 텍스트
청킹 (Chunking)
임베딩 모델 명칭
임베딩 모델의 버전 (Version) / 리비전 (Revision)
벡터의 차원 수
정규화 (Normalization) 전제 조건
코사인 (Cosine) / 내적 (Dot) / L2 등 거리 계산 전제 조건
검색 (Retrieval)에 사용하는 메타데이터 및 검색 대상 텍스트

즉, Cloud SQL + pgvector에서 AlloyDB + ScaNN으로 옮기는 것뿐이라면, 대부분의 경우 Embedding (임베딩)을 다시 만들 필요는 없습니다.

나중에 이러한 판단을 내릴 수 있도록, chunk (청크) 테이블에는 최소한 embedding_model_name, embedding_model_version, embedding_dimension, distance_metric, normalized, source_text_hash, parser_version, chunker_version을 저장해 두는 것이 안전합니다. Gemini Embedding처럼 출력 차원을 지정할 수 있는 모델의 경우, 모델 이름뿐만 아니라 출력 차원도 반드시 저장해야 합니다.

참고로, gemini-embedding-001과 gemini-embedding-2는 임베딩 공간 (embedding space)이 호환되지 않습니다. 001에서 2로 이행하는 경우에는 동일한 chunk 본문이라도 재임베딩 (re-Embedding)이 필요합니다. 또한, gemini-embedding-001에서 3072 미만의 차원을 사용하는 경우에는 수동 정규화 (normalization)가 필요한 경우가 있는 반면, gemini-embedding-2는 비기본 차원을 자동으로 정규화한다고 설명되어 있습니다. 즉, embedding_model_name뿐만 아니라 모델 버전, 차원 수, 정규화 여부를 저장해 두어야 하는 의미가 있습니다.

필요한 것은 vector data (벡터 데이터)의 이행과, 이행 대상에서의 index (인덱스) 재생성입니다.

반대로, Embedding을 다시 만들어야 하는 경우는 다음과 같습니다.

Embedding 모델 이름이나 모델 version / revision을 변경할 때
vector 차원 수가 변경될 때
chunking (청킹)을 변경할 때
OCR이나 Layout Parser (레이아웃 파서)의 출력이 변경될 때
source document (소스 문서)가 크게 변경될 때
검색 대상으로 하는 텍스트나 metadata (메타데이터)를 변경할 때
distance metric (거리 측정 방식)이나 정규화 전제가 변경될 때
평가 데이터에서 기존 Embedding의 품질이 낮다는 것을 알게 되었을 때

특히 chunking 변경은 놓치기 쉽습니다.

RAG의 정밀도가 낮을 때, Embedding 모델만 바꾸고 싶어집니다. 하지만 실제로는 PDF의 읽기 순서가 깨져 있거나, FAQ의 한 줄이 거대한 chunk에 섞여 있거나, 이미지 내 텍스트를 가져오지 못하는 경우가 많습니다.

그 경우에는 Embedding 모델을 바꾸기 전에, parser (파서)와 chunking을 먼저 바로잡아야 합니다. 그리고 parser/chunking을 바로잡았다면, 당연히 Embedding은 다시 만들어야 합니다.

vector index rebuild와 Embedding 재생성은 별개입니다

이 부분도 구분하는 것이 좋습니다.

Embedding 재생성은 텍스트를 모델에 통과시켜 vector를 다시 만드는 것입니다.

index rebuild (인덱스 재구축)는 이미 존재하는 vector에 대해 검색용 index를 다시 만드는 것입니다.

예를 들어, Cloud SQL에서 AlloyDB로 옮긴다고 가정해 봅시다.

이때, Embedding은 그대로 이행할 수 있을지도 모릅니다. 하지만 AlloyDB 측에서 ScaNN index를 만든다면, index는 다시 만들어야 합니다.

BigQuery vector search에서도 테이블 데이터가 크게 바뀌면 vector index의 rebuild가 필요할 수 있습니다.

Vertex AI Vector Search에서도 batch index (배치 인덱스)라면 업데이트 방법을 설계해야 합니다. streaming update (스트리밍 업데이트)를 사용한다면 그에 맞춰 만들어야 합니다.

따라서 운영 설계에서는 이 두 가지를 나누어 생각합니다.

Embedding을 다시 만드는 것인가
index만 다시 만드는 것인가

이 차이를 설명할 수 있다면, RAG 제안의 신뢰도가 상당히 달라집니다.

Agent Search / Vertex AI Search

다음은 Agent Search입니다.

이전의 Vertex AI Search, Discovery Engine, Agent Builder 등의 명칭이 섞여 있어 솔직히 다소 복잡합니다. 공식 문서상에서도 'Vertex AI Search is being renamed to Agent Search'라는 흐름으로 진행되고 있습니다.

가격 페이지는 여기입니다.

주요 가격은 다음과 같습니다.

※ 가격은 2026-05-26 시점의 General Pricing 기준입니다. 무료 티어(Free Tier), Configurable Pricing, 리전(Region) 차이, 세금, 환율, 고정비, 로그 및 네트워크 비용은 제외되어 있습니다. Agent Search에는 계정당 월 10,000 queries의 무료 티어가 있지만, Advanced Generative Answers는 무료 티어 대상에서 제외됩니다.

항목	가격
Search Standard Edition	$1.50 / 1,000 queries
...
Agent Search의 장점은 검색 기반(Search Infrastructure)을 상당히 많이 맡길 수 있다는 점입니다.

사내 검색, 웹사이트 검색, 문서 검색, 생성 답변(Generative Answers)까지 포함하여 매니지드(Managed) 서비스로 가져가고 싶다면 강력한 선택지입니다. Google Cloud답게 커넥터(Connector)나 엔터프라이즈 서치(Enterprise Search)에 가까운 용도와도 궁합이 좋습니다.

반면, 독자적인 RAG를 구축하고 싶다면 주의가 필요합니다.

청킹(Chunking)을 세밀하게 제어하고 싶다
파서(Parser)를 독자적으로 평가하고 싶다
리트리벌(Retrieval)의 top-k를 확인하고 싶다
리랭크(Rerank) 전후를 비교하고 싶다
앱 DB의 메타데이터 필터링(Metadata Filtering)과 일체화하고 싶다
테넌트(Tenant)별 특수한 권한 처리를 넣고 싶다

이런 경우에는 Cloud SQL / AlloyDB / Vector Search 계열을 사용하여 자체 RAG(Self-built RAG) 방식으로 구축하는 것이 더 명확할 수 있습니다.

그리고 비용 문제입니다.

Enterprise + Advanced Generative Answers를 사용할 경우, 대략 1,000 queries당 $8입니다. 100만 쿼리라면 월 $8,000입니다. 일본 엔화로 환산하면 환율에 따라 다르겠지만, 상당히 큰 금액입니다.

물론 검색 기반을 직접 구축하는 데 드는 인건비나 운영비를 고려하면 Agent Search가 더 저렴할 수도 있습니다. 하지만 "매니지드 서비스라고 해서 항상 저렴한 것"은 아닙니다.

RAG Engine

RAG Engine은 자체 구축 RAG와 Agent Search의 중간 단계로 보는 것이 적절해 보입니다.

RAG Engine은 단순한 오케스트레이션(Orchestration)뿐만 아니라, RAG 코퍼스(Corpus) / 파일 메타데이터(File Metadata) 관리에 RagManagedDb를 사용합니다. 또한 구성에 따라 임베딩 인덱싱(Embedding Indexing) / 리트리벌(Retrieval)에도 RagManagedDb, 즉 Spanner 백엔드(Backend)가 사용됩니다. 데이터 인제스션(Data Ingestion), 파일 파싱(File Parsing), 청킹(Chunking), 임베딩 생성(Embedding Generation), 인덱싱/리트리벌(Indexing/Retrieval), 리랭킹(Reranking) 등 사용하는 구성 요소마다 과금되므로, RAG Engine의 처리 비용뿐만 아니라 RagManagedDb / Spanner 측의 비용도 확인할 필요가 있습니다.

이미지로 비유하자면, RAG Engine은 "모든 것이 포함된 완제품"이라기보다, 최근의 마라탕처럼 재료를 선택하면 가게 측에서 조리해 주는 방식에 가깝습니다. Document AI를 사용할지, 어떤 임베딩(Embedding)을 사용할지, 어떤 벡터 DB(Vector DB)를 사용할지에 따라 구성과 요금이 달라집니다. Agent Search처럼 검색 경험 전체를 통째로 맡기는 서비스라기보다, RAG에 필요한 부품들을 Google Cloud 측에서 매니지드(Managed) 방식으로 조합하기 위한 메커니즘으로 이해하면 쉽습니다.

여기서 혼란스러울 수 있는 점은 "그럼 전부 RAG Engine을 통하는 게 좋지 않나?"라는 의문입니다.

결론부터 말씀드리면, 앱 본체의 DB와 RAG용 코퍼스(Corpus)를 분리해도 괜찮으며, RAG 처리를 Google Cloud 측의 매니지드 컴포넌트(Managed Component)로 몰아넣고 싶다면 RAG Engine은 매우 좋은 선택지입니다. 반면, Cloud SQL + pgvector나 AlloyDB를 직접 사용하는 구성과는 데이터 보유 방식이 조금 다릅니다.

RAG Engine에서 말하는 RagManagedDb는 본인의 앱용 PostgreSQL이 아닙니다. RAG Engine이 RAG 코퍼스 / 파일 / 청크 / 임베딩 인덱싱 / 리트리벌을 위해 사용하는 매니지드 측의 저장소입니다. 즉, 프로덕트 본체의 Cloud SQL이나 AlloyDB와는 별개로, RAG Engine 측의 RAG 코퍼스가 생성되는 이미지입니다.

그리고 RAG Engine의 vector DB 선택지로 나오는 것은 RagManagedDb, Vertex AI Vector Search, Pinecone, Weaviate 등입니다. 적어도 현시점의 공식 문서상으로는, 「기존의 Cloud SQL + pgvector」나 「기존의 AlloyDB」를 그대로 RAG Engine의 managed vector DB로 선택한다는 모습은 아닙니다.

vector DB로 RagManagedDb를 사용하는 경우, backend는 Spanner Enterprise edition입니다. 즉, RagManagedDb를 선택한다면 뒷단에서는 Spanner 계열의 비용과 제약을 고려해야 합니다. 반면, Vector Search 등 다른 vector DB를 선택하는 경우에는 해당 선택지의 비용, 리전(Region), 제약 사항도 고려해야 합니다. 다만, 어느 쪽이든 RAG Engine의 corpus / file metadata 관리에는 RAG Engine 측의 managed layer가 관여합니다.

따라서 정리하면 다음과 같습니다.

Cloud SQL + pgvector / AlloyDB를 직접 사용하는 구성: 애플리케이션 DB, chunk, metadata, tenant 정보, embedding을 PostgreSQL 측으로 모으기 쉽습니다. SQL, transaction, 앱 측의 권한 설계와 통합하기 쉽습니다. 대신 retrieval pipeline, index 설계, rerank, 평가, 운용은 직접 구축해야 합니다.

RAG Engine을 사용하는 구성: corpus ingestion, chunking, embedding, retrieval 등을 managed 서비스에 맡기기 쉽습니다. 대신, 애플리케이션 본체 DB와는 별개의 RAG corpus / managed vector DB를 갖는 설계가 되기 쉬우며, 기존 PostgreSQL의 schema나 transaction과 일체화된 RAG를 구현하기는 어렵습니다.

예를 들어, 메인 업무 데이터가 Cloud SQL / AlloyDB에 있고, 그 행 데이터나 tenant 권한과 완전히 일체화하여 RAG를 하고 싶다면, Cloud SQL + pgvector / AlloyDB를 직접 다루는 편이 설명하기 쉽습니다.

반대로, RAG 대상이 PDF, 사내 문서, 매뉴얼, 지식 베이스(Knowledge Base) 중심이며, 앱 DB와 다소 분리되어도 괜찮고 DB 운용보다 managed ingestion / retrieval을 우선시하고 싶다면, RAG Engine은 매우 좋은 선택지입니다.

또한, RAG Engine corpus를 Vector Search 2.0 backend로 사용하는 경우, 현시점에서는 us-central1만 이용 가능합니다. Preview / Pre-GA 취급이나 데이터 소재지, CMEK, VPC-SC 등의 요구사항도 견적 산출 전에 확인해야 합니다. 일본 리전이나 데이터 소재지가 중요한 프로젝트에서는 이 제약이 설계 판단에 영향을 미칩니다.

즉, RAG Engine을 사용하지 않는 이유는 「성능이 약해서」가 아닙니다. 애플리케이션 DB와 RAG 데이터를 하나로 묶어서 관리하고 싶은지, 아니면 RAG corpus를 managed service 측으로 분리하여 관리해도 괜찮은지의 차이입니다.

이것은 취향의 문제라기보다, 프로덕트의 데이터 설계에 달려 있습니다.

Vertex AI Vector Search / Agent Retrieval

대규모 vector search라면, Vertex AI Vector Search나 Agent Retrieval이 후보가 됩니다.

가격 페이지상에는 classic Vector Search나 Storage-optimized Vector Search / Agent Retrieval 계열의 SKU가 있습니다.

대표적인 것으로는 다음과 같은 것들이 있습니다.

Classic Vector Search:

index build/update: $3.00 / GiB data processed
streaming inserts: $0.45 / GiB ingested
deployed index는 node-hour 과금

Storage-optimized Vector Search / Agent Retrieval:

Storage-optimized CU: $2.30 / CU-hour / replica
Performance-optimized CU: $0.065 / CU-hour (Agent Retrieval 측의 SKU)
data write/update: $0.45 / GiB

이 부분은 SKU가 나누어져 있으므로, 견적을 산출할 때는 classic Vector Search와 Agent Retrieval / Storage-optimized 계열을 섞지 않는 것이 안전합니다.

Vector Search는 강력합니다. 대량의 vector를 저지연 (low latency)으로 검색하고 싶다면, 전용 서비스를 사용할 의미가 있습니다.

다만, 여기서는 Classic Vector Search를 전제로 생각할지, 아니면 Vector Search 2.0 / Agent Retrieval을 전제로 생각할지에 따라 설계가 달라집니다.

Classic Vector Search를 사용하는 경우에는 PostgreSQL 등에 chunk 본문이나 ACL/metadata를 보유하고, Vector Search에는 id/vector/filter metadata를 동기화하는 설계가 되기 쉽습니다. 즉, 동기화 처리, 삭제 반영, 재인덱싱 (re-index), 실패 시의 복구 (recovery), 버전 관리 (version management)가 필요합니다.

반면, Vector Search 2.0 / Agent Retrieval에서는 payload data를 vector similarity와 함께 저장·취득·필터링할 수 있는 통합 데이터 스토리지 (Unified Data Storage)나, 자동 임베딩 (embedding) 생성, 내장 텍스트 검색 (built-in text search) 방향으로 나아가고 있습니다. 따라서 반드시 "source DB 동기화가 필요"한 것은 아닙니다. 요구사항에 따라, 신뢰할 수 있는 데이터 원천 (source of truth)을 PostgreSQL / BigQuery / GCS 등 별도의 DB에 둘지, 아니면 Vector Search 2.0 측에 집중시킬지를 선택합니다.

소규모 RAG에서 처음부터 이렇게 구성하면 상당히 무겁습니다.