DBT를 왜 써야 하는가, 언제 써야 하는가?

728x90

✅ DBT를 왜 써야 하는가 (Why DBT?)

☑️ 1. SQL 변환 로직이 많아지고 있다

raw → 정제 → 집계 쿼리가 늘어남
비슷한 SQL이 여기저기 복붙됨
“이 테이블 누가 만들었지?” 상황 발생

👉 DBT는 SQL을 ‘관리 대상 코드’로 바꿔줌

☑️ 2. 데이터 품질 이슈를 사전에 잡고 싶다

null 값
중복 키
잘못된 범위 값

tests:
  - not_null
  - unique

👉 쿼리 결과가 아니라 “데이터 자체를 테스트”

☑️ 3. 실행 순서 관리가 힘들다

테이블 A → B → C
순서 틀리면 에러
수동 실행은 한계

👉 ref() 기반으로 DAG 자동 관리

☑️ 4. 협업과 리뷰가 필요하다

SQL도 리뷰 받고 싶다
누가 어떤 로직을 바꿨는지 알고 싶다
롤백이 필요하다

👉 Git + PR + 코드리뷰 가능

☑️ 5. 문서가 자동으로 있었으면 좋겠다

컬럼 설명 매번 정리하기 귀찮음
신규 인원이 테이블 이해 못함

👉 DBT Docs = 자동 데이터 카탈로그

☑️ 6. “이 테이블 믿어도 되나요?”에 답하고 싶다

언제 업데이트됨?
어떤 raw에서 왔음?
테스트 통과했음?

👉 Lineage + Test 결과로 신뢰성 확보

🧠 한 줄 요약 (Why)

DBT는 SQL 변환 작업을 ‘개발 가능한 데이터 파이프라인’으로 만들어준다

📌 DBT를 언제 써야 하는가 (When DBT?)

아래 체크리스트에서 3개 이상 해당되면 DBT 도입 강력 추천

✅ 환경 체크

BigQuery / Redshift / Snowflake 사용 중
DW 안에서 SQL로 데이터 가공 중
ELT 구조 (Load → Transform)

✅ 데이터 구조 체크

raw / staging / mart 구조가 있다
같은 데이터를 여러 분석가가 사용
집계 테이블, 지표 테이블이 많다

✅ 운영 & 협업 체크

SQL 쿼리가 수십~수백 개다
누가 언제 수정했는지 추적이 필요
테스트 없이 테이블이 운영된다
문서화가 항상 밀린다

✅ 지금 겪고 있는 문제 체크

“이 테이블 뭐임?” 자주 나옴
쿼리 깨지면 나중에 알게 됨
분석 결과가 자주 안 맞는다
테이블 간 의존성이 헷갈린다

❌ DBT가 굳이 필요 없는 경우

아래에만 해당되면 굳이 안 써도 됨

테이블 3~5개 수준
개인 분석용, 단기 프로젝트
SQL 거의 안 씀
데이터 변환 대부분 Spark / Python

🧩 DBT vs 다른 도구 간단 비교

역할도구

수집 (Extract)	Airbyte / Fivetran
변환 (Transform)	DBT
오케스트레이션	Airflow / Kestra
품질 검사	DBT test / GE
저장	BigQuery / Redshift

👉 DBT는 “변환 전용”이다

🧠 블로그 마무리용 문장

DBT는 데이터가 ‘많아졌을 때’ 쓰는 도구가 아니라,
데이터가 ‘중요해졌을 때’ 쓰는 도구다.