Skip to main content
이 문서는 선행 지식 섹션의 일부입니다.

​
데이터 수집 (Ingestion) 솔루션

​
스트리밍 수집

​
배치/CDC 수집

💡 데이터 수집 도구 선택의 현실: 현업에서 가장 많이 쓰이는 조합은 (1) Kafka(실시간 이벤트) + (2) Fivetran 또는 Lakeflow Connect(SaaS/DB 배치 수집) + (3) Auto Loader(파일 수집) 입니다. 세 가지를 용도에 맞게 조합하면 대부분의 수집 요구사항을 커버할 수 있습니다.
💡 CDC(Change Data Capture)란? 데이터베이스에서 발생하는 변경 사항(INSERT, UPDATE, DELETE)을 실시간으로 감지하여 다른 시스템에 전달하는 기술입니다. 전체 데이터를 매번 복사하는 대신, 변경된 부분만 전달하므로 효율적입니다.

​
데이터 처리 (Processing) 엔진

💡 Spark vs Polars: “우리 데이터가 수 GB인데도 Spark를 써야 하나요?”라는 질문을 자주 받습니다. 데이터가 수십 GB 이하이고 단일 머신에서 처리 가능하다면, Polars나 DuckDB가 더 가볍고 빠를 수 있습니다. Spark는 수 TB~PB 규모의 데이터, 또는 여러 사용자가 동시에 접근하는 환경에서 진가를 발휘합니다. Databricks의 Serverless 노트북에서는 소규모 데이터도 빠르게 처리할 수 있으므로, 실무에서는 “일관된 환경”의 이점을 위해 Databricks를 사용하는 경우가 많습니다.

​
클라우드 데이터 플랫폼 비교

​
주요 플랫폼 상세 비교

Databricks vs Snowflake — 가장 자주 받는 비교 질문
💡 클라우드 데이터 플랫폼 선택의 현실: 실무에서 플랫폼을 선택할 때, 순수 기술력보다 **“우리 팀이 가장 잘 쓸 수 있는 도구”**가 더 중요합니다. SQL 분석가가 대다수인 팀에서는 Snowflake가, ML/AI 엔지니어가 많은 팀에서는 Databricks가, Microsoft 생태계에 깊이 투자한 조직에서는 Fabric이 자연스러운 선택입니다.

​
AI & ML 플랫폼

💡 MLflow vs 다른 ML 플랫폼: MLflow는 Databricks가 만든 오픈소스이지만, Databricks 없이도 사용할 수 있습니다. SageMaker나 Vertex AI는 각 클라우드에 종속되지만, MLflow는 어디서든 실행 가능합니다. 이러한 오픈소스 전략은 Databricks의 핵심 철학 중 하나입니다. 현업에서는 MLflow를 “실험 추적의 표준”으로 사용하는 팀이 매우 많으며, Databricks를 쓰지 않는 회사에서도 MLflow만 독립적으로 사용하는 경우가 있습니다.

​
데이터 거버넌스

💡 데이터 거버넌스가 왜 중요한가요? GDPR(유럽 개인정보보호법), 개인정보보호법 등 규제가 강화되면서, “누가, 어떤 데이터를, 언제, 왜 접근했는지”를 추적할 수 있어야 합니다. 거버넌스 도구 없이 운영하면 감사(Audit) 시 대응이 불가능합니다. Unity Catalog는 이를 Databricks 플랫폼 안에서 자연스럽게 해결합니다.

​
빅 플레이어 포지션 맵

데이터 플랫폼 포지션 비교

​
실무 경험으로 본 각 도구 — 써본 사람만 아는 이야기

​
Hadoop: 설치에 3일, 운영에 평생

2010년대 초반, Hadoop은 빅데이터의 대명사였습니다. 하지만 실제로 운영해본 사람이라면 이런 기억이 있을 것입니다.

​
Spark: 30분이면 시작, 하지만 튜닝은 별도

Spark는 Hadoop의 고통을 크게 줄여주었습니다. 하지만 직접 운영하면 다른 문제가 생깁니다.
💡 Databricks와의 차이: Databricks는 이런 Spark 운영의 고통을 해결하기 위해 만들어졌습니다. 클러스터 자동 확장, Photon 엔진(C++ 기반 고성능 실행 엔진), Adaptive Query Execution(자동 튜닝), 데이터 스큐 자동 감지 등을 플랫폼 수준에서 제공합니다.

​
왜 어떤 도구는 사라지고, 어떤 도구는 살아남았는가?

💡 핵심 교훈: 살아남은 도구들의 공통점은 (1) 명확한 차별점이 있고, (2) 활발한 커뮤니티가 있으며, (3) 클라우드 환경에 적응했다 는 것입니다. 반면 사라진 도구들은 “더 나은 대안이 등장했는데, 전환 비용이 높지 않았던” 도구들입니다.

​
현재 생태계에서 Databricks의 위치

Databricks는 “데이터 플랫폼의 스위스 아미 나이프”라고 할 수 있습니다. 아래와 같이 다른 도구들을 하나의 플랫폼으로 대체하거나 통합합니다. 물론 Databricks가 모든 도구를 100% 대체하는 것은 아닙니다. 예를 들어, 복잡한 시각화가 필요하면 Tableau가 여전히 강력하고, 초저지연 스트리밍이 필요하면 Flink가 적합합니다. 하지만 “80%의 워크로드를 하나의 플랫폼에서 처리할 수 있다”는 것은 운영 복잡성을 크게 줄여줍니다.
💡 현업에서는 이렇게 합니다: 대부분의 기업에서 Databricks를 도입할 때 “모든 기존 도구를 Databricks로 교체”하지는 않습니다. 가장 흔한 패턴은 (1) 기존 Kafka는 그대로 유지, (2) ETL/ML은 Databricks로 통합, (3) BI는 기존 Tableau를 Databricks SQL에 연결 하는 방식입니다. 점진적 마이그레이션이 현실적이며, 한 번에 모든 것을 바꾸려 하면 리스크가 커집니다.

​
기술 선택 가이드

​
규모/용도별 적합한 기술 스택

💡 현업에서는 이렇게 합니다: 기술 선택은 “현재 팀의 역량”과 “데이터 규모”를 기준으로 해야 합니다. 데이터가 수 GB이고 팀이 23명이면 PostgreSQL + dbt로 충분합니다. 데이터가 TBPB 규모이고 팀이 10명 이상이면 Databricks나 Snowflake 같은 클라우드 데이터 플랫폼이 필수적입니다. “나중에 커질 것을 대비해서 처음부터 큰 도구를 도입하자”는 접근은 대부분 과도한 복잡성과 비용만 초래합니다.

​
도구 선택 시 피해야 할 함정

현업에서 기술 선택 시 흔히 빠지는 함정들입니다.

​
함정 1: “유행하니까” 도입

​
함정 2: “오픈소스가 무료”라는 착각

​
함정 3: “한 도구로 모든 것을”

만능 도구는 없습니다. Databricks가 아무리 통합 플랫폼이라 해도, 초저지연 OLTP(온라인 트랜잭션)나 복잡한 시각화에는 전문 도구가 더 적합합니다. 각 도구의 강점과 약점을 이해하고, 적재적소에 배치하는 것이 핵심입니다.

​
데이터 오케스트레이션 도구

데이터 파이프라인을 스케줄링하고 관리하는 도구도 생태계의 중요한 부분입니다.
💡 현업에서의 선택: Databricks를 주력으로 사용한다면 Lakeflow Jobs 가 가장 자연스럽습니다. 클러스터 관리, 재시도, 알림이 통합되어 있습니다. 만약 Databricks 외의 다른 시스템(AWS Lambda, API 호출 등)도 오케스트레이션해야 한다면 Airflow 가 적합합니다. 둘을 함께 사용하는 경우(Airflow가 전체 워크플로우를 관리하고, 개별 Databricks 작업은 Lakeflow Jobs로 실행)도 많습니다.

​
데이터 품질 도구

데이터의 정확성과 신뢰성을 보장하기 위한 도구도 점점 중요해지고 있습니다.

​
정리

​
참고 링크