개발자를 위한 데이터 도구 지도 — 웨어하우스부터 dbt까지

데이터 도구 지도는 “도구 이름 나열”이 아니라 데이터가 어디서 와서, 어디에 쌓이고, 어떻게 가공되며, 누가 쓰는지를 단계별로 붙인 맵입니다. 백엔드·앱 개발자가 데이터 회의에서 놓치는 부분은 대개 이 네 단계 중 하나입니다. 이 글은 설치 가이드가 아니라 용어·역할·도구 클래스 위치를 잡아 주는 입문 지도입니다.

이 글이 답하는 질문

소프트웨어 엔지니어가 데이터 제품·파이프라인 팀에 붙었을 때, 분석·저장·가공 도구가 각각 무엇을 하는지 빠르게 감을 잡도록 돕는 글입니다.

Metabase 대시보드 만드는 법, Spark 클러스터 운영, 통계 기초 강의는 다루지 않습니다. 목표는 “그 사람들이 말하는 말이 어느 단계 얘기인지”를 알아듣는 것입니다. 영문 장문 가이드 Guide to data tools landscape for developers(OlegWock)의 구조를 참고해, 한국 개발자 독자용으로 다시 썼습니다.

데이터 직군, 네 가지 맛

데이터 직군은 크게 분석형 · 과학형 · 엔지니어링형 · ML형으로 나누면 대화가 쉬워집니다. 작은 팀에서는 한 사람이 여러 맛을 겸하지만, 쓰는 도구 묶음이 다릅니다.

유형	대표 직함	하루 일과 예	자주 쓰는 것
분석형	데이터 분석가, BI	SQL로 이탈률 뽑고 Tableau 대시보드	SQL, 스프레드시트, BI
과학형	데이터 사이언티스트	이탈 요인 탐색, 모델·A/B	Python, pandas, 노트북
엔지니어링형	데이터 엔지니어	소스→웨어하우스 파이프라인, 스키마·품질	Spark, 웨어하우스, 오케스트레이터
ML형	ML 엔지니어/사이언티스트	추천·분류 모델 학습·배포·모니터링	학습 스택, 피처 스토어, 서빙 API

분석형은 해석과 전달이 중심입니다. 고객 데이터를 SQL로 가져와 지역별 이탈을 계산하고, 마케팅에 리텐션 아이디어를 제안하는 식입니다.

과학형은 표면 리포트보다 한 겹 더 들어갑니다. 같은 고객 데이터에서 상관 요인을 찾고, 이탈 확률 모델을 만들고, 캠페인 A/B를 설계합니다.

**엔지니어링형(데이터 엔지니어)**은 “분석 가능한 상태”를 만듭니다. 여러 소스에서 끌어와 정리한 뒤 웨어하우스·레이크에 적재하고, 품질 체크와 쿼리 성능을 챙깁니다. 분석가가 한 번 한 작업을 reverse ETL로 안정 스케줄에 올리는 일도 여기입니다.

ML형은 모델 학습·배포·재학습이 축입니다. 이 글에서는 ML 도구 세부는 깊게 다루지 않습니다. 다만 “데이터 도구 지도” 밖이 아니라, 웨어하우스 피처 → 학습 → API 서빙으로 같은 생명주기의 끝단 소비에 가깝다는 점만 기억하면 됩니다.

데이터는 이렇게 흘러간다 — ETL과 ELT

ETL은 Extract(추출) → Transform(변환) → Load(적재) 순서로, 원천에서 뽑고 가공한 뒤 최종 저장소에 넣는 고전 패턴입니다.

ELT는 순서를 바꿉니다. 먼저 원천 데이터를 웨어하우스 등에 넣고, 그 안에서 변환합니다. 원본을 남겨 재가공하기 쉽지만 저장·연산 비용이 늘 수 있습니다. 어느 쪽이 “정답”이 아니라, 원본 보존 vs 비용·지연 트레이드오프입니다.

실무에서는 단계가 겹치거나 반복됩니다. 중요한 건 파이프라인 대화에서 “지금 transform이 소스 쪽인가, 웨어하우스 안인가”를 구분하는 것입니다.

어디에 쌓나 — 웨어하우스·레이크·레이크하우스

저장 유형은 크게 데이터 웨어하우스 · 데이터 레이크 · 데이터 레이크하우스 세 갈래로 보면 됩니다.

파일 형식부터 잡으면 이후 도구가 덜 헷갈립니다. CSV·엑셀은 사람이 주고받기 쉽고, Parquet 같은 컬럼 지향 포맷은 압축·스캔에 유리해 데이터 도구 사이에서 “공통어”에 가깝습니다. 메모리 쪽에서는 Apache Arrow가 제로카피 교환에 자주 쓰입니다.

데이터 웨어하우스는 분석(OLAP)에 맞춘 저장·쿼리 엔진 결합체입니다. 앱 DB(PostgreSQL 등 OLTP)가 “id로 한 행 조회”에 강하다면, 웨어하우스는 “지난 1년 지역별 매출 합” 같은 집계에 강합니다. 대표 예로 Snowflake, BigQuery, Redshift, 오픈/셀프호스트 쪽 ClickHouse·Doris 등이 거론됩니다. 보통 정제된 구조화 데이터의 최종 거점에 가깝고, ELT에서는 랜딩존으로도 씁니다.

데이터 레이크는 S3·GCS·Blob 같은 저렴한 오브젝트 스토리지에 파일을 쌓는 쪽에 가깝습니다. 구조화·반구조·비구조 모두 넣을 수 있지만, 메타데이터 카탈로그와 쿼리 엔진(Spark, Trino, Athena 등) 없이 방치하면 데이터 늪이 됩니다.

데이터 레이크하우스는 레이크 위에 테이블 포맷(Iceberg, Delta Lake, Hudi 등)을 올려 ACID·스키마 진화·타임 트래블 같은 웨어하우스에 가까운 기능을 얹은 형태입니다. 저장은 싸고 엔진은 고를 수 있다는 점이 매력으로 설명됩니다.

한 줄로 비교하면: 웨어하우스는 속도·편의·가격, 레이크는 유연·저비용·거버넌스 부담, 레이크하우스는 둘 사이 절충입니다.

어디서 오나 · 어떻게 가공하나

데이터 소스는 앱 DB, Stripe 같은 SaaS API, 브라우저 이벤트, IoT 등 거의 모든 곳입니다. 매번 직접 스크립트를 짜기보다 Fivetran · Airbyte · dlt 같은 수집(ingestion) 도구로 커넥터를 붙이는 경우가 많습니다. DB에서는 반복 폴링 대신 복제 로그를 읽는 CDC(Change Data Capture, 예: Debezium) 이야기도 자주 나옵니다.

가공은 언어·규모·실시간성으로 갈립니다.

• 언어: 데이터 쪽 범용 언어의 중심은 Python(numpy, pandas, Polars 등). 쿼리·변환 언어로는 SQL이 필수에 가깝습니다.
• 배치 vs 실시간: 월 매출 집계처럼 큰 덩어리·느슨한 SLA는 배치, 사기 탐지·봇 차단처럼 지연이 민감하면 스트림/마이크로배치.
• SQL 변환: dbt·SQLMesh는 SQL 모델과 의존성(DAG)으로 웨어하우스 안 변환을 표준화합니다. “ref로 모델 연결 → 순서대로 빌드”가 핵심 아이디어입니다.
• 로컬 DataFrame: pandas(즉시 실행), Polars LazyFrame(계획 후 collect), 그리고 “분석용 SQLite” 비유의 DuckDB로 CSV·Parquet를 로컬 SQL 조회.
• 분산: 데이터가 한 대를 넘으면 Spark가 사실상 표준에 가깝고, Dask·Ray·Flink 등이 용도별로 붙습니다.
• 스트림: Kafka(이벤트 로그; 처리 자체는 안 함) + Flink·Spark Structured Streaming 등. Kafka Connect/Streams는 이름만 비슷한 별 레이어입니다.
• 오케스트레이션: Airflow·Dagster·Prefect 등은 DAG로 작업을 스케줄·재시도합니다. 데이터 변환 엔진이 아니라 “언제 무엇을 돌릴지” 지휘자입니다. 스트림처럼 끝나지 않는 파이프라인은 Flink 쪽이 더 잘 맞습니다.

품질·관측도 빼놓기 쉽습니다. 잡 실패는 Prometheus·Grafana 계열, 데이터 이상(스키마·볼륨)은 Great Expectations·dbt tests 또는 Monte Carlo류 자동화 도구 이야기가 나옵니다.

적재 이후 같은 저장소 안에서도 메달리온(Bronze/Silver/Gold) 으로 정제 단계를 나누는 팀이 많습니다. Gold는 대시보드·리포트용 모델에 가깝고, 차원 모델링(팩트·디멘전·스타 스키마) 용어가 여기서 자주 나옵니다. 처리 결과를 다시 CRM·헬프데스크로 밀어 넣는 것이 reverse ETL(Hightouch 등)입니다.

표가 늘면 데이터 카탈로그(사람이 읽는 문서·소유권)와 시맨틱 레이어(매출 정의·지역 정의 단일화, LookML·Cube·dbt Semantic Layer)가 필요합니다. 리니지는 테이블·컬럼이 어디서 왔는지 추적해 영향 분석·컴플라이언스에 씁니다.

어디로 쓰이나 — BI·운영 분석·노트북

소비 단계의 대표는 BI 대시보드·리포트입니다. Tableau·Power BI·Looker·Metabase 등이 웨어하우스에 붙어, SQL을 덜 쓰는 사람도 차트를 만듭니다.

운영 분석(operational analytics) 은 전략 리포트만이 아니라 영업·CS 일상에 지표를 넣는 것입니다. HubSpot에 LTV 동기화, Zendesk에 최근 주문·티켓 맥락 등이 예입니다. reverse ETL이 배달 수단 중 하나입니다.

모든 질문이 대시보드일 필요는 없습니다. 애드혹·탐색 분석은 노트북(Jupyter, Colab, Deepnote, marimo 등)이나 웨어하우스 SQL UI에서 “지난주 가입이 왜 줄었나”를 파고드는 작업입니다. 개발자 입장에선 “배포 파이프라인”과 “한 번 쓰는 탐색 노트북”을 혼동하지 않는 것이 중요합니다.

개발자가 오늘 잡을 한 줄 지도

회의에서 도구 이름을 들으면 아래 네 칸 중 어디에 넣을지만 메모해도 데이터 도구 지도가 손에 잡힙니다.

1. 수집 — Airbyte, Fivetran, CDC, 커스텀 인제스터
2. 저장 — 웨어하우스 / 레이크 / 레이크하우스(+ Iceberg·Delta)
3. 처리 — dbt, Spark, Flink, Airflow(오케스트레이션)
4. 소비 — Metabase·Tableau, reverse ETL, 노트북, ML 서빙

제품 기능을 설계할 때도 같습니다. 노트북 제품이면 로컬 DataFrame·SQL 셀·웨어하우스 커넥터가 어느 칸을 건드리는지 먼저 그립니다. 파이프라인 UI면 오케스트레이터 DAG와 실제 변환 엔진을 분리해 그립니다.

FAQ

Q1. 데이터 엔지니어와 백엔드 엔지니어 차이는 뭔가요?

백엔드는 보통 트랜잭션 앱·API·OLTP에 초점을 둡니다. 데이터 엔지니어는 분석·학습이 가능하도록 대량 데이터의 이동·정제·스케줄·품질을 책임지는 비중이 큽니다. 겹치는 기술(Python, SQL, 클라우드)은 많지만 성공 지표가 “요청 지연”보다 “파이프라인 SLA·데이터 신뢰” 쪽에 가깝습니다.

Q2. ETL과 ELT 중 무엇을 써야 하나요?

원본을 웨어하우스에 남기고 변환을 SQL/dbt로 돌리기 쉬우면 ELT가 흔합니다. 소스 부하·개인정보·비용 때문에 먼저 줄여 넣어야 하면 ETL 성격이 강해집니다. 팀 표준과 규제·비용이 기준입니다.

Q3. 데이터 레이크와 데이터 웨어하우스를 둘 다 쓰나요?

자주 같이 씁니다. 날것·다양한 포맷은 레이크, 정제·고빈도 BI 쿼리는 웨어하우스, 또는 레이크하우스 한 축으로 합치는 식입니다. “하나만 고르면 끝”인 회사는 규모가 작을 때 더 흔합니다.

Q4. dbt는 데이터베이스인가요?

아닙니다. dbt는 웨어하우스 등 쿼리 엔진 위에서 SQL 변환 모델을 빌드·테스트·문서화하는 도구입니다. 데이터 자체는 엔진이 처리합니다.

Q5. Kafka는 메시지 큐인가요?

비슷한 면도 있지만, 전형적인 큐처럼 “한 번 소비하면 사라짐”이 아니라 로그에 이벤트를 유지해 여러 컨슈머가 재생할 수 있는 이벤트 스트리밍 플랫폼에 가깝습니다. 처리 로직은 Flink 등 별 컴포넌트가 담당하는 경우가 많습니다.

마무리

데이터 도구 지도의 핵심은 제품 로고 암기가 아니라 생명주기 네 칸에 이름을 꽂는 습관입니다. 직군 네 맛, 저장 세 유형, ETL/ELT, 그리고 dbt·Spark·Airflow·BI가 각각 어느 칸인지 구분되면 회의 속도가 달라집니다.

오늘 할 일 한 가지: 최근 스크럼·슬랙에 나온 데이터 관련 도구 이름 세 개를 적고, 각각을 수집 / 저장 / 처리 / 소비 중 하나에 표시해 보세요. 애매하면 그 질문이 동료에게 던지기 좋은 첫 질문입니다.

참고(영문 원 가이드): Guide to data tools landscape for developers — OlegWock, sinja.io