Snowflake DCM Projects

Snowflake DCM Projects(데이터베이스 변경 관리, Database Change Management)는 Snowflake 객체를 코드로 관리하는 선언적(declarative) 접근 방식을 활성화해요. 데이터베이스, 스키마, 테이블 및 기타 객체의 원하는 대상 상태를 정의 파일에 정의하면, Snowflake가 그 상태에 도달하기 위해 필요한 변경을 판단하고 적용해요. 이는 인프라스트럭처-코드 도구에서 흔한 plan-then-deploy 워크플로를 사용해 dev, staging, production 같은 환경에 걸친 버전 관리된 반복 가능한 배포를 가능하게 해요.

출처: Snowflake User Guide - DCM Projects overview

본문

DCM 프로젝트는 Snowflake Workspaces나 로컬 IDE에서 손으로 작성·디버깅·배포하거나, Cortex Code로 자연어 프롬프트를 통해 하거나, CI/CD 파이프라인을 통해 자동화할 수 있어요. 정의에 반복되는 패턴이 있다면 Jinja 템플릿(딕셔너리, 루프, 조건, 매크로 포함)을 사용해 코드를 파라미터화할 수 있어요.

DCM 프로젝트를 관리하는 높은 수준의 워크플로는 다음과 같아요.

Snowflake Workspace, 원격 Git 리포지토리, 또는 로컬 디렉터리에 DCM 프로젝트 파일(manifest.yml과 SQL 정의 파일)을 만들어요.
각 대상 환경에 대해 새 DCM 프로젝트를 만들어요.
DCM 프로젝트 파일에서 Snowflake 객체를 정의해요. 지원되는 객체 유형에 대해 DEFINE 키워드로 기존 SQL 배포 스크립트를 변환해요.
(선택) 공유 또는 대체 템플릿 변수와 매크로를 추가해요.
DCM PLAN 명령을 실행해 배포를 모의 실행하고 변경을 미리 봐요.
프로젝트 버전을 배포해 Snowflake에서 변경을 적용해요.
프로젝트 실행을 모니터링해요.
DCM 프로젝트를 반복해요. 프로젝트 파일을 갱신하고, 플랜 출력을 검토하고, 필요에 따라 새 버전을 배포해요.

이 수명 주기는 데이터베이스 변경을 통제되고 버전 관리되며 감사 가능한 방식으로 구축·테스트·배포·모니터링하는 데 도움이 돼요.

인터페이스

Snowsight Workspaces, 로컬 IDE의 Snowflake CLI, Cortex Code의 자연어 프롬프트, SQL 명령, 또는 자동화된 CI/CD 파이프라인으로 DCM 프로젝트를 작업할 수 있어요. 이 인터페이스들의 비교, 설정 지침, 그리고 일반적인 개발에서 프로덕션 워크플로에 어떻게 맞는지에 대한 다이어그램은 DCM 프로젝트 배포·관리의 인터페이스 도구를 참고해요.

시작하는 방법

다음 중 한 가지 방식으로 DCM 프로젝트를 시작할 수 있어요. Cortex Code가 이 경로들 중 어느 것에든 도움을 줄 수 있어요.

빠른 시작 시도: Snowflake Labs 리포지토리의 데모 프로젝트를 복제하고 안내된 퀵스타트가 단계를 안내하게 해요.
새 프로젝트 시작: Snowsight Workspace에 새로 비어 있는 DCM 프로젝트를 만들어요.
기존 프로젝트 가져오기: 기존 DCM 프로젝트가 포함된 Git 리포지토리를 Workspace나 로컬 환경으로 복제해 수정·테스트·배포해요.
기존 인프라 마이그레이션: 마이그레이션 저장 프로시저나 Cortex Code 스킬로 기존 계정 인프라나 커스텀 SQL 스크립트를 DCM 프로젝트로 변환해요.

빠른 시작:

Get Started with Snowflake DCM Projects 퀵스타트는 샘플 푸드 트럭 분석 파이프라인을 다루며 다음을 포함해요.

Snowflake Labs DCM 리포지토리에 연결된 Snowflake Workspace 만들기
전용 역할과 DCM 프로젝트 객체 설정
프로젝트의 매니페스트 파일, 정의 파일, Jinja 매크로 탐색
PLAN과 DEPLOY를 실행해 파이프라인 만들기
데이터 메트릭 함수로 데이터 품질 기대치(expectation) 연결

기존 객체를 DCM Projects로 마이그레이션:

이미 DCM Projects 관리 아래로 가져오려는 Snowflake 객체가 있다면, Snowflake Labs DCM 리포지토리의 migration-tools 폴더에 있는 마이그레이션 도구를 사용해요. 두 도구 모두 선택한 데이터베이스나 스키마에 대해 GET_DDL을 실행해 기존 객체에 대한 DEFINE 문을 생성해요.

Cortex Code 스킬: 전체 마이그레이션 워크플로를 안내해요. 저장 프로시저를 실행해 DEFINE 파일을 생성하고, PLAN을 실행해 라이브 객체와 비교하고, diff를 바탕으로 DEFINE 문을 다듬는 것을 돕고, 변경 없이 DEPLOY를 실행해 객체를 DCM Projects에 도입하고, 선택적으로 다중 환경 설정을 위한 Jinja 템플릿 기회를 식별해요. Cortex Code는 검토·승인을 위해 핵심 체크포인트에서 멈춰요.
저장 프로시저: Cortex Code를 사용할 수 없을 때의 대체 수단이에요. 파일 생성 단계만 담당하며, 이후 DCM 프로젝트를 설정하고 PLAN·DEPLOY를 수동으로 실행해요.

참고: 마이그레이션 스킬과 저장 프로시저는 실험적 도구로 제공돼요. 철저히 테스트하고 자신의 책임으로 사용해 주세요.

핵심 용어

선언적 정의(Declarative definitions): DCM Projects에서는 객체의 현재 상태와 무관하게 Snowflake 환경의 원하는 상태(예: 어떤 테이블·스키마·역할이 존재해야 하는지)를 정의해요. 객체를 만들거나 수정하는 각 단계를 지정하지 않아요. 무엇을 원하는지 설명하면 Snowflake가 어떻게 그렇게 할지 알아내요. 구체적으로 DCM Projects는 템플릿 기능이 있는 DEFINE 문을 활용해요. 이는 프로젝트 파일을 다른 환경에서 재사용·커스터마이즈할 수 있게 해줘요. 프로젝트 안 DEFINE 문의 순서와 위치는 결과에 영향을 주지 않아요. Snowflake가 변경을 적용하기 전에 모든 문을 수집하고 정렬하므로 시퀀싱이나 종속성을 수동으로 처리할 필요가 없어요.
DCM 프로젝트 파일: DCM 프로젝트는 보통 Git 리포지토리나 로컬 워크스페이스에서 관리되는 SQL과 YAML 소스 파일 집합을 기반으로 해요. DCM 프로젝트의 Snowflake 객체, 속성, 관계, 제약 조건을 프로젝트 정의 파일(SQL 파일)에서 정의해요. 프로젝트 파일을 개발 워크스페이스에서 갱신해요. 변경은 DCM 프로젝트 객체를 통해 배포한 뒤에만 Snowflake에 반영돼요.
DCM 프로젝트 객체: DCM 프로젝트는 DCM 프로젝트 파일에 정의된 객체를 배포·관리하는 데 사용하는 Snowflake의 스키마 수준 객체예요. 각 대상 환경마다 DCM 프로젝트 객체가 필요해요. DCM 프로젝트 객체는 DCM 명령을 실행하는 데 사용되며, 실행된 모든 배포의 불변 아티팩트와 정의 파일을 저장해요. DCM 프로젝트가 스키마 수준 객체이긴 하지만, 다른 데이터베이스의 객체를 만들고 관리하는 데 사용할 수 있어요. 또한 DCM 프로젝트를 실행해 변경을 건조 실행(dry run)해서 배포 전에 변경을 미리 볼 수도 있어요.

요구 사항

Snowsight, Snowflake CLI, SQL, 또는 Cortex CLI를 사용해 DCM Projects를 관리해요.
DCM 프로젝트 객체를 만들 수 있는 데이터베이스와 스키마가 필요해요.
DCM 프로젝트 정의를 로컬이나 Snowflake Workspace에 저장해요.
협업, 버전 관리, 변경 동기화에 Git을 사용해요.
Snowflake CLI로 로컬 정의를 실행하려면 대상 DCM 프로젝트 객체의 스키마에 임시 스테이지를 만들 권한도 필요해요.

비용

DCM Projects는 모든 Snowflake 에디션에서 사용할 수 있어요. DCM Projects 연산이 발생시키는 컴퓨팅 비용 외에 DCM Projects 전용 비용은 없어요. PLAN, DEPLOY 같은 DCM Projects 연산은 주로 메타데이터 연산이며, ALTER나 CREATE 문이 있는 DDL 스크립트를 실행하는 것과 비슷하게 Cloud Services 컴퓨팅 비용을 발생시켜요. Jinja 템플릿을 렌더링하거나 정보 스키마에서 DCM Projects 배포 기록을 쿼리할 때처럼 웨어하우스 컴퓨팅 비용도 적용될 수 있어요. Snowsight Workspaces에서 DCM ANALYZE 명령은 프로젝트의 정의 파일을 적극적으로 편집하는 동안에만 백그라운드로 실행돼요.

고려 사항과 제한 사항

프로젝트 크기와 성능:

PLAN, DEPLOY 같은 DCM Projects 연산의 실행 시간은 프로젝트 정의의 크기와 형태에 크게 의존해요. 외부 소스 테이블을 조인하는 뷰에서 읽는 함수를 호출하는 동적 테이블에 대한 권한 같은 복잡한 종속성 그래프는 단순히 독립 테이블이 많은 것보다 성능에 더 큰 영향을 줘요. 1,000개 이상의 엔터티가 있는 대형 프로젝트에서는 PLAN이나 DEPLOY가 10분 이상 걸릴 수 있어요. 정의를 더 적은 파일로 통합하면 일반적으로 PLAN과 DEPLOY 명령의 실행 시간이 빨라져요. 현재 DCM Projects는 프로젝트당 최대 10,000개의 정의된 엔터티·권한·첨부를 지원하며, 최대 총 크기는 10MB예요. 이 10MB 제한은 모든 소스 파일의 합과 렌더링된 정의 파일 모두에 적용돼요. 어떤 경우에는 이러한 제한을 초과하면 타임아웃으로 실행이 실패할 수 있어요. DCM Projects는 프로젝트의 /sources 아래 최대 10,000개 파일도 지원해요. 대형 프로젝트에 상호 의존성이 없는 세그먼트(예: 별도의 비즈니스 단위나 애플리케이션)가 있다면 그 경계를 따라 여러 개의 더 작은 프로젝트로 분할하는 것을 고려해요. 이는 PLAN과 DEPLOY 실행 시간을 개선할 수 있어요. 활발한 개발 중 정의 변경을 더 빨리 검증하려면 전체 프로젝트 대신 변경한 정의만 평가하는 PLAN DELTA를 사용해요.

체인지셋(Changeset):

PLAN과 DEPLOY 명령 모두 모든 DDL 변경을 plan_result.json 파일 안에 나열해요. 체인지셋은 수행되거나 계획된 연산(CREATE, ALTER, DROP)과 comment, schedule, timeout 같은 영향을 받는 개별 속성을 나열해요.

참고: 아직 preview 상태인 객체 유형의 경우 체인지셋이 그 객체의 모든 속성에 걸친 모든 세분화된 변경을 포착한다는 보장은 없어요.

템플릿:

정의 파일은 Jinja2 템플릿이므로 Jinja2 템플릿의 모든 제한이 적용돼요.
DCM 템플릿 변수는 자격 증명 같은 민감한 정보를 위한 것이 아니에요. 렌더링된 SQL 정의는 환경 변수가 삽입한 값을 읽어내지(redact) 않아요.

DCM Projects의 핵심 사용 사례

이 섹션은 DCM Projects의 핵심 사용 사례와, 규모가 있는 데이터 비즈니스가 직면하는 과제를 해결하는 데 어떻게 도움이 되는지 설명해요. 이 사용 사례는 팀의 책임에 따라 두 가지 일반 범주로 나뉘어요.

인프라와 거버넌스를 관리하는 플랫폼 팀
개별 데이터 제품과 파이프라인을 관리하는 기능(feature) 팀

인프라 관리를 위한 DCM Projects:

플랫폼 팀이 여러 비즈니스 단위를 위해 표준화된 인프라를 배포하고 유지 관리하려 할 때, DCM Projects로 코드에 표준 객체 집합을 SQL 파일로 정의할 수 있어요. 그리고 Jinja로 이 템플릿을 예를 들어 팀 이름으로 파라미터화해 여러 번 배포할 수 있어요.

예: 각 비즈니스 단위마다 전용 DCM 프로젝트 만들기

각 비즈니스 단위마다 전용 DCM 프로젝트를 만들고 모든 프로젝트가 같은 파라미터화된 정의 파일을 참조하는 방식이에요.

DEFINE DATABASE {{team_name}}_DB;
DEFINE ROLE {{team_name}}_ADMIN;
DEFINE WAREHOUSE {{team_name}}_WH WITH
  warehouse_size = '{{wh_size}}'
  auto_suspend = 300;

GRANT OWNERSHIP ON DATABASE {{team_name}}_DB TO ROLE {{team_name}}_ADMIN;
GRANT OWNERSHIP ON WAREHOUSE {{team_name}}_WH TO ROLE {{team_name}}_ADMIN;
GRANT ROLE {{team_name}}_ADMIN TO ROLE SYSADMIN;

다음 명령으로 DCM 프로젝트를 실행해요.

EXECUTE DCM PROJECT FINANCE_INFRA PLAN
  USING (team_name => 'Finance', wh_size => 'LARGE')
  FROM ...

예: 여러 비즈니스 단위를 위한 단일 DCM 프로젝트 만들기

이 접근 방식에서는 Jinja 템플릿의 루프를 사용해 하나의 DCM 프로젝트에서 여러 비즈니스 단위의 인프라를 관리해요.

{% for team_name in teams %}
  DEFINE DATABASE {{team_name}}_DB;
  DEFINE ROLE {{team_name}}_ADMIN;
  DEFINE WAREHOUSE {{team_name}}_WH WITH
    warehouse_size = '{{wh_size}}'
    auto_suspend = 300;
  GRANT OWNERSHIP ON DATABASE {{team_name}}_DB TO ROLE {{team_name}}_ADMIN;
  GRANT OWNERSHIP ON WAREHOUSE {{team_name}}_WH TO ROLE {{team_name}}_ADMIN;
  GRANT ROLE {{team_name}}_ADMIN TO ROLE SYSADMIN;
{% endfor %}

다음 명령으로 DCM 프로젝트를 실행해요.

EXECUTE DCM PROJECT FINANCE_INFRA PLAN
  USING (teams => ['Finance', 'HR', 'Engineering'], wh_size => 'MEDIUM')
  FROM ...

이렇게 하면 플랫폼 팀과 관리자가 다음과 같은 변경을 쉽게 할 수 있어요.

팀을 목록에 추가해 그 팀을 위해 기존 인프라 템플릿을 배포.
목록에서 팀을 제거해 그 팀의 인프라를 삭제.
모든 팀에 새 READ_ONLY 역할 추가.
모든 팀 또는 특정 팀에 걸쳐 권한이나 웨어하우스 크기 같은 특정 구성을 변경.
PLAN을 실행해 현재 상태를 기대 표준과 비교하고 다시 배포해 표준을 복원.

데이터 파이프라인을 위한 DCM Projects:

기능 팀이 자주 직면하는 과제를 DCM Projects가 해결하는 데 도움이 돼요. 자신의 데이터 파이프라인을 쉽게 작성·관리하려는 비즈니스 단위는 DCM Projects로 비즈니스 로직을 정의·테스트·배포·반복할 수 있어요.

테이블, 동적 테이블, 뷰, 웨어하우스, 역할, 권한, 데이터 메트릭 함수, 기대치를 모두 한 프로젝트에서 관리할 수 있어요.
파이프라인에 대한 증분 변경을 테스트하고 배포할 수 있어요. 구성을 변경하고, 변환 로직을 구현하고, 컬럼과 뷰를 추가할 수 있어요.
객체를 배포하기 전에 데이터 샘플을 미리 봐 변환 로직을 검증할 수 있어요.
같은 파이프라인 정의를 여러 환경에 배포할 수 있어요.
프로덕션에 변경을 배포하기 전에 프리프로덕션 환경에서 데이터 품질 기대치를 테스트할 수 있어요.

Snowflake DCM Projects