dbt Projects on Snowflake의 CI/CD 이해하기

dbt Projects on Snowflake의 CI/CD 이해하기

dbt 프로젝트 객체는 Snowflake CLI 명령을 사용해 배포와 실행을 CI/CD 워크플로에 통합하는 것을 지원해요. 간단한 전체 빌드(full-build) 워크플로는 dbt Projects on Snowflake에서 CI/CD 통합 설정 튜토리얼을 참조하세요. 풀 리퀘스트별 제로 복사 클론 데이터베이스를 사용하는 Slim CI 워크플로는 dbt Projects on Snowflake용 Slim CI와 PR별 데이터베이스로 CI/CD 설정 튜토리얼을 참조하세요.

출처: Snowflake 문서

본문

이 항목은 CI/CD 플랫폼(GitHub Actions, GitLab CI/CD, 또는 Azure DevOps)을 사용해 풀 리퀘스트를 열거나 main에 머지할 때마다 dbt Projects on Snowflake를 자동으로 테스트하고 배포하는 방법을 설명해요.

지속적 통합(Continuous Integration, CI) 은 각 풀 리퀘스트에서 dev 스키마를 대상으로 dbt 프로젝트를 실행해요. 즉, 누군가 코드 저장소에서 풀 리퀘스트를 열거나 업데이트할 때마다 새 코드에 대해 테스트와 빌드를 자동으로 실행하는 거예요. 이렇게 하면 머지 전에 문제를 일찍 잡을 수 있어요.

지속적 배포(Continuous Deployment, CD) 는 커밋이 머지된 후에도 Snowflake의 dbt 프로젝트 객체를 최신 상태로 유지해요. 즉, 코드가 브랜치에 머지될 때마다 업데이트된 코드를 프로덕션에 자동 배포해요. 이렇게 하면 프로덕션 환경이 안정적이고 재현 가능하게 최신 상태를 유지해요.

CI/CD는 수동적이고 오류가 발생하기 쉬운 배포를 피하고, 변경 사항이 머지 전에 검증되도록 보장하며, 일관되고 반복 가능한 배포를 가능하게 해요.

왜 CI/CD로 dbt 프로젝트 객체를 업데이트하는가

dbt 프로젝트는 모든 데이터 변환을 코드로 정의하므로 빈번한 업데이트가 쉽게 오류를 유발할 수 있어요. CI는 머지 전에 각 변경 사항을 별도의 dev 환경에서 테스트해 이런 문제를 일찍 잡아요.

변경 사항이 머지된 후에는 CD가 Snowflake 프로덕션 환경의 공식 dbt 프로젝트 객체를 자동으로 업데이트해요. 이렇게 하면 수동 단계가 제거되고, 위험이 줄어들며, 모든 것이 버전 관리되고, 안정적이고 협업적인 워크플로가 지원돼요.

CI/CD 모범 사례에 대한 자세한 내용은 CI/CD(Continuous integration and continuous deployment) 문서를 참조하세요.

CI 검증 경로 선택하기

각 풀 리퀘스트에 필요한 검증의 범위에 따라 두 경로 중 하나를 선택하세요.

  • 전체 빌드(Full build): 격리된 dev target에서 dbt build를 실행해 프로젝트의 모든 모델과 테스트를 검증해요. 이 입문 경로는 철저하고 단순하지만, 풀 리퀘스트가 몇 개의 모델만 변경해도 전체 프로젝트를 컴파일·실행·테스트해요. 프로젝트가 커질수록 추가 작업이 더 커져요. 튜토리얼은 dbt Projects on Snowflake에서 CI/CD 통합 설정 문서를 참조하세요.
  • Slim CI: 가장 최근 성공한 프로덕션 실행에서 state를 가져와 state:modified+만 실행·테스트하고, 변경되지 않은 업스트림 참조는 프로덕션으로 defer해요. 이 경로는 보통 더 빠르고 비용 효율적인 풀 리퀘스트 검증을 제공해요. 튜토리얼은 dbt Projects on Snowflake용 Slim CI와 PR별 데이터베이스로 CI/CD 설정 문서를 참조하세요.

state, defer, Slim CI, 실패한 실행 복구에 dbt 아티팩트를 사용하는 방법에 대한 자세한 내용은 Slim CI와 프로덕션 defer에 dbt 아티팩트 사용 문서를 참조하세요.

dbt 프로젝트에서 CI/CD 사용을 위한 상위 수준 사전 요구 사항

  • Git 저장소(예: GitHub, GitLab, 또는 Azure Repos)에 저장된 dbt 프로젝트.
  • dbt Projects on Snowflake 접근 제어 문서에 설명된 권한을 가진 Snowflake 계정과 사용자.
  • 다음 객체를 만들고 편집할 권한 또는 대신 각각을 만들어줄 관리자에 대한 접근 권한: Snowflake 계정·데이터베이스·스키마 값을 보관하는 CI/CD 플랫폼 시크릿과 변수, CI 및 CD 작업을 정의하는 워크플로 파일. CI/CD 플랫폼과 통신할 Snowflake 서비스 계정.
  • Snowflake에서 dev 환경(CI용)과 prod 환경(CD용)의 분리(예: 환경별 별도 데이터베이스 또는 스키마).
  • CI/CD 러너(예: GitHub Actions, GitLab Runner, 또는 Azure DevOps 에이전트)가 OIDC나 PAT 같은 방식으로 Snowflake에 연결할 수 있는 방법. 자세한 내용은 Snowflake CLI와 CI/CD 통합 문서를 참조하세요.
  • 코드 저장소에서 dev와 prod target(예: 데이터베이스/스키마, 웨어하우스)을 가리키도록 구성된 dbt_projects_profiles.yml 또는 profiles.yml 파일.
  • Git 공급자가 Snowflake로 인바운드 접근할 수 있도록 허용하는 네트워크 정책(network policy).

CI/CD 워크플로 개요

다음 단계는 CI/CD를 사용하는 일반적인 워크플로를 보여줘요.

  1. 개발자가 브랜치에서 dbt 코드(모델, 테스트 등)를 작성하거나 수정해요.
  2. 개발자가 풀 리퀘스트를 열어요.
  3. CI가 시작돼요: dbt 프로젝트 객체의 테스터 인스턴스가 Snowflake dev 환경에 배포돼요. 워크플로는 전체 dbt build를 실행하거나 Slim CI를 사용해 DAG의 변경된 부분만 실행·테스트해요. 작업이 실패하면 풀 리퀘스트가 실패해요. 개발자는 수정·업데이트한 후 다시 실행해야 해요. 모든 작업이 통과하면 풀 리퀘스트가 머지 자격을 얻어요.
  4. 풀 리퀘스트가 main에 머지돼요.
  5. CD가 시작돼요: Snowflake의 프로덕션 dbt 프로젝트 객체가 최신 코드를 반영하도록 업데이트돼요.
  6. 선택적으로 자동 스케줄링(예: Snowflake 태스크를 통한)을 배포해 수동 개입 없이 데이터 파이프라인이 스케줄에 따라 실행되게 할 수 있어요.

더 알아보기 (Learn more)