Databricks 비용 최적화 2026, DBU·태그·예산 경보 운영 기준

Databricks 비용 최적화를 위한 DBU 사용량 분석과 데이터 플랫폼 비용 회의 장면 — Databricks 예산은 DBU 사용량, list price, 태그, 컴퓨트 정책을 같은 화면에서 봐야 흔들리지 않는다.

Databricks 비용 최적화를 검색하는 팀은 대개 월말 청구서보다 늦게 문제를 발견한다.

노트북은 꺼지지 않았고, Jobs는 같은 데이터를 다시 계산했으며, 태그가 비어 있어 어느 팀 비용인지 설명하기 어렵다.

이 글은 Databricks를 더 싸게 보이게 만드는 요령이 아니라 DBU, list price, 태그, 예산 경보를 운영 절차로 묶는 기준이다.

이 글의 billing 표기는 Databricks 비용 시스템 테이블 이름이며, LLM API 입력·출력 토큰 단가 비교가 아니라 DBU와 USD list price 관리 글이다.

핵심 요약

Databricks 비용은 사용량 테이블, SKU list price, custom tag, 예산 threshold를 함께 봐야 팀별 책임이 생긴다.
공식 문서 기준 system.billing.usage는 DBU 사용량과 SKU, workspace, identity, custom tag를 비용 분석의 출발점으로 제공한다.
서버리스 노트북은 기본 실행 timeout이 2.5시간, 즉 9,000초라서 장시간 쿼리 방지 정책을 초반부터 정해야 한다.
예산 경보는 최대 4개 공유 threshold와 최대 1,000개 budget 제한을 고려해 계정, workspace, team 단위로 나눠야 한다.

이 글이 필요한 사람

Databricks 비용이 늘었지만 어떤 workspace와 job이 원인인지 바로 설명하기 어려운 데이터 플랫폼 팀
DBU 사용량과 클라우드 인프라 비용을 분리해서 chargeback 모델을 만들어야 하는 FinOps 담당자
서버리스 노트북, SQL warehouse, Jobs, Lakeflow pipeline 비용을 같은 기준으로 보고 싶은 데이터 엔지니어
compute policy, custom tag, budget alert를 도입했지만 실제 운영 규칙이 느슨한 workspace 관리자
Snowflake, BigQuery, Databricks 같은 관리형 데이터 플랫폼 비용을 구매 전에 비교해야 하는 의사결정자

공식 비용 팩트부터 고정한다

Databricks 가격 페이지는 SKU별 undiscounted list price를 기준으로 가격표를 제공한다고 설명한다.

조직별 할인과 credit은 별도일 수 있으므로 운영 대시보드는 실제 계약 금액과 list price 차이를 나눠서 봐야 한다.

Databricks 문서는 비용을 usage table과 list_prices table로 연결해 Total Dollar Cost를 계산하는 예시를 제시한다.

공식 항목	확인한 숫자·단위	운영 해석	담당자 질문
list price	SKU별 undiscounted list price	할인 전 기준으로 팀별 비교선을 만든다	계약 할인과 credit을 별도 열로 보나
system.billing.usage	usage_quantity 예시 259.2958 DBU	실제 사용량은 SKU와 workspace별로 모은다	DBU가 어느 job과 owner에 붙나
list_prices join	usage_quantity × effective_list.default = USD 비용	고정 단가를 수기로 쓰지 않고 시점별 가격을 조인한다	price_start_time과 price_end_time을 반영하나
serverless timeout	기본 2.5시간, 9,000초	노트북 runaway query를 timeout으로 막는다	workspace 기본값과 예외 승인 흐름이 있나
timeout 반영	설정 변경 전파 약 5분	변경 직후 테스트 쿼리로 적용 여부를 본다	운영 공지와 테스트 시간이 잡혔나
budget threshold	공유 threshold 최대 4개	월 50%, 80%, 100%, 120% 같은 계단을 만든다	받는 사람과 조치 owner가 있나
budget 수	계정당 최대 1,000개	팀·프로젝트별 쪼개기는 과도하게 늘리지 않는다	budget naming과 tag 표준이 있나
alert 지연	일반 예산 알림 최대 24시간 지연 가능	실시간 차단 장치로 오해하지 않는다	일일 점검 쿼리가 별도로 있나

이 조건이면 비용 최적화의 첫 작업은 인스턴스 크기 조정이 아니다.

먼저 owner, project, env 태그가 비어 있는 사용량을 없애고 budget threshold를 실제 조치 owner에게 연결해야 한다.

Databricks 비용은 네 묶음으로 나눠 본다

Databricks 비용은 단일 월정액처럼 보지 않는 편이 안전하다.

interactive notebook, job compute, SQL warehouse, serverless workload가 서로 다른 사용 패턴과 owner를 갖기 때문이다.

비용 묶음	주요 신호	낭비 패턴	최적화 기준
Notebook	사용자, notebook, serverless timeout, query history	분석 후 세션 방치와 큰 데이터 scan 반복	timeout, personal compute, review 대상 query profile
Jobs	job_id, job_name, run_name, task_key, schedule	같은 테이블 재계산과 실패 retry 폭증	incremental 처리, retry 제한, job owner 태그
SQL warehouse	warehouse_id, dashboard, query history	작은 대시보드에 과한 warehouse와 idle 시간	auto stop, warehouse sizing, dashboard refresh 주기
Lakeflow pipeline	dlt_pipeline_id, update_id, materialized view	full refresh 남발과 maintenance 비용 증가	update window, table별 DBU 추적, pipeline owner
Model serving·AI workload	endpoint, serving workload, per-user budget	테스트 endpoint 상시 노출과 실험별 비용 분리 실패	별도 budget, endpoint tag, offline batch 대체 검토

이 경우는 단순히 더 작은 compute로 바꾸면 장애가 난다.

월말 비용은 줄어도 데이터 처리 시간이 길어져 SLA와 downstream job 실패가 늘어나는 경우다.

반대로 분석 노트북과 임시 dashboard가 대부분이면 timeout과 자동 종료가 가장 빠른 절감점이 된다.

태그 없이는 비용 최적화가 아니라 추측이 된다

Databricks 문서는 custom tag가 compute resource와 serverless workload의 비용 추적, reporting, budgeting에 쓰인다고 설명한다.

태그는 팀 이름을 보기 좋게 붙이는 장식이 아니라 예산 책임을 나누는 최소 단위다.

다만 Databricks는 tag data가 plain text로 저장되고 전역 복제될 수 있다고 경고한다.

그래서 project, env, cost_center처럼 운영에 필요한 값만 쓰고 개인정보나 민감한 식별자는 넣지 않는다.

태그 키	권장 값	비용 질문	보안 주의
team	data-platform, ml, analytics	어느 팀이 월 비용을 만들었나	실명이나 이메일을 값으로 넣지 않는다
project	billing-mart, churn-model	어떤 제품·과제가 비용을 썼나	고객명이나 계약명을 그대로 쓰지 않는다
env	dev, staging, prod	비운영 환경이 과하게 쓰나	prod 혼동을 막기 위해 allowlist를 둔다
owner	group alias	알림과 조치를 누가 받나	개인 이메일 대신 그룹 alias를 쓴다
data_class	public, internal, restricted	민감 데이터 workload가 비용과 분리되나	민감한 세부 내용은 태그값에 쓰지 않는다

이 조건이면 태그를 optional로 두면 안 된다.

프로젝트별 chargeback을 하거나, 예산 초과 알림을 팀별로 나눠야 하거나, production workload만 따로 보호해야 하는 경우다.

compute policy는 비용 상한과 권한 상한을 같이 다룬다

Databricks compute policy는 사용자가 만들 수 있는 compute 설정을 제한하는 workspace admin 도구다.

공식 문서는 policy가 per-cluster maximum cost에 기여하는 속성 제한, max DBUs per hour, 사용자별 compute 수 제한에 쓰일 수 있다고 설명한다.

중요한 점은 policy가 이미 떠 있는 초과 compute를 자동 종료하지 않는다는 사실이다.

관리자가 limit을 1개로 줄여도 사용자가 3개 compute를 이미 실행 중이면 추가 리소스는 수동으로 정리해야 한다.

정책 항목	낮은 위험 설정	높은 위험 설정	운영 확인
max DBUs per hour	업무 유형별 상한을 둔다	Unrestricted compute를 기본으로 둔다	상한 초과 요청은 승인 기록을 남긴다
max resources per user	분석가와 job owner를 나눈다	모든 사용자에게 무제한 생성 권한을 준다	idle compute 정리 리포트를 본다
policy family	Personal, shared, jobs 용도를 분리한다	하나의 정책으로 모든 업무를 처리한다	정책별 adoption을 월간 확인한다
libraries	정책에 허용 library를 붙인다	init script와 compute-scoped library를 방치한다	최대 500개 library 제한을 넘지 않는다
tags	team, project, env를 필수화한다	tag 없는 compute를 허용한다	비어 있는 tag는 생성 실패로 처리한다

이 경우는 강한 policy를 먼저 넣지 않는다.

ML Runtime, GPU, RDD, legacy library가 얽힌 workload를 충분히 inventory하지 않은 상태에서 상한만 낮추는 경우다.

먼저 2주 정도 usage table과 query history로 실제 workload를 보고 pilot policy를 만든다.

서버리스 노트북 비용은 timeout과 예외 승인으로 막는다

Databricks 서버리스 노트북은 기본 실행 timeout이 2.5시간이다.

문서 기준으로 9,000초를 넘는 query는 취소되며, workspace admin은 Settings > Compute의 Serverless interactive 설정에서 기본값을 바꿀 수 있다.

개별 notebook은 spark.databricks.execution.timeout 설정으로 workspace 기본값을 override할 수 있다.

따라서 비용 최적화 정책은 단순히 짧은 timeout을 강제하는 문장이 아니라 예외 승인과 검증 방법까지 포함해야 한다.

상황	기본 판단	예외 허용 조건	검증
임시 탐색 분석	2.5시간 기본 timeout 유지	대용량 scan 사전 승인	query profile과 scanned data 확인
정기 ETL 전환 전 노트북	Jobs로 옮기는 일정 지정	전환 기간만 override	job_id와 notebook owner 연결
모델 feature 생성	serverless와 jobs 비용 비교	재사용 feature table 설계	월별 DBU와 output table 크기 확인
대시보드 refresh	SQL warehouse 정책 우선	임시 분석만 serverless 허용	refresh 주기와 idle 시간 확인
교육·실습 workspace	짧은 timeout과 작은 budget	강사 승인 시만 확대	untagged usage 0건 확인

이 조건이면 서버리스가 더 낫다.

사용자가 compute 설정을 잘 모르고, 짧은 분석을 자주 실행하며, admin이 workload별 정책보다 안전한 기본값을 원할 때다.

반대로 장시간 batch와 반복 schedule이 핵심이면 Jobs compute나 Lakeflow pipeline으로 옮겨 owner와 schedule을 고정한다.

실무 순서: 월말 보고서가 아니라 매일 보는 비용 운영으로 바꾼다

Databricks 비용 최적화의 실무 순서는 인스턴스 스펙 조정부터 시작하지 않는다.

가장 먼저 비용을 만든 주체를 식별하고, 그 다음에 경보와 정책으로 재발을 막는다.

system table 접근 권한을 가진 account admin 또는 workspace admin owner를 정한다.
team, project, env, owner 태그 표준을 만들고 개인정보가 들어가지 않도록 금지어를 정한다.
compute policy에서 필수 태그와 max DBUs per hour, 사용자별 compute 수 제한을 pilot workspace에 먼저 적용한다.
system.billing.usage와 system.billing.list_prices를 조인해 월별 USD 추정 비용을 팀·프로젝트·SKU별로 본다.
예산은 계정 전체와 workspace, 주요 project 단위로 나누고 최대 4개 shared threshold를 초과하지 않게 설계한다.
서버리스 노트북 timeout은 기본 2.5시간을 기준으로 두고 예외 notebook은 owner와 만료일을 붙인다.
상위 10개 SKU와 상위 10개 job을 매일 확인하고, 20% 이상 증가한 항목은 owner에게 ticket을 만든다.
월말에는 list price 기준 비용, 계약 할인 반영 비용, 실제 cloud infrastructure 비용을 서로 다른 열로 보여준다.

이 순서를 지키면 Databricks 비용 최적화가 “누가 많이 썼다”는 비난으로 흐르지 않는다.

대신 어떤 workload가 어떤 business value를 위해 어느 SKU를 썼는지 설명할 수 있다.

실무 시나리오 1: 데이터 마트 팀의 DBU 급증

데이터 마트 팀이 매일 새벽 전체 테이블을 다시 계산하면서 월 DBU가 갑자기 늘었다고 가정하자.

처음 볼 것은 cluster 크기가 아니라 job_id, job_name, output table, incremental 처리 여부다.

usage table에서 job_id별 DBU를 보고, query history에서 같은 scan이 반복되는지 확인한다.

이 조건이면 작은 compute로 줄이는 것보다 partition pruning, incremental load, materialized view 갱신 범위 조정이 먼저다.

job owner 태그가 비어 있으면 다음 달에도 같은 문제가 반복된다.

실무 시나리오 2: 분석가 노트북이 예산을 갉아먹는 경우

분석가가 큰 테이블을 탐색하다가 notebook을 닫지 않고 퇴근하는 상황은 흔하다.

서버리스 기본 timeout 2.5시간은 이런 낭비를 막는 1차 안전장치다.

다만 timeout만 낮추면 정당한 장기 분석까지 취소될 수 있다.

이 조건이면 예외 override를 허용하되 owner, 목적, 만료일, 예상 USD를 budget ticket에 남겨야 한다.

반대로 반복 분석이면 notebook이 아니라 scheduled job이나 dashboard refresh로 옮겨야 한다.

실무 시나리오 3: SQL warehouse와 dashboard 비용

대시보드가 많아지면 사람은 보지 않는데 warehouse가 계속 깨어 있는 문제가 생긴다.

이때는 dashboard별 refresh 주기, warehouse idle 시간, 사용자가 실제로 보는 시간대를 함께 본다.

이 조건이면 모든 dashboard를 실시간처럼 새로고침할 필요가 없다.

영업 오전 회의용 dashboard는 출근 전 1회, 운영 지표 dashboard는 짧은 주기, 실험용 dashboard는 수동 refresh로 나누는 편이 낫다.

비용 절감은 refresh 주기와 warehouse 크기를 같이 바꿀 때 실효성이 생긴다.

보안과 거버넌스 리스크를 비용표에 같이 넣는다

Databricks 비용 최적화는 보안과 분리하면 오래가지 않는다.

태그값에 개인정보를 넣거나, unrestricted compute를 넓게 열거나, init script와 library drift를 방치하면 비용 절감보다 감사 리스크가 커진다.

Unity Catalog, workspace 권한, compute policy, tag 표준은 비용과 보안을 동시에 잡는 장치다.

리스크	비용 영향	보안 영향	대응
untagged compute	owner 불명 비용이 누적된다	책임자 없는 데이터 접근이 남는다	필수 tag policy와 예외 승인
unrestricted policy	대형 compute가 쉽게 생성된다	권한 과다와 library drift가 생긴다	업무별 policy family와 상한
장시간 notebook	idle과 runaway query 비용이 는다	임시 결과와 민감 데이터가 방치된다	timeout, query profile, 정리 ticket
과도한 dashboard refresh	SQL warehouse 사용량이 오른다	불필요한 데이터 노출면이 늘어난다	refresh tier와 viewer 기준 정리
민감한 tag 값	비용 보고서 공유가 어려워진다	plain text tag 복제 리스크가 생긴다	tag 값 allowlist와 금지어 검사

이 조건이면 비용 절감보다 governance 정리가 우선이다.

어떤 데이터가 어느 workspace에서 누가 실행한 compute로 처리되는지 설명할 수 없는 경우다.

실무 스켈레톤: 비용 attribution SQL

아래 SQL은 Databricks 공식 문서의 usage table과 list price join 흐름을 운영 보고서 형태로 바꾼 예시다.

-- Databricks cost attribution query skeleton
-- 목적: SKU별 DBU 사용량을 list price와 연결해 팀별 월 비용을 본다.
-- 실제 실행 전에는 권한, 카탈로그 접근, 태그 키, 월 범위를 조직 기준에 맞춘다.

SELECT
  usage.custom_tags['team'] AS team,
  usage.custom_tags['project'] AS project,
  usage.sku_name,
  usage.usage_unit,
  SUM(usage.usage_quantity) AS usage_qty,
  SUM(usage.usage_quantity * prices.pricing.effective_list.default) AS estimated_usd
FROM system.billing.usage AS usage
JOIN system.billing.list_prices AS prices
  ON prices.sku_name = usage.sku_name
WHERE usage.usage_date BETWEEN DATE '2026-07-01' AND DATE '2026-07-31'
  AND usage.usage_end_time >= prices.price_start_time
  AND (prices.price_end_time IS NULL OR usage.usage_end_time < prices.price_end_time)
GROUP BY usage.custom_tags['team'], usage.custom_tags['project'], usage.sku_name, usage.usage_unit
ORDER BY estimated_usd DESC;

핵심은 SKU별 사용량을 수기로 계산하지 않고, 사용 시점에 유효한 list price와 조인하는 것이다.

이 결과는 실제 계약 할인과 credit을 반영하기 전의 내부 비교선으로 쓰는 편이 안전하다.

정책 템플릿: 태그와 timeout을 같은 파일에 둔다

아래 JSON은 실제 Databricks 정책을 그대로 복사하라는 뜻이 아니라 FinOps 정책 검토용 스켈레톤이다.

{
  "policy_name": "finops-shared-compute",
  "owner": "data-platform",
  "required_tags": {
    "team": "fixed-or-allowlist",
    "project": "required",
    "env": "dev-staging-prod"
  },
  "cost_controls": {
    "max_dbus_per_hour": "workspace_admin_defined",
    "auto_termination_minutes": 20,
    "serverless_notebook_timeout_seconds": 9000,
    "allow_unrestricted_compute": false
  },
  "review_cadence": {
    "daily": ["runaway_jobs", "untagged_usage", "serverless_timeout_exceptions"],
    "weekly": ["top_sku_growth", "policy_compliance", "budget_thresholds"],
    "monthly": ["team_chargeback", "sku_mix", "discount_gap_review"]
  }
}

workspace admin은 이 스켈레톤을 바탕으로 실제 policy definition, budget, owner 알림 흐름을 나눠 구현한다.

정책 변경 후 기존 compute가 자동으로 고쳐진다고 가정하지 말고 compliance 목록을 따로 확인한다.

검증 스크립트: 월별 CSV로 예산 초과 후보 찾기

아래 Python은 SQL 결과를 CSV로 받아 owner 없는 비용과 threshold 초과 팀을 찾는 검증용 스켈레톤이다.

#!/usr/bin/env python3
# databricks_cost_guardrail.py
# 목적: system table query 결과 CSV를 받아 예산 초과 후보를 찾는 검증용 스켈레톤이다.
# 실제 알림 전송과 차단은 조직 승인 절차를 붙인 뒤 연결한다.

import csv
from decimal import Decimal

MONTHLY_LIMIT_USD = Decimal("5000")
TEAM_LIMIT_USD = Decimal("1200")

by_team = {}
with open("databricks_monthly_cost.csv", newline="") as f:
    for row in csv.DictReader(f):
        team = row.get("team") or "untagged"
        by_team[team] = by_team.get(team, Decimal("0")) + Decimal(row["estimated_usd"])

total = sum(by_team.values(), Decimal("0"))
if total > MONTHLY_LIMIT_USD:
    print("account_budget_warning", total)

for team, amount in sorted(by_team.items(), key=lambda x: x[1], reverse=True):
    if team == "untagged" or amount > TEAM_LIMIT_USD:
        print("review_required", team, amount)

실제 운영에서는 이 출력만으로 compute를 끄지 않는다.

먼저 owner에게 workload 목적, business impact, 다음 달 예상 사용량을 확인한 뒤 policy나 schedule을 고친다.

도입 전 체크리스트

Databricks pricing page와 계약서를 나눠 list price, 할인, credit, cloud infrastructure 비용을 구분한다.
system.billing.usage 접근 권한과 보존 범위를 account admin이 확인한다.
팀·프로젝트·환경 태그 표준을 만들고 tag data에 개인정보를 넣지 않는 규칙을 문서화한다.
compute policy에서 max DBUs per hour, max resources per user, 필수 tag를 pilot으로 건다.
서버리스 notebook timeout 2.5시간 기준을 유지할지 줄일지 workload별로 정한다.
budget threshold는 4개 제한을 고려해 월 50%, 80%, 100%, 120%처럼 단순하게 둔다.
budget alert가 최대 24시간 늦을 수 있으므로 runaway job 탐지는 매일 query로 따로 본다.
상위 비용 job은 owner, schedule, input table, output table, retry 정책을 같이 점검한다.
SQL warehouse는 dashboard refresh 주기와 실제 viewer 수를 기준으로 크기와 자동 종료를 조정한다.
월간 리뷰에는 절감액뿐 아니라 실패 job, 지연된 pipeline, 보안 예외, untagged 비용을 함께 넣는다.

자주 묻는 질문

Databricks 비용 최적화는 어디서 시작해야 하나요?

먼저 system.billing.usage에서 SKU, workspace, job, custom tag별 DBU 사용량을 보고 owner 없는 비용을 제거하는 작업부터 시작하는 편이 안전합니다.

Databricks list price와 실제 계약 비용은 같은가요?

아닐 수 있으므로 공식 list price는 내부 비교선으로 쓰고, 할인·credit·계약 조건은 별도 열로 관리해야 합니다.

서버리스 노트북 timeout 2.5시간을 줄이면 바로 비용이 줄까요?

짧은 탐색 workload에는 효과가 있지만 장시간 정당한 분석까지 취소될 수 있으므로 예외 승인과 query profile 검증을 함께 둬야 합니다.

custom tag는 어느 정도까지 강제해야 하나요?

team, project, env, owner 정도는 필수화하되 개인정보나 고객 식별자를 tag 값에 넣지 않도록 allowlist와 금지어를 같이 둬야 합니다.

budget alert만 있으면 runaway job을 막을 수 있나요?

일반 budget alert는 최대 24시간 늦을 수 있으므로 상위 job과 사용량 급증은 매일 system table query로 별도 점검해야 합니다.

compute policy를 강하게 걸면 모든 비용 문제가 해결되나요?

아니요, 기존 compute는 자동 종료되지 않을 수 있고 workload별 예외가 있으므로 policy adoption, compliance, 수동 정리 절차를 같이 운영해야 합니다.

출처와 확인일

Databricks — Databricks pricing and SKU list price notice (확인일: 2026-07-27)
Databricks Docs — Cost management tools on Databricks (확인일: 2026-07-27)
Databricks Docs — Monitor costs using system tables (확인일: 2026-07-27)
Databricks Docs — Billable usage system table reference (확인일: 2026-07-27)
Databricks Docs — Create and monitor budgets (확인일: 2026-07-27)
Databricks Docs — Use tags to attribute and track usage (확인일: 2026-07-27)
Databricks Docs — Create and manage compute policies (확인일: 2026-07-27)
Databricks Docs — Serverless compute for notebooks overspend protection (확인일: 2026-07-27)
Databricks Docs — Classic compute configuration best practices (확인일: 2026-07-27)
Databricks Docs — Compute configuration reference (확인일: 2026-07-27)

위 출처는 2026-07-27 기준으로 확인했으며, Databricks SKU, list price, serverless 기능, budget 제한, compute policy UI와 권한은 cloud, region, workspace 설정, 계약 조건에 따라 달라질 수 있습니다.

이 글은 일반적인 데이터 플랫폼 비용 운영 검토 자료이며, 실제 예산 집행, 계약 할인, 개인정보 처리, 보안 정책은 공식 문서와 조직 내부 책임자 검토를 기준으로 최종 확인해야 합니다.

Tech in Depth tnals1569@gmail.com

피드백 보내기

이글루 홈캠 vs 파인뷰 홈캠 비교: 화각, 보안, 가격까지 완벽 분석하기

- 8월 29, 2025

글 읽기

이 블로그 검색