들어가는 글
2024년 7월 24일 수요일, 역삼역 근처 지다이닝컴퍼니에서 개최된 Seoul dbt Meetup #3에 발표자로 참석했습니다. dbt Labs는 전 세계 30개국에 걸쳐 59개 그룹으로 구성된 dbt Community Meetup 커뮤니티를 운영하고 있으며, 약 25,000명이 참여하고 있습니다. 그 중 Seoul dbt Meetup은 한국을 대표하는 그룹입니다.
dbt는 ELT 중 Transformation 영역에 특화된 애널리틱스 엔지니어링 프레임워크입니다. 저는 이전 직장에서 처음 dbt를 접하게 되었고, 기초를 확실하게 다지고 싶어서 Udemy의 The Complete dbt (Data Build Tool) Bootcamp: Zero to Hero 강의를 들으며 공부하던 중 dbt의 매력에 푹 빠지게 되었습니다.
이전 직장에서는 데이터 엔지니어 동료 분이 이미 구축하신 dbt 프로젝트 상에서 각 데이터 마트를 만들고 서비스할 지표들을 고도화하는 일을 했습니다. 반면, 현 직장에서는 기존 프로덕트 내에 BI서비스를 도입하기 위해 dbt를 제로 베이스에서 시작하게 되었습니다. 까다로운 일들을 마주할 때도 있었지만, 전반적으로 매우 높은 몰입감을 느낄 수 있었습니다.
Orchestration 작업까지 1차적으로 완료한 후 큰 성취감을 느껴 개발 후기를 작성했었는데, 영광스럽게도 Seoul dbt Meetup을 운영하시는 Herick님의 제안을 받아 발표를 하게 되었습니다.
무대 체질인 사람으로서 발표 시간이 정말 짜릿했고, 네트워킹 시간 동안에는 친분이 있는 분들, 새롭게 알게 된 분들과 고민과 관심사를 공유하며 시간 가는 줄 몰랐습니다. Meetup이 끝나고 집으로 돌아와 여전히 설렘과 신남(?)에 휩싸인 지금, 감정이 옅어지기 전에 얼른 후기를 정리해보도록 하겠습니다.
발표 후기
현재 직장에서 운영 중인 프로덕트의 BI 서비스 기능을 도입하기 위해 dbt를 활용하여 데이터 웨어하우스 개발을 시작했었습니다. 참석자 분들 중 이미 dbt에 대한 조예가 깊은 분들도 계셨지만, 절반 이상은 아직 도입하지 않은 분들도 계셨는데요. 그래서 dbt의 개념, 활용 사례, 창출할 수 있는 가치에 대한 큰 흐름을 보여 드리기 위해 발표를 진행했습니다.
1. 먼저 사내 개발자 동료 분이 AWS S3의 운영 데이터를 EMR과 Kafka를 통해 OLAP 시스템을 구축하여 애널리틱스 엔지니어링 설계를 할 수 있는 환경이 마련되었습니다. 이 데이터 스트리밍부터 데이터 웨어하우스, GraphQL, 프론트엔드까지의 흐름을 시각화하여 보여드렸습니다.
2. 이어서 dbt가 어떻게 프로덕트 개발의 ROI를 높일 수 있는지 이해를 돕기 위해 dbt의 주요 기능을 소개해드렸습니다. 참석하신 분들 중 절반 이상이 아직 dbt를 도입하시지 않은 상태였기 때문에 다행히 눈높이에 맞는 내용이었던 것 같습니다.
3. 본격적으로 dbt를 통해 제가 활용한 여섯 가지 사례를 이론과 함께 말씀 드렸습니다. 특히 많은 분들께서 Incremental Strategy의 Merge 방식을 효율적으로 실행할 수 있는 노하우에 관심이 많으시다는 걸 체감할 수 있었습니다.
4. 그 후, 개발 과정에서 겪었던 시행착오와 배움을 토대로 “미리 알았으면 좋았을 텐데”라고 느낀 소소한 팀들을 정리해드렸습니다.
5. 마지막으로 dbt에 관심이 많지만 막막함을 느끼는 분들께 격려의 메시지를 전해드리며 발표를 마무리했습니다.
또 다른 발표자였던 뤼튼(wrtn)의 데이터 엔지니어 재성님의 발표도 들었는데요. 재성님의 발표는 엔지니어링 비용 절감 관점에서 보다 깊은 두 가지 팁을 공유해주셨습니다.
- [팁 1] Merge Strategy 적용시
incremental_predicates매크로를 구현하여 스캔량을 절감할 수 있습니다. 저도 특정 모델에 Merge Strategy를 사용하여 특정 필드 값을 매일 업데이트하고 있는데, 프로덕트 사용자 수가 증가함에 따라 추후 비용 문제가 커질 것입니다. 이 매크로를 통해 스캔량 절감 방안을 고려해야 할 것 같습니다.
- [팁 2] Custom Test Macro를 구현하여 스캔량을 절감할 수 있습니다. 예를 들어, BigQuery의 Partitioned Column이
date인 경우batch_date를 변수로 주어 해당batch_date에 한해서만 스캔하게 되면 특정date에 대한 파티션만 스캔하게 되어 테스트 비용을 절감할 수 있습니다. 저의 경우 Test Macro의 총 실행 수가 1,000개가 넘는데, 데이터 사이즈가 늘어남에 따라 Test 자체의 시간과 비용이 늘어날 것 같아 이 노하우가 매우 유용했습니다. 적용 방법도 어렵지 않아 금방 시도해볼 수 있을 것 같습니다.
-- 대강 아래와 같은 느낌의 Test Macro를 작성합니다. (실제 발표 자료의 내용과 다를 수 있음)
{% test not_null_by_date(model, column_name, partitioned_column="date") %}
SELECT
{{ column_name }}
FROM
{{ model }}
WHERE
1 = 1
{%- if var('batch_date') IS NOT NONE AND var('batch_date') != "" %}
AND DATE({{ partitioned_column }}) = DATE('{{ var('batch_date') }}')
{%- endif %}
{% endtest %}# yaml 파일에서 대강 아래와 같은 느낌으로 Test를 정의합니다. (실제 발표 자료의 내용과 다를 수 있음)
models:
- name: model
columns:
- name: user_id
tests:
- not_null_by_date네트워킹 후기
발표가 끝난 후, 피자를 먹으며 몇몇 분들께 인사 드리고 이런저런 고민과 관심사를 나누었습니다. 짧은 시간 동안 워낙 많은 이야기를 나누어 모든 것들이 다 기억나지는 않지만, 아래 내용들이 떠오릅니다.
- 회사를 운영하시는 입장에서 바라보는 데이터 엔지니어링과 활용 고민
- GPT를 통한 분석 자동화 인프라 만들기
- 데이터 분석 컨텐츠 만들기
- 어떻게 하면 데이터로 조직에 기여할 수 있을까?
전반적으로 들었던 생각은, 데이터를 통해 조직에 높은 ROI를 가져다주어야 한다는 것이었습니다. dbt를 사용하든 어떤 툴을 사용하든, 결국 데이터를 통해 프로덕트의 방향을 잘 설정하여 리소스보다 더 많은 매출을 올릴 수 있어야 한다는 점입니다. 이 점에 대한 고민은 여전히 참 어렵고, 어느 기업이든 누구나 하고 계신 고민일 것 같은데, 누구에게나 시원하게 풀리는 고민은 아니겠지만 끊임 없이 고민을 하며 일을 해야 하는 것 같습니다.
나가는 글
회사에서 데이터 관련 실무를 홀로 하는 입장에서, 조직의 리더 분들께서 지원과 신뢰를 아낌 없이 해주셔서 감사하게 생각하고 있습니다. 하지만 업무의 자유도가 높은 만큼, 사실 제 안의 구체적인 생각들을 공유하거나 피드백을 받을 기회가 많지 않다는 고민도 함께 존재합니다.
이런 상황에서 dbt Meetup을 통해 같은 관심사를 가진 분들, 그리고 저보다 더 잘 아는 분들과 만나는 것은 무척 소중한 시간이었습니다. 제 후기를 공유하고 질문을 통해 피드백을 받으며, 어떻게 풀어가고 계신지 여쭤보는 과정을 통해 스스로의 현 상황을 객관화하고 개선할 부분을 발견하는 데 큰 도움이 되었습니다. 저는 그만큼 다른 분들께 유익한 이야기를 전달해드렸을까 하는 생각이 들기도 하네요.
이렇게 유익한 자리를 마련해주신 Herick님, 그리고 영국에서 오신 Abimbola님께 다시 한 번 감사의 말씀을 전합니다. 앞으로 dbt를 더 깊이 다뤄보며 애널리틱스 엔지니어링 전문성을 한층 더 발전시켜 나가고 싶어 마음이 불타오릅니다. 읽어주셔서 감사합니다.
