Skip to main content

​
이 문서에서 다루는 내용

대규모 조직에서 Databricks 플랫폼을 안전하고 체계적으로 운영하기 위한 거버넌스 전략을 다룹니다. 플랫폼 아키텍처 설계부터 접근 제어, 데이터 분류, 감사/컴플라이언스, 데이터 품질 관리, CI/CD 자동화까지 엔터프라이즈 수준의 모범 사례를 제공합니다.

​
1. 플랫폼 설계

​
1.1 Workspace 분리 전략

Workspace를 어떻게 분리하느냐에 따라 보안, 비용 관리, 운영 효율성이 결정됩니다.
전략구조장점단점적합한 조직
환경별 분리Dev / Staging / Prod환경 간 완전 격리, 규제 충족 용이Workspace 수 증가규제 산업 (금융, 의료)
팀별 분리DE / DS / Analytics팀별 독립 운영, 비용 추적 용이크로스팀 협업 어려움팀 간 독립성 높은 조직
하이브리드환경 × 팀 매트릭스최대 유연성관리 복잡도 높음대기업 (1000+ 사용자)
단일 Workspace하나의 Workspace관리 단순, Unity Catalog로 격리규모 확장 시 한계스타트업, 소규모 팀
💡 권장 패턴: 대부분의 엔터프라이즈는 환경별 분리 (Dev/Staging/Prod) 를 기본으로 하되, Unity Catalog의 카탈로그 수준에서 팀/프로젝트를 분리하는 방식이 효과적입니다.
수준구성
Unity Catalog MetastoreAccount 수준 - 모든 Workspace에서 공유
Dev Workspace개발팀 자유 실험, 느슨한 정책
Staging Workspace통합 테스트, 프로덕션과 유사한 정책
Prod Workspace엄격한 접근 제어, 감사 로그 필수

​
1.2 Unity Catalog 네임스페이스 설계

3단계 네임스페이스: catalog.schema.table
수준명명 규칙예시용도
Catalog{환경}_{도메인} 또는 {환경}prod_sales, dev_hr환경 + 비즈니스 도메인 격리
Schema{데이터 계층} 또는 {팀}bronze, silver, goldMedallion 계층 또는 팀 분리
Table{엔티티}_{설명}orders_daily, customers_dim비즈니스 엔티티
명명 규칙 표준안 
-- 카탈로그 명명 패턴
-- 패턴 1: 환경 중심 (소규모 조직)
-- prod / dev / staging

-- 패턴 2: 환경 + 도메인 (중대형 조직, 권장)
-- prod_sales / prod_marketing / dev_sales / dev_marketing

-- 패턴 3: 도메인 중심 (데이터 메시 구조)
-- sales / marketing / finance (환경은 Workspace로 분리)

-- 스키마 명명: Medallion 계층
CREATE SCHEMA prod_sales.bronze;    -- 원본 데이터
CREATE SCHEMA prod_sales.silver;    -- 정제된 데이터
CREATE SCHEMA prod_sales.gold;      -- 비즈니스 집계
CREATE SCHEMA prod_sales.sandbox;   -- 개발/실험용

-- 테이블 명명 규칙
-- {엔티티}_{유형}: orders_fact, customers_dim, daily_revenue_agg
-- 접미사: _fact (팩트), _dim (디멘션), _agg (집계), _raw (원본)

​
1.3 멀티 클라우드 / 멀티 리전 거버넌스

고려사항전략구현 방법
데이터 주권리전별 Metastore 분리리전별 Unity Catalog Metastore 생성
크로스 리전 공유Delta Sharing리전 간 데이터를 복제 없이 공유
통합 거버넌스Account 수준 관리Account Console에서 전체 Workspace 관리
재해 복구멀티 리전 복제핵심 데이터를 다른 리전에 비동기 복제
⚠️ 주의: Unity Catalog의 리니지(Lineage)와 접근 제어는 동일 Metastore 내에서만 작동합니다. 크로스 Metastore 데이터 공유 시에는 Delta Sharing을 사용하며, 리니지 추적이 단절될 수 있습니다.

​
2. Workspace 분리 전략 상세

​
2.1 환경별 분리 (Dev / Staging / Prod)

가장 일반적인 패턴으로, 소프트웨어 개발 생명주기(SDLC)에 맞춰 Workspace를 분리합니다.
Workspace용도접근 정책클러스터 정책비용 관리
Dev개발, 실험, PoC개발자 전원 접근 허용Single Node 권장, GPU 제한예산 상한 설정 (태그 기반)
Staging통합 테스트, UATCI/CD Service Principal + QA 팀Prod와 동일한 정책 (축소 스케일)Dev 대비 30~50% 예산
Prod프로덕션 워크로드Service Principal 중심, 개인 접근 최소화엄격한 Compute PolicySLA 기반 예산
[환경별 분리 아키텍처]

Account Console (단일 관리 포인트)
  ├── Unity Catalog Metastore (공유)
  │     ├── dev 카탈로그     ← Dev Workspace에서만 접근
  │     ├── staging 카탈로그  ← Staging Workspace에서만 접근
  │     └── prod 카탈로그    ← Prod Workspace에서만 접근
  │
  ├── Dev Workspace
  │     ├── 개발자 그룹 (자유 실험)
  │     └── 클러스터: Single Node, Auto-stop 10분
  │
  ├── Staging Workspace
  │     ├── CI/CD Service Principal
  │     └── 클러스터: Prod 축소 스케일
  │
  └── Prod Workspace
        ├── Service Principal (워크로드 실행)
        ├── 관리자 그룹 (최소 인원)
        └── 클러스터: 엄격한 Compute Policy

​
2.2 팀별 분리

팀 간 독립성이 높고, 비용 추적이 중요한 조직에 적합합니다.
Workspace팀카탈로그공유 데이터 접근
DE Workspace데이터 엔지니어링de_dev, de_prodshared 카탈로그 읽기
DS Workspace데이터 사이언스ds_dev, ds_prodshared 카탈로그 읽기
Analytics Workspace분석가analyticsshared + de_prod 읽기
주의 팀별 분리의 함정: 팀 간 데이터 공유가 빈번하면 Workspace 분리가 오히려 병목이 됩니다. 이 경우 단일 Workspace + Unity Catalog 카탈로그 수준 분리가 더 효과적입니다.

​
2.3 프로젝트별 분리

규제 산업(금융, 의료)에서 프로젝트별 데이터 격리가 필수인 경우 사용합니다.
프로젝트Workspace격리 수준근거
고객 신용 평가credit-scoring-prod네트워크 격리 + CMK금융 규제 (여신전문금융업법)
환자 데이터 분석patient-analytics-prodVPC 격리 + IP 제한HIPAA / 개인정보보호법
일반 분석analytics-prod표준 보안규제 대상 아님