Databricks는 처음인 당신을 위한 안내서: Part 1

데이터 분야에 계신 분들이라면 Hadoop, Spark 같은 단어는 한 번쯤 들어보셨을 겁니다. 대용량 데이터를 처리하는 핵심 기술들이죠. 그런데 최근 들어 “데이터브릭스(Databricks)”라는 이름이 점점 더 많이 들려옵니다. “그거 그냥 클라우드에서 Spark 쓰게 해주는 서비스 아니야?” 라고 생각하셨다면, 오늘 이 글을 통해 그 생각이 완전히 바뀌실 거라 확신합니다.

오늘은 데이터 엔지니어의 시각에서, Databricks가 대체 무엇이고 왜 이렇게 많은 기업들이 주목하는지, 그리고 가장 궁금해하실 비용 문제까지 속 시원하게 파헤쳐 보겠습니다.

들어가며: “우리 회사 데이터, 혹시 따로 놀고 있진 않나요?”

혹시 여러분의 회사 데이터 인프라는 이런 모습 아닌가요?

• 데이터 엔지니어는 ETL 파이프라인을 위해 Airflow 서버를 들여다보고,

• 데이터 분석가는 쿼리 성능을 위해 BigQuery나 Redshift 같은 별도의 웨어하우스에 접속하고,

• 머신러닝 엔지니어는 모델 학습을 위해 SageMaker나 자체 GPU 서버를 사용합니다.

데이터는 분명 S3나 GCS 같은 클라우드 스토리지에 잘 모아뒀는데, 막상 데이터를 사용하려는 사람들은 각자 다른 도구와 환경을 사용하느라 정신이 없습니다. 데이터는 한 곳에 있지만, 활용은 여러 곳에서 파편적으로 일어나는 것이죠.

이런 구조는 마치 여러 부품을 억지로 이어 붙인 ‘프랑켄슈타인 아키텍처’처럼 느껴질 때가 많습니다. 각 분야의 전문가들이 모여 최고의 도구를 선택했지만, 결국 전체적인 복잡도만 높아지고 팀 간의 협업은 점점 더 어려워집니다. 데이터는 쌓여만 가는데 정작 가치 있는 정보를 꺼내 쓰기는 힘든 ‘데이터 늪(Data Swamp)’에 빠지기 딱 좋은 환경입니다.

Databricks의 등장: “데이터 호수와 창고를 합치면 어떨까?”

이런 복잡하고 답답한 상황을 해결하기 위해, 아주 멋진 아이디어가 등장합니다. 바로 ‘레이크하우스(Lakehouse)’ 입니다. 이름에서 짐작할 수 있듯이, ‘데이터 레이크’와 ‘데이터 웨어하우스’를 합친 개념이죠.

• 데이터 레이크 (Data Lake)
  

  

• • 장점: 정형, 비정형 데이터를 가리지 않고 원본 그대로, 저렴하게 저장할 수 있습니다. 유연성이 매우 높죠.

  • 단점: 관리가 제대로 되지 않으면 어떤 데이터가 어디에 있는지 알 수 없는 ‘데이터 늪’이 되기 쉽습니다. 그에 따라, 데이터의 신뢰성이나 품질을 보장하기 어렵습니다.

• 데이터 웨어하우스 (Data Warehouse)

  

  • 장점: 잘 정제된 데이터를 저장하여 빠르고 안정적인 분석(BI)이 가능하며, 데이터 품질과 성능이 보장됩니다.

  • 단점: 구조화된 데이터만 저장할 수 있어 유연성이 떨어지고, 저장 및 컴퓨팅 비용이 비쌉니다. 또한, 머신러닝 같은 고급 분석에 활용하기에는 제약이 있을 수 있습니다.

레이크하우스는 데이터 레이크의 저렴함과 유연함, 그리고 데이터 웨어하우스의 안정성과 성능. 이 두 가지 장점만 쏙쏙 뽑아 합친 것입니다. 모든 데이터를 한 곳(데이터 레이크)에 저장하되, 그 위에 웨어하우스와 같은 안정성과 거버넌스 기능을 제공하는 것이죠.

그리고 오늘 이야기할 Databricks는, 바로 이 레이크하우스 아키텍처를 가장 완벽하게 구현한 통합 데이터 플랫폼입니다.

Databricks 플랫폼 A to Z: 그래서 구체적으로 뭘 할 수 있는데?

“좋아요, 레이크하우스라는 컨셉은 알겠어요. 그럼 Databricks는 구체적으로 어떤 기능들로 이걸 구현하나요?”

데이터 엔지니어의 입장에서 가장 감탄했던 핵심 기능들을 중심으로, 조금 더 깊게 설명해 드릴게요.

똑똑한 파일 포맷, ‘델타 레이크(Delta Lake)’

“그냥 S3에 Parquet 파일 쌓는 거랑 뭐가 달라요?” 라는 질문에 대한 완벽한 대답입니다. 델타 레이크는 일반적인 데이터 파일 위에 강력한 기능들을 추가한 오픈소스 스토리지 포맷입니다.

• ACID 트랜잭션: 데이터 작업(ETL) 중간에 에러가 나도 데이터가 오염되지 않습니다. (S3 같은 객체 스토리지에 저장된 _delta_log라는 트랜잭션 로그를 통해 이를 구현합니다.) 이 로그 덕분에 여러 사용자가 동시에 데이터를 읽고 써도 충돌이 발생하지 않는, 데이터베이스 수준의 안정성을 보장합니다.

• Time Travel: “아차!” 하고 데이터를 잘못 업데이트했나요? 걱정 마세요. 델타 레이크는 마치 ‘Ctrl+Z’처럼 VERSION AS OF 구문을 통해 특정 버전이나 타임스탬프로 데이터를 손쉽게 조회하고 복구할 수 있습니다.

• 스키마 관리: 약속된 데이터 형식(Schema)과 다른 데이터가 들어오면 파이프라인이 깨지는 일을 막아줍니다. Schema Evolution 옵션을 통해 새로운 컬럼이 추가되는 변경사항에는 유연하게 대응할 수도 있습니다.

‘최고 성능’으로 튜닝된, Apache Spark 엔진

Databricks의 심장이자 엔진입니다. 중요한 사실은, Databricks는 Spark를 처음 만든 개발자들이 창업한 회사라는 점입니다. ‘원조 맛집’인 셈이죠. 그들은 단순히 오픈소스 Spark를 가져다 쓰는 것이 아니라, 성능을 극한으로 끌어올린 독자적인 최적화 버전을 제공합니다.

단순한 Spark 호스팅이 아닙니다: Databricks Runtime(DBR)의 비밀

• 🚀 Photon 엔진: 이것이 게임 체인저입니다. 기존 Spark는 JVM(자바 가상 머신) 위에서 동작하는데, Databricks는 C++로 작성된 고성능의 벡터화된(Vectorized) 쿼리 엔진 ‘Photon‘을 개발했습니다. 이는 JVM의 오버헤드를 줄이고 최신 CPU의 SIMD(Single Instruction, Multiple Data) 연산 능력을 최대한 활용하여, 특히 SQL 쿼리나 DataFrame 연산에서 오픈소스 Spark 대비 몇 배나 빠른 성능을 보여줍니다.

• ⚙️ 최적화된 런타임: Databricks는 Spark의 핵심 로직, 예를 들어 데이터 셔플링(Shuffling)이나 캐싱(Caching) 알고리즘을 개선하고, 최신 하드웨어에 맞게 튜닝된 라이브러리들을 포함한 Databricks Runtime (DBR)을 제공합니다. 사용자는 복잡한 Spark 설정을 고민할 필요 없이, 이미 최적화된 환경에서 작업을 시작할 수 있습니다.

• 🛠️ 편리한 관리와 디버깅: 직접 Spark 클러스터를 운영해본 분들은 클러스터 관리와 성능 디버깅이 얼마나 고된 일인지 아실 겁니다. Databricks는 클릭 몇 번으로 클러스터를 생성하고, 작업량에 따라 자동으로 노드 수를 조절(Auto-scaling)하며, Spot Instance를 활용해 비용을 절감하는 기능을 기본 제공합니다. 또한, 복잡한 Spark UI를 개선하여 병목 지점을 훨씬 쉽게 찾을 수 있도록 도와줍니다.

모든 데이터의 중앙 관리자, ‘유니티 카탈로그(Unity Catalog)’

데이터 거버넌스 관점에서도 Databricks는 장점이 많습니다. 단순히 메타데이터를 관리하는 것을 넘어, 강력한 보안과 데이터 계보 추적 기능을 제공합니다.

• 세분화된 접근 제어(Fine-Grained Access Control): 테이블 단위뿐만 아니라 Row(행) 레벨, Column(열) 레벨까지 접근 권한을 제어하고, 특정 컬럼의 데이터를 마스킹 처리할 수 있습니다. 덕분에 여러 데이터 사본을 만들 필요 없이, 하나의 테이블에 대해 사용자 역할별로 다른 뷰를 제공할 수 있습니다.

• 중앙화된 거버넌스: 클라우드 종류(AWS, Azure, GCP)나 리전(Region)에 상관없이, 조직의 모든 Databricks 작업 공간(Workspace)에 있는 데이터를 하나의 카탈로그에서 중앙 집중적으로 관리하고 정책을 적용할 수 있습니다.

협업과 개발을 위한 통합 환경

데이터 엔지니어링 작업은 광범위한 범위를 가지고 있지만, 기본적으로 1) 데이터 수집 및 추출 코드 개발, 2) 작업 스케줄링, 3) SQL 쿼리 실행 환경 구성 및 쿼리 최적화 작업을 포함할 것입니다. 데이터 엔지니어로서 Databricks를 사용하며 가장 큰 장점으로 다가온 것은, 위 3가지 작업을 하나의 플랫폼에서 가능하게 한다는 점입니다.

• Notebook: 데이터 과학자와 분석가들이 Python, SQL, R 등 다양한 언어로 실시간으로 코드를 실행하고 결과를 시각화하며 협업할 수 있습니다.

  

• Workflows: 데이터 엔지니어들이 만든 ETL 파이프라인을 특정 시간마다, 혹은 특정 이벤트가 발생할 때마다 실행하도록 스케줄링하고 모니터링하는 기능입니다. (Airflow의 역할을 Databricks 안에서 해결!)

• SQL Warehouse: 데이터 분석가나 BI 개발자들이 가장 익숙한 SQL을 사용해 대용량 데이터를 빠르고 쉽게 쿼리할 수 있도록 최적화된 컴퓨팅 환경입니다. (위에서 설명한 Photon 엔진이 여기서 진가를 발휘합니다.) 또한, SQL 웨어하우스를 생성하는 것에 그치지 않고, 실시간으로 모니터링 할 수 있는 환경도 제공합니다. 

  

그래서 비용은 어떤가요? (TCO와 실제 예시)

“이렇게 좋은 기능들이 많은데, 당연히 비싸지 않을까요?”

아마 가장 궁금해하실 부분일 겁니다. 결론부터 말씀드리면, Databricks는 ‘공짜’가 아닙니다. 하지만 단순히 비싸다고 말하기 전에, ‘총소유비용(TCO, Total Cost of Ownership)’ 관점에서 바라봐야 합니다.

Databricks는 복잡한 데이터 인프라를 직접 구축하고 운영하는 데 드는 고급 엔지니어의 인건비, 유지보수 및 장애 대응 비용, 데이터 전문가들의 생산성 저하와 같은 수많은 ‘보이지 않는 비용’을 DBU(Databricks Unit)라는 예측 가능한 서비스 비용으로 전환시켜 줍니다. 엔지니어들은 인프라 걱정 없이 데이터의 ‘가치’에만 집중할 수 있게 되죠.

구체적인 비용 예시

개념적인 설명만으로는 감이 잘 안 오실 수 있습니다. 그래서 가상의 시나리오를 통해 Databricks 작업 비용이 실제로 어떻게 계산되는지 단계별로 보여드리겠습니다.

⚠️ 주의: 아래의 가격은 설명을 위한 예시이며, 실제 비용은 클라우드 제공사, 리전, 시점에 따라 변동될 수 있습니다. 계산 방식을 이해하는 데 초점을 맞춰주세요.

• 시나리오: 매일 새벽, 1시간 동안 ETL 파이프라인 실행

• 클러스터: m5d.2xlarge 5대 (드라이버 1, 워커 4)

• 환경: AWS 서울 리전, Premium 플랜, Jobs Compute

1단계: 클라우드 인프라 비용 (AWS EC2)
m5d.2xlarge의 시간당 온디맨드 비용을 약 $0.5라 가정하면,

(노드 5대) × (시간당 0.5) × (1시간) = $2.50

2단계: Databricks 서비스 비용 (DBU)
Jobs Compute의 DBU 요율을 $0.15/DBU, m5d.2xlarge의 시간당 DBU 소모량을 8 DBU로 가정하면,

(노드 5대) × (시간당 8 DBU) × (DBU당 0.15) × (1시간) = $6.00

3단계: 총비용

총비용 (온디맨드 기준): $2.50 (AWS) + $6.00(Databricks) = $8.50

이 작업을 한 달(30일) 동안 매일 실행한다면 월간 비용은 약 $255가 됩니다. 여기서 Spot Instance를 적극 활용하면 AWS 비용이 크게 줄어 총비용을 30% 이상 절감할 수 있습니다. 어떤 종류의 작업을, 어떤 자원으로, 얼마나 쓰느냐에 따라 비용이 투명하게 결정되는 구조입니다.  (단, 인스턴스 유형, 리전, 요금제, Spot 활용 여부, 스토리지·네트워크 사용량 등에 따라 실제 비용은 달라질 수 있습니다.)

5. 결론: Databricks, 단순한 비용을 넘어 ‘가치’에 투자하는 것

Databricks는 단순히 여러 오픈소스를 모아놓은 플랫폼이 아닙니다. 델타 레이크라는 견고한 기반 위에, ‘Photon’이라는 강력한 엔진으로 무장한 최고 성능의 Spark를 얹고, 유니티 카탈로그라는 관제탑을 통해 모든 것을 통제하는 고도로 통합되고 최적화된 데이터 엔지니어링 플랫폼입니다.

초기 도입 비용이나 DBU 요금이 부담스럽게 느껴질 수도 있습니다. 하지만 복잡한 데이터 인프라를 직접 구축하고 운영하는 데 드는 막대한 ‘숨겨진 비용’과 ‘기회비용’을 고려한다면, Databricks는 오히려 합리적인 선택이 될 수 있습니다.