[dbt 입문] 한 방에 이해하기: 왜 모두가 dbt를 쓰는가?

안녕하세요! 오늘은 모던 데이터 스택의 핵심, dbt(data build tool)에 대해 이야기해보려 합니다. 의료 데이터 분석가로서 SQL로 환자 데이터를 뽑다 보면 이런 고민 해보신 적 없나요?

 

"어? 지난달 재입원율 쿼리 어디 저장해뒀지?" "김 연구원님이 뽑은 환자 수랑 내가 뽑은 환자 수가 왜 다르지?" (알고 보니 status='active' 조건 하나 차이...) "이 테이블, 누가 언제 만든 건지 믿을 수 있는 건가?"

 

이런 'SQL 지옥'에서 우리를 구원해 줄 도구가 바로 dbt입니다.

 

1. dbt가 뭔가요? (The "T" in ELT)

데이터를 분석하기 위해 우리는 보통 ELT (Extract - Load - Transform) 과정을 거칩니다.

1. Extract (수집): 병원 EMR, 로그 데이터 등을 가져옵니다.
2. Load (적재): BigQuery나 Snowflake 같은 데이터 웨어하우스에 '날 것(Raw Data)' 그대로 넣습니다.
3. Transform (변환): 분석하기 좋게 가공합니다. (예: birth_date를 age로 변환, 결측치 처리 등)

dbt는 바로 이 'Transform(변환)' 과정을 담당하는 도구입니다. 복잡한 파이썬 코드나 ETL 툴 없이, 오직 SQL만으로 데이터를 변환하고 관리할 수 있게 해줍니다.

 

2. 왜 dbt를 써야 할까요? (Before & After)

dbt가 없을 때 (Traditional SQL)

• 복붙의 연속: 비슷한 쿼리를 여기저기 복사해서 씁니다. 로직이 바뀌면 전부 다 찾아가서 고쳐야 합니다.
• 믿을 수 없는 데이터: 테스트가 없어서, 대시보드 숫자가 틀려도 아무도 모릅니다. 나중에 의사 선생님이 "이거 이상한데?"라고 해야 발견합니다.
• 문서화 부재: 이 컬럼이 뭘 의미하는지 만든 사람만 압니다 (혹은 만든 사람도 까먹습니다).

dbt를 쓸 때 (Modern Analytics Engineering)

• 모듈화 (Modularity): patients 테이블을 한 번만 잘 정의해두면, 다른 모든 쿼리에서 ref('patients')로 가져다 씁니다. 로직은 한 곳에서만 수정하면 됩니다.
• 자동 테스트 (Testing): "환자 ID는 절대 NULL일 수 없고 중복되면 안 된다"라고 설정만 해두면, dbt가 매번 자동으로 검사해 줍니다.
• 버전 관리 (Git): SQL 코드도 개발자처럼 Git으로 관리합니다. 누가 언제 뭘 바꿨는지 다 기록됩니다.
• 자동 문서화 & 리니지 (Lineage): 데이터가 어디서 와서 어디로 흘러가는지 보여주는 지도(Lineage Graph)를 자동으로 그려줍니다. 신규 입사자에게 설명할 필요가 없습니다.

3. 핵심 기능 요약

1. SELECT문만 있으면 됩니다: CREATE TABLE, INSERT 같은 DDL은 dbt가 알아서 합니다. 분석가는 오직 데이터 로직(SELECT)에만 집중하세요.
2. 데이터 품질 보장: unique, not_null 같은 테스트를 통해 "쓰레기 데이터"가 분석 결과로 흘러가는 것을 막아줍니다.
3. 협업의 표준: 모든 분석가가 같은 방식으로 코드를 짜고 리뷰할 수 있게 해줍니다. 팀 전체의 생산성이 올라갑니다.