[Databricks] 무엇을 하는 플랫폼이고, 어떤 장점이 있을까? - 1편

Databricks는 데이터 수집·처리, SQL 분석, AI·ML 개발과 그 작업의 운영을 연결하는 데이터 플랫폼이다. 엔지니어가 데이터를 정제하고, 분석가가 SQL로 조회하고, 모델 개발자가 학습 데이터를 준비하는 일을 공통 데이터와 관리 체계 위에서 수행하도록 돕는다. Databricks 개요

데이터플랫폼 1편에서는 웨어하우스·레이크·레이크하우스·마트의 역할을, 2편에서는 여러 작업이 실행 관리와 권한 같은 운영 기능을 공유해야 하는 이유를 살펴봤다. 이번에는 그 기반을 Databricks로 구성하면 어떤 요소가 연결되고, 어떤 점이 편해지는지 알아본다.

설명은 2026년 10월 2일 확인한 Databricks on AWS 공식 문서를 기준으로 한다. 쇼핑몰 예시는 역할을 설명하기 위한 가상의 구성이다. 화면 조작에 앞서 제품의 구조를 이해하는 데 집중하며, 특정 실행 환경에서 측정한 성능이나 실습 결과를 다루지는 않는다.

Databricks에서 무엇을 만들고 운영할까

Databricks에 접속해 노트북을 만들고 Python 코드를 실행하는 장면만 보면, 클라우드에서 Spark를 실행하는 개발 도구처럼 보일 수 있다. 실제로는 노트북 밖에도 역할이 있다. 처리 결과를 테이블로 관리하고, SQL 사용자에게 제공하며, 누가 읽을지 정하고, 내일 같은 작업을 다시 실행하는 기능까지 연결한다.

그렇다고 Databricks라는 하나의 데이터베이스에 모든 원본을 넣어야 한다는 뜻은 아니다. 클라우드 스토리지의 파일과 원천 시스템에서 데이터를 가져와 필요한 형태로 처리한다. 데이터가 저장되는 위치와 코드를 실행하는 연산 자원은 구분된다. Databricks가 제공하는 환경에서 이 저장·처리·활용을 함께 운영하는 것이다. Databricks의 구조

이 글에서는 레이크하우스를 중심으로 구성해 보자. 레이크하우스는 레이크의 데이터에 테이블 관리와 분석 기능을 결합하는 구조이고, Databricks는 이 구조에서 엔지니어링·분석·모델 개발 작업을 수행할 환경을 제공한다.

주문 데이터 하나가 분석과 모델 개발에 쓰이기까지

앞 글의 쇼핑몰에는 주문·결제·환불 내역과 상품 클릭 이벤트가 있다. 상품팀은 날짜·상품 분류별 판매 현황을 보고 싶고, 모델 개발자는 고객의 조회·구매 이력으로 추천 모델에 넣을 입력값을 만들고 싶다.

예를 들어 주문을 추출한 파일과 클릭 JSON이 클라우드 스토리지에 도착한다고 하자. 다음처럼 작업을 구성할 수 있다.

상품팀과 모델 개발자가 같은 상세 테이블에서 출발하면, 원천 결제 내역을 각자 다시 해석할 필요가 줄어든다. 그렇다고 둘이 언제나 똑같은 최종 테이블을 읽는 것은 아니다. 날짜별 매출과 고객별 행동은 필요한 행의 단위가 다르므로 목적별 가공은 남는다.

이 도식은 이 글의 예시 구성을 직접 그린 것이다. 화살표는 데이터 처리·활용 흐름을 나타내며, 아래의 두 관리 기능은 데이터가 순서대로 통과하는 저장소가 아니다. 작업은 Lakeflow Jobs로 연결하고 데이터 접근은 Unity Catalog로 관리한다. AI 활용을 위해 추가한 리뷰 데이터와 Genie는 뒤의 AI 절에서 살펴본다.

화면, 연산, 테이블, 운영 기능의 역할 나누기

Workspace와 Notebook: 작업을 작성하고 함께 살펴보는 곳

Workspace는 노트북·쿼리·작업 같은 자산을 사용하고 협업하는 환경이다. 그 안의 Notebook에는 코드 셀과 설명, 실행 결과, 시각화를 함께 둘 수 있다. 주문상품 정제 코드를 작성하고 몇 행의 결과를 확인하는 데 쓰는 식이다. 노트북은 여러 사용자의 공동 편집도 지원한다. Workspace, Notebook

여기서 노트북 파일과 처리 결과 테이블을 구분해야 한다. 노트북은 무엇을 실행할지 담고, 테이블은 그 작업이 읽거나 저장하는 데이터다. 노트북 셀을 작성한 것만으로 데이터가 갱신되지는 않는다. 실제로 코드를 실행할 연산 자원이 필요하다.

Compute, Spark, Databricks SQL: 코드를 실제로 실행하는 쪽

Compute는 작업에 CPU·메모리 같은 자원을 제공하는 실행 환경이다. Apache Spark는 그 자원에서 큰 데이터를 나누어 처리하는 분석 엔진으로, Python의 PySpark나 SQL 등으로 변환을 작성할 수 있다. 이 예제에서는 Spark로 주문·환불을 조인하고 클릭 이벤트를 정제한다. Compute, Apache Spark

Databricks SQL은 SQL 분석과 BI를 위한 환경이다. 상품팀은 Spark 프로그램 전체를 알지 못해도 준비된 마트를 SQL로 조회할 수 있다. 이때 사용하는 SQL warehouse는 SQL 실행에 맞춘 연산 자원이다. 앞 글의 데이터 웨어하우스 전체나 테이블을 담는 폴더를 뜻하지 않는다. SQL warehouse

실행 자원을 사용하는 방식도 하나가 아니다. Serverless는 인프라의 준비·확장 관리를 서비스에 맡기는 방식이고, classic compute는 사용자가 설정하고 관리할 자원의 범위가 더 크다. AWS 기준 classic compute plane은 고객 AWS 계정에서, serverless compute plane은 Databricks가 관리하는 영역에서 동작한다. 구체적인 지원 기능은 선택한 compute와 워크스페이스·리전에 따라 확인해야 한다. 실행 영역의 차이

Spark는 독립적인 오픈 소스 프로젝트이며 Databricks 밖에서도 실행할 수 있다. Databricks의 가치는 엔진 제공에 더해 개발 환경, 테이블 관리, SQL 서비스와 운영 기능을 연결하는 데 있다. 두 이름을 같은 제품처럼 보지 않아야 역할이 분명해진다.

Delta Lake: 데이터 파일을 하나의 테이블 상태로 관리하기

Spark가 주문상품을 파일로 저장한 다음에는, 어떤 파일들을 현재 주문상품 테이블로 읽을지 정해야 한다. Delta Lake는 Parquet 데이터 파일에 트랜잭션 로그를 더해 테이블의 상태와 변경을 관리하는 오픈 소스 기술이다. 이 글의 정제 데이터와 마트는 Delta 테이블로 저장한다고 가정한다. Delta Lake

예를 들어 환불을 반영한 새 파일이 작성됐더라도 커밋되기 전까지는 현재 테이블의 변경으로 읽히지 않아야 한다. Delta의 트랜잭션과 스냅샷을 이용하면, 지원되는 읽기·쓰기 경로에서 조회가 일관된 테이블 상태를 사용하도록 관리할 수 있다. 동시에 쓰는 작업 사이에는 충돌이 발생할 수 있으며, 격리 수준과 사용 기능에 따라 처리가 달라진다. 동시 작업과 격리

Delta Lake가 쿼리를 계산하는 엔진이거나 작업 스케줄러인 것은 아니다. 파일과 테이블 상태의 관리 규칙을 제공하고, 엔진이 그 규칙에 맞춰 읽고 쓴다. 또한 Delta Lake 자체와 이를 통합한 Databricks 서비스의 기능 범위는 같지 않다. 다른 엔진에서 사용할 때는 지원하는 프로토콜·테이블 기능을 확인해야 한다.

Unity Catalog: 같은 이름과 권한 체계로 데이터 찾기

Unity Catalog는 테이블·뷰 같은 데이터 자산과 AI 자산의 접근 권한, 탐색, 계보 등을 관리한다. 앞의 상품팀 마트를 누가 읽을 수 있는지, 어떤 상세 데이터에서 만들어졌는지를 관리하는 역할이다. Unity Catalog

테이블은 catalog.schema.table이라는 세 단계 이름으로 참조한다. 예를 들어 shop.analytics.fact_order_item에서 shop은 catalog, analytics는 schema, 마지막이 테이블 이름이다. Catalog와 schema는 데이터 자산을 조직하는 이름 공간이다. 이 이름 자체를 실제 파일 경로로 해석하면 안 된다.

상품팀에는 마트 조회에 필요한 권한을 주고, 고객 식별 정보가 있는 상세 데이터에는 허용된 담당자만 접근하도록 구성할 수 있다. 계보 추적이 지원하는 작업에서는 원천부터 결과 테이블까지의 연결도 살펴볼 수 있다. 다만 원본 스토리지에 직접 접근하는 별도 경로가 있다면 그 권한까지 맞춰야 한다. 카탈로그에 등록하는 것만으로 모든 접근 경로와 외부 작업이 자동으로 통제·추적되는 것은 아니다.

Lakeflow Jobs: 만든 작업을 반복해서 운영하기

Lakeflow Jobs는 노트북 실행, SQL 작업 같은 task를 하나의 job으로 묶고 일정과 의존 관계를 관리한다. 정제 작업이 성공한 뒤 마트를 집계하고, 모델용 가공을 별도 후속 작업으로 실행하는 구성이 가능하다. 각 실행의 상태와 이력을 확인하며 운영한다. Lakeflow Jobs

여기서 Job은 작업을 언제 어떤 순서로 실행할지 관리하고, compute는 실제 코드를 실행한다. Job 자체가 데이터를 보관하는 테이블이거나 Spark를 대신하는 엔진은 아니다. 과거 날짜를 입력으로 받도록 코드를 작성해 두면 같은 작업을 재처리에 사용할 수 있지만, 중복 반영을 막는 로직은 별도로 설계해야 한다.

레이크하우스 아키텍처가 주는 강점

앞에서 나눈 구성 요소는 레이크하우스의 장점을 구현하는 데 연결된다. 다양한 원천 데이터를 보관하는 레이크의 기반에 신뢰할 수 있는 테이블 관리와 SQL 분석을 결합하고, 그 데이터를 AI·ML에서도 재사용하는 것이 핵심이다. Databricks는 여기에 권한과 작업 운영을 통합한다. 레이크하우스 구조

출처: Databricks, Intelligent Data Warehousing on Databricks. 제공받은 원본 이미지를 변경 없이 사용했다. 그림을 누르면 원본 크기로 볼 수 있다.

그림의 가운데 정제·마트 영역을 기준으로 보면, 위쪽의 데이터 엔지니어링과 AI/ML, 오른쪽의 SQL 조회·대시보드·Genie가 같은 데이터 기반에 연결돼 있다. 아래쪽의 저장 형식과 권한 관리, 위쪽의 실행 관리는 그 활용을 뒷받침한다. 모든 프로젝트가 그림의 단계를 전부 만들어야 한다는 뜻은 아니다. 쇼핑몰에서는 주문상품 상세 테이블과 상품팀 마트부터 시작해 추천용 데이터와 리뷰 분석을 붙여 갈 수 있다.

정제한 데이터를 BI와 AI에서 함께 사용한다

쇼핑몰에서 SQL 분석용 시스템과 모델 개발용 시스템에 주문 데이터를 따로 복사하면, 환불 반영 시각과 정제 로직을 양쪽에서 맞춰야 한다. Databricks에서 같은 정제 테이블을 읽도록 구성하면 이 공통 처리와 데이터 제공을 묶을 수 있다. 팀이 늘 때마다 원천 데이터부터 새 파이프라인을 만드는 수고를 줄이는 것이다.

효과가 생기려면 테이블의 의미와 갱신 기준을 공유해야 한다. 모델 학습에는 특정 시점의 고정된 데이터가 필요할 수 있고, 상품팀에는 최신 환불을 반영한 값이 필요할 수 있다. 공통 기반을 쓴다는 것은 모든 복사본과 목적별 테이블이 사라진다는 뜻이 아니다. 어떤 시점의 데이터를 사용할지도 각 작업에 맞게 정해야 한다.

파일 기반 저장에 테이블의 신뢰성을 더한다

클라우드 스토리지에 주문 파일과 클릭 JSON을 모아 두는 것만으로는 어떤 파일이 현재 테이블에 속하는지, 갱신 중인 데이터를 어떻게 읽을지가 정해지지 않는다. 레이크하우스는 이 저장 기반 위에 트랜잭션·스키마 관리 같은 기능을 더한다. 이 글에서는 Delta Lake가 그 역할을 맡는다.

환불 반영 작업이 여러 파일을 새로 쓰는 동안에도 조회는 커밋된 테이블 상태를 기준으로 수행할 수 있다. 입력 컬럼과 자료형이 테이블 규칙에 맞는지 검사하도록 구성하면 잘못된 형태의 데이터를 적재 단계에서 발견하는 데도 도움이 된다. 파일을 다양하게 보관하는 유연성을 유지하면서, 보고서가 읽을 테이블의 상태를 관리하는 것이다. 다만 자료형이 맞는다고 매출 계산까지 정확해지는 것은 아니므로 업무 규칙 검증은 따로 필요하다. Delta 테이블 관리

저장량과 처리량을 따로 늘릴 수 있다

쇼핑몰이 주문 이력 3년치를 보관한다고 해서, 그 전체 데이터를 매 순간 처리할 연산 자원을 계속 켜 둘 필요는 없다. 저장소와 compute를 분리하면 데이터는 유지하면서 야간 정제 작업에는 그 작업에 맞는 자원을, 낮의 상품팀 조회에는 SQL warehouse를 사용할 수 있다. 보관할 데이터의 양과 특정 시간에 필요한 처리 능력을 별도로 계획할 수 있다는 장점이다.

Delta Lake 같은 공개 테이블 형식과 Parquet 같은 파일 형식은 호환되는 다른 도구에서 데이터를 활용할 선택지도 넓혀 준다. 그림의 Open Storage는 이런 기반을 가리키며, Parquet는 파일 형식이고 Delta Lake·Iceberg는 테이블 형식이라는 차이가 있다. 모든 엔진이 모든 테이블 기능을 지원한다는 뜻은 아니다. 다른 도구와 연결할 때는 형식·프로토콜 지원, 권한과 데이터 이동 비용을 확인해야 한다. 저장·연산 분리와 개방형 형식도 Databricks만의 독점 기능은 아니다. Databricks 레이크하우스

SQL 사용자와 코드 작성자가 같은 데이터를 두고 협업한다

엔지니어가 노트북에서 정제한 테이블을 분석가가 SQL로 조회하면, 결과를 CSV로 내려받아 전달하는 단계를 줄일 수 있다. 모델 개발자도 권한이 있는 공통 데이터를 이용해 입력값을 가공할 수 있다. 노트북의 코드·설명·결과를 함께 살피면 변환 의도를 공유하기도 쉬워진다.

이 장점은 데이터 모델과 접근 권한이 갖춰졌을 때 성립한다. 같은 Workspace를 사용한다는 이유만으로 모든 사용자가 모든 테이블을 볼 수 있거나, 코드의 품질이 자동으로 맞춰지는 것은 아니다. 테이블 설명과 검수, 작업 배포 절차는 여전히 필요하다.

테이블 관리와 작업 운영을 연결한다

Delta Lake는 데이터를 갱신할 때 테이블 상태를 일관되게 관리하고, Jobs는 그 갱신 작업의 순서와 실행 상태를 관리한다. Unity Catalog는 작업이 다루는 데이터의 권한과 계보를 맡는다. 이 기능이 연결되면 데이터 파일 교체, 작업 실행, 사용자 접근을 각각 별도 도구로 연결해야 하는 수고를 줄일 수 있다.

그렇다고 세 기능이 하나의 문제를 모두 해결하는 것은 아니다. 트랜잭션이 있어도 매출 계산식이 잘못될 수 있고, 상세 테이블 갱신 뒤 마트 작업만 실패할 수도 있다. 테이블 상태의 일관성, 파이프라인의 완료, 업무 데이터의 정확성은 각각 확인해야 한다. Databricks는 이를 구현하고 운영할 기능을 제공하며, 조직에 맞는 처리·검증 기준은 사용자가 만든다.

이런 기능은 Databricks에만 있는 독점적인 개념은 아니다. 이 제품을 검토할 때의 핵심은 각 기능의 존재 여부에 더해, 실제 팀의 처리·분석·모델 개발 작업을 같은 기반에서 얼마나 수월하게 연결할 수 있는가다.

AI 기능으로 무엇을 할 수 있을까

Databricks의 AI 기능은 크게 두 방향으로 보면 이해하기 쉽다. 하나는 코드를 작성하거나 데이터를 질문하는 사용자의 작업을 돕는 AI이고, 다른 하나는 리뷰 분류나 예측처럼 데이터 처리·서비스에 AI를 적용하는 기능이다. 모델을 직접 학습하지 않고 사용하는 기능도 있다.

Genie: 코드 작성과 데이터 질문을 돕는다

현재 공식 문서에서 Genie는 여러 AI 사용 환경을 묶는 이름이다. 개발자용 Genie Code, 업무 데이터를 질문하는 Genie One, 질문에 사용할 데이터와 업무 규칙을 구성하는 Genie Agents를 구분한다. Genie 구성

엔지니어는 Genie Code에 주문상품 집계 코드 초안을 요청하거나 기존 코드의 의미와 오류를 설명해 달라고 할 수 있다. 상품팀 사용자는 준비된 Genie 환경에서 “지난주 잡화 판매 금액은 얼마인가?”처럼 자연어로 질문하는 활용을 생각할 수 있다. 코드 작성이나 SQL 문법을 익히는 부담을 줄이고, 데이터를 탐색하는 진입점을 넓히는 기능이다. Genie Code

이때 AI가 우리 쇼핑몰의 매출 기준을 저절로 아는 것은 아니다. 어떤 테이블을 사용하고 환불을 어떻게 반영할지 데이터와 지표·업무 규칙을 준비해야 한다. 생성한 코드와 쿼리, 답변이 그 기준에 맞는지도 확인한다. 단순 합계 질문에 답하는 것과 “왜 매출이 줄었는가”의 원인을 입증하는 것은 다른 문제다.

AI Functions: 리뷰를 분석 가능한 컬럼으로 바꾼다

쇼핑몰에 상품 리뷰가 추가됐다고 하자. SQL로 리뷰 수를 세기는 쉽지만, 내용이 배송·품질·가격 중 무엇에 관한 것인지 분류하려면 텍스트를 해석해야 한다. AI Functions는 SQL이나 노트북 등에서 AI를 호출해 이런 데이터를 변환하는 함수들이다. 예를 들어 ai_classify로 지정한 라벨에 따라 텍스트를 분류하거나 ai_summarize로 요약할 수 있다. AI Functions

리뷰에 topic 같은 분류 컬럼을 만들어 저장하면, 이후에는 상품별 배송 관련 리뷰 비중을 일반 SQL로 집계하고 판매 현황과 함께 볼 수 있다. 이 흐름의 결과는 채팅 답변에 그치지 않고, 다른 분석이 다시 사용할 수 있는 데이터가 된다. 다만 분류 결과는 예측이므로 표본을 검수하고 애매한 표현을 어떻게 다룰지 정해야 한다.

함수별 지원 모델·리전·실행 환경에는 조건이 있다. 예를 들어 확인 시점의 공식 문서에서는 Classic SQL warehouse에서 AI Functions를 지원하지 않는다. 함수를 실행하는 쿼리 연산 외에 모델 추론 비용이 발생할 수도 있어, 전체 리뷰에 반복 적용하기 전에 처리 범위와 결과 재사용 방식을 정해야 한다.

모델 개발과 운영: 추천·예측을 실제 작업으로 연결한다

자체 추천 모델을 만들려면 주문·클릭에서 학습 데이터를 준비하고, 여러 모델의 성능을 비교한 뒤 사용할 모델을 관리해야 한다. Databricks는 이 과정에 MLflow를 통합한다. MLflow로 실험의 설정·평가 지표·모델 같은 결과물을 기록하면, 어떤 학습 실행에서 나온 모델인지 비교하고 추적할 수 있다. Databricks의 MLflow

선택한 모델은 주기적으로 전체 고객의 추천 점수를 계산해 테이블에 저장하는 배치 작업에 사용할 수 있다. 요청마다 예측값을 반환해야 한다면 Model Serving으로 지원되는 모델을 호출 가능한 엔드포인트로 제공하는 방식도 있다. 예를 들어 서비스가 고객의 입력값을 보내고 예측 결과를 받아 사용하는 구조다. 데이터 준비, 학습, 예측 결과 제공까지 연결할 수 있다는 의미이며, 모델의 정확도나 추천 품질을 보장한다는 뜻은 아니다. Model Serving

이처럼 같은 쇼핑몰에서도 AI의 쓰임은 다르다. 엔지니어는 코드 작성을 보조받고, 상품팀은 자연어로 데이터를 질문하며, 리뷰는 분류된 분석 데이터가 되고, 모델 개발자는 추천 모델을 운영할 수 있다. Databricks의 데이터 관리·처리 기반을 AI의 입력과 결과 관리에도 활용한다는 점에서 앞서 살펴본 구성과 연결된다.

어떤 팀에 잘 맞고, 무엇이 남을까

정제 작업이 많고 SQL 분석과 모델 개발이 같은 상세 데이터를 반복해서 사용한다면 Databricks를 검토할 이유가 있다. 데이터 엔지니어와 분석가, 모델 개발자가 서로 다른 언어와 작업 방식을 쓰더라도 공통 테이블과 권한·실행 체계를 이용할 수 있기 때문이다.

반면 정해진 테이블 몇 개로 하루 한 번 보고서를 만드는 요구를 이미 잘 충족하고 있다면, 통합할 작업이 얼마나 있는지부터 살펴보는 편이 좋다. 기능이 넓다는 사실만으로 기존 구성보다 단순하거나 저렴해지는 것은 아니다. 선택한 실행 방식의 사용량, 저장과 데이터 이동, 운영 인력의 학습·관리 비용을 함께 봐야 한다.

도입 후에도 주문상품 한 행의 의미, 환불의 반영 기준, 중복 처리, 마트 제공 권한은 팀이 결정해야 한다. Databricks의 장점은 이러한 결정을 없애는 데 있지 않다. 결정한 규칙을 실행할 도구와 여러 작업이 재사용할 공통 환경을 제공한다는 데 있다.

다음 실습에서는 작은 주문 데이터를 노트북에서 테이블로 만들고 SQL로 조회하면서, 코드가 있는 곳·코드가 실행되는 곳·결과가 저장되는 곳이 어떻게 구분되는지 확인해 볼 수 있다.