Jobs & Workflows 운영: 스케줄링, CI/CD, 프로덕션 장애 대응
60 Databricks Interview Questions Senior DEs Actually Ask (2026) — 미상 (DataVidhya 블로그, 2026) Operations, Security & Scenarios, Q41-Q44 (pp.13-15) 및 beginner guide 'Jobs & Workflows in Databricks' (pp.12-13)
이 모듈을 다 읽으면
- Job과 Workflow의 차이, 그리고 트리거 종류(CRON/파일 도착/API 호출)를 설명할 수 있다
- Databricks Repos·Databricks Asset Bundles·Terraform이 CI/CD 파이프라인에서 각각 어떤 역할을 하는지 구분할 수 있다
- 프로덕션 파이프라인 장애가 발생했을 때 원인을 좁혀가는 표준적인 순서를 설명할 수 있다
Databricks에서 자동화는 Job(단일 자동 작업)과 Workflow(여러 태스크를 순서대로 잇는 체인)로 이뤄지며, CRON 스케줄·파일 도착·외부 API 호출 등 다양한 트리거로 실행된다. CI/CD는 Databricks Repos(Git 연동), Databricks Asset Bundles(코드·잡·클러스터 설정을 하나의 배포 단위로 묶는 CLI 도구), Terraform(인프라 as 코드)을 조합해 구성한다. 프로덕션 장애 시에는 로그 확인 → 클러스터 상태 확인 → 데이터 품질 확인 → 필요 시 Time Travel로 복구 → 재시도의 순서로 원인을 좁혀간다.
Job, Workflow, 트리거
Job은 노트북·SQL 쿼리·스크립트를 수동 개입 없이 실행하는 자동화된 작업이다. 매일 노트북을 여는 대신, 스스로 실행되도록 스케줄링해둔다. Workflow는 여러 태스크를 연결한 시퀀스로, 하나의 노트북만 실행하는 대신 `Notebook 1 → Notebook 2 → Notebook 3`처럼 여러 노트북을 순서대로 실행할 수 있다.
Job을 스케줄링할 때는 태스크(노트북, JAR, Python 파일)를 정의한 뒤 트리거를 구성한다. 트리거는 CRON 기반 스케줄일 수도 있고, 새 파일이 S3에 도착할 때 실행되는 'File Arrival' 트리거일 수도 있고, Airflow나 Azure Data Factory 같은 외부 도구에서의 API 호출일 수도 있다. 프로덕션에서는 격리된 환경과 낮은 DBU 비용을 위해 항상 잡을 'New Job Cluster'로 지정하는 것이 원칙이다.
핵심 포인트
- Job은 단일 자동화 작업, Workflow는 여러 태스크를 순서대로 잇는 체인이다
- 트리거는 CRON 스케줄, 파일 도착(File Arrival), 외부 도구(Airflow 등)의 API 호출 중 선택할 수 있다
- 프로덕션 잡은 격리와 비용 절감을 위해 'New Job Cluster'를 지정하는 것이 원칙이다
CI/CD 구성 요소
Databricks의 CI/CD는 보통 세 가지를 조합한다. Databricks Repos는 워크스페이스를 GitHub, GitLab 등 Git 프로바이더와 연결해, 브랜치 생성·커밋·PR·코드 리뷰·머지 같은 표준 소프트웨어 엔지니어링 관행을 노트북에 적용할 수 있게 한다. 이를 통해 프로덕션 잡이 특정 Git 태그나 브랜치의 코드를 실행하도록 구성하기 쉬워진다.
Databricks Asset Bundles(DABs)는 코드, 잡, 클러스터, 설정을 포함한 프로젝트 전체를 하나의 번들로 정의해, CLI로 Dev/QA/Prod 등 여러 환경에 배포할 수 있게 하는 도구다. Terraform은 Databricks Terraform provider를 통해 인프라를 코드로 관리해, 워크스페이스 설정과 클러스터 구성이 환경 전반에서 일관되게 유지되도록 한다.
핵심 포인트
- Databricks Repos는 Git 연동으로 브랜치·커밋·PR 같은 표준 워크플로우를 노트북에 적용한다
- Databricks Asset Bundles(DABs)는 코드·잡·클러스터 설정을 하나의 배포 단위로 묶어 여러 환경에 CLI로 배포한다
- Terraform은 인프라 as 코드로 워크스페이스·클러스터 설정의 환경 간 일관성을 보장한다
프로덕션 파이프라인 장애 대응 순서
원문이 제시하는 표준적인 대응 순서는 다음과 같다. 첫째, Jobs UI의 'Runs' 탭에서 에러 로그와 스택 트레이스를 확인한다. 둘째, 클러스터가 OOM(메모리 부족)으로 죽었는지, 혹은 클라우드 프로바이더의 스팟 인스턴스 선점(preemption)이 있었는지 클러스터 상태를 확인한다. 셋째, 코드 자체는 문제가 없다면 소스 데이터 형식이 예기치 않게 바뀌지 않았는지 데이터 품질을 확인한다(DLT/Lakeflow Pipelines의 Expectations나 Spark UI로 입력 레코드를 확인). 넷째, 데이터가 손상되었다면 Delta Time Travel로 마지막으로 정상이었던 상태로 테이블을 복구한다(`RESTORE TABLE ... TO VERSION AS OF ...`). 다섯째, 코드나 설정을 수정한 뒤 실패한 태스크에 대해 수동으로 'Retry' 또는 'Repair'를 실행한다.
이 순서는 '가장 확인 비용이 낮고 흔한 원인부터 좁혀나간다'는 일반적인 장애 대응 원칙을 그대로 따른다 — 로그(가장 빠름) → 인프라 상태 → 데이터 자체 → 복구 → 재실행 순으로, 각 단계에서 원인이 밝혀지면 다음 단계로 넘어가지 않고 바로 수정에 들어간다.
핵심 포인트
- 장애 대응은 '로그 확인 → 클러스터 상태 확인 → 데이터 품질 확인 → Time Travel로 복구 → 재시도'의 순서를 따른다
- 데이터가 손상된 경우 `RESTORE TABLE ... TO VERSION AS OF ...`로 마지막 정상 버전으로 되돌릴 수 있다
- 이 순서는 확인 비용이 낮고 흔한 원인부터 좁혀나가는 일반적인 장애 대응 원칙을 반영한다