웨어하우스에 데이터를 적재한 뒤 그것을 분석 가능한 형태로 변환하는 일은 오랫동안 복잡한 SQL 스크립트 더미와 수작업으로 이뤄졌습니다. 누가 어떤 테이블을 만들었는지, 의존 관계가 무엇인지 아무도 모르는 상태가 흔했습니다. dbt는 이 변환 계층(ELT의 T)을 소프트웨어 엔지니어링 원칙으로 다루게 해주는 도구입니다.
이 글에서는 dbt의 모델, 참조 시스템, 테스트, 문서화를 차례로 살펴보고, 실무에서 모델 구조를 어떻게 잡아야 하는지 다룹니다.
dbt가 바꾸는 것
dbt의 출발점은 단순합니다. 모든 변환은 SELECT 문 하나로 표현되는 모델이고, dbt가 그것을 CREATE TABLE 또는 VIEW로 감싸 실행합니다. 엔지니어는 결과 테이블이 아니라 그 테이블을 정의하는 쿼리에 집중합니다. 여기에 버전 관리, 테스트, 의존성 그래프가 따라옵니다.
핵심 마법은 ref 함수입니다. 모델끼리 직접 테이블명을 쓰지 않고 ref로 참조하면 dbt가 의존 그래프를 자동 구성하고 올바른 순서로 빌드합니다. 환경(dev, prod) 간 스키마 전환도 ref가 알아서 처리합니다.
모델 계층 구조
잘 설계된 dbt 프로젝트는 보통 세 계층으로 나눕니다. 이 구조는 변경에 강하고 재사용이 쉽습니다.
- staging: 원천 테이블당 1:1, 컬럼명 정리와 타입 캐스팅만
- intermediate: 여러 staging을 조합한 중간 로직, 재사용 단위
- marts: 비즈니스 도메인별 최종 산출물, BI 연결
-- models/marts/fct_orders.sql
with orders as (
select * from {{ ref('stg_orders') }}
),
payments as (
select * from {{ ref('stg_payments') }}
)
select o.order_id, o.customer_id, sum(p.amount) as total
from orders o left join payments p using (order_id)
group by 1, 2테스트와 문서화
dbt의 진짜 강점은 데이터 품질 테스트를 선언적으로 붙일 수 있다는 점입니다. YAML에 not_null, unique, accepted_values, relationships 같은 제약을 명시하면 빌드마다 자동 검증됩니다. 기본 테스트로 부족하면 SQL로 커스텀 테스트를 작성합니다.
같은 YAML에 컬럼 설명을 적으면 dbt docs가 자동으로 데이터 카탈로그와 계보 그래프를 생성합니다. 코드와 문서가 한곳에 있어 문서가 낡지 않는다는 점이 큰 가치입니다.
운영과 성능
모델이 수백 개를 넘으면 전체 빌드 시간이 부담스러워집니다. 매번 전체 테이블을 새로 만드는 대신 incremental 모델로 새 데이터만 추가 처리하세요. is_incremental 분기로 증분 조건을 걸면 빌드 시간이 수십 분에서 수 분으로 줄어듭니다.
또한 dbt build와 함께 상태 비교 선택(state:modified)을 쓰면 변경된 모델과 그 하위만 빌드해 CI 시간을 절약할 수 있습니다. 한 가지 주의점은 증분 모델의 고유 키 설정 오류로 인한 중복인데, unique 테스트로 반드시 방어하세요.
dbt는 분석가를 엔지니어로 만든다. 버전 관리, 테스트, 문서화가 SQL 워크플로에 자연스럽게 녹아들기 때문이다.
정리
dbt는 변환 계층을 모듈화된 SQL 모델로 다루며 ref 기반 의존성, 선언적 테스트, 자동 문서화를 제공합니다. staging-intermediate-marts 계층으로 구조를 잡고, 증분 모델로 성능을 확보하며, 테스트로 품질을 지키는 것이 분석 엔지니어링의 표준 워크플로입니다.
