데이터 도구를 이름 대신 흐름으로 이해하는 법

데이터 도구를 이름 대신 흐름으로 이해하는 법

AI 뉴스 썸네일

데이터 프로젝트에 처음 들어가면 제품 이름부터 쏟아져요. dbt, Spark, Kafka, Airflow가 한 문장에 섞이면 각 도구가 같은 일을 하는지조차 헷갈리기 쉬워요. 최근 공개된 데이터 도구 지형 가이드는 도구 목록 대신 데이터가 이동하는 순서로 이 생태계를 설명해요. 1

핵심 요약

구분	맡는 일	대표 선택지
수집	원천 시스템의 데이터를 목적지로 옮겨요	Airbyte, dlt, Fivetran, Debezium
저장	분석용 데이터를 비용과 성능 조건에 맞춰 보관해요	Snowflake, BigQuery, S3, Iceberg, Delta Lake
처리	데이터를 정제하고 집계하거나 실시간으로 계산해요	dbt, DuckDB, Spark, Flink
실행 관리	작업 순서, 일정, 재시도, 실패 복구를 맡아요	Airflow, Dagster, Prefect
활용과 관리	대시보드, 운영 업무, 품질, 권한, 계보를 연결해요	Tableau, Metabase, DataHub, OpenMetadata

1. 데이터 도구는 생명주기에서 자리를 찾아야 해요

원문은 데이터의 생명주기를 수집, 저장, 처리, 활용으로 나눠요. 이 기준을 잡으면 이름이 비슷한 제품도 역할을 구분할 수 있어요. Kafka는 이벤트를 받아 보관하고 여러 소비자에게 전달해요. Flink는 들어오는 이벤트를 계속 계산해요. Airflow는 여러 배치 작업의 순서와 실패 복구를 관리해요. 셋을 모두 데이터 파이프라인 도구라고 부를 수 있지만, 실제 책임은 서로 달라요. 2

저장소는 비용과 사용 방식으로 골라요

데이터 웨어하우스는 분석 쿼리를 빠르고 편하게 실행하기 좋아요. 저장 형식과 쿼리 엔진이 한 제품 안에서 긴밀하게 움직이는 대신 비용이 높을 수 있어요. 데이터 레이크는 S3 같은 객체 저장소에 여러 형식의 파일을 저렴하게 보관해요. 다만 이름, 스키마, 접근 정책을 제대로 관리하지 않으면 필요한 데이터를 찾기 어려워져요.

728x90

레이크하우스는 레이크 위에 테이블 형식을 얹어요. Apache Iceberg, Delta Lake, Apache Hudi가 대표적이에요. 이 계층이 ACID 트랜잭션, 스키마 변경, 버전 관리와 같은 기능을 맡아요. 저장 비용만 비교하면 판단을 그르칠 수 있어요. 실제 설계에서는 쿼리 엔진의 연산 비용과 운영 복잡도도 함께 계산해야 해요.

처리 규모와 지연 시간부터 정해요

작은 데이터는 pandas, Polars, DuckDB만으로도 충분할 수 있어요. DuckDB는 별도 서버 없이 CSV와 Parquet를 SQL로 조회할 수 있어 탐색 작업이나 작은 배치에 잘 맞아요. 단일 머신의 메모리와 CPU를 넘어서면 Spark 같은 분산 처리 도구를 검토할 차례예요.

결과를 언제 받아야 하는지도 선택을 바꿔요. 지난달 매출 집계는 배치로 처리해도 돼요. 결제 이상 탐지나 실시간 사용량 집계는 이벤트가 들어오는 즉시 계산해야 할 수 있어요. Kafka는 이벤트 전달과 보관을, Flink는 지속적인 스트림 계산을 맡는 식으로 책임을 나누면 구성이 선명해져요.

파일 형식도 파이프라인의 일부예요

CSV는 작은 데이터를 전달하고 사람이 직접 열어 보기 편해요. Parquet는 열 단위 저장과 압축을 활용해 큰 분석 데이터를 저장하거나 옮길 때 유리해요. Arrow는 파일 보관보다 메모리 안의 계산과 도구 사이 데이터 전달에 초점을 맞춰요. 같은 데이터라도 저장, 전송, 계산 중 어디에 쓰는지에 따라 적합한 형식이 달라져요.

마지막 단계는 대시보드에서 끝나지 않아요

처리한 데이터는 BI 대시보드 외에도 영업과 고객 지원 도구, 제품 안의 분석 화면, 머신러닝 학습에 쓰여요. 웨어하우스의 고객 점수를 CRM으로 돌려보내는 역방향 ETL도 여기에 들어가요. 다수 사용자에게 밀리초 단위 분석을 제공한다면 ClickHouse나 Apache Pinot 같은 실시간 OLAP 저장소가 필요할 수 있어요.

팀과 파이프라인이 커지면 데이터의 의미를 관리하는 일이 더 어려워져요. 카탈로그는 데이터의 소유자와 접근 정책을 기록해요. 시맨틱 계층은 매출이나 활성 사용자 같은 지표 정의를 통일해요. 데이터 계보는 특정 열이 어느 원천과 변환을 거쳤는지 추적해요. 도구를 추가하기 전에 누가 어떤 데이터를 만들고 책임지는지부터 정해야 이 기능들이 제대로 작동해요.

왜 중요한가요

데이터 프로젝트의 초기 설계에서는 유명 제품을 많이 넣는 것보다 경계를 분명히 하는 편이 실용적이에요. 원천 데이터는 어디에 있고, 얼마나 자주 바뀌며, 결과를 몇 초 안에 받아야 하는지 먼저 적어 보세요. 데이터양, 쿼리 유형, 장애 복구 수준, 접근 권한까지 정하면 필요한 범주가 드러나요. 그다음 각 범주 안에서 운영 부담과 비용을 비교할 수 있어요. 2

작은 팀이라면 PostgreSQL, 객체 저장소, DuckDB, 정기 작업만으로 시작해도 돼요. 실시간 요구가 없는데 Kafka와 Flink를 먼저 들이면 운영할 시스템만 늘 수 있어요. 반대로 여러 원천의 데이터가 자주 바뀌고, 실패한 작업을 부분 재실행해야 하며, 여러 팀이 같은 지표를 쓴다면 수집 도구, 오케스트레이터, 카탈로그에 투자할 이유가 생겨요.

이 가이드는 제품별 성능 비교나 설치법을 다루지 않아요. 대신 새 도구를 만났을 때 던질 질문을 줘요. 무엇을 입력받는지, 어디에 결과를 쓰는지, 데이터를 직접 계산하는지, 다른 작업의 실행만 조정하는지 확인하면 낯선 제품도 기존 지형 안에 놓을 수 있어요.

참고 자료

1. 개발자를 위한 데이터 도구 지형 가이드 — GeekNews
2. Guide to data tools landscape for developers — OlegWock