Snowflake vs Databricks — Glass Box와 Black Box, 그리고 수렴하는 두 플랫폼
Databricks vs Snowflake 2026: Architecture, Cost, Use Cases — 미상 (데이터 플랫폼 비교 블로그, 2026 — 이 학습 프로그램에서는 Snowflake 관점 앵커로 취급) 전체 (pp.1-13, Databricks 자체 심화보다 'Snowflake와 어떻게 다른가'에 초점) — Architecture, Storage Layer, Performance, Pricing, Use Cases, FAQ, Conclusion
이 모듈을 다 읽으면
- 'Glass Box'(Databricks)와 'Black Box'(Snowflake) 비유가 가리키는 통제력·추상화 수준의 차이를 설명할 수 있다
- 스토리지 계층에서 Delta Lake+Liquid Clustering과 마이크로파티션+Hybrid Table을 대응시켜 비교할 수 있다
- 두 플랫폼의 비용 모델(DBU+클라우드 인프라 vs 크레딧) 서술의 한계를 정정할 수 있다
- 워크로드 유형별로 어떤 플랫폼이 유리한지 판단하고, 두 플랫폼이 서로의 강점 쪽으로 수렴하는 흐름을 설명할 수 있다
Databricks는 고객이 소유한 클라우드 스토리지 위에 Delta Lake·Spark·Photon·Unity Catalog를 얹는 'Glass Box'(개발자가 파티셔닝·셔플·파일 포맷까지 들여다볼 수 있는 구조)이고, Snowflake는 SQL만 노출하고 내부 최적화를 전부 감추는 'Black Box'다. 스토리지 계층에서는 Delta Lake의 Liquid Clustering이 Snowflake 마이크로파티션·Hybrid Table(Unistore)에 대응되고, 비용 모델은 DBU+클라우드 인프라(Databricks) vs 크레딧 단일 청구(Snowflake)로 대비되지만, Databricks Serverless 제품은 이미 단일 청구 모델로 수렴하고 있어 '항상 두 장의 청구서'라는 단순화는 정정이 필요하다. 두 플랫폼은 워크로드별 강점이 뚜렷이 다르면서도, Snowflake는 Python/Iceberg를, Databricks는 Serverless SQL/거버넌스 UI를 각각 흡수하며 점점 서로를 닮아가고 있다.
아키텍처 철학: Glass Box vs Black Box
Databricks는 데이터를 자체 스토리지에 저장하지 않는다. 데이터 파일은 고객이 소유한 클라우드 오브젝트 스토리지(AWS S3, Azure Data Lake, GCS)에 Parquet·Delta Lake 형식 그대로 남아 있고, Databricks는 그 위에서 동작하는 처리 계층 — Delta Lake(트랜잭션 계층), Apache Spark(분산 컴퓨트 엔진), Photon(C++로 작성된 벡터화 SQL 실행기), Unity Catalog(거버넌스) — 로 기능한다. 개발자는 파티셔닝, 셔플, 캐싱, 파일 포맷을 직접 들여다보고 다룰 수 있다는 점에서 이를 'Glass Box'라고 부른다. 이는 배우는 사람에게 기회이자 어려움이다 — 실제 대규모 데이터 프레임워크가 어떻게 동작하는지 깊이 이해할 수 있지만, 그만큼 익혀야 할 개념도 많다.
Snowflake는 완전관리형 SaaS로 동작한다. 사용자는 파일이 어디에 있는지, 파티션을 어떻게 관리할지 전혀 신경 쓸 필요가 없고, 데이터는 Snowflake 내부에 저장되며 오직 SQL을 통해서만 접근한다. 클러스터링, 프루닝, 압축, 스케일링, 메타데이터 최적화가 모두 내부에서 자동으로 처리되기 때문에 'Black Box'라고 불린다. 이 덕분에 깊은 엔지니어링 지식 없이도 빠르고 예측 가능한 성능을 낼 수 있어, BI·분석 세계에서 널리 채택된다.
핵심 포인트
- Databricks는 고객 소유 클라우드 스토리지 위에 처리 계층(Delta Lake, Spark, Photon, Unity Catalog)만 얹는 'Glass Box' 구조다
- 개발자가 파티셔닝·셔플·파일 포맷을 직접 다룰 수 있다는 것이 Databricks의 통제력이자 학습 난이도의 원천이다
- Snowflake는 데이터를 내부에 저장하고 SQL만 노출하는 'Black Box' 구조로, 내부 최적화는 전부 자동 처리된다
스토리지 계층 대응: Liquid Clustering vs Hybrid Table
Databricks에서는 Delta Lake — Parquet 파일 위에 트랜잭션 로그(_delta_log 폴더)를 얹은 오픈소스 포맷 — 를 사용한다. 한동안 개발자는 Z-Ordering으로 파일 물리적 배치를 수동으로 관리했지만, 최근 도입된 Liquid Clustering은 힐베르트 커브(Hilbert curve)를 이용해 파일 레이아웃을 동적으로 자동 재조정하는 방식으로 이를 대체하며 '작은 파일 문제'를 자동으로 해결한다. 사용자는 디렉터리 레이아웃(예: /year=2024/month=12/)을 고민하는 대신 CLUSTER BY로 클러스터링 키만 지정하면 되고, OPTIMIZE 명령으로 전체 재작성보다 저렴한 증분 재클러스터링을 트리거할 수 있다.
Snowflake는 마이크로파티션(모듈 2 참고)으로 파일을 자동 관리하며, 표준 테이블은 분석(OLAP) 워크로드에 강점을 갖는다. 여기에 더해 개별 행 단위 조회와 기본 키(Primary Key) 제약이 필요한 트랜잭션(OLTP)성 워크로드를 위한 Hybrid Table(Unistore)을 별도로 제공한다 — 행 기반 저장과 인덱스를 지원해 애플리케이션 상태 저장 같은 용도에 적합하다.
핵심 포인트
- Databricks는 Z-Ordering(수동)에서 Liquid Clustering(힐베르트 커브 기반 자동 재정렬)으로 진화해 작은 파일 문제를 해결했다
- Snowflake 표준 테이블은 마이크로파티션 기반 OLAP에 강점을 가지며, OLTP성 워크로드는 별도의 Hybrid Table(Unistore)로 대응한다
- 두 플랫폼 모두 '파일 레이아웃 자동 최적화'라는 같은 문제를 서로 다른 자료구조(힐베르트 커브 vs 마이크로파티션)로 해결한다
비용 모델과 그 단순화의 한계 — 정정
Databricks는 DBU(Databricks Unit, 플랫폼 사용료)와 클라우드 VM 비용(예: EC2)을 각각 별도로 지불하는 모델이다. Spot Instance 같은 저렴한 VM을 활용하면 비용을 크게 절감할 수 있어 유연하지만, 청구서가 두 장으로 나뉘어 복잡하다는 인상을 준다. Snowflake는 크레딧이라는 단일 단위로 컴퓨트+마크업을 묶어 청구하는 'all-in' 모델이라 단순하지만, 순수 인프라 단가만 따로 최적화하기는 어렵다.
정정 — 원문은 Databricks 비용 모델을 '항상 DBU+별도 클라우드 VM 청구'로 단순화해 서술하지만, Databricks의 Serverless 제품(Serverless SQL 웨어하우스, Serverless 잡·노트북 컴퓨트)은 클라우드 인프라 비용을 DBU 단가 안에 통합해 단일 청구서로 제공한다. 즉 실제로는 '클래식 컴퓨트를 쓰면 두 장의 청구서, Serverless 컴퓨트를 쓰면 Snowflake와 유사한 한 장의 청구서'로 나뉘는 것이 정확한 서술이며, '항상 두 장'이라는 단정은 최신 상황과 다르다. 스토리지 비용 역시 Databricks는 고객이 소유한 스토리지의 저렴한 요율을 그대로 지불(패스스루)하는 반면, Snowflake는 관리형 스토리지에 소폭의 마크업(대략 TB당 40달러 안팎으로 알려져 있으나 클라우드·리전·계약 형태에 따라 달라진다)이 붙는다는 차이도 있다.
핵심 포인트
- Databricks 클래식 컴퓨트는 DBU+클라우드 VM으로 청구서가 두 장이지만, Serverless 제품은 단일 청구로 통합되어 있다
- 정정: '항상 두 장의 청구서'라는 서술은 Databricks Serverless 제품군에는 적용되지 않는다
- Snowflake 스토리지는 관리형이라 소폭의 마크업이 붙지만, Databricks는 고객 소유 스토리지 요율을 그대로 패스스루한다
워크로드 매핑과 수렴 흐름
원문이 제시하는 용도별 권장은 다음과 같다 — 데이터 웨어하우징·BI/대시보드(높은 동시성, 빠른 캐싱)는 Snowflake, 실시간 ETL(복잡한 이벤트 처리는 Spark Streaming)과 데이터 사이언스·ML(네이티브 MLflow, Python 생태계, GPU 지원)은 Databricks, 이미지·오디오·비디오 같은 비정형 데이터 처리도 Databricks가 유리하다. 두 플랫폼을 함께 쓰는 조직도 흔하다 — Databricks에서 ETL·ML 처리를 마친 뒤 최종 'Gold' 테이블만 Snowflake로 옮겨 비즈니스 분석가들이 Tableau나 PowerBI로 조회하게 하는 패턴이다.
동시에 두 플랫폼은 서로의 강점 쪽으로 수렴하는 중이다. Snowflake는 Python 지원(Snowpark), Streamlit 앱 실행(Snowpark Container Services), Iceberg Table(모듈 9 참고) 역량을 흡수하며 데이터 레이크에 가까워지고 있다. Databricks는 Serverless SQL, Unity Catalog, 개선된 UI로 데이터 웨어하우스에 가까운 사용성을 갖춰가고 있다. 'Databricks가 Snowflake를 대체할 것인가/그 반대인가'라는 이분법적 질문보다, 두 아키텍처(엔진으로서의 Databricks, 박스로서의 Snowflake)를 모두 이해하는 것이 주니어와 시니어 데이터 엔지니어를 가르는 기준이라는 것이 원문의 결론이다.
핵심 포인트
- BI/대시보드/웨어하우징은 Snowflake, 실시간 ETL/ML/비정형 데이터 처리는 Databricks가 유리하다는 것이 일반적인 용도 매핑이다
- Databricks에서 ETL/ML을 처리한 뒤 Gold 테이블만 Snowflake로 옮겨 BI 도구가 조회하게 하는 결합 사용 패턴이 흔하다
- Snowflake는 Python/Iceberg 역량을, Databricks는 Serverless SQL/Unity Catalog/UI 개선을 흡수하며 서로 수렴하고 있다