데이터베이스

AlloyDB: 하이브리드 검색을 위한 통합 데이터베이스 엔진

Tue, 13 Oct 2026 19:00:00 +0000

*이 콘텐츠는 AI 번역 도구를 사용하여 번역되었습니다. 정확성을 기하기 위해 노력하고 있으나, 자동 번역에는 오류나 누락이 포함될 수 있습니다. 정확한 정보는 영문 원본을 참고해 주시기 바랍니다.

최신 AI 및 RAG 애플리케이션에서 검색 관련성을 높이려면 시맨틱 컨텍스트를 위한 벡터 검색 및 키워드 정밀도를 위한 전체 텍스트 검색(FTS)과 같은 두 가지 이상의 기술을 결합해야 합니다. PostgreSQL용 AlloyDB는 이 두 가지 기능을 모두 지원하지만, 이를 관리하려면 기존에는 최고의 성능을 보장하기 위해 보다 직접적인 운영 접근 방식이 필요했습니다.

문제는 검색을 실행하는 것이 아니라 이후 여러 결과를 융합하는 과정에 있습니다. 벡터 쿼리의 결과(거리 점수)와 FTS 쿼리의 결과(관련성 점수)를 통합하려면 애플리케이션 계층의 복잡한 SQL 쿼리나 커스텀 코드가 필요합니다. 따라서 융합, 점수 정규화, 재순위 지정을 위한 별도의 시스템을 유지해야 하는 경우가 많습니다.

이 문서에서는 AlloyDB AI의 하이브리드 검색이 이러한 복잡성을 어떻게 해결하는지 자세히 설명합니다. 최근 업데이트를 통해 다음과 같은 작업을 수행할 수 있게 되었습니다.

하이브리드 검색 간소화: 복잡한 SQL 쿼리 또는 다단계 애플리케이션 워크플로를 Reciprocal Rank Fusion(RRF)으로 구동되는 단일 고성능 SQL 함수로 통합합니다.
FTS 성능 최적화: 새로운 RUM 확장 프로그램을 사용하여 단어 위치를 색인에 직접 저장함으로써 지연 시간이 짧은 관련성 순위 지정과 효율적인 구문검색을 달성합니다.
업계 표준 순위 지정 활용: 새롭게 기본 지원되는 BM25 색인을 활용하여 별도의 설정 없이 정확도 높은 키워드 기반 스코어링을 구현할 수 있습니다.
검색 활용 범위 확장: 새로운 외부 검색용 외부 데이터 래퍼(FDW)를 사용하여 AlloyDB 환경을 벗어나지 않고도 Elasticsearch, OpenSearch, Solr를 비롯한 전문 외부 클러스터에 대해 쿼리를 실행할 수 있습니다.

다단계 워크플로의 문제

AlloyDB AI의 네이티브 솔루션이 출시되기 전에는 강력한 하이브리드 검색을 구현하기가 매우 어려웠습니다. 특히 표준 SQL을 사용하여 데이터베이스 내에서 이 로직을 유지하려는 개발자에게는 더욱 어려운 문제였습니다. 이 접근 방식은 다단계 조정이 필요했기 때문에 두 소스에 대해 관리하고 유지하기 어려울 뿐만 아니라 소스가 추가되면 확장하는 것이 사실상 불가능했습니다. 이러한 단계에는 다음이 포함되었습니다.

벡터 검색 실행: 벡터 열 또는 벡터 색인(AlloyDB의 경우 ScaNN 색인일 수 있음)을 사용해 쿼리를 실행하고 상위 k개 결과를 찾아 벡터 점수를 생성합니다.
FTS 쿼리 실행: 일반화된 역색인(GIN) 등을 사용해 FTS 쿼리를 실행하고 상위 k개 결과를 찾습니다.
점수 정규화(불안정한 단계): 복잡한 SQL 로직 또는 커스텀 애플리케이션 코드를 작성하여 두 결과 집합을 공통 척도에 매핑합니다. 이 로직은 데이터 분포가 변경되면 제대로 작동하지 않을 가능성이 높습니다.
교차 서비스 조인 및 재순위 지정 수행: 애플리케이션 메모리를 사용하여 문서 ID에 대해 복잡한 FULL OUTER JOIN을 수행하고, 정규화된 점수의 가중치 합계를 적용하고, 마지막으로 FTS 검색이 벡터 검색에 사용된 시스템과 다른 별도의 시스템에서 수행된 경우 결합된 결과를 정렬합니다.

이러한 분산된 접근 방식은 취약한 점수 로직, 지연 시간 증가, 높은 운영 부하, 검색 품질 유지를 위한 애플리케이션 전문 지식에 대한 의존성으로 이어졌습니다.

AlloyDB로 하이브리드 검색 아키텍처 간소화

이를 간소화하는 핵심은 RRF를 도입하는 것입니다. RRF는 본질적으로 순위 기반이므로 점수 정규화의 불안정한 단계를 교묘하게 우회합니다. RRF는 두 부분으로 구성됩니다.

1. 단일 정보 소스

여러 단계의 가져오기 및 조인 프로세스 대신 하나의 SQL 함수를 호출하여 검색 구성요소를 선언적 JSON 배열로 제공하면 됩니다.

code_block: <ListValue: [StructValue([('code', 'SELECT id, score \r\nFROM ai.hybrid_search(\r\n search_inputs => ARRAY[\r\n -- Vector Component (Semantic) with dynamic embedding generation from natural language\r\n $json${\r\n "data_type": "vector",\r\n "limit": 10,\r\n "table_name": "documents",\r\n "key_column": "doc_id",\r\n "vec_column": "embedding",\r\n "distance_operator": "<=>",\r\n "query_vector": "ai.embedding(\'text-embedding-005\', \'alloydb search\')::vector"\r\n }$json$::jsonb,\r\n \r\n -- Text Component (Keyword)\r\n $json${\r\n "data_type": "text",\r\n "limit": 10,\r\n "table_name": "documents",\r\n "key_column": "doc_id",\r\n "text_column": "content",\r\n "query_text_input": "alloydb search"\r\n }$json$::jsonb\r\n ]\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad66c9e790>)])]>

(참고: 통합 ai.hybrid_search API는 두 가지 구성요소로만 제한되지 않습니다. 새로운 FDW를 통한 외부 검색 소스도 기본적으로 지원합니다.

2. 데이터베이스 네이티브 조정

hybrid_search() 함수는 단일 쿼리 계획에서 전체 워크플로를 실행하여 오버헤드를 최소화하고 트랜잭션 일관성을 보장합니다. 여기에는 다음이 사용됩니다.

동적 CTE 생성: 이 함수는 동적 SQL을 구성하여 각 구성요소에 대한 공통 테이블 표현식(CTE)을 만듭니다. 각 CTE는 결과의 위치 순위(ROW_NUMBER())를 계산합니다.
커널 수준 융합: 순위가 지정된 모든 구성요소 결과는 문서 ID를 기반으로 FULL OUTER JOIN을 사용하여 즉시 결합됩니다.
최종 RRF 점수: 결합된 순위는 RRF 공식을 사용하여 최종 통합 점수를 계산하는 데 사용됩니다.

이 접근 방식을 사용하면 불안정한 점수 계산과 애플리케이션 측 조인이 필요하지 않습니다. 현재 순위 지정 알고리즘은 Reciprocal Rank Fusion(RRF)이지만, 향후 추가적인 병합 및 순위 지정 옵션을 도입할 예정입니다.

결과: 성능 및 운영 간소화

복잡한 외부 워크플로에서 네이티브 SQL 함수로 전환하면 즉각적이고 측정 가능한 이점을 얻을 수 있습니다.

측정항목	다단계 애플리케이션 워크플로(수동 SQL로 시뮬레이션)	AlloyDB AI 네이티브 hybrid_search() UDF
코드 복잡성	복잡한 점수 정규화 함수, 서비스 호출, 애플리케이션 조인	외부 로직 없이 단일 선언적 SQL 호출만으로 충분
유지보수	정규화 공식의 지속적인 조정	조정이 필요하지 않음. RRF는 순위 기반이며 분포에 구애받지 않음

FTS 성능 향상: RUM 확장 프로그램

AlloyDB AI의 hybrid_search() 함수는 고성능 벡터 검색과 FTS를 결합하여 포괄적인 검색 관련성을 제공하도록 설계되었습니다. AlloyDB의 기본 FTS 기능은 강력하지만 텍스트 구성요소에 표준 PostgreSQL GIN 색인을 사용하면 고급 작업에서 병목 현상이 발생할 수 있습니다.

GIN 색인의 문제는 단어의 위치 정보를 저장하지 않는다는 것입니다. 이러한 제한으로 인해 다음 작업을 수행하려면 비용이 많이 드는 테이블 스캔을 통해 콘텐츠를 재분석해야 합니다.

관련성 순위 지정: 단어 근접성과 빈도를 기반으로 검색 결과 점수를 계산합니다.
구문 검색: 위치 정보가 필요한 정확한 단어 순서를 찾습니다.

짧은 지연 시간의 FTS를 위한 RUM 확장 프로그램 소개

RUM 확장 프로그램은 이러한 성능 문제를 직접 해결하는 GIN 기반의 강력한 색인 액세스 방법입니다.

RUM의 핵심 이점: 단어 -> [docID] 매핑 방식의 GIN 색인과 달리 RUM 색인은 각 단어의 위치 정보를 색인 내에 직접 저장합니다(예: 단어 -> [(docID1, [pos])], …).
성능 이점: 이를 통해 RUM은 순위 지정 및 구문검색과 같은 복잡한 작업을 주로 색인 자체 내에서 수행하여 비용이 많이 드는 힙 스캔을 방지할 수 있습니다. RUM은 훨씬 더 빠른 관련성 순위 지정과 효율적인 구문 및 근접성 검색을 제공합니다.
하이브리드 검색에 적합: RUM은 하이브리드 검색 프레임워크 내에서 벡터 검색(예: ScaNN)을 보완하는 중요한 역할을 합니다. GIN의 잠재적 지연 시간으로 인해 실시간 하이브리드 접근 방식에는 적합하지 않기 때문입니다.

RUM 확장 프로그램은 순위 지정 작업이 많거나 동시 실행 작업이 많은 검색 애플리케이션에 적합합니다. RUM은 단어 위치를 색인에 직접 저장하므로 순위를 매기는 동안 테이블 페이지를 다시 스캔할 필요가 없어 정렬된 결과를 빠르게 제공합니다. 그러나 색인 빌드 속도가 느리고 디스크 사용량이 많다는 단점이 있습니다. 워크로드에서 쓰기 속도와 스토리지 밀도보다 빠른 쿼리와 정확한 순위 지정이 중요하다면 RUM은 투자할 가치가 충분합니다.

측정 가능한 이점 및 통합

RUM을 도입하면 AlloyDB에서 FTS의 성능이 직접적으로 향상되어 원시 FTS 쿼리에서 상당한 이점을 얻을 수 있을 뿐만 아니라 FTS 쿼리가 포함된 하이브리드 검색에서도 이점을 얻을 수 있습니다. 다음은 다양한 BEIR 데이터 세트에서 GIN과 비교하여 RUM을 사용할 때의 속도 향상을 보여주는 성능 통계입니다.

(성능은 BEIR Natural Questions 벤치마크를 사용한 테스트를 기반으로 함)

RUM은 검색 및 순위 지정을 위한 특수 <=> 거리 연산자와 통합됩니다. 이 연산자는 하이브리드 검색 SQL 호출에서도 지원되어 두 가지 장점을 모두 제공합니다. 다음 Codelab에서는 하이브리드 검색 UDF를 사용하여 RUM 색인을 구성하고 사용하는 방법을 보여줍니다.

BM25 색인 소개: 최신 순위 지정 표준

최근 Google Cloud는 Cloud SQL 및 AlloyDB에 BM25 색인을 프리뷰 버전으로 도입하여 pg_textsearch 확장 프로그램을 통해 업계 표준 관련성 순위 지정 기능을 제공했습니다. BM25는 TF-IDF를 사용하여 용어 빈도 포화와 문서 길이 정규화를 고려하므로 키워드 기반 검색 쿼리에 대해 훨씬 더 높은 정밀도와 품질을 제공합니다. AlloyDB AI 내의 기본 BM25 색인을 활용하면 즉시 뛰어난 순위 지정 정확성을 달성할 수 있으므로 외부 검색엔진이나 복잡한 커스텀 스코어링 로직을 구현하지 않고도 정확히 일치하는 용어와 중요한 키워드에 높은 점수를 부여할 수 있습니다.

code_block: <ListValue: [StructValue([('code', "-- Install pg_textsearch extension\r\nCREATE EXTENSION pg_textsearch;\r\n\r\n-- Create the native BM25 index on the content column\r\nCREATE INDEX idx_docs_bm25 \r\nON cymbal_products \r\nUSING bm25 (product_description) \r\nWITH (text_config='english');\r\n\r\n-- Full text search query\r\nSELECT product_name, product_description <@> 'cherry tree' AS bm25_score \r\nFROM cymbal_products\r\nORDER BY bm25_score \r\nLIMIT 5;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad67234190>)])]>

외부 검색: 외부 데이터 래퍼로 활용 범위 확장

검색 기능을 더욱 확장하기 위해 AlloyDB AI에 외부 검색용 외부 데이터 래퍼(FDW)도 도입했습니다. 이를 통해 Elasticsearch, OpenSearch, Solr를 시작으로 전문 외부 클러스터에 대해 전체 텍스트 검색을 실행할 수 있으며 다음과 같은 몇 가지 주요 아키텍처 이점을 제공합니다.

최적화된 검색: AlloyDB 환경을 벗어나지 않고도 전용 검색 백엔드의 순위 지정 알고리즘과 더 풍부한 특성 세트를 활용할 수 있습니다.
통합 SQL 인터페이스: 고급 FTS 쿼리의 표현력을 유지하면서 표준 PostgreSQL SQL을 사용하여 외부 데이터와 상호작용하고, 조인을 수행하고, 결과를 병합할 수 있습니다.
강력한 이식성: 기존 검색 인프라를 유지하면서 AlloyDB AI가 제공하는 간소화된 하이브리드 아키텍처의 이점을 누릴 수 있습니다.

다음 Codelab은 Elasticsearch 및 Solr 통합을 통해 하이브리드 검색을 구현하는 방법을 종합적으로 안내하는 코드 가이드입니다.

AI 기반 검색을 위한 통합 아키텍처

현대 검색의 진정한 과제는 기술적인 것이 아니라 아키텍처의 단순성과 지속적인 운영 안정성을 달성하는 것입니다. AlloyDB AI는 세 가지 핵심 혁신을 기반으로 구축된 통합 플랫폼으로 이 문제를 해결합니다.

하이브리드 검색 간소화: RRF를 기반으로 하는 AlloyDB AI의 하이브리드 검색 함수는 취약한 다단계 애플리케이션 워크플로를 단일 고성능 SQL 호출로 변환합니다. 이러한 네이티브 구현은 복잡한 점수 정규화와 애플리케이션 측 조인의 필요성을 없애 운영 및 엔지니어링 비용을 대폭 절감하는 동시에 일관되게 정확하고 빠른 하이브리드 관련 결과를 제공합니다.
FTS 성능 최적화: 하이브리드 검색의 FTS 구성요소가 다양한 애플리케이션 요구사항을 충족할 수 있도록 AlloyDB AI는 고유한 전체 텍스트 검색 옵션을 제공합니다. RUM 확장 프로그램은 위치 데이터를 색인에 직접 저장하여 더 빠른 관련성 순위 지정과 효율적인 구문 검색을 지원함으로써 지연 시간이 짧은 성능에 맞게 최적화합니다. 이는 빠른 쿼리 속도가 필요할 때 중요합니다. 반면, BM25 색인은 업계 표준 관련성 순위 지정 기능을 제공하며 키워드 스코어링의 정확도가 우선인 경우에 적합합니다. 검색 지연 시간 또는 순위 정밀도 중 어디에 중점을 두는지에 따라 이러한 옵션 중에서 선택할 수 있습니다.
외부 검색을 통한 활용 범위 확대: FDW를 통한 외부 검색 추가로 AlloyDB의 도달범위가 Elasticsearch와 같은 전문 검색 백엔드로 확장됩니다. 이를 통해 익숙한 PostgreSQL 인터페이스를 유지하면서 전용 검색 클러스터의 우수한 확장성과 고급 검색 기능을 활용할 수 있습니다. AlloyDB AI는 이러한 외부 결과를 하이브리드 검색 프레임워크에 직접 통합함으로써 가장 방대한 텍스트 저장소도 벡터 기반 시맨틱 인사이트와 결합할 수 있도록 보장합니다.

AlloyDB AI는 데이터베이스 커널 내에서 스코어링, 조인, 재순위 지정의 복잡성을 통합합니다. 또한 최적화되고 지연 시간이 짧은 내부 FTS를 위해 RUM을 활용하거나 전문화되고 확장 가능한 백엔드를 위해 외부 검색을 활용하는 FTS에 대한 이중 경로 접근 방식을 제공함으로써 강력하고 독립적인 검색 기반을 제공합니다. 이처럼 두 가지를 함께 사용하는 방식은 전체 하이브리드 검색 스토리에 필수적이며 워크로드, 데이터 볼륨, 기존 인프라에 따라 최적의 경로를 선택할 수 있는 유연성을 제공합니다. 이제 높은 성능과 간편한 유지보수를 갖춘 검색 아키텍처를 기반으로 지능형 애플리케이션 기능을 빌드하는 데 집중할 수 있습니다.

실제 작동 방식 보기

AlloyDB가 최고의 하이브리드 검색엔진인 이유를 알아보세요.

AlloyDB의 BM25 지원에 대해 알아보세요.

시작하기

AI 워크로드의 속도와 비용 효율성을 높일 준비가 되셨나요?

AlloyDB 사용이 처음이신가요? 30일 무료 체험판으로 AlloyDB를 살펴보세요.
하이브리드 검색 시작하기: 텍스트 검색 색인을 설정하고 벡터 검색 색인을 선택합니다. 이러한 항목이 생성되면 다양한 하이브리드 검색 쿼리를 수행하는 몇 가지 예시를 확인할 수 있습니다.
외부 검색: AlloyDB에서 외부 데이터 래퍼와 외부 테이블을 만들어 Elasticsearch, Solr 또는 OpenSearch의 외부 데이터를 쿼리합니다.

대규모 관리형 Apache Iceberg: Spanner가 Lakehouse 런타임 카탈로그를 지원하는 방법

Tue, 13 Oct 2026 10:00:00 +0000

고객이 레이크하우스 아키텍처로 현대화함에 따라 호환되는 엔진 전반에서 공유 데이터 자산을 생성하기 위해 Apache Iceberg와 같은 개방형 형식을 표준으로 채택하고 있습니다. 이를 통해 데이터를 시맨틱 지식으로 전환하고, 선제적인 조치를 취하고, 에이전트 규모로 운영되는 AI 네이티브 레이크하우스를 빌드할 수 있습니다.

레이크하우스의 핵심 구성요소 중 하나는 카탈로그이며, Apache Iceberg 환경에서는 일반적으로 Iceberg REST 카탈로그를 의미합니다. Apache Iceberg 카탈로그는 테이블 포인터를 관리하고, 원자적 커밋을 처리하며, 테이블 위치에 대한 단일 정보 소스 역할을 합니다. 하지만 대규모 엔터프라이즈 조직이 레이크하우스로 전환하며 현대화를 추진함에 따라, 레이크하우스 아키텍처의 핵심 요소로서 확장성과 가용성이 뛰어난 관리형 카탈로그가 필요하다는 사실을 깨닫기 시작했습니다. 이는 에이전트를 통해 쿼리 규모가 확장될수록 더욱 중요해집니다. 에이전트의 수많은 반복적인 소규모 쿼리를 지원하려면 원자성, 일관성, 가용성, 동시 실행을 대규모로 제공하는 관리형 카탈로그를 기반으로 시스템을 구축해야 합니다.

이 블로그에서는 에이전트 규모의 최신 클라우드 환경에서 관리형 카탈로그가 직면하는 과제를 살펴보고 Google Cloud의 서버리스 Lakehouse 런타임 카탈로그가 이러한 과제를 해결하는 데 어떻게 도움이 되는지 보여줍니다. 사실상 무제한으로 확장되는 Google Cloud의 상시 가동 데이터베이스인 Spanner를 기반으로 하며, 개방형 Apache Iceberg REST 카탈로그 사양에 맞춰 빌드된 Lakehouse 런타임 카탈로그는 에이전트 시대에 필요한 확장성과 가용성이 뛰어난 기반을 제공합니다.

레이크하우스에서 관리형 카탈로그가 해결해야 하는 과제

레이크하우스에서 대규모 프로덕션 분석을 운영하는 데이터 엔지니어 및 인프라 리드와 이야기를 나누다 보면 다음과 같은 핵심 고충 사항이 공통적으로 나타납니다. 이러한 문제는 관리형 카탈로그를 통해 반드시 해결해야 할 과제입니다.

원자적 커밋 및 동시 실행 제어: Iceberg는 낙관적 동시 실행 제어(OCC)를 통해 ACID 트랜잭션을 보장합니다. 관리형 카탈로그는 현재 메타데이터 포인터를 교체하기 위해 어떠한 오류도 허용하지 않는 완벽한 원자적 비교 및 바꾸기(CAS) 작업을 구현해야 합니다.

고가용성 및 운영 유지보수: 카탈로그가 다운되면 쿼리가 즉시 실패하므로 관리형 카탈로그는 중요한 Tier-1 서비스가 됩니다.

카탈로그를 지원하는 데이터베이스 확장: 카탈로그 설계자는 일반적으로 테이블 메타데이터와 상태를 위한 지원 데이터베이스를 선택할 때 어려운 절충점에 직면합니다. 기존의 수직 확장 관계형 데이터베이스는 SQL 및 ACID 트랜잭션을 제공하지만, 동시 읽기/쓰기 부하가 심해지면 CPU, 메모리, 스토리지, 연결 등 물리적 한계에 부딪히게 됩니다. 이를 해결하기 위해 수동으로 샤딩하면 막대한 운영 오버헤드가 발생합니다. 반면, 수평 확장 데이터베이스 시스템은 eventual consistency를 갖거나, 관리가 어렵거나, 엔터프라이즈 환경에 적합하지 않는 등의 여러 문제를 안고 있는 경우가 많습니다.

테이블 유지보수 조정: 카탈로그만으로는 데이터를 최적화할 수 없습니다. 압축, 스냅샷 만료, 매니페스트 재작성, 분리된 파일 정리를 위한 보조 파이프라인을 빌드하고 운영해야 합니다.

거버넌스 및 보안: 카탈로그는 보안 게이트키퍼 역할을 합니다. 카탈로그는 다음 사항을 구현하고 관리해야 합니다.

인증 프로토콜(예: OAuth2 토큰 교환, IAM 제휴)
네임스페이스 및 테이블 수준까지 액세스 제어
판매된 스토리지 사용자 인증 정보(예: 쿼리 엔진에 광범위하고 직접적인 스토리지 사용자 인증 정보가 필요하지 않도록 단기 토큰 생성)

Lakehouse 런타임 카탈로그

이러한 과제를 해결하기 위해 Google Cloud는 Iceberg REST 카탈로그를 지원하는 Lakehouse 런타임 카탈로그(정식 버전)를 빌드했습니다. Lakehouse 런타임 카탈로그는 Apache Iceberg와 같은 최신 개방형 테이블 형식을 지원하도록 처음부터 설계된 완전한 서버리스 기반의 고가용성 통합 메타데이터 레지스트리입니다. Lakehouse 런타임 카탈로그는 Apache Iceberg REST 카탈로그 사양을 기본적으로 구현하여 메타데이터 검색을 컴퓨팅 엔진에서 분리함으로써 여러 Iceberg 호환 엔진이 공유 데이터 자산에 액세스할 수 있도록 보장하고 워크로드를 더 빠르게 프로덕션으로 전환할 수 있도록 지원합니다. Google Cloud는 많은 고객이 관리형 카탈로그를 원활하게 마이그레이션할 수 있도록 지원해 왔습니다. 예를 들어 Etsy는 자사 카탈로그를 Lakehouse 런타임 카탈로그로 마이그레이션하여, 데이터를 이동 없이 조인함으로써 파이프라인 쿼리 속도를 60% 향상했습니다.

이 방법은 다음과 같은 여러 가지 아키텍처 이점을 제공합니다.

개방형 API: Iceberg REST 카탈로그를 지원하므로 여러 팀이 단일 통합 데이터 세트에서 각자 선호하는 분석 도구를 사용할 수 있습니다.
멀티 엔진 상호 운용성: 등록된 테이블은 표준 REST 인터페이스를 통해 Google Cloud Managed Service for Apache Spark, BigQuery, 오픈소스 엔진 전반에서 즉시 검색하고 쿼리할 수 있습니다.
Iceberg 테이블의 읽기/쓰기 상호 운용성: BigQuery, Managed Spark와 같은 Iceberg 호환 엔진을 활용하여 Lakehouse 런타임 카탈로그에 등록된 Iceberg 테이블에 데이터를 기록할 수 있습니다. 고객은 Managed Spark를 사용하여 외부 카탈로그에 있는 Iceberg 테이블에 데이터를 기록할 수도 있습니다.
엔터프라이즈급 기능을 갖춘 완전 관리형 Iceberg 스토리지: Google의 차별화된 인프라를 사용하여 Iceberg 테이블에서 성능을 갖춘 분석을 실행합니다. 이를 통해 오픈소스의 유연성뿐만 아니라 성능, 확장성, 거버넌스, 멀티모달 처리의 이점을 누릴 수 있습니다.
데이터 복사 없음: 테이블 정의가 기본 객체 스토어의 기존 데이터를 직접 가리킵니다. 기본 데이터를 이동하거나 재작성하거나 복제할 필요가 없습니다.
클라우드 전반의 양방향 카탈로그 제휴:벤딩된 사용자 인증 정보 및 OIDC 토큰 교환을 지원하여 Databricks Unity, Snowflake Horizon, AWS Glue의 데이터에 액세스합니다. 이를 통해 Google AI를 AWS 및 Azure 데이터에 직접 적용할 수 있습니다.
사용자 인증 정보 벤더 제공을 사용한 보안 액세스: 카탈로그는 여러 승인 메커니즘을 지원하므로 사용자 인증 정보 벤더 제공과 최종 사용자 인증 정보 중에서 선택할 수 있습니다. 즉, 기본 객체 스토어(Cloud Storage, AWS S3, Azure Blob Storage)의 파일에 직접 액세스할 필요 없이 사용자 인증 정보 벤더 제공 같은 최신 메커니즘을 사용하여 테이블에 액세스할 수 있습니다.
AI 기반 컨텍스트 및 거버넌스: Lakehouse 런타임 카탈로그는 Knowledge Catalog 및 Cloud IAM과 직접 통합되므로 에이전트에 대한 신뢰할 수 있는 컨텍스트를 정의하고 모든 컴퓨팅 엔진에 테이블 수준 보안을 일관되게 적용할 수 있습니다. 카탈로그에서 Iceberg 테이블에 대한 즉시 사용 가능한 검색, 계보, 인사이트를 얻을 수 있습니다.
원자적 커밋 및 동시 실행 제어, 고가용성 및 확장성: Google의 전 세계 규모 인프라와 Spanner를 기반으로 데이터와 함께 메타데이터를 확장하는 데 필요한 고가용성, 동시 실행, 확장성을 확보할 수 있습니다. Cloud Storage 이중 리전 및 멀티 리전 버킷을 지원하여 장애 조치 사용 사례를 지원합니다. 또한 서버리스와 노옵스(no-ops) 환경을 통해 TCO가 절감되고 모든 워크로드 규모에 맞게 확장할 수 있습니다.

Lakehouse 런타임 카탈로그의 원동력

Lakehouse 런타임 카탈로그는 Spanner를 기반으로 빌드되어 strong consistency가 보장되는 가용성이 높고 동시 실행 및 확장성이 뛰어난 카탈로그입니다. 수직적 단일 노드 한계에 부딪히는 기존의 수직 확장형 관계형 데이터베이스와 달리, Spanner는 완전한 관계형 SQL 시맨틱 및 멀티 테이블 ACID 트랜잭션을 NoSQL 시스템의 장점인 읽기와 쓰기 모두에 대한 수평 확장 탄력성과 결합했습니다.

Spanner는 최대 99.99%의 가용성을 제공하는 Spanner의 리전 구성을 통해 Lakehouse 런타임 카탈로그의 가용성을 높입니다. 또한 Spanner는 Lakehouse 런타임 카탈로그에 즉시 사용 가능한 확장성을 제공합니다. 수평 확장 가능한 데이터베이스인 Spanner는 수동 샤딩이 필요하지 않으며 컴퓨팅과 스토리지를 독립적이고 투명하게 확장합니다. Spanner는 데이터 볼륨과 쿼리 부하를 동적으로 모니터링하여 데이터 범위를 분할하고 노드 간에 재배포합니다. 컴퓨팅 노드는 CPU 사용률과 스토리지 기준점에 따라 동적으로 확장됩니다. Spanner는 분할 수준의 과부하를 자동으로 감지하여, 부하가 집중된 노드에서 사용량이 많은 분할을 다른 곳으로 알아서 이동해 줍니다. 또한 Spanner를 사용하면 Lakehouse 런타임 카탈로그 사용자가 관계형 일관성과 분산 확장성 간의 기존 절충점을 극복하고, Lakehouse 런타임 카탈로그의 업계 선도적인 일관성 보장 기능을 활용할 수 있습니다. Lakehouse 트랜잭션은 직렬화가 가능합니다. 데이터베이스 내 트랜잭션 순서는 클라이언트가 커밋된 트랜잭션을 관찰하는 순서와 동일합니다. 이러한 기반을 통해 Lakehouse 사용자는 에이전트 규모로 운영할 수 있습니다.

또한 에이전트 사용 사례를 더욱 강화하기 위해 Lakehouse 런타임 카탈로그는 Knowledge Catalog와 직접 통합되어 레이크하우스 Iceberg 테이블을 쉽게 검색하고 에이전트에 신뢰할 수 있는 컨텍스트를 제공합니다. Knowledge Catalog는 Spanner에서 제공하는 전체 텍스트 검색과 기본 벡터 검색의 효율적인 조합을 활용합니다. 이러한 접근 방식을 사용하면 단일 쿼리에서 어휘 키워드 검색과 시맨틱 임베딩을 페어링하여 검색 재현율을 높일 수 있습니다. 두 색인 유형 모두 동일한 기본 데이터 세트를 기반으로 빌드되므로, 기본 테이블 DML 작업과 동시에 엄격한 트랜잭션 ACID 일관성을 유지하며 업데이트됩니다. 이를 통해 동기화 파이프라인, 외부 벡터, 전체 텍스트 검색 시스템 관리와 같은 운영 오버헤드를 줄일 수 있습니다. 요약하자면, Lakehouse 런타임 카탈로그를 통해 에이전트형 사용 사례의 출시 기간(TTM)을 단축할 수 있습니다.

분석 워크로드와 운영 워크로드 결합

Apache Iceberg를 기반으로 하는 Google Cloud의 경계 없는 레이크하우스를 사용하면 분석 데이터를 운영 워크로드와 결합할 수 있습니다. 사용 사례로는 레이크하우스의 데이터 애셋을 OLTP 데이터(Spanner)와 결합하여 분석하는 것부터, Spanner와 같은 운영 데이터베이스에서 레이크하우스 애셋에 액세스할 수 있는 지연 시간이 짧은 서빙 애플리케이션, 퍼스트 파티 및 서드 파티 에이전트의 대화형 분석에 이르기까지 다양합니다.

아래 예시를 통해 Spanner와 결합된 Lakehouse 런타임 카탈로그가 실제로 어떻게 작동하는지 확인할 수 있습니다. 여기서는 Apache Iceberg를 기반으로 하는 맨해튼 택시 운행 분석 데이터와 Spanner에 저장된 택시 구역 운영 데이터를 결합하여 가장 혼잡한 교통 경로를 찾아봅니다. 또한 이 예시에서는 대화형 분석 에이전트를 사용하여 동일한 데이터에 액세스하고 2차 인사이트를 얻을 수 있음을 보여줍니다.

맨해튼에서 가장 정체가 심한 교통 경로 확인하기

경계 없는 레이크하우스로 현대화

Google Cloud의 레이크하우스로 현대화하면 분석 엔진과 에이전트 전반에서 데이터 사일로를 최소화하고, 멀티 엔진 거버넌스를 통합하고, 에이전트에 신뢰할 수 있는 컨텍스트를 제공하고, 운영 TCO를 대폭 절감할 수 있습니다. Spanner 기반 Lakehouse 런타임 카탈로그를 활용하면 에이전트 규모로 운영할 수 있도록 최신 클라우드 환경을 준비하는 데 도움이 됩니다. 자세히 알아보고 무료 체험을 시작하려면

레이크하우스 웹페이지를 방문하고 Spanner에 관한 자세한 내용은 여기에서 확인해 보세요.

AlloyDB 및 Memorystore for Valkey에서 장기 AI 에이전트 메모리를 구현하는 방법

Mon, 12 Oct 2026 17:00:00 +0000

엔터프라이즈 AI 에이전트가 복잡하고 며칠에 걸친 워크플로와 장기 작업을 실행하려면 영구 메모리가 필요합니다. 이 블로그에서는 단기 버퍼 메모리용 Memorystore for Valkey와 장기 영구 메모리용 AlloyDB AI를 사용하는 2계층 메모리 아키텍처가 중요한 데이터와 엔터프라이즈 가드레일을 유지하면서 토큰 지출을 최대 70%까지 줄이는 데 어떻게 도움이 되는지 살펴봅니다.

사용자의 휴가 예약을 돕도록 설계된 맞춤형 여행 에이전트를 빌드한다고 상상해 보세요. 사용자는 며칠에 걸쳐 에이전트와 여러 차례 상호작용하며 여행 일정 브레인스토밍부터 실제 구매 의도 관련 질문까지 다양한 질문을 합니다. 진정으로 원활한 사용자 경험을 제공하려면 이 에이전트는 이전 세션에서 설정된 항공편 선호도(예: '직항 항공편만'), 호텔 예산, 식단 제한 사항(예: '글루텐 프리 식사 옵션 필요')을 기억해야 합니다. 더 중요한 것은 대화가 관광지 추천과 일정 계획과 같은 세부 사항으로 깊이 들어가더라도 이러한 핵심 사실을 계속 유지해야 한다는 점입니다. 에이전트는 모든 후속 질문과 방문할 장소에 대한 흥미로운 세부정보로 인해 사용자의 기본적인 요구사항과 결정을 잊거나 덮어쓰지 않도록 해야 합니다.

스테이트풀(Stateful) 워크플로는 본질적으로 LLM의 스테이트리스(Stateless) 특성과 충돌합니다.

AI 에이전트는 멀티턴 대화와 장기 실행 워크플로에 사용되지만, 대규모 언어 모델(LLM)은 세션 간에 상태를 유지하지 않습니다. 사용자가 며칠 후 다시 에이전트를 사용하면 모델은 빈 컨텍스트 윈도우로 시작합니다. 애플리케이션이 장기 에이전트 메모리를 사용하여 과거 컨텍스트를 재구성하도록 빌드되지 않은 경우, 사용자는 매번 목표와 컨텍스트를 다시 설명해야 하므로 실망스럽고 단편적인 경험을 하게 됩니다.

이제 백만 토큰 규모의 컨텍스트 윈도우가 표준이 되면서 이 문제에 대한 일반적인 해결 방법은 '컨텍스트 스터핑'입니다. 즉, 원시 채팅 기록부터 도구 실행 로그에 이르기까지 프롬프트에 들어갈 수 있는 모든 내용을 턴마다 덤프하는 것입니다. 실제로 이는 AI 모델 사용 초기에 흔히 볼 수 있는 패턴이었습니다. 하지만 이러한 임시방편은 규모가 커지면 금방 문제가 됩니다. 메시지마다 토큰 비용이 배로 늘어나고, 간단한 프롬프트인데도 응답 시간이 30초 이상으로 길어질 수 있으며, 모델이 산더미 같은 프롬프트 텍스트에 묻힌 중요한 요청 사항을 간과하게 되어 '중간에서 길을 잃는' 성능 저하를 겪기 시작합니다.

또 다른 일반적인 해결 방법은 롤링 요약을 사용하는 것입니다. LLM에 이전 메시지를 주기적으로 요약 단락으로 압축하도록 요청하는 것입니다. 이렇게 하면 프롬프트 크기가 줄어들지만, LLM 기반 요약은 본질적으로 정보 손실이 발생합니다. 몇 차례 압축을 거치면 미묘하지만 중요한 세부정보가 백그라운드 노이즈로 간주되어 필터링됩니다. 몇 차례 대화가 오가고 나면 에이전트는 앞서 설정한 정확한 제약 조건을 은연중에 위반합니다. 한마디로, 이전 대화나 멀티턴 작업의 메모리를 유지하면서도 사용자 경험을 저하시키거나 새로운 병목 현상을 일으키지 않는 더 확장 가능한 접근 방식이 필요합니다.

2계층 메모리 아키텍처 구현

가드레일과 제약 조건을 준수하는 신뢰할 수 있고 비용 효율적인 엔터프라이즈 에이전트를 빌드하려면 2계층 메모리 아키텍처를 사용하는 것이 좋습니다.

단기 세션 버퍼: 토큰 제한 슬라이딩 윈도우를 사용하여 활성 대화 턴을 메모리에 캐시하므로 여러 라운드에 걸쳐, 심지어 기기 간에도 컨텍스트 윈도우 크기를 안정적으로 유지하면서 최신 메시지를 최신 상태로 유지할 수 있습니다. 이 계층에서는 매 턴마다 1밀리초 미만의 높은 처리량 조회가 필요하므로 Memorystore for Valkey가 활성 세션 상태를 유지하는 데 적합합니다.
장기 영구 메모리: 중요한 사실, 사용자 환경설정, 에피소드 사실을 세션 전반에 걸쳐 저장합니다. 이 계층에는 트랜잭션 무결성, 데이터 거버넌스, 관계형 데이터와 벡터 전반의 하이브리드 검색이 필요하며, 이러한 기능은 AlloyDB AI에서 네이티브로 제공됩니다.

장기 메모리와 활성 세션 버퍼를 모두 관계형 데이터베이스에 직접 저장할 수도 있지만, 인메모리 캐시가 있는 2계층 아키텍처가 더 나은 성능과 확장성을 제공할 수 있습니다. 활성 세션 버퍼는 매우 일시적이며 모든 대화 턴에서 1밀리초 미만의 고처리량 업데이트가 필요합니다. 인메모리 키-값 캐시에서 이러한 빠른 쓰기를 처리하면 관계형 데이터베이스에서 쓰기 증폭과 테이블 비대화를 방지할 수 있습니다. 그렇지 않으면 빈번한 행 삭제와 집중적인 비우기가 필요합니다. 이는 데이터베이스 앞에 캐싱 계층을 추가하여 핫 행에 대한 고빈도 조회를 오프로드하는 것과 유사합니다. 이러한 업무 분담을 통해 기본 데이터베이스는 가볍고 반응성이 뛰어난 상태를 유지하며, 트랜잭션 일관성, 복잡한 하이브리드 벡터 검색, 장기 분석 쿼리 실행 등 본래 설계된 목적에 리소스를 집중할 수 있습니다.

Memorystore for Valkey의 단기 캐싱과 네이티브 AlloyDB AI 기능을 결합하면 데이터베이스 계층 내에서 직접 항목 추출, 메모리 압축, 교차 세션 메모리, 하이브리드 검색을 실행하여 활성 프롬프트를 간결하고 빠르며 비용 효율적으로 유지할 수 있습니다.

aside_block: <ListValue: [StructValue([('title', 'AlloyDB 30일 무료 체험 인스턴스를 시작해 보세요'), ('body', <wagtail.rich_text.RichText object at 0x7fad742c2d50>), ('btn_text', ''), ('href', ''), ('image', None)])]>

네 가지 메모리 유형 이해하기

장기 에이전트 상태를 효과적으로 구성하기 위해, 에이전트 메모리를 앞서 설명한 단기 및 장기 스토리지 계층 전반에서 네 가지 상호 보완적인 유형으로 더 세분화하면 다음과 같습니다.

메모리 유형	저장하는 항목	스토리지 레이어	수명
버퍼(단기)	최근 원시 대화 턴	Memorystore for Valkey	활성 세션
요약 메모리	일반적으로 '압축'이라고 부르는 이전 대화의 압축된 기록	Memorystore for Valkey	멀티턴 윈도우
에피소드 메모리	과거 작업, 이벤트, 도구 출력	PostgreSQL용 AlloyDB(정형 SQL + 전체 텍스트 검색 + 벡터를 사용한 하이브리드 검색)	영구 보관
항목 및 규칙 메모리	사용자 환경설정, 제약 조건, 거부권	PostgreSQL용 AlloyDB(정형 SQL + 전체 텍스트 검색 + 벡터를 사용한 하이브리드 검색)	영구 보관

단기 대화 컨텍스트를 정형화된 장기 규칙과 분리함으로써 에이전트는 원시 상호작용 로그로 토큰 윈도우를 채우지 않고도 필요에 따라 관련 컨텍스트를 검색할 수 있습니다.

계층형 메모리 아키텍처 청사진

아래 다이어그램은 애플리케이션 조정 레이어, Memorystore for Valkey 단기 버퍼, AlloyDB AI 장기 저장소를 연결하는 읽기 및 쓰기 경로를 보여줍니다.

이 시스템은 조정된 두 가지 실행 경로를 통해 작동합니다.

읽기 경로: 사용자가 질문하면 애플리케이션은 Memorystore for Valkey에서 활성 슬라이딩 윈도우를 가져오고, ai.generate를 사용하여 데이터베이스 내 쿼리 정규화를 실행하고, ai.hybrid_search를 사용하여 AlloyDB를 쿼리하여 범위가 지정된 항목 규칙과 관련 에피소드 사실을 검색합니다.
쓰기 경로: 응답을 생성한 후 해당 대화 턴은 즉시 Memorystore for Valkey에 캐시됩니다. 비동기 백그라운드 큐 작업자가 대화에서 정형 항목을 추출하여 AlloyDB에 직접 기록하면, 트랜잭션 기반 자동 임베딩이 데이터베이스에서 벡터 표현을 즉시 계산하고 저장합니다.

비즈니스 영향 및 ROI

멀티턴 개발 대화(도구 실행이 많은 45턴 이상)에 대한 벤치마크 테스트에서 단기 캐싱을 장기 지속성과 분리하면 단순한 컨텍스트 스터핑에 비해 측정 가능한 비용 및 성능 개선이 확인되었습니다.

측정항목 / 측정기준	단순한 컨텍스트 스터핑	계층형 메모리(AlloyDB + Valkey)	순 비즈니스 영향
활성 프롬프트 크기(45턴)	토큰 747,033개	토큰 83,262개	프롬프트 크기 88.9% 감소
45번째 턴 응답 지연 시간	33.5초	6.7초	80.0% 더 빠른 응답
턴당 응답 대기 시간	33.5초	4.2초~6.7초	36%~80% 감소
누적 세션 토큰	토큰 1,790만 개	토큰 409만 개	토큰 및 비용 72.0% 절감
규칙 및 제약 조건 재현율	턴이 지날수록 저하됨	저하되지 않음	ACID 보존 재현율

참고: 위의 측정항목은 여러 세션, 프로젝트, 컨텍스트 전환에 걸쳐 개발자와 상호작용하는 실제 엔터프라이즈 AI 페어 프로그래밍 어시스턴트를 모방하여 시뮬레이션된 개발자 워크로드의 내부 벤치마크 결과를 반영합니다. 실제 절감액과 지연 시간은 프롬프트 구조, 쿼리 빈도, 데이터 볼륨에 따라 달라집니다.

이러한 결과는 계층형 메모리가 에이전트 단위 경제성을 어떻게 변화시키는지 보여줍니다. 턴이 추가될 때마다 비용 곡선이 상승하는 대신, 프롬프트 크기가 제한되어 지속적인 LLM API 비용을 줄이면서도 빠른 응답 시간을 유지할 수 있습니다.

AlloyDB AI의 핵심 기술적 이점

AlloyDB AI는 핵심 AI 기능을 데이터베이스 엔진에 직접 임베딩하여 영구 에이전트 메모리를 구현하는 데 드는 운영 오버헤드를 줄입니다.

트랜잭션 데이터베이스 내 자동 임베딩(ai.initialize_embeddings): AlloyDB는 Agent Platform(이전 명칭: Vertex AI)과의 네이티브 통합을 사용하여 텍스트 열에 대한 벡터 임베딩을 자동으로 생성하며, 초당 최대 3,000개의 임베딩을 생성합니다. incremental_refresh_mode => 'transactional'을 사용하면 AlloyDB는 동일한 트랜잭션 내에서 소스 데이터가 변경될 때 임베딩을 최신 상태로 유지하므로 커스텀 임베딩 파이프라인, 외부 스케줄러 또는 복잡한 재시도 로직이 필요하지 않습니다.
데이터베이스 내 생성형 AI 함수(ai.generate): AlloyDB를 사용하면 SQL 쿼리에서 직접 Gemini와 같은 파운데이션 모델을 실행할 수 있습니다. 이를 통해 애플리케이션에서 별도의 왕복 없이 데이터베이스 내 쿼리 분해(복합적인 사용자 질문을 단일 측면의 하위 쿼리로 분해하고 '마지막 세션'과 같은 상대적인 시간 구문을 명시적인 식별자로 해결)를 수행할 수 있습니다.
Reciprocal Rank Fusion(ai.hybrid_search)이 기본 제공되는 네이티브 하이브리드 검색: AlloyDB는 엔진 내에서 직접 상호 순위 융합(RRF)을 실행하는 기본 제공 SQL 함수를 제공합니다. 이 기능은 단일 데이터베이스 호출에서 벡터 코사인 유사성(HNSW 또는 ScaNN 색인에 대한 <=>)과 PostgreSQL 전체 텍스트 검색(BM25, RUM 또는 GIN 사용)을 결합하여 시맨틱 매칭과 정확한 키워드 검색을 혼합하는 동시에 메타데이터 필터 푸시다운(filter_condition)을 지원하여 성능을 개선하고 결정론적 범위 격리를 제공합니다.
IAM 사용자 인증 정보를 사용한 직접적인 Agent Platform 통합: AlloyDB는 Google Cloud IAM 서비스 계정 역할과 데이터베이스 인증을 사용하여 Google Cloud의 비공개 네트워크를 통해 Agent Platform 파운데이션 모델에 직접 연결하므로 애플리케이션 코드에 API 키를 저장하거나, 주기적으로 순환하거나, 전달할 필요가 없습니다.
통합 운영, 벡터, 거버넌스 엔진: AlloyDB는 관계형 비즈니스 데이터, 벡터 임베딩, 전체 텍스트 색인, 엔터프라이즈 권한을 단일 ACID 호환 PostgreSQL 데이터베이스에 통합하여 별도의 운영 및 벡터 데이터베이스 전반에서 데이터 드리프트와 통합 복잡성을 방지합니다.

주요 구현 패턴

다음은 2계층 메모리 아키텍처를 구성하는 데 사용되는 핵심 데이터베이스 패턴입니다. 전체 러너블 Python 및 SQL 스크립트는 함께 제공되는 AlloyDB 에이전트 메모리 Codelab을 참고하세요.

1. 스키마 및 자동 임베딩 설정

AlloyDB에서 필요한 확장 프로그램을 설치하고 정형 메타데이터, 전체 텍스트 검색을 위해 생성된 tsvector 열, 벡터 임베딩 열을 사용하여 agent_entities 테이블을 정의합니다.

code_block: <ListValue: [StructValue([('code', "-- 1. Enable AI extensions\r\nCREATE EXTENSION IF NOT EXISTS google_ml_integration CASCADE;\r\nCREATE EXTENSION IF NOT EXISTS vector CASCADE;\r\nCREATE EXTENSION IF NOT EXISTS rum CASCADE;\r\n\r\n-- 2. Create structured entity & preference table\r\nCREATE TABLE IF NOT EXISTS agent_entities (\r\n entity_id UUID PRIMARY KEY DEFAULT gen_random_uuid(),\r\n user_id TEXT NOT NULL,\r\n entity_name TEXT NOT NULL,\r\n project_id TEXT DEFAULT 'global',\r\n session_id TEXT,\r\n scope TEXT NOT NULL DEFAULT 'session',\r\n summary TEXT NOT NULL,\r\n summary_embedding VECTOR(768),\r\n summary_tsv TSVECTOR GENERATED ALWAYS AS (\r\n to_tsvector('english', entity_name || ' ' || summary)\r\n ) STORED,\r\n updated_at TIMESTAMPTZ DEFAULT NOW(),\r\n UNIQUE (user_id, entity_name)\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad7431dc50>)])]>

그런 다음 ai.initialize_embeddings를 사용하여 임베딩을 생성합니다. transactional 모드를 사용하면 소스 데이터가 변경될 때 임베딩이 최신 상태로 유지됩니다.

code_block: <ListValue: [StructValue([('code', "-- Register transactional in-database auto-embedding\r\nCALL ai.initialize_embeddings(\r\n model_id => 'text-embedding-005',\r\n table_name => 'agent_entities',\r\n content_column => 'summary',\r\n embedding_column => 'summary_embedding',\r\n incremental_refresh_mode => 'transactional',\r\n batch_size => 10\r\n);"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad7431de10>)])]>

마지막으로 HNSW 벡터 색인과 RUM 전체 텍스트 검색 색인을 만들어 하이브리드 검색이 빠르고 효율적으로 수행되도록 합니다.

code_block: <ListValue: [StructValue([('code', '-- Create vector and full-text indexes\r\nCREATE INDEX IF NOT EXISTS agent_entities_embedding_idx\r\n ON agent_entities USING hnsw (summary_embedding vector_cosine_ops);\r\n\r\nCREATE INDEX IF NOT EXISTS agent_entities_tsv_idx\r\n ON agent_entities USING rum (summary_tsv rum_tsvector_ops);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad7431c410>)])]>

2. 네이티브 하이브리드 검색으로 장기 메모리 쿼리

읽기 경로에서 ai.hybrid_search를 사용하여 관련 장기 항목을 검색합니다. 이 네이티브 SQL 함수는 AlloyDB에서 직접 Reciprocal Rank Fusion(RRF)을 실행하여 단일 데이터베이스 쿼리에서 벡터 유사성 검색과 전체 텍스트 키워드 검색 결과를 원활하게 재정렬하고 결합합니다.

code_block: <ListValue: [StructValue([('code', 'def retrieve_hybrid_entities(\r\n conn,\r\n user_id: str,\r\n project_id: str,\r\n query_text: str,\r\n query_vector_literal: str,\r\n limit: int = 3\r\n) -> dict[str, Any]:\r\n """Queries long-term memory using AlloyDB native hybrid_search (RRF)."""\r\n filter_cond = f"user_id = \'{user_id}\' AND (project_id = \'{project_id}\' OR scope = \'global\')"\r\n \r\n search_inputs = [\r\n json.dumps({\r\n "data_type": "vector",\r\n "weight": 0.4,\r\n "table_name": "agent_entities",\r\n "key_column": "entity_name",\r\n "vec_column": "summary_embedding",\r\n "distance_operator": "<=>",\r\n "limit": 10,\r\n "query_vector": query_vector_literal,\r\n "filter_condition": filter_cond\r\n }),\r\n json.dumps({\r\n "data_type": "text",\r\n "weight": 0.6,\r\n "table_name": "agent_entities",\r\n "key_column": "entity_name",\r\n "text_column": "summary_tsv",\r\n "limit": 10,\r\n "ranking_function": "ts_rank",\r\n "query_text_input": query_text,\r\n "filter_condition": filter_cond\r\n })\r\n ]\r\n\r\n query_sql = """\r\n SELECT e.entity_name, e.summary, e.project_id, e.scope, e.updated_at\r\n FROM ai.hybrid_search(\r\n search_inputs => %s::JSONB[],\r\n include_json_output => false\r\n ) h\r\n JOIN agent_entities e ON e.entity_name = h.id\r\n WHERE e.user_id = %s\r\n LIMIT %s;\r\n """'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad7431d450>)])]>

3. AI 함수를 사용한 데이터베이스 내 메모리 압축

커스텀 가지치기 스크립트를 작성하지 않고도 장기 스토리지 증가를 관리하기 위해 AlloyDB에서 직접 자동화된 추출 및 압축 쿼리를 실행하여 저장하면 이점이 있는 중요한 부분을 식별할 수 있습니다. 이 패턴은 ai.generate와 함께 SQL 공통 테이블 표현식(CTE)을 사용하여 오래된 에피소드 항목을 고밀도 요약으로 통합합니다.

code_block: <ListValue: [StructValue([('code', "-- Consolidate older episodic logs into a permanent summary\r\nWITH old_events AS (\r\n SELECT document AS content\r\n FROM langchain_pg_embedding\r\n WHERE cmetadata->>'user_id' = 'user_dev_42'\r\n AND created_at < NOW() - INTERVAL '30 days'\r\n ORDER BY created_at ASC\r\n LIMIT 50\r\n),\r\nconsolidated AS (\r\n SELECT ai.generate(\r\n 'Summarize these historical events into a dense memory paragraph:\\n' || string_agg(content, E'\\n'),\r\n model_id => 'gemini-3.5-flash'\r\n ) AS summary_text\r\n FROM old_events\r\n)\r\nINSERT INTO agent_entities (user_id, entity_name, summary, updated_at)\r\nSELECT 'user_dev_42', 'longterm_session_summary', summary_text, NOW()\r\nFROM consolidated\r\nWHERE summary_text IS NOT NULL\r\nON CONFLICT (user_id, entity_name)\r\nDO UPDATE SET summary = EXCLUDED.summary, updated_at = NOW();"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad7431c7d0>)])]>

예를 들어 자녀와 함께 이용할 항공편을 변경하는 복잡한 과정에 대한 긴 상호작용을 '직항 항공편을 선호합니다'라는 요약으로 정리할 수 있습니다.

4. 2계층 메모리 아키텍처를 ADK 에이전트에 연결

핵심 2계층 메모리 아키텍처가 구성되면 이제 함께 제공되는 Codelab에 표시된 대로 기본 ADK 메모리 프로바이더를 확장하여 이 2계층 메모리 아키텍처를 사용할 수 있습니다(예: ADKTieredMemoryProvider). 장기 메모리를 ADK 에이전트에 연결하려면 다음과 같이 도구(예: longterm_memory_tool)로 제공하면 됩니다.

code_block: <ListValue: [StructValue([('code', 'from adk_memory_provider import ADKTieredMemoryProvider\r\n\r\nagent = Agent(\r\n name="adk_memory_agent", model=GEMINI_MODEL, instruction="Initial instruction",\r\n tools=[long_term_memory_tool, run_command_tool],\r\n before_tool_callback=guardrail.create_before_tool_callback(USER_ID, "CloudRetail")\r\n)'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad66c19b50>)])]>

엔터프라이즈 거버넌스 및 멀티 테넌트 보안

엔터프라이즈 프로덕션 환경에서 에이전트 메모리를 실행하려면 엄격한 보안 경계와 액세스 제어가 필요합니다. 먼저 범위 및 멀티 테넌트 격리를 유지해야 합니다. agent_entities에서 user_id, project_id, scope 열을 색인화하고 PostgreSQL 행 수준 보안(RLS)을 적용하면 동일한 데이터베이스 클러스터 내에서 부서, 팀, 개별 사용자 간에 메모리 저장소를 격리할 수 있습니다. 파라미터화된 보안 뷰(PSV)는 또 다른 결정론적 애플리케이션 수준 보안 레이어를 제공하여 악의적인 프롬프트와 지나치게 광범위한 SQL 쿼리로부터 보호합니다.

또한 위의 구현 패턴에서 볼 수 있듯이 자동화된 메모리 수명 주기 관리를 제공해야 합니다. 예약된 SQL 압축 쿼리와 시간 기반 파티션 가지치기를 결합하면 시간이 지나도 예측 가능한 데이터베이스 사용 공간과 쿼리 지연 시간을 유지하는 데 도움이 됩니다. 이 접근 방식에 대한 자세한 내용은 함께 제공되는 Codelab을 참고하세요.

요약 및 다음 단계

활성 컨텍스트 윈도우를 영구 스토리지에서 분리하는 것은 프로덕션에 즉시 사용 가능한 AI 에이전트를 빌드하는 실용적인 접근 방식입니다. 1밀리초 미만의 세션 캐싱을 위한 Memorystore for Valkey와 트랜잭션 장기 스토리지를 위한 AlloyDB AI를 함께 사용하면 장기 작업과 멀티턴 에이전트 경험 전반에서 엄격한 비즈니스 규칙을 유지하면서도 토큰 비용을 대폭 절감하고 더 빠른 응답 시간을 달성할 수 있습니다.

시작하려면 다음 안내를 따르세요.

AlloyDB 에이전트 메모리 Codelab에서 제공하는 전체 실무형 튜토리얼을 단계별로 진행하여 실제 작동하는 2계층 메모리 아키텍처를 배포해 보세요.
AlloyDB AI 문서에서 데이터베이스 측 머신러닝 기능에 대해 자세히 알아보세요.
자동 벡터 임베딩 생성 및 하이브리드 벡터 검색 실행에 대한 가이드를 살펴보세요.

Spanner 큐 출시: 에이전트 워크로드 등을 위한 트랜잭션 메시징

Mon, 12 Oct 2026 17:00:00 +0000

AI 에이전트는 단순히 쿼리에 답하는 데 그치지 않고 자율적으로 환불을 처리하고, 인벤토리를 관리하며, 다단계 핸드오프를 실행하고, 하위 에이전트를 조정하는 등 복잡한 에이전트 워크플로를 수행할 수 있습니다. 이로 인해 에이전트는 운영 데이터베이스에서 내부 상태를 유지하면서 별도의 메시징 또는 이벤트 큐 시스템을 통해 비동기 작업을 디스패치해야 하는 경우가 많습니다. 하지만 안타깝게도 이러한 애플리케이션을 개발하는 팀 입장에서는, 커밋 시점이 서로 맞지 않는 두 시스템을 관리하면 에이전트형 시스템의 트랜잭션 일관성이 훼손됩니다.

오늘 Google Cloud는 Spanner에 직접 내장된 기본 트랜잭션 메시징인 Spanner 큐의 정식 버전이 출시되었다는 기쁜 소식을 전해드립니다. 신뢰할 수 있는 에이전트 실행을 위해 특별히 설계된 Spanner 큐를 사용하면, 메시지 생성은 트랜잭션 내에서 또 하나의 쓰기 작업을 수행하는 것만큼이나 간단해집니다. 에이전트의 상태 변경과 의도된 다운스트림 작업은 원자적으로 함께 커밋되거나 그렇지 않을 경우 완전히 실패합니다.

기존 방식과 비교해 보겠습니다. 데이터베이스 상태 업데이트는 성공했지만 작업 디스패치에 실패하는 경우, AI 에이전트는 수행할 작업은 결정했으나 실제 실행은 하지 못하는 상태가 됩니다. 메시지 디스패치가 성공했지만 상태 트랜잭션이 롤백되면 에이전트가 잘못된 상태를 기반으로 작업을 실행합니다. 비동기 멀티 에이전트 조정에서 발생하는 재시도, 추측 실행, 경합 상태는 이러한 오류를 더욱 악화시켜, 결국 개발자가 복잡한 아웃박스 패턴, 멱등성 레이어, 조정 작업자를 직접 구축해야만 하며, 이는 에이전트형 아키텍처에 막대한 신뢰성 부담을 안겨줍니다.

에이전트형 아키텍처의 주요 기능

Spanner 큐는 인프라 오버헤드를 발생시키지 않고 이러한 복잡한 비동기 워크플로를 지원하는 몇 가지 핵심 기능을 제공합니다.

원자적 '결정 및 실행' 큐 추가. 단일 Spanner 읽기-쓰기 트랜잭션 내에서 에이전트는 내부 메모리 또는 상태 테이블을 업데이트하고 동시에 피어 에이전트에 태스크를 큐에 추가할 수 있습니다. Spanner의 엄격한 직렬화 가능성과 전역 외부 일관성을 기반으로 상태 변경과 실행 의도가 단일 원자 단위로 커밋됩니다.

예약된 실행 및 지연. 큐 메시지는 커밋 즉시 디스패치되거나 향후 전송되도록 예약할 수 있습니다. 지연된 재시도, 예약된 에이전트 체크인, SLA 에스컬레이션 타이머와 같은 에이전트 패턴은 외부 cron 스케줄러나 폴링 인프라 없이도 메모리 업데이트와 함께 트랜잭션 방식으로 큐에 추가할 수 있습니다.

에이전트 작업자를 위한 스트리밍 SQL 가져오기. 자율 에이전트는 스트리밍 SQL 읽기를 통해 작업을 동적으로 가져와 처리합니다. 에이전트 런타임은 수신되는 작업을 스트리밍하고, 용량이 확보되는 대로 처리하며, 트랜잭션 내에서 작업 완료를 확인하여 엔드 투 엔드 작업 실행 상태의 안정성을 보장합니다.

에피소드 메모리 지속성 및 핸드오프. 장기 에피소드 요약, 반영 상태 전환, 하위 에이전트 간 컨텍스트 핸드오프를 포함한 에이전트 메모리 업데이트는 큐를 통해 비동기적이면서도 트랜잭션 방식으로 유지될 수 있습니다. 이를 통해 에이전트의 내부 메모리가 실시간 대화형 턴을 차단하지 않고도 실행 기록과 완전히 동기화된 상태를 유지할 수 있습니다.

Spanner 큐가 자율 에이전트에 필수적인 이유

트랜잭션 기반의 에이전트 '정확히 한 번' 실행: 에이전트가 도구 호출 결과를 평가할 때 상태 수정, 추론 결과의 지속성 유지, 다운스트림 도구 호출 작업이 하나의 트랜잭션 내에 통합되어 저장됩니다. Google은 적어도 한 번의 전송과 최대 한 번의 ACK를 보장하므로 정확히 한 번 처리를 실현할 수 있습니다.

강력한 멀티 에이전트 조정 및 핸드오프: 멀티 에이전트 시스템(A2A)에서는, 기본 에이전트에서 전문 에이전트로의 상태 핸드오프가 내구성 있고 트랜잭션 방식으로 커밋된 메시지로 표현됩니다. 전문 에이전트 작업자는 에이전트 상호작용의 완전히 감사 가능한 계보를 유지하면서 결과물 메시지를 수신합니다.

기본 기능으로 제공되는 타임아웃 및 휴먼인더루프 워크플로: 에이전트 워크플로는 사람의 승인이나 예약된 후속 조치를 위해 일시중지해야 하는 경우가 많습니다. Spanner 큐는 타임아웃 관리를 기본적으로 처리합니다. 단일 트랜잭션이 대기 중인 승인 상태를 기록하고 자동 에스컬레이션 메시지를 예약하여 먼저 트리거되는 항목을 해결합니다.

에이전트 큐를 위한 SQL 기반 모니터링 가능성: 실행 중인 에이전트 워크로드를 검사하고, 작업 백로그를 모니터링하고, 에이전트 실행 기록을 감사하는 작업을 큐 테이블에 대한 표준 SQL 쿼리로 수행할 수 있으므로 불투명한 메시지 저장소 블랙박스를 피할 수 있습니다.

에이전트 워크플로의 다음 단계

AI 에이전트 외에도 Spanner 큐는 다양한 기존 이벤트 기반 아키텍처에서 유연한 다목적 메시징 플랫폼 역할을 합니다. 소셜 애플리케이션의 실시간 활동 피드 지원, 뉴스 게시를 통한 실시간 소식 제공, 리테일 업종의 주문 처리 및 인벤토리 워크플로 조정, 금융 서비스의 높은 처리량의 비동기 작업 처리 및 트랜잭션 알림 처리 등 어떤 경우든 Spanner 큐는 기본 데이터베이스 내에서 비동기 메시지 전송 및 트랜잭션 이벤트 기반 워크플로를 위한 강력한 기반을 제공합니다.

자세히 들여다보기: Spanner 큐의 트랜잭션 메커니즘

Spanner 큐는 Spanner에서 퍼스트 클래스 관계형 구조로 표현되므로 익숙한 GoogleSQL을 사용하여 큐를 정의, 검사, 관리할 수 있습니다.

1. 큐 정의 및 원자적으로 큐에 추가

에이전트가 고객 환불 승인을 결정하면, 단일 ACID 트랜잭션 내에서 Orders 테이블을 업데이트함과 동시에 OrderAgentTasks 큐로 실행 작업을 디스패치합니다.

code_block: <ListValue: [StructValue([('code', '-- Assume parent table:\r\n-- CREATE TABLE Orders (\r\n-- OrderId STRING(64) NOT NULL, ...\r\n-- )\r\n-- PRIMARY KEY (OrderId);\r\n\r\n-- Define the transactional queue table\r\nCREATE QUEUE OrderAgentTasks (\r\n OrderId STRING(64) NOT NULL,\r\n TaskId STRING(64) NOT NULL,\r\n TaskType STRING(64) NOT NULL,\r\n Payload JSON NOT NULL\r\n) PRIMARY KEY (OrderId, TaskId, TaskType), INTERLEAVE IN Orders;\r\n\r\n-- Inside a Read-Write Transaction:\r\n-- 1. Update business state atomically\r\n\r\n-- BEGIN TRANSACTION;\r\n\r\nUPDATE Orders\r\nSET Status = \'REFUND_APPROVED\',\r\n UpdatedAt = PENDING_COMMIT_TIMESTAMP()\r\nWHERE OrderId = @orderId;\r\n\r\n-- 2. Enqueue the asynchronous agent action in the same transaction\r\nINSERT INTO OrderAgentTasks (OrderId, TaskId, TaskType, Payload)\r\nVALUES (\r\n @orderId,\r\n @taskId,\r\n \'EXECUTE_REFUND\',\r\n JSON \'{"action": "execute_refund", "amount": 49.99}\'\r\n);\r\n\r\n-- COMMIT;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad75ddc390>)])]>

이렇게 하면 주문 상태가 REFUND_APPROVED로 성공적으로 전환된 경우에만 EXECUTE_REFUND 작업이 존재하게 됩니다.

2. 시간 기반 예약 및 원자적 취소

관리자의 승인을 최대 72시간 동안 기다린 후 에스컬레이션하는 등 시간에 따라 달라지는 워크플로의 경우 에이전트는 시스템 DeliverTime 열을 채워 메시지 공개 상태를 지연시킵니다.

code_block: <ListValue: [StructValue([('code', '-- Schedule an automated escalation check-in 72 hours in the future\r\nINSERT INTO OrderAgentTasks (OrderId, TaskId, TaskType, Payload, DeliverTime)\r\nVALUES (\r\n @orderId,\r\n @escalationTaskId,\r\n \'ESCALATE_UNAPPROVED_ORDER\',\r\n JSON \'{"action": "escalate_to_supervisor"}\',\r\n TIMESTAMP_ADD(CURRENT_TIMESTAMP(), INTERVAL 72 HOUR)\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad75ddd310>)])]>

관리자가 4시간 후에 요청을 승인하면 애플리케이션은 며칠 후에 발생하는 허위 에스컬레이션 알림을 처리할 필요가 없습니다. 단일 트랜잭션에서 표준 SQL DELETE를 사용하여 주문 상태를 업데이트하고 대기 중인 에스컬레이션 작업을 취소합니다.

code_block: <ListValue: [StructValue([('code', "-- BEGIN TRANSACTION;\r\n\r\nUPDATE Orders\r\nSET Status = 'MANAGER_APPROVED',\r\n ApprovedBy = @managerId\r\nWHERE OrderId = @orderId;\r\n\r\n-- Atomically cancel the pending delayed escalation task. `ASSERT_ROWS_MODIFIED 1` will\r\n-- act as a safeguard and cause a statement level error.\r\n\r\n-- A statement level error can be captured and the transaction can be\r\n-- user-aborted/cancelled in case the queue entry was already deleted.\r\n-- Otherwise the transaction will complete successfully regardless if the \r\n-- queue entry still exists and you'll only know if a queue entry was deleted by\r\n-- checking the number of rows affected by the DELETE.\r\nDELETE FROM OrderAgentTasks\r\nWHERE OrderId = @orderId\r\n AND TaskId = @escalationTaskId\r\n AND TaskType = 'ESCALATE_UNAPPROVED_ORDER',\r\nASSERT_ROWS_MODIFIED 1;\r\n\r\n-- COMMIT;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad75dde890>)])]>

3. 스트리밍 방식의 소비, 임대 기간 갱신,원자적 확인

다운스트림 에이전트 작업자는 스트리밍 SQL 연결(ExecuteStreamingSql)을 통해 RECEIVE_<QueueName> 테이블 값 함수(TVF)를 사용하여 작업을 가져와 처리합니다. Spanner는 메시지 임대 기간을 자동으로 관리하며, 임대된 각 작업과 함께 고유한 SpannerLeaseToken 및 만료 타임스탬프를 반환합니다.

code_block: <ListValue: [StructValue([('code', "-- Step 1: Consume tasks via a long-lived streaming SQL query\r\nSELECT\r\n OrderId,\r\n TaskId,\r\n TaskType,\r\n Payload,\r\n SpannerLeaseToken,\r\n SpannerLeaseExpirationTimestamp\r\nFROM RECEIVE_OrderAgentTasks(max_duration => '20m');"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad74625b50>)])]>

AI 에이전트 작업은 멀티턴 LLM 추론이나 외부 API 호출처럼 기본 임대 기간보다 오래 걸리는 작업이 포함되는 경우가 많습니다. 이럴 때 작업자는 RENEWLEASE_<QueueName> 함수를 사용하여 임대 기간을 능동적으로 연장할 수 있습니다.

code_block: <ListValue: [StructValue([('code', '-- Step 2: Extend lease ownership during long-running agent execution\r\nSELECT *\r\nFROM RENEWLEASE_OrderAgentTasks(lease_tokens => [@leaseToken]);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad74627d10>)])]>

에이전트가 외부 도구 실행을 완료하면(TaskId를 외부 API의 멱등성 키로 전달) 읽기-쓰기 트랜잭션을 열어 최종 상태를 기록하고 ASSERT_ROWS_MODIFIED 1로 메시지를 삭제하여 해당 메시지를 확인(ACK) 처리합니다.

code_block: <ListValue: [StructValue([('code', "-- Step 3: Atomically checkpoint agent results and ACK the message\r\n-- BEGIN TRANSACTION;\r\n\r\nUPDATE Orders\r\nSET RefundTransactionId = @externalRefundId,\r\n Status = 'REFUND_COMPLETED'\r\nWHERE OrderId = @orderId;\r\n\r\nDELETE FROM OrderAgentTasks\r\nWHERE OrderId = @orderId\r\n AND TaskId = @taskId\r\n AND TaskType = @taskType\r\nASSERT_ROWS_MODIFIED 1;\r\n\r\n-- COMMIT;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad74624810>)])]>

ASSERT_ROWS_MODIFIED 1을 사용하면 임대 기간 만료로 인한 경합 상태로부터 시스템을 보호할 수 있습니다. 네트워크 일시중지로 인해 작업자의 실행이 지연되어 임대 기간이 만료된 경우, 다른 작업자가 이미 해당 작업을 처리하고 삭제했을 수 있습니다. 중단된 작업자가 재개되어 문을 실행하려고 하면 ASSERT_ROWS_MODIFIED 1은 큐 행이 이미 사라진 것을 감지하고 문 수준 오류를 발생시킵니다. 이 오류를 포착하고 트랜잭션을 중단하면 비활성 작업자가 최신 데이터베이스 상태를 덮어쓰지 못하게 됩니다.

Spanner 변경 내역과 Spanner 큐 비교

Spanner 변경 내역은 다운스트림 통합 및 감사를 위해 데이터베이스 데이터 변경사항(삽입, 업데이트, 삭제)을 거의 실시간으로 캡처합니다. 변경 내역과 큐 모두 애플리케이션이 데이터 변경에 반응할 수 있도록 하지만, Spanner 변경 내역은 지속적인 변경 데이터 캡처(CDC)와 다운스트림 분석 또는 스토리지로의 데이터 스트리밍을 위해 설계되었습니다. 반면 Spanner 큐는 트랜잭션 작업 조정을 위해 명시적으로 설계되었으며, 읽기-쓰기 트랜잭션 내에서 기본 메시지 임대 기간 설정, 예약된 전송, SQL 기반 가져오기, 원자적 확인을 지원합니다.

시작하기

Spanner는 엄격한 글로벌 일관성 하에 관계형, 하이브리드 검색, 그래프, 키-값 기능을 결합하여 에이전트형 데이터를 위한 통합 기반을 제공합니다. Spanner 큐는 에이전트가 단일 통합 플랫폼 내에서 데이터에 대한 추론부터 트랜잭션 작업 실행에 이르기까지 전 과정을 원활하게 전환할 수 있게 함으로써 에이전트 루프를 완성합니다. 이제 Spanner 큐를 정식 버전으로 이용하실 수 있습니다.

Spanner 90일 무료 체험판에 가입하고 공개 문서를 확인해 보세요. 지금 바로 Spanner 데이터베이스에 큐 테이블을 생성하여 복원력 있는 '정확히 한 번' 에이전트형 워크로드를 빌드할 수 있습니다.

Spanner Omni 정식 버전 출시: 어디에나 배포할 수 있는 분산형 멀티 모델 데이터베이스

Mon, 12 Oct 2026 04:00:00 +0000

어디에나 배포할 수 있는 Spanner 버전인 Spanner Omni가 이제 정식 버전으로 출시되어 온프레미스 데이터 센터나 다른 클라우드에서도 가장 까다로운 프로덕션 워크로드를 지원할 준비가 되었습니다.

Google은 10여 년 전 Spanner를 통해 NoSQL의 수평 확장성과 기존 관계형 데이터베이스의 ACID 규정 준수 및 strong consistency를 결합하여 분산 SQL 시장을 개척했습니다. 그 이후로 Spanner는 복잡한 워크로드를 간소화하고 에이전트 AI를 지원하는 상호 운용 가능한 멀티 모델 데이터베이스로 진화했습니다. 이제 단일 데이터베이스 내에서 SQL, 그래프, 키-값, 전체 텍스트 검색, 벡터 검색, 분석 처리를 열 기반 엔진과 결합하여 제공합니다.

Google Cloud Next ’26에서 Spanner Omni를 처음 선보였을 때, Google은 분산형 데이터베이스를 Google Cloud 외부로 확장하여 고객의 인프라에 직접 제공했습니다. 이로 인해 기업 고객과 개발자 커뮤니티 모두에서 엄청난 관심을 보였습니다. 실제로 Spanner Omni는 출시 이후 200만 회 이상 다운로드되었습니다.

Spanner Omni는 완전 관리형 Spanner 서비스와 동일한 핵심 기능을 제공하며, 필요한 곳 어디에나 배포할 수 있는 자유를 더했습니다. 비공개 데이터 센터에서 가상 머신이나 Kubernetes를 실행하든, 여러 클라우드에 걸쳐 멀티 클라우드 배포를 실행하든, 노트북에서 로컬로 테스트하든, Spanner Omni는 Google 수준의 일관성, 가용성, 확장성, 상호 운용 가능한 멀티 모델 기능을 차세대 에이전트 AI 애플리케이션에 직접 제공합니다.

Spanner Omni는 Spanner 고유의 핵심 기능을 그대로 유지하면서, 원하는 곳 어디든 자유롭게 배포할 수 있는 환경을 제공합니다.

Attio, Spanner Omni로 에이전트형 애플리케이션 속도 가속화

Spanner Omni를 사용하면 팀에서 한 번의 빌드만으로 어디에나 배포할 수 있으며, Google Cloud, 온프레미스, 기타 클라우드 전반에서 애플리케이션 이식성을 확보할 수 있습니다. 런던에 본사를 둔 AI 기반 CRM 회사인 Attio는 Spanner를 기반으로 플랫폼을 구축했습니다. Attio는 에이전트형 애플리케이션 환경을 모든 기능을 갖춘 컨테이너화된 Spanner Omni와 관리형 Spanner의 결합 모델로 마이그레이션했습니다.

"Attio는 AI 기반 CRM 플랫폼이라는 비전을 실현하기 위해 Spanner를 기반으로 세계에서 가장 발전된 에이전트형 애플리케이션 환경을 구축하고 있습니다. Spanner Omni는 모든 환경에서 Spanner의 기능과 성능을 구현함으로써, 에이전트가 최근 발표된 Spanner 큐와 같이 복잡한 미션 크리티컬 워크플로를 프로덕션 환경에 적용할 수 있게 해준다는 점에서 저희에게 매우 큰 성과였습니다. Spanner Omni를 통해 이전에는 불가능했던 수준의 규모와 신뢰도로 프로덕션 속도를 가속화할 수 있었습니다." - 알렉산더 크리스티, Attio 공동 설립자 겸 CTO

어떤 환경에서든 활용 가능한 기본 제공 AI 기능

Spanner Omni는 Spanner의 통합 멀티 모델 기반을 프라이빗 인프라와 서드 파티 클라우드로 직접 확장하여 AI 워크로드에 중요한 기능을 제공합니다.

벡터 검색 및 Spanner Graph: 관계형 테이블과 함께 벡터 임베딩을 기본적으로 저장하고 색인을 생성합니다. KNN 및 ANN 검색 지원을 통해 시맨틱 유사성을 정형 SQL 필터와 결합할 수 있습니다. Spanner Graph는 속성 그래프를 엔진에 직접 통합하여 복잡한 항목 관계를 추적하고 그래프 순회를 벡터 검색과 연결할 수 있도록 지원합니다.
모델 컨텍스트 프로토콜(MCP) 지원: MCP Toolbox를 사용하여 에이전트 시스템과 직접 통합합니다. 이 개방형 표준을 통해 자율 에이전트는 스키마를 검사하고 관련 컨텍스트를 검색할 수 있으며, 멀티 클라우드 배포 환경 전반에서 Spanner Omni를 운영 메모리 레이어로 활용할 수 있습니다.

Spanner Omni의 새로운 기능

프리뷰 출시 이후 Google은 Spanner Omni의 기능을 확장하고, 프로덕션에 즉시 사용 가능한 배포 수준으로 가격 책정 모델을 개선하기 위해 노력해 왔습니다.

프로덕션 배포를 위한 엔터프라이즈 기능

정식 버전 출시로 미션 크리티컬 프로덕션 워크로드에 필요한 엔터프라이즈급 기능 전체를 사용할 수 있게 되었습니다. 주요 기능은 다음과 같습니다.

강력한 보안 및 거버넌스: TLS 암호화, 인증 및 승인, 감사 로깅을 포함한 고급 엔터프라이즈 보안 기능을 지원합니다.
데이터 보호: 고성능 백업 및 복원 기능으로 실수로 인한 삭제나 데이터 손상으로부터 데이터를 보호합니다.
워커 노드: Spanner Omni에만 있는 전용 스테이트리스(Stateless) 컴퓨팅 노드로, 기본 Spanner Omni 서버에서 백그라운드 및 리소스 집약적인 작업을 오프로드하여 핵심 데이터베이스 워크로드를 처리하는 데 집중할 수 있도록 설계되었습니다.
엔터프라이즈급 지원: Google Cloud Customer Care에 직접 액세스하여 중요한 워크로드를 원활하게 실행할 수 있습니다.

유연한 라이선스 및 업계 표준 가격 책정

Spanner Omni는 개발의 모든 단계에서 사용자를 지원하기 위해 규모와 예산에 맞춰 선택할 수 있는 두 가지 라이선스 등급을 제공합니다.

개발자 버전(무료): 비상업용 비프로덕션 환경에서 개발, 테스트, 프로토타입 제작을 위해 최적화된 버전입니다. Spanner의 모든 핵심 기능을 제공하므로, 프로덕션 환경으로 확장하기 전에 애플리케이션을 빌드하고 검증하는 용도로 활용할 수 있습니다. 개발자 버전에는 기본 라이선스가 제공됩니다. 기본 라이선스는 90일 동안 유효하며, 백업 기능과 워커 노드를 제외하고 상업용 버전과 동일한 모든 기능을 제공합니다. 4개 이하의 vCPU를 사용하는 단일 서버 환경에 배포할 경우, 기본 라이선스는 만료 없이 계속 사용할 수 있으며 백업 및 복원 기능도 함께 지원됩니다. vCPU가 4개를 초과하는 경우, 이 양식을 작성하면 기본 라이선스 기간을 90일 이후까지 연장할 수 있습니다.
상업용 버전(유료): 상업용 프로덕션 워크로드를 위해 설계된 이 버전은 엔터프라이즈 지원과 함께 Spanner Omni의 모든 기능을 제공합니다. 이 모델은 업계 표준을 철저히 따르며, vCPU 기반의 예측 가능한 연간 구독 모델을 채택하고 있습니다. 또한 사전 프로덕션 버전 평가를 위한 개념 증명 라이선스를 할인된 가격으로 제공합니다.

Spanner Omni와 Google Cloud의 완전 관리형 Spanner 비교

Spanner Omni의 목표는 Google Cloud에서 제공되는 완전 관리형 Spanner 서비스와 동일한 수준의 기능을 제공하는 것입니다. 그러나 Spanner Omni는 자체 관리형 소프트웨어이므로 Spanner Omni를 배포하고 운영하는 방식은 Google Cloud의 완전 관리형 Spanner와 다음과 같은 몇 가지 측면에서 다릅니다.

자체 관리형 운영: 정기 유지보수, 버전 업그레이드, 인프라 모니터링을 포함한 모든 일상적인 운영을 사용자가 직접 담당합니다.
가용성 및 SLA: Spanner Omni는 고객 관리 인프라에서 실행되므로 Google은 가용성 SLA를 제공하지 않습니다. 그러나 Google에서 권장하는 참조 아키텍처에 따라 배포하면 비슷한 수준의 고가용성을 달성할 수 있습니다.
Google Cloud와의 통합: Spanner Omni는 어디서나 실행될 수 있도록 BigQuery, Knowledge Catalog, Gemini Enterprise 및 기타 Google Cloud 서비스와의 기본 통합과 같이 Google Cloud 전용 기능에 의존하는 관리형 Spanner에서 사용할 수 있는 기능을 제외합니다.
기능 동등성 로드맵: 현재 Spanner Omni와 완전 관리형 Spanner 간에 일부 기능 격차가 존재하지만, 향후 출시에서 이러한 격차를 해소하기 위해 적극적으로 업데이트를 개발하고 있습니다.

지금 시작하기

온프렘 기존 시스템을 현대화하든, 복원력 있는 멀티 클라우드 아키텍처를 빌드하든, Spanner Omni는 확장을 지원할 준비가 되어 있습니다.

자세한 내용은 Spanner Omni 웹사이트에서 문서와 사용 사례를 살펴보세요.
Spanner Omni 상업용 버전의 모든 기능을 사용하려면 Google Cloud 계정팀에 문의하거나 https://cloud.google.com/consulting/spanner-omni에서 Google Cloud에 문의하세요.
비상업적, 비프로덕션 목적으로 개발 및 테스트하려면 Spanner Omni 개발자 버전을 다운로드하세요.

에이전트를 위한 PostgreSQL을 제공하는 AlloyDB: 에이전트 규모의 실시간 데이터와 완전한 워크로드 격리

Wed, 07 Oct 2026 04:00:00 +0000

기업은 성능 저하가 허용되지 않는 미션 크리티컬 운영 데이터베이스를 사용합니다. 그러나 소수의 에이전트만 집중적인 추론 루프를 실행해도 쿼리가 예측할 수 없이 급증하여 기존 아키텍처가 쉽게 과부하될 수 있습니다.

오늘 Google Cloud는 AlloyDB가 에이전트를 위한 PostgreSQL(프리뷰 버전)을 제공하여 미션 크리티컬 시스템을 손상시키지 않고 실시간 데이터 액세스를 지원한다는 소식을 발표합니다. 이제 AlloyDB는 샌드박스 처리된 데이터베이스 인스턴스를 몇 초 만에 프로비저닝하여 동적 에이전트 버스트에 맞게 확장할 수 있으므로 완전한 워크로드 격리가 가능합니다. 몇 개의 에이전트부터 수백만 개의 에이전트까지 어떤 규모로든 에이전트를 비용 효율적으로 실행할 수 있으며, 에이전트가 완료되면 인스턴스가 자동으로 가동 중지됩니다. 이번 발표의 주요 내용은 다음과 같습니다.

이제 AlloyDB는 프로덕션에 대한 최신 읽기 전용 액세스 권한을 가진 수천 개의 서버리스 데이터베이스 인스턴스로 PostgreSQL을 확장하도록 설계된 에이전트형 데이터베이스 아키텍처를 제공합니다. 이러한 인스턴스는 프로덕션 워크로드가 실행되는 기본, 대기, 읽기 복제본 인스턴스와 완전히 분리된 상태로 유지됩니다.
이러한 각 인스턴스는 Google의 엑사바이트 규모 분산 스토리지 시스템인 Colossus의 통합 스토리지 계층에서 지원하는 데이터베이스의 실시간 데이터에 액세스합니다. 이를 통해 에이전트는 밀리초 미만의 I/O와 초당 테라비트의 합산된 스캔 처리량을 달성하여 초당 300만 개 이상의 쿼리를 지원할 수 있습니다.
이러한 인스턴스는 전체 AlloyDB PostgreSQL 엔진을 활용하여 모든 색인, SQL의 전체 기능, 포괄적인 벡터, 전체 텍스트, 공간 검색에 대한 액세스를 제공합니다. 또한 에이전트는 BigQuery와 Spark를 활용하여 복잡한 ETL 파이프라인 없이도 레이크하우스 분석을 실행할 수 있습니다.
에이전트가 작업을 완료하면 이러한 인스턴스가 즉시 0으로 축소되므로, 활성 추론 루프에 대해서만 비용이 청구되어 클라우드 지출이 줄어듭니다.

Google Cloud는 PostgreSQL용 AlloyDB를 통해 100% PostgreSQL 호환 엔진 내에 고급 벡터 연산, 머신러닝 추론, 파운데이션 모델 연동을 직접 통합함으로써 에이전트형 엔터프라이즈 관계형 데이터베이스를 선도하고 있습니다. 정적 비밀번호를 IAM 인증으로 대체하고, VPC 서비스 제어를 통해 트래픽을 격리하고, 고객 관리 암호화 및 감사를 제공하는 등 심층적인 Google Cloud 보안 통합을 통해 데이터를 보호합니다. 이 기능은 이제 에이전트형 아키텍처에서 제공하는 확장성과 결합되어 AlloyDB를 최고의 엔터프라이즈급 에이전트형 PostgreSQL 제품으로 만들어 줍니다.

시작하려면 여기에서 프리뷰를 신청하세요.

중요한 이유

오늘날의 에이전트 시대에는 단일 코파일럿 에이전트 상호작용에서 수백만 개의 에이전트가 동시에 공동작업하는 네트워크로 빠르게 전환되고 있습니다. 이러한 에이전트가 한꺼번에 쿼리하고 작동하면 갑작스러운 트래픽 급증으로 인해 핵심 데이터베이스가 과부하되어 비즈니스를 운영하는 시스템에 지장을 줄 수 있습니다.

에이전트에는 빠른 분석과 실시간 프로덕션 데이터에 대한 지연 시간이 짧은 액세스가 모두 필요하며, B-트리, 벡터, 텍스트, 공간 색인을 활용하여 워크플로를 효율적으로 실행합니다. 새로운 아키텍처는 객체 스토리지 위에 있는 페이지 캐싱 레이어에 의존하지만, 확장성과 비용 문제로 인해 프로덕션 시스템의 안정성이 저하될 수 있습니다.

또한 이 아키텍처는 까다로운 상충 관계에 직면합니다. 즉, 분석을 위해 프로덕션 데이터를 활용하려고 하면 운영 액세스에 성능 병목 현상이 발생하여 에이전트가 프로덕션에 배포되는 순간 미션 크리티컬 데이터베이스가 위험해집니다. 이러한 접근 방식은 데이터베이스 스토리지에 기존 객체 스토어를 사용하여 문제를 해결하려고 합니다. 이를 통해 일부 에이전트에 도움이 될 수 있는 분석 액세스가 가능하지만, 기본 데이터베이스는 프로덕션 워크로드에 사용하기에는 너무 느리고 I/O 지연 시간이 최대 10배 더 높습니다. 페이지 캐싱 레이어는 기껏해야 패치에 불과합니다. 캐시 자체는 여전히 충분히 빠르지 않은 경우가 많으며, 에이전트형 워크로드로 인해 쉽게 포화되는 확장성 병목 현상을 일으킵니다.

활성 멀티 에이전트 시스템이 집중적인 추론 주기를 실행하면 예측할 수 없는 동시 쿼리 급증을 유발하여 캐싱 레이어에 과부하가 발생하고, 미션 크리티컬 프로덕션 시스템이 에이전트로 인한 중단에 취약해집니다. 따라서 이러한 아키텍처에서는 전체 운영 사용 사례 클래스를 실행할 수 없으므로 기업은 실시간 엔터프라이즈 데이터에 대한 AI의 혁신적인 힘을 활용할 수 없습니다.

AlloyDB의 고유한 에이전트형 PostgreSQL 아키텍처

Google은 다른 접근 방식을 취하고 있습니다. AlloyDB는 AI 시대를 위해 특별히 설계된 에이전트형 데이터베이스 아키텍처를 제공하며, 다음과 같은 네 가지 주요 차별화된 기능을 갖추고 있습니다.

인위적인 병목 지점 없이 밀리초 미만의 I/O 지연 시간: AlloyDB의 업계 최고 수준의 트랜잭션 및 쿼리 처리와 Google의 전 세계 규모 Colossus 스토리지 인프라를 기반으로 하는 지연 시간이 짧은 객체 스토리지를 결합한 이 아키텍처는 에이전트를 위한 대규모 공유 저장공간 플레인을 제공합니다. 밀리초 미만의 I/O와 초당 테라비트 이상의 합산 스캔 대역폭을 달성하여 에이전트가 최신 운영 데이터에 대해 직접 집중적인 읽기 쿼리와 벡터 검색을 실행할 수 있습니다.
수요에 맞게 확장하면서 프로덕션 워크로드에서 완전히 격리: AlloyDB는 최신 프로덕션 데이터에 대해 샌드박스 처리된 데이터베이스 인스턴스를 몇 초 만에 동적으로 프로비저닝하여 확장합니다. 에이전트가 한정된 운영 리소스를 나눠 써야 하는 기존 아키텍처와 달리, 에이전트형 데이터베이스 컴퓨팅은 기본 데이터베이스 클러스터와 완전히 격리되어 있으므로 에이전트가 프로덕션 성능을 저하시키지 않고 집중적이며 예측하기 어려운 추론 루프를 실행할 수 있습니다. 이러한 강력한 안전 가드레일과 엔터프라이즈급 거버넌스, 세분화된 액세스 제어를 결합하면 안심하고 프로덕션 데이터에서 PostgreSQL의 제약 없는 강력한 기능을 마음껏 활용할 수 있습니다. 이를 통해 활성 에이전트 루프에서 분석 쿼리, 벡터 쿼리, 운영 포인트 조회를 원활하게 혼합하여 사용할 수 있습니다.
사용한 만큼만 지불하는 결제: 대부분의 에이전트 활동은 동시 쿼리가 급증한 후 비활성 기간이 이어지는 것이 특징입니다. 이러한 급증을 수용하기 위해 전용 읽기 복제본을 프로비저닝하면 값비싼 인프라를 24시간 내내 유지해야 합니다. 대규모 에이전트 그룹을 비용 효율적으로 지원하고 프로비저닝된 시스템의 유휴 컴퓨팅 오버헤드를 제거하기 위해, 이러한 에이전트형 AlloyDB 인스턴스는 초당 수백만 개의 쿼리를 처리하도록 빠르게 확장할 수 있으며, 사용한 만큼만 지불하는 유연한 가격 책정 모델을 통해 자동으로 0까지 축소됩니다.
ETL 없이 기본 레이크하우스 통합: 모든 프로덕션 데이터가 Google Cloud의 경계 없는 레이크하우스와 기본적으로 통합됩니다. 이를 통해 에이전트는 BigQuery와 Apache Spark용 Lightning Engine에서 페더레이션 쿼리를 실행하여 대규모 레이크하우스 데이터 세트를 AlloyDB의 최신 트랜잭션 데이터와 조인할 수 있습니다. 따라서 불안정한 일괄 ETL 파이프라인을 빌드하고 유지관리할 필요가 없으며, 자율 에이전트가 실시간 운영 상태와 과거 레이크하우스 컨텍스트에 즉시 액세스할 수 있습니다.

“공급망이 점점 더 자율화되면서, 당사 플랫폼은 수천 개 시설에 걸쳐 복잡한 물류 워크플로를 조정하기 위해 실시간 트랜잭션 인텔리전스를 활용하고 있습니다. 에이전트를 위한 AlloyDB의 새로운 PostgreSQL 아키텍처는 획기적인 변화를 가져다주었습니다. 이제 동시에 협업하는 에이전트 네트워크를 배포하여 초 미만 단위의 최신성으로 인벤토리 및 주문 데이터를 분석하는 동시에, 핵심 트랜잭션 처리가 전혀 영향을 받지 않도록 유지할 수 있습니다. 차세대 엔터프라이즈 공급망 AI를 구동하는 데 필요한 격리, 속도, 비용 효율성을 제공합니다.” - Sanjeev Siotia, Manhattan Associates 부사장 겸 최고 기술 책임자

가용성

AlloyDB의 에이전트를 위한 PostgreSQL이 이제 프리뷰 버전으로 제공됩니다.

자세히 알아보려면 문서 페이지를 방문하고 여기에서 가입하여 시작하세요.

에이전트 시대를 위한 타협 없는 새로운 데이터베이스 아키텍처

Tue, 06 Oct 2026 19:00:00 +0000

데이터베이스 엔지니어링 분야에 종사하는 모든 이들은 단 하나의 질문에 매달려 왔습니다. 데이터를 보유한 레코드 시스템을 손상시키지 않으면서 OLTP 워크로드를 확장하려면 어떻게 해야 할까요?

Exadata는 데이터베이스 아래의 수평 확장 스토리지 계층으로 쿼리를 오프로드하여 네트워크 병목 현상을 제거하는 방식으로 이 문제를 해결했습니다. Azure SQL Hyperscale은 공유 블록 서버를 사용하여 수십 개의 읽기 복제본으로 수평 확장했습니다. Aurora는 로그 애플리케이션을 분산 스토리지 노드로 오프로드하여 수십 개의 PostgreSQL 노드에서 읽기 작업을 확장했습니다. 한편, 새로운 아키텍처는 프로비저닝된 캐시 계층을 앞에 두고 기존 객체 스토리지에 데이터를 유지합니다. 이를 통해 핫 데이터의 지연 시간은 줄일 수 있지만 캐시 부적중이 발생할 때마다 긴 지연 시간이 발생하는 문제는 여전히 남습니다.

이러한 각 아키텍처는 본질적으로 규모, 지연 시간, 격리라는 세 가지 특성 중 적어도 하나, 경우에 따라서는 두 가지 특성의 제약을 받습니다. 예를 들어 공유 블록 서버를 기반으로 구축된 아키텍처는 블록 서버에서 I/O 병목 현상이 불가피하게 발생하기 때문에 확장성이 저하됩니다. 또한 복제본 트래픽이 급증할 때마다 프로덕션 워크로드가 제한되므로 격리 측면에서도 손해를 감수해야 합니다.

이러한 절충안 중 일부는 당시에는 합리적인 선택이었으며, 지난 40년 동안 엔터프라이즈 데이터베이스 워크로드의 요구사항을 충족해 왔습니다. 그러나 에이전트 시대에는 이러한 타협이 더 이상 용납되지 않습니다. 에이전트형 워크로드는 동적으로 생성되며 사전에 검증할 수 없으므로 비즈니스 연속성을 위해 미션 크리티컬 시스템과 격리하는 것이 필수적입니다. 또한 에이전트형 워크로드에는 데이터베이스 엔진과 모든 색인의 성능을 온전히 활용해야만 달성할 수 있는 짧은 지연 시간이 필요합니다. 이와 동시에 단일 데이터베이스에서는 지금껏 시도된 적 없는 완전히 새로운 수준의 탄력적 확장성도 요구됩니다. 예를 들어 수많은 에이전트가 한꺼번에 단일 데이터베이스를 처리하기 위해 불과 몇 초 만에 1,000개의 컴퓨팅 노드를 사용하고 1분도 채 되지 않아 작업을 완료할 수도 있습니다.

진정한 에이전트형 데이터베이스 아키텍처에 필요한 세 가지 원칙

에이전트 시대에는 세 가지 기본 원칙으로 정의되는 새로운 에이전트형 데이터베이스 아키텍처가 필요할 것입니다. 에이전트형 데이터베이스 아키텍처라면 이 세 가지를 모두 충족해야 하며, 그렇지 않다면 진정한 의미의 에이전트형이라고 할 수 없습니다.

원칙: 격리 — 설계 단계부터 격리하되, 실시간 데이터 액세스 보장. 에이전트는 기본 클러스터와 데이터베이스 구성요소를 공유하지 않는 데이터 경로를 통해 1초 미만의 최신 상태가 보장되는 실시간 프로덕션 데이터를 읽을 수 있어야 합니다. 실시간이란 오래된 사본이나 브랜치가 아니라 초 단위로 최신 상태를 유지하는 것을 의미합니다. 이는 할당량을 통한 제한이 아닌 물리적인 분리입니다. 할당량 공유는 운명 공동체를 의미하기 때문입니다. 경계는 스토리지 레이어를 통해 바로 확장되므로 설계 단계부터 리소스 경합을 방지됩니다.
원칙: 지연 시간 — 1밀리초 미만의 기준 I/O. 운영 워크로드에는 1밀리초 미만의 블록 I/O가 필요하며, 에이전트의 경우에도 이 기준은 낮아지지 않습니다. 컴퓨팅 노드는 가속화를 위해 DRAM과 로컬 SSD를 활용하지만, 원격 스토리지에 도달하는 캐시 부적중은 애플리케이션이든 에이전트든 1밀리초 이내에 완료되어야 합니다. 성능이 10배 이상 급격히 저하되는 아키텍처는 근본적으로 에이전트가 사용하기에 적합하지 않습니다.
원칙: 확장성 — 에이전트 규모의 컴퓨팅 및 I/O. 에이전트의 확장성은 즉각적이고, 변동성이 크며, 그 규모도 방대합니다. 데이터베이스 컴퓨팅 노드는 몇 초 만에 가동되어 수천 개로 확장되고, 짧은 버스트 중에 실행된 후, 에이전트가 작업을 완료하면 자동으로 0까지 축소될 수 있어야 합니다. 지금까지 프로덕션에 영향을 주지 않으면서 데이터베이스가 컴퓨팅과 I/O를 수천 개의 노드로 동적으로 확장할 수 있을 것이라고는 아무도 생각하지 못했습니다. 에이전트는 본질적으로 동적으로 작동하므로 컴퓨팅이든, 스토리지 I/O이든, 그 사이의 캐싱 계층이든 전체 스택에서 사전 프로비저닝하는 방식은 애초에 불가능합니다.

중요한 것은 에이전트형 아키텍처가 이 세 가지 원칙을 동시에 준수해야 한다는 점입니다. 이를 통해 에이전트는 프로덕션 안정성을 저해하지 않으면서 실시간 운영 데이터, 즉 기업 지식을 직접 활용해 작업할 수 있습니다. 그 결과로 다음과 같은 획기적인 이점을 얻을 수 있습니다.

관련 장애 방지: 비즈니스를 운영하는 엔진과 이를 기반으로 추론하는 에이전트 Fleet을 완전한 분리하여 에이전트가 프로덕션에 영향을 미칠 수 있는 경로를 차단합니다.
용량 예측 불필요: 진정한 탄력성을 통해 예측할 수 없는 에이전트 규모에 대비하여 사전 프로비저닝해야 하는 부담을 없앱니다.
기능 타협 불필요: 에이전트가 사용할 수 있는 기능을 제한하지 않습니다. 에이전트는 모든 추론 단계에서 관계형 SQL, 하이브리드 검색(벡터, 전체 텍스트, 공간), 색인의 모든 기능을 활용할 수 있습니다.

AlloyDB의 에이전트형 아키텍처

AlloyDB의 새로운 에이전트형 데이터베이스 아키텍처는 이 세 가지 원칙을 모두 충족하는 최초의 시스템입니다. Google은 처음부터 스토리지, 네트워크, 컴퓨팅, 데이터베이스 전반을 고려하여 설계했기 때문에 다음과 같은 이점을 제공합니다.

설계 단계부터 격리하여 공동 운명 방지: 트랜잭션 프로덕션 클러스터는 에이전트 워크로드와 완전히 격리된 전용 사전 프로비저닝 인프라에서 실행됩니다. 에이전트는 모델 컨텍스트 프로토콜(MCP)을 통해 독립적이고 일시적인 microVM 기반 AlloyDB 노드 풀과 상호작용합니다. 이러한 노드는 프로덕션용 스토리지 세그먼트와 분리된 전용 Colossus 스토리지 세그먼트에서 데이터를 직접 읽습니다.
예측 가능한 1밀리초 미만의 스토리지 I/O: 모든 스토리지 읽기는 Google의 Colossus 스토리지 시스템에서 직접 처리되므로 이 시스템의 기본적인 1밀리초 미만 지연 시간이 그대로 적용되며 콜드 캐시 부적중이 발생할 때 성능이 급격히 저하되는 현상을 방지합니다.
0에서 수천 개까지 지원하는 진정한 컴퓨팅 확장: 에이전트 활동이 급증하면 에이전트 풀이 0개에서 수천 개의 노드로 빠르게 확장되고, 작업이 완료되는 즉시 다시 0개로 축소됩니다.

에이전트는 1초 미만의 최신 상태가 보장되는 프로덕션 데이터를 쿼리할 수 있으며 완전한 PostgreSQL 엔진을 자유롭게 사용하여 포인트 조회, 색인 순회, 벡터, 전체 텍스트 및 공간 검색, 열 기반 스캔, 레이크하우스 전반의 페더레이션 쿼리 등 추론 루프를 실행할 수 있습니다.

에이전트용 AlloyDB PostgreSQL 프리뷰에 참여하여 규모에 관계없이 모든 프로덕션 데이터에 대해 에이전트를 실행하세요. 전체 기능에 대한 자세한 내용은 함께 제공되는 공지 블로그에서 확인할 수 있습니다.

기존 아키텍처가 세 가지 원칙을 모두 충족할 수 없는 이유

기존 운영 데이터베이스와 새로운 운영 데이터베이스는 모두 세 가지 아키텍처 패러다임 중 하나를 사용하여 확장하려고 합니다. 자율 AI 에이전트의 요구사항을 기준으로 평가하면 각 패러다임에는 근본적인 구조적 한계가 있으며, 세 가지 원칙을 모두 동시에 충족하는 아키텍처는 없습니다.

독립적인 복제본(공유되지 않는 스토리지)

기존 관계형 아키텍처는 기본 인스턴스에서 전용 복제본 데이터베이스로 복제 로그를 스트리밍하여 읽기 작업을 확장하며, 각 복제본에는 자체 로컬 또는 연결된 블록 스토리지가 있습니다. 이러한 방식은 원칙: 격리를 충족합니다. 복제본은 기본 클러스터와 물리적 리소스를 공유하지 않으며, 지속적인 로그 복제를 통해 거의 실시간으로 최신 상태를 유지합니다. 또한 전용 로컬 스토리지를 통해 예측 가능한 1밀리초 미만의 읽기 지연 시간을 보장하므로 원칙: 지연 시간도 충족합니다. 그러나 원칙: 확장성은 충족하지 못합니다. 확장하려면 새 복제본을 프로비저닝하고 수백 기가바이트에서 수백 테라바이트에 이르는 스토리지를 리하이드레이션해야 하기 때문입니다. 이 모든 과정에는 몇 시간이 걸리므로 몇 초 단위로 빠르게 이루어지는 에이전트 추론 작업의 요구사항과는 전혀 맞지 않습니다. 또한 정적으로 프로비저닝된 컴퓨팅 및 스토리지는 에이전트가 실행을 완료한 후에도 오랫동안 유휴 비용을 계속 발생시킵니다.

분리된 공유 스토리지 서버

두 번째 접근 방식은 지속성, 복제를 관리하고 블록 쓰기를 오프로드할 수 있는 커스텀 스토리지 서버의 공유된 멀티 테넌트 계층에서 스테이트리스(Stateless) 컴퓨팅 노드를 분리합니다. 이 접근 방식은 원칙: 지연 시간을 충족합니다. 최적화된 스토리지 서버에 도달하는 읽기 작업에 일관적이고 낮은 운영 지연 시간을 제공하기 때문입니다. 그러나 원칙: 격리는 충족하지 못합니다. 모든 복제본이 기본 인스턴스와 동일한 서버에서 데이터를 읽으므로 에이전트 I/O가 프로덕션 I/O와 직접 경합하게 되어 운명을 공유하기 때문입니다. 또한 원칙: 확장성도 충족하지 못합니다. 데이터가 복사되지 않으므로 스테이트리스(Stateless) 컴퓨팅 복제본이 빠르게 가동되지만 총 스토리지 I/O 대역폭은 사전 프로비저닝된 스토리지 계층으로 고정됩니다. 기본 I/O 용량을 확장하지 않은 채 컴퓨팅 노드만 추가하면 스토리지 포화와 제한이 가속화될 뿐입니다.

공유 블록 서버를 사용하는 객체 스토리지

새롭게 등장한 세 번째 접근 방식은 범용 객체 스토리지에 데이터를 영구적으로 보관하고 공유 블록 서버 계층을 통해 블록 읽기를 처리합니다. 객체 스토리지에서 무작위 읽기 작업을 수행하는 데 수십 밀리초가 걸리기 때문에(기존 데이터베이스 스토리지보다 훨씬 느리고, 적어도 지난 25년 동안 사용되어 온 엔터프라이즈 디스크 어레이보다도 느림) 블록 서버는 핫 데이터를 보관하여 짧은 지연 시간으로 제공할 수 있도록 합니다. 이 접근 방식은 원칙: 지연 시간을 충족하지만 한 가지 주의할 점이 있습니다. 블록 서버에서 캐시 부적중이 발생하면 결국 객체 스토리지에 액세스해야 하므로 지연 시간이 허용하기 어려운 수준으로 높아집니다. 원칙: 격리는 충족하지 못합니다. 복제본이 프로덕션과 블록 서버를 공유하기 때문입니다. 에이전트 I/O와 프로덕션 I/O가 동일한 용량을 사용하므로 해당 용량이 소진되거나 제한되면 에이전트 뿐만 아니라 프로덕션도 영향을 받습니다. 또한 공유 스토리지 서버와 동일한 이유로 원칙: 확장성도 충족하지 못합니다. 복제본은 빠르게 가동할 수 있지만 블록 서버의 I/O는 버스트가 발생해도 그에 맞춰 확장되지 않습니다.

이 계열의 일부 아키텍처는 Apache Spark와 같은 분석 엔진이 데이터베이스 엔진을 우회하여 기본 객체 스토리지를 직접 읽을 수 있도록 하기도 합니다. 분석 워크로드의 경우 이는 가치 있고 실용적인 접근 방식입니다. 그러나 에이전트에는 짧은 지연 시간의 검색이 필요합니다. 색인, 포인트 조회, 벡터 검색을 사용할 수 없게 되면 무차별 대입 테이블 스캔이 강제되어 지연 시간이 폭발적으로 증가하고, 그 결과, 에이전트가 검색-추론 루프를 실행하는 능력이 손상됩니다.

기존 아키텍처 평가

Google은 사용 가능한 DRAM보다 큰 데이터 세트에 대해 동시 색인 조회를 실행하는 방식으로 공유 블록 서버와 함께 객체 스토리지 아키텍처를 사용하는 상용 서비스를 평가하고 확장 한도와 프로덕션 격리를 모두 테스트했습니다. 단일 리더 인스턴스로 시작하여 최대 8개의 읽기 복제본을 추가하여 워크로드를 확장했습니다.

물리적 리소스를 공유하는 아키텍처에서는 읽기 복제본을 통해 에이전트를 확장하면 복제본과 기본 성능이 모두 빠르게 저하됩니다. 아래 차트에서 볼 수 있듯이 Google의 테스트에서는 복제본을 추가해도 처리량은 2배도 채 늘지 않았으며, 복제본 4개에서 정점을 찍은 후 공유 블록 서버 대역폭이 포화 상태에 이르면서 오히려 감소했습니다.

기본 데이터베이스에 미치는 영향은 즉각적이고 심각했습니다. 복제본이 추가되면서 기본 처리량이 75% 이상 급감했습니다.

요컨대, 기존 아키텍처든 새로운 아키텍처든 모두 에이전트가 요구하는 규모를 충족할 수 없으며, 프로덕션 시스템의 안정성을 위협하지 않으면서 이러한 규모를 지원하는 것은 사실상 불가능합니다.

원칙에 따른 평가

* 부분 충족: 핫 데이터는 블록 서버에서 짧은 지연 시간으로 제공되지만, 블록 서버에서 캐시 부적중이 발생하면 객체 스토리지에 액세스하게 되어 수십 밀리초의 지연 시간이 발생합니다.

각각의 경우 이러한 격차는 단순히 조정으로 해결할 수 있는 문제가 아니라 구조적으로 발생하는 문제입니다. 복제는 각 복제본에 자체 스토리지를 제공하여 격리하므로 해당 스토리지를 채우는 것보다 빠르게 복제본을 추가할 수 없습니다. 공유 스토리지 서버는 스토리지를 공유하여 컴퓨팅을 빠르게 추가하므로 I/O를 격리하거나 확장할 수 없습니다. 객체 스토리지 기반 블록 서버는 프로비저닝된 계층을 통해 지연 시간을 복구하므로 격리할 수도 없고 버스트할 수도 없으며, 모든 캐시 부적중이 발생할 때마다 여전히 객체 스토리지에 액세스해야 합니다. 각각의 접근 방식은 한 레이어의 문제를 해결하고 다른 레이어에서 그에 따른 대가를 치릅니다. 이 세 가지 원칙을 모두 동시에 모두 충족하려면 컴퓨팅, 네트워크, 스토리지를 아우르는 데이터베이스 아키텍처를 새롭게 설계해야 합니다.

스택 전반에서 AlloyDB를 설계한 방법

AlloyDB의 에이전트형 데이터베이스 아키텍처는 Google의 데이터, AI, 인프라 스택 전반에 걸쳐 수직적으로 통합되어 있습니다. 여기에는 AI 모델, 데이터베이스 엔진, 분석 엔진뿐만 아니라 스토리지, 네트워킹, 컴퓨팅 인프라도 포함됩니다.

스토리지: Colossus를 기반으로 사용

지속성 레이어에서 AlloyDB는 Google 검색, YouTube, Gmail, Google Drive, Spanner, Bigtable을 뒷받침하는 Google의 엑사바이트 규모 분산 스토리지 시스템인 Colossus를 기반으로 합니다. 단일 Colossus 클러스터는 엑사바이트 규모의 스토리지와 수만 대의 머신으로 확장됩니다. Google은 Spanner를 통해 Colossus에서 직접 설계된 트랜잭션 데이터베이스가 수천 개의 노드로 확장될 수 있음을 입증했습니다. 새로운 AlloyDB 아키텍처는 에이전트라는 새로운 과제에 동일한 기반을 적용합니다.

Colossus에는 AlloyDB가 세 가지 원칙을 충족할 수 있도록 하는 세 가지 특성이 있습니다.

직접적인 1밀리초 미만의 I/O: Colossus는 읽기 지연 시간을 최소화하도록 설계되었습니다. Colossus 스트림을 여는 데이터베이스 노드는 데이터가 물리적으로 상주하는 위치를 설명하는 핸들을 수신합니다. 승인 및 메타데이터 확인은 스트림이 생성될 때 한 번만 수행됩니다. 이후의 모든 읽기 작업은 최적화된 네트워크 프로토콜을 통해 데이터가 저장된 디스크로 직접 이동합니다. 그 결과 데이터베이스의 모든 데이터에서 1밀리초 미만의 지연 시간이 발생하며, 중간에 워밍할 필요가 없고 계층에서 캐시 부적중도 발생하지 않습니다.
대규모 처리량: Colossus는 대역폭을 프로비저닝할 필요 없이 무제한의 호스트가 동시에 액세스할 수 있으며 단일 AlloyDB 데이터베이스에 최대 15TB/s의 합산 처리량과 초당 2,000만 개의 쿼리 처리 성능을 제공합니다. Colossus 규모에서는 AlloyDB 에이전트 노드 Fleet의 부하를 처리하기 위한 별도의 스토리지가 필요하지 않습니다. AlloyDB 에이전트 노드 Fleet이 발생시키는 부하는 스토리지가 이미 처리하고 있는 부하의 일부이기 때문입니다.
물리적 세그먼트 파티셔닝: AlloyDB는 별도의 Colossus 세그먼트 집합에서 에이전트의 요청을 처리하므로 에이전트 I/O는 프로덕션 데이터 경로와 경합하지 않도록 의도적으로 별도의 경로에 분산됩니다.

컴퓨팅, 네트워크, 스토리지 등 데이터 경로의 어느 지점에서도 에이전트는 데이터베이스 구성요소를 프로덕션과 공유할 수 없습니다.

네트워크: Jupiter를 통한 확장 가능한 대역폭

컴퓨팅과 스토리지는 Google의 대용량 데이터 센터 네트워크인 Jupiter를 통해 결합됩니다. 단일 Jupiter 패브릭은 10만 대 이상의 서버를 초당 13페타비트의 바이섹션 대역폭으로 연결합니다. 이는 지구상의 모든 사람이 영상 통화를 할 수 있을 만큼 충분한 대역폭입니다.

Jupiter는 네트워킹 패브릭 전반에서 예측 가능한 짧은 지연 시간으로 높은 바이섹션 대역폭을 제공하므로 에이전트 노드를 클러스터 내 어디에든 유연하게 예약하고 중앙 집중식 스토리지에 일관되게 액세스할 수 있습니다. 에이전트 풀이 0에서 수천 개로 확장되더라도 기본 상호 연결 용량이 배치 병목 현상을 일으키지 않고 증가하는 트래픽을 수용합니다.

컴퓨팅: 탄력적인 서버리스 PostgreSQL 및 분석

컴퓨팅 레이어에서 에이전트는 MCP를 통해 AlloyDB의 에이전트 풀에 연결됩니다. 에이전트 풀은 데이터베이스의 최신 상태에 대한 읽기 전용 액세스 권한이 있는 AlloyDB 에이전트 노드로 구성됩니다. 이 레이어는 다음을 제공합니다.

MicroVM 격리: 각 에이전트 노드는 가볍고 안전한 MicroVM 내에서 실행되는 완전한 기능을 갖춘 PostgreSQL용 AlloyDB 데이터베이스 엔진입니다. 이러한 인스턴스는 서로 완전히 격리되며 전용 기본 클러스터와도 완전히 격리됩니다.
빠른 가동 및 확장: 에이전트 노드는 에이전트의 요청에 따라 프로비저닝되며 에이전트의 작업이 완료되면 자동으로 중지됩니다. 버스트에 대응하여 AlloyDB는 수천 개의 에이전트 노드를 빠르게 프로비저닝하여 수백만 개의 동시 에이전트를 처리하고 에이전트가 작업을 완료되면 이를 해제합니다. 에이전트 노드가 활동한 시간을 기준으로 초 단위의 요금이 청구되므로 버스트가 발생하여 수십 초 동안 수천 개의 노드를 사용하더라도 해당 작업에서 실제로 사용한 리소스에 대해서만 요금이 청구됩니다.

한편 프로덕션 클러스터는 현재와 동일하게 유지됩니다. 즉, 레코드 시스템의 용량에 맞춰 사전 프로비저닝된 전용 인프라에서 그대로 운영됩니다. 에이전트 노드는 Colossus에서 직접 읽으며, 1초 미만의 최신 상태가 보장되는 일관된 프로덕션 상태를 확인합니다.

에이전트 풀 뿐만 아니라 BigQuery와 Spark도 프로덕션 클러스터와 동일한 격리 상태로 Colossus에서 AlloyDB 데이터를 읽을 수 있습니다. 따라서 에이전트는 레이크하우스 페더레이션을 사용하여 실시간 운영 데이터를 대규모 레이크하우스 데이터 세트와 조인할 수 있습니다.

Google 규모의 스토리지, 네트워크, 컴퓨팅 레이어를 기반으로 구축된 AlloyDB의 새로운 에이전트형 데이터베이스 아키텍처는 놀라운 목표를 달성합니다. 바로 데이터 공유입니다. 그 외에는 아무것도 공유하지 않습니다.

AlloyDB의 에이전트형 데이터베이스 아키텍처 평가

Google은 사용 가능한 DRAM보다 큰 데이터 세트에서 동시 색인 조회를 실행하여 전체 스택에 걸친 AlloyDB의 확장성을 테스트했습니다. 기존의 읽기 복제본이 아닌 에이전트 풀의 독립적인 데이터베이스 인스턴스인 단일 에이전트 노드로 시작하여 에이전트 워크로드를 실행하고, 단일 데이터베이스에서 수천 개의 노드로 동적으로 확장하여 총 에이전트 처리량과 프로덕션에 미치는 영향을 모두 측정했습니다.

이 테스트에서는 에이전트 노드를 1개에서 10개로 확장하자 처리량이 3,900QPS에서 41,000QPS로 선형적으로 증가했습니다. 여기에서 두 자릿수 더 확장한 결과 최대 1,000개 노드까지 거의 선형적인 성능 확장을 달성했습니다. 테스트 결과는 다음과 같습니다.

기본 클러스터 성능 저하 없음: 에이전트 노드를 1개에서 1,000개로 확장해도 기본 클러스터의 성능에는 측정 가능한 영향이 없었습니다.
대규모 처리량: 합산 처리량이 동적으로 773배 증가하여 300만 QPS에 도달했으며, 1,000개의 컴퓨팅 노드에서 Colossus를 통해 800만 IOPS가 넘는 성능을 달성했습니다.

2,100개의 에이전트 노드에서 동시 전체 테이블 스캔을 실행하는 유사한 벤치마크에서는 합산 스캔 처리량이 초당 1테라비트를 초과했습니다.

에이전트 풀은 프로덕션 클러스터와 물리적 인프라를 공유하지 않으므로 팀은 프로덕션 시스템을 위험에 빠뜨리지 않고 추론 Fleet을 수천 개의 노드로 확장할 수 있습니다.

설계 단계부터 세 가지 원칙을 모두 고려한 엔지니어링

아래 표는 AlloyDB의 아키텍처가 세 가지 원칙을 각각 어떻게 충족하는지 보여줍니다.

모든 에이전트형 데이터베이스 아키텍처에는 Colossus의 특성을 갖춘 스토리지, 컴퓨팅과 해당 스토리지를 제약 없이 연결하는 네트워크, 에이전트 규모에 맞춰 프로비저닝하고 해제할 수 있는 컴퓨팅이라는 세 가지 기본 요소가 필요합니다.

Google은 Google 검색, YouTube, Gmail을 실행하기 위해 20년 넘게 바로 이러한 기반을 구축해 왔습니다. 그리고 이제 그 기반이 에이전트형 데이터베이스 아키텍처의 기반이 되었습니다.

프로덕션에 영향을 주지 않고 에이전트에 실시간 데이터 제공

AI를 활용해 빌드하는 모든 조직은 동일한 근본적 딜레마에 직면합니다. 바로 비즈니스를 운영하는 시스템을 위험에 빠뜨리지 않으면서 에이전트가 실시간 운영 데이터에 완전히 액세스할 수 있게 하려면 어떻게 해야 하는가입니다. 지금까지는 애플리케이션 요구사항이 아니라 아키텍처가 이러한 선택을 좌우했습니다. 에이전트에 데이터베이스에 대한 직접 액세스 권한을 부여한다는 것은 미션 크리티컬 시스템을 예측할 수 없는 부하, 심각한 리소스 경합, 프로덕션 중단의 위험에 노출한다는 것을 의미했습니다.

이 세 가지 원칙을 기반으로 빌드된 아키텍처는 이러한 타협을 완전히 없애줍니다. 에이전트는 1초 미만의 최신 상태를 유지하는 실시간 프로덕션 데이터를 기반으로 추론합니다. 또한 1밀리초 미만의 I/O 지연 시간으로 모든 색인, 벡터, 전체 텍스트 및 공간 검색, SQL의 전체 기능을 비롯한 완전한 엔진을 자유롭게 활용할 수 있습니다. 이 아키텍처는 에이전트가 필요로 할 때 수천 개의 격리된 노드로 동적으로 확장되고, 에이전트가 작업을 완료하면 다시 0으로 축소됩니다. 이 과정에서 핵심 트랜잭션 워크로드는 전혀 영향을 받지 않습니다. 공유되는 구성요소도 할당량도 없으며, 관련 장애도 나타나지 않습니다. 따라서 에이전트는 비즈니스 연속성을 저해하지 않으면서 혁신을 실현할 수 있습니다.

이러한 특성은 프로덕션 데이터를 읽는 다른 모든 워크로드로 확장됩니다. 보고, 분석, 애플리케이션은 프로덕션을 위험에 빠뜨리지 않고 실시간 데이터를 자유롭게 읽을 수 있으므로 지난 50년 동안 운영 데이터베이스를 좌우해 온 제약에서 벗어날 수 있습니다.

기업의 레코드 시스템에 있는 데이터는 기업이 보유한 가장 소중한 자산입니다. 이러한 기반을 바탕으로 마침내 그러한 데이터의 가치를 온전히 활용할 수 있습니다.

데이터베이스가 드디어 제약에서 벗어난 것입니다.

자세히 알아보려면 문서 페이지를 방문하고 여기에서 가입하여 시작하세요.

Memorystore for Valkey 9.1로 마이크로초 단위의 지연 시간에 3배의 QPS 실현

Tue, 06 Oct 2026 19:00:00 +0000

Google Cloud는 오픈소스 소프트웨어를 기반으로 최고의 관리형 환경을 제공하기 위해 노력하고 있습니다. 오늘 Google Cloud는 Memorystore for Redis Cluster와 비교하여 마이크로초 단위의 지연 시간에 최대 3배의 초당 쿼리 수(QPS)를 구현하는 Memorystore for Valkey 9.1의 정식 버전을 발표합니다.

Redis Inc.가 허용적인 오픈소스 BSD 라이선스에서 이중 라이선스 모델로 라이선스를 전환했던 2024년부터 Google Cloud의 Valkey 지원이 시작되었습니다. Google Cloud는 이러한 전환에 대응하여 다른 기술 리더들과 함께 Linux Foundation에서 관리하는 오픈소스 대안인 Valkey 개발을 지원하게 되었습니다.

Valkey는 그 이후로 놀라운 발전을 거듭하며 주요 성능 및 기능 업데이트를 통해 원래 포크를 훨씬 뛰어넘어 한계를 확장했습니다. Valkey는 수백만 명의 동시 사용자를 처리하기 위해 AI와 마이크로서비스를 확장하는 조직에 특히 매력적입니다. 이러한 상황에서 백엔드 개발자와 설계자는 대규모 처리량을 제공하는 동시에 마이크로초 단위의 지연 시간을 유지해야 합니다.

이 블로그에서는 Valkey 9.1이 성능을 구현하는 방법, 새로운 개발자 기능, 시작하는 방법, 고객이 사용하는 방법을 살펴보겠습니다.

자세히 살펴보기: 스레드 통신 재고

처리량이 높은 인메모리 데이터 스토어에서 기본 실행 루프가 차단되지 않도록 하려면 효율적인 I/O 오프로드가 중요합니다. 이전에는 Valkey가 클라이언트 소켓을 라운드 로빈 방식으로 I/O 스레드에 정적으로 할당했기 때문에 기본 스레드가 대기 중인 클라이언트 목록을 지속적으로 폴링하여 완료된 작업을 감지해야 했습니다.

Valkey 9.1은 목록 폴링을 잠금 없는 멀티 큐 메시징 아키텍처로 대체하여 스레드 간 CPU 낭비를 없애고 동적 작업 분산을 지원합니다. 이 아키텍처는 보완적인 다음 세 가지 큐로 구성되어 있습니다.

기본 스레드에서 I/O 스레드 큐: 읽기 및 쓰기 작업을 단일 생산자 다중 소비자(SPMC) 큐로 전달합니다. 여유 있는 작업자 스레드가 필요에 따라 태스크를 가져오므로 동적 작업 가로채기가 가능하여 스레드 부족이나 핫스팟 문제를 방지합니다.
I/O 스레드에서 기본 스레드 큐: 작업자 스레드가 완료된 태스크를 다중 생산자 단일 소비자(MPSC) 큐로 내보냅니다. 기본 스레드는 완료된 작업을 즉시 팝하여 바쁜 대기 목록 반복을 제거합니다.
I/O 스레드별 큐: 전용 단일 생산자 단일 소비자(SPSC) 큐는 스레드 선호 메모리 정리와 대용량 epoll 오프로드를 처리합니다.

또한 Valkey 9.1은 정적 스레드 기준점을 2단계 동적 확장 엔진으로 대체합니다.

CPU 기반 '가동': 기본 스레드 CPU 사용량이 30%를 넘으면 엔진이 자동으로 첫 번째 백그라운드 I/O 스레드를 활성화하여 큐 병목 현상이 발생하기 전에 수신 트래픽을 흡수합니다.
큐 깊이 자동 확장: 가동된 후에는 Valkey가 실시간 SPMC 큐 백로그를 기반으로 활성 I/O 작업자 스레드 수를 동적으로 확장하거나 축소하여 추가 코어가 필요할 때만 사용되고 유휴 상태일 때는 파킹되도록 합니다.

Valkey 9.1의 새로운 개발자 기능

Valkey 9.1은 원시 성능을 넘어 강력한 새 명령어와 향상된 보안 제어를 통해 엔지니어링팀의 주요 기능 요청을 해결합니다. 이러한 새로운 기능으로 할 수 있는 작업은 다음과 같습니다.

1. 세분화된 데이터베이스 수준 액세스 제어(ACL)

Google Cloud는 최근 Memorystore for Valkey에 대한 액세스 제어 목록(ACL) 지원을 시작했으며 IAM을 사용해 더 세분화된 키 수준 및 명령어 수준 승인을 제공합니다. 이 기본 보안 메커니즘은 추가 비용 없이 제공되며 다음과 같은 기능이 포함되어 있습니다.

중앙 집중식 관리: 1:N 매핑 방식을 사용하면 단일 ACL 정책을 정의하고 여러 클러스터에 연결할 수 있습니다.
안전한 멀티 테넌시: 조직은 데이터베이스 Fleet 전반에서 최소 권한과 안전한 멀티 테넌시를 쉽게 적용할 수 있습니다.
향상된 모니터링 가능성: 이 기능에는 버전이 지정된 정책 버전과 포괄적인 감사 로깅이 포함됩니다.

이전에는 ACL 규칙이 인스턴스 전체에 전역적으로 적용되었습니다. Valkey 9.1을 사용하면 관리자가 ACL 프레임워크 내에서 특정 숫자 데이터베이스 수준에서 사용자 액세스를 제한할 수 있습니다.

실제 사례: 스테이징 또는 서비스별 사용자를 구성하고 비프로덕션 데이터베이스에 대한 액세스를 엄격하게 격리할 수 있습니다.

production 사용자: @all ~* db=0
staging 사용자: @all ~* db=1
dev 사용자: @all ~* db=2

키에 접두사를 지정할 필요 없이 여러 데이터베이스에서 데이터베이스 수준 액세스 제어를 활용하여 무단 데이터 액세스 및 애플리케이션 버그를 방지합니다.

2. CLUSTERSCAN: 효율적인 클러스터 전체 키 스캔

이전에는 대규모 클러스터에서 키를 스캔하려면 노드를 개별적으로 쿼리해야 했습니다. 이 접근 방식은 클러스터 또는 장애 조치를 인식하지 못했습니다. 따라서 프로세스 중에 슬롯 마이그레이션 또는 노드 장애 조치가 발생하면 스캔에서 키를 놓치거나 중복을 반환하거나 실패할 수 있습니다.

CLUSTERSCAN 명령어는 토폴로지 인식 커서를 도입하여 이러한 제한사항을 해결합니다. 이 커서는 현재 슬롯, 로컬 해시 테이블의 지문, 로컬 커서를 인코딩합니다. 이 추가 인코딩 정보를 사용하면 클라이언트가 토폴로지 변경 및 리디렉션을 원활하게 처리하면서 전체 클러스터에서 키를 스캔할 수 있습니다.

CLUSTERSCAN은 다음 두 가지 기본 스캔 전략을 지원합니다.

사용 사례 1: 순차적 전체 클러스터 스캔(단일 작업자)

이 전략은 속도보다 단순성을 우선시하는 간단한 스크립트나 백그라운드 작업에 적합합니다. 클라이언트는 커서 0에서 시작하여 클러스터의 모든 슬롯을 순차적으로 순회합니다.

code_block: <ListValue: [StructValue([('code', 'CLUSTERSCAN 0 MATCH "user:*" COUNT 10\r\n1) "0B3a21-{06S}-64"\r\n2) 1) "user:101"\r\n2) 2) ...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fadb0ae9110>)])]>

스캔을 계속하려면 반환된 커서를 다음 호출에 전달합니다. 현재 슬롯이 완전히 스캔되면 커서가 자동으로 다음 슬롯으로 이동합니다.

code_block: <ListValue: [StructValue([('code', 'CLUSTERSCAN 0B3a21-{06S}-64 MATCH "user:*" COUNT 10\r\n1) "0B3a21-{07T}-0"\r\n2) 1) "user:102"\r\n2) 2) ...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad7431d150>)])]>

명령어가 '0' 커서를 반환하면 스캔이 완료됩니다.

사용 사례 2: 병렬화된 클러스터 스캔(여러 작업자)

이 전략은 처리량이 높은 스캔에 적합합니다. SLOT 인수를 사용하면 스캔이 특정 슬롯으로 제한되므로 16,384개의 슬롯을 여러 병렬 작업자에 분할할 수 있습니다.

작업자 1(슬롯 0을 스캔):

code_block: <ListValue: [StructValue([('code', 'CLUSTERSCAN 0 SLOT 0 MATCH "user:*" COUNT 10\r\n1) "0B3a21-{06S}-64"\r\n2) 1) "user:101"\r\n2) 2) ...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad66c215d0>)])]>

작업자 2(슬롯 1000을 병렬로 스캔):

code_block: <ListValue: [StructValue([('code', 'CLUSTERSCAN 0 SLOT 1000 MATCH "user:*" COUNT 10\r\n1) "0B3a21-{08X}-32\r\n2) 1) "user:999"\r\n2) 2) ...'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad670cb110>)])]>

여기에서 작업자 1은 계속해서 SLOT 0을 전달하고 작업자 2는 계속해서 SLOT 1000을 전달합니다. 슬롯과 커서가 일치하지 않으면 오류가 반환됩니다. 16,384개의 슬롯이 모두 스캔되면 클러스터 스캔이 완료된 것으로 간주됩니다.

3. 원자성 및 만료를 위한 추가 명령어

HGETDEL: 원자적 가져오기 및 삭제

일반적인 애플리케이션 패턴에서는 해시 필드를 읽고 즉시 삭제합니다(예: 일회용 인증 토큰 또는 단기 세션 상태 사용). Valkey 9.1에는 단일 네트워크 왕복에서 해시 필드의 값을 검색하고 원자적으로 삭제하는 HGETDEL이 도입되었습니다.

실제 사례:HSET user:1001 temp_token "abcde"(integer) 1HGETDEL user:1001 FIELDS 1 temp_token 1. "abcde"HGET user:1001 temp_token(nil)

MSETEX: 여러 키의 공유 만료 시간

새로운 MSETEX 명령어는 여러 키를 동시에 단일 공유 만료 시간으로 설정할 수 있어 다중 명령어 파이프라인 오버헤드를 제거합니다.

실제 사례: 서로 다른 여러 키가 300초 후에 함께 만료되도록 임시 세션 상태 설정:MSETEX 2 session:auth "ok" session:user_id "1001" EX 300(integer) 1TTL session:auth(integer) 300

조건부 플래그로 향상된 HSETEX

HSETEX는 이제 NX(필드가 없는 경우에만 설정) 및 XX(필드가 있는 경우에만 설정) 조건부 플래그를 지원합니다.

실제 사례: 1시간 TTL로 비율 제한 기준점 필드를 초기화하여 기존 활성 제한을 덮어쓰지 않도록 설정:HSETEX config:123 NX EX 3600 FIELDS 1 "rate_limit" "100"(integer) 1

Memorystore for Valkey 9.0 기반

Valkey 9.1은 Google Cloud Next '26에서 Memorystore for Valkey에 대해 발표한 주요 업데이트를 기반으로 출시되었습니다.

AI 및 벡터 워크로드를 위한 기본 제공 모듈: 기본 JSON 지원 및 블룸 필터를 통해 빠른 문서 쿼리 및 멤버십 검사가 가능합니다.
6가지 새로운 노드 크기: 비용과 규모를 관리하는 데 도움이 되도록 6가지 새로운 노드 크기를 추가했습니다.

소형 노드: 경량 마이크로서비스 및 개발/테스트 환경을 위한 Custom-Pico(1.25GB), Custom-Micro(2.5GB), Custom-Mini(3.5GB)를 지원합니다. 클러스터 모드가 사용 중지된 환경에서만 사용할 수 있습니다.
높은 CPU 및 대형 SKU: CPU 사용량이 많은 애플리케이션에 최적화된 HighCPU-Medium(8 vCPU/13GB) 및 Standard-Large(8 vCPU/26GB)를 지원합니다.
XXL SKU: 노드당 110GB RAM과 16개의 vCPU를 갖춘 Highmem-XXLarge로, 대규모 클러스터 통합을 통해 가장 까다로운 워크로드를 지원합니다.

(참고: 위 수치는 오픈소스 벤치마크를 기반으로 하며, 실제 성능 개선은 워크로드에 따라 달라질 수 있습니다.)

완전 관리형 Memorystore for Valkey로 마이그레이션

Redis OSS/Valkey 캐싱 레이어를 직접 관리해야 하는 경우 귀중한 엔지니어링 대역폭이 소모되고 확장 중에 운영상의 마찰이 발생합니다. 이번에 Memorystore for Valkey로 마이그레이션하는 새로운 워크플로도 발표하게 되어 기쁘게 생각합니다.

이번 출시를 통해 인프라 마이그레이션이 간단한 완전 관리형 방식으로 제공됩니다. 데이터가 마이그레이션되면 애플리케이션에서 Memorystore for Valkey를 가리키도록 간단한 구성만 변경하면 됩니다. 이 워크플로는 정식 버전으로 제공됩니다. 직접 관리하는 Redis 또는 Valkey에서 완전 관리형 Memorystore for Valkey로 전환하려면 다음 4단계를 따르세요.

1. 대상 인스턴스 프로비저닝: 필요한 샤드 수, 노드 크기, 클러스터링된 데이터베이스 옵션으로 구성된 Memorystore for Valkey 인스턴스를 배포합니다.

2. 온라인 복제 설정: 소스 데이터베이스에서 Memorystore로 직접 지속적인 이중 동기화 온라인 마이그레이션을 시작합니다.

3. 데이터 동기화 검증: 복제 측정항목을 실시간으로 모니터링하여 전체 데이터 세트 정렬과 짧은 지연 시간의 복제 상태를 확인합니다.

4. 컷오버 실행: 애플리케이션 연결 엔드포인트를 Memorystore for Valkey로 전환하여 새 캐시 사용을 시작합니다.

Memorystore for Valkey 고객 사례

이미 Google Cloud 상위 100대 고객 중 95% 이상이 Google Cloud Memorystore를 사용하여 까다롭고 처리량이 많은 워크로드를 지원하고 있으며, Memorystore for Valkey 사용자 수가 증가함에 따라 이러한 추세는 더욱 강화되고 있습니다.

빠르게 변화하는 라이브 스포츠 세계에서는 완벽한 디지털 경험을 제공하는 것이 무엇보다 중요합니다. 경기의 흐름을 바꾸는 플레이가 나오면 수백만 명의 팬이 즉시 자신들의 기기를 꺼내 실시간 통계를 확인하고, 하이라이트를 시청하고, 대화형 기능을 사용합니다. 이러한 대규모의 예측 불가능한 트래픽 급증을 처리하려면 엄청난 규모를 감당할 수 있는 기본 아키텍처가 필요합니다. Valkey의 초기부터 파트너였던 Major League Baseball(MLB)과 같은 조직의 경우 성능 저하 없이 예측할 수 없는 트래픽 급증을 관리하는 것이 필수적입니다.

"MLB는 Memorystore for Valkey를 신뢰하여 이를 통해 대규모 라이브 야구 경기를 지원하고 수백만 명의 팬에게 실시간 통계와 중단 없는 디지털 경험을 제공하고 있습니다. 앞으로 있을 Memorystore for Valkey 9.1의 출시도 매우 기대하고 있습니다. 엔진 최적화와 지연 시간 개선을 통해 가장 예측하기 어려운 경기 당일의 트래픽 급증을 처리할 수 있는 더 높은 성능을 확보하여 팬들에게 기술이 지원할 수 있는 최고의 경험을 제공할 수 있도록 할 것입니다." - Rob Engel, Major League Baseball 소프트웨어 엔지니어링 부문 SVP

경기장 밖에서도 리테일 업종은 특히 주요 쇼핑 시즌이나 반짝 세일 기간에 자체적으로 엄청난 확장 과제에 직면합니다. 현대적인 이커머스 플랫폼은 실시간 맞춤설정, 유동 가격, 즉각적인 인벤토리 업데이트를 통해 쇼핑객의 참여를 유도합니다. 단 몇 밀리초의 지연만으로도 고객 여정이 중단되고 수익에 영향을 미칠 수 있습니다. 경쟁력을 유지하기 위해 Target과 같은 선도적인 리테일러는 가장 중요한 고객 대상 플랫폼을 지원하는 초고속 응답 캐싱 레이어를 필요로 합니다.

"Target은 Google Cloud Memorystore for Valkey를 활용하여 지연 시간이 매우 짧고 복원력이 뛰어난 맞춤설정 서비스용 캐싱을 제공합니다. Valkey 9.1의 향상된 성능을 활용하여 수요가 많은 기간 동안 맞춤설정 플랫폼을 더욱 빠르고 확장 가능하며 복원력 있게 만들 수 있기를 기대합니다." - Scott Weide와 Sumanth Huddar, Target 선임 엔지니어링 관리자

이러한 지연 시간이 매우 짧은 아키텍처에 대한 수요는 스포츠와 리테일 업종을 넘어 다양한 분야로 확대되고 있습니다. 디지털 환경 전반에서 은행, AI 기반 개발, 디지털 스트리밍, 통신 분야의 조직은 모두 매우 빠르고 가용성이 높은 캐시가 필요하다는 공통된 요구사항을 가지고 있습니다. 고빈도 금융 거래 처리, 실시간 복잡한 머신러닝 추론 제공, 원활한 글로벌 동영상 스트림 전송, 방대한 양의 통신 데이터 라우팅 등 어떤 경우든 마이크로초 단위의 지연 시간은 성공을 위한 새로운 기준입니다.

Valkey로 전환

캐시 병목 현상으로 가장 까다로운 애플리케이션의 속도가 느려지는 문제를 방지할 수 있습니다. 지금 바로 Memorystore for Valkey 9.1의 성능, 동적 확장성, 향상된 보안을 경험해 보세요.

빌드 시작: Google Cloud 콘솔에서 Memorystore for Valkey 9.1 인스턴스를 만드세요.
자세히 알아보기: 기술 문서를 읽고 지원되는 명령어, ACL 구성, Memorystore for Valkey의 세부 기능에 대한 전체 목록을 확인하세요.

1인 창업자가 AlloyDB와 MCP를 기반으로 5개 대륙에서 입찰 플랫폼을 운영하는 방법

Tue, 06 Oct 2026 16:00:00 +0000

편집자 주: 5개 대륙의 시장에서 활동하는 입찰 인텔리전스 스타트업인 Lucius AI에서는 단일 운영자가 PostgreSQL용 AlloyDB를 기반으로 전체 데이터 플랫폼을 운영하고 있습니다. 이 기업은 시맨틱 검색을 ScaNN 색인으로 마이그레이션하고 모델 컨텍스트 프로토콜(MCP)로 데이터베이스 작업을 관리하여 쿼리 지연 시간을 47배 단축하고 MCP를 통해 일상적인 관리 작업을 자동화했습니다.

핵심 요약

Lucius AI는 영국, 오스트레일리아, 인도, EU 전역에서 210,000개 이상의 입찰 공고를 처리하는 글로벌 입찰 플랫폼을 운영하고 있지만, 1인 창업자에게 최소한의 운영 오버헤드만을 요구합니다.
Lucius AI는 PostgreSQL용 AlloyDB를 배포하여 관계형 카탈로그, 감사 로그, 벡터 임베딩을 단일 관리형 데이터베이스 엔진으로 통합했습니다.
시맨틱 검색을 ScaNN 색인으로 마이그레이션한 결과, 대표적인 프로덕션 쿼리에서 쿼리 지연 시간이 1.14초에서 24밀리초로 줄어 속도가 47배나 향상되었습니다.
Lucius AI는 모델 컨텍스트 프로토콜(MCP)을 사용해 AI 에이전트를 AlloyDB에 연결하여 엄격한 최소 권한에 따라 쿼리 분석, 데이터 기록 빈도 확인, 사고 포렌식을 자동화하고 있습니다.

1인 기업의 입찰 인텔리전스 활용

Lucius AI는 공공 계약에 입찰하는 기업이 글로벌 시장 전반의 기회를 평가할 수 있도록 지원합니다. 이 플랫폼은 뉴질랜드, 미국, 싱가포르, 영국, 오스트레일리아, 인도, 캐나다, EU의 공공 조달 공고와 아프리카 및 아시아 전역의 세계은행 기부금 지원 공고를 수집합니다. Lucius AI는 Gemini를 사용하여 입찰 공고 문서를 분석하고 규정 준수 매트릭스, 입찰 추천, 원본 소스 페이지를 인용한 응답 초안을 생성합니다. 이 플랫폼은 중소 규모 공급업체에서 수작업으로 처리하려면 며칠이 걸리는 문서 검토와 많은 비용이 드는 외부 컨설팅을 대체할 수 있습니다.

이러한 규모의 플랫폼을 운영하려면 광범위한 운영 조정이 필요합니다.

야간에 13개의 공공 조달 소스에서 데이터 수집
진행 중인 수만 건의 입찰을 포함한 210,000건 이상의 입찰 공고 카탈로그
Cloud Run의 두 프로덕션 리전: 유럽, 그리고 방위 산업 부문 고객을 위해 고객 관리 암호화 키(CMEK)를 사용하는 자체 AlloyDB 클러스터 기반의 오스트레일리아 배포
지속적인 분석, 성능 조정, 데이터 검증, 사고 대응

전담 데이터 엔지니어링팀 또는 데이터베이스 관리팀 없이 이러한 운영 업무를 관리하려면 운영 유지보수를 외부에 위임해야 합니다. Lucius AI는 PostgreSQL용 AlloyDB를 핵심 레코드 시스템으로 사용하고 모델 컨텍스트 프로토콜(MCP)을 통해 AI 에이전트를 연결하여 데이터베이스 작업을 안전하게 실행함으로써 이 문제를 해결했습니다.

AlloyDB로 시스템 통합

Lucius AI는 별도의 관계형 데이터베이스, 벡터 데이터베이스, 로그 스토어를 배포하는 대신 PostgreSQL용 AlloyDB에 모든 핵심 데이터를 저장합니다. 관계형 입찰 공고 카탈로그, 문서 메타데이터, 감사 로그, 벡터 임베딩이 동일한 데이터베이스 엔진에 상주합니다. 벡터 임베딩을 관계형 행과 함께 저장하면 별도의 벡터 스토어를 관리할 필요가 없고 통합된 백업 스케줄을 수립할 수 있으며 ID 관리를 중앙 집중화할 수 있습니다.

인증은 전적으로 Cloud IAM을 사용합니다. 서비스 연결 시 애플리케이션 환경에 데이터베이스 비밀번호를 저장하는 대신 특정 액세스 요구사항에 맞게 범위가 지정된 데이터베이스 역할에 매핑된 전용 Google Cloud 서비스 계정을 사용합니다. AlloyDB에서 자동 백업 및 PITR(point-in-time recovery)을 통해 데이터베이스 안정성을 기본적으로 관리해 주므로 커스텀 재해 복구 절차가 필요하지 않습니다.

이 통합 아키텍처는 프로덕션에서 다음과 같은 사항을 지원합니다.

카탈로그에 210,000개 이상의 입찰 공고가 포함되어 있으며 임베딩이 함께 저장됩니다.
시맨틱 색인을 다시 빌드하는 과정에서 Gemini 임베딩 모델을 사용하여 약 3달러에 불과한 API 비용으로 10.6분 만에 115,820개의 레코드를 임베딩했습니다. 현재는 AlloyDB 자동 임베딩을 통해 이러한 벡터를 최신 상태로 유지하고 있습니다.
ai.rank 함수를 사용하여 검색 순위 재지정을 평균 지연 시간 77밀리초로 데이터베이스 내에서 직접 실행하여 독립형 순위 재지정 마이크로서비스 없이도 검색어에 가장 관련성 높은 결과를 반환합니다.

시맨틱 검색 속도 47배 향상

입찰 공고 카탈로그 전반의 시맨틱 검색에서 처음에는 색인이 생성되지 않는 벡터 비교를 사용하여 대표 쿼리에 1.14초가 걸렸습니다. 이 워크로드를 AlloyDB의 ScaNN 색인으로 마이그레이션한 결과, 쿼리 지연 시간이 24밀리초로 단축되어 속도가 47배 개선되었습니다.

색인 추천은 색인 마이그레이션을 준비하기 전에 쿼리 계획을 벤치마킹한 자동화된 성능 감사 과정에서 AI 에이전트를 통해 생성되었습니다.

MCP를 사용한 데이터베이스 작업 자동화

Lucius AI는 일상적인 관리 작업을 위임하기 위해 사전 빌드된 alloydb-postgres 서버를 사용하여 오픈소스 데이터베이스용 MCP 도구 상자를 구성했습니다.

운영 위임에는 엄격한 액세스 제어가 필요합니다. 이 에이전트는 스키마 전반의 SELECT 권한과 단일 운영 테이블에 대한 UPDATE 권한이 부여된 전용 PostgreSQL 역할을 사용하여 연결됩니다. 파괴적인 명령어 (DROP, DELETE, TRUNCATE)는 생략하여 에이전트 작업을 승인된 운영 경계로 제한합니다.

이 구성에 따라 AI 에이전트가 4가지 주요 영역에서 정기적인 데이터베이스 작업을 수행하고 있습니다.

주문형 분석: 임시 SQL 쿼리를 통해 국가별로 유지 사용자 집단, 활성화 유입경로, 카탈로그 적용 범위를 컴파일하여 수동 대시보드나 복잡한 분석 파이프라인을 빌드하고 유지보수할 필요가 없습니다.
성능 최적화: ScaNN 색인 생성 전략 식별과 같은 쿼리 계획 검사 및 색인 분석을 수행합니다.
사고 포렌식: 외부 보안 프로브에 대응하여 에이전트가 감사 로그를 파싱하여 몇 분 만에 요청 타임라인을 재구성하고 테넌트 격리가 그대로 유지되었는지 확인합니다.
자동화된 데이터 품질 검사: 매일 아침 13개 조달 소스 전체에서 수집 워터마크와 최신 상태를 평가합니다.

이 아키텍처를 채택할 경우 점진적인 권한 구조를 설정하면 명확한 가드레일을 마련할 수 있습니다. 읽기 전용 액세스로 시작하고, 요구사항에 따라 권한을 확장하고, 파괴적인 작업은 인간 관리자로 제한하면 됩니다.

향후 계획

Lucius AI는 운영 오버헤드를 더욱 줄이기 위해 세 가지 기술 이니셔티브를 계획하고 있습니다.

AlloyDB AI의 자동화된 벡터 임베딩: 전체 카탈로그에서 ai.initialize_embeddings를 검증한 후 주간 유지보수 작업에서 ai.refresh_embeddings를 사용하여 벡터를 업데이트합니다.
열 기반 엔진 가속화: 자동 열 지정을 지원하는 AlloyDB의 열 기반 엔진을 사용 설정하자 데이터베이스에서 하루 만에 4개의 테이블에서 자주 쿼리되는 열 40개를 식별하여 메모리에 저장했습니다. 그 결과, 별도의 분석 스토어 없이도 보고 쿼리 속도가 향상되었습니다.
관리형 원격 MCP 서버: 자체 호스팅 도구 상자 프로세스에서 Google Cloud의 AlloyDB용 완전 관리형 원격 MCP 서버로 전환해 MCP 서버 호스팅 및 유지보수 부담을 줄일 예정입니다.

Lucius AI는 AlloyDB를 핵심 데이터의 기반으로 삼고 MCP를 통해 일상적인 작업을 관리하면 엔지니어가 한 명이더라도 복원력 있는 멀티 리전 조달 플랫폼을 빌드하고 운영할 수 있음을 보여줬습니다.

Lucius AI에 대해 자세히 알아보려면 ailucius.com을 방문하세요. PostgreSQL용 AlloyDB를 평가하려면 AlloyDB 클러스터를 배포하여 자체 워크로드로 성능을 테스트해 보세요.

AI 에이전트가 준비되었습니다. 그렇다면 데이터는 어떤가요?

Thu, 01 Oct 2026 21:00:00 +0000

조직이 AI 이니셔티브를 확장하는 데 있어 가장 큰 병목 현상 중 하나는 무엇일까요? 오늘날 모델의 기능이 아니라 비즈니스 컨텍스트와 시맨틱 의미에 대한 액세스 권한이 문제입니다.

에이전트 시대에 기업은 단순히 데이터를 저장하는 것을 넘어 신뢰할 수 있는 컨텍스트로 데이터를 활성화하여 수동적인 기록 시스템에서 선제적인 행동 시스템으로 전환해야 합니다.

하지만 AI 에이전트는 비선형 속도로 작동합니다. 예를 들어 단일 프롬프트로 에이전트가 여러 시스템에서 독립적으로 탐색, 쿼리, 실행을 수행하도록 트리거할 수 있어 기본 인프라에 부담을 줄 수 있습니다. 컴퓨팅, 네트워킹, 스토리지 레이어가 에이전트 AI에 최적화되어 있지 않으면 그 위에 있는 데이터 플랫폼이 제대로 작동하지 않습니다.

Google Cloud의 인프라 현황 보고서 에 따르면 조직의 83% 가 프로덕션급 에이전트 AI 시스템을 지원하려면 인프라를 업그레이드해야 한다고 생각하는 것은 당연한 일입니다.

이 문제를 해결하기 위해 Google Cloud는 2026년 Google Cloud Next에서 데이터, AI 모델, 운영 데이터베이스를 단일 작업 시스템으로 통합하는 에이전트형 데이터 클라우드를 도입했습니다. 에이전트형 데이터 클라우드가 작동하려면 칩에서 모델에 이르기까지 AI 네이티브여야 합니다. 기본 인프라는 에이전트 부하를 수용할 수 있어야 합니다.

Google의 에이전트형 데이터 클라우드

적절한 인프라 기반이 에이전트형 데이터 클라우드에 어떤 힘을 실어주어 오늘날 조직이 직면한 가장 큰 데이터 문제를 해결할 수 있는지 살펴보겠습니다.

컨텍스트 부족 극복

에이전트형 시스템이 효과적으로 작동하려면 분산된 데이터 시스템과 기존 아키텍처에서 자주 발견되는 컨텍스트에 액세스할 수 있어야 합니다. 이로 인해 에이전트가 이러한 컨텍스트를 파악하기 어려워 불완전하고 부정확한 결과가 나올 수 있습니다. 실제로 Google Cloud 보고서에 따르면 IT 리더의 43% 가 '레거시 API 및 데이터 소스와의 통합이 어려움'을 에이전트 AI 인프라의 가장 큰 허점으로 꼽았습니다.

하지만 조직은 복잡성과 비용을 늘리지 않고는 대규모 데이터 세트를 이동하여 AI에 연결할 수 없습니다.

Google의 에이전트형 데이터 클라우드는 개방적이고 유연한 인프라에서 실행되는 경계 없는 레이크하우스 를 활용하여 이 문제를 해결합니다. 에이전트는 개방형 표준 (Apache Spark, Apache Iceberg)을 통해 BigQuery 및 Spanner와 같은 강력한 기본 엔진에 액세스하여 마치 로컬 데이터인 것처럼 환경 전반에서 데이터를 읽고, 추론하고, 활성화할 수 있으므로 기존 설정의 지연 시간과 비용을 우회할 수 있습니다.

불필요한 수동 작업에서 벗어나기

연결되지 않은 시스템의 패치워크에서 에이전트를 확장하면 상당한 병목 현상이 발생할 수 있습니다. Google Cloud의 연구에 따르면 리더의 81% 가 AI를 확장할 때 예상치 못한 비용이 발생하는 주요 원인으로 운영 복잡성과 엔지니어링 오버헤드를 꼽았습니다 . 서로 다른 시스템 전반에 걸쳐 AI 에이전트를 연결하기 위해 엔지니어가 수동으로 작업하는 데 드는 시간을 그 이유로 들었습니다.

생각에서 행동으로 옮기려면 에이전트는 분석 소스와 운영 소스 모두에서 실시간 데이터를 연결할 수 있어야 합니다. 이를 위해서는 수직적 통합이 필요합니다. 모델, 데이터 시스템, 기본 가속기가 공동 설계된 AI 네이티브 인프라를 기반으로 에이전트형 데이터 클라우드를 빌드하면 네트워크 홉이 줄어들고 도구가 더 잘 통합됩니다. 이 통합 시스템을 사용하면 에이전트가 일반적인 엔지니어링 오버헤드 없이도 인사이트에 도달하고 안전한 트랜잭션을 트리거할 수 있습니다.

데이터에 신뢰와 지식 제공

에이전트가 데이터를 발견하고 쿼리하는 것만으로는 충분하지 않습니다. 안전하고 정확한 조치를 취하려면 에이전트에게 풍부한 컨텍스트와 비즈니스 로직도 필요합니다. 그러나 AI 모델 그라운딩에 사용되는 특화된 고처리량 벡터 데이터베이스가 부족하다는 점을 주요 인프라 격차로 꼽은 리더가 36% 에 달하며, 이는 에이전트에게 컨텍스트를 제공하는 능력을 저해하는 요인으로 작용합니다.

에이전트가 잠재력을 최대한 발휘하려면 기존 ERP와 서드 파티 CRM을 포함한 데이터 시스템을 실시간으로 읽고 쓸 수 있도록 빌드된 기반이 필요합니다. 또한 3주 전에 사용자가 설정한 선호도를 기억한 상태로 현재 복잡한 작업을 수행할 수 있는 장기 기억 능력이 필요합니다. 이러한 실시간 자동화가 없으면 에이전트는 모든 쿼리에 대해 데이터를 다시 처리해야 합니다.

AI에 컨텍스트를 제공하기 위해 조직은 Knowledge Catalog를 사용하여 데이터 레이크의 데이터를 집계하고 보강하며 에이전트형 검색을 지원하고 있습니다. 비정형 데이터에서 의미를 추출하고 시맨틱스를 자동으로 생성하는 카탈로그는 활성 추론 레이어 역할을 합니다. 에이전트가 올바른 컨텍스트를 검색할 수 있도록 이 카탈로그는 처리량이 높은 인프라로 뒷받침되어야 합니다.

앞으로의 방향

AI를 진정한 경쟁 우위로 전환하려면 연결된 활성 데이터 생태계를 구축해야 합니다. 파일럿에서 프로덕션으로 전환하려면 에이전트가 모든 데이터에 원활하게 액세스할 수 있어야 하며, 이를 위해서는 에이전트 시대의 요구사항을 처리할 수 있는 인프라가 지원되어야 합니다. 2026년 이후의 승자는 반드시 가장 스마트한 에이전트를 보유한 기업이 아닐 것입니다. 이들은 에이전트에 적절한 지식을 안전하고 비용 효율적으로 대규모로 제공할 수 있는 사람들입니다. 데이터는 에이전트 시대에 맞게 준비되어 있나요?

에이전트 AI 시대의 인프라 현황 보고서에서 리더들이 AI에 최적화된 아키텍처 접근방식을 어떻게 취하고 있는지 확인해 보세요.

BigQuery 그래프를 사용한 식품 공급망의 디지털 트윈 모델링

Mon, 28 Sep 2026 20:00:00 +0000

성장하는 레스토랑의 예

식당 체인을 운영한다고 가정해 보겠습니다. 비즈니스가 어떻게 운영되는지 알기 위해 직접 만져보고 느낄 수 없기 때문입니다. 비즈니스의 상태를 감지할 수 있는 도구와 비즈니스의 디지털 복제본이 필요합니다.

성장의 마찰

성장으로 인해 스프레드시트로는 해결할 수 없는 고유한 종류의 마찰이 발생합니다.

채찍 효과: 다운스트림의 작은 수요 변화가 업스트림의 인벤토리 파도로 증폭됩니다.
SOP 이탈: 표준 준비 작업에서 약간만 벗어나도 결국 전체 브랜드 분위기가 훼손됩니다.
식품 안전 영향 범위: 오염된 재료 하나가 네트워크 전반에 걸쳐 복잡하고 지저분한 위험 지도를 만듭니다.
무단 지출: 현지 관리자가 계약 외 식재료를 구매하여 발생한 '백만 달러의 누수'

디지털 트윈

디지털 모델을 사용하면 세상에 대해 더 통찰력 있는 질문을 던질 수 있지만, 데이터를 구성하는 방식에 대해 중요한 선택을 해야 합니다. 기존의 관계형 테이블이 표준이었지만, 여전히 모든 작업에 적합한 도구인지 물어봐야 합니다. 세상은 본질적으로 상호 연결되어 있으므로 그래프 기반 모델로 전환하는 것이 현실을 포착하기 위한 자연스러운 진화일 수 있습니다.

수천 개의 애셋, 복잡한 공급망 또는 글로벌 물류 네트워크를 관리할 때 기존의 관계형 데이터베이스는 종속 항목을 추적하기 위해 리소스 집약적인 대규모 SQL 조인이 필요합니다. 이 아키텍처는 물리적 이벤트와 운영 인식 사이에 지연 시간 격차를 만듭니다.

BigQuery 그래프를 사용한 모델링

BigQuery 그래프를 사용하면 기존 데이터 플랫폼 내에서 전체 공급망의 디지털 트윈을 빌드할 수 있습니다. 물리적 세계(항목, 레시피, 위치)를 노드와 엣지로 이루어진 검색 가능한 맵으로 전환하면 새로운 차원의 명확성을 얻을 수 있습니다.

1. 시맨틱 계층 정의

데이터를 새 데이터베이스로 이동하는 대신 기존 테이블 위에 그래프 뷰를 만듭니다. 이렇게 하면 BigQuery에서 테이블이 서로 어떻게 관련되어 있는지 정확히 알 수 있습니다.

쿼리 언어:

code_block: <ListValue: [StructValue([('code', '# Build the Graph Nodes & Edges\r\nCREATE or REPLACE PROPERTY GRAPH `restaurant.bombod`\r\nNODE TABLES (\r\n `restaurant.item` label item properties all columns,\r\n `restaurant.location` label location properties all columns,\r\n `restaurant.itemlocation` label itemlocation properties all columns\r\n)\r\nEDGE TABLES (\r\n `restaurant.bom`\r\n KEY(bomKey)\r\n SOURCE KEY (childItemLocation) REFERENCES `restaurant.itemlocation`(itemLocationKey)\r\n DESTINATION KEY (parentItemLocation) REFERENCES `restaurant.itemlocation`(itemLocationKey)\r\n LABEL consists_of properties all columns\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad75dc5050>)])]>

BigQuery 그래프를 사용하여 모델링한 가상의 레스토랑 공급망 이미지

실무에서의 정밀도

이러한 변화는 일상 업무에 어떤 영향을 미치나요? 비즈니스를 혼란에서 정밀함으로 전환합니다.

수술 리콜: 공급업체가 리스테리아 발생을 보고하면 그래프를 앞으로 이동하여 어떤 특정 레스토랑의 어떤 메뉴 항목이 영향을 받았는지 정확히 파악합니다.
날씨 위험 분석: 허리케인이 유통 센터를 위협할 때 매장 목록이 아닌 영향 범위가 표시됩니다. 해당 허브에 크게 의존하는 위치를 파악하고 보급품을 다른 경로로 재전송합니다.

2. 검색 실행

그래프 쿼리는 모델러와 데이터 과학자가 데이터를 쿼리할 수 있는 새로운 도구입니다. 복잡한 다중 도메인 데이터 개념을 단순화하고 쿼리를 간소화하며 데이터 분석을 문제 표현의 더 단순하고 자연스러운 표현으로 만듭니다. 예를 들어 닭고기를 취급하는 모든 위치를 알고 싶다면 아래와 같이 그래프 쿼리를 실행할 수 있습니다.

특정 불만사항이나 위험을 조사하기 위해 그래프 쿼리 언어를 사용하여 모델에 대한 검색을 실행합니다.

Graph Query Language

code_block: <ListValue: [StructValue([('code', "# Navigate to the source of a specific ingredient issue\r\nGraph restaurant.bombod\r\nMATCH (a:itemlocation)-[c:consists_of]->(b:itemlocation) \r\nWHERE b.itemKey LIKE '%Chicken%'\r\nRETURN to_json([to_json(a),to_json(c),to_json(b)]) as result"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad67165710>)])]>

악취의 근원 - 그래프로 모델링

미래를 위한 기반 구축

디지털 트윈을 최대한 활용하려면 다음 원칙을 따르세요.

구조에 집중: 그래프를 사용하여 관계와 종속 항목을 파악하고, 일일 매출 합계를 관계형 테이블에 보관합니다.
키 정리: 데이터 엔지니어링에 시간을 투자하세요. 그래프는 연결만큼 강력합니다.
에지 속성 캡처: 리드 타임이나 배송비와 같은 메타데이터를 에지에 직접 저장하여 모델의 유용성을 높입니다.

결론

레스토랑 업계는 비즈니스 데이터를 목록으로만 취급하는 관계형 방식을 벗어났습니다. BigQuery 그래프를 사용해 디지털 트윈으로 도메인 간 관계를 빌드하면 반응적인 문제 해결에서 선제적인 모델링으로 전환할 수 있습니다. 이제 목록으로 네트워크를 관리하는 대신 몇 초 만에 연결을 확인할 수 있습니다.

지금 시작하기

여기 에서 튜토리얼을 확인하세요.
BigQuery 문서를 방문하여 개요 와 빠른 시작 가이드를 확인하세요.
의견 공유: 커뮤니티에 참여하고 bq-graph-preview-support@google.com을 통해 질문에 대한 답변을 받아보세요.
관련 블로그: BigQuery 그래프 소개

AlloyDB 및 Cloud SQL의 네이티브 BM25 순위 지정 발표

Mon, 28 Sep 2026 20:00:00 +0000

벡터 검색은 생성형 AI, 검색 증강 생성 (RAG), 데이터 에이전트 아키텍처의 중요한 구성요소이지만, 때로는 벡터 검색만으로는 충분하지 않습니다. 벡터 임베딩은 개념적 의미를 이해하는 데 탁월하지만 특정 영숫자 ID와 정확한 제품 SKU 번호에는 어려움을 겪습니다. 진정으로 강력한 검색 및 AI 애플리케이션을 빌드하려면 시맨틱 벡터 검색과 기존의 정확한 키워드 전체 텍스트 검색을 결합해야 할 수 있습니다. 이를 하이브리드 검색이라고 합니다.

검색에서 BM25(Best Matching 25)는 문서가 주어진 쿼리와 얼마나 관련이 있는지 추정하는 데 사용되는 핵심 알고리즘입니다. 지금까지 AlloyDB 또는 Cloud SQL에서 BM25 순위를 지정하려면 추가적인 전체 텍스트 검색 백엔드를 추가해야 했습니다. 이로 인해 데이터 사일로, 동기화 지연, 운영 복잡성이 발생했습니다. 오늘 Google Cloud는 Tiger Data에서 만든 오픈소스 pg_textsearch 확장 프로그램을 통해 AlloyDB 및 PostgreSQL용 Cloud SQL 17+에서 기본 BM25 색인을 미리보기로 제공하여 별도의 전체 텍스트 검색 백엔드를 유지관리하는 데 드는 부담을 완전히 없애드립니다.

이제 통합된 하이브리드 검색 백엔드를 사용하면 최첨단 전체 텍스트 검색을 위해 별도의 시스템을 프로비저닝, 관리하거나 비용을 지불할 필요가 없습니다. 이 모든 작업은 운영 데이터가 저장된 데이터베이스 내에서 직접 이루어지며 다음과 같은 이점을 제공합니다.

업계 표준 키워드 순위: Tiger Data의 pg_textsearch를 기반으로 C에 최적화된 BM25 점수를 Postgres 테이블에 바로 제공합니다.
복잡성 해소, 완전한 일관성: 벡터 및 전체 텍스트 검색을 위해 여러 백엔드를 유지보수할 때 발생하는 데이터 중복, ETL 파이프라인, 동기화 지연을 제거합니다.
강화된 시맨틱 검색(AlloyDB 전용): ScaNN 및 HNSW 색인 유형을 사용하여 표준 PostgreSQL에 비해 최대 6배 및 10배 더 빠른 벡터 검색 쿼리를 얻을 수 있습니다.

pg_textsearch를 사용해야 하는 이유

의미 있는 규모로 전체 텍스트 검색을 위해 PostgreSQL의 기본 제공 ts_rank 를 사용해 본 적이 있다면 이미 그 한계를 알고 있을 것입니다. 코퍼스가 커질수록 순위 품질이 저하됩니다. 역문서 빈도에 대한 지원이 없으므로 일반적인 단어와 드문 단어의 가중치가 동일합니다. 용어 빈도 포화가 없으므로 '데이터베이스'를 50번 언급하는 문서가 한 번 언급하는 문서보다 순위가 높습니다.

BM25는 정보 검색의 표준으로, 역문서 빈도 (더 희귀한 용어가 더 중요함), 용어 빈도 포화 (반복이 지배하지 않음), 문서 길이 정규화를 제공합니다. Tiger Data가 PostgreSQL 페이지에서 BM25 검색 엔진을 빌드한 방법에 대한 자세한 내용은 이 블로그 게시물을 참고하세요.

전체 텍스트 검색 예시

AlloyDB와 Cloud SQL에서 BM25 전체 텍스트 검색을 시작하는 방법은 다음과 같습니다. 고유 식별자 uniq_id, product_name 열, 각 제품의 텍스트 설명을 포함하는 product_description 열, 생성된 product_embedding 열을 포함하는 샘플 테이블 cymbal_products를 고려해 보겠습니다. cymbal_products 에는 실내 및 실외 식물을 포함한 다양한 소매 제품에 대한 정보가 포함되어 있습니다.

색인 생성

BM25를 사용하려면 pg_textsearch 확장 프로그램을 사용 설정합니다.

code_block: <ListValue: [StructValue([('code', '-- Install pg_textsearch extension\r\nCREATE EXTENSION pg_textsearch;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad74087350>)])]>

cymbal_products 테이블의 product_description열에 색인을 만듭니다.

code_block: <ListValue: [StructValue([('code', "-- Create the native BM25 index on the content column\r\nCREATE INDEX idx_docs_bm25 \r\nON cymbal_products \r\nUSING bm25 (product_description) \r\nWITH (text_config='english');"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad74085d90>)])]>

<@> 특수 연산자를 사용하여 BM25 전체 텍스트 검색 쿼리를 실행할 수 있습니다. 아래 스니펫에서는 'cherry tree'를 검색합니다.

code_block: <ListValue: [StructValue([('code', "-- Full text search query\r\nSELECT product_name, product_description <@> 'cherry tree' AS bm25_score \r\nFROM cymbal_products\r\nORDER BY bm25_score \r\nLIMIT 5;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad74087090>)])]>

샘플 출력은 아래와 같습니다. 점수가 더 음수일수록 관련성이 더 높습니다.

AlloyDB 하이브리드 검색 예시

AlloyDB에서 하이브리드 검색 시스템을 설정하는 것은 간단합니다. 동일한 테이블에서 벡터 색인과 키워드 색인을 모두 생성하고 하이브리드 검색 사용자 정의 함수 (UDF)를 사용하여 결과를 원활하게 병합할 수 있습니다.

벡터 색인 생성

ScaNN 벡터 검색 색인을 만드는 방법은 다음과 같습니다.

code_block: <ListValue: [StructValue([('code', '-- Install vector extension\r\nCREATE EXTENSION vector;\r\n\r\n-- Install scann extension\r\nCREATE EXTENSION IF NOT EXISTS alloydb_scann;\r\n\r\n-- Create scann vector search index \r\nCREATE INDEX cymbal_products_embeddings_scann ON cymbal_products USING scann(product_embedding cosine);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad740844d0>)])]>

하이브리드 검색

AlloyDB는 하이브리드 검색 쿼리를 매우 간단하게 실행할 수 있는 기본 제공 하이브리드 검색 UDF를 제공합니다. UDF는 RRF (Reciprocal Rank Fusion) 알고리즘을 사용하여 각 검색 구성요소의 순위가 지정된 결과를 단일 통합 목록으로 병합합니다. 이 쿼리는 UDF를 활용하여 제품 설명에서 '집보다 키가 큰 나무'에 대한 벡터 검색과 '캘리포니아'에 대한 키워드 검색을 수행합니다.

code_block: <ListValue: [StructValue([('code', 'CREATE EXTENSION google_ml_integration;\r\n\r\nSELECT *\r\nFROM ai.hybrid_search(\r\n search_inputs => ARRAY[\r\n \'{\r\n "data_type": "vector",\r\n "weight": 0.5,\r\n "table_name": "cymbal_products",\r\n "key_column": "uniq_id",\r\n "vec_column": "product_embedding",\r\n "distance_operator": "public.<=>",\r\n "limit": 10,\r\n "query_vector": "ai.embedding(\'\'text-embedding-005\'\', \'\'trees that grow taller than houses\'\')::vector"\r\n }\'::JSONB,\r\n \'{\r\n "data_type": "text",\r\n "weight": 0.5,\r\n "table_name": "cymbal_products",\r\n "key_column": "uniq_id",\r\n "text_column": "product_description",\r\n "limit": 10,\r\n "ranking_function": "<@>",\r\n "query_text_input": "California"\r\n }\'::JSONB\r\n ],\r\n);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad740855d0>)])]>

아래 샘플 출력에서 볼 수 있듯이 결과는 RRF 점수의 내림차순으로 순위가 매겨집니다.

여기서 하이브리드 검색은 시맨틱 직관과 정확한 키워드 매칭 사이의 간극을 메웁니다. 벡터 임베딩은 '집보다 큰 나무'와 같은 개념적 쿼리를 파악하는 데 탁월하지만, 기존의 전체 텍스트 검색은 '캘리포니아'와 같은 엄격한 식별자에 필요한 정확한 정밀도를 제공합니다. AlloyDB는 이 두 가지를 융합하여 애플리케이션이 '캘리포니아 시카모어'와 같이 지역과 관련성이 높은 매우 구체적인 결과를 목록의 맨 위에 표시하도록 보장합니다.

Cloud SQL 하이브리드 검색 예시

Cloud SQL에서는 아래와 같이 동일한 테이블에 벡터 색인과 키워드 색인을 모두 만들고 공통 테이블 표현식 (CTE)을 사용하여 결과를 원활하게 병합하고 RRF 점수를 병합할 수 있습니다.

벡터 색인 생성

Cloud SQL에서 HNSW 색인을 만드는 방법은 다음과 같습니다.

code_block: <ListValue: [StructValue([('code', '-- Install vector extension\r\nCREATE EXTENSION vector;\r\n\r\n-- Create an HNSW index on the embedding column for fast approximate nearest neighbor search\r\nCREATE INDEX product_hnsw_idx ON cymbal_products USING hnsw(product_embedding vector_cosine_ops);'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad74087650>)])]>

하이브리드 검색

하이브리드 검색 쿼리는 다음과 같습니다.

code_block: <ListValue: [StructValue([('code', "CREATE EXTENSION google_ml_integration;\r\n\r\n-- BM25 keyword results\r\nWITH keyword_results AS (\r\n SELECT uniq_id, product_name, \r\n ROW_NUMBER() OVER (ORDER BY product_description <@> 'California') AS rank_kw\r\n FROM cymbal_products\r\n ORDER BY product_description <@> 'California'\r\n LIMIT 10\r\n),\r\n-- Semantic vector results\r\nsemantic_results AS (\r\n SELECT uniq_id, product_name, \r\n ROW_NUMBER() OVER (ORDER BY product_embedding <=> google_ml.embedding('text-embedding-005', 'trees that grow taller than houses')::vector) AS rank_vec\r\n FROM cymbal_products\r\n ORDER BY product_embedding <=> google_ml.embedding('text-embedding-005', 'trees that grow taller than houses')::vector\r\n LIMIT 10\r\n)\r\n-- Reciprocal Rank Fusion (RRF) to merge and score both lists\r\nSELECT COALESCE(k.uniq_id, s.uniq_id) AS uniq_id,\r\n COALESCE(k.product_name, s.product_name) AS product_name,\r\n COALESCE(1.0 / (60 + k.rank_kw), 0) + COALESCE(1.0 / (60 + s.rank_vec), 0) AS rrf_score\r\nFROM keyword_results k\r\nFULL OUTER JOIN semantic_results s ON k.uniq_id = s.uniq_id\r\nORDER BY rrf_score DESC\r\nLIMIT 5;"), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad740861d0>)])]>

결과 출력은 위에 표시된 AlloyDB 하이브리드 검색 결과와 동일합니다.

실제 사례 확인

데모 동영상에서 이 모든 것이 어떻게 결합되는지 확인해 보세요.

시작할 준비가 되셨나요? 확인해 보세요”

AlloyDB 리소스

AlloyDB 사용이 처음이신가요? 30일 무료 체험판 으로 AlloyDB를 살펴보세요.
AlloyDB AI에서 벡터 색인 선택
AlloyDB BM25 문서
AlloyDB 하이브리드 검색 UDF 문서

Cloud SQL 리소스

Cloud SQL BM25 문서

Tiger Data pg_textsearch 출시 페이지

M4N VM 제품군 정식 버전 출시: I/O 및 메모리 집약적 워크로드를 위한 코어당 최고 수준의 IOPS 및 처리량 제공

Mon, 28 Sep 2026 16:00:00 +0000

엔터프라이즈 조직이 미션 크리티컬 애플리케이션을 확장함에 따라 스토리지 I/O 및 메모리 액세스가 심각한 운영 병목 현상을 초래할 수 있습니다. Oracle 데이터베이스, SAP HANA와 같은 인메모리 데이터베이스, 높은 처리량의 SQL Server 클러스터, EHR 시스템, 실시간 빅데이터 분석 등 메모리 집약적 데이터베이스를 사용하는 기업은 필요한 RAM 용량과 스토리지 대역폭을 확보하기 위해 컴퓨팅 코어(vCPU)를 과도하게 프로비저닝해야 하는 경우가 많으며, 이는 고가의 서드 파티 소프트웨어 라이선스 비용 상승으로 이어집니다.

오늘 Google Compute Engine에서 네트워크 및 블록 스토리지 최적화 VM 제품군의 두 번째 제품인 M4N 머신 시리즈의 정식 버전을 출시했습니다. 이 머신 시리즈는 I/O 집약적인 고성능 메모리 워크로드를 위해 특별히 설계되었습니다. 다른 하이퍼스케일러의 유사 제품과 비교했을 때 M4N은 고성능 메모리 인스턴스에서 코어당 가장 높은 IOPS 및 처리량을 제공하며 Oracle 데이터베이스의 총소유비용을 20% 이상 절감합니다.

또한 M4N은 더 높은 메모리 비율(최대 26:1)과 크기(6TB)로 최적화된 업계 최초의 네트워크 및 블록 스토리지 인스턴스입니다. 5세대 인텔® 제온® 스케일러블 프로세서로 구동되고 Google Cloud의 커스텀 Titanium 오프로드 아키텍처를 기반으로 빌드된 M4N 인스턴스는 Hyperdisk Extreme과 결합 시 최대 25,000MiB/s(25GiB/s)의 총 호스트 스토리지 성능과 최대 100만 IOPS를 제공하여 기존 M4 인스턴스의 블록 스토리지 성능을 두 배로 높입니다.

M4N은 극도로 높은 밀도의 RAM과 타협 없는 I/O 성능을 모두 요구하는 워크로드를 대상으로 하며, 높은 처리량을 필요로 하는 엔터프라이즈 애플리케이션의 특정 스토리지 및 네트워크 병목 현상을 해결하여 기존 메모리 최적화 제품군(M1, M2, M3, M4, X4 등)을 보완합니다.

고성능을 요구하는 워크로드를 위해 설계됨

워크로드 카테고리	대표적인 적용 분야	M4N의 장점
미션 크리티컬 엔터프라이즈 DB	Oracle, SAP HANA, SQL Server, IBM DB2, MySQL, PostgreSQL	최대 26.57GB/vCPU의 메모리 대 코어 비율과 25GiB/s의 스토리지 성능을 결합하여 신속한 데이터 수집, 트랜잭션 로깅 및 지연 없는 백업 주기를 지원합니다.
생성형 AI 및 RAG 데이터 레이어	Milvus, Pinecone, Qdrant, Vespa, Redis, 인메모리 컨텍스트 캐싱	RAM의 대규모 벡터 색인을 대상으로 1밀리초 미만의 유사성 검색을 수행하고, 분산 모델 검색을 위해 400Gbps의 네트워크 대역폭을 결합합니다.
엔터프라이즈 의료 및 ERP	Epic Systems(운영 데이터베이스), SAP ECC, SAP S/4HANA	지속적인 I/O 여유 공간으로 임상 및 트랜잭션 처리량이 급증하는 시간대에 쿼리 지연 시간 급증을 방지합니다.
실시간 분석 및 EDA	전자 설계 자동화, 유전체학 모델링, 인메모리 OLAP	대규모 데이터 세트를 RAM에 온전히 로드할 수 있는 높은 메모리 용량과 체크포인트 덤프를 위한 최대 스토리지 대역폭을 갖추고 있습니다.

Oracle 라이선스 비용 최적화

엔터프라이즈 IT 부서는 코어 기반 소프트웨어 라이선스 비용 상승으로 어려움을 겪고 있습니다. Oracle 데이터베이스와 같은 워크로드의 경우 라이선스 요금은 일반적으로 인스턴스에 할당된 vCPU 또는 물리적 코어 수를 기준으로 산정됩니다. 지금까지는 필요한 양의 RAM과 스토리지 성능을 얻기 위해 필요 이상으로 많은 컴퓨팅 코어에 대한 비용을 지불해야 했습니다.

M4N은 업계 최고의 높은 메모리 대 vCPU 비율로 이러한 패러다임을 바꿉니다. M4N은 모든 주요 하이퍼스케일러의 고성능 메모리 인스턴스 중 코어당 가장 높은 IOPS와 처리량을 제공하므로 데이터베이스 관리자는 다음과 같은 이점을 누릴 수 있습니다.

TCO 및 라이선스 오버헤드 감소: Oracle 데이터베이스 성능 밀도 요구사항을 충족하면서 코어의 과도한 프로비저닝을 방지하여 주요 하이퍼스케일러의 유사 제품에 비해 TCO를 20% 이상 절감합니다.
인프라 규모 적정 조정: 대규모 메모리 풀에 액세스하는 동시에 워크로드에 필요한 정확한 양의 컴퓨팅 성능을 할당할 수 있습니다.
캐시 적중률 개선: 코어당 사용 가능한 메모리가 늘어나면 데이터베이스의 더 많은 부분이 시스템 글로벌 영역(SGA)에 상주할 수 있어 비용이 많이 드는 I/O 작업을 줄이고 효율성을 더욱 높일 수 있습니다.

고객의 의견

M4N을 조기에 도입한 결과, 워크로드에 최적화된 인프라가 혁신의 원동력임이 입증되었습니다.

“M4N 도입 전에는 Google Cloud에서 까다로운 I/O 요구사항을 충족하고 필요한 성능 밀도를 확보하기 위해 컴퓨팅 리소스를 과도하게 프로비저닝해야 하는 경우가 많았습니다. 새로운 M4N 인스턴스는 소형부터 대형까지 다양한 사양에서 높은 처리량을 제공하여 이 문제를 해결합니다." - 셰리 트로잔, Sabre 수석 솔루션 설계자

"Google Cloud가 미션 크리티컬 데이터베이스 워크로드를 위한 차세대 고성능 인프라를 선보여서 매우 기쁩니다. 이 새로운 컴퓨팅 플랫폼은 확장성, 복원력, 고성능이 필요한 엔터프라이즈급 Oracle 배포에 있어 엄청난 잠재력을 보여줍니다. Google Cloud에서 Oracle 워크로드를 실행하는 고객에게 이 혁신이 어떤 의미를 가질지 기대가 큽니다.” - 발라 쿠치보틀라, Tessell 공동 설립자 겸 CEO

"Google Cloud는 M4N을 통해 플랫폼 공동 설계의 한계를 계속해서 넓혀가고 있습니다. 5세대 인텔 제온 스케일러블 프로세서와 Google의 커스텀 Titanium 오프로드 아키텍처를 결합한 M4N은 세계에서 가장 까다로운 미션 크리티컬 데이터 환경에 필요한 압도적인 메모리 용량, 높은 메모리 대역폭, 타협 없는 I/O 처리량을 제공합니다." - 인텔

새로운 소식: M4N으로 극한의 데이터 레이어 확장

M4N은 클라우드 인프라에서 이전에는 별개로 여겨졌던 두 가지 패러다임인 대규모 메모리 사용량과 극한의 I/O 성능을 하나로 연결합니다. 커스텀 Titanium 오프로드로 설계된 M4N은 인프라 부가기능이나 메모리 밀도 저하 없이 I/O 병목 현상을 최소화합니다. M4N이 이러한 환경에 어떻게 적용되는지 살펴보겠습니다.

1. 고대역폭 데이터 전송 지원

대규모 메모리 사용량이 요구되는 워크로드의 경우 M4N은 다음과 같은 이점을 제공합니다.

우수한 VM 간 대역폭: 동일한 VPC 내에서 최대 400Gbps의 집계 VM 간 네트워크 대역폭과 최대 50Gbps의 단일 흐름 대역폭을 제공하여 분산 데이터베이스 클러스터와 실시간 스트리밍 데이터 레이어를 위한 비차단 데이터 교환을 지원합니다.
향상된 인터넷 및 이그레스 처리량: 최대 200Gbps의 인터넷 이그레스 대역폭과 최대 48MPPS의 패킷 처리 성능을 제공합니다.
즉시 사용 가능한 고대역폭: 프리미엄 Tier_1 네트워킹 부가기능을 구매하거나 구성할 필요 없이 최대 성능을 구현할 수 있습니다.

2. Hyperdisk를 통한 동적 스토리지 성능

Google Cloud의 차세대 스토리지 포트폴리오와 결합된 Hyperdisk 기반 M4N을 사용하면 IOPS, 처리량, 용량을 독립적으로 조정할 수 있습니다.

Hyperdisk Extreme(HdX): 최대 25GiB/s의 집계 블록 스토리지 처리량과 1,000,000 IOPS를 제공하며, 이는 표준 M4의 스토리지 성능보다 두 배 높은 수준입니다. 이는 신속한 데이터베이스 복구, 트랜잭션 체크포인트 설정, 즉각적인 인메모리 색인 새로고침에 적합합니다.
Hyperdisk Balanced(HdB): 최대 20GiB/s의 처리량과640,000 IOPS까지 확장되어 대규모 환경에서 비용 효율적인 엔터프라이즈 스토리지를 제공합니다.

M4N 머신 유형 및 사양

M4N 인스턴스는 3가지 메모리 대 vCPU 비율 등급으로 제공되며, 16~224개의 vCPU와 최대 5,952GB의 DDR5 RAM까지 확장 가능합니다. 또한 M4N은 특정 워크로드 요구사항에 맞게 세 가지 메모리 대 vCPU 비율로 사전 정의된 VM 구성을 제공하며, 리소스 기반 약정 사용 할인(CUD)을 지원합니다. 자세한 내용은 여기에서 확인하세요.

지금 시작하기

M4N 인스턴스는 현재 전 세계 일부 리전에서 이용 가능합니다. M4N 제품군이 메모리 및 I/O 집약적 애플리케이션의 성능을 어떻게 향상시키고 라이선스 비용을 절감할 수 있는지 자세히 알아보려면 계정 담당자에게 문의하거나 관련 문서를 참조하세요.

Database Migration Service의 Gemini를 사용하여 PostgreSQL 마이그레이션 가속화

Mon, 28 Sep 2026 00:00:00 +0000

팀에서 Oracle 또는 SQL Server와 같은 기존 상용 데이터베이스에서 오픈소스 PostgreSQL 또는 PostgreSQL용 AlloyDB와 같은 완전 관리형 서비스로 핵심 애플리케이션을 마이그레이션하기로 결정한 시나리오를 가정해 보겠습니다.

초기 단계는 순조롭게 진행됩니다. 스키마가 변환되고, 테이블이 채워지고, 데이터 마이그레이션 파이프라인이 테라바이트 규모의 데이터를 몇 시간 만에 전송합니다. 프로젝트가 일정보다 앞서 진행되고 있습니다.

그러면 팀은 병목 현상에 직면하게 됩니다.

기존 데이터베이스에는 PL/SQL 또는 T-SQL과 같은 독점적인 SQL 언어로 작성된 수백 개의 저장 프로시저, 복잡한 트리거, 커스텀 함수가 포함되어 있습니다. 이러한 루틴에는 트랜잭션 검증, 주문 처리, 맞춤 보고를 처리하는 중요한 비즈니스 로직이 수년간 포함되어 있습니다.

갑자기 현대화 프로젝트가 중단됩니다. 수천 줄의 절차적 논리를 변환하려면 전문적인 이중 언어 전문 지식, 수개월의 수동 재작성, 높은 변환 오류 위험이 필요합니다. 이 코드 변환은 데이터베이스 마이그레이션의 '라스트 마일' 병목 현상을 나타내며 마이그레이션에서 가장 복잡한 부분입니다.

다행히도 최근 AI의 발전으로 라스트 마일 문제에 대한 해결책이 마련되었습니다. Database Migration Service (DMS)에는 Gemini 기반의 AI 지원 코드 변환 기능이 포함되어 있습니다. 생성형 AI를 마이그레이션 워크플로에 직접 도입하면 저장 프로시저, 트리거, 커스텀 함수를 PostgreSQL PL/pgSQL 코드로 더 빠르고 정확하게 변환할 수 있습니다.

저장 프로시저 변환 과제

상용 데이터베이스 엔진은 저장 프로시저, 사용자 정의 함수, 패키지 본문, 조건부 논리에 대해 공급업체별 구문을 사용합니다. 이 로직을 PostgreSQL PL/pgSQL로 변환하려면 변수 정의, 예외 처리 블록, 커서 루프, 기본 제공 함수를 매핑해야 합니다.

수백 개의 저장 프로시저가 포함된 복잡한 엔터프라이즈 스키마를 마이그레이션할 때 수동 코드 변환에는 몇 달에 달하는 엔지니어링 노력이 필요한 경우가 많습니다. 데이터베이스팀은 레거시 로직을 한 줄씩 파싱하고, 조건부 분기를 다시 구현하고, 엔진 간 데이터 유형 변환을 검증해야 합니다.

DMS의 AI 지원 코드 변환

Database Migration Service의 Gemini는 Google Cloud 콘솔 내에서 직접 이러한 변환 작업을 가속화합니다. DMS는 소스 언어와 PostgreSQL 간의 구조적 차이점을 설명하는 AI 생성 코드 추천과 함께 자동화된 스키마 변환을 제공합니다.

이 서비스는 변환된 PL/pgSQL 코드를 원본 소스 코드와 나란히 표시하므로 데이터베이스팀은 제안을 실시간으로 검토, 수정, 검증할 수 있습니다.

그림 1: 코드 변환과 Gemini 인라인 설명을 나란히 표시하는 Database Migration Service 인터페이스

통합 AI가 중요한 이유

주요 공급업체의 대부분의 AI 앱과 도구는 SQL 코드를 포함한 코드를 생성하고 변환할 수 있습니다. 그러나 엔터프라이즈 데이터베이스를 변환하려면 일반적인 AI 채팅 도구에서 제공하는 스니펫 번역보다 훨씬 더 많은 것이 필요합니다. Database Migration Service의 Gemini는 다음과 같은 몇 가지 주요 이점을 제공합니다.

전체 스키마 컨텍스트: DMS의 Gemini는 코드 스니펫을 개별적으로 평가하는 대신 테이블 관계, 데이터 유형, 종속 뷰, 전체 마이그레이션 프로젝트의 교차 프로시저 참조를 포함한 전체 데이터베이스 컨텍스트를 분석합니다.
엔터프라이즈 보안 및 개인 정보 보호: 코드 변환은 Google Cloud 프로젝트 경계 및 IAM 거버넌스 내에서 엄격하게 실행되어 독점적인 비즈니스 로직과 지식 재산을 보호합니다.
통합 실행 작업공간: DMS는 수백 개의 파일에 걸쳐 수동으로 복사하여 붙여넣는 작업을 없애줍니다. 단일 콘솔 내에서 나란히 표시된 차이점을 검토하고, 인라인 AI 설명을 검사하고, 코드를 편집하고, 검증된 PL/pgSQL 루틴을 대상 데이터베이스에 직접 배포할 수 있습니다.
결정론적 정확성 및 AI 컴파일: DMS는 표준 DDL 변환, 스칼라 함수, 잘 정의된 문법 변환과 같은 1:1 매핑을 위한 결정론적 컴파일러 규칙을 복잡한 절차 블록을 위한 Gemini 컨텍스트 합성 기능과 결합하여 모델 드리프트 없이 정확하고 예측 가능한 변환을 보장합니다.

Oracle PL/SQL을 PostgreSQL로 변환

고유한 NVL 및 DECODE 함수를 사용하여 고객 주문 합계를 계산하고 등급 기반 할인을 적용하는 Oracle PL/SQL 저장 프로시져를 고려해 보겠습니다. 원래 워크플로에서는 NVL을 COALESCE에 수동으로 매핑하고, DECODE 문을 표준 CASE 표현식으로 다시 작성하고, WHEN NO_DATA_FOUND THEN과 같은 예외 블록을 조정해야 합니다.

DMS에서 마이그레이션 평가를 실행하면 Gemini가 소스 프로시저를 분석하고 기본 PostgreSQL PL/pgSQL 코드를 생성합니다.

소스: Oracle PL/SQL

code_block: <ListValue: [StructValue([('code', 'CREATE OR REPLACE PROCEDURE calculate_discount (\r\n p_customer_id IN NUMBER,\r\n p_discount OUT NUMBER\r\n) AS\r\n v_total NUMBER := 0;\r\nBEGIN\r\n SELECT NVL(SUM(amount), 0) INTO v_total\r\n FROM orders WHERE customer_id = p_customer_id;\r\n \r\n p_discount := DECODE(TRUE, v_total > 10000, 0.15, v_total > 5000, 0.10, 0.05);\r\nEXCEPTION\r\n WHEN NO_DATA_FOUND THEN\r\n p_discount := 0;\r\nEND;\r\n/'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad75dc6750>)])]>

타겟: PostgreSQL PL/pgSQL (DMS의 Gemini로 변환)

code_block: <ListValue: [StructValue([('code', 'CREATE OR REPLACE FUNCTION calculate_discount (\r\n p_customer_id NUMERIC,\r\n OUT p_discount NUMERIC\r\n) RETURNS NUMERIC AS $$\r\nDECLARE\r\n v_total NUMERIC := 0;\r\nBEGIN\r\n SELECT COALESCE(SUM(amount), 0) INTO v_total\r\n FROM orders WHERE customer_id = p_customer_id;\r\n\r\n p_discount := CASE\r\n WHEN v_total > 10000 THEN 0.15\r\n WHEN v_total > 5000 THEN 0.10\r\n ELSE 0.05\r\n END;\r\nEND;\r\n$$ LANGUAGE plpgsql;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad67236510>)])]>

생성된 SQL과 함께 Gemini는 NVL이 COALESCE로 변환된 이유와 Oracle DECODE 함수가 PostgreSQL의 명시적 CASE 블록으로 변환된 방법을 자세히 설명하는 인라인 설명을 제공합니다.

그림 2: DMS의 Gemini로 구동되는 엔드 투 엔드 데이터베이스 코드 변환 파이프라인

완전한 스키마 제어 및 검증 유지

보안, 투명성, 코드 정확성은 데이터베이스 현대화의 핵심 요소로 남아 있습니다. DMS의 Gemini는 설정된 Google Cloud 보안 경계 내에서 엄격하게 작동하여 코드를 프로젝트에 비공개로 유지합니다.

신뢰성을 보장하기 위해 전환 및 검증 프로세스는 구조화된 워크플로를 따릅니다.

자동 스키마 컨텍스트 가져오기: DMS 변환 작업공간을 설정하면 서비스가 테이블 스키마, 데이터 유형, 외래 키 제약조건, 교차 프로시저 종속 항목을 포함한 전체 소스 데이터베이스 메타데이터를 자동으로 파싱합니다. Gemini는 코드 생성 중에 이 프로젝트 전체 컨텍스트를 참조하므로 종속 객체 정의를 수동으로 제공할 필요가 없습니다.
자동화된 구문 및 종속 항목 검증: 코드가 생성되면 DMS는 대상 PostgreSQL 구문 규칙에 대해 검증 파서를 실행합니다. 객체에는 검증 상태 표시기 (예: 변환됨, 경고 또는 조치 필요)가 할당되어 수동 검토가 필요한 루틴을 빠르게 강조 표시합니다.
대화형 평가 상태: 모든 스키마 변경사항을 완전히 제어할 수 있습니다. 변환 작업공간 내에서 나란히 표시된 차이점을 검사하고, 인라인 AI 설명을 검토하고, 변경사항을 타겟 데이터베이스에 적용하기 전에 PL/pgSQL 코드를 직접 편집할 수 있습니다.
스테이징 배포 및 검증: 코드의 작업공간 검증이 통과되면 변환된 스키마와 함수를 프로덕션 전환 전에 기능 실행 및 성능 테스트를 위해 대상 스테이징 인스턴스 (예: Cloud SQL 또는 AlloyDB)에 적용할 수 있습니다.

데이터베이스 현대화 간소화

Database Migration Service의 AI 지원 코드 변환은 데이터베이스팀이 몇 달이 아닌 며칠 만에 기존 데이터베이스 로직을 변환할 수 있도록 도와줍니다. 데이터베이스 관리자와 애플리케이션 개발자는 코드를 처음부터 다시 작성하는 데 귀중한 시간을 낭비하는 대신 새로운 기능을 추가하고, 성능을 테스트하고, 애플리케이션을 현대화하는 데 집중할 수 있습니다.

일반적인 Oracle 및 SQL Server 변환 시나리오와 DMS가 이를 PostgreSQL로 변환하는 방법에 대한 좋은 예시를 확인하려면 최근에 게시된 Gemini가 알려주는 PostgreSQL 동영상 시리즈를 시청하세요.

데이터베이스 마이그레이션의 어려움은 이제 그만, Gemini가 기존 데이터베이스 로직을 원활하게 변환하는 방법을 알려드립니다.

Database Migration Service 시작하기

데이터베이스 변환을 시작하려면 Database Migration Service 콘솔 (https://console.cloud.google.com/dms)에서 마이그레이션 평가를 시작하거나 이기종 마이그레이션 가이드 (https://cloud.google.com/database-migration)를 읽어보세요.

통신 업계 자율성 확대: 분산 그래프 흐름(Distributed GraphFlow)으로 GNN 활용

Sun, 27 Sep 2026 22:00:00 +0000

전자통신 업계는 현재 기존의 수동적인 인간 중심 운영에서 완전한 자율 네트워크 운영으로 전환되는 패러다임 변화를 겪고 있습니다. 최신 네트워크는 점점 더 복잡하고 이질적이며 대규모로 성장하고 있어 수작업 규칙 기반 방법과 기존 머신러닝(ML) 접근 방식만으로는 네트워크 운영을 자동화하기에 충분하지 않습니다. ML 메서드는 대량의 정형 데이터에서 미묘한 패턴을 식별하고 정밀한 예측을 수행할 수 있지만, 데이터와 데이터가 나타내는 시스템을 이해하고 추론하며 궁극적으로 인간 운영자가 내릴 법한 결정을 내리는 능력은 부족합니다.

AI 에이전트의 성장과 추론 능력은 이러한 한계를 해결할 수 있는 유망한 솔루션입니다. 그러나 인간 운영자가 대규모 네트워크에서 생성된 수십억 개의 데이터 포인트에 분산된 통계 정보를 직접 수집할 수 없는 것과 마찬가지로, AI 에이전트도 이러한 규모로 작동할 수 있는 능력이 부족합니다. 이러한 문제를 해결하기 위해 통신 기업들은 방대한 시간 및 관계형 데이터에서 네이티브로 작동하도록 설계된 최신 형태의 머신러닝인 그래프 신경망(GNN)을 도입하고 있습니다. GNN을 AI 에이전트와 통합하면 운영자는 근본 원인 분석, 용량 계획, 트래픽 예측, 가상 시나리오 시뮬레이션, 실시간 이상 감지와 같은 고급 진단 기능을 이러한 인사이트를 해석하고 합당한 조치를 실행하는 데 필요한 추론 능력과 결합할 수 있습니다. 이 강력한 조합을 통해 네트워크는 시스템이 자율적으로 작동하는, TM Forum에서 정의한 레벨 5 자율성으로 안전하게 전환할 수 있습니다.

이 게시물에서는 Google Cloud의 자율 네트워크 운영 프레임워크를 지원하는 세 가지 구성요소(데이터, ML, AI)를 소개합니다.

Google 자율 네트워크 운영 프레임워크 아키텍처

기반: Spanner Graph의 디지털 트윈

Google Cloud의 자율 네트워크 운영 프레임워크의 핵심은 네트워크 디지털 트윈입니다. 이는 실제 통신 네트워크를 지속적으로 실시간 미러링하는 매우 상세한 가상 복제본입니다. 이 디지털 트윈은 정적 모델이 아니라 시간 경과에 따라 구성요소의 진화하는 상태와 관계를 포착하는 동적, 시간적 네트워크 그래프로 표현됩니다. 이러한 아키텍처 접근 방식을 통해 운영자는 마치 과거로 돌아간 것처럼 이전 데이터로 ML 모델을 학습시키고 평가할 수 있으며, AI 에이전트에게 레벨 5 자율성을 달성하는 데 필요한 기본적인 운영 지식을 제공할 수 있습니다. 디지털 트윈은 이 디지털 환경 내에서 제안된 네트워크 변경의 영향을 시뮬레이션함으로써 중요한 신뢰 계층을 구축하여 AI 에이전트가 미래 상태를 자신 있게 설계하고 네트워크 문제를 자동으로 해결할 수 있도록 합니다.

Google Cloud의 Spanner Graph는 이 디지털 트윈을 호스팅하는 데 특히 적합합니다.

확장성 및 가용성: Spanner Graph는 최신 애플리케이션을 위한 타협 없는 기반을 제공하며, 네트워크가 성장함에 따라 사실상 무제한으로 확장할 수 있고, 0-RPO/0-RTO 및 99.999%의 가용성을 제공합니다.
멀티 모델 지원: 단일 플랫폼에서 여러 데이터 모델(관계형, 그래프, 벡터, 전체 텍스트 검색)을 지원하므로 개발자가 최근접 이웃 벡터 검색과 결합된 그래프 횡단과 같은 복잡한 구성을 빌드할 수 있습니다.
전역 일관성: Spanner는 네트워크에 대한 전역적으로 일관된 뷰를 제공하여 시스템 개발을 간소화합니다.

다음 그림은 라우터, 인터페이스(물리적 포트), VPN(L3VPN 서비스 인스턴스), 흐름(활성 트래픽 세션)이라는 네 가지 노드 유형으로 구성된 네트워크 토폴로지를 보여줍니다. 이들은 전체 네트워크 스택을 캡처하는 방향성 에지 유형으로 연결됩니다. 물리적 포함(라우터-인터페이스), 물리적 링크(인터페이스-인터페이스), 컨트롤 플레인 피어링(OSPF/iBGP를 통한 라우터-라우터), 서비스 멤버십(라우터-VPN), 트래픽 앵커링(흐름-인터페이스, 흐름-VPN)이 여기에 해당합니다.

상위 수준 네트워크 토폴로지

ML 레이어: 분산 그래프 흐름(DGF)

네트워크가 어떻게 작동하고 반응할지 예측하기 위해 디지털 트윈은 분산 그래프 흐름(DGF)으로 구동되는 ML 레이어를 활용합니다. 이 레이어는 Spanner Graph 내에 호스팅된 방대한 양의 과거 정형 데이터를 학습하여 중요한 예측 인사이트를 도출하고, 이를 통해 인간 운영자와 AI 에이전트가 사후 대응이 아닌 선제적으로 네트워크를 관리할 수 있도록 지원합니다.

DGF는 최근 오픈소스로 공개된 Python 라이브러리로, GNN 모델링의 전체 엔드 투 엔드 수명 주기를 관리하도록 설계되었습니다. Google CoreML과 Google 연구팀이 개발한 이 제품은 지난 10년간 Google 내부에서 축적된 대규모 도구와 전문성을 Google Cloud 엔터프라이즈 고객에게 직접 제공합니다. 이 라이브러리는 다양한 엔지니어링 요구사항을 충족하기 위해 숙련된 팀을 위한 고성능의 구성 가능한 하위 수준 프리미티브와 함께 사전 GNN 전문 지식이 필요 없는 빠른 개발을 위한 간단한 API를 제공합니다.

예를 들어 GraphFlow에서 상위 수준 API를 사용하여 GNN 모델을 학습시키고 평가하는 작업은 코드 5줄로도 충분할 만큼 간단합니다.

code_block: <ListValue: [StructValue([('code', 'import dgf\r\n\r\n# Fetch the data from Spanner Graph\r\ngraph, schema = dgf.io.read_spanner_graph(...)\r\n\r\n# Train a node attribute prediction model\r\nmodel = dgf.learning.train_node_model(graph, schema, target_column="risk_score")\r\n\r\n# Evaluate the model\r\nmodel.evaluate()\r\n# Make predictions\r\nmodel.predict(graph, seed_node_idxs=[0, 1, 2])\r\n\r\n# Save the model for later\r\nmodel.save("/tmp/model")'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad676f8290>)])]>

DGF는 자율 네트워크 운영 요구사항에 직접 매핑되는 상위 수준 개념을 제공합니다.

사용 사례

통신사는 DGF와 GNN을 활용하여 다음과 같은 여러 고급 사용 사례를 통해 사후 대응적 유지보수에서 선제적 예방으로 전환할 수 있습니다.

이상 감지: GNN은 과거 패턴과 현재 상태를 캡슐화하는 노드 및 에지 임베딩을 생성합니다. 비정상적인 임베딩은 서비스 성능 저하로 이어지기 전에 검토를 위해 플래그가 지정됩니다.
근본 원인 분석(RCA): DGF는 특정 우편번호 지역의 '연결 실패'와 같이, 사고와 관련된 네트워크 인스턴스만 포함하는 특정 하위 그래프를 출력할 수 있습니다. 이를 통해 문제 해결 에이전트는 전체 글로벌 네트워크를 스캔하지 않고도 고속 분석을 수행할 수 있습니다.
예측 유지보수: 시스템이 빠르게 움직이는 장비의 '핸드오버 실패'와 같은 기기 장애 또는 에지 중단 가능성을 예측하여 선제적인 부하 분산 또는 경로 재지정이 가능합니다. 또한 에이전트를 결합하면 '휴먼온더루프/휴먼인더루프' 방식을 도입하여 문제 해결 조치를 자동화할 수 있습니다.
가상 시나리오 분석: GNN을 사용하면 통신사가 광케이블 단선, 트래픽 급증, 기기 구성 변경과 같은 시나리오를 시뮬레이션할 수 있습니다. 토폴로지적 종속 항목을 모델링함으로써 GNN은 이러한 국지적 변화가 전체 네트워크에 어떻게 전파되는지 예측할 수 있으며, 이를 통해 엔지니어는 위험이 없는 디지털 환경에서 복원력을 테스트하고 완화 전략을 평가할 수 있습니다.

시나리오: GNN 및 DGF를 사용한 근본 원인 분석

디지털 트윈(예시 코드)을 만들고 나면 간단한 5단계 프로세스를 통해 GNN과 DGF를 활용한 근본 원인 분석(RCA) 탐지를 구현할 수 있습니다.

디지털 트윈에 연결: DGF Spanner Graph 커넥터(dgf.io.read_spanner_graph)를 사용하여 Spanner Graph의 디지털 트윈에서 DGF 환경으로 네트워크 토폴로지를 직접 로드합니다.
지도 노드(또는 에지) 예측 모델 학습: 학습 데이터와 목표에 따라 지도 노드 예측 모델을 학습시켜 타겟 노드 특성을 예측하거나, 에지 예측 모델을 학습시켜 근본 원인 항목 노드와 영향을 받는 항목 노드 간의 에지를 예측합니다. 제공된 샘플 데이터에 대해 상위 수준 dgf.learning.train_node_model API를 사용하여 지도 노드 예측 모델을 학습시킵니다.
노드 예측 모델을 사용하여 근본 원인 노드 예측: 노드 예측 모델을 직접 사용하여 이상이 있는 노드에 대한 영향 점수를 예측할 수 있습니다. 예측된 영향 점수가 가장 높은, 즉 이상치의 영향을 받는 항목 노드가 근본 원인의 주요 후보가 됩니다.
Gemini Enterprise Agent Platform(이전 명칭: Vertex AI)에 배포: 모델을 내보내고 Gemini Enterprise 엔드포인트에서 호스팅하여 확장 가능하고 지연 시간이 짧은 예측을 지원합니다.
실시간 추론: 이상치 날짜를 입력으로 사용하여 추론 엔드포인트에 예측 호출을 수행합니다. 엔드포인트는 예측된 근본 원인 항목 노드를 반환합니다.

지금 시작하세요

분산 그래프 흐름(Distributed Graph Flow)을 사용한 GNN을 네트워크 운영에 통합하는 것은 단순한 기술 업그레이드를 넘어 통신 업계의 중대한 진화입니다. GNN 기반 자율 프레임워크로 전환하면 운영자는 서비스 중단 시간을 크게 단축하고, 실시간으로 용량을 최적화하며, 궁극적으로 운영 효율성 개선을 통해 우수한 고객 경험을 제공할 수 있습니다.

나만의 지능형 네트워크 애플리케이션을 빌드하려면 확장 가능한 GNN 학습 및 추론을 위한 필수 프리미티브를 제공하는 Distributed GraphFlow(DGF) 라이브러리를 확인하세요. 직접 체험해 보려면 단계별 코드 샘플을 따라 해보세요. 또한 비즈니스 인식 GNN 복구 네트워크와 관련하여 최근 수상 경력에 빛나는 문샷 프로젝트를 살펴보고 이 백서를 검토하여 자체 최적화 자율 네트워크에 대한 Google의 접근 방식을 더 자세히 알아볼 수 있습니다.

AlloyDB Omni RPM 조정자를 사용하는 엔터프라이즈급 PostgreSQL 정식 버전 출시

Wed, 16 Sep 2026 22:00:00 +0000

프로덕션에 즉시 사용 가능한 보안, 복원력을 갖추고 다운타임을 최소화한 운영을 엔터프라이즈 환경의 PostgreSQL 워크로드에 제공하는 AlloyDB Omni Red Hat RPM 조정자의 정식 버전 출시를 발표하게 되어 기쁘게 생각합니다. 이번 정식 버전 출시는 프리뷰 출시 기간에 마련된 기반을 토대로 하며, AlloyDB Omni 버전 18.3.0과 함께 출시되어 Google AI 기능을 통해 클라우드와 유사한 데이터베이스 자동화를 가상 머신과 베어메탈 서버에 직접 제공합니다.

이 정식 버전 출시를 기준으로 AlloyDB Omni를 요구사항에 맞게 네 가지 모드로 배포할 수 있습니다. 자세한 내용은 AlloyDB Omni 문서를 참고하세요.

독립형 컨테이너(Debian/UBI)
고가용성 엔터프라이즈 배포를 위한 Kubernetes 오퍼레이터가 포함된 컨테이너
독립형 RPM
고가용성 엔터프라이즈 배포를 위한 RPM 조정자 포함

자체 관리형 데이터베이스를 실행해야 하는 이유

대부분의 사용 사례에서 관리형 클라우드 데이터베이스 서비스는 가장 간단하고 비용 효율적인 옵션입니다. 그러나 클라우드 안팎에서 PostgreSQL 데이터베이스를 직접 실행하는 시나리오도 있습니다. AlloyDB Omni RPM 배포는 클라우드의 성능과 컨테이너화되지 않은 로컬 인프라의 제어가 필요한 조직을 위해 빌드되었으며, 사용 사례는 다음과 같습니다.

워크로드 현대화: AlloyDB Omni는 표준 PostgreSQL L에 비해 트랜잭션 워크로드 속도가 2배 이상 빠르고 분석 쿼리 속도는 최대 100배 더 빠르므로 전체 마이그레이션 없이도 기존 인프라를 개선할 수 있습니다.
규제 환경: 데이터 레지던시 및 보안 요구사항이 엄격한 업종의 경우 RPM 조정자가 SELinux 및 로컬 감사 로깅과 같은 필요한 도구를 제공하여 규정 준수 상태를 유지합니다.
에지 및 온프레미스 배포: 에지 또는 베어메탈 서버에 배포하면 지연 시간이 짧은 처리와 연결 해제된 작업이 가능합니다.
AI 지원 인프라: 최신 생성형 AI 애플리케이션을 위한 벡터 검색과 같은 AlloyDB AI 기능을 온프레미스에서 직접 사용하여 AI 통합을 위한 데이터베이스 클러스터를 프로비저닝할 수 있습니다.

유연한 참조 아키텍처

AlloyDB Omni RPM 조정자는 성능 극대화, 읽기 처리량 확장, 강력한 고가용성(HA) 보장 등 조직의 특정 운영 요구사항에 맞게 조정된 유연한 배포 모델을 제공합니다. 자세한 내용은 AlloyDB Omni 가용성 참조 아키텍처 개요를 참조하세요. 조정자는 인스턴스 파라미터, 노드 구성, 네트워킹 옵션을 조정하여 맞춤설정할 수 있는 참조 아키텍처 사양을 정의할 수 있도록 하여 클러스터 프로비저닝 및 수명 주기 관리를 간소화합니다. 다음은 확장 가능한 AlloyDB Omni HA 참조 아키텍처의 배포 뷰 예시입니다.

RPM 조정자를 사용하는 AlloyDB Omni 클러스터의 고가용성 참조 아키텍처

이 다이어그램은 RPM 조정자가 관리하는 AlloyDB Omni의 가용성이 높은 분산 데이터베이스 참조 아키텍처를 보여줍니다. 클라이언트 애플리케이션이 강력한 부하 분산 계층에 연결되고 부하 분산기가 읽기-쓰기 트래픽을 활성 기본 데이터베이스 노드로 직접 라우팅하는 반면, 읽기 전용 트래픽은 복제본 노드로 라우팅되는 것을 보여줍니다. 부하 분산기는 가상 IP(VIP)를 사용하며, Keepalived(VIP 장애 조치용), PgBouncer(PostgreSQL 연결 풀링용), Haproxy(라우팅 및 부하 분산용)를 통해 자체적으로 고가용성을 제공합니다. AlloyDB Omni 기본 인스턴스 데이터베이스 노드는 여러 영역에 데이터를 동기식으로 복제하여 고가용성을 달성합니다. 기본 HA 클러스터에 영향을 주지 않고 읽기 집약적인 워크로드를 수평 확장하기 위해 별도의 읽기 풀 인스턴스가 배포됩니다. 이러한 노드는 활성 노드로부터 비동기 복제를 수신하며 수평 확장할 수 있습니다.

독립적인 컨트롤 플레인이 클러스터의 전체 구성과 상태를 관리하는 방식을 보여줍니다. 관리자는 RPM 조정자와 상호작용하여 데이터베이스의 수명 주기를 감독합니다. 컨트롤 플레인에는 중복 클러스터 관리자와 3노드 etcd 기반 분산 구성 스토어가 포함되어 클러스터 상태를 안정적으로 유지하고 구성을 관리합니다. 컨트롤러는 각 개별 데이터베이스 노드에서 실행되는 노드 관리자와 직접 상호작용합니다. 단일 클러스터만 배포하는 경우 동일한 노드 집합에서 컨트롤 플레인과 데이터 플레인 구성요소를 실행할 수 있습니다.

고가용성 및 읽기 확장성

RPM 조정자를 사용하면 더욱 간편하게 업타임을 유지하고 까다로운 워크로드의 읽기를 확장할 수 있습니다. 모든 데이터/제어 경로 구성요소와 읽기 가능한 대기 노드의 장애를 처리하고 노드 간의 네트워크 중단을 완화하는 기능을 포함하여 스택 전반의 장애를 자동으로 처리할 수 있는 복원력 있는 아키텍처를 제공합니다.

이제 조정자가 읽기 워크로드를 수평 확장하기 위한 읽기 풀을 지원하며, 분석 쿼리 또는 유사한 워크로드의 니즈를 충족하기 위해 클러스터에 읽기 풀을 동적으로 만들거나 추가할 수 있는 기능을 제공합니다. 또한 시스템은 대기 노드와 읽기 풀 모두에 전용 읽기 엔드포인트를 구성합니다.

Google Cloud는 AlloyDB Omni RPM 조정자의 기능을 지속적으로 확장하고 있습니다. 비즈니스 연속성과 리전 간 복원력을 더욱 강화하는 고급 엔터프라이즈급 기능을 비롯해 곧 출시될 기능을 기대해 주세요.

데이터 보호 및 보안

데이터 보안 및 복구는 RPM 조정자의 핵심입니다. 이번 출시 버전에서는 자동화된 백업 및 복원 기능을 통합하여 백업 일정을 구성하고 GCS 또는 S3 호환 스토리지에 대한 완전 자동화된 백업을 자동으로 관리할 수 있습니다. 조정자를 사용하면 S3 또는 GCS 버킷이나 로컬에서 백업을 실행할 수 있습니다. 또한 PITR(point-in-time recovery) 및 완전 자동화된 인플레이스 PIT 복원이 기본적으로 지원됩니다.

RPM 조정자는 부트스트랩 시 또는 부트스트랩 후에 SELinux 시행을 지원하여 엄격한 엔터프라이즈 규정 준수 및 보안 표준을 충족하고 필수 액세스 제어와 강력한 프로세스 격리를 보장합니다.

데이터베이스 작업

데이터베이스 Fleet 관리와 관련된 운영 오버헤드를 줄였습니다.

번거로움 없는 짧은 다운타임 유지보수: 완전히 자동화된 새로운 짧은 다운타임 유지보수(LDTM)를 통해 수명 주기 업데이트 및 확장 작업을 더 쉽게 관리할 수 있습니다. 마이너 버전 업그레이드와 CPU 및 메모리 리소스 조정은 가용성을 극대화하기 위해 다운타임을 최소화하고 자동 롤백을 지원하는 방식으로 실행됩니다.
동적 구성: 데이터베이스 관리자는 부트스트랩 시 또는 부트스트랩 후에 GUC/구성을 수정하는 기능을 포함하여 번거로움 없이 설정을 동적으로 조정할 수 있습니다. AI 통합을 위한 클러스터를 프로비저닝할 수도 있습니다.
간소화된 클러스터 유지보수: 워크로드 수요 변화에 따라 데이터베이스 노드를 추가하거나 삭제할 수 있는 네이티브 운영 기능을 통해 클러스터 공간을 간단하게 관리할 수 있습니다.

모니터링 가능성, AI, 확장 프로그램

Fleet를 모니터링하고 조정하려면 심층적인 가시성과 적절한 도구 모음이 필요합니다.

고급 로깅: 조정자는 데이터 및 제어 경로 로그를 로그 디스크로 전달하여 감사 가능성과 디버깅을 간소화합니다.
풍부한 모니터링 가능성: 커스텀 측정항목 지원을 통해 모니터링 생태계에 맞게 모니터링 가능성을 미세 조정할 수 있습니다. 커스텀 측정항목을 사용하면 분당 신규 사용자 등록 수, 특정 테넌트의 활성 세션 수, 처리된 주문량과 같은 비즈니스 수준 이벤트를 데이터베이스에서 직접 추적하고 이를 회사의 중앙 모니터링 가능성 플랫폼으로 내보낼 수 있습니다.
AI 및 확장 프로그램: AlloyDB Omni에서 지원되는 확장 프로그램 목록 외에도 조정자에는 자연어를 사용한 쿼리, AI 기반 검색, AI 함수 등 모든 AlloyDB Omni의 AI 기능에 대한 지원이 포함됩니다.

지금 시작하기

AlloyDB Omni Red Hat RPM 조정자는 베어메탈 또는 VM 플랫폼에서 PostgreSQL 호환 워크로드를 관리하는 새로운 방법을 제공하며, AlloyDB의 고성능, 생성형 AI 기능 및 Gemini 모델에 대한 액세스를 결합하여 AI 에이전트와 애플리케이션을 빌드하고 완전한 자동화를 실현합니다.

온프레미스 데이터베이스 작업을 한 단계 업그레이드할 준비가 되셨나요? AlloyDB 문서를 살펴보고 지금 바로 정식 버전을 사용해 보세요. 지금 신청하세요.

새로운 Codelab을 통해 RPM 조정자를 사용하여 가용성이 높은 AlloyDB Omni 클러스터를 배포해 볼 수도 있습니다.

DMS를 넘어: SQL Server 로그인 및 사용자를 Cloud SQL로 마이그레이션 가속화

Wed, 16 Sep 2026 22:00:00 +0000

이제 데이터베이스 현대화 여정을 위한 계획을 모두 마치셨습니다. Google Cloud의 Database Migration Service(DMS)를 설정하고, 복제를 구성하여, 온프레미스 또는 클라우드 시스템의 애플리케이션 데이터베이스를 완전 관리형 SQL Server용 Cloud SQL 인스턴스에 성공적으로 동기화했습니다.

복제가 완료되어 데이터가 최신 상태로 업데이트되었으며 컷오버할 준비가 되었습니다. 하지만 애플리케이션이 새로 마이그레이션된 데이터베이스에 연결을 시도하면 다음과 같은 메시지가 표시되면서 문제가 발생합니다.

Msg 18456, Level 14, State 1, Line 1: Login failed for user 'app_user.

원인은 간단합니다. SQL Server 로그인이 데이터베이스와 함께 마이그레이션되지 않았기 때문입니다. 이 게시물에서는 이러한 격차가 존재하는 이유, 이 격차가 실제로 조직의 보안 상황을 보호하는 이유, 오랜 시간 검증된 표준 SQL Server 도구를 사용하여 격차를 얼마나 쉽게 해소할 수 있는지 살펴보겠습니다.

DMS가 로그인을 마이그레이션하지 않는 이유: 보안 및 규정 준수

Database Migration Service(DMS)는 데이터베이스 수준 스키마와 트랜잭션 데이터를 복제하는 데 매우 효율적입니다. 그러나 시스템 master 데이터베이스나 서버 로그인, 권한과 같은 인스턴스 수준 객체는 의도적으로 마이그레이션하지 않습니다.

자칫 기능이 누락된 것처럼 보일 수 있지만, 사실 이는 세 가지 핵심 요소를 바탕으로 설계된 의도적인 디자인 옵션입니다.

보안 격리 및 권한 경계: 원본 환경과 대상 Cloud SQL 환경은 서로 다른 보안 패러다임에서 작동합니다. 마스터 시스템 데이터베이스를 직접 복제하면 승인되지 않은 권한 에스컬레이션이 발생할 수 있습니다. 예를 들어 sysadmin 권한이 있는 온프레미스 로그인은 완전 관리형 Google Cloud 데이터베이스에 대한 무제한 sysadmin 액세스 권한을 가져서는 안 됩니다. 클라우드 제공업체가 물리적 백업, 패치, 보안을 관리하는 경우 올바른 운영을 보장하기 위해 기본 운영체제에 대한 액세스를 제한해야 합니다.
규정 준수 및 감사 거버넌스: 명시적인 관리자 감독 없이 암호화된 비밀번호 해시와 서버 수준의 보안용 사용자 인증 정보를 자동으로 마이그레이션하면 PCI-DSS나 SOC 2와 같은 기업 규정 준수 프레임워크를 위반하는 경우가 많습니다. 보안 객체 마이그레이션을 관리자가 직접 수행하는 의도적인 단계로 유지함으로써 조직은 승인된 ID만 클라우드 시작 영역에 프로비저닝되도록 보장할 수 있습니다.
ID 현대화의 필요성: 클라우드 마이그레이션은 오래된 사용자 인증 정보를 업데이트하고 불필요한 계정을 정리할 수 있는 더할 나위 없이 좋은 기회입니다. 온프레미스 인스턴스에는 더 이상 사용되지 않는 legacy SQL 로그인이 포함되어 있는 경우가 많습니다. 이를 클라우드 관리형 서비스에 무작정 복제하는 것은 보안상 위험합니다. 또한 Cloud SQL로의 이전은 legacy SQL 인증에서 고객 관리형 Active Directory(CMAD)와 같은 최신 클라우드 네이티브 ID 솔루션으로 전환하는 촉매제 역할을 하는 경우가 많습니다.

로그인과 사용자의 차이 이해: SID 연결

로그인을 성공적으로 마이그레이션하기 위해 SQL Server가 보안을 관리하는 방법을 간단히 살펴보겠습니다. SQL Server는 ID를 두 개의 개별 계층으로 분리합니다.

로그인(서버 수준): master 데이터베이스에 저장됩니다. 로그인은 SQL Server 인스턴스에 대한 클라이언트 연결을 인증합니다.
사용자(데이터베이스 수준): 개별 사용자 데이터베이스 내에 저장됩니다. 사용자는 해당 특정 데이터베이스 내에서 연결을 통해 수행할 수 있는 작업을 승인합니다.

서버 로그인과 데이터베이스 사용자를 연결하는 것은 고유한 보안 식별자(SID)입니다.

데이터베이스를 백업하고 복원하거나 DMS를 사용하여 복제하면 데이터베이스 수준의 사용자(및 해당 SID)가 데이터베이스 파일 내에서 마이그레이션됩니다. 그러나 해당 서버 수준의 로그인이 대상 마스터 데이터베이스에 없거나, 존재하더라도 SID가 다른 경우 매핑이 중단됩니다. 이로 인해 데이터베이스 액세스 권한은 있지만 서버 수준에서 인증할 방법이 없는 '분리된 사용자'가 발생합니다.

그림 1: 해당 로그인이 없는 데이터베이스나 보안 식별자(SID)가 일치하지 않는 데이터베이스를 마이그레이션하면 대상 인스턴스에 고립된 사용자가 발생하는 방식

권장 솔루션: sp_help_revlogin을 사용하여 로그인 복제

모든 로그인을 수동으로 다시 만들고 비밀번호 해시를 추측하는 대신 Microsoft에서 제공하는 기존 스크립트인 sp_help_revlogin을 사용할 수 있습니다.

이 스크립트는 소스 인스턴스의 모든 SQL Server 인증 로그인에 대한 CREATE LOGIN 문이 포함된 T-SQL 쿼리를 생성하며, 원래의 암호화된 비밀번호 해시와 정확한 보안 식별자(SID)를 포함합니다.

1단계: 소스 인스턴스에 도우미 프로시저 만들기

SQL Server Management Studio(SSMS)를 사용하여 소스 SQL Server 인스턴스에 연결합니다. 공식 Microsoft 스크립트를 복사하고 실행하여 소스 master 데이터베이스에 필요한 두 가지 저장 프러시저인 sp_hexadecimal 및 sp_help_revlogin을 만듭니다.

2단계: 마이그레이션 스크립트 생성하기

프로시저가 생성되면 SSMS 쿼리 창에서 다음 문을 실행합니다. 출력을 깔끔하게 복사할 수 있도록 출력 설정을 Results to Text(Ctrl + T)로 전환했는지 확인합니다.

code_block: <ListValue: [StructValue([('code', 'EXEC master.dbo.sp_help_revlogin;'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad67235c10>)])]>

출력에는 다음과 유사한 자동 생성된 T-SQL 문이 포함됩니다.

code_block: <ListValue: [StructValue([('code', 'CREATE LOGIN [app_user] WITH PASSWORD = 0x01004F3D... HASHED, SID = 0x8D2F..., DEFAULT_DATABASE = [CustomerDB]'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad67166a50>)])]>

HASHED 비밀번호 옵션과 원래 SID를 사용하여 로그인을 스크립팅하면 SQL Server에서 원래 비밀번호와 보안 링크를 그대로 유지하면서 로그인을 안전하게 다시 만들 수 있습니다.

3단계: Cloud SQL에 스크립트 적용하기

생성된 스크립트를 복사하고 대상 SQL Server용 Cloud SQL 인스턴스에 연결한 후 쿼리를 실행합니다. 클라우드에 올바른 비밀번호로 로그인이 즉시 생성됩니다.

sp_help_revlogin을 통해 생성된 스크립트를 실행하면, 정확한 보안 식별자(SID)와 비밀번호 해시를 그대로 유지한 상태로 대상 Cloud SQL 인스턴스에 로그인을 복제할 수 있습니다. 아래와 같이 이 방법을 사용하면, 데이터베이스 마이그레이션 시 데이터베이스 수준 사용자가 서버 수준 로그인에 자동으로 매핑되므 '분리된 사용자' 문제를 완전히 방지할 수 있습니다.

그림 2: sp_help_revlogin 스크립트를 사용하여 비밀번호 해시와 원래 SID를 보존하고 SQL Server용 Cloud SQL에서 사용자 매핑을 해결하는 통합 마이그레이션 프로세스

참고: sp_help_revlogin은 Microsoft에서 만들고 유지관리하는 저장 프러시저입니다. 최신 버전을 다운로드하고 문서를 읽어보세요.

분리된 사용자 문제 해결

sp_help_revlogin을 실행하기 전에 대상 Cloud SQL 인스턴스에 수동으로 로그인을 만든 경우 SID가 일치하지 않아 사용자가 '분리'될 수 있습니다.

만약 분리된 사용자(예: app_user)가 발견되더라도, 단 한 줄의 명령어로 새로 생성된 서버 로그인에 간편하게 다시 매핑할 수 있습니다.

code_block: <ListValue: [StructValue([('code', 'ALTER USER [app_user] WITH LOGIN = [app_user];'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad75d70950>)])]>

이 명령어를 실행하면 데이터베이스 사용자와 서버 로그인이 SID를 통해 즉시 다시 연결되며, 애플리케이션 연결이 완벽하게 복원됩니다.

보안을 한층 더 강화

sp_help_revlogin을 사용하여 SQL 로그인을 마이그레이션하는 것이 리프트 앤 시프트 마이그레이션의 가장 쉬운 방법이지만, 클라우드 마이그레이션을 활용하여 인증을 현대화하는 것을 고려해 보세요. SQL Server용 Cloud SQL은 고객 관리형 Active Directory(CMAD)와의 강력한 통합을 지원합니다. 대상 인스턴스를 Active Directory와 통합하면 legacy SQL 로그인을 지원 중단하고 중앙 집중식 엔터프라이즈급 Kerberos 인증을 사용할 수 있습니다.

마무리

데이터베이스 마이그레이션은 단순히 데이터 행을 옮기는 것이 아닙니다. 애플리케이션이 첫날부터 안전하고 규정을 준수하며 운영 가능한 상태를 유지하도록 보장하는 작업입니다. Google Cloud의 DMS가 데이터 복제라는 까다로운 작업을 대신 처리해 주지만, 로그인 마이그레이션 또한 단 3단계의 간단한 과정만으로 원활한 컷오버를 확실히 보장할 수 있습니다.

마이그레이션 전략을 최적화하는 방법에 대해 더 자세히 알아보려면 SQL Server용 Cloud SQL 마이그레이션 가이드를 확인해 보세요. 또한 Database Migration Service를 활용해 Google Cloud로의 이전 과정을 얼마나 간소화할 수 있는지 직접 살펴보시기 바랍니다.

Spanner: DML 트랜잭션의 누적 변형 한도 삭제

Tue, 15 Sep 2026 18:00:00 +0000

Spanner는 Google Cloud의 타협 없는 운영 데이터베이스로, 최신 분산 시스템에 필요한 수평적 확장성과 상시 가용성에 더해 관계형 데이터베이스의 풍부한 기능 모음과 익숙한 생태계를 제공합니다. 오늘날 은행, 소매, 미디어 및 엔터테인먼트, AI 인프라 등 다양한 산업의 혁신 기업이 가장 중요한 워크로드를 Spanner에서 실행하고 있습니다. 이번에 Spanner에서 더 크고 복잡한 트랜잭션을 보다 유연하게 처리할 수 있는 새로운 방법을 발표하게 되어 기쁩니다. 이를 통해 최고 수준의 데이터 일관성이 필요한 애플리케이션을 더욱 간편하게 구축할 수 있습니다.

운영 워크로드에서는 일반적으로 실시간 의사 결정과 세밀한 데이터 업데이트가 함께 이루어집니다. 예를 들어 전자상거래 앱의 여러 단계로 구성된 결제 과정에서 사기를 탐지하는 경우를 생각해 볼 수 있습니다. 이러한 변경 작업은 트랜잭션으로 처리되어야 합니다. 즉, 모든 작업이 성공하거나 모두 실패해야 하며, 이후의 요청에서는 항상 올바른 데이터가 조회되어야 합니다. 이번 Spanner의 ACID 트랜잭션 업데이트를 통해 애플리케이션은 익숙한 DML을 사용하면서 일관성, 확장성 또는 가용성을 저해하지 않고 한 번의 업데이트에서 더 많은 데이터를 처리할 수 있습니다.

더 높은 한도, 더 많은 유연성

이전에는 Spanner에서 DML 등을 사용해 하나의 트랜잭션에서 쿼리가 수행할 수 있는 변경 작업의 수를 80,000개로 제한했습니다. 이 값은 대략 업데이트되는 행 수와 열 수를 곱한 값에 종속 색인에서 발생하는 변경 작업을 더해 계산되었습니다. 애플리케이션은 시간이 지남에 따라 더 많은 데이터를 처리하고 새로운 기능을 제공하도록 발전합니다. 이에 따라 트랜잭션의 크기도 커지면서, 이전에는 한도에 여유가 있던 작은 트랜잭션도 이 한도에 도달할 수 있습니다.

이번 업데이트에서는 트랜잭션에 적용되던 80,000개의 mutation mod 한도를 개별 DML 문에 적용하도록 변경합니다. 이제 DML 문은 전체 트랜잭션에 적용되는 변형 한도에 더 이상 포함되지 않습니다. 따라서 하나의 트랜잭션에 INSERT, UPDATE, DELETE와 같은 DML 문을 개수에 제한 없이 포함할 수 있습니다. 단, 각 개별 문에서 생성되는 mutation mod 수는 80,000개 미만이어야 합니다.

주요 이점

더 큰 트랜잭션: 누적 변형 한도를 준수하기 위해 인위적으로 트랜잭션을 분할하는 대신, 비즈니스 요구사항에 따라 DML 문을 논리적으로 그룹화할 수 있습니다.
원활한 전환: 이번 변경사항은 기존의 모든 Spanner 클라이언트 라이브러리와 호환되므로 애플리케이션 코드를 업데이트할 필요가 없습니다.

기술적 고려사항

잠금 및 중단

이제 하나의 트랜잭션에 더 많은 DML 문을 포함할 수 있지만, 트랜잭션이 크고 실행 시간이 길어질수록 잠금이 더 오래 유지된다는 점에 유의해야 합니다. 이로 인해 잠금 경합 및 트랜잭션 중단이 발생할 가능성이 높아질 수 있습니다. 트랜잭션을 간결하게 유지하면 높은 성능을 유지하고 리소스 경합을 최소화하는 데 도움이 됩니다.

DML과 Mutation API 비교

한도 적용 방식은 데이터를 수정하는 데 사용하는 방법에 따라 다릅니다.

DML 문: 각 문(예: executeUpdate)은 80,000개 mod 한도를 기준으로 개별적으로 평가됩니다.
변형 API: insert() 또는 update()와 같은 클라이언트 라이브러리 메서드를 사용하는 경우 커밋 호출 시 변경사항이 제공됩니다. 80,000개 한도는 해당 호출에 포함된 전체 변형 집합에 계속 적용됩니다.

mutation mod 이해하기

Spanner는 수정되는 셀, 기본 키, 보조 색인 업데이트 등 변경 작업의 복잡성을 기준으로 mod 수를 계산합니다. 변경사항이 계산되는 방식에 대한 자세한 내용은 이 블로그를 참고하세요. CommitStats의 mutation_count를 통해 커밋된 트랜잭션에서 발생한 총 mod 수를 모니터링할 수 있습니다. mutation_count에는 모든 DML 문과 커밋 호출을 통해 해당 트랜잭션에 포함된 모든 변경사항이 집계됩니다.

Java 구현 예시

다음 예시에서는 새로운 한도 적용 방식에 따라 하나의 트랜잭션에서 여러 DML 문을 실행하는 방법을 보여줍니다.

code_block: <ListValue: [StructValue([('code', 'import com.google.cloud.spanner.DatabaseClient;\r\nimport com.google.cloud.spanner.Statement;\r\nimport com.google.cloud.spanner.TransactionContext;\r\nimport com.google.cloud.spanner.TransactionRunner.Work;\r\n\r\n// Assuming dbClient is your initialized DatabaseClient\r\ndbClient\r\n .readWriteTransaction()\r\n .run(\r\n new Work<Void>() {\r\n @Override\r\n public Void doWork(TransactionContext transaction) throws Exception {\r\n // Each executeUpdate call is evaluated separately against the 80k mod limit.\r\n\r\n // Example 1: Updating specific products\r\n Statement stmt1 = Statement.newBuilder(\r\n "UPDATE Products SET InStock = FALSE WHERE ProductId = @productId")\r\n .bind("productId").to(1L)\r\n .build();\r\n transaction.executeUpdate(stmt1); // Verified against 80k limit\r\n\r\n Statement stmt2 = Statement.newBuilder(\r\n "UPDATE Products SET InStock = FALSE WHERE ProductId = @productId")\r\n .bind("productId").to(2L)\r\n .build();\r\n transaction.executeUpdate(stmt2); // Verified against 80k limit separately\r\n\r\n // Example 2: Inserting related order data\r\n Statement stmt3 = Statement.newBuilder(\r\n "INSERT INTO OrderItems (OrderId, ItemId, Quantity) VALUES (@orderId, @itemId, @qty)")\r\n .bind("orderId").to(100L)\r\n .bind("itemId").to(1L)\r\n .bind("qty").to(2)\r\n .build();\r\n transaction.executeUpdate(stmt3); \r\n\r\n Statement stmt4 = Statement.newBuilder(\r\n "UPDATE Orders SET LastUpdated = PENDING_COMMIT_TIMESTAMP() WHERE OrderId = @orderId")\r\n .bind("orderId").to(100L)\r\n .build();\r\n transaction.executeUpdate(stmt4); \r\n\r\n return null;\r\n }\r\n });'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fad75dc7c90>)])]>

변경되지 않은 사항

개별 문 한도: 하나의 DML 문에서 자체적으로 80,000개를 초과하는 mod가 생성되는 경우에는 현재와 동일한 오류가 반환됩니다.
기타 트랜잭션 한도: 바이트 단위의 최대 트랜잭션 크기와 같은 다른 제약 조건은 계속 적용됩니다. 자세한 내용은 여기를 참조하세요.

권장사항

CommitStats 모니터링: CommitStats에서 반환된 mutation_count를 활용하여 작업에서 발생하는 부하를 파악합니다.
대규모 작업 최적화: 하나의 문(예: 일괄 업데이트)이 한도를 초과하는 경우 Partitioned DML을 사용하거나 키를 기준으로 페이지를 나누는 것이 좋습니다.

Spanner는 다운타임 없이 확장해야 하는 운영 애플리케이션을 위한 신뢰할 수 있는 선택지입니다. 이러한 변형 한도 확대로 개발자는 Spanner의 전역 일관성을 활용하는 더 큰 트랜잭션을 실행할 수 있는 유연성을 확보할 수 있게 되었습니다. Spanner가 팀의 빠른 혁신을 지원하면서 위험을 줄이는 데 어떻게 도움이 되는지 알아보거나, 무료 체험판 또는 월 $54부터 시작하는 프로덕션 인스턴스로 직접 사용해 보세요.

외부 참조

AlloyDB ScaNN이 벡터 검색을 100억 개의 벡터로 확장하는 방법

Thu, 03 Sep 2026 21:00:00 +0000

엔터프라이즈급 에이전트 AI 애플리케이션의 요구사항을 충족하기 위해 기본 벡터 데이터베이스는 최신 사용 사례가 수십억 개의 벡터로 확장될 수 있으므로 효과적으로 확장하는 데 어려움을 겪는 경우가 많습니다.

완전 관리형 PostgreSQL 호환 데이터베이스 서비스인 AlloyDB는 까다로운 엔터프라이즈 워크로드를 처리하도록 설계되었습니다. Google의 인프라와 상용 데이터베이스의 안정성을 결합하여 높은 가용성과 확장성을 제공하며, 에이전트 AI 사용 사례에 최적화된 최첨단 분석 엔진을 포함합니다. 이러한 성능의 핵심은 ScaNN 색인으로, 이제 100억 개의 벡터 규모에서도 효율적으로 작동합니다. 이는 혁신적인 4단계 트리 (프리뷰)와 효율적인 메모리 사용량을 결합한 주요 아키텍처 개선을 통해 달성되었습니다.

100억 벡터 규모의 과제

100억 개의 벡터 워크로드로 확장하려면 상당한 메모리와 컴퓨팅 문제가 발생합니다. 이전 AlloyDB ScaNN 트리 기반 색인은 2단계 또는 3단계 트리 구성으로 제한되었으며, 이러한 구조를 확장하려고 하면 다음과 같은 여러 병목 현상이 발생했습니다.

컴퓨팅 집약도 증가: 더 큰 트리 구조는 색인 구성과 쿼리 순회 모두에 훨씬 더 많은 연산을 요구합니다.
메모리 제약: 100억 개의 벡터에 필요한 샘플링 프로세스가 시스템의 사용 가능한 메모리 용량을 쉽게 초과할 수 있습니다.

솔루션: 4단계 아키텍처

최근 AlloyDB ScaNN 출시의 주요 혁신은 4단계 트리 (프리뷰)의 도입입니다. 그림 1에 나와 있는 이 아키텍처는 하향식 전략을 사용하여 정확성과 빌드 효율성 간의 균형을 최적화합니다. 높은 성능을 유지하고 재현율 손실을 완화하기 위해 시스템은 Top-K 브랜치, SOAR, 중심점 조정, 균형 잡힌 트리 모양과 같은 주요 개선사항을 통합합니다.

그림 1. AlloyDB ScaNN 4단계 트리 아키텍처

이 설계에는 두 가지 주요 이점이 있습니다.

1. 계층적 파티셔닝을 통한 컴퓨팅 집약도 감소

4단계 아키텍처는 계층적 파티셔닝을 사용하여 쿼리 중에 스캔되는 벡터의 양을 제한함으로써 컴퓨팅 집약도를 크게 줄입니다. 평면적이거나 제대로 분할되지 않은 공간을 탐색하는 대신, 다층적 계층 구조는 검색 경로를 기하급수적으로 좁힙니다. 그림 2는 다양한 트리 수준에서 검색 공간을 보여주며 구조적 계층화가 순회 효율성을 어떻게 최적화하는지 보여줍니다.

그림 2. 2단계, 3단계, 4단계 트리의 검색 공간

2단계: 대략적인 파티셔닝을 활용하여 쿼리를 안내하므로 기본 검색 복잡도는 O(N1/2)입니다.
3단계: 중간 레이어를 도입하여 클러스터를 더 세분화하고 탐색 범위를 O(N1/3)으로 좁힙니다.
4단계: 순회 효율성을 O(N1/4)까지 최적화하는 세분화된 파티션을 구현하여 100억 개 이상의 벡터를 충분히 허용합니다.

AlloyDB ScaNN은 데이터 세트가 확장됨에 따라 계층적 레이어를 동적으로 확장하여 쿼리 지연 시간을 매우 낮게 유지하고 계산 규모의 벽이 성능에 영향을 미치지 않도록 방지합니다.

2. 효율적인 메모리 사용

100억 개의 벡터 규모를 달성하려면 높은 메모리 효율성이 필요합니다. AlloyDB ScaNN은 이러한 전략을 사용하여 메모리 관리 성능을 극대화합니다.

균형 잡힌 트리 모양 구성: 4단계 트리는 균형 잡힌 구성을 활용하여 학습 데이터 세트의 크기를 제한하는 메모리 제한을 우회합니다. 이 균형 잡힌 아키텍처는 축소된 샘플링 크기를 효과적으로 활용하여 충실도가 높은 트리 파티션을 구성합니다.
샘플링 최적화: 시스템이 메모리 제한에 직면하면 성능과 정확성을 고려한 압축된 샘플링 세트를 생성합니다.

성능 테스트 결과

내부 테스트에서 혁신적인 4단계 트리 아키텍처를 활용하여 다음과 같은 성능 결과를 달성할 수 있습니다.

AlloyDB는 ScaNN 색인을 사용하여 100억 개 이상의 벡터로 확장할 수 있습니다.
AlloyDB는 ScaNN 색인을 사용하여 100억 개의 벡터에서 51ms p95 지연 시간 이하와 95% 재현율을 제공할 수 있습니다.

지금 시작하기

지금 바로 AlloyDB ScaNN의 4단계 트리 (프리뷰) 아키텍처를 경험해 보세요. 빠른 시작 가이드에 따라 인스턴스를 설정하여 AlloyDB용 ScaNN을 배포할 수 있습니다. 최적화된 고속 벡터 검색은 공식 ScaNN 문서를 참조하세요. 신규 사용자는 30일 무료 체험 프로그램을 통해 AlloyDB를 살펴볼 수도 있습니다. 여러분이 빌드할 멋진 결과물을 기대하겠습니다.

에이전틱 데이터 클라우드의 새로운 소식: 실행 시스템 구축

Tue, 28 Apr 2026 01:00:00 +0000

* 본 아티클의 원문은 2026년 4월 23일 Google Cloud 블로그(영문)에 게재되었습니다.

기업들은 단순히 질문에 답하는 생성형 AI를 넘어, 기업을 대신해 인지하고 추론하며 행동하는 자율형 에이전트로 전환하고 있습니다. 이러한 에이전트를 기존의 레거시 스택에서 확장하려고 시도하면 거버넌스 파편화, 지속적인 신뢰 격차, 추론 루프의 단절과 같은 구조적 실패에 노출될 뿐만 아니라 비용 폭증을 초래할 수 있습니다.

이를 해결하기 위해 우리는 에이전틱 데이터 클라우드(Agentic Data Cloud)를 소개합니다. 이는 기업의 데이터 플랫폼을 정적인 저장소에서 동적인 추론 엔진으로 진화시킨 AI 네이티브 아키텍처입니다. 이 시스템은 '생각'과 '실행' 사이의 간극을 좁혀, AI 에이전트가 비즈니스 데이터와 맥락을 바탕으로 직접 행동할 수 있게 합니다. 지난 세대의 지능형 시스템(Systems of Intelligence)이 인간의 규모에 맞춰 설계되었다면, 에이전틱 데이터 클라우드는 에이전트의 규모에 맞춰 구축된 실행 시스템(System of Action)입니다.

선도적인 기업들은 이미 에이전틱 데이터 클라우드를 사용하여 가시적인 가치를 창출하고 있습니다.

Vodafone: 고객에게 중단 없는 서비스를 제공하기 위해 수백 개의 에이전트를 출시했으며, 이를 통해 매년 수백만 유로를 절감할 것으로 기대하고 있습니다.
American Express: 핵심 온프레미스 데이터 웨어하우스와 수백 개의 프로덕션 애플리케이션을 BigQuery로 이전하여, 신뢰할 수 있는 대규모 에이전틱 커머스를 구현하고 있습니다.
Virgin Voyages: 1,000개 이상의 전문 AI 에이전트를 사용하고 있으며, 그중 하나는 대규모 여정 재예약 시간을 6시간에서 단 11분으로 단축했습니다.

오늘 우리는 에이전틱 데이터 클라우드를 뒷받침하는 세 가지 새로운 혁신 분야를 발표합니다.

에이전트에게 신뢰할 수 있는 비즈니스 맥락을 제공하여 정확도를 높이는 유니버설 컨텍스트 엔진(Universal Context Engine).
데이터 전문가와 개발자의 역할을 에이전트 오케스트레이터로 진화시키는 에이전틱 우선의 실무자 경험(Agentic-first practitioner experiences).
전체 데이터 자산을 연결하여 데이터 사일로를 제거하는 AI 네이티브 멀티 클라우드 레이크하우스(Cross-cloud lakehouse).

유니버설 컨텍스트 엔진으로 에이전트 역량 강화

AI의 지능은 그 기반이 되는 '맥락(Context)'에 달려 있습니다. 만약 에이전트가 여러분이 정의한 '마진(Margin)'의 의미나 공급망의 복잡한 관계를 이해하지 못한다면 추측에 의존할 수밖에 없습니다. 에이전틱 엔터프라이즈 시대에는 데이터만으로는 부족하며, 과거의 거버넌스 모델 역시 불충분합니다. 이것이 우리가 Dataplex Universal Catalog를 Knowledge Catalog로 진화시킨 이유입니다. 이 카탈로그는 집계, 지속적인 강화, 검색이라는 엄격한 프레임워크를 사용하여 전체 데이터 자산에 걸쳐 비즈니스적 의미를 매핑하고 추론합니다.

동작 방식은 다음과 같습니다.

집계(Aggregation): 진정한 맥락을 구축하려면 모든 곳에서 데이터를 모아야 합니다. 우리는 Google Cloud와 파트너 데이터 플랫폼 전반에서 네이티브 맥락을 집계하고 있습니다. 여기에는 Palantir, Salesforce Data360, SAP, ServiceNow, Workday(프리뷰)와 같은 서드파티 카탈로그, 애플리케이션, 운영 체제 및 AI 플랫폼이 포함됩니다. 레이크하우스를 사용하면 서드파티 데이터 자산이 Knowledge Catalog에 자동으로 매핑됩니다. Google Cloud 소스의 경우, 전략 문서에서 시맨틱을 자율적으로 생성하는 새로운 LookML Agent(프리뷰)와 플랫폼에 비즈니스 로직을 네이티브하게 내장하는 BigQuery measures(프리뷰)를 통해 비즈니스 로직을 자동화하고 있습니다.
지속적인 강화(Continuous enrichment): Knowledge Catalog는 조직 전반의 사용 로그를 분석하고 백그라운드에서 데이터를 프로파일링하여 지속적인 강화를 수행합니다. 이는 데이터가 무엇인지뿐만 아니라, 기업이 데이터를 실제로 어떻게 사용하는지 학습합니다. 이는 비정형 데이터까지 확장됩니다. 파일이 Google Cloud Storage에 저장되는 즉시, Smart Storage(프리뷰)가 이미지와 PDF 객체(예정)를 즉시 태깅하고 강화합니다. 또한 유용한 비정형 데이터 컬렉션을 식별하고 Gemini를 사용하여 누락된 스키마를 자동으로 생성하며 복잡한 관계를 매핑하므로 AI가 더 이상 '맹목적으로' 작동하지 않게 됩니다.
검색 및 검색(Search and retrieval): 방대한 맥락 레이어를 만드는 것도 중요하지만, 에이전틱 시대에 검색은 새로운 쿼리 경로로 진화했습니다. 엔터프라이즈 규모에서 가장 어려운 문제는 속도, 관련성, 글로벌 도달 범위 및 보안입니다. 이를 해결하기 위해 Knowledge Catalog는 Google 검색의 혁신을 바탕으로 구축된 정교한 하이브리드 검색 스택을 사용합니다. 관련성을 높이기 위해 시맨틱 및 렉시컬 매칭을 지능형 머신러닝 기반 재순위화(re-ranking)와 결합합니다. 신뢰를 보장하기 위해 액세스 제어 인식 검색을 통해 보안 권한을 네이티브하게 적용하므로, 에이전트는 승인된 자산에만 액세스하고 조치를 취할 수 있습니다.

Knowledge Catalog는 현재 Deep Research Agent(프리뷰)를 구동하고 있습니다. Gemini Enterprise에서 제공되는 이 에이전트는 BigQuery와 같은 데이터 플랫폼은 물론 내부 문서와 웹 자산 전반에서 다단계 추론을 수행하여, 과거에 수주간의 수동 작업이 필요했던 복잡한 질문에 대해 인용구와 정밀도를 갖춘 답변을 제공합니다.

에이전틱 우선의 실무자 경험

새로운 아키텍처로 이동함에 따라 데이터 실무자의 역할은 수동으로 파이프라인을 작성하는 것에서 의도 중심의 엔지니어링을 조율하는 것으로 바뀝니다.

우리는 Google Cloud Data Agent Kit(프리뷰)를 통해 이러한 전환을 가속화하고 있습니다. 새로운 인터페이스를 도입하는 대신, 개발자들이 선호하는 환경(VS Code, Gemini CLI, Codex, Claude Code 등)에 바로 적용할 수 있는 도구, 확장 프로그램 및 플러그인 세트를 출시합니다. 이를 통해 IDE나 터미널을 네이티브 데이터 환경으로 변환하여, 시스템이 자율적으로 프레임워크(dbt, Apache Spark, Apache Airflow 등)를 선택하고 Google의 표준에 맞춘 프로덕션용 코드를 생성하도록 합니다.

이 키트는 단순히 도구를 연결하는 데 그치지 않고, 데이터를 이동시키지 않고도 페타바이트 규모까지 확장 가능한 고성능 기능을 개발자의 흐름에 직접 주입합니다. Data Agent Kit에는 다음과 같은 Google의 기본 에이전트들을 구동하는 것과 동일한 도구들이 포함되어 있습니다.

Data Engineering Agent (정식 출시): 처음부터 복잡한 파이프라인 변환을 구축하고 거버넌스 규칙을 적용하여 잘못된 데이터가 프로덕션에 유입되는 것을 방지합니다.
Data Science Agent (정식 출시): 데이터 랭글링부터 학습까지 모델 라이프사이클을 자동화하며, BigQuery Dataframes 및 서버리스 Apache Spark 전반으로 확장합니다.
Database Observability Agent (프리뷰): 인프라의 24/7 파수꾼 역할을 하며 근본 원인을 진단하고 데이터베이스 복구 조치를 실행합니다.

또한 에이전트의 원활한 실행을 돕기 위해 Google Cloud는 Model Context Protocol(MCP)을 전면 수용했습니다. 이는 에이전트가 BigQuery, Spanner(프리뷰), AlloyDB, Cloud SQL(정식 출시), Looker(프리뷰) 등 핵심 엔진 전반에서 데이터 자산을 검색하고 사용할 수 있게 해주는 보안 유니버설 인터페이스를 제공합니다.

비즈니스 사용자를 위한 경험도 재구상했습니다. 이제 BigQuery, Cloud SQL, Spanner, AlloyDB(프리뷰), Looker(정식 출시) 전반에서 Conversational Analytics(대화형 분석)가 지원됩니다. 조직은 이러한 맞춤형 분석 에이전트를 Gemini Enterprise에 게시하여, 직원들이 익숙한 인터페이스에서 실시간 데이터와 대화할 수 있게 함으로써 수동 보고서를 기다리는 시간을 없앨 수 있습니다.

에이전틱 규모를 위해 구축된 멀티 클라우드 토대

에이전트가 행동하기 위해서는 근본적으로 개방된 토대가 필요합니다. 만약 에이전트가 클라우드 간 지연 시간에 가로막히거나 특정 업체의 폐쇄적인 환경에 갇혀 있다면 자율성은 무너집니다. 이에 우리는 다음과 같은 기능을 통해 진정한 경계 없는 멀티 클라우드 레이크하우스(Cross-cloud Lakehouse)를 선보입니다.

분석 자산 연결: Cross-Cloud Interconnect(CCI)를 데이터 플레인에 직접 통합합니다. CCI의 전용 고속 프라이빗 네트워킹과 Apache Iceberg REST Catalog를 결합하여 지연 시간을 낮추고 막대한 이그레스(Egress) 비용을 제거합니다. 결과적으로 에이전트는 AWS와 Azure에 있는 데이터를 마치 Google Cloud에 있는 것처럼 원활하게 사용할 수 있습니다.
독점적 사일로 종식: 양방향 페더레이션(Bi-directional federation, 프리뷰)을 출시하여 독점 카탈로그 시대를 끝내고자 합니다. 엔진은 이제 Amazon S3의 Databricks Unity Catalog(프리뷰), Snowflake Polaris(프리뷰), Amazon S3의 AWS Glue Data Catalog(프리뷰)에서 직접 데이터를 읽을 수 있습니다. 이는 강화된 Lakehouse Governance(프리뷰)를 통해 보안 정책이 멀티 클라우드 환경 전반에 즉시 적용되도록 뒷받침됩니다.
운영 데이터의 해방: 세계에서 가장 확장성이 뛰어나고 글로벌 일관성을 갖춘 데이터베이스인 Spanner Omni(프리뷰)를 발표합니다. 이제 처음으로 클라우드, 온프레미스, 혹은 노트북 등 어디에서나 Google을 구동하는 것과 동일한 역량으로 Spanner 엔진을 실행할 수 있습니다.
인사이트와 실행 사이의 간극 해소: 대부분의 '통합' 데이터 플랫폼은 복잡한 ETL 파이프라인 구축을 강요하여 에이전트의 실시간 데이터 접근을 가로막습니다. AlloyDB용 레이크하우스 제휴(프리뷰)을 통해 프로토콜 수준의 제로-ETL 동기화를 제공함으로써, 에이전트가 운영 트랜잭션 내에서 낮은 지연 시간으로 깊이 있는 분석 이력에 접근할 수 있게 합니다.

미래를 자동화하다

에이전트 규모로 이동하면 워크로드가 수천 배 더 많아집니다. 이를 지원하기 위한 네 가지 주요 성능 혁신을 발표합니다.

Apache Spark용 Lightning Engine: 독점적인 시장 대안 대비 최대 2배의 가성비를 제공합니다.
Managed Lustre: 까다로운 모델에 데이터를 충분히 빠르게 공급할 수 있도록 최대 10TB/s의 처리량을 제공합니다.
Bigtable 인메모리 티어: 실시간 애플리케이션을 위해 1밀리초 미만의 읽기 지연 시간을 제공합니다. 이제 별도의 캐싱 레이어를 둘 필요가 없습니다.
BigQuery 유동적 확장(Fluid scaling): 오토스케일링 워크로드의 비용을 평균 최대 34% 절감하며, 에이전트가 행동할 때 리소스를 즉시 늘리고 사용하지 않을 때 줄여줍니다.

실행 시스템(System of Action) 위에서 성공을 구축하세요

수동적인 관찰의 시대는 끝났습니다. 미래는 Google의 에이전틱 데이터 클라우드가 가능케 하는 실행 시스템(System of Action)의 것입니다.

에이전틱 데이터 클라우드가 여러분의 비즈니스를 위해 무엇을 할 수 있는지 확인해 볼 준비가 되셨습니까? 실행 시스템을 통해 자율형 에이전트에게 데이터를 공급할 준비를 하는 방법에 대한 전략 워크숍을 지금 신청하세요.

에이전틱 데이터 클라우드에 대해 더 자세히 알고 싶으신가요? 수동적인 데이터를 능동적인 실행으로 전환하기 위한 당사의 청사진을 확인해 보시기 바랍니다.