[dbt] dbt는 무엇이고, 언제 활용될까?

(생성 AI를 사용한 내용은 🤖 아이콘으로 표기해두었습니다)

 

I. dbt란?

Data Build Tool의 약자로, 데이터 웨어하우스에 있는 데이터를 신뢰할 수 있는 분석용 데이터로 변환하기 위한 transformation workflow 툴임.

dbt를 통해 다양한 환경에서 쌓이는 raw 데이터를 중복 없이, 검증된 규칙에 따라 구조화된 형태로 만듦으로써 downstream BI/도구에서 쓸 수 있도록 변환함.

---

 

dbt의 작동 방식

1) ELT 워크플로우에서 “T”단계 담당

dbt는 “Extract → Load → Transform” 중에서 Transform 단계만 담당.
즉, 데이터를 다른 시스템에서 추출하거나 로드하지는 않고, 이미 데이터 웨어하우스에 들어온 데이터를 변환(transformation) 하는 데 집중.

 

즉, 다른 도구(Fivetran, Stitch 등)로 데이터를 웨어하우스로 로드 -> dbt로 그 데이터를 정리/변형해서 BI에 적합한 구조로 생성

 

2) SQL을 코드처럼 다루는 방식

dbt는 SQL을 단순한 쿼리로 실행하는 것이 아니라, SQL을 버전 관리 가능한 코드 처럼 다룸.

• 각 변환 작업을 model로 정의
• dbt가 자동으로 의존 관계를 파악해서 올바른 순서로 실행
• 모델 간 종속성을 데이터 DAG로 시각화 가능

 

3) 소프트웨어 엔지니어링 관행 적용

dbt는 코드 관리와 품질 보증을 위해 아래와 같은 기법을 제공.

• 버전 관리 — Git 등을 통해 변환 로직을 소스 코드 수준으로 형상 관리
• 테스트 — 데이터 품질 테스트(예: null 값 없음, unique, 예상 범위 등) 자동화
• 문서화 — 모델/컬럼의 설명, lineage 문서 자동 생성
• 자동 실행(CI/CD) — 변경점을 테스트, 검토, 배포까지 자동화
• 테스트 및 검증 — 빌드 과정에서 오류/문제 발견 가능

---

dbt 프로젝트 구조 살펴보기

dbt 프로젝트는 dbt가 어떻게 데이터 변환을 수행할지 알려주는 구성임.

dbt init  커맨드 입력 시 아래와 같은 패키지가 자동으로 구성됨.

my_dbt_project/
├── dbt_project.yml                   # 프로젝트 설정 파일
├── profiles.yml                      # (로컬) 데이터 웨어하우스 연결 설정
├── README.md                        # 프로젝트 설명
├── models/                          # 변환 SQL 모델
│   ├── staging/                     # 스테이징 레이어
│   │   ├── stg_orders.sql
│   │   ├── stg_customers.sql
│   │   └── stg_products.sql
│   ├── intermediate/                # 비즈니스 로직 레이어
│   │   ├── int_customer_orders.sql
│   │   └── int_sales_summary.sql
│   └── marts/                       # 최종 분석/비즈니스 테이블
│       ├── core/
│       │   ├── dim_customers.sql
│       │   ├── dim_products.sql
│       │   └── fct_sales.sql
│       └── marketing/
│           └── mrt_customer_ltv.sql
├── seeds/                          # 정적 데이터(CSV 등)
│   └── currency_rates.csv
├── snapshots/                      # 스냅샷 정의 (변경 추적용)
│   └── customer_snapshot.sql
├── macros/                        # 재사용 가능한 매크로 함수
│   └── generate_schema_name.sql
├── analyses/                     # 일회성/분석용 쿼리
│   └── ad_hoc_analysis.sql
└── tests/                        # 커스텀 테스트 SQL
    └── assert_positive_total.sql

dbt_project

• dbt에서 가장 중요한 파일

 

models

• dbt는 3가지 하위 폴더로 구성하길 제안함.
  • staging : 모든 raw데이터 용 sql 소스를 넣어두는 곳, 간단한 정제(데이터 타입, 컬럼명 재정의 등)를 위한 staging file을 넣어둠.
  • intermediate : 최종 사용자에게 노출하고 싶지 않으면서, staging 단계보단 무거운 정제가 들어간 로직을 넣어두는 곳.
  • marts : 최종 사용자에게 노출될 모든 파일이 있는 곳으로, 사용될 준비가 된 클린한 테이블만 노출함.

 

seeds

• csv이나 flat file을 업로드할 수 있는 공간
• 완벽한 테이블을 만들기 전에 프로토타입으로 테스트하기 위해 사용할 수 있음.

 

snapshots

• 당시의 상태를 보여주는 테이블로, 컬럼의 히스토리를 추적하는 데에 유용함.

 

macros

• 파이썬 함수처럼 재사용가능한 매크로 로직을 넣어두는 곳

 

analyses

• 표출하고 싶지 않은 sql 파일들을 넣어두는 곳
• (주로 DQ리포트, 일회용, 분석용으로 사용하는 sql 파일들..)

 

tests

• 데이터의 오류를 잡아내기 위한 sql 포맷의 assertion 문을 넣어놓는 공간
• 단일 테스트를 위한 공간

 

---

II. dbt 활용 사례

dbt는 그럼 언제 활용되는 걸까?

---

Airflow 와 dbt

dbt를 접하고 우선 처음으로 든 생각은 airflow와 dbt는 어떤게 다른거지? 였다. 

airflow도 마찬가지로 dag를 스케줄링하여 transform단계를 수행하는 거고, dbt 역시 transform 단계를 수행하는 툴이기 때문에, 언제 airflow 대신 dbt를 사용하는 지 헷갈렸다.

 

🤖 dbt와 airflow의 차이점은?

	Aiflow	dbt
해결하는 의존성	Task / Job 실행 순서	데이터 모델(테이블) 간 의존성
의존성 정의 방식	Python 코드로 명시 (task_a >> task_b)	SQL 내부 ref()로 자동 추론
SQL 내부 구조 인식	❌ SQL 내용 모름	✅ 어떤 모델을 참조하는지 정확히 인식
컬럼/테이블 변경 영향도	❌ 수동 관리	✅ downstream 모델 자동 반영
데이터 품질 의존성	❌ Task 성공/실패만 판단	✅ test 실패 시 downstream 차단 가능
문서화	❌ 별도 작성 필요	✅ DAG + 모델 문서 자동 생성
사용 위치	오케스트레이션 레이어	데이터 웨어하우스 내부
대표 역할	언제 실행할지	무엇을 어떻게 만들지

 

그래서 Airflow와 dbt는 주로 다음 역할을 분담하여 함께 사용한다고 한다.

레이어	도구	역할
Orchestration	Airflow	스케줄링, 재시도, 알림
Transformation	dbt	모델 DAG, 테스트, 문서화
Storage	BigQuery / Snowflake	분석용 데이터 저장

(dbt에서도 스케줄링 기능을 제공은 하지만, 확장성 (dbt 프로세스가 아닌 외부 프로세스와 함께 스케줄링이 필요할 때 등)을 위해 dbt와 airflow를 함께 사용하는 사례가 많은 것으로 보임)

 

위 생성 답변을 보고 dbt의 강점 겸 역할을 다음과 같이 정리해봤다.

1. dbt는 참조하는 테이블에 이상이 생길 경우 명시적으로 인지가 가능하다.
    생각해보니 Airflow만 사용할 경우, 참조하고 있는 원본 테이블의 메타가 변경되거나 데이터 타입이 변경되는 경우가 적지않게 있는데,

    task 내에 미리 예외 케이스를 작성해두지 않은 경우, 참조한 테이블의 변경사항을 무시하고 transform되어 문제가되는 이슈가 생길 수      있다.

    반면 dbt는 not_null, unique, relationships 테스트 등을 통해 참조 테이블의 정상 여부를 사전에 정의하기가 편하다.

 

2. 테스트 코드를 정의하기 편하다.

    Airflow 만 사용할 경우, 같은 원본 데이터를 참조하는 다른 두개의 dag가 있을 때, 해당 원본 데이터의 정상 여부를 테스트하기 위해

    같은 테스트 코드를 두 개의 dag 내에 중복으로 작성하거나 혹은 테스트용 task를 중복으로 추가하는 비용이 발생할 수 있다.

    반면 dbt는 yml파일 혹은 원본 데이터 모델 파일에 테스트를 한번만 정의하여, 다른 데이터 모델에서 가져다 쓸 수 있다는 장점이 있다.

 

 

3. docs를 작성하기 편하다.

    Airflow를 통해 도출된 테이블은 테이블 정의서를 dag와는 별개로 작성하는 과정이 필요하다.

    그러나 dbt에선 테이블 마다 자동으로 docs를 정의할 수 있는 기능이 있고, codegen 패키지를 통해 자동으로 스키마를 작성할 수 있어

    편하다.

 

 

---

dbt 적용 사례

dbt를 실제로 현업에 적용한 사례에 대해 몇가지 살펴봤고,

https://medium.com/iotrustlab/data-warehouse-with-dbt-b65be67750e9

[AE] dbt를 통한 데이터 웨어하우스 개발 후기

https://blog.nftbank.ai/nftbank%EC%9D%98-dbt-data-lakehouse-%ED%8F%BC-%EB%AF%B8%EC%B3%A4%EB%8B%A4-95c905fcb1e5

NFTBank의 dbt + Data Lakehouse 폼 미쳤다 🎆

 

dbt를 왜 적용했는지에 대해 아래와 같이 요약해볼 수 있었다.

 

1️⃣ docs 작성 편의성 확보로 데이터 가독성과 이해도 향상

• dbt의 문서화와 Lineage 기능을 통해 데이터 마트의 구조와 로직을 빠르게 파악 가능
• 테이블·컬럼 설명, 의존성, 테스트 정보를 자동 문서화
• 분석가와 엔지니어가 데이터 이해에 소요되는 시간을 크게 단축

 

 

 2️⃣ 프로젝트 확장성과 유지보수성 강화

• dbt의 Lineage + 문서화로 데이터 간 의존성 추적 용이
• DRY한 SQL 코드와 테스트된 데이터셋 재사용 가능
• 새로운 프로젝트나 데이터 체인을 기존 모델에 쉽게 확장

 

 

3️⃣ Snapshot 디렉토리에서 별도 관리 가능

• Periodic / Accumulating Snapshot Fact Table 자동화 지원
• 일·주·월 단위로 수익, 비용, 재고, 잔액 등 시점 데이터 관리
• Snapshot 디렉토리를 통한 이력 관리 표준화

 

 

4️⃣ dependency를 고려한 Transform

• 테이블 간 의존 관계를 자동 분석하여 DAG 형태로 Transform 실행
• 대규모 Transform 작업을 안정적으로 운영
• 신규 Mart 추가 및 특정 Mart 유지보수의 독립성 확보

 

 

5️⃣ Test 편의

• 데이터 정합성 테스트 자동화
• Built-in 테스트 + 사용자 정의 테스트 지원

 

 

6️⃣ 다양한 데이터 플랫폼에 Deploy 가능

• SQL + Jinja 템플릿 기반 개발
• 실행 시 순수 SQL로 변환되어 DB에 DDL / DML 자동 적용 (PostgreSQL, Snowflake, BigQuery, Redshift, DuckDB 등 다양한 데이터 플랫폼과 호환.)