Iceberg에서 인텔리전스로: Snowflake와 Google Cloud로 구현하는 AI 활용에 최적화된 경계 없는 레이크하우스

Iceberg: 사일로에서 벗어나 상호운용성으로

과거에는 모든 데이터베이스가 자체 데이터를 독점적으로 관리했습니다. 조직이 하나의 분석 엔진만 사용하던 시절에는 이러한 방식으로도 전혀 문제가 없었습니다. 그러나 오늘날의 데이터 팀은 작업의 특성에 따라 Apache Spark™, BigQuery, Gemini Enterprise Agent Platform, Snowflake(CoCo 및 CoWork 포함) 등 다양한 서비스를 조합해 사용하며, 같은 파이프라인 안에서 이러한 조합이 이뤄지는 경우도 많습니다.

그 결과 기업은 유연성과 일관성 중 하나를 선택해야 하는 양자택일의 딜레마에 직면하게 되었습니다.

• 각 팀이 원하는 엔진을 자유롭게 사용하도록 하고 데이터를 여러 시스템에 복제하면 중복 데이터, 불일치, 보안 및 운영 리스크가 발생합니다.
• 반대로 모두가 하나의 엔진만 사용하도록 강제하면 멀티 엔진 아키텍처가 제공하는 전문성과 자율성을 포기해야 합니다.

업계에는 이 두 가지를 넘어서는 제3의 선택지가 필요했고, 그 해답은 데이터 지역성(Data Locality) 원칙이라는 근본적인 인사이트에서 출발했습니다. 대량의 데이터를 네트워크를 통해 이동시키는 것보다, 실행 가능한 작은 코드 조각을 데이터가 있는 곳으로 보내는 편이 더 빠르고 비용 효율적이며 안전하다는 것입니다.

이러한 관점은 하나의 아키텍처 패턴으로 수렴합니다. 데이터를 각 엔진으로 복사하는 대신, 각 엔진의 컴퓨팅을 데이터가 있는 곳으로 가져오는 방식입니다. 모든 데이터는 고객 소유의 스토리지 버킷에 남아 있고, 모든 엔진은 데이터의 물리적 배치 방식에 대해 동일한 규칙을 따르므로 하나의 테이블을 직접 읽고 쓸 수 있습니다.

이를 구현하려면 모든 엔진이 공통으로 이해할 수 있는 공통 언어, 즉 합의된 개방형 테이블 형식이 필요합니다.

업계는 그 공통 언어로 Apache Iceberg™를 선택했습니다. Iceberg는 페타바이트 규모의 테이블 관리를 위해 Netflix에서 개발된 뒤 Apache Software Foundation에 기증되었으며, 현재 Spark, Trino, Flink, BigQuery, Snowflake를 비롯한 수십 개의 데이터 처리 엔진에서 지원됩니다. Iceberg라는 공통 언어를 사용하면 모든 엔진은 독점적인 어댑터 없이도 동일한 데이터를 읽고 쓰며 상호운용할 수 있습니다.

카탈로그: Iceberg에서 레이크하우스로

개방형 형식은 상호운용성 문제를 상당 부분 해결하지만, 새로운 문제를 제기합니다. 바로 ‘누가 책임지고 관리할 것인가?’에 대한 문제입니다. 여러 엔진이 동일한 파일을 읽고 쓸 수 있다면, 누군가는 테이블 메타데이터를 관리하고 액세스 정책을 적용하며 동시에 수행되는 쓰기 작업을 조율하고 어떤 엔진도 오래되거나 일관성이 깨진 데이터를 보지 않도록 보장해야 합니다. 이 역할을 담당하는 것이 카탈로그이며, 카탈로그는 레이크하우스의 거버넌스 계층 역할을 수행합니다. 카탈로그는 어떤 테이블이 존재하는지, 각 테이블의 스키마는 무엇인지, 누가 접근할 수 있는지, 그리고 데이터 파일이 실제로 어디에 저장되어 있는지를 관리하는 유일한 관리 주체(single source of authority)입니다. 카탈로그가 없는 개방형 데이터는 결국 관리되지 않는 데이터(ungoverned data)에 불과합니다.

카탈로그는 벤디드 자격 증명(vended credentials)을 통해 스토리지 액세스를 제어합니다. 엔진이 테이블 데이터에 접근을 요청하면 카탈로그는 장기간 사용할 수 있는 스토리지 버킷 자격 증명을 제공하는 대신 짧은 기간 동안만 유효하고 필요한 권한만 부여된 스토리지 토큰을 발급합니다. 따라서 엔진은 기반 스토리지 계층에 대한 지속적인 액세스 권한을 얻지 못합니다.

서로 다른 공급업체가 만든 엔진 전반에서 이 모델이 작동하려면 카탈로그 간 표준화된 통합 프로토콜이 필요합니다. 표준 프로토콜이 없으면 모든 엔진은 모든 카탈로그와 각각 별도의 맞춤형 통합을 구현해야 합니다. 이 문제를 해결하는 오픈 API 사양이 바로 Iceberg REST Catalog(IRC)입니다. IRC는 클라이언트가 네임스페이스를 검색하고, 테이블 메타데이터를 로드하고, 업데이트를 커밋하는 방식을 정의합니다. 모든 카탈로그는 IRC 엔드포인트를 제공하고, 모든 엔진은 이를 클라이언트로 연결해 사용합니다.

벤디드 자격 증명과 표준 프로토콜의 조합은 엔진이 카탈로그 경계를 넘나들 수 있게 하며, 업계에서는 이를 페더레이션이라고 부릅니다. 예를 들어, Snowflake 쿼리가 Google Cloud의 Lakehouse 카탈로그에 접근하거나 BigQuery 작업이 Snowflake Horizon의 데이터를 읽는 경우에도 각 카탈로그는 요청한 엔진에 실제 필요한 최소 권한만 가진 단기 토큰만 발급합니다. 따라서 요청을 시작한 엔진과 관계없이 거버넌스가 적용됩니다. 진정한 상호운용성을 구현하려면 이러한 기능은 양방향으로 제공되어야 합니다. 즉, 카탈로그 외부의 엔진이 해당 Iceberg 테이블을 읽고 쓸 수 있는 인바운드 페더레이션과, 자체 컴퓨팅이 다른 카탈로그의 관리형 Iceberg 테이블을 읽고 쓸 수 있는 아웃바운드 페더레이션이 필요합니다.

카탈로그와 벤디드 자격 증명은 함께 단일 거버넌스 계층을 구성하여 보안을 적용하고, 액세스를 제어하며, 감사를 중앙에서 관리합니다. 이를 통해 고객은 카탈로그 전반에서 Iceberg 테이블에 양방향으로 액세스할 수 있으며, Iceberg 호환 엔진 간에도 제로 카피 아키텍처를 구현할 수 있습니다.

따라서 핵심 아키텍처 질문은 다음으로 좁혀집니다. 카탈로그는 누가 관리할 것인가? 고객은 DIY 방식의 자체 관리형 카탈로그를 배포할 수도 있지만, 대부분은 관리형 Iceberg REST Catalog를 선택하게 됩니다.

직접 구축을 원하는 기업이라면 Apache Polaris™를 배포할 수 있습니다. Apache Polaris는 Snowflake와 Dremio가 공동으로 개발한 후 Apache Software Foundation에 기증한 대표적인 오픈소스 IRC 구현체입니다. 이 방식은 조직에 완전한 통제권을 제공하지만, 인프라 운영, 규모 조정, 패치 적용, 가용성 확보 등 모든 운영 책임 역시 직접 부담해야 합니다. 또한 관리형 솔루션과 달리 DIY 카탈로그는 서버리스가 아니므로 사용하지 않을 때도 자동으로 리소스를 0으로 축소할 수 없어 지속적인 운영 비용을 발생시킵니다.

실제로는 대부분의 조직이 카탈로그 운영보다 데이터에 집중하기 위해 관리형 IRC를 선택합니다. Snowflake와 Google Cloud를 함께 사용하는 환경에서는 각각 다음과 같은 관리형 서비스를 제공합니다.

• 레이크하우스 런타임 카탈로그(Google Cloud의 관리형 Apache Iceberg 카탈로그로, Lakehouse for Apache Iceberg의 일부)는 데이터 레이크하우스의 단일 진실 공급원 역할을 하는 서버리스 확장형 메타스토어입니다. 이를 통해 여러 엔진(BigQuery, Google 관리형 Spark, Apache Spark, Trino, Snowflake)이 Apache Iceberg 같은 개방형 형식 전반에서 동일한 데이터 사본에 액세스할 수 있습니다. 또한 페더레이션을 사용하면 Google Cloud의 에이전트와 엔진이 Snowflake, Databricks, AWS Glue 등의 카탈로그에 있는 데이터에도 경계를 넘어 액세스할 수 있습니다.
• Snowflake Horizon Catalog는 Apache Polaris를 통합하고, 추가 설정 없이 모든 Snowflake 계정에 표준 준수 IRC 엔드포인트를 내장합니다. Horizon은 기본 카탈로그 운영을 넘어 엔터프라이즈 거버넌스 기능을 제공합니다. RBAC, 컬럼 수준 마스킹, 행 액세스 정책, 데이터 계보, 감사 로깅이 여기에 포함됩니다. 또한 Trino, BigQuery, Apache Flink 등 다양한 Iceberg 호환 엔진이 Snowflake 관리형 Iceberg 테이블을 읽고 쓸 수 있습니다.

페더레이션: 레이크하우스에서 개방형 레이크하우스로

레이크하우스 런타임 카탈로그, Snowflake Horizon Catalog 및 기타 관리형 카탈로그 옵션은 서로 배타적인 선택지가 아닙니다. 이들은 카탈로그 페더레이션을 통해 같은 조직 안에서 공존할 수 있으며, 조직은 단일 카탈로그에서 시작한 뒤 필요에 따라 점진적으로 페더레이션을 확장할 수 있습니다.

각 카탈로그는 자체 테이블을 관리하고, 모든 엔진은 IRC를 통해 해당 테이블에 액세스합니다.

Google Cloud가 레이크하우스 런타임 카탈로그를 통해 카탈로그를 관리하는 경우, Snowflake는 IRC 엔드포인트에서 테이블을 자동으로 검색하고 동기화하는 카탈로그 연결 데이터베이스(CLD)를 통해 연결됩니다. Snowflake 사용자는 표준 SQL(SELECT, INSERT, UPDATE, DELETE) 또는 Snowflake의 CoCo, CoWork를 통해 Google Cloud 레이크하우스 Iceberg 테이블을 네이티브 테이블처럼 사용할 수 있으며, 그 위에는 Snowflake 거버넌스(RBAC, 마스킹, 계보)가 적용됩니다.

마찬가지로 Snowflake가 Horizon을 통해 카탈로그를 관리하는 경우, Google Cloud 서비스는 레이크하우스 카탈로그 페더레이션을 통해 해당 테이블에 도달합니다. 즉 BigQuery, Apache Spark용 관리형 서비스 및 Google Cloud의 기타 Iceberg 호환 엔진이 Horizon의 IRC 엔드포인트에 연결해 Snowflake 관리형 Iceberg 테이블을 직접 읽고 씁니다.

그 결과 완전히 개방적이고 상호운용 가능한 데이터 플랫폼이 구현됩니다. 모든 엔진은 시스템 간 ETL 없이 고객의 클라우드 스토리지 버킷에서 직접 읽고 쓰며, 각 팀은 고유한 선호도에 따라 작업에 가장 적합한 도구를 선택합니다. 동시에 카탈로그 계층은 이 모든 환경 전반에 통합 거버넌스를 적용합니다.

시맨틱 컨텍스트: 개방형 레이크하우스에서 AI -ready 환경으로

잘 설계된 레이크하우스는 데이터 상호운용성 문제를 상당 부분 해결하지만, 상호운용성만으로 AI가 데이터를 제대로 활용할 수 있는 것은 아닙니다. “데이터에 액세스할 수 있다”는 것과 “AI가 정확하고 신뢰할 수 있는 답변과 행동을 생성한다”는 것 사이에는 다음 세 가지 간극이 존재합니다.

• 프로그래밍 방식의 액세스
• 시맨틱 토대
• 컨텍스트 기반 지능

프로그래밍 방식의 액세스
사람 분석가는 자신이 선호하는 엔진으로 테이블을 쿼리하지만, AI 에이전트에는 별도의 접근 채널이 필요합니다. Snowflake는 모든 MCP 호환 클라이언트가 레이크하우스 데이터를 탐색하고 쿼리하며 추론할 수 있도록 Model Context Protocol(MCP) 서버를 제공합니다. MCP는 AI 애플리케이션과 데이터 소스 사이에 범용 인터페이스를 제공하는 개방형 표준 인터페이스입니다. 따라서 Gemini Enterprise, 코드 어시스턴트, 사용자 지정 에이전트 프레임워크는 각각 별도의 통합을 구현할 필요 없이 동일한 프로토콜을 통해 데이터에 연결할 수 있습니다. 마찬가지로 BigQuery도 퍼스트 파티와 서드 파티 AI 에이전트 모두에서 액세스할 수 있는 MCP 서버를 제공해, Google Cloud 및 멀티클라우드 환경 전반의 에이전트형 워크플로우에서 레이크하우스 자산에 대한 프로그래밍 방식 액세스를 지원합니다.

오케스트레이션 프레임워크, 사용자 지정 파이프라인, 임베디드 분석처럼 직접적인 프로그래밍 방식 제어가 필요한 애플리케이션의 경우 Cortex Agents와 Gemini Enterprise 에이전트도 REST API를 통해 액세스할 수 있습니다. MCP와 REST API를 함께 사용하면 AI 에이전트도 사람 분석가와 동일하게 인증과 거버넌스가 적용된 방식으로 Iceberg 테이블에 접근할 수 있으며, 해당 테이블이 어떤 카탈로그에서 관리되는지와는 관계없이 동일한 접근 방식을 제공합니다.

시맨틱 토대
AI 시스템은 데이터가 무엇을 의미하는지 이해하지 못할 때 할루시네이션을 일으킵니다. 시맨틱 모델은 물리적 테이블 위에 비즈니스 로직을 정의함으로써 이러한 문제를 해결합니다. 여기에는 계산 규칙을 갖춘 지표, 계층 구조를 갖춘 차원, 엔터티 간 관계, 그리고 조직의 지식을 담은 검증된 쿼리 패턴이 포함됩니다. 여기서 중요한 점은 비즈니스 로직이 AI 프롬프트가 아니라 데이터 계층에 존재해야 한다는 것입니다. 정의가 데이터 위의 시맨틱 모델에서 관리되면 모든 AI 시스템이 동일하고 올바른 로직을 상속하므로, 드리프트와 불일치, 추측이 줄어듭니다.

Semantic View Autopilot는 Horizon Context의 일부로, 이러한 작업을 대규모 환경에서도 지속 가능하게 만들어 줍니다. Autopilot은 분석가가 수백 개의 시맨틱 모델을 수동으로 정의하도록 요구하는 대신, 쿼리 패턴, 사용자 행동, 테이블 관계, BI 도구 통합, 보고서 사용 현황을 학습해 시맨틱 모델을 자동으로 발견하고 유지 관리합니다. 자연어를 활용해 시맨틱 모델을 직접 작성하고 다듬고 싶은 팀을 위해서는 Semantic Studio의 내장형 CoCo 어시스턴트(현재 프라이빗 프리뷰 제공)가 Git 통합 기능, 비주얼 및 YAML 에디터와 함께 제공됩니다. 따라서 시맨틱 정의를 다른 코드 자산처럼 버전 관리 및 코드 리뷰를 수행할 수 있습니다. 데이터가 변화하더라도 시맨틱 모델은 최신 상태를 유지하므로 시간이 지나도 AI 정확도가 저하되지 않습니다. 그 결과 할루시네이션은 줄어들고 정확도는 높아지며, 비즈니스 로직은 실제 데이터에 기반하게 됩니다. 마찬가지로 Google Cloud의 범용 시맨틱 계층을 활용할 수도 있습니다. Looker가 새롭게 지원하는 데이터베이스 내 분석 모델을 활용하는 방식이며, 여기에는 BigQuery Graph 및 Snowflake Semantic Views와의 새로운 통합이 포함되어 핵심 에이전트 여정에서 비즈니스 사용자에게 그래프 모델의 역량을 제공합니다.

컨텍스트 기반 지능
컨텍스트란 AI 시스템에 데이터가 무엇인지뿐 아니라 이를 올바르게 해석하는 방법까지 알려주는 주변 정보입니다. Snowflake Horizon Context는 이러한 컨텍스트 계층을 생성하고 적용합니다. 여기에는 비즈니스 용어로 작성된 테이블 및 컬럼 설명, 데이터 품질 신호(최신성, 완전성, 유의 사항), 사용 패턴(어떤 질문에 어떤 테이블이 권위 있는지), 레이크하우스 전반의 도메인 관계가 포함됩니다. 이러한 컨텍스트는 Horizon에서 관리되므로 데이터와 동일한 거버넌스를 상속합니다. 따라서 에이전트와 사용자 모두 자신에게 권한이 있는 컨텍스트와 답변만 확인할 수 있습니다. Google Cloud Lakehouse도 Knowledge Catalog를 통해 신뢰할 수 있는 컨텍스트를 제공하며, Gemini 기반 인사이트를 레이크하우스 테이블에 제공하여 AI 에이전트의 할루시네이션을 줄이고, 사용자가 인사이트를 실제 업무에 활용할 수 있도록 지원합니다. 이 컨텍스트는 Snowflake 네이티브 Iceberg 테이블은 물론, CLD로 연결되거나 Google Cloud에서 페더레이션된 모든 Iceberg 테이블에 적용됩니다. 결국 AI는 데이터뿐만 아니라, 해당 데이터를 정확하게 해석하는 데 필요한 컨텍스트까지 함께 전달받습니다. 이것이 단순한 LLM의 추측성 답변(“매출은 ...일 수 있습니다”)과 근거 기반 응답( “4분기 매출은 회계 분기 정의로 필터링한 신뢰할 수 있는 finance.revenue 테이블 기준 $47.2M였습니다”)을 구분하는 핵심 요소입니다.

에이전틱 AI: 데이터에서 실행으로

엔터프라이즈 컨텍스트와 시맨틱 뷰가 마련되면 AI 에이전트는 정형 및 비정형 데이터를 모두 높은 정확도로 활용할 수 있습니다. Snowflake CoWork는 모두의 업무를 위한 개인 에이전트로, 깊이 있게 추론하고 반복 업무를 자동화하며 아이디어가 의사결정과 실행으로 이어지는 시간을 단축합니다. 단순히 사용자의 지시를 기다리는 것이 아니라, 능동적으로 인사이트를 제시하고, 백그라운드에서 분석을 실행하며, 비즈니스가 데이터를 실제로 정의하는 방식에 기반해 거버넌스가 적용되고 추적 가능한 답변을 제공합니다.

Snowflake CoCo는 이러한 역량을 개발 워크플로우로 확장하여 엔터프라이즈 데이터 수명 주기 전반에서 데이터 네이티브 코딩 에이전트 역할을 수행합니다. 파이프라인 구축 및 유지 관리뿐만 아니라, Cortex Agents와 Streamlit 앱 생성, 실제 카탈로그 메타데이터에 기반한 검증된 SQL 및 Python 생성까지 지원합니다. 이를 통해 지식 근로자와 데이터 엔지니어 모두 동일한 시맨틱 토대를 공유하고, 사람과 에이전트의 작업 전반에 거버넌스와 옵저버빌리티를 적용해 운영할 수 있습니다.

이와 같은 동일한 페더레이션 기반은 Google Cloud의 AI 기능도 네이티브로 사용할 수 있게 합니다. 레이크하우스가 Google Cloud에서 실행되므로 Gemini 역시 스택 전반에서 네이티브로 활용할 수 있습니다. Gemini는 텍스트, 이미지, 비디오, 코드를 하나의 컨텍스트에서 함께 이해하는 멀티 모달 기능을 제공합니다. 따라서 레이크하우스는 정형 테이블뿐만 아니라 GCS에 저장된 문서, 이미지, 비정형 콘텐츠까지 모두 AI 워크플로우에 포함할 수 있습니다. 또한 Gemini의 긴 컨텍스트 윈도우는 대규모 스키마, 시맨틱 모델 정의, 쿼리 기록 등을 한 번에 처리할 수 있어 복잡한 분석 질의에 대한 정확도를 높입니다.

Gemini Enterprise는 Lakehouse for Apache Iceberg 환경에서 MCP(Snowflake MCP 서버 또는 BigQuery MCP 서버)를 통해 레이크하우스와 연결됩니다. Gemini Enterprise 사용자는 자연어로 질문하고, Iceberg 테이블의 거버넌스 적용 데이터를 바탕으로 답변을 받습니다. 이때 쿼리는 Cortex Agents와 시맨틱 모델을 통해 라우팅되어 근거 기반 응답을 보장합니다. 사용자가 Snowflake CoWork, CoCo, Gemini Enterprise 또는 REST API 기반의 사용자 지정 AI 에이전트 중 어떤 방식을 통해 상호작용을 하든 동일한 시맨틱 계층, 동일한 컨텍스트, 동일한 거버넌스가 일관되게 적용됩니다.

그 결과는 단순한 개방형 레이크하우스를 넘어섭니다. 상호운용성과 거버넌스를 갖추고, 풍부한 시맨틱 정보와 표준화된 프로토콜을 제공하여 사람과 AI 에이전트 모두가 접근할 수 있는 AI 활용 준비가 된 개방형 레이크하우스입니다.

더 알아보기

• Snowflake에서 상호운용 가능한 레이크하우스 구축하기 위한 최신 제품 기능을 확인해 보세요.
• Snowflake와 Google Cloud로 구현하는 Cross-Cloud Lakehouse에 대해 알아보세요.
• Google Cloud에서 제공하는 Snowflake 관련 콘텐츠를 더 확인해 보세요.

참고: Apache Iceberg, Apache Polaris 및 Apache Spark는 Apache Software Foundation의 상표입니다.