0. INTRO

데이터 플랫폼이 커질수록 가장 먼저 복잡해지는 것은 데이터 자체가 아니라 데이터의 관리 방식입니다.

여러 팀이 같은 데이터 레이크를 공유하고, 수많은 테이블·파일·모델이 쌓이기 시작하면
“이 데이터는 누가 만들었는가?”, “누가 접근할 수 있는가?”, “어디에 저장되어 있는가?” 같은 질문에 명확히 답하기 어려워지죠.😅

Databricks Unity Catalog는 이런 문제를 해결하기 위해 등장한 통합 데이터 거버넌스 계층입니다.
단순히 테이블 권한을 관리하는 기능을 넘어,
👉 데이터·파일·모델 전반에 대해 중앙 집중식으로 접근 제어, 감사, 메타데이터 관리를 제공합니다.

기존 Hive Metastore 기반 환경에서는 워크스페이스마다 메타스토어가 분리되거나, 클라우드 스토리지 접근 권한과 Databricks 권한이 이중으로 관리되는 경우가 많았습니다. Unity Catalog는 이를 Account 단위의 단일 Metastore 구조로 통합하여 보안과 운영 복잡도를 크게 줄였습니다.

또한 Unity Catalog는

• SQL 기반의 일관된 권한 모델
• 메이저 클라우드 벤더(AWS / Azure / GCP)에 독립적인 설계
• 테이블뿐 아니라 External Location, Volume, ML 모델까지 관리 가능

이라는 점에서,
Databricks를 단순한 분석 도구가 아닌 엔터프라이즈 데이터 플랫폼으로 확장시키는 핵심 구성 요소라고 볼 수 있습니다.

이 글에서는 Unity Catalog의 핵심 개념과 구조를 중심으로,
왜 필요한지, 그리고 기존 방식과 무엇이 다른지 차근차근 살펴보겠습니다.

---

1. Unity Catalog 계층 구조

UC는 Metastore > Catalog > Schema > Table/Volume의 4단계 계층 구조를 가집니다. 특히 저장 위치(Storage Location)는 상위 계층에서 하위 계층으로 상속되는 구조를 가집니다.

1-1) Metastore

• UC의 최상위 컨테이너로, 모든 권한 관리와 메타데이터의 중심지입니다.
• Account Console 수준에서 생성하며, AWS/GCP/Azure 객체 저장소를 기본 위치로 사용합니다.
• 하나의 Metastore는 여러 Workspace에 연결될 수 있어 조직 전체의 통합 거버넌스를 가능하게 합니다.
• Workspace > Catalog Explorer > External Data > External Locations에서 연결된 저장소 정보를 확인할 수 있습니다.

1-2) Catalog

• 데이터 자산을 그룹화하는 첫 번째 단위입니다.
• 카탈로그 생성 시 실제 데이터가 저장될 MANAGED LOCATION을 지정할 수 있습니다.
• 지정하지 않으면 Metastore의 경로에 저장됩니다.

1-3) Schema (Database)

• 카탈로그 내의 하위 단위로 태이블, 뷰, 볼륨을 포함합니다.
• 스키마 생성 시 LOCATION을 지정하면 해당 경로가 하위 Managed 객체의 기본 경로가 됩니다.

1-4) Objects (Table / Volume)

• 실제 데이터가 담기는 최종 단위입니다.
• 최하위 객체는 상위 스키마나 카탈로그에 설정된 위치를 따라가거나, 직접 LOCATION을 지정(External)할 수 있습니다.

---

2. Managed vs External 핵심 개념

UC에서 가장 중요한 차이는 데이터의 소유권(Lifecycle Management)입니다.

구분	Managed (관리형)	External (외부형)
정의	UC가 데이터의 위치와 생명주기를 모두 관리	사용자가 데이터 저장 위치를 지정
저장 위치	Metastore/Catalog/Schema에 설정된 기본 경로	DDL 작성 시 명시한 LOCATION 경로
DROP 시 동작	메타데이터 + 물리적 데이터 모두 삭제	메타데이터만 삭제 (실제 데이터 유지)
UNDROP 시 동작	메타데이터 + 물리적 데이터 모두 복구 (7일 이내)	메타데이터 복구 및 기존 데이터 재연결
용도	일반적인 데이터베이스 워크로드	기존 데이터의 연결 또는 외부 시스템 공유용

---

3. 시나리오별 물리 저장 & 삭제 규칙

스키마가 External(Location 지정)이라 하더라도 그 안의 객체가 Managed인 경우, UC의 관리 원칙이 우선 적용됩니다.

#	Schema 타입	Object	Object 타입	물리 저장 위치 (Path Logic)	DROP 시 데이터 삭제 여부
1	Managed	Table	Managed	s3://root/catalog/schema/table_name/	삭제 (O)
2	Managed	Table	External	gs://external/path/to/table/	유지 (X)
3	Managed	Volume	Managed	s3://root/catalog/schema/volume_name/	삭제 (O)
4	Managed	Volume	External	gs://external/path/to/volume/	유지 (X)
5	External	Table	Managed	Schema Location 또는 Managed Storage	삭제 (O)
6	External	Table	External	테이블 DDL에 지정한 LOCATION	유지 (X)
7	External	Volume	Managed	Schema Location 또는 Managed Storage	삭제 (O)
8	External	Volume	External	볼륨 DDL에 지정한 LOCATION	유지 (X)

💡 핵심 포인트:
1. 테이블 선언이 Managed라면, 하위 저장소가 어디든 DROP 시 데이터는 삭제됩니다.
2. External Schema 내의 Managed Table은 스키마가 가진 LOCATION 경로 아래에 생성되더라도 'Managed' 특성상 삭제 권한이 UC에 있습니다.

---

4. DDL 명령어 레퍼런스

4-1) Catalog 생성

카탈로그 수준에서 격리된 저장 공간을 사용하고 싶을 때 MANAGED LOCATION을 사용합니다.

-- 1. 기본형 카탈로그 (메타스토어 저장소 상속)
CREATE CATALOG IF NOT EXISTS prod_catalog;

-- 2. 관리형 위치를 지정한 카탈로그 (분리된 버킷 사용)
CREATE CATALOG IF NOT EXISTS dev_catalog
MANAGED LOCATION 's3://my-dev-bucket/uc-managed/';

4-2) Schema 생성

• Schema는 Catalog 하위에 생성되며, 해당 Schema에서 생성될 Managed 객체들의 기본 저장 경로를 결정할 수 있습니다.

-- Managed Schema (상위 Catalog의 경로 상속)
CREATE SCHEMA IF NOT EXISTS catalog.managed_schema;

-- External Schema (Managed 객체들이 저장될 특정 경로 지정)
CREATE SCHEMA IF NOT EXISTS catalog.external_schema
MANAGED LOCATION 'gs://my-bucket/external-schema-path/';

4-3) Table 생성

• Managed Table: LOCATION을 지정하지 않으면 상위 Schema/Catalog의 경로 하위에 데이터가 저장됩니다.
• External Table: LOCATION을 명시해야 하며, External Location으로 등록된 경로라면 어디든 저장 가능합니다. (반드시 상위 스키마 경로 아래일 필요는 없음)

-- Managed Table
CREATE TABLE catalog.schema.man_tbl (id INT, name STRING) USING DELTA;

-- External Table (External Location 등록 선행 필요)
CREATE TABLE catalog.schema.ext_tbl (id INT) 
LOCATION 'gs://my-bucket/data/ext_tbl/';

4-4) Volume 생성

• Managed Volume: UC가 관리하는 기본 경로에 파일이 저장됩니다.
• External Volume: 등록된 외부 경로를 직접 참조하여 비정형 데이터를 관리합니다.

-- Managed Volume (비정형 데이터용)
CREATE VOLUME catalog.schema.man_vol;

-- External Volume (LOCATION 명시 및 External Location 등록 필요)
CREATE EXTERNAL VOLUME catalog.schema.ext_vol
LOCATION 'gs://my-bucket/files/ext_vol/';

---

5. 관리형 볼륨(Volume) vs 테이블(Table)

구분	Tables	Volumes
데이터 형태	Tabular (행/열)	Files (모든 형식)
주요 포맷	Delta, Parquet, CSV 등	로그, 이미지, 하위 디렉토리 등

💡 권장 워크로드:

• 정형 데이터 및 분석용 지표 데이터는 Table 추천
• 머신러닝 모델 파일, 로그 파일, 원본(Raw) 파일 관리는 Volume 추천

---

6. 요약 및 주의사항

1. External Location 등록: External Table/Volume을 만들기 전, 클라우드 스토리지 경로가 UC에 External Location으로 등록되어 있어야 합니다.
2. Managed의 삭제 규정: Managed 타입은 "UC가 데이터의 생명주기를 책임진다"는 뜻이므로, DROP 시 데이터가 물리적으로 삭제됩니다. 단, 7일 이내라면 UNDROP 명령어로 복구가 가능합니다.
3. External의 복구: External 테이블은 DROP 시 데이터가 유지되므로 언제든 재연결이 가능하지만, UNDROP을 사용하면 테이블 권한 등 메타데이터까지 함께 복구됩니다.
4. 스키마 위치 상속: 스키마에 LOCATION을 주면 그 아래의 Managed 객체들은 부모 스키마의 경로를 기본값으로 사용합니다.

---

7. 설계 시 권장 사항(Best Practices)

1. 환경 분리: dev, staging, prod 카탈로그를 만들고 각각 다른 MANAGED LOCATION(S3 버킷 등)을 지정하여 물리적으로 데이터를 격리하세요.
2. Managed 우선: 특별한 이유(외부 시스템 공유, 기존 데이터 등)가 없다면 성능과 관리 편의성을 위해 Managed Table(Delta) 사용을 권장합니다.
3. Volume 활용: .csv, .json 원본 파일이나 머신러닝 모델, 로그 등 비정형 파일은 Table이 아닌 Volume으로 관리하여 보안과 추적성을 확보합니다.
4. 권한 최소화: EXTERNAL LOCATION을 직접 참조하는 권한은 데이터 엔지니어 등 관리자에게만 부여하고, 일반 분석가는 Managed Table을 통해서만 데이터에 접근하도록 설계하세요.