[dbt] 1. ELT의 시대 - dbt란 무엇인가?

이런 환경을 구조적으로 바꾸기 위해 dbt(Data Build Tool)가 나왔습니다. dbt(Data Build Tool)는 단순한 SQL 정리 도구가 아니라, 데이터 모델링의 방식 자체를 바꾸는 도구로 주목받고 있습니다. 그래서 이번 시리즈에서는 dbt에 대해서 다뤄보려고 합니다.

이번 글에서는 dbt의 철학, 기술적 역할, 실무에서 어떤 점을 해결해주는지 구체적으로 정리해보려 합니다.

dbt(Data Build Tool)

dbt는 SQL을 기반으로 데이터 웨어하우스 안에서 변환 작업을 수행하는 오픈소스 도구입니다.

다양한 데이터 원천에서 데이터를 추출(Extract)하고 로드(Load)한 뒤, 그 위에 SQL 모델을 정의하고 테스트하며 문서화할 수 있도록 설계되었습니다.

즉, dbt는 ELT(Extract–Load–Transform) 흐름에서 ‘T(Transform)’ 단계만을 담당하며, 데이터 엔지니어링을 ‘소프트웨어 개발처럼’ 접근할 수 있게 합니다.

ELT와 dbt: 시대의 전환점

전통적인 ETL 방식의 한계

과거에는 ETL(Extract–Transform–Load) 방식이 표준이었습니다. 하지만 다음과 같은 문제점들이 있었습니다:

문제	상세 설명
높은 처리 비용	별도 ETL 서버에서 변환 작업을 수행해야 함
확장성 제약	데이터 규모 증가 시 성능 병목 발생
유연성 부족	사전에 정의된 스키마에만 적합한 구조

이런 구조는 변환 로직이 폐쇄적인 파이프라인에 갇혀 있었고, 재사용이나 추적이 어려웠습니다.

ELT 방식의 등장과 확산

클라우드 기반의 데이터 웨어하우스(BigQuery, Snowflake 등)가 등장하면서, 변환 작업을 ETL 서버가 아니라 웨어하우스 안에서 직접 처리하는 ELT 방식이 일반화되었습니다.

장점	실무 효과
처리 속도 향상	웨어하우스의 컴퓨팅 파워를 직접 활용
모든 데이터 유형 지원	정형, 반정형, 비정형 데이터 모두 처리 가능
비용 효율성	스토리지와 컴퓨팅 분리로 리소스 최적화 가능

ELT가 현실적으로 가능해졌기 때문에, 변환 로직을 SQL로 직접 관리하고 표준화하려는 수요가 커졌고, 그 중심에 dbt가 등장했습니다.

dbt가 해결하는 실무적 문제

전통적인 SQL 작업의 문제점

많은 팀들이 SQL을 활용하지만, 다음과 같은 문제가 반복됩니다.

•

SQL 파일이 흩어져 있어 재사용 불가

•

쿼리 간 의존성이 추적되지 않음

•

쿼리 테스트나 문서화가 부재

•

협업 시 충돌이나 규칙 없는 변경 발생

dbt의 구조적 해결책

dbt는 이러한 문제들을 아래 기능으로 해결합니다.

•

Git 기반 코드 관리: 변경 이력과 작업 주체 추적

•

ref() 기반 참조 시스템: 쿼리 간 의존성 명시

•

자동 문서화: 모델 계보(lineage)와 설명을 시각화

•

내장 테스트 DSL: not_null, unique, accepted_values 등 검증 내장

•

재사용성 높은 SQL 모듈화: Jinja 템플릿을 통한 코드 재사용

dbt의 핵심 철학

dbt는 다음 네 가지 설계 철학을 중심으로 구축되었습니다.

1. SQL 중심 설계

•

데이터 분석가가 익숙한 SQL만으로 전체 파이프라인을 구성 가능

•

별도의 프로그래밍 언어 없이도 강력한 추상화가 가능

2. 코드로서의 데이터

•

모델 정의는 .sql과 .yml 파일로 구성되며, Git을 통해 버전 관리

•

이를 통해 협업, 리뷰, 배포 프로세스에 소프트웨어 개발 방식을 적용 가능

3. 자동 의존성 관리

•

모델 간 참조는 ref() 함수로 명시하며, dbt는 이를 바탕으로 의존성 그래프를 생성하고 자동으로 실행 순서를 결정

4. 재사용성과 모듈화

•

Jinja 템플릿, 변수, macro 등을 통해 SQL 코드의 중복을 줄이고 재사용성 상승

dbt의 대표 구조 예시

기존 SQL 방식과 dbt로 관리하는 방식을 예시를 통해서 간단하게 비교해보겠습니다.

전통 SQL 방식

-- sales_summary.sql
SELECT
  product_id,
  SUM(amount) AS total_sales
FROM raw_sales
WHERE date >= '2024-01-01'
GROUP BY product_id;
SQL
복사

•

Git 관리 불가능

•

의존성 표현 없음

•

테스팅/문서화 부재

dbt 방식

-- models/marts/sales_summary.sql
{{ config(materialized='table') }}

SELECT
  product_id,
  SUM(amount) AS total_sales
FROM {{ ref('stg_sales') }}  -- 'stg_sales' 모델을 참조 (의존성 명시)
WHERE date >= '{{ var("start_date") }}'  -- 변수로 시작 날짜를 관리 (재사용성 향상)
GROUP BY product_id;
SQL
복사

•

Git 기반 관리

•

ref()로 의존성 명시

•

변수와 템플릿 사용으로 재사용성 향상

•

tests/ 디렉토리에서 무결성 검증

구조를 넘어 운영까지

이처럼 dbt는 단순히 SQL 쿼리 스타일을 바꾸는 도구가 아닙니다. 쿼리 간 관계를 명확히 표현하고, 이를 기반으로 모델 실행 순서를 자동 조정하는 구조적 기반을 제공합니다.

그리고 이 구조는 곧 운영 효율성으로 이어집니다.

•

CI/CD 통합: GitHub Actions, GitLab CI 등과 연계해 테스트 → 리뷰 → 배포까지 자동화 가능

•

문서화 자동 생성: dbt docs generate 명령으로 계보(lineage), 컬럼 정보, 설명을 정리된 형태로 출력

•

협업 문화 정착: Slack, Airflow, BI 도구와의 연결을 통해 데이터 흐름 전반을 투명하게 관리 가능

이 모든 기능은 결국 데이터팀이 개발자처럼 일할 수 있는 환경을 만들어줍니다.

마무리

dbt는 단순한 쿼리 관리 도구가 아니라, 데이터 파이프라인을 코드로 다루는 문화를 가능하게 하는 시스템입니다. 기존 ETL 중심의 복잡하고 폐쇄적인 구조를 넘어, ELT 기반에서 개방적이고 협업 가능한 데이터 환경을 구축할 수 있도록 설계되어 있습니다.

이미 SQL에 익숙한 팀이라면, 별도의 학습 곡선 없이도 빠르게 적응할 수 있고, 코드 중심의 데이터 운영 방식으로 한 단계 더 나아갈 수 있습니다.

다음 글에서는 dbt 개발 환경을 구축하고, 첫 모델을 실행하는 과정을 단계별로 정리해보겠습니다. 설치부터 프로젝트 초기화, 데이터베이스 연결까지 실무적인 흐름을 함께 다뤄볼 예정입니다.