Databricks 프로젝트의 비용 구조를 이 세 층으로 나누지 않으면 견적서가 뒤엉킨다.
| 층 | 항목 | 청구 주체 |
|---|---|---|
| A | Databricks 플랫폼 — DBU 소비량 | Databricks |
| B | 클라우드 인프라 — VM · 스토리지 · 네트워크 | CSP (AWS · Azure · GCP) |
| C | 구축 · 컨설팅 · 운영 용역 | 수행사 |
핵심은 청구서가 최소 두 장 나온다는 점이다. DBU 청구와 별개로 클라우드 사업자가 기반 컴퓨트 · 스토리지에 대해 따로 청구한다. 고객이 "얼마입니까" 라고 물을 때 한 숫자로 답할 수 없는 이유가 여기 있다.
VM · 관리형 스토리지 · 네트워크 전송 · 전용 연결(Private Link) 등. CSP 약정 할인(RI · Savings Plan) 반영 여부를 함께 적는다.
PoC 를 별도 단계로 떼어 두는 것이 안전하다. 설계 · 구축 · 마이그레이션 · 운영 · 교육으로 나눈다.
VAT 별도 표기, 환율 기준일, 견적 유효기간, 그리고 전제조건을 반드시 적는다. 소비 기반 과금이라 예상 DBU 의 산정 근거와 워크로드 규모 가정이 빠지면 나중에 근거를 댈 수 없다. 사용량은 초기 추정보다 크게 늘어나는 경우가 흔하므로 변동 가능성도 명시한다.
Azure Databricks 는 Azure 의 1st-party 서비스라 DBU 가 Azure 청구서에 통합된다.
AWS 는 그렇지 않다. 청구가 둘로 갈린다.
AWS Marketplace 를 통해 구매하면 DBU 비용이 AWS 청구서에 합쳐지고 AWS 약정 소진에도 잡힌다. 청구서를 한 장으로 줄이면서 이미 걸어 둔 AWS 약정을 채울 수 있어, AWS 기반 프로젝트에서는 이 경로를 먼저 검토할 만하다.
판단 기준은 하나다. A 와 B 를 누구 명의로 고객에게 청구할 것인가.
수행사가 MSP · 리셀러가 아니면 A 와 B 를 자기 명의로 재판매할 수 없다. 여기서 세 갈래가 나온다.
| 구조 | 내용 | 맞는 상황 |
|---|---|---|
| MSP 턴키 | MSP 가 A + B 의 계약 · 청구 · 정산을 맡고, 수행사는 C 만 담당 | 고객이 단일 계약 · 단일 청구서를 원할 때 |
| 고객 직접 계약 | 고객이 Databricks · CSP 와 직접 계약하고 수행사는 C 만 견적 | 자체 클라우드 계정과 조달 역량이 있는 대기업 · 공공 |
| 수행사 파트너 등록 | Databricks 파트너 + CSP 리셀러 등록 | 장기적으로 재판매까지 할 계획일 때. 단건 프로젝트에는 과하다 |
고객 직접 계약이라도 견적서에는 A · B 를 "고객 직접 부담(참고 추정치)" 으로 적어 총소유비용을 보여 주는 편이 제안 완성도가 높다.
구축만 하면 고객 계정 안에서 작업하고 끝나므로 MSP 가 필요 없다. 운영을 맡으면 계정의 비용 · 보안 · IAM 관리가 따라온다. 그래도 두 갈래다.
계약 형태가 미정이면 A · B 를 "고객 직접" 과 "MSP 경유" 두 시나리오로 병기한 모듈형 견적서를 낸다. 고객이 그 문서를 그대로 의사결정 자료로 쓸 수 있다.
운영 범위에 FinOps 를 명시하면 "운영을 맡기면 비용이 준다" 는 근거가 생긴다. Databricks 에서 낭비가 가장 큰 곳은 정해져 있다.
자동 종료 설정률과 클러스터 적정화를 운영 KPI 로 제시한다. 실제 DBU 단가는 워크로드 · 리전 · 서버리스 여부 · 약정에 따라 달라지므로 숫자는 공식 가격 페이지의 계산기로 산정한다.