AlloyDB 2026: BM25 전문 검색·ScaNN 벡터·AI SQL·레이크하우스 페더레이션으로 PostgreSQL에서 하이브리드 데이터 플랫폼을 구성하는 방법

요약

• 출처: Google Cloud Next '26 (2026-04-22 ~ 24, 약 110일 전) 및 2026년 7-8월 공식 블로그 발표 — 180일 패스백 창 내
• 핵심 변화: AlloyDB가 PostgreSQL 호환 OLTP를 유지하면서 전문 검색(BM25), 근사 벡터(ScaNN), 생성 AI SQL 함수, Lakehouse Federation을 단일 데이터 평면에 통합
• 실무 관련성: RAG 파이프라인이나 하이브리드 검색이 필요한 팀이 Elasticsearch·Pinecone 같은 외부 인덱스를 제거하고 기존 PostgreSQL 워크플로 안에서 처리 가능한지를 판단하는 기준이 됨
• 단계: ScaNN 인덱스·AI SQL 함수는 Preview; BM25(pg\_textsearch)는 Preview; Lakehouse Federation BigQuery는 GA, Apache Iceberg는 Preview; PostgreSQL 18 GA

AlloyDB는 Google의 PostgreSQL 호환 관리형 데이터베이스다. 2022년 출시 당시의 핵심 가치는 컬럼 엔진 내장과 스토리지/컴퓨트 분리였다. 2025년에 벡터 검색(HNSW + ScaNN 프리뷰)이 추가되면서 임베딩 저장소로 주목받기 시작했고, 2026년 상반기에 BM25 전문 검색·AI SQL 함수·Lakehouse Federation이 한꺼번에 공개됐다.

이 챕터는 각 기능이 실제로 무엇을 하는지, 기존 아키텍처에서 무엇을 대체할 수 있는지, 그리고 어디서 아직 외부 시스템이 필요한지를 구체적으로 정리한다.

2026년 AlloyDB 기능 지도

△ = Google Cloud Next '26 발표(~110일 전), 180일 패스백 창 내

BM25 전문 검색: pg\_textsearch

PostgreSQL은 오래전부터 tsvector/tsquery 기반 GIN 인덱스로 전문 검색을 지원했다. 기본 랭킹 함수 ts_rank는 TF(단어 빈도)만 고려하며 IDF(역문서 빈도) 가중치를 통계적으로 계산하지 않는다. 텍스트 코퍼스가 크거나 희귀 용어 매칭이 중요한 검색에서 정확도가 떨어지는 이유다.

AlloyDB의 pg_textsearch 확장은 BM25(Best Matching 25) 알고리즘을 구현한다.

BM25 핵심 수식:

score(q, d) = Σ IDF(t) × (f(t,d) × (k1+1)) / (f(t,d) + k1 × (1 - b + b × |d|/avgdl))

• f(t,d): 문서 d에서 단어 t의 빈도
• |d|: 문서 길이, avgdl: 평균 문서 길이
• k1 (≈1.2): 포화 매개변수 — 단어 빈도가 증가할수록 점수 증분이 감소
• b (≈0.75): 길이 정규화 — 긴 문서에 패널티

PostgreSQL 내장 ts_rank와 달리 문서 총 수, 단어별 역문서 빈도를 컬렉션 전체에서 사전 계산해 저장한다. AlloyDB는 이 통계 테이블을 컬럼 엔진에 올려 스캔을 가속한다.

-- 확장 활성화
CREATE EXTENSION IF NOT EXISTS pg_textsearch;

-- BM25 인덱스 생성
CREATE INDEX idx_products_bm25
  ON products
  USING bm25 (description tsv_description)
  WITH (text_column = 'description', language = 'korean');

-- BM25 랭킹 전문 검색
SELECT id, name,
       bm25_rank(tsv_description, to_tsquery('korean', '벡터 검색')) AS score
FROM products
WHERE tsv_description @@ to_tsquery('korean', '벡터 검색')
ORDER BY score DESC
LIMIT 10;

한국어 토크나이저 지원 여부는 현재 Preview 단계에서 제한적이다. 영문 및 다국어 분석기 옵션이 주요 경로다.

하이브리드 검색: BM25 + ScaNN 결합

벡터 검색만 사용하면 "정확한 용어 매칭"에 약하다. 예를 들어 사용자가 GPT-4o라고 입력했을 때 임베딩 공간에서는 유사한 모델 이름이 가까워도 정확히 GPT-4o를 포함한 문서를 상위에 올리는 데 실패할 수 있다. BM25는 이런 정확 매칭에 강하지만 의미적 유사성은 반영하지 못한다. 둘을 결합하면 두 약점을 상호 보완할 수 있다.

-- BM25 결과와 ScaNN 벡터 결과를 RRF로 결합
WITH bm25_results AS (
  SELECT id,
         ROW_NUMBER() OVER (ORDER BY bm25_rank(content_tsv, query) DESC) AS rk
  FROM articles,
       to_tsquery('english', 'vector search database') query
  WHERE content_tsv @@ query
  LIMIT 100
),
vector_results AS (
  SELECT id,
         ROW_NUMBER() OVER (ORDER BY embedding <=> $1::vector) AS rk
  FROM articles
  ORDER BY embedding <=> $1::vector
  LIMIT 100
)
SELECT COALESCE(b.id, v.id) AS id,
       1.0/(60 + COALESCE(b.rk, 100)) + 1.0/(60 + COALESCE(v.rk, 100)) AS rrf_score
FROM bm25_results b
FULL OUTER JOIN vector_results v ON b.id = v.id
ORDER BY rrf_score DESC
LIMIT 20;

RRF(Reciprocal Rank Fusion) 공식: score = Σ 1/(k + rank_i) (k=60이 일반적 기본값)

AlloyDB가 두 인덱스를 모두 관리하므로 Elasticsearch나 Pinecone 같은 별도 인덱스 서버 없이 단일 psql 연결로 처리된다.

ScaNN 인덱스: 10B 벡터 규모

AlloyDB는 원래 pgvector 호환 HNSW 인덱스를 지원했다. HNSW는 소~중간 규모(수천만 건)에서 잘 동작하지만, 빌드 메모리와 삽입 비용이 높아 수십억 건 규모에서 한계가 있다.

ScaNN(Scalable Approximate Nearest Neighbors)은 Google Research가 개발한 ANN 알고리즘으로, 양자화와 비등방성 벡터 양자화(AVQ)를 결합해 높은 재현율을 유지하면서 메모리를 줄인다.

AlloyDB에서의 공개 수치 (Next '26 기준, 정확한 벤치마크 설정은 Needs confirmation):

• 최대 10B 벡터까지 단일 인덱스 지원
• HNSW 대비 6× 빠른 쿼리 처리량 (Google 공식 클레임)
• 컬럼 엔진과 결합 시 HNSW+컬럼 대비 4× 추가 향상

-- ScaNN 인덱스 생성
CREATE INDEX idx_embeddings_scann
  ON documents
  USING scann (embedding vector_cosine_ops)
  WITH (num_leaves = 1000, num_leaves_to_search = 100);

-- ScaNN 벡터 검색
SELECT id, title, embedding <=> $1::vector AS distance
FROM documents
ORDER BY embedding <=> $1::vector
LIMIT 10;

HNSW와 ScaNN 중 선택 기준:

AI SQL 함수

AlloyDB AI는 BigQuery ML 접근 방식을 PostgreSQL 위에 올린 것으로 이해할 수 있다. Vertex AI 모델(Gemini 포함)을 SQL 함수 형태로 직접 호출한다.

현재 Preview 단계 함수:

-- 감성 분석
SELECT id, review_text,
       ai.analyze_sentiment(review_text) AS sentiment
FROM product_reviews;
-- 반환: {"score": 0.85, "magnitude": 0.9, "label": "positive"}

-- 텍스트 요약
SELECT id, article,
       ai.summarize(article, max_output_tokens => 100) AS summary
FROM news_articles;

-- 조건부 판단 (자연어 기반 필터)
SELECT * FROM support_tickets
WHERE ai.if(description, 'Is this a billing issue?');

-- 자연어 랭킹
SELECT id, content,
       ai.rank(content, 'Most relevant to database migration risks') AS relevance
FROM documents
ORDER BY relevance DESC LIMIT 5;

-- 텍스트 생성
SELECT id, product_name,
       ai.generate(
         prompt => 'Write a 50-word product description for: ' || product_name,
         model => 'gemini-2.0-flash'
       ) AS description
FROM products WHERE description IS NULL;

-- 수요 예측 (시계열 데이터)
SELECT ai.forecast(
  table => 'daily_sales',
  time_column => 'date',
  target_column => 'revenue',
  horizon => 30
);

각 함수는 내부적으로 Vertex AI API를 호출하며, AlloyDB 네트워크 내에서 Private Service Connect를 통해 처리된다. 비용은 Vertex AI 호출 건수로 청구된다.

실무 한계:

• 함수 호출마다 네트워크 RTT 발생 — 대량 배치 처리에 부적합
• 응답 일관성(hallucination)은 SQL 레벨에서 검증 불가
• Preview 단계이므로 SLA 없음

Lakehouse Federation

Federation은 AlloyDB의 PostgreSQL 쿼리 플래너가 외부 소스에 쿼리 일부를 위임(push down)하는 방식으로 동작한다. 데이터를 AlloyDB로 복사하지 않는다.

-- BigQuery 외부 테이블 연결 (GA)
CREATE EXTERNAL TABLE ext_bq_events
  WITH COLUMN DEFINITION USING FOREIGN SERVER alloydb_bq_server
  SERVER OPTIONS (
    project = 'my-gcp-project',
    dataset = 'analytics',
    table = 'user_events'
  );

-- AlloyDB OLTP + BigQuery 데이터 조인
SELECT u.name, COUNT(e.event_id) AS event_count
FROM users u                          -- AlloyDB 로컬 테이블
JOIN ext_bq_events e ON u.id = e.user_id  -- BigQuery 외부 테이블
WHERE e.event_date >= '2026-01-01'
GROUP BY u.name
ORDER BY event_count DESC;

Apache Iceberg 연합은 Cloud Storage의 Iceberg 테이블에 대해 동일한 방식으로 동작한다. CREATE EXTERNAL TABLE ... USING iceberg 구문을 사용한다.

실제 제약:

• 외부 소스 쿼리 비용은 BigQuery/GCS 과금 기준으로 별도 발생
• 일관성 보장 없음 — BigQuery 데이터는 AlloyDB 트랜잭션 밖
• 복잡한 조인 푸시다운은 쿼리 플래너가 제대로 처리하지 못할 수 있음 (EXPLAIN으로 확인 필수)

PostgreSQL 18 GA

AlloyDB는 2026년 상반기에 PostgreSQL 18을 GA로 지원했다.

PostgreSQL 18 주요 변화 중 AlloyDB 운영에 직접 영향을 주는 것:

• 비동기 I/O: libaio/io\_uring 기반 — AlloyDB의 분리형 스토리지 레이어와 상호작용 방식이 달라짐
• 논리 복제 슬롯 페일오버: AlloyDB HA 클러스터에서 논리 복제 슬롯을 레플리카로 자동 전파
• COPY FROM ... RETURNING: 대량 삽입 후 생성된 행 즉시 반환 — 임베딩 파이프라인에서 배치 삽입 후 후속 처리 단순화
• pg_wait_events 뷰 확장: 대기 이벤트 가시성 향상 — AlloyDB Database Insights와 통합

Database Insights MCP 서버

AlloyDB는 Claude·ChatGPT 등 LLM 클라이언트가 데이터베이스 운영 정보에 접근할 수 있도록 Remote MCP(Model Context Protocol) 서버를 제공한다.

지원 기능:

• 슬로우 쿼리 분석 (top_slow_queries 리소스)
• 인덱스 추천 (index_advisor 도구)
• 테이블 통계 요약
• 잠금 경합 분석

# Claude Desktop에서 AlloyDB MCP 서버 연결 (settings.json)
{
  "mcpServers": {
    "alloydb-insights": {
      "command": "npx",
      "args": ["-y", "@google-cloud/alloydb-mcp-server"],
      "env": {
        "ALLOYDB_PROJECT": "my-project",
        "ALLOYDB_INSTANCE": "my-instance",
        "ALLOYDB_DATABASE": "mydb"
      }
    }
  }
}

이 서버를 통해 LLM 에이전트가 "가장 느린 쿼리 5개를 분석하고 인덱스를 추천해 줘"라고 자연어로 요청하면 Database Insights API를 조회해 구체적 SQL을 반환한다.

주의: MCP 서버는 AlloyDB 읽기 권한이 있는 서비스 계정으로 동작한다. 쓰기 권한이나 DDL 실행 권한을 부여하면 LLM이 직접 스키마를 변경할 수 있으므로 최소 권한 원칙을 반드시 적용해야 한다.

도입 검토 기준

AlloyDB 통합이 유리한 경우:

• 이미 AlloyDB를 OLTP로 사용 중이고, 추가 인프라 도입 비용이 부담스러운 경우
• RAG 파이프라인에서 임베딩과 원본 행 데이터를 함께 조회하는 경우
• BigQuery와 OLTP 데이터를 조인해야 하는 경우 (Federation)
• AI SQL로 소량 배치 처리(< 1만 건/회)를 단순화하고 싶은 경우

AlloyDB 통합이 부적합한 경우:

• AI SQL 함수를 초당 수천 건 실시간 호출해야 하는 경우
• BM25·ScaNN이 Preview 상태임을 감수할 수 없는 프로덕션 SLA
• 멀티클라우드 또는 GCP 외 환경
• 임베딩 차원수가 4096 이상인 경우 (PostgreSQL 벡터 지원 한계 확인 필요)

요점 정리

• AlloyDB 2026은 PostgreSQL 데이터 평면 안에 BM25·ScaNN·AI SQL·Lakehouse Federation을 통합했다. 아직 대부분이 Preview 상태다.
• BM25(pg\_textsearch)는 기존 ts_rank 한계를 극복하지만, 한국어 토크나이저 지원은 Preview 단계에서 제한적이다.
• ScaNN은 HNSW 대비 10B 벡터 규모에서 6× 빠른 쿼리를 목표로 하지만, 실제 워크로드에서 벤치마크를 직접 검증해야 한다.
• RRF를 통한 BM25 + ScaNN 하이브리드 검색은 단일 SQL로 처리 가능해 외부 검색 엔진 의존도를 줄이는 가장 현실적인 경로다.
• Lakehouse Federation은 BigQuery 데이터를 AlloyDB에 복사하지 않고 조인할 수 있게 해 ETL 파이프라인 단계를 줄인다. 단 일관성 경계와 푸시다운 한계를 EXPLAIN으로 반드시 확인해야 한다.
• Database Insights MCP 서버는 LLM 에이전트가 슬로우 쿼리를 분석하고 인덱스를 추천하게 하는 운영 편의 기능이다. 쓰기 권한을 부여하면 위험하다.

References

• Google Cloud Blog, "What's new for Google Cloud databases at Next '26" (2026): https://cloud.google.com/blog/products/databases/whats-new-for-google-cloud-databases-at-next26
• AlloyDB AI SQL Functions documentation (Preview): https://cloud.google.com/alloydb/docs/ai/work-with-ai-query-functions
• AlloyDB Vector Search with ScaNN: https://cloud.google.com/alloydb/docs/ai/use-scann-index
• AlloyDB Lakehouse Federation: https://cloud.google.com/alloydb/docs/federation/overview
• AlloyDB pg_textsearch BM25: https://cloud.google.com/alloydb/docs/full-text-search
• PostgreSQL 18 Release Notes: https://www.postgresql.org/docs/18/release-18.html
• Robertson, S. & Zaragoza, H., "The Probabilistic Relevance Framework: BM25 and Beyond" (2009): https://dl.acm.org/doi/10.1561/1500000019
• Google ScaNN library: https://github.com/google-research/google-research/tree/master/scann
• AlloyDB Database Insights MCP Server: https://cloud.google.com/alloydb/docs/insights/mcp-server
• Guo, R. et al., "Accelerating Large-Scale Inference with Anisotropic Vector Quantization" (ICML 2020, ScaNN paper): https://arxiv.org/abs/1908.10396