dbt 기초와 아키텍처
ETL에서 ELT로: 왜 변환이 웨어하우스 안으로 들어왔나
전통적인 ETL 파이프라인에서는 외부 처리 엔진이 원본 데이터를 추출(Extract)하고 변환(Transform)한 뒤 웨어하우스에 적재(Load)했다. 이 방식은 Hadoop 시대에는 합리적이었지만, Snowflake·BigQuery·Redshift 같은 클라우드 데이터 웨어하우스가 등장하면서 패러다임이 바뀌었다. 클라우드 웨어하우스는 탄력적으로 확장하고 MPP(대규모 병렬 처리)로 복잡한 쿼리를 빠르게 처리한다. 즉, 변환에 필요한 컴퓨팅이 이미 웨어하우스 안에 있다.
ELT는 이 강점을 활용한다. 원본을 먼저 웨어하우스에 그대로 올린 다음, 웨어하우스 안에서 SQL로 변환한다. 별도의 변환 서버나 Spark 클러스터가 필요 없다.
dbt(Data Build Tool)는 ELT의 T(Transform) 단계를 코드로 관리하는 오픈소스 프레임워크다. 2016년 Fishtown Analytics(현 dbt Labs)에서 공개했고, 2026년 현재 데이터 엔지니어링과 애널리틱스 엔지니어링의 사실상 표준 변환 도구로 자리 잡았다.
dbt가 실제로 하는 일
dbt는 데이터를 직접 이동하지 않는다. dbt가 하는 일은 단 하나다: SQL을 컴파일하고, 웨어하우스에서 실행해 테이블·뷰를 만든다.
개발자는 .sql 파일에 SELECT 문만 작성한다. dbt가 이를 받아서 CREATE TABLE AS 또는 CREATE VIEW AS 같은 DDL로 감싸 실행한다. 복잡한 DDL, 스키마 생성, 의존 순서 결정은 dbt가 처리한다.
또한 dbt는 Jinja 템플릿 엔진을 내장한다. SQL 안에서 반복 코드를 매크로로 추출하고, 환경(dev/prod)에 따라 스키마 이름을 동적으로 변경하고, 모델 간 참조를 ref() 함수로 선언할 수 있다.
dbt Core vs dbt Cloud
| 항목 | dbt Core | dbt Cloud |
|---|---|---|
| 형태 | 오픈소스 CLI | 관리형 SaaS 플랫폼 |
| 실행 | 로컬 터미널 / CI 서버 | 웹 IDE + 스케줄러 |
| 비용 | 무료 | 유료 (개인 개발자 플랜은 무료) |
| 협업 | Git + 외부 툴 필요 | 빌트인 IDE, PR, 슬랙 알림 |
| 적합 | 자체 인프라, 커스텀 CI | 소규모·중규모 팀, 빠른 시작 |
dbt Core가 모든 기능의 기반이며, dbt Cloud는 그 위에 스케줄링·알림·문서 호스팅·데이터 계보 시각화를 더한 레이어다.
내부 동작: Compile → DAG → Execute
dbt가 dbt run 명령을 받으면 세 단계로 진행된다.
- 컴파일(Compile): dbt는
.sql파일의 Jinja 템플릿을 렌더링한다.{{ ref('stg_orders') }}같은 함수를 실제 스키마·테이블명으로 치환하고, 컴파일된 순수 SQL을target/compiled/디렉터리에 저장한다.
- DAG 분석: 모델 간
ref()호출을 분석해 방향성 비순환 그래프(DAG)를 구성한다. 순환 참조가 있으면 컴파일 오류를 낸다. DAG를 위상 정렬해 실행 순서를 결정하고, 의존 관계가 없는 모델은 스레드(기본 4개)로 병렬 실행한다.
- 웨어하우스 실행: 각 모델의 SQL을 Materialization 타입에 맞는 DDL로 감싸 웨어하우스에 전송한다. dbt 자체는 데이터를 처리하지 않는다. 모든 연산은 웨어하우스의 엔진이 담당한다.
어댑터: 웨어하우스 연결
dbt는 어댑터(Adapter) 플러그인으로 다양한 데이터 플랫폼에 연결한다. 공식 어댑터는 Snowflake, BigQuery, Redshift, Databricks, DuckDB, PostgreSQL, Trino 등을 지원하며, 커뮤니티 어댑터를 통해 더 많은 플랫폼을 사용할 수 있다.
어댑터는 profiles.yml에 설정한다. 예를 들어 BigQuery 프로젝트 ID, Snowflake 계정명, Redshift 호스트 정보를 여기에 저장한다. 민감한 자격증명은 환경 변수로 분리하는 것이 권장된다.
Materialization: 모델을 어떻게 구현할까
dbt 모델을 실행하면 웨어하우스에 어떤 객체가 생길지는 Materialization 설정으로 결정한다.
| 타입 | 생성 객체 | 특징 | 언제 쓸까 |
|---|---|---|---|
| view | 뷰 | 항상 최신 데이터 반영, 저장 없음 | 가벼운 staging 모델 |
| table | 테이블 | 매번 전체 재생성, 빠른 조회 | 자주 조회되는 mart |
| incremental | 테이블 | 신규·변경 행만 처리 | 대용량 이벤트/로그 |
| ephemeral | 없음 (CTE로 인라인) | 웨어하우스 객체 미생성 | 중간 변환 재사용 |
한 줄 정리
dbt는 ELT의 변환 단계를 SQL + Jinja 모델로 코드화하고, DAG 기반으로 의존 순서를 자동 결정해 웨어하우스 위에서 실행하는 오픈소스 변환 프레임워크다.
References
- https://www.getdbt.com/blog/best-elt-tools
- https://www.fivetran.com/blog/dbt-explained
- https://www.analyticsengineering.com/resources/what-is-dbt-data-build-tool-a-simple-explanation
- https://www.startdataengineering.com/post/dbt-data-build-tool-tutorial/
- https://popsql.com/learn-dbt/dbt-dag
- https://reccehq.com/ai-blog/what-is-dbt-dag-lineage/
- https://medium.com/@likkilaxminarayana/6-dbt-project-structure-explained-a-practical-guide-for-analytics-engineers-5894f6230756