본문으로 건너뛰기

3.4 데이터 가상화와 분석 플랫폼

사본에서 쿼리가 실행된다는 사실만으로 원본 의존성이 사라졌다고 판단하기는 어렵습니다. 원본 테이블을 삭제해도 공유 파일이 남아 한동안 읽기에 성공하는 경우가 있습니다. 자식이 사용하는 snapshot 때문에 부모를 삭제하지 못하는 경우도 있습니다. 두 경우를 구분해야 합니다. 생성 명령의 성공 여부뿐 아니라 참조 대상과 정리 동작도 비교해야 합니다. 그래야 장기 시험 환경과 보존 환경의 수명을 설계할 수 있습니다.

이 장의 제품 비교 기준일은 2026-09-30입니다. Delphix VDB, Snowflake clone을 다룹니다. Delta shallow/deep clone, Oracle snapshot PDB도 다룹니다. 테이블 사본과 DB 사본, 실행 환경 전체는 서로 다른 단위로 구분합니다. 현행 문서로 확인한 기능과 과거 버전의 조건을 명시합니다. 마지막 절에서는 공개 고객 사례와 동일 조건의 측정이 각각 무엇을 입증하는지 구분합니다.

Delphix의 수집 사본과 VDB​

Delphix Continuous Data는 원본의 파일과 로그를 수집합니다. 이 수집 결과로 내부 사본인 dSource를 유지합니다. dSource의 변경 이력은 timeflow와 snapshot으로 관리합니다. 그 snapshot에서 쓰기 가능한 VDB를 제공합니다. VDB의 변경은 Delphix Storage의 새 블록에 기록합니다. 이 구조에서는 원본 서비스, 수집 사본, 시험용 VDB를 별도 관리 대상으로 구분해야 합니다.

원본과의 연결 해제와 수집 사본 삭제는 동작이 다릅니다. 현행 dSource 문서에서 detach는 원본과의 연결을 끊는 동작입니다. 이미 수집한 데이터와 snapshot은 유지합니다. 분리된 dSource에서도 VDB를 제공합니다. 다만 갱신 기준은 분리 전에 확보한 snapshot으로 제한됩니다. 반면 dSource 삭제는 metadata, snapshot, 로그와 정책을 제거합니다. 원본 DB 자체는 유지합니다. 의존하는 VDB나 vPDB가 없어야 삭제할 수 있다는 조건도 명시합니다.

따라서 운영 정책에서는 연결 상태와 데이터 수명을 별도로 관리하도록 제안합니다. 수집 연결을 중단한 뒤에도 기존 VDB는 동작하는 경우가 있습니다. 이 결과만으로 최신성을 확인할 수는 없습니다. dSource 삭제 제한은 dSource에 대한 보호 조건입니다. 이를 원본 DB 삭제까지 막아준다는 뜻으로 해석해서는 안 됩니다. 삭제 대상이 운영 DB인지, dSource인지, 개별 VDB인지 기록해야 합니다. 그래야 의존성을 정확히 검토할 수 있습니다.

이 도식은 데이터 공급과 의존성 확인의 범위를 설명합니다. 엔진별 connector와 target 환경 설정까지 모두 같다는 의미는 아닙니다. role, extension, secret과 scheduled job의 복제 범위에는 미확인 항목이 있습니다. 이 항목들은 소스 엔진별로 남아 있습니다. 마스킹 기능을 제공하더라도 과거 snapshot의 처리 규칙은 별도로 확인해야 합니다. 모든 외부 자격증명의 처리 규칙도 별도 확인이 필요합니다.

Snowflake의 객체와 저장 공간​

Snowflake의 2016년 3월 공식 글은 clone 제공을 확인하는 근거입니다. 이 clone은 metadata와 데이터 참조를 이용합니다. 그 날짜를 최초 출시일로 사용하지 않습니다. 비교 단위는 table, schema, database입니다. 과거 시점 clone에는 Time Travel 보존 조건이 적용됩니다. PostgreSQL 인스턴스를 하나 더 기동하는 구조와는 비교 단위가 다릅니다. 같은 단위로 비교하면 객체별 포함 범위와 실행 자원의 차이를 놓치게 됩니다.

표준 테이블의 clone은 생성 시 기존 micro-partition을 공유합니다. 이후 변경에 따라 각 객체의 새 데이터가 생깁니다. 원본과 clone은 각자의 수명을 갖습니다. 공유 데이터를 소유한 테이블이 삭제되어도 남은 clone은 저장 공간을 참조합니다. 이때 해당 저장 공간의 소유권이 이전됩니다. 저장 문서는 Time Travel 보존이 끝나고 Fail-safe로 넘어갈 경계에서 이를 설명합니다. 이 설명은 표준 테이블 범위이며 hybrid table의 추가 저장 규칙과 구별합니다.

정리 정책에서는 객체가 목록에서 사라진 시각을 관찰하도록 제안합니다. 공유 데이터의 보존이 끝난 시각도 별도로 관찰합니다. 삭제 직후 저장 비용이 같은 비율로 감소한다고 예측하기는 어렵습니다. 공유 참조와 보존 상태가 남아 있기 때문입니다. 초기 clone은 데이터 복사가 적지만 변경 데이터와 이력의 전체 비용은 따로 계산해야 합니다. 초기 복사량만으로 전체 비용을 0으로 볼 수는 없습니다.

권한과 실행 객체에도 예외가 있습니다. database와 schema clone에서 하위 객체 권한 상속은 별도 규칙을 따릅니다. container 자체 권한에도 다른 규칙을 적용합니다. COPY GRANTS를 지원하는 객체에서는 ownership을 제외한 권한 복사를 선택합니다. 이를 account 전체의 사용자와 role 복제로 설명하지 않습니다. database role에는 별도 clone 명령이 있습니다.

cloned task와 alert는 정지 상태로 시작합니다. stage와 pipe에는 별도 복제 예외가 있습니다. 외부 sequence 등 원본 참조도 남는 경우가 있습니다. 따라서 clone한 database에서 시험 SQL이 성공해도 추가 확인이 필요합니다. 외부 입출력과 예약 실행의 준비 여부는 별도로 확인해야 합니다. 모든 secret과 external integration의 복제 범위는 미확인으로 남깁니다. 필요한 객체의 동작은 시험 계획에 개별 등록합니다.

Delta shallow clone과 deep clone​

Delta shallow clone은 원본 data file을 참조합니다. Databricks의 deep clone은 data와 metadata를 복사합니다. 두 모드를 같은 clone 명령군으로 묶더라도 원본 파일에 대한 의존성은 다릅니다. OSS Delta Lake는 2.3부터 shallow clone을 제공합니다. 따라서 Unity Catalog를 모든 shallow clone의 필수 조건으로 쓰지 않습니다.

OSS와 기존 Hive metastore 계열의 shallow clone은 원본 파일을 참조합니다. 원본 VACUUM이 참조 파일을 제거하면 읽기가 실패할 위험이 있습니다. 로그 보존 기간과 데이터 파일의 생존은 별도로 확인해야 합니다. deep clone은 데이터를 복사하므로 이러한 원본 파일 참조 의존성과 구분됩니다. 다만 이 사실만으로 계정이나 리전 장애까지 분리한 백업을 확보했다고 판정하지 않습니다.

Unity Catalog의 shallow clone 문서는 clone 관계 추적을 설명합니다. 이 추적으로 유효한 파일을 VACUUM에서 보호합니다. 기준 문서에서 이 기능은 Public Preview입니다. managed table은 Databricks Runtime 13.3 LTS 이상을 요구합니다. external table은 14.3 LTS 이상을 요구합니다. 같은 테이블 유형 사이의 clone 조건도 적용됩니다. 이 세부 조건은 사실 대장의 조사 항목을 공식 문서로 보완한 내용입니다.

원본 managed table의 삭제와 이후 purge는 VACUUM의 참조 보호와 별도 문제입니다. clone은 원본 파일이 남아 있는 동안 읽기가 가능합니다. 실제 파일 삭제 후에는 사용할 수 없게 됩니다. 일부 workspace에는 원본 삭제 보호도 있으므로 환경의 실제 동작을 확인해야 합니다. external table의 DROP TABLE은 하부 파일을 삭제하지 않는다는 차이도 있습니다. 삭제 직후 단일 쿼리가 성공해도 영구 독립성은 별도로 검증해야 합니다.

Delta clone은 테이블 단위이며 원본 history와 일부 metadata를 승계하지 않습니다. 복제 범위는 workspace role, secret, scheduled job을 포함한 실행 환경 전체와 구분합니다. 분석 시험의 재현성을 확보하려면 복제한 테이블 버전을 기록해야 합니다. 실행 코드와 필요한 외부 설정도 별도로 기록하도록 제안합니다. 데이터 파일의 존재 조건과 시험 환경의 재현 조건을 함께 검토합니다.

Oracle snapshot PDB와 의존성 대조​

Oracle snapshot PDB cloning은 2013년 6월 백서에서 확인됩니다. 백서는 이를 12.1.0.1 기능으로 설명합니다. 당시 백서는 Sun ZFS, NetApp, Oracle ACFS를 지원 스토리지로 제시합니다. 이는 해당 버전과 시점의 근거입니다. 현재 Oracle 제품의 모든 배치가 같은 제약을 갖는다는 뜻은 아닙니다. 오래된 기능의 존재를 설명하는 자료와 도입할 버전의 지원 조건을 구분해야 합니다.

12c 관리 문서는 CLONEDB 설정에 따라 조건을 나누어 설명합니다. snapshot 지원 파일시스템 또는 Direct NFS 및 원본 read-only 유지 조건입니다. CLONEDB=TRUE 경로에서는 clone이 존재하는 동안 원본을 open read-only로 유지해야 합니다. SNAPSHOT COPY로 만든 clone이 남아 있을 때의 원본 삭제 동작도 명시합니다. 이 상태에서 source PDB를 삭제하면 닫힌 clone은 열리지 않습니다. 열린 clone에서도 오류가 발생합니다. 따라서 이 동작을 원본 삭제의 자동 차단 보장과 구별해야 합니다. 정리 순서에는 원본 보존 조건을 반영해야 합니다. 사용자, wallet, scheduler, 외부 연결의 복제 범위는 개별 확인 대상으로 남깁니다.

Flashback Query와 Flashback Database도 snapshot PDB와 구별합니다. 전자는 과거 데이터 조회, 후자는 DB 되감기 기능입니다. 새 시험 환경 provisioning과는 기능이 다릅니다. 기존 Copy-on-Write와 Thin Clone 계보의 개념 설명과 연결합니다. 이 장은 각 사본의 참조 대상과 삭제 조건을 비교하는 데 집중합니다.

제품과 모드사본이 참조하는 대상원본 관련 정리 동작전체 환경 복제 범위
Delphix VDBdSource 또는 VDB의 snapshotdSource 삭제 전 의존 VDB와 vPDB 제거 조건엔진과 connector별, 일부 미확인
Snowflake 표준 테이블 clone공유 micro-partition참조와 보존 상태에 따른 소유권 이전객체별 권한 및 task, stage 예외
Delta OSS 및 Hive metastore shallow clone원본 data file원본 VACUUM의 파일 삭제 영향테이블 단위, 원본 history 미승계
Delta Unity Catalog shallow clone원본 data file과 추적된 참조유효 파일 보호, managed 원본 purge 영향Runtime과 테이블 유형 조건
Databricks Delta deep clone복사한 data와 metadata원본 data file의 직접 참조 없음테이블 단위, 일부 metadata 제외
Oracle 12c snapshot PDB지원 스토리지의 snapshot 및 원본 관련 데이터원본 삭제 시 clone 열기 실패 또는 실행 오류wallet과 외부 연결 등 미확인

이 표에서 말하는 원본은 제품마다 다릅니다. Delphix의 dSource는 이미 수집한 내부 사본입니다. Delta의 원본은 참조 파일을 가진 테이블입니다. 따라서 원본 삭제 시험을 설계할 때는 실제로 제거할 객체와 파일을 먼저 지정하도록 제안합니다. 조상 snapshot 삭제 제한, 파일 정리, 보존 만료는 서로 다른 조건입니다. 이를 하나의 실패 조건으로 묶으면 어떤 의존성이 문제였는지 구분하기 어렵습니다.

기능 문서와 고객 사례 및 측정 근거​

이 Part는 제품 순위를 매기는 대신 주장별 확인 방법에 따라 증거를 구분합니다. 공식 기능 문서는 특정 버전과 모드에서 제공하는 동작의 근거입니다. 고객 사례는 실제 사용 목적과 공개된 운영 흐름의 근거입니다. 동일 조건의 측정은 생성 시간과 부하, 복구와 비용을 대조하는 근거입니다. 서로 다른 세 종류를 하나의 신뢰도 점수로 합산하지 않습니다.

증거 종류기록 대상이 장의 근거 상태
기능 문서버전, 모드, 제공 단계, 전제 조건공식 문서로 확인, 일부 항목 미확인
고객 사례고객명, 사용 목적, 공개된 운영 범위실명 공급사 사례의 신뢰도 보통
동일 조건 측정데이터, 자원, 작업 경계, 결과 로그수행하지 않음

공개 사례 중 Virgin Money는 운영 데이터 기반 시험 환경의 갱신과 마스킹 요구를 설명합니다. 이에 Delphix를 활용했습니다. Landkreditt는 Snowflake Zero-Copy Cloning을 개발에 활용한 사실을 공개합니다. 두 사례의 신뢰도는 조사 원본의 등급을 따라 보통으로 표시합니다. 두 사례는 공급사의 실명 고객 자료입니다. 고객 전체의 비용 절감과 개발 개선 효과를 clone 기능 하나의 성과로 환산하지 않습니다.

고객 자체 운영 문서로 확인한 사례에는 높음이라는 등급을 적용합니다. 이 등급도 해당 사용 사실의 근거를 뜻합니다. 예를 들어 GitLab의 DBLab 운영 문서는 운영 규모 데이터 검증의 사용 근거입니다. 이 장의 제품들 사이에 가용성 우열을 정하는 자료는 아닙니다. 공개된 사례가 없는 항목은 사례 미확인으로 남깁니다. 사례 확인 여부와 기능 지원 여부는 구분합니다.

후속 측정에는 원본 갱신, 사본 쓰기, 원본 삭제를 별도 단계로 두도록 제안합니다. 보존 만료와 파일 정리도 별도 단계로 둡니다. 각 단계 전후의 쿼리 결과와 저장량, 오류를 기록합니다. 이를 공급사 문서의 조건과 대조합니다. 이 장은 해당 시험 결과를 보유하지 않으므로 복구 성공이나 비용 우열을 확정하지 않습니다. Part 4의 후보 선택에서는 먼저 필요한 사본 범위와 허용할 원본 의존성을 정합니다. 남은 조건은 검증 과제로 넘깁니다.

참고​