dbt Core vs Cloud, Airflow 연동, 상태 기반 CI/CD
50 dbt Interview Questions for Data Engineers (Real Answers, 2026) — 미상 (데이터 엔지니어링 커리어 블로그, 2026) Section 5: Production & Deployment, Q39-Q43 (pp.12-14)
이 모듈을 다 읽으면
- dbt Core와 dbt Cloud의 책임 분리와 각각을 선택하는 팀의 특징을 설명할 수 있다
- Airflow에서 dbt를 실행하는 패턴(단일 태스크 vs Cosmos)의 장단점을 판단할 수 있다
- manifest.json과 state:modified 선택이 어떻게 CI를 빠르게 만드는지 설명할 수 있다
dbt Core는 무료 오픈소스 CLI이고 dbt Cloud는 그 위에 웹 IDE, 잡 스케줄링, CI/CD 통합, 환경 관리, 호스팅 문서 사이트를 얹은 유료 SaaS다. 프로덕션에서는 Airflow의 BashOperator/KubernetesOperator나 Astronomer의 cosmos 라이브러리로 dbt를 실행하며, CI 파이프라인은 프로덕션 manifest와 state:modified+ 선택을 이용해 변경된 모델과 그 다운스트림만 빌드함으로써 빠른 피드백을 얻는다.
dbt Core vs dbt Cloud, Airflow 연동
dbt Core는 로컬이나 서버에 설치하는 무료 오픈소스 CLI다. dbt Cloud는 Core 위에 웹 IDE, 잡 스케줄링, CI/CD 통합, 환경 관리, 호스팅 문서 사이트를 더한 유료 SaaS 플랫폼이다. Core는 완전한 통제권을 주지만 인프라를 직접 운영해야 하고, Cloud는 관리형 인프라를 주는 대신 비용이 든다. 대체로 엔터프라이즈 팀은 Cloud를, 오픈소스 중심 팀은 Airflow나 GitHub Actions와 함께 Core를 쓴다.
Airflow에서 프로덕션으로 dbt를 실행하는 표준 패턴은 컨테이너 안에서 dbt build --target prod를 실행하는 BashOperator나 KubernetesOperator다. 더 정교한 구성은 Astronomer의 cosmos 라이브러리를 쓰는데, 이는 dbt manifest를 파싱해 dbt 모델마다 개별 Airflow 태스크를 만들어 Airflow UI에서 모델 단위 관측성(observability)을 제공한다. 안티패턴은 dbt 전체를 실행하는 단일 Airflow 태스크다 — 모델 하나가 실패해도 모델 단위로 재시도할 수 없기 때문이다.
참고: 2025년 dbt Labs는 Rust로 새로 작성된 dbt Fusion 엔진을 공개했다. 이는 정적 분석 기반의 더 빠른 SQL 컴파일과 다중 웨어하우스 지원을 목표로 하며, 로컬 CLI 경험과 Cloud 관리 기능 사이의 경계를 점차 흐리고 있다. 이 블로그가 다루는 'Core vs Cloud' 이분법은 여전히 큰 그림에서는 유효하지만, 최신 동향으로 Fusion 엔진의 존재도 알아두면 좋다.
핵심 포인트
- dbt Core: 무료 오픈소스 CLI, 인프라는 직접 운영. dbt Cloud: Core 위에 웹 IDE·스케줄링·CI/CD·환경 관리를 더한 유료 SaaS
- Airflow에서는 BashOperator/KubernetesOperator로 컨테이너 안에서 dbt build --target prod를 실행하는 것이 표준 패턴
- Astronomer의 cosmos는 dbt manifest를 파싱해 모델별 개별 Airflow 태스크를 생성, 모델 단위 관측성과 재시도를 가능하게 한다
- 단일 Airflow 태스크로 dbt 전체를 실행하는 것은 모델 단위 재시도가 불가능한 안티패턴이다
- 2025년 공개된 dbt Fusion(Rust 기반 신규 컴파일/실행 엔진)은 Core/Cloud 경계를 점차 흐리는 최신 동향이다
CI/CD, manifest.json, state:modified
최소한의 CI 파이프라인은 다음과 같다: 모든 PR에서 프로덕션의 슬림(slim) manifest를 이용해 CI 스키마에 대해 dbt build --select state:modified+를 실행한다. 이는 변경된 모델과 그 다운스트림 의존자만 빌드하고 테스트를 실행한다. 테스트를 통과하면 PR을 머지해도 안전하다. dbt Cloud는 이를 (지연된 상태를 이용하는 CI 잡으로) 기본 내장하고 있다. Core에서는 GitHub Actions나 GitLab CI에서 프로덕션 manifest.json을 내려받아 --state ./prod-manifest/를 전달하는 식으로 직접 구성한다.
manifest는 모든 dbt 실행마다 생성되는 JSON 파일로, 프로젝트의 모든 모델·테스트·소스·매크로와 그 컴파일된 SQL에 대한 완전한 기술(description)을 담는다. 이는 문서 사이트, 리니지 그래프, 그리고 결정적으로 상태 기반 선택(state-based selection)을 구동한다. 현재 manifest를 이전 manifest와 비교해 dbt는 어떤 모델이 바뀌었는지 판단할 수 있고, 이것이 state:modified 선택을 가능하게 한다. 프로덕션 manifest는 아티팩트로 취급해 S3나 CI 캐시에 저장해야 한다.
state:modified 선택은 현재 프로젝트를 이전 manifest와 비교해 SQL, 설정, 상류 의존성이 바뀐 모델만 고른다. + 연산자와 결합하면(state:modified+) 다운스트림 모델도 함께 고른다. 이것이 dbt CI를 빠르게 만드는 핵심이다 — 500개 모델을 전부 빌드하는 대신 PR에서 바뀐 3개 모델과 그 10개 의존자만 빌드한다. 상태 기반 선택이 없다면 CI 잡은 실용적이라 하기엔 너무 느려질 것이다.
핵심 포인트
- 최소 CI 파이프라인: 프로덕션 슬림 manifest 기준으로 dbt build --select state:modified+를 PR마다 실행한다
- manifest.json은 모델·테스트·소스·매크로·컴파일된 SQL 전체를 기술하며 문서 사이트·리니지·상태 기반 선택의 근거가 된다
- state:modified(+)는 변경된 모델(과 다운스트림)만 골라 CI 빌드 범위를 프로젝트 전체에서 실제 변경분으로 좁혀 CI를 빠르게 만든다
- dbt Cloud는 지연된 상태(deferred state) CI 잡을 기본 제공하고, Core에서는 프로덕션 manifest.json을 --state로 직접 전달해야 한다