dbt Core v2.0: Fusion 엔진이 기본이 되면서 달라진 프로젝트 구조와 마이그레이션 기준

왜 지금 봐야 하나

2026년 7월 기준 dbt Core v2.0은 알파 단계(a4, 2026-07-06)지만, 아키텍처 방향은 이미 확정됐다. Snowflake Summit 2026(6월 1일)에서 dbt Labs는 v2.0의 핵심을 공개했다. Fusion 엔진(Rust 기반 런타임)을 오픈소스화하고, 이를 기반으로 dbt Core를 재구성한다는 내용이다.

이전 챕터(database-frontier/23)에서 다룬 dbt Core 1.12는 v2.0 마이그레이션 관점에서 중요한 징검다리였다. 1.12는 v2 파서를 opt-in 플래그(--use-v2-parser)로 테스트할 수 있고, 1.x에서 deprecated된 패턴들을 경고로 잡아준다.

이 글은 v2.0이 1.x와 무엇이 다른지, 어떤 브레이킹 변경이 있는지, 그리고 지금 1.x를 운영하는 팀이 무엇을 준비해야 하는지를 정리한다.

1.x와 무엇이 달라졌는가

Python 런타임의 한계

dbt Core 1.x의 핵심 런타임은 Python으로 작성됐다. 프로젝트 규모가 커질수록 파싱 시간이 선형 이상으로 증가했다. 모델 수천 개를 가진 팀은 dbt compile이나 dbt parse에 수십 초를 소비했다. CI 파이프라인에서 변경된 모델만 선택적으로 실행하는 Slim CI가 필수가 된 이유도 여기 있다.

더 근본적인 문제는 언어 명세의 부재였다. 1.x는 YAML 구조나 Jinja 매크로 사용에 관대했다. 특정 패턴이 경고 없이 동작하다가 버전이 올라가면 예기치 않게 깨지는 상황이 반복됐다. 에코시스템 도구(IDE 플러그인, 린터, 카탈로그)가 dbt 프로젝트를 파싱하는 안정적인 인터페이스가 없어서 각자 부분 구현을 유지해왔다.

v2.0: Rust 기반 Fusion 엔진

v2.0의 핵심은 Fusion 엔진이다. Fusion은 Rust로 작성된 dbt 런타임으로, 1.x의 Python 파서와 실행 엔진을 대체한다. 파싱 속도는 기존 대비 30배 이상 빠르다고 dbt Labs가 밝혔다. 대형 프로젝트에서 수십 초 걸리던 파싱이 1초 이내로 줄어든다.

Fusion은 그동안 dbt Cloud 전용으로만 제공됐으나, v2.0에서 처음으로 오픈소스화됐다.

두 가지 배포판

v2.0은 하나의 버전이지만 두 가지 배포판으로 나뉜다.

dbt-core(OSS): Apache 2.0 라이선스. Fusion 엔진의 핵심 파서와 런타임을 포함한다. CLI, 어댑터 인터페이스, 프로젝트 파싱, 모델 실행 등 기본 기능을 포함한다.

dbt(Fusion 배포판): dbt Labs의 proprietary 라이선스. dbt Mesh, dbt Explorer, dbt Cloud와의 연동 기능, 고급 상태 관리 등을 추가로 포함한다.

오픈소스 사용자는 dbt-core만으로 대부분의 작업을 처리할 수 있다. dbt Mesh나 다중 프로젝트 상태 공유가 필요하면 dbt 배포판이 필요하다.

v2.0의 주요 신기능

Parquet Artifact

1.x의 manifest.json은 모델 수천 개를 가진 프로젝트에서 수백 MB에 달했다. 브라우저에서 dbt docs serve를 열면 이 JSON을 전부 파싱하느라 수 초가 걸렸다. CI에서 Slim CI를 구현하려면 manifest.json을 파싱하는 커스텀 스크립트가 필요했다.

v2.0은 manifest.json을 Parquet 아티팩트로 대체한다. Parquet는 컬럼형 바이너리 포맷이기 때문에 용량이 작고, DuckDB나 Pandas로 직접 쿼리할 수 있다. 영향도 분석, 다운스트림 모델 탐색, CI 최적화를 SQL로 표현할 수 있게 된다.

dbt State

기존 Slim CI는 manifest.json을 두 시점 비교해서 변경된 모델을 찾는 방식이었다. dbt run --select state:modified+처럼 사용했다. 이 기능이 v2.0에서는 dbt State 플러그인으로 통합된다.

dbt State는 로직과 데이터가 변경되지 않은 노드를 건너뛰거나 클론한다. state:modified뿐만 아니라 변경의 종류(소스 변경, 상위 모델 변경, 설정 변경)를 더 세밀하게 추적한다.

dbt lint

v2.0에는 SQL 린터인 dbt lint가 내장된다. SQLFluff 호환 설정(.sqlfluff 파일, --noqa 주석)을 그대로 읽지만, Rust로 구현됐기 때문에 벤치마크 기준으로 단일 스레드 SQLFluff 대비 약 50배 빠르다고 dbt Labs가 밝혔다. CI에서 별도 SQLFluff 설치 없이 dbt lint만으로 SQL 품질 게이트를 구현할 수 있다.

dbt Docs v2

기존 문서는 브라우저가 manifest.json 전체를 로드해야 했다. Docs v2는 컴팩트 바이너리 인덱스를 사용한다. 전체 manifest를 메모리에 올리지 않고도 모델 탐색, 계보(lineage) 시각화, 테스트 상태 조회가 가능하다. 대형 프로젝트에서 초기 로드 시간이 대폭 줄어든다.

브레이킹 변경 목록

Fusion 엔진은 1.x보다 훨씬 엄격하게 YAML을 검증한다. 1.x에서 경고로만 나오던 패턴이 v2.0에서는 실행 자체를 막는다.

1) 엄격한 YAML 검증

description을 desciption으로 오타를 내도 1.x는 그냥 넘어갔다. v2.0은 에러로 처리한다. 알 수 없는 YAML 키, 잘못된 중첩 구조, 오타가 있는 필드명이 전부 실행을 차단한다.

2) 구 CLI 플래그 제거

1.x에서 deprecated된 --models 플래그가 v2.0에서 완전히 제거됐다. --select를 써야 한다. --exclude도 동일하게 확인해야 한다.

3) YAML 앵커 위치 변경

1.x에서 일부 팀이 YAML 앵커(&anchor, *anchor)를 임의로 사용하던 경우가 있었다. v2.0은 앵커를 anchors: 키 아래에만 허용한다.

4) get_relation() 없는 경우 동작 변경

1.x에서 관계가 없는 경우 get_relation()이 None을 반환하고 이를 출력하면 문자열 "None"이 나왔다. v2.0에서는 에러를 발생시킨다. 이 동작에 의존하는 커스텀 매크로가 있으면 수정이 필요하다.

5) 일부 패키지 비호환

에코시스템 패키지(어댑터 포함)가 아직 v2.0 호환 업데이트를 완료하지 않은 경우가 있다. 사용 중인 패키지가 v2.0을 지원하는지 먼저 확인한다.

마이그레이션 경로

dbt Labs가 권장하는 마이그레이션 순서는 세 단계다.

1단계: dbt Core 1.12로 업그레이드

1.12는 v2.0 마이그레이션을 위한 준비 릴리스다. 1.12에서 deprecated 경고를 모두 해소하는 것이 첫 번째 목표다. 1.12에는 opt-in Fusion 파서(--use-v2-parser)가 내장돼 있어서 v2.0 호환성을 사전 검증할 수 있다.

dbt --use-v2-parser parse
dbt --use-v2-parser compile

파싱 에러가 없으면 코어 YAML 구조는 v2.0 준비가 됐다는 의미다.

2단계: dbt-autofix 실행

pip install dbt-autofix
dbt-autofix --check  # 수정 가능한 문제 목록만 출력
dbt-autofix          # 자동 수정 적용

dbt Labs에 따르면 dbt-autofix가 호환성 문제의 약 80%를 자동으로 수정한다. CLI 플래그, 구 YAML 패턴, 일부 매크로 패턴이 대상이다.

3단계: 환경 순서대로 배포

v2.0 배포는 개발 → 스테이징 → 프로덕션 순으로 단계별로 진행한다. 각 환경에서 전체 dbt build를 실행하고 결과를 이전 버전과 비교 검증한다.

운영자가 확인해야 할 것

1) 알파 단계 리스크

2026년 7월 기준 v2.0은 알파(a4)다. 아직 프로덕션 사용을 권장하지 않는다. 그러나 1.12의 --use-v2-parser로 미리 호환성을 검증하고 deprecated 경고를 해소해두는 것은 지금 당장 해야 할 일이다.

2) 배포판 선택: dbt-core vs dbt

dbt Mesh 없이 단일 프로젝트를 운영하는 팀이라면 dbt-core(OSS)로 충분하다.

3) Parquet artifact 연동

기존에 manifest.json을 직접 파싱하는 커스텀 스크립트(메타데이터 추출, 영향도 분석, Slim CI 구현 등)가 있다면 Parquet artifact에 맞게 수정이 필요하다. DuckDB를 사용하면 SQL로 쿼리할 수 있어서 복잡한 파싱 코드가 단순해진다.

4) SQL 린터 전환

팀이 기존에 SQLFluff를 독립적으로 실행하고 있었다면, v2.0으로 마이그레이션 후 dbt lint로 통합할 수 있다. .sqlfluff 설정 파일을 그대로 사용할 수 있고, CI 시간이 단축된다.

도입 전 체크리스트

• [ ] 사용 중인 dbt 버전을 1.12로 업그레이드하고 모든 deprecated 경고를 해소한다.
• [ ] dbt --use-v2-parser parse를 실행하고 파싱 에러 유무를 확인한다.
• [ ] dbt-autofix로 자동 수정 가능한 문제를 처리하고 나머지를 수동으로 수정한다.
• [ ] 사용 중인 어댑터와 커뮤니티 패키지의 v2.0 지원 상태를 확인한다.
• [ ] manifest.json을 직접 파싱하는 스크립트를 파악하고 Parquet artifact 전환 계획을 세운다.
• [ ] dbt-core(OSS)와 dbt(Fusion 배포판) 중 팀 요구사항에 맞는 것을 선택한다.
• [ ] v2.0이 GA 될 때 개발 환경에서 먼저 전환하고 결과를 검증한다.

한 문장으로

dbt Core v2.0은 Rust Fusion 엔진으로 파서를 교체해 30배 빠른 파싱을 제공하고, Parquet artifact·dbt State·dbt lint를 표준 기능으로 통합하되, 엄격한 YAML 언어 명세 도입으로 1.x에서 경고로만 나오던 패턴이 이제는 실행을 막는다는 점이 마이그레이션의 핵심이다.

References

• dbt Core v2 is here: still open source, now rebuilt for what's next (dbt Labs Blog): https://docs.getdbt.com/blog/dbt-core-v2-is-here
• Upgrading to v2.0 (dbt Developer Hub): https://docs.getdbt.com/docs/dbt-versions/core-upgrade/upgrading-to-v2
• About dbt versions (dbt Developer Hub): https://docs.getdbt.com/docs/dbt-versions
• Upgrading to the dbt Fusion engine (dbt Developer Hub): https://docs.getdbt.com/docs/dbt-versions/core-upgrade/upgrading-to-fusion
• dbt Fusion: 30x Faster parsing and why Migration matters (Data Engineer Hub): https://dataengineerhub.blog/articles/dbr-fusion-engine-migration-guide
• dbt-core roadmap: 2026-06 announcing v2 (GitHub): https://github.com/dbt-labs/dbt-core/blob/main/docs/roadmap/2026-06-announcing-v2.md
• dbt Core v2.0: The Biggest Evolution of dbt Since Its Launch (Medium): https://dataengg22.medium.com/dbt-core-2-0-the-biggest-evolution-of-dbt-since-its-launch-3aaaf37a6ce6
• dbt Core Updates — July 2026 (Releasebot): https://releasebot.io/updates/dbt-labs/dbt-core