개방형 상호운용성을 통한 데이터 선택권 확보
이 블로그 독자라면 직관적으로 이해할 수 있겠지만 먼저 개방형 상호운용성을 정의해 보겠습니다. 개방형 상호운용성이란 개방형으로 공개된 표준 기반 인터페이스를 통해 거버넌스가 적용된 데이터에 안전하게 액세스하도록 조직의 데이터 플랫폼을 설계하는 역량입니다. 이를 통해 독점 기술 종속을 줄이고 더 폭넓은 생태계 호환성을 확보할 수 있습니다.
개방형 상호운용성은 조직과 데이터의 관계를 바꿉니다. 조직에 데이터 주도권을 부여해 부담이 큰 마이그레이션이나 데이터 이동 없이 각 워크로드에 가장 적합한 엔진과 도구를 자유롭게 선택할 수 있게 합니다. 이 정의는 Snowflake가 Apache Iceberg™와 Apache Polaris™에서 최고 수준의 경험을 제공하는 방식의 핵심입니다. 그 결과 고객은 Iceberg 테이블을 Snowflake나 다른 환경에 배치하면서 Snowflake 카탈로그로 강제로 이전하지 않고도 해당 테이블에 대한 모든 읽기 및 쓰기 작업을 수행할 수 있습니다.
Databricks Unity Catalog도 상호운용성을 제공한다고 주장합니다. 그러나 자세히 살펴보면 개방형 상호운용성의 가장 기본적인 약속조차 충족하지 못한다는 것을 알 수 있습니다. 모든 Iceberg 테이블을 읽거나 쓸 수 있어야 하며 특정 도구에 종속되지 않는 개방형 보안 메커니즘을 통해 이러한 작업을 수행할 수 있어야 한다는 약속입니다.
모든 Iceberg 테이블을 읽고 쓰기
테이블에 사용할 카탈로그를 선택하는 것은 아키텍처에서 가장 중요한 결정입니다. 이 선택은 해당 테이블이나 다른 테이블에서 수행할 수 있는 작업을 결정하며 선택의 폭을 넓히거나 제한합니다. 바로 이 지점에서 진정한 상호운용성이 중요해집니다. 진정한 상호운용성을 구현하려면 커뮤니티가 주도하는 개방형 표준을 통한 인바운드 및 아웃바운드 페더레이션이 모두 필요합니다. 인바운드 페더레이션은 카탈로그 외부의 엔진이 Iceberg 테이블을 읽고 쓸 수 있다는 뜻이며 아웃바운드 페더레이션은 다른 카탈로그에서 관리하는 Iceberg 테이블을 읽거나 쓸 수 있다는 뜻입니다.
상호운용성 검증을 통과하지 못한 Unity Catalog
이 글을 작성하는 시점에 Unity Catalog는 인바운드 방향에서만 완전한 상호운용성을 지원합니다. 인바운드 액세스의 경우 외부 엔진이 Unity Catalog의 Iceberg REST Catalog 엔드포인트에 연결해 테이블에 액세스할 수 있습니다. 그러나 아웃바운드 액세스는 상황이 근본적으로 다릅니다. Snowflake Horizon과 같은 외부 카탈로그의 Iceberg 테이블에 액세스할 때 Databricks는 Iceberg REST Catalog API를 사용하지 않습니다. 대신 JDBC를 사용해 metadata.json 경로를 가져오는 Snowflake Catalog SDK를 사용한 뒤 사전 구성된 IAM 자격 증명으로 기반 스토리지에 직접 액세스합니다(문서). 더욱이 이 방식은 읽기 작업에만 적용됩니다. 외부 카탈로그에서 관리하는 Iceberg 테이블은 명시적으로 읽기 전용으로 유지되며 외부 Iceberg 테이블에 대한 쓰기는 지원되지 않습니다(문서).
이러한 제한이 데이터 주도권 확보에 미치는 영향은 분명합니다. Databricks와 Unity Catalog에서 워크로드를 운영하면 사실상 전체 데이터 자산을 Unity Catalog로 마이그레이션해야 합니다. 이는 상호운용성의 기본적인 약속을 훼손할 뿐 아니라 Unity Catalog가 시장에서 가장 ‘상호운용성이 뛰어난 카탈로그’라는 자체 주장과도 배치됩니다.
Snowflake Horizon Catalog는 근본적으로 다릅니다. Apache Polaris를 기반으로 구축된 Snowflake Horizon Catalog는 Iceberg REST Catalog 프로토콜을 엔드투엔드로 구현합니다. Horizon은 Snowflake의 네이티브 거버넌스 계층입니다. Snowflake가 관리하거나 액세스하는 Iceberg 테이블 전반에 분류, 액세스 정책, 계보, 품질, 카탈로그 관리를 일관되게 적용하면서도 읽기 또는 쓰기 작업을 제한하지 않습니다. 또한 Snowflake의 데이터를 활용하는 데이터 팀은 플랫폼이나 테이블 유형에 한정된 부분적인 뷰가 아니라 전체 데이터 자산에서 민감 데이터가 어디에 있는지 종합적으로 파악할 수 있습니다. 이는 Horizon Catalog가 Catalog Linked Databases라는 기능을 통해 Unity Catalog와 같은 외부 카탈로그에 연결하고 해당 쿼리에 필요한 액세스 권한을 얻기 위해 외부 카탈로그의 Iceberg REST Catalog 엔드포인트를 직접 호출하기 때문에 가능합니다. 새로운 IAM 역할이나 장기 자격 증명을 요청하거나 새로운 보안 메커니즘을 관리하기 위해 플랫폼 팀에 티켓을 제출할 필요가 없습니다.
상호운용성에서 개방형 보안이 중요한 이유
Iceberg REST Catalog는 카탈로그가 서로 안전하게 통신하는 방식을 정의합니다. 이 기능을 발급된 자격 증명(vended credentials)이라고 합니다. 발급된 자격 증명은 특정 작업을 위해 소스 카탈로그가 위임하는 단기 토큰입니다. 이 기능은 카탈로그가 테이블 및 보안 태세에 대한 단일 진실 공급원 역할을 하도록 하는 메커니즘을 제공합니다. 하지만 Iceberg REST Catalog 사양에 정의되어 있더라도 카탈로그가 이를 반드시 구현해야 하는 것은 아닙니다. 발급된 자격 증명의 대안은 IAM 역할과 액세스 키 같은 장기 자격 증명을 통한 광범위한 액세스입니다. 이러한 접근 방식은 보안 태세를 복잡하게 만들고 잠재적 위험을 높입니다. 첫째, 액세스 범위가 특정 쿼리로 제한되지 않으며 실제로는 특정 테이블 단위로도 제한되지 않습니다. 둘째, 소스 카탈로그 및 IAM 계층에 모두 정책을 중복 정의해야 하므로 Iceberg REST 사양이 권장하는 안전한 개방형 상호운용성의 기반이 무너집니다.
Snowflake Horizon Catalog는 인바운드와 아웃바운드 페더레이션 모두에 발급된 자격 증명을 완전하게 구현합니다. 따라서 Snowflake 관리형 Iceberg 테이블에 액세스하는 엔진이 무엇이든 Iceberg 테이블과 액세스 정책을 단일 창에서 관리할 수 있습니다. 실제로 Horizon Catalog에서 액세스 정책을 정의하면 별도 작업 없이 원하는 엔진에서도 해당 정책이 적용됩니다. 지금까지는 오브젝트 수준(카탈로그, 네임스페이스, 테이블)에서 작동해 왔으며 새로 도입되어 프라이빗 프리뷰로 제공되는 Scan Plan API는 호환 엔진에 대한 거버넌스를 세분화된 행 및 열 수준 액세스 제어까지 확장합니다. 이 글을 작성하는 시점에 Unity Catalog는 외부 카탈로그에서 발급한 자격 증명을 사용하지 않으므로 소스 카탈로그의 액세스 정책을 준수하지 않습니다.
전체 비교: 상호운용성이 가장 뛰어난 카탈로그는?
| 주요 기능 | Snowflake Horizon | Databricks UC | 이 격차가 미치는 영향 |
|---|---|---|---|
| Iceberg REST Catalog 자격 증명 발급 구현 | 🟢 양방향: 쿼리별로 발급되는 자격 증명 인바운드 및 아웃바운드 페더레이션 | 🟡 인바운드만 지원. 아웃바운드 연결에서는 IRC를 사용하지 않음.¹ | Unity Catalog는 장기 유효 IAM 자격 증명을 요구해 불필요한 보안 위험을 초래하며 Unity Catalog에서 관리하지 않는 테이블의 쿼리를 JDBC 연결을 통해 라우팅해 쿼리당 비용을 높일 수 있습니다. |
| 외부 카탈로그 테이블 읽기 및 쓰기 | 🟢 Iceberg REST Catalog를 통해 외부 카탈로그 테이블에 모든 DML 지원 | 🟡 Lakehouse Federation은 읽기 전용. 외부 카탈로그 테이블에 INSERT, UPDATE, DELETE, MERGE를 지원하지 않음.² | Unity Catalog에서는 모든 테이블을 마이그레이션하거나 작업을 읽기 전용으로 제한해야 하므로 가치 실현이 지연되고 AI 워크플로우의 효과가 낮아질 수 있습니다. |
| Snowflake 및 Snowflake 외부 엔진에서 쿼리할 때 ABAC 적용 | 🟢 Spark용 행 및 열 마스킹과 행 액세스 정책 GA. Scan Plan API를 통해 모든 Iceberg REST 호환 엔진으로 확대 예정(퍼블릭 프리뷰 예정. 자세한 내용은 계정팀에 문의). | 🟡 외부 Iceberg 엔진용 베타. 프로덕션에 사용할 준비가 되지 않음.³ | 보안 정책은 Snowflake에서는 GA이지만 Databricks에서는 프리뷰 단계입니다. |
| 복제 및 재해 복구 | 🟢 Snowflake 관리형 테이블 완전 지원 | 🟡 행 필터나 열 마스크가 적용된 테이블은 복제에서 제외되며 복구 지점 목표(RPO) 달성을 지연시킴. Managed DR은 제한적으로 제공되는 프리뷰 단계의 유료 부가 기능.⁴ | Unity Catalog에서는 복제 및 재해 복구 대상이 되려면 테이블에서 액세스 정책을 제거해야 합니다. |
Unity Catalog 없이도 Databricks 사용 가능
앞서 설명한 제한 사항은 Unity Catalog에 적용되지만 Databricks 컴퓨팅은 Snowflake Horizon과 같이 Iceberg REST(IRC) API를 지원하는 외부 카탈로그에서 완전한 읽기 및 쓰기 기능을 계속 제공할 수 있습니다. Unity Catalog를 활성화하지 않은 Databricks Spark 클러스터를 구성하면 이러한 기능을 사용할 수 있습니다. 이 구성에서는 클러스터가 모든 IRC 호환 카탈로그에 대한 완전한 읽기 및 쓰기 액세스를 유지하며 각 쿼리는 액세스 정책을 준수합니다. 그러나 클러스터에서 Unity Catalog를 활성화하면 이 기능이 제한됩니다. 이는 Databricks 플랫폼 전반의 제한이 아니라 Unity Catalog에만 해당하는 제한임을 보여줍니다. 오픈 소스 Spark는 Spark 세션 변수를 사용해 Iceberg에 연결하는 방식을 지원합니다. 다만 이 방식을 사용하면 Unity Catalog 통합 모델 외부에서 운영하게 됩니다.
진정한 데이터 주도권으로 가는 길
진정한 데이터 주도권은 선택의 자유에서 출발합니다. 강제 마이그레이션이나 사일로화된 보안 모델의 부담 없이 고유한 워크로드에 가장 적합한 엔진과 도구를 선택할 수 있는 자유입니다. 상호운용성은 단순한 기술 사양이 아니라 고객 우선 아키텍처에 대한 약속입니다.
카탈로그를 선택할 때 차이는 개방형 표준을 어떻게 구현했는지에 있습니다. 상호운용성을 인바운드 연결로만 제한하는 카탈로그를 사용하면 선호하는 컴퓨팅 엔진과 원하는 거버넌스 모델 중 하나를 선택해야 합니다. 반면 Snowflake Horizon에 구현한 것처럼 Iceberg REST Catalog 프로토콜을 엔드투엔드로 구현하면 어떤 엔진을 선택하더라도 보안 태세를 유지하는 양방향 액세스를 제공할 수 있습니다.
데이터 리더의 목표는 분명합니다. 아키텍처 결정은 미래의 선택지를 좁히는 것이 아니라 넓히는 방향이어야 합니다. 개방형 보안과 양방향 상호운용성을 핵심 요건으로 다루는 카탈로그를 우선적으로 고려할 것을 권장합니다. 진정한 개방형 접근 방식을 채택하면 데이터가 단일 공급자에 묶인 종속 요소가 아니라 직접 통제하는 전략적 자산으로 유지됩니다.
이 게시물은 퍼블릭 프리뷰 단계의 기능을 언급하며, 해당 기능은 변경될 수 있습니다. 프리뷰 기능은 프로덕션 사용에 적합하지 않을 수 있습니다. 현재 기능 제공 여부는 Snowflake 설명서를 참조하세요.
- 발급된 자격 증명을 통한 인바운드 및 아웃바운드 페더레이션
- 외부 관리형 테이블 쓰기 지원
Apache Iceberg와 Apache Polaris는 Apache Software Foundation의 상표입니다.
- “Foreign Iceberg 테이블에서는 자격 증명 발급을 지원하지 않습니다.”docs.databricks.com/aws/en/external-access/iceberg
- “외부 페더레이션 Hive 메타스토어와 Lakehouse Federation을 통해 액세스하는 모든 외부 테이블은 읽기 전용입니다.”docs.databricks.com/aws/en/tables/foreign
- “엔진 간 속성 기반 액세스 제어(ABAC)가 베타로 제공됨에 따라 Unity Catalog는 Iceberg REST Catalog Scan API를 사용하는 Iceberg 클라이언트까지 속성 기반 액세스 제어를 확장합니다.”databricks.com/blog/unity-catalog-and-next-era-apache-icebergtm
- “행 필터나 컬럼 마스크가 적용된 테이블과 ABAC 태그가 지정된 리소스는 시스템 테이블에서 복제 실패로 표시되며 장애 조치 그룹 범위에서 해당 리소스를 제거할 때까지 이러한 실패로 인해 RPO 달성이 지연됩니다.” docs.databricks.com/aws/en/admin/managed-disaster-recovery (2026년 6월 19일 업데이트)
