DCM 프로젝트 배포 및 관리

이 주제는 DCM Projects를 만들어 배포해 Snowflake 환경(계정 포함)을 관리하는 방법을 설명해요.

출처: Snowflake User Guide - Deploy and manage DCM Projects

본문

DCM 프로젝트를 관리하는 작업은 다음을 포함해요.

DCM 프로젝트를 위해 Snowflake 계정을 준비해요.
프로젝트 파일에서 프로젝트 구성과 객체를 정의해요.
DCM Projects 객체를 만들어요.
배포 전에 제안된 변경을 미리 보기 위해 PLAN을 실행해요.
프로젝트를 배포해요.
프로젝트를 모니터링·갱신·반복하며 유지 관리해요.

프로젝트에 증분 변경을 지속적으로 배포하고 대규모 계정 인프라 변경도 배포할 수 있어요.

DCM 프로젝트 준비하기

Snowflake 계정이 다음 사전 요구 사항을 충족해야 해요.

DCM Projects 객체를 만들 수 있는 데이터베이스와 스키마
DCM Projects 객체를 만들 권한과 웨어하우스에서 쿼리를 실행할 접근 권한이 있는 역할
Snowflake CLI의 경우 임시 스테이지를 만들 권한이 있는 역할

인터페이스 도구:

인터페이스 도구	무엇에 좋은가
Snowsight(Workspace)	Snowflake 네이티브 클라우드 IDE. DCM 정의 파일을 UI로 쉽게 만들거나 업로드. Git 리포지토리에 연결해 변경을 pull/push. 정의 파일 검토·편집·디버깅. DCM 명령 실행.
Cortex Code	에이전트형 AI 도구. DCM 스킬로 DCM 프로젝트를 자동으로 생성·마이그레이션·디버깅·배포. 단계별로 나란히 작업도 가능.
Snowflake CLI	로컬 IDE에서 계정과 상호작용하는 CLI. DCM Projects는 문서화된 명령·옵션에 Snowflake CLI 버전 3.24.0 이상이 필요해요.

Git 통합:

DCM 프로젝트 정의 파일이 저장된 Git 리포지토리에 연결해요. Git 리포지토리에서 새 워크스페이스를 만들고, 계획한 변경을 위한 Git 브랜치를 만들거나 선택하며(선택한 브랜치의 파일을 워크스페이스 편집기로 복제), 편집한 파일을 Git으로 동기화해요.

DCM 프로젝트 만들기

필요한 역할과 권한:

DCM 프로젝트 객체를 만드는 사용자의 역할은 다음 권한이 있어야 해요.

CREATE DCM PROJECT ON SCHEMA 권한:

GRANT CREATE DCM PROJECT ON SCHEMA <schema_name> TO ROLE <role_name>;

DCM 프로젝트 만들기:

Snowsight Workspaces에서 Projects » Workspaces를 선택한 뒤 + Add new » DCM Project로 새 DCM 프로젝트 폴더를 만들 수 있어요. CLI로는 다음 명령을 사용해요.

snow dcm create <my_project> --if-not-exists   # 기본 대상 사용
snow dcm create --target DEV                   # 명명된 대상 사용

접근 제어와 역할 권한

스키마 수준 DCM 프로젝트 객체의 RBAC를 READ, MONITOR, OWNERSHIP 권한으로 설정할 수 있어요.

권한	설명	허용되는 작업
`READ`	DCM 프로젝트 객체가 존재하는지 보여줘요. DCM 프로젝트가 배포한 객체·권한을 나열해요.	DCM 프로젝트가 배포한 객체와 권한을 볼 수 있어요.
`MONITOR`	`READ` 권한의 모든 작업 외에 배포 기록을 볼 수 있어요.	배포 기록·아티팩트 관찰.
`OWNERSHIP`	객체의 소유권.	모든 DCM 명령 실행.

DCM 관리 객체에 대한 소유권:

DCM 프로젝트를 배포하는 역할은 기본적으로 배포된 모든 객체의 OWNERSHIP 권한을 가져요. 프로젝트 정의는 소유권을 다른 역할로 이전할 수 있어요. 소유권 잠금(owner lockout)을 방지하려면 DCM 프로젝트 소유자 역할이 소유권을 받는 역할을 보유해야 해요. DCM PLAN과 DEPLOY는 잠재적인 소유권 잠금을 적극적으로 확인하고, GRANT OWNERSHIP이 소유권을 프로젝트 소유자 역할에서 떨어뜨리면 어떤 변경도 하기 전에 실패해요.

DCM 프로젝트 정의하기

DCM 프로젝트는 매니페스트 파일과 하나 이상의 SQL 객체 정의 파일을 기반으로 해요. 이 파일들은 Git 리포지토리나 로컬 워크스페이스에 저장·관리돼요.

매니페스트 파일은 해당 계정 식별자, DCM 프로젝트 객체, 이 객체들의 소유자 역할, 선택적 템플릿 구성으로 하나 이상의 대상 환경을 지정해요. 선택적으로 템플릿 기본값과 하나 이상의 구성을 지정해요.
객체 정의 파일은 관리할 Snowflake 객체 그룹을 정의해요.

DCM 프로젝트 PLAN하기

PLAN은 배포 전에 변경을 미리 보는 건조 실행(dry run)을 수행해요. Snowflake는 프로젝트 정의 파일을 기존 객체와 비교해 어떤 객체가 생성·변경·삭제될지 보여줘요. 계정에는 어떤 변경도 이루어지지 않아요. 배포 전에 변경을 검토·검증하는 데 PLAN을 사용해요. 구성이나 플랜 결과의 출력 경로 같은 옵션을 지정할 수 있어요.

PLAN 명령 실행하기:

PLAN 명령은 입력으로 다음을 받아요.

매니페스트 파일의 경로. CLI는 매니페스트에서 대상을 읽어요(default_target 또는 --target 플래그). SQL 명령의 경우 매니페스트 파일 경로와 프로젝트 이름을 제공해야 해요.

PLAN DELTA:

PLAN DELTA는 기존 프로젝트에 대한 증분 변경 검증을 위한 더 빠른 PLAN 변형이에요. 현재 계정 상태에 대해 모든 정의를 확인하는 대신, 변경한 정의와 그에 의존하는 프로젝트의 하류 정의만 평가해요. 활발한 개발 중 편집에 대한 더 빠른 피드백을 얻기 위해 PLAN DELTA를 사용해요. 변경되지 않은 정의를 건너뛰기 때문에 DCM 밖에서 발생한 변경을 감지하지 못해요.

정의 파일 경로:

매니페스트와 정의 파일의 위치를 참조하는 옵션:

Workspace 경로에서: Snowsight UI가 현재 워크스페이스 안의 모든 DCM 프로젝트 정의를 자동으로 나열해요. 그 중 하나를 선택해 DCM 명령을 실행하게 해요.
로컬 파일 시스템에서: Snowflake CLI 사용자에게 유용해요.
Git 브랜치에서: 파일을 로컬로 가져오거나 Workspace에서 사용할 수 있어요.
스테이지 경로에서: 정의 파일을 스테이지에 올리고 스테이지 경로로 참조해요.

PLAN 출력:

PLAN·DEPLOY 출력 형식(JSON 스키마와 예시 포함)은 EXECUTE DCM PROJECT 명령 레퍼런스의 PLAN·DEPLOY 출력 섹션을 참고해요.

DCM 프로젝트 배포하기

DCM 프로젝트를 배포하면 다음 작업이 수행돼요.

정의됐지만 아직 존재하지 않는 객체를 생성해요.
존재하지만 현재 정의와 다른 객체를 변경해요.
정의된 대로 이미 존재하는 객체를 건너뛰어요.
존재하지만 더 이상 정의되지 않는 객체를 삭제해요.

같은 동작이 프로젝트에 정의된 권한과 첨부된 데이터 품질 기대치에도 적용돼요.

DEPLOY 명령 실행하기:

DEPLOY 명령을 실행하려면 다음 입력을 제공해요.

매니페스트 파일의 경로.
매니페스트에 구성 프로필이 정의돼 있으면 구성 프로필 이름.
선택적으로, 기본값을 재정의하는 구성 프로필 값.
선택적으로 배포 별칭(deployment alias).

DCM 프로젝트 관리하기

DCM 프로젝트가 관리하는 객체와 권한 보기:

SHOW ENTITIES IN DCM PROJECT 명령으로 특정 DCM 프로젝트가 현재 관리하는 모든 Snowflake 객체 목록을 볼 수 있어요. 모든 객체의 정규화된 이름 목록을 제공해요. 결과를 보려면 DCM 프로젝트에 대한 READ 권한과 관리 객체 자체를 볼 권한이 모두 필요해요. 결과가 가장 최근 배포의 객체와 반드시 일치하지는 않아요. 수동으로 삭제되거나 분리된 객체는 다르게 보일 수 있어요.

객체를 DCM 프로젝트에서 분리하기:

ALTER <object> 명령에 UNSET DCM PROJECT 절을 사용하면 배포되어 이제 DCM 프로젝트가 관리하는 객체를 분리할 수 있어요. 이 명령은 객체를 삭제하지 않고 객체와 DCM 프로젝트 사이의 연결을 제거해요. 다른 DCM 프로젝트로 객체 관리를 시작하고 싶을 때 이 명령을 사용할 수 있어요. 분리하기 전에 프로젝트 정의 파일에서 해당 DEFINE 문을 제거해야 해요.

DCM 프로젝트에서 권한 분리하기:

ALTER DCM PROJECT ... UNMANAGE GRANT는 기본 권한을 회수하지 않고 프로젝트의 관리 범위에서 권한을 제거해요. 권한은 정확히 그대로 유지되고, 프로젝트의 추적만 제거돼요. UNMANAGE GRANT를 사용할 때:

권한을 다른 프로젝트나 수동 관리로 이전할 때
외부 변경(예: DCM 밖의 누군가가 권한을 회수) 후 오래된 권한 참조를 정리할 때

필요한 권한: ALTER DCM PROJECT ... UNMANAGE GRANT를 실행하는 역할은 DCM Project 객체에 대한 OWNERSHIP이 있어야 해요. REVOKE 권한이나 대상 리소스의 소유권은 필요하지 않아요.

문법: <grant_specification>은 GRANT <privilege> 문과 같은 문법을 사용해요. DCM 정의 파일에서 GRANT 키워드를 생략하고 GRANT 줄을 쓰는 것처럼 정확히 작성해요.

반환 값: 성공 시 명령은 지정 해제된 권한 수를 포함한 메시지를 반환해요.

분리 후 다음 단계: UNMANAGE GRANT를 실행한 뒤, 다음 배포 전에 프로젝트 정의 파일에서 해당 GRANT 문을 제거해요. 그대로 두면 다음 EXECUTE DCM PROJECT 실행에서 권한이 다시 통합돼요.

오류 처리: 다음 경우 명령이 오류를 반환해요.

참조된 권한이나 보안 가능 객체가 존재하지 않거나 해석할 수 없는 경우
역할이 DCM Project에 대한 OWNERSHIP이 없는 경우
역할이 참조된 보안 가능 객체를 볼 수 없는 경우

명령은 조용히 실패하지 않아요. 모든 오류가 보고되므로 정확히 어떤 권한이 지정 해제됐는지 확인할 수 있어요.

DCM 프로젝트 퍼지(Purge):

개발 샌드박스나 데모용 임시 DCM 프로젝트 객체를 만들 때, PURGE 옵션이 있는 EXECUTE DCM PROJECT 명령으로 단일 문에서 전체 프로젝트를 정리할 수 있어요. PURGE는 정의 없이 배포를 실행해 모든 엔터티를 삭제하고, 모든 권한을 회수하며, 프로젝트가 현재 관리하는 모든 첨부를 제거해요.

경고: PURGE는 설계상 파괴적이에요. 개발·데모 같은 비프로덕션 프로젝트에만 사용해요.

DCM 프로젝트 삭제하기:

DCM 프로젝트 객체가 삭제되면 모든 관리 엔터티, 권한, 기대치는 "비관리(unmanaged)" 상태로 그대로 유지돼요.

중요: DCM 프로젝트 객체를 삭제하거나 교체하면 객체가 포함한 모든 배포 기록 아티팩트를 잃어요.

DCM 프로젝트 배포 자동화하기

CI/CD 모범 사례:

비프로덕션 환경을 대상으로 하는 DCM 프로젝트는 실수로 프로덕션에 배포되는 것을 피하기 위해 프로덕션 프로젝트와 다른 역할이 소유해야 해요.
프로덕션 환경을 대상으로 하는 DCM 프로젝트는 모든 객체를 배포하기에 충분히 맞춤화된 접근 권한만 가진 전용 프로덕션 배포 역할이 소유해야 해요.

GitHub Actions:

snowflakedb/snowflake-actions 리포지토리에 DCM Projects 파이프라인을 자동화하는 재사용 가능한 복합(composite) GitHub Actions 집합이 GitHub Marketplace에서 제공돼요. 각 액션은 수명 주기의 한 단계를 처리하며, 이들을 조합해 엔드투엔드 CI/CD 파이프라인을 만들 수 있어요. 이 재사용 액션들은 GitHub에서만 사용할 수 있어요. 같은 CI/CD 개념이 Azure DevOps, GitLab CI/CD 등에도 적용돼요.

인증:

OIDC(OpenID Connect)는 CI/CD 파이프라인에 권장되는 인증 방식이에요. GitHub 내장 ID 토큰을 사용하며 저장된 시크릿을 필요로 하지 않기 때문이에요.

샘플 워크플로:

snowflake-labs DCM 리포지토리의 GitHub_workflows 디렉터리에는 재사용 액션을 완전한 CI/CD 파이프라인으로 조합하는 바로 사용할 수 있는 워크플로 파일이 있어요. 이들을 리포지토리의 .github/workflows/ 디렉터리로 복사하고 프로젝트에 맞게 커스터마이즈할 수 있어요. 모든 샘플 워크플로는 매니페스트 대상에서 Snowflake account_identifier와 project_owner 역할을 직접 읽어요.

자주 묻는 질문(FAQ)

기존 객체 이름을 어떻게 바꾸나요?

DCM 프로젝트 밖에서 ALTER 명령을 실행해요.
정의를 변경해요.
새 정의가 새 상태와 일치하는지 확인하려면 PLAN을 실행해요(PLAN에서 변화 없음).
새 상태를 저장하려면 DEPLOY를 실행해요.

DCM 프로젝트 배포 및 관리