LLM WikiAccess-protected knowledge portal
← 스터디 홈
127편 · 약 6분

dbt Core 2.0 Fusion 엔진: Rust 런타임 오픈소스화와 Parquet 아티팩트로 데이터 모델 빌드 기반을 바꾼 방법

배경: dbt Core가 감당하지 못한 규모

dbt는 데이터 모델을 SQL로 정의하고 의존성 그래프를 따라 실행하는 변환 도구다. 수백 개 모델 규모에서는 잘 동작하지만, 수천 개 모델이 얽힌 대형 프로젝트에서는 두 가지 병목이 눈에 띈다.

첫째, 파싱 속도다. dbt Core는 Python으로 모든 모델 파일을 해석하고 의존성 그래프를 구성한다. 모델이 늘어날수록 dbt parse나 dbt compile 시간이 선형에 가깝게 증가한다. 둘째, 아티팩트 크기다. manifest.json이 수백 MB를 넘는 프로젝트도 생긴다. 이 파일을 CI에서 읽거나 문서 사이트에서 렌더링하는 데도 시간이 걸린다.

dbt Labs는 이 문제를 Rust로 작성한 새 런타임 — Fusion 엔진 — 으로 해결하려 했다. 2026년 6월 1일, Fivetran과의 합병 완료와 함께 dbt Core 2.0 알파가 출시되었고, Fusion 엔진의 핵심 Rust 코드가 Apache 2.0 라이선스로 공개되었다.

dbt Core 2.0의 구조

SQL 모델
models/**/*.sql
↓
YAML 설정
sources, tests
→
Fusion 런타임 (Rust)
병렬 파서
↓
DAG 분석기
↓
SQL 생성기
→
DW 어댑터
BigQuery, Snowflake…
Parquet 아티팩트
manifest.parquet
dbt Core 2.0 빌드 파이프라인 — Rust 파서가 모델 그래프를 구성하고 Parquet 아티팩트를 출력한다

핵심 변화는 세 가지다.

1. 공유 Rust 런타임. dbt Core와 상용 Fusion 엔진이 같은 Rust 코어를 공유한다. 이전에는 Core(Python)와 Fusion(Rust)이 별개 코드베이스로 발전해 기능 차이가 생겼다. 2.0부터는 오픈소스 사용자도 같은 고성능 기반 위에서 dbt를 실행한다.

2. 대규모 프로젝트 파싱 속도 개선. Rust 파서는 멀티스레드로 모델 파일을 병렬 처리한다. 가장 큰 dbt 프로젝트에서 파싱 시간 단축 효과가 크다. 구체적인 수치는 프로젝트 구성에 따라 다르다.

3. Parquet 아티팩트. manifest.json 대신 manifest.parquet을 출력한다. DuckDB나 AI 에이전트가 직접 쿼리할 수 있고, 컬럼형 포맷이라 특정 필드만 읽을 때 네트워크·파싱 비용이 줄어든다.

Fusion 엔진 오픈소스화의 의미

Fusion은 원래 dbt Cloud 전용 고성능 런타임이었다. 오픈소스 Core와 상용 Fusion 사이에서 기능 차이가 벌어지면서, 대형 팀은 클라우드 버전이 아니면 성능 문제를 해결하기 어려운 상황이었다.

2.0은 그 경계를 없앴다. Fusion의 핵심 Rust 코드가 Apache 2.0으로 공개되어, 자체 인프라에서 dbt를 운영하는 팀도 같은 런타임 이점을 누릴 수 있다. dbt Labs의 수익 모델은 Fusion 엔진 자체가 아니라 dbt Cloud의 스케줄링·모니터링·협업 기능으로 옮겨간다.

Parquet 아티팩트 활용 패턴

JSON 대비 Parquet 아티팩트의 실용적 차이는 두 가지다.

첫째, 쿼리 가능성이다. manifest.json에서 특정 모델의 의존성을 찾으려면 JSON 파싱 후 전체 트리를 탐색해야 한다. manifest.parquet는 DuckDB로 직접 SQL 쿼리를 날릴 수 있다.

-- 예: 특정 소스에 의존하는 모델 목록
SELECT unique_id, name FROM read_parquet('manifest.parquet')
WHERE depends_on LIKE '%source.raw_events%';

둘째, AI 에이전트 통합이다. Parquet는 Arrow IPC 포맷과 호환되어, LLM 에이전트나 데이터 카탈로그 도구가 선택적 컬럼만 읽어 컨텍스트로 활용하기 쉽다.

언어 사양 정형화

dbt 2.0은 언어 사양(language spec)을 처음으로 공식화했다. 이전까지는 YAML 설정의 어느 키가 어떤 타입을 받는지 문서와 구현이 다른 경우가 있었다. 2.0부터는 파서가 사양을 강제하므로, 오타나 타입 불일치가 런타임 오류 대신 파싱 단계에서 잡힌다.

이는 dbt 위에 도구를 만드는 팀(IDE 플러그인, 린터, 카탈로그)에도 이점이다. 안정적인 사양을 기준으로 파서를 구현할 수 있다.

도입 체크리스트

dbt Core 1.x에서 2.0 알파로 이전을 검토하는 팀이 확인해야 할 항목이다.

  • 어댑터 호환성: 사용 중인 dbt-<adapter> 패키지가 2.0을 지원하는지 확인. 초기 알파 단계에서는 BigQuery·Snowflake·Databricks 어댑터부터 지원된다.
  • Parquet 아티팩트 파이프라인: CI에서 manifest.json을 파싱하는 스크립트가 있다면 Parquet 읽기로 교체하거나 JSON 출력 옵션 유지 여부를 결정한다.
  • 언어 사양 위반 체크: dbt parse를 2.0으로 실행하면 기존 프로젝트에서 사양 위반이 발견될 수 있다. 마이그레이션 전 드라이런으로 오류 목록을 먼저 확인한다.
  • 알파 단계 유의: 2.0.0-alpha.2까지 출시된 시점 기준이므로, 프로덕션 도입 전에 릴리스 노트와 알려진 이슈를 재확인한다.

References

  • https://docs.getdbt.com/blog/dbt-core-v2-is-here
  • https://github.com/dbt-labs/dbt-core/blob/main/docs/roadmap/2026-06-announcing-v2.md
  • https://github.com/dbt-labs/dbt-core/releases/tag/v2.0.0-alpha.2
  • https://docs.getdbt.com/docs/fusion/fusion-releases
  • https://www.brooklyndata.co/ideas/2026/06/01/dbt-core-v2_0-is-here-and-the-real-story-isnt-the-one-in-the-headline