dbt

dbt가 해결하는 문제와 ELT에서의 위치

dbt 이전에는 팀들이 수백 개의 손으로 작성한 CREATE TABLE/INSERT 문을 버전 관리도, 테스트도, 리니지 추적도 없이 운영했다. dbt는 SQL 변환 로직을 Git 버전관리, CI, 자동 문서화, 의존성 그래프가 딸린 소프트웨어처럼 다룰 수 있게 만들어 이 문제를 해결한다.

인터뷰에서 자주 놓치는 포인트는 dbt가 추출(Extract)이나 적재(Load)를 하지 않는다는 경계다. dbt는 이미 웨어하우스 안에 존재하는 원천 데이터만 변환(Transform)하며, 데이터를 웨어하우스로 가져오는 일은 Fivetran이나 Airbyte 같은 별도의 EL 도구가 담당한다. 이 역할 분리 덕분에 dbt는 'ELT' 아키텍처에서 T(Transform) 계층 전용 도구로 자리 잡았다.

dbt 모델과 Materialization 선택

모델은 models/ 디렉터리 아래 저장된 단일 SELECT문(.sql 파일)이다. dbt run을 실행하면 dbt는 이 SELECT문을 설정된 materialization에 맞는 DDL(CREATE TABLE, CREATE VIEW, MERGE 등)로 감싸 웨어하우스에서 실행한다. 테스트·문서·리니지 같은 dbt의 다른 모든 기능은 이 모델 단위에 부착된다.

dbt-core가 오래전부터 내장해 온 materialization은 네 가지다. view는 매 쿼리마다 SQL을 재실행하는 가벼운 뷰로, 데이터를 지속시킬 필요가 없을 때 쓴다. table은 매 실행마다 전체를 재구축하며, 다운스트림이 빠른 읽기를 필요로 하고 전체 재구축 비용을 감당할 수 있을 때 쓴다. incremental은 신규/변경분만 처리해 재구축이 너무 느리거나 비쌀 만큼 큰 팩트 테이블에 적합하다. ephemeral은 독립된 오브젝트로 구체화되지 않고, 이를 참조하는 모델의 컴파일된 SQL 안에 CTE로 인라인된다.

— 정정: '네 가지 materialization'이라는 설명은 dbt-core 1.6(2023년 7월 릴리스) 이전 기준이다. 이후 Snowflake, Postgres, Redshift, Databricks 등 여러 어댑터가 materialized_view라는 다섯 번째 materialization을 지원하기 시작했다. 이는 매 실행마다 전체를 재구축하는 대신, 웨어하우스가 네이티브로 제공하는 자동 갱신(incremental refresh) 매터리얼라이즈드 뷰 오브젝트를 dbt가 관리하도록 해준다. 2026년 현재 인터뷰에서 '네 가지'라고만 답하면 최신 기능을 놓친 것으로 보일 수 있으므로, 'dbt-core 기본 네 가지 + 어댑터별로 지원하는 materialized_view'라고 답하는 것이 더 정확하다.