서비스 개발자를 위한 Databricks 입문

Databricks를 처음 살펴볼 때는 Spark 실행 환경과 SQL 분석, 권한 관리, 모델 API가 한꺼번에 등장해 무엇부터 알아야 할지 헷갈렸습니다. 서비스에서 발생한 데이터를 적재하고 다시 조회하는 과정을 기준으로 나눠 보니 각 기능의 역할을 이해하기 쉬웠습니다.

이 글에서는 데이터를 저장하고 정제한 뒤 앱에서 사용하는 흐름을 정리합니다. 제품 설명과 예시는 2026년 10월 AWS용 공식 문서를 기준으로 보완했습니다.

기존 빅데이터 도구와의 연결

예전에 다루던 빅데이터 환경에서는 저장, 처리, SQL, 워크플로와 권한을 여러 도구로 구성했습니다. Databricks에서도 이 역할 구분은 남아 있습니다. 다만 같은 플랫폼 안에서 데이터와 권한, 실행 환경을 연결해 제공합니다.

각 제품을 그대로 대체하는 대응표는 아닙니다. 기존 시스템도 저장과 분석을 연결할 수 있었고, Databricks로 옮긴다고 데이터 복제나 권한 관리 문제가 자동으로 없어지지는 않습니다.

Lakehouse와 데이터 흐름

Lakehouse는 데이터 레이크의 유연한 저장 방식과 웨어하우스의 테이블·분석 기능을 연결하는 접근입니다. Databricks에서는 오브젝트 스토리지의 데이터를 Delta 테이블로 관리하고, 처리와 SQL 분석에 활용하는 구성을 볼 수 있습니다.

그림은 데이터 처리 흐름을 단순화한 예시입니다. 실제로는 각 단계의 권한과 실행 자원, 재처리 범위를 함께 정해야 합니다. 분석용 테이블을 만들었다는 이유로 서비스의 트랜잭션 DB를 그대로 대체할 수 있는 것도 아닙니다.

Delta Lake의 테이블 관리

Delta Lake는 데이터 파일과 트랜잭션 로그를 이용해 테이블 변경을 관리합니다. ACID 트랜잭션과 스키마 검사, 이전 버전 조회 등을 제공하며 배치와 스트리밍에서 사용할 수 있습니다.

새 필드가 들어온다고 모든 스키마 변경을 자동으로 받아 주는 것은 아닙니다. 스키마를 언제 확장할지와 잘못된 데이터를 어떻게 처리할지 정해야 합니다. 이전 버전 조회도 로그와 데이터 파일의 보존 상태에 영향을 받으므로 영구 백업으로 생각하면 안 됩니다.

다음은 개념 확인용 SQL입니다. analytics.audit 카탈로그·스키마와 필요한 실행·생성 권한이 준비됐다고 가정합니다.

CREATE TABLE IF NOT EXISTS analytics.audit.events (
    event_id STRING,
    event_time TIMESTAMP,
    payload STRING
) USING DELTA;
 
SELECT date_trunc('DAY', event_time) AS event_date,
       count(*) AS event_count
FROM analytics.audit.events
GROUP BY 1
ORDER BY 1 DESC;

테이블 생성과 집계 예시이므로 실제 이벤트 적재는 포함하지 않습니다. 서비스에서 이 구조를 사용할 때는 중복 이벤트와 시간대, 누락과 재처리 기준도 추가로 정해야 합니다.

Unity Catalog의 자산과 권한

Unity Catalog에서는 테이블·뷰·볼륨·모델 같은 자산을 catalog.schema.object 이름으로 관리합니다. Workspace는 코드를 작성하고 작업을 실행하는 공간이고, Catalog는 데이터 자산과 권한을 구분하는 단위입니다.

테이블을 읽으려면 보통 해당 테이블의 SELECT 외에 상위 Catalog와 Schema의 사용 권한도 필요합니다. SQL warehouse에서 조회한다면 그 실행 자원에 접근할 권한도 별도입니다. 테이블 이름이 보이는 것과 데이터를 읽을 수 있는 것은 구분해야 합니다.

SQL·앱·모델 API의 구분

정제한 데이터는 SQL과 대시보드로 보거나 앱에서 조회할 수 있습니다. Databricks Apps는 이런 데이터를 사용하는 애플리케이션을 실행하는 환경이고, Model Serving은 모델을 추론 API로 제공하는 기능입니다. 모델 API를 호출하는 것과 SQL로 테이블을 읽는 것은 요청 형식과 권한이 다릅니다.

서비스 개발자가 먼저 정할 것은 어떤 데이터를 보내고, 어떤 주체가 결과를 읽고, 어느 응답 속도와 실패 처리가 필요한지입니다. 이 기준이 있어야 데이터 처리 작업과 앱의 역할을 나눌 수 있습니다.

다음 글에서는 Databricks Apps의 인증과 권한을 설명합니다.

참고 자료

• Databricks Lakehouse 개요 
• Delta Lake와 테이블 관리 
• 테이블 이력과 보존 조건 
• Unity Catalog 개요 
• Mosaic AI Model Serving