Snowflake Iceberg Horizon 활용법, 데이터 이동 없이 AI 시작하기

기존 순서가 왜 문제였나

원문은 지금까지의 관행을 이렇게 짚습니다. 이사회는 올해 안에 AI를 내놓으라고 하는데, 플레이북은 먼저 데이터를 옮기고 모으고 통제한 다음에 AI를 하라고 해요. 과거에는 데이터를 조회하려면 그 데이터를 소유한 시스템의 전용 컴퓨트를 거쳐야 했습니다. Oracle에 있는 데이터는 Oracle이, Teradata에 있는 데이터는 Teradata가 필요했고, 시스템을 넘나드는 분석은 데이터를 한곳으로 물리적으로 옮기는 일부터 시작했어요. 그래서 중앙 집중이 AI를 포함한 모든 작업의 선행 조건이 됐습니다. 원문은 데이터를 옮길 때마다 비용과 위험이 늘어난다는 점도 강조합니다.

오픈 테이블 포맷이 바꾼 것

Apache Iceberg는 데이터와 그것을 저장한 시스템 사이의 의존을 끊었다고 합니다. 호환되는 어떤 컴퓨트 엔진이든 Iceberg 포맷 데이터를 읽을 수 있어서 저장소와 컴퓨트가 분리돼요. 원문 설명대로라면 Iceberg 테이블은 고객 자신의 클라우드 스토리지에 Parquet 파일로 둘 수 있고, 다른 Iceberg 호환 엔진도 읽을 수 있습니다. 읽기와 쓰기가 양방향으로 되기 때문에 복제 없이 데이터를 쓸 수 있다는 설명이에요.

원문이 든 예시는 두 가지입니다. ERP와 여러 시스템에 운영 데이터가 흩어진 제조사, 그리고 CRM의 고객 데이터와 POS의 거래, 공급망 플랫폼의 재고가 따로 있는 리테일러예요. 이런 소스를 하나의 자산처럼 조회할 수 있고, 데이터는 제자리에 둔 채 AI 워크로드가 그 자리에서 돈다고 합니다.

Horizon Catalog가 맡는 거버넌스

예전에는 거버넌스가 데이터의 위치에 묶여 있었습니다. 일관되게 통제하려면 먼저 중앙화해야 했고, 그래서 거버넌스 요구가 하나 늘 때마다 마이그레이션을 끝내야 할 이유가 하나 늘었어요. Snowflake Horizon Catalog는 플랫폼 안팎의 데이터, 데이터 제품, 앱, 모델, 에이전트에 하나의 정책 세트를 적용합니다. 세분화된 역할 기반 접근 제어, 마스킹과 행 접근 정책, 컬럼 단위 리니지, 접근 이력이 포함돼요.

• 행 접근 및 마스킹 정책을 Apache Spark, Trino, PyIceberg 같은 외부 엔진으로 확장 (퍼블릭 프리뷰)
• 스캔을 계획하는 시점에 정책을 적용해 사용자에게 허용된 데이터만 엔진에 전달
• 모든 작업은 Snowflake 접근 이력에 기록
• 사람 분석가, BI 도구, AI 에이전트 등 호출자 종류와 관계없이 동일하게 적용

AI에 더 엄격한 통제가 필요하면 Agent identity 기능으로 에이전트가 접근할 수 있는 데이터를 호출한 사용자와 별개로 정의할 수 있습니다. 마스킹과 행 접근 정책을 에이전트 세션에 직접 지정할 수 있고, 작업은 사용자와 실행한 에이전트 양쪽에 귀속돼서 컴플라이언스 팀이 AI가 무엇을 언제 건드렸는지 감사 추적을 얻어요. 원문은 GDPR, 데이터 레지던시, EU AI Act를 겨냥한 설명도 덧붙였습니다.

실무 적용 포인트

원문이 권하는 방향은 분명합니다. 데이터가 언제 준비되느냐고 묻지 말고, 한 분기를 더 기다리면 비용이 얼마인지 물으라는 거예요. 출발점은 초점을 좁힌 파일럿이고, 빠르게 가치를 보여줄 수 있는 유스케이스를 우선합니다. 체크할 항목을 정리하면 이렇습니다.

• AI 일정과 마이그레이션 일정을 분리해서 계획하기
• 거버넌스 프레임워크가 아직 정비 중이어도 첫날부터 그 안에서 AI 워크로드 만들기
• 새 유스케이스를 데이터 전략과 아키텍처를 다듬는 테스트 베드로 쓰기
• AI 에이전트 접근 권한을 사용자 권한과 따로 설계하기

거버넌스 없이 속도만 내면 도시계획 없이 지은 도시처럼 AI 도구가 난립하고, 결과가 제각각이라 AI 산출물에 대한 신뢰가 깎인다고 원문은 경고합니다. 마이그레이션도 AI가 힘든 부분을 맡으면 더 빨라질 수 있다는 점에서, AI는 현대화의 결과이면서 도구라는 입장이에요.