데이터 엔지니어링 초보자를 위한 DBT 가이드

DBT(Data Build Tool)는 데이터 엔지니어와 분석가를 위한 오픈소스 도구로, SQL을 활용해 데이터 파이프라인을 간단하고 효율적으로 관리할 수 있도록 도와준다. 주로 데이터 변환과 관련된 작업에 초점을 맞추며, 기존의 ETL(Extract, Transform, Load) 과정을 ELT(Extract, Load, Transform)로 전환하는 데 유용하다. 이번 글에서는 DBT가 무엇인지, 왜 사용해야 하는지, 그리고 현대 데이터 스택에서 어떤 역할을 하는지 상세히 다뤄볼 것이다.

1.1. DBT란?

Data Build Tool은 SQL 기반의 데이터 변환 도구이다. 데이터 웨어하우스에서 실행되는 SQL 쿼리를 통해 데이터를 변환하고 이를 관리할 수 있는 프레임워크를 제공한다. 가장 큰 특징 중 하나는 코드 중심의 데이터 변환과 관리 방식을 채택했다는 점이다. 코드 중심이란, 데이터 변환 로직을 SQL 파일로 정의하고 Git으로 버전 관리를 할 수 있음을 의미한다. Git의 버전 관리에 대한 글은 여기에서 참고하면 된다.

예를 들어, sales라는 테이블의 데이터를 집계하여 월별 매출을 계산하고 싶다면, DBT 모델을 다음과 같이 작성할 수 있다:

-- models/monthly_sales.sql
SELECT
    DATE_TRUNC('month', sale_date) AS sale_month,
    SUM(sales_amount) AS total_sales
FROM {{ source('raw', 'sales') }}
GROUP BY 1;

동일한 작업을 하려면 데이터를 Python, Java, 또는 기타 스크립트 언어로 처리해야 할 것이다. 이는 SQL로 작성하는 것보다 복잡하고, 데이터 웨어하우스의 성능을 온전히 활용하지 못할 가능성이 높다. 데이터 변환 로직을 유지보수하는 데도 더 많은 시간이 소요된다.

1.2. 왜 사용해야 하나?

재사용 가능한 코드: SQL 쿼리를 모듈화하고 재사용할 수 있는 구조를 제공한다. 예를 들어, 공통 변환 로직을 매크로(Macro)로 정의하면 여러 모델에서 재사용할 수 있다.
- 예를 들어, 날짜 변환 로직인 매크로 format_date를 작성하여

{% macro format_date(column) %}
DATE_TRUNC('day', {{ column }})
{% endmacro %}

여러 모델에서 이런 식으로 호출하여 사용할 수 있다

SELECT {{ format_date('sale_date') }} AS sale_date
FROM {{ source('raw', 'sales') }}

2. 자동화된 테스트: 데이터 무결성을 검증하기 위한 테스트 기능을 제공한다. 예를 들어, 특정 열이 Null 값이 없어야 한다는 조건을 정의하면, 이를 자동으로 검증할 수 있다.

3. 효율적인 협업: Git 기반의 버전 관리와 표준화된 구조를 통해 팀 간 협업이 수월해진다.

4. 최신 데이터 스택과의 통합: BigQuery, Snowflake, Redshift 등 주요 데이터 웨어하우스와 쉽게 통합된다.

1.3. ETL에서 ELT로 전환하는 이유

기존의 ETL 프로세스는 데이터를 추출(Extract), 변환(Transform)한 후 데이터 웨어하우스에 적재(Load)하는 방식이었다. 그러나 이러한 방식은 다음과 같은 한계를 가지고 있다:

확장성 문제: 변환 작업이 데이터 웨어하우스로 로드되기 전에 이루어지기 때문에 대량 데이터를 처리할 때 성능 병목이 발생할 수 있다.
복잡성 증가: 다양한 변환 로직을 실행하기 위해 전용 ETL 서버나 별도의 프로세스를 유지해야 한다.
유지보수 어려움: ETL 작업이 복잡해질수록 관리와 디버깅이 어려워진다.

ELT는 이러한 문제를 해결하기 위해 데이터 웨어하우스의 강력한 처리 성능을 활용하여 데이터를 추출(Extract)하고 로드(Load)한 후, 변환(Transform)을 수행하는 방식이다. 이 접근법은 다음과 같은 장점을 제공한다:

처리 성능 향상: 데이터 변환 작업이 데이터 웨어하우스 내에서 실행되므로, 데이터 웨어하우스의 병렬 처리 및 확장성을 최대한 활용할 수 있다.
단순화된 데이터 파이프라인: 별도의 ETL 서버를 유지할 필요가 없으며, SQL 기반의 변환 로직으로 파이프라인을 단순화할 수 있다.
비용 효율성: 클라우드 기반 데이터 웨어하우스는 종량제 가격 모델을 제공하므로, 필요한 만큼만 비용을 지불하게 된다.

하지만 이렇게 말해도 아직은 피부로 느껴지지 않을 수 있다…. 대표적인 마케팅 데이터인 Google Analytics 데이터를 사용하여 ETL과 ELT 방식을 비교해보겠다.

ETL 방식:
1. Google Analytics 데이터(API를 통해 가져온 데이터)를 별도의 ETL 도구로 추출한다.추출한 데이터를 ETL 서버에서 전처리하여 필요 없는 열을 제거하고 날짜 형식을 변환하는 등의 변환을 거친다.변환된 데이터를 데이터 웨어하우스에 적재한다.
- 데이터를 추출 후 데이터 정제를 수행한 후, 다음과 비슷한 프로시저를 사용해 최종 데이터를 로드하는 과정을 거친다. 즉, 원본 형태에 가까운 staging_table과 데이터 정제 후인 final_table을 각각 관리하며 데이터 정제 과정은 이 프로시저를 사용한다.

CREATE PROCEDURE dbo.transform_google_analytics_data
AS
BEGIN
    -- 데이터 정제 로직
    INSERT INTO final_table
    SELECT id, session_count, event_count
    FROM staging_table
    WHERE session_count > 0;
END;

이 때의 문제점은 대량 데이터를 처리할 때 저장 프로시저 내부의 변환 로직이 서버의 성능 한계에 의해 병목을 일으킬 수 있다는 점이다 (특히 MSSQL일 때는 스케줄링에 아주 골치가 아파진다). 또한, 운영 난이도도 올라가는데 staging_table과 final_table 간 데이터를 정제하고 동기화하는 로직이 복잡하며, 추가적인 관리가 필요하다.

만약 저장 프로시저에 포함된 변환 로직이 증가하면, 코드를 디버깅하고 업데이트하는 작업이 점점 더 어려워질 수 있다. 실제로 내가 현업에서 쓰던 MSSQL 프로시저 중에 1000줄에 가까운 프로시저가 있는데 전형적인 스파게티 모델을 만들어 악몽인 녀석이었다. BigQuery로 마이그레이션하면서 DBT를 도입해 아주 깔끔하게 정리 가능해졌다.

ELT 방식:
1. Google Analytics 데이터를 원본 그대로 데이터 웨어하우스(예를 들어, BigQuery)에 적재한다.DBT로 적재된 데이터를 변환한다. 예를 들어, 세션 데이터를 월별 집계로 변환한다.

-- models/monthly_sessions.sql 
SELECT DATE_TRUNC('month', session_date) AS session_month, COUNT(*) AS total_sessions 
FROM {{ source('raw', 'google_analytics_sessions') }} 
GROUP BY 1;

ELT 방식에서는 데이터를 웨어하우스에 로드한 후 변환 작업을 수행하므로, 데이터 파이프라인이 간소화되고 데이터 처리 속도와 유연성이 크게 향상된다.

1.4. 주요 개념

효과적으로 사용하려면 주요 개념을 이해해야 한다:

모델(Model): SQL 파일로 작성된 데이터 변환 로직이다. 각 모델을 실행하여 결과를 데이터 웨어하우스에 저장한다.
- 예: models/customers.sql
소스(Source): 외부에서 로드된 원본 데이터를 가리킨다. 소스를 추적하고 문서화할 수 있다.
- 예: source('raw', 'sales')
시드(Seed): CSV 파일을 데이터 웨어하우스에 로드하는 기능이다. 작은 참고 데이터를 추가할 때 유용하다.
- 예: data/regions.csv
테스트(Test): 데이터 무결성을 검증하기 위한 규칙이다. Null 값 검증, 고유성 검증 등 다양한 테스트를 설정할 수 있다.
- 예: tests/not_null_sales_id.sql
매크로(Macro): 반복되는 SQL 로직을 재사용 가능하도록 함수처럼 정의한 것이다.
- 예: {{ my_custom_macro(arg1, arg2) }}
스냅샷(Snapshot): 특정 시점의 데이터를 캡처하여 데이터의 변경 이력을 추적할 수 있는 기능이다.
- 사용 예시: 매일 고객 테이블의 상태를 기록하여 고객의 상태 변화(예: 등급, 상태 변화)를 감사(audit) 목적으로 추적할 수 있다. 이를 통해 특정 고객이 VIP 상태에서 일반 상태로 변경된 시점을 확인할 수 있다.

1.5. DBT를 배우기 전 알아야 할 것들

SQL: SQL을 기반으로 동작하므로, SQL에 익숙해야 한다. SELECT, JOIN, GROUP BY와 같은 기본적인 쿼리 문법을 이해하고 있어야 한다.
Git: 모든 프로젝트는 Git으로 관리된다. 따라서 Git의 기본적인 사용법(예: clone, commit, push, pull)을 알아야 한다.
데이터 웨어하우스 기초: 데이터 웨어하우스의 기본 개념(테이블, 스키마, 쿼리 실행 등)을 이해해야 한다. BigQuery, Snowflake, 또는 Redshift 중 하나에 대해 간단히라도 경험해보는 것이 좋다.

처음 시작할 때 다소 생소할 수 있지만, 데이터를 관리하고 분석하는 데 좋은 도구가 될 수 있다. 다음 글에서는 DBT를 설치하고 첫 번째 프로젝트를 설정하는 방법을 단계별로 알아볼 것이다.