Slim CI와 defer to production에 dbt 아티팩트 사용

Slim CI와 defer to production에 dbt 아티팩트 사용

dbt 프로젝트 객체를 사용하면 최근 프로덕션 실행의 아티팩트를 개발 및 CI 워크플로에서 재사용할 수 있어요. Snowflake는 배포된 프로덕션 객체에서 이 아티팩트를 직접 제공하므로 별도 아티팩트 저장소를 유지할 필요가 없어요. Slim CI는 아티팩트를 사용해 변경된 리소스와 그 다운스트림 의존성을 처리하고, defer는 빌드되지 않은 업스트림 참조를 기존 프로덕션 릴레이션으로 해결해요. 함께 이 기능들은 dbt 실행 시간을 단축하고 웨어하우스 사용을 줄여요.

이 가이드가 설명하는 내용:

• state 아티팩트 선택.
• Snowflake Workspaces 또는 Snowflake CLI에서 Slim CI와 defer 사용.
• 실패한 실행에서 복구.
• dbt 프로젝트 객체를 동시에 실행.
• 특정 쿼리의 dbt 아티팩트 검색.

📌 이 페이지에서 설명하는 일부 기능은 가변 live 버전을 사용하는 dbt 프로젝트 객체가 필요해요. live 버전 객체를 얻으려면 2026_06 동작 변경 번들에 옵트인하거나, Snowflake 계정 담당자에게 별도의 단일 live 버전 기능을 활성화하도록 요청하세요. 그런 다음 객체를 생성하거나 교체하고, 기존 버전 객체는 SYSTEM$MIGRATE_DBT_PROJECT로 마이그레이션하세요. 자세한 내용은 dbt 프로젝트 객체의 단일 가변 live 버전으로의 마이그레이션 문서를 참조하세요.

출처: Snowflake 문서

본문

개념(Concepts)

Slim CI와 defer to production

dbt state 선택은 실행 중인 프로젝트를 이전 실행의 아티팩트와 비교해요. 가장 중요한 state 아티팩트는:

• manifest.json: 이전 프로젝트의 리소스와 관계를 설명해요.
• run_results.json: 이전 명령이 처리한 리소스의 상태를 기록해요.
• sources.json: 소스 로드 타임스탬프를 포함한 소스 신선도(source freshness) 결과를 기록해요.

--state <path> 옵션은 dbt에 이 아티팩트를 어디서 읽을지 알려줘요. dbt 프로젝트 객체의 경우 임포트(import)를 사용해 아티팩트를 실행의 ./imports 디렉터리 아래에 마운트한 다음 --state를 마운트된 디렉터리를 가리키게 해요.

서로 다른 셀렉터가 서로 다른 아티팩트를 필요로 해요. state:modified+는 manifest.json을, result:error+는 run_results.json을, source_status:fresher+는 현재 소스 신선도 결과를 이전 sources.json과 비교해요. 셀렉터는 이전 실행에서 가져온 결과에 해당 아티팩트가 포함되어 있을 때만 작동해요. 소스 신선도 사전 요구 사항과 비교 동작은 소스 상태 선택 문서를 참조하세요.

Slim CI는 state 셀렉터를 사용해 CI가 처리하는 리소스를 제한해요. state:modified+ 셀렉터는 state 아티팩트 대비 변경된 리소스와 그 다운스트림 의존성을 선택해요. 전체 프로젝트를 재빌드하고 재테스트하는 대신 변경된 리소스와 그 다운스트림 의존성만 검증하고 싶을 때 Slim CI를 사용하세요.

Slim CI는 증분 모델과 다릅니다:

• Slim CI는 프로젝트 DAG에서 변경되지 않은 노드를 건너뛰어요.
• 증분 모델은 선택된 모델이 실행될 때 새 행이나 변경된 행만 처리해요.

Slim CI는 또한 dbt State Aware Orchestration과 다릅니다. Slim CI는 dbt 아티팩트와 --state, --select state:modified+ 같은 셀렉터를 사용해요. State Aware Orchestration은 관계 메타데이터를 사용해 모델을 실행해야 하는지 결정해요.

--defer 옵션은 참조된 모델이 현재 실행에 선택되지 않았을 때 dbt가 업스트림 ref()를 어떻게 해결하는지 제어해요. 프로덕션 아티팩트가 state 참조로 마운트되면 dbt는 CI target에서 그 모델을 재빌드하는 대신 기존 프로덕션 릴레이션을 사용할 수 있어요.

state 선택과 defer는 서로 다른 문제를 해결해요:

• state 선택은 CI가 어떤 노드를 처리할지 결정해요.
• defer는 dbt가 빌드되지 않은 업스트림 관계를 어디서 찾을지 결정해요.
• 선택된 target은 CI가 처리하는 모델을 어디에 쓸지 결정해요.

auto compile과 writeback 이해하기

Auto compile은 배포에, writeback은 실행에 적용돼요:

• AUTO_COMPILE = TRUE면 Snowflake가 배포 중 dbt compile을 실행해요. 외부 접근 통합이 구성되면 Snowflake가 먼저 dbt deps를 실행한 다음 dbt compile을 실행해요. AUTO_COMPILE = FALSE로 설정하면 두 명령을 모두 건너뛰어요. Auto compile은 기본적으로 활성화돼요.
• DEFAULT_WRITEBACK은 이후 실행이 target 및 log 아티팩트를 live 버전에 기록할지 제어해요. 실행은 WRITEBACK으로 객체 기본값을 재정의할 수 있어요.

Auto compile은 Snowflake가 프로젝트 세부 정보를 표시할 수 있도록 컴파일 아티팩트를 live 버전에 기록해요. SYSTEM$DBT_GET_LAST_*_RUN_TARGET 함수가 재사용할 수 있는 실행 결과는 만들지 않아요.

Writeback을 비활성화하면 실행이 target 및 log 아티팩트를 live 버전에 기록하지 못하게 해요. dbt 프로젝트 객체를 동시에 실행할 계획이라면 Snowflake는 writeback 비활성화를 권장해요. Snowflake는 이 설정과 관계없이 쿼리별 결과 아티팩트와 아카이브를 저장해요.

검색 방법은 프로그래밍 방식으로 dbt 아티팩트와 로그 접근 문서를 참조하세요.

state 아티팩트 선택

이전 실행을 식별하는 방법과 일치하는 시스템 함수를 선택하세요:

1. 일반적인 Slim CI 워크플로에는 SYSTEM$DBT_GET_LAST_SUCCESSFUL_RUN_TARGET을 사용해요. 결과를 AS 'state'로 임포트하면 Snowflake가 target 아티팩트를 ./imports/state에 마운트해요.
2. 가장 최근 실패한 자격 있는 실행에서 복구하려면 SYSTEM$DBT_GET_LAST_FAILED_RUN_TARGET을 사용해요.
3. 성공인지 실패인지와 관계없이 가장 최근 완료된 자격 있는 실행이 필요하면 SYSTEM$DBT_GET_LAST_RUN_TARGET을 사용해요.
4. 필요로 하는 실행의 쿼리 ID를 안다면 SYSTEM$LOCATE_DBT_ARTIFACTS 또는 SYSTEM$LOCATE_DBT_ARCHIVE를 사용해요. 결과를 AS 'state'로 임포트하면 Snowflake가 쿼리 범위 결과를 ./imports/state 아래에 마운트하고, dbt 아티팩트는 ./imports/state/target에 있어요.

SYSTEM$DBT_GET_LAST_*_RUN_TARGET 함수는 dbt 프로젝트 객체, 완료 상태, 자격 있는 명령 필터, target 경로로 최근 실행을 선택해요. SYSTEM$LOCATE_DBT_* 함수는 특정 실행의 쿼리 ID를 요구해요.

기본적으로 SYSTEM$DBT_GET_LAST_*_RUN_TARGET 함수는 compile, build, run, docs generate 실행을 검색해요. 신선도 결과를 찾으려면 명령 필터로 'source freshness'를 전달하세요. 이 함수들은 일치하는 실행의 target 위치를 반환해요.

이 함수들은 dbt 명령을 실행하거나 누락된 아티팩트를 생성하지 않아요.

IMPORTS에서 사용하면 SYSTEM$DBT_GET_LAST_*_RUN_TARGET 함수는 manifest.json, run_results.json, 있고 sources.json을 포함한 독립 target 아티팩트를 임포트해요. SYSTEM$LOCATE_DBT_ARTIFACTS는 특정 쿼리의 results 디렉터리(dbt_artifacts.zip 포함)를 임포트하지만 ZIP 파일을 추출하지 않아요. 컴파일된 SQL 같은 아카이브 처리된 target과 logs가 필요하면 SYSTEM$LOCATE_DBT_ARCHIVE를 직접 사용하세요. 이 함수가 실행으로 ZIP 파일을 추출하는 유일한 방법이며, 실행은 최대 하나의 ZIP 파일을 추출할 수 있어요. 전체 아카이브를 임포트하는 것은 독립 아티팩트를 임포트하는 것보다 오래 걸릴 수 있어요. results 디렉터리의 파일 목록은 results 디렉터리 내용 문서를 참조하세요.

dbt state 아티팩트 사용을 위한 사전 요구 사항

CI 작업이 프로덕션 dbt 아티팩트를 가져오기 전에 다음이 있어야 해요:

• 지난 7일 이내에 자격 있는 실행이 한 번 이상 있는 프로덕션 dbt 프로젝트 객체.
• 프로덕션 객체에 MONITOR 권한이 있는 CI 역할.
• CI 작업이 관계를 만들거나 업데이트할 수 있는 별도 데이터베이스 또는 스키마.
• 테스터 dbt 프로젝트 객체를 배포하고 실행하는 데 필요한 권한.

배포 시점의 자동 컴파일은 SYSTEM$DBT_GET_LAST_*_RUN_TARGET 시스템 함수가 사용할 수 있는 dbt 아티팩트를 생성하지 않아요. 프로덕션 dbt 프로젝트 객체를 배포 후, 그리고 7일에 한 번 이상 실행해 자격 있는 dbt 아티팩트가 계속 사용 가능하게 하세요.

CI 역할에 프로덕션 객체에 대한 모니터링 접근을 부여해요:

GRANT MONITOR ON DBT PROJECT <database>.<schema>.production_project TO ROLE <ci_role>;

역할은 또한 웨어하우스와, 변경되지 않은 업스트림 참조가 해결되는 프로덕션 관계에 대한 접근이 필요해요.

Snowflake Workspaces에서 defer to production 사용

개발 중 state로 프로덕션 아티팩트를 사용하려면:

1. 실행 패널에서 Advanced options를 선택해요.
2. Defer to Production을 활성화해요.
3. 프로덕션 dbt 프로젝트 객체가 포함된 데이터베이스와 스키마를 선택한 다음 객체를 선택해요. dbt 프로젝트 객체는 그 객체에 MONITOR 권한이 있을 때만 나타나요. 객체는 또한 지난 7일 이내에 자격 있는 실행이 한 번 이상 있어야 해요.
4. state로 사용할 target 아티팩트를 선택해요: Last Successful Run(기본값), Last Failed Run Target, Last Run Target.
5. 변경된 노드와 그 다운스트림 의존성을 처리하려면 dbt 인수에 --select state:modified+를 추가해요.
6. dbt 명령을 실행해요.

워크스페이스는 선택한 target 아티팩트를 ./imports/state 아래로 임포트하고 명령에 자동으로 --defer와 --state ./imports/state를 추가해요. 선택한 옵션이 워크스페이스가 사용할 최근 실행 시스템 함수를 결정해요. 예를 들어 Last Successful Run을 선택하면 생성된 SQL은 다음과 유사할 수 있어요:

EXECUTE DBT PROJECT FROM WORKSPACE "USER$"."PUBLIC"."my_dbt_projects"
  ARGS = 'run --defer --state ./imports/state --select state:modified+'
  IMPORTS = (
    SYSTEM$DBT_GET_LAST_SUCCESSFUL_RUN_TARGET('sales_db.sales_schema.prod_sales_project') AS 'state'
  );

Snowflake CLI로 Slim CI 사용

다음 패턴은 자동 컴파일을 비활성화한 테스터 객체를 배포하고, 마지막 성공 프로덕션 실행에서 dbt 아티팩트를 가져오고, 하나의 선택적 dbt build로 DAG 순서대로 모델과 테스트를 실행해요:

snow dbt deploy tester_dbt_project \
  --source ./path/to/dbt_project \
  --no-auto-compile

snow dbt execute \
  --import "SYSTEM\$DBT_GET_LAST_SUCCESSFUL_RUN_TARGET('my_db.my_schema.production_dbt_project') AS 'state'" \
  tester_dbt_project \
  build --target dev --state ./imports/state --defer --select state:modified+

여러 위치에서 파일을 마운트하도록 --import를 여러 번 지정할 수 있어요. 각 별칭은 ./imports 아래의 하위 디렉터리를 명명해요. 예를 들어 AS 'state'는 반환된 아티팩트를 ./imports/state에 마운트해요. --state 옵션은 그 경로에서 아티팩트를 읽어요.

--import와 함께 SYSTEM$LOCATE_DBT_ARTIFACTS는 results 디렉터리(dbt_artifacts.zip 포함)를 임포트하지만 ZIP 파일을 추출하지 않아요. 컴파일된 SQL 같은 아카이브 처리된 target과 logs가 필요하면 SYSTEM$LOCATE_DBT_ARCHIVE를 직접 사용하세요. Snowflake가 아카이브를 자동으로 추출해요. 실행은 자동으로 최대 하나의 ZIP 파일을 추출할 수 있어요.

GitHub Actions는 Snowflake CLI로 배포할 때 저장소 URL, 브랜치, 커밋 메타데이터를 자동으로 공급해요. 다른 CI 러너에서는 dbt 프로젝트 객체가 소스로 추적 가능하도록 --git-url, --git-branch, --git-commit을 명시적으로 전달하세요.

각 풀 리퀘스트에 대해 격리된 데이터베이스로 --env와 --env-vars를 사용하는 종단 간 Slim CI 예시는 dbt Projects on Snowflake용 Slim CI와 PR별 데이터베이스로 CI/CD 설정 튜토리얼을 참조하세요.

실패한 실행에서 복구

run이나 build가 중간에 실패하면 전체 명령을 다시 실행하면 이미 성공한 작업이 반복돼요. dbt retry는 전체 재실행을 피할 수 있지만, 상속된 인수와 선택된 리소스로 이전 호출을 재생하므로 dbt가 다시 실행하는 것에 대한 제어가 적어요.

실패한 실행의 쿼리 ID를 안다면 SYSTEM$LOCATE_DBT_ARTIFACTS로 그 결과를 임포트한 다음 명시적 결과 셀렉터를 사용하세요:

EXECUTE DBT PROJECT my_dbt_project
  ARGS = 'build --state ./imports/state/target --select result:error+'
  IMPORTS = (
    SYSTEM$LOCATE_DBT_ARTIFACTS('<query_id>') AS 'state'
  );

쿼리 ID를 모른다면 SYSTEM$DBT_GET_LAST_FAILED_RUN_TARGET으로 가장 최근 실패한 실행의 state를 임포트한 다음 명시적 결과 셀렉터를 사용하세요:

EXECUTE DBT PROJECT my_dbt_project
  ARGS = 'build --state ./imports/state --select result:error+'
  IMPORTS = (
    SYSTEM$DBT_GET_LAST_FAILED_RUN_TARGET('my_db.my_schema.production_dbt_project', 'run,build') AS 'state'
  );

Snowflake CLI 사용:

snow dbt execute \
  --import "SYSTEM\$DBT_GET_LAST_FAILED_RUN_TARGET('my_db.my_schema.production_dbt_project', 'run,build') AS 'state'" \
  my_dbt_project \
  build --state ./imports/state --select result:error+

result:error+ 셀렉터는 오류가 난 리소스와 그 다운스트림 의존성을 다시 실행해요. result: 셀렉터는 --state가 run_results.json을 포함한 아티팩트(예: run 또는 build 명령의 아티팩트)를 가리켜야 해요.

실패한 테스트에는 1+result:fail+을 사용해 실패한 테스트, 그 부모 모델, 다운스트림 리소스를 다시 실행해요.

dbt 프로젝트 객체를 동시에 실행

데이터 팀은 보통 파이프라인의 독립적인 슬라이스를 서로 다른 주기로 실행해야 해요. 같은 dbt 프로젝트 객체를 동시에 실행해 각 슬라이스가 중복 배포된 객체 없이 최신 상태를 유지하게 할 수 있어요.

기본적으로 dbt 프로젝트 객체는 DEFAULT_WRITEBACK=TRUE이므로 동시 실행이 live 버전의 같은 디렉터리에 target 및 log 아티팩트를 쓸 수 있어요. 이 겹치는 쓰기 때문에 실행이 실패할 수 있어요. 격리 패턴 중 하나를 사용하세요:

1. 실행이 target 및 log 아티팩트를 live 버전에 유지할 필요가 없을 때는 writeback 비활성화를 선호해요. 이후 실행에 대해 기본적으로 writeback을 비활성화하려면 dbt 프로젝트 객체에 DEFAULT_WRITEBACK = FALSE를 설정하거나, WRITEBACK = FALSE 또는 --no-writeback으로 개별 실행에 대한 객체 기본값을 재정의해요.
2. writeback이 필요하면 각 실행에 대해 서로 겹치지 않는 별도의 target 및 log 디렉터리를 사용하세요.

배포 중 객체 기본값 설정

Snowflake CLI에서 --no-default-writeback을 사용해 이후 실행에 대해 writeback을 비활성화한 상태로 프로젝트를 만들거나 업데이트해요:

snow dbt deploy my_db.my_schema.my_dbt_project \
  --source ./path/to/dbt_project \
  --no-default-writeback

이 설정은 객체에 유지돼요. 이후 배포에서 플래그를 생략하면 기존 설정이 그대로 유지돼요. 기본 writeback 비활성화는 실행 시점 아티팩트 writeback에만 영향을 미쳐요. 자동 컴파일은 여전히 생성 또는 배포 중 컴파일된 아티팩트를 live 버전에 쓸 수 있어요. 자동 컴파일을 비활성화하려면 별도로 --no-auto-compile을 지정할 수 있어요.

SQL에서는 dbt_project.yml과 프로젝트 파일을 포함한 스테이지 디렉터리에서 객체를 만들 때 DEFAULT_WRITEBACK=FALSE를 설정해요:

CREATE OR REPLACE DBT PROJECT my_db.my_schema.my_dbt_project
  FROM '@my_db.my_schema.dbt_source_stage/my_dbt_project/'
  DEFAULT_WRITEBACK = FALSE;

CREATE OR REPLACE DBT PROJECT는 기존 객체를 다시 만들고 그 실행 기록을 제거해요. 기존 객체의 writeback 기본값만 바꾸려면 아래 ALTER DBT PROJECT ... SET을 사용하세요. 객체를 교체하지 않고 소스 파일을 업데이트하려면 ALTER DBT PROJECT ... DEPLOY를 사용하세요.

기존 객체의 기본값 변경

프로젝트를 재배포하지 않고 이후 실행에 대해 writeback을 비활성화하려면:

ALTER DBT PROJECT my_db.my_schema.my_dbt_project
  SET DEFAULT_WRITEBACK = FALSE;

한 실행에 대한 기본값 재정의

객체 기본값을 바꾸지 않고 개별 SQL 실행에 대해 writeback을 비활성화하려면:

EXECUTE DBT PROJECT my_db.my_schema.my_dbt_project
  ARGS = 'run'
  WRITEBACK = FALSE;

Snowflake CLI에서는 dbt 프로젝트 이름 앞에 --no-writeback을 전달해요:

snow dbt execute --no-writeback my_dbt_project run

실행이 WRITEBACK 또는 CLI writeback 플래그를 생략하면 객체의 DEFAULT_WRITEBACK 값을 사용해요. 아티팩트를 live 버전에 유지해야 하는 실행에 대해 비활성화된 객체 기본값을 WRITEBACK=TRUE 또는 --writeback으로 재정의할 수도 있어요.

Snowflake는 이 설정과 관계없이 쿼리별 결과 아티팩트와 아카이브를 저장해요. 검색 방법은 프로그래밍 방식으로 dbt 아티팩트와 로그 접근 문서를 참조하세요.

별도의 target 및 log 경로 사용

live writeback이 필요하다면 각 실행에 별도의 target 및 log 디렉터리를 지정해요:

EXECUTE DBT PROJECT my_db.my_schema.my_dbt_project
  ARGS = 'run --target-path target/pr_123 --log-path logs/pr_123';

Snowflake CLI:

snow dbt execute my_dbt_project \
  run --target-path target/pr_123 --log-path logs/pr_123

다음 제한 사항이 적용돼요:

• target 및 log 경로는 프로젝트 안의 디렉터리를 가리켜야 해요. Snowflake는 실행 결과와 함께 관련 없는 프로젝트 파일이 업로드되는 것을 피하기 위해 전용 하위 디렉터리를 가리킬 것을 권장해요.
• Snowflake는 각 target 및 log 디렉터리의 전체 내용을 실행 결과와 함께 업로드해요. 관련 없는 파일을 업로드하면 파일 수가 늘고 성능이 저하될 수 있어요.
• 동시 실행이 사용하는 target 및 log 디렉터리는 겹치면 안 돼요. 겹치는 쓰기 때문에 실행이 실패할 수 있어요.

배포 시점 자동 컴파일은 환경 변수로 정의된 커스텀 target 또는 log 경로를 지원하지 않아요. 이 커스텀 경로를 사용하려면 --no-auto-compile로 배포한 다음 compile을 수동으로 실행하세요.

특정 쿼리의 dbt 아티팩트 사용

가장 최근 자격 있는 실행이 필요로 하는 dbt 아티팩트를 갖고 있을 때 SYSTEM$DBT_GET_LAST_*_RUN_TARGET 함수가 가장 간단한 선택이에요. 특정 실행의 dbt 아티팩트를 사용해야 한다면 그 쿼리 ID를 사용하세요.

SYSTEM$LOCATE_DBT_ARTIFACTS로 쿼리 범위 results 디렉터리를 임포트해요:

EXECUTE DBT PROJECT my_db.my_schema.my_dbt_project
  ARGS = 'run --state ./imports/state/target --select result:error+'
  IMPORTS = (
    SYSTEM$LOCATE_DBT_ARTIFACTS('<query_id>') AS 'state'
  );

SYSTEM$LOCATE_DBT_ARTIFACTS는 dbt_artifacts.zip을 포함한 쿼리 범위 results 디렉터리를 임포트하지만 ZIP 파일을 추출하지 않아요. results 디렉터리를 ./imports/state 아래에 마운트하고 dbt 아티팩트는 그 target 하위 디렉터리에 있어요.

컴파일된 SQL 같은 아카이브 처리된 target과 logs가 필요하면 SYSTEM$LOCATE_DBT_ARCHIVE를 직접 사용하세요:

EXECUTE DBT PROJECT my_db.my_schema.my_dbt_project
  ARGS = 'run --state ./imports/state/target --select result:error+'
  IMPORTS = (
    SYSTEM$LOCATE_DBT_ARCHIVE('<query_id>') AS 'state'
  );

SYSTEM$LOCATE_DBT_ARCHIVE는 실행으로 ZIP 파일을 추출하는 유일한 방법이에요. 실행은 최대 하나의 ZIP 파일을 추출할 수 있어요. 전체 아카이브를 임포트하는 것은 독립 아티팩트를 임포트하는 것보다 오래 걸릴 수 있어요.

다른 아티팩트 기반 dbt 워크플로 사용

가변 live 버전은 또한 다음 워크플로를 지원해요:

• 부분 파싱(Partial parsing): writeback을 활성화하면 dbt가 호환 가능한 파싱 아티팩트를 target 경로에 유지하고 이후 실행에서 재사용할 수 있어요.
• 소스 신선도(Source freshness): 소스 신선도를 평가하고 sources.json을 target 경로에 쓰려면 source freshness를 실행해요. SQL 실행과 검색 예시는 소스 신선도 결과 검색 문서를 참조하세요.
• 프로젝트 정리: 구성된 target 디렉터리를 제거하려면 clean을 실행해요. 정리는 전부 아니면 전무예요. 자세한 내용은 dbt 프로젝트 객체 정리 문서를 참조하세요.

관측성(Observability)

Query History와 dbt 프로젝트 실행 기록을 사용해 개별 실행을 검사해요. dbt 프로젝트 객체의 live target 및 log 경로에는 writeback이 활성화될 때 아티팩트가 포함되는 반면, 쿼리별 결과 디렉터리는 writeback과 관계없이 별도 실행 아티팩트를 포함해요.

모니터링 절차, 아티팩트·로그 검색, 배포 메타데이터는 dbt Projects on Snowflake 모니터링 문서를 참조하세요. 쿼리별 아티팩트 위치는 SYSTEM$LOCATE_DBT_ARTIFACTS 및 SYSTEM$LOCATE_DBT_ARCHIVE 문서를 참조하세요.

참조(Reference)

다음 옵션과 시스템 함수가 주요 아티팩트 기반 워크플로를 구성해요:

옵션 또는 시스템 함수	범위와 목적
AUTO_COMPILE / --no-auto-compile	Snowflake가 배포 중 dbt 프로젝트를 컴파일할지 제어.
DEFAULT_WRITEBACK	이후 실행이 기본적으로 target 및 log 아티팩트를 live 버전에 기록할지 제어.
WRITEBACK / --writeback / --no-writeback	개별 실행에 대한 객체의 DEFAULT_WRITEBACK 설정 재정의.
--target-path / --log-path	target 및 log 디렉터리 지정. writeback이 필요할 때 동시 실행에는 별도 디렉터리 사용.
--import / IMPORTS	실행의 ./imports 디렉터리 아래에 파일 또는 아티팩트 마운트.
--state	이전 dbt 아티팩트를 포함한 디렉터리 식별.
state:modified+	변경된 리소스와 그 다운스트림 의존성 선택.
--defer	state 아티팩트가 설명하는 관계를 사용해 빌드되지 않은 참조 해결.
SYSTEM$DBT_GET_LAST_SUCCESSFUL_RUN_TARGET	최근 성공 실행의 객체 범위 state 반환. ./imports/state에 임포트.
SYSTEM$DBT_GET_LAST_FAILED_RUN_TARGET	실패한 실행 복구를 위해 최근 실패 실행의 객체 범위 state 반환. ./imports/state에 임포트.
result:error+ / 1+result:fail+	오류가 난 리소스 또는 실패한 테스트와 실패한 실행 복구에 필요한 관련 리소스 선택.
SYSTEM$DBT_GET_LAST_RUN_TARGET	가장 최근 완료된(성공 또는 실패) 실행의 객체 범위 state 반환. ./imports/state에 임포트.
SYSTEM$LOCATE_DBT_ARTIFACTS	알려진 쿼리 ID에 대한 쿼리 범위 results 디렉터리 반환. state는 ./imports/state/target에 있음.
SYSTEM$LOCATE_DBT_ARCHIVE	알려진 쿼리 ID에 대한 완전한 쿼리 범위 아카이브 반환. 추출된 state는 ./imports/state/target에 있음.

더 알아보기 (Learn more)

• dbt Projects on Snowflake 모니터링
• dbt Projects on Snowflake에서 CI/CD 통합 설정 튜토리얼
• dbt Projects on Snowflake 개요