개발자를 위한 데이터 도구 지형 가이드

 (sinja.io)
11P by GN⁺ | ★ favorite | 댓글과 토론
  • 데이터 분야에 처음 참여한 소프트웨어 개발자가 도구의 이름만 외우지 않고, 데이터의 수집/저장/처리/활용 단계에서 각 도구가 맡는 역할과 연결 관계를 파악하도록 전체 지형을 정리함
  • 데이터 직군은 대략 분석/과학/엔지니어링/머신러닝 유형으로 나뉘며, SQL과 BI부터 통계 모델과 노트북, 파이프라인 인프라, 운영 모델 배포까지 서로 다른 문제와 도구를 다룸
  • 저장소는 빠른 분석과 편의성을 제공하는 데이터 웨어하우스, 저렴하고 유연한 데이터 레이크, 테이블 형식으로 ACID와 스키마 관리를 추가한 레이크하우스로 구분됨
  • 데이터 처리는 dbt 같은 SQL 변환, pandas와 DuckDB의 로컬 처리, Spark의 분산 배치 처리, Kafka와 Flink의 스트림 처리로 확장되며, Airflow 같은 오케스트레이터가 독립 작업의 실행 순서와 실패 복구를 관리함
  • 처리된 데이터는 대시보드뿐 아니라 영업/지원 업무, 임시 분석, 머신러닝, 제품 내 분석 기능, 데이터 판매에 활용되며, 규모가 커질수록 카탈로그/시맨틱 계층/계보/거버넌스가 데이터의 의미와 책임을 유지하는 핵심 기반이 됨

개발자가 알아야 할 범위

  • 데이터 회사에 합류했지만 관련 배경이 없던 소프트웨어 엔지니어가 도구의 용도와 노트북과의 상호작용을 이해하기 위해 정리한 개발자용 개괄서임
  • 대시보드 제작법, 통계 기초, Spark 클러스터 운영법이나 같은 범주의 제품별 심층 비교는 다루지 않음
  • 데이터가 어디서 생기고 어떻게 처리·저장·표시되는지 따라가며 각 도구가 맡는 생명주기 단계를 구분함

데이터 직군의 네 가지 유형

  • 실제 역할의 경계는 특히 작은 회사나 팀에서 흐리지만, 전체 지형을 이해하기 위해 네 유형으로 나눌 수 있음
  • 분석형은 SQL과 스프레드시트로 데이터를 해석하고 인사이트를 시각화함
    • Data analyst와 BI analyst가 대표적이며 Tableau, Excel 등을 사용함
    • 고객 데이터를 조회해 지역별 이탈률을 계산하고 Tableau 대시보드와 유지 캠페인 제안을 만드는 작업이 예시임
  • 과학형은 통계·모델·실험을 통해 표면적인 보고보다 깊은 질문이나 예측을 다룸
    • Data scientist가 대표적이며 Python, pandas, scikit-learn, 노트북을 주로 사용함
    • 이탈 요인을 탐색하고 고객별 이탈 가능성 모델을 만든 뒤 유지 캠페인의 A/B 테스트를 설계·분석할 수 있음
  • 엔지니어링형은 원천 데이터를 수집·정제·표준화해 웨어하우스나 레이크에 적재하고 데이터 도구와 데이터베이스를 운영함
    • Data engineer가 대표적이며 Python, Apache Spark, 데이터베이스, 웨어하우스, 클라우드를 사용함
    • 분석 결과를 반복 실행 가능한 역방향 ETL 파이프라인으로 확장하거나, 여러 원천의 거래 데이터를 통합하고 스키마·쿼리·품질 검사를 관리함
  • 머신러닝형은 분류 모델부터 LLM까지 AI 모델을 만들고 운영함
    • ML scientist와 ML engineer를 하나로 묶은 범주이며, 별도 도구 생태계가 커서 본문에서는 상세히 다루지 않음
    • 추천 모델용 학습 데이터를 조립하고 모델을 학습·조정해 API로 배포한 뒤 예측을 감시하고 행동 변화에 맞춰 재학습함

ETL과 ELT

  • ETL(Extract-Transform-Load) 은 원천 데이터를 추출하고, 정제하거나 다른 데이터와 결합한 뒤 결과를 목적지에 적재하는 일반적인 흐름임
  • 단계의 순서는 고정되지 않으며 반복되거나 서로 겹칠 수 있음
  • ELT는 원천 데이터를 먼저 웨어하우스에 적재한 뒤 그 안에서 변환하고 결과를 별도 테이블에 저장함
    • 추가 저장 공간과 연산 때문에 비용이 늘 수 있음
    • 원본이 남아 있어 나중에 다른 방식으로 다시 처리할 수 있음

파일과 메모리 형식

  • CSV는 작은 데이터를 전달하기 쉽고 대부분의 사무용 소프트웨어에서 열 수 있어 비기술 사용자에게 적합함
  • Apache Parquet는 열 지향 파일 형식으로 압축률이 높고 큰 데이터를 효율적으로 저장·전송할 수 있음
    • 대부분의 데이터 도구가 지원해 도구 사이의 공용 형식 역할을 함
    • Apache ORC도 비슷한 문제를 해결함
  • Apache Avro는 행 지향 이진 형식으로 레코드 전달, 특히 스트림 처리에 사용됨
  • Apache Arrow는 처리와 제로카피 전송에 최적화된 사실상의 표준 인메모리 형식임
    • Parquet는 작은 파일과 필요한 항목의 스캔에, Arrow는 CPU·GPU 명령과 캐시를 활용한 실제 계산에 초점을 둠
    • Arrow는 더 많은 메모리를 사용하지만 pandas와 Rust의 DataFusion 같은 도구 사이에서 데이터를 효율적으로 전달함
    • pandas의 선택적 백엔드로 쓸 수 있고 Polars와 DataFusion은 처음부터 Arrow 기반으로 만들어짐

데이터 웨어하우스

  • 데이터 웨어하우스는 PostgreSQL·MySQL 같은 데이터베이스와 비슷하지만 분석 부하에 최적화됨
  • MySQL 같은 OLTP 데이터베이스는 ID로 사용자 행 하나를 찾는 작업에 적합하고, OLAP 웨어하우스는 연간 지역별 매출 합계처럼 열 단위 집계에 적합함
  • 전통적으로 정제된 구조화 데이터의 최종 저장소였지만, ELT에서는 원시 데이터의 최초 적재 지점으로도 사용됨
  • 저장 형식과 쿼리 엔진이 밀접하게 결합되어 빠른 BI·보고 쿼리를 제공하는 대신 세 저장소 유형 가운데 비용이 가장 높음
  • 제품에는 Snowflake, BigQuery, Redshift가 있음
  • 오픈소스·자체 호스팅 선택지에는 ClickHouse, Apache Doris, StarRocks가 있음
  • 작은 프로젝트라면 전통적인 데이터베이스도 충분할 수 있음

데이터 레이크

  • 데이터 레이크는 CSV, Parquet, JSON, 이메일, 이미지 등 구조화·반구조화·비구조화 데이터를 최소한으로 처리해 보관하는 대규모 클라우드 폴더에 가까움
  • Amazon S3, Google Cloud Storage, Azure Blob Storage에 명명·파티션 규칙과 접근 정책을 정하고 파일을 저장해 구축할 수 있음
  • 제대로 관리하지 않으면 찾거나 활용하기 어려운 데이터 늪(data swamp) 이 될 수 있음
  • 관리형 선택지에는 Azure Data Lake와 Snowflake의 데이터 레이크 기능이 있음
  • 데이터를 직접 검색·다운로드·파싱하지 않고 질의하려면 메타데이터 카탈로그와 쿼리 엔진이 필요함
    • 카탈로그는 테이블 이름, 스키마, 파일 매핑을 기록함
    • 쿼리 엔진은 해당 메타데이터로 관련 파일을 읽고 SQL 등의 질의를 실행함
  • 카탈로그에는 Hive Metastore, AWS Glue Data Catalog, Unity Catalog가 있음
  • 쿼리 엔진에는 Apache Spark, Trino, Amazon Athena가 있음

데이터 레이크하우스

  • 데이터 레이크하우스는 저렴하고 유연한 레이크 위에 웨어하우스에 가까운 기능을 추가함
  • 핵심 구성요소인 테이블 형식이 쿼리 엔진과 원시 데이터 사이에서 저장 방식을 관리함
    • ACID로 동시 쓰기, 쓰기 도중 오류, 데이터 손상을 처리함
    • 반구조화 데이터도 스키마를 정의해야 하며, 완전한 비구조화 데이터는 테이블 형식의 이점을 얻지 못함
    • 스키마 진화와 버전 관리를 지원함
    • 인덱스와 파티션 최적화로 질의를 빠르게 만들 수 있음
    • 일부 구현은 특정 시점의 스냅샷을 조회하는 시간 여행을 지원함
  • 레이크 기반이어서 웨어하우스보다 저렴할 수 있고 특정 쿼리 엔진에 묶이지 않지만, 별도 연산 비용까지 포함해야 하므로 일대일 가격 비교는 어려움
  • 주요 테이블 형식은 Apache Iceberg, Delta Lake, Apache Hudi임
  • 관리형 서비스에는 Google의 Lakehouse for Apache Iceberg, Databricks, IBM watsonx.data가 있음

데이터 원천과 수집

  • 데이터는 PostgreSQL·Mongo 같은 애플리케이션 데이터베이스, Stripe 같은 외부 API, 브라우저 분석 이벤트, IoT 장치 등에서 들어옴
  • 추출 후 바로 처리할 수도 있고, ELT에서는 형태·크기·인프라에 따라 레이크·레이크하우스·웨어하우스에 원본을 먼저 저장할 수 있음
  • 전용 스크립트는 유연하지만 인증, 페이지네이션, 오류 처리 같은 반복적인 연결 코드를 다시 구현해야 함
  • 데이터 수집 도구는 원천과 목적지 커넥터를 설정해 이 반복 작업을 처리함
    • 추출 데이터를 먼저 어딘가에 적재해야 하므로 ELT 흐름으로 기울기 쉬움
    • 대표 제품은 Fivetran, Airbyte, dlt임
  • 변경 데이터 캡처(CDC) 는 테이블을 반복 조회하지 않고 데이터베이스 복제 로그에서 삽입·수정·삭제를 포착함
    • 수집 도구가 데이터베이스 원천에 내부적으로 사용함
    • 독립형 오픈소스 구성요소로 Debezium이 널리 쓰임

데이터 처리 언어

  • Python은 큰 커뮤니티와 네이티브 라이브러리 생태계를 갖춘 데이터 작업의 사실상 표준 언어임
    • 다른 언어로 만든 도구도 Python 바인딩을 제공하는 경우가 많으며 Rust 기반 Apache DataFusion이 한 예임
  • numpy는 고성능 다차원 배열을 제공하고 여러 라이브러리의 기반이 됨
  • pandas는 1차원 Series와 2차원 DataFrame을 제공하는 사실상의 표준임
    • seaborn·Plotly로 시각화하고 streamlit으로 대화형 앱을 만들 수 있음
    • DuckDB로 SQL 질의를 하거나 scikit-learn의 머신러닝 기법을 적용할 수 있음
  • R은 학계, Java·Scala는 Spark 같은 빅데이터 프레임워크에서 사용되며 Julia와 Rust도 데이터 작업에 쓰이지만 Python보다 보급률이 낮음
  • SQL은 웨어하우스 질의와 변환에 널리 쓰이지만 실행 환경마다 문법이 조금씩 다름

배치와 실시간 처리

  • 배치 처리는 지난달 매출 집계처럼 큰 데이터 묶음을 정기적으로 처리하며 결과를 몇 시간이나 며칠 기다릴 수 있는 작업에 적합함
  • 실시간 처리는 도착 즉시 처리하는 스트림 방식이나 20초 단위 같은 마이크로배치를 사용함
  • 봇 탐지처럼 결과 속도가 중요한 파이프라인은 사용자를 가능한 한 빨리 식별·차단하기 위해 실시간 처리를 사용함

SQL 기반 변환

  • dbt와 SQLMesh는 SQL select 문으로 변환을 정의하고 실제 쿼리 엔진에서 실행되도록 컴파일함
  • 두 도구는 데이터를 직접 처리하지 않고 변환 오케스트레이션을 담당함
  • 사용자 정의 Python 스크립트보다 변환 방식을 표준화하고 복잡한 작업을 의존성이 있는 작은 모델로 분리할 수 있음
  • dbt의 ref는 하드코딩한 테이블명 대신 모델을 참조하고, 의존성 그래프에 따라 올바른 순서로 실행함
  • 결과는 보통 원본과 같은 웨어하우스·레이크하우스·레이크에 저장되지만, 쿼리 엔진 설정에 따라 다른 목적지로 보낼 수도 있음

로컬 DataFrame과 DuckDB

  • DataFrame은 표 형식 데이터를 다루는 2차원 배열 추상화이며 Python에서는 pandas가 가장 널리 쓰임
  • 다른 구현에는 Python·Rust의 Polars, Rust의 DataFusion, Julia의 DataFrames.jl, R의 data.frame, Java의 tablesaw가 있음
  • pandas, data.frame, tablesaw는 호출 즉시 연산하는 즉시 실행(eager) 방식임
  • DataFusion과 Polars의 LazyFrame은 연산을 논리 계획으로 쌓은 뒤 .collect()에서 실행함
    • 실행 전에 계획을 최적화할 수 있어 더 빨라질 가능성이 있음
  • 로컬 라이브러리는 메모리와 CPU에 제한됨
    • pandas는 모든 데이터를 메모리에서 처리하므로 RAM 크기에 묶임
    • Polars의 스트리밍은 RAM보다 큰 데이터도 다룰 수 있지만 일부 연산은 작업 집합을 메모리에 올려야 함
  • DuckDB는 “분석용 SQLite”로 불리는 인프로세스 OLAP 데이터베이스임
    • 별도 인프라 없이 로컬의 CSV, Parquet, pandas DataFrame을 SQL로 조회함

대규모 분산 처리

  • 단일 머신의 한계를 넘으면 데이터를 여러 조각으로 나눠 클러스터에서 병렬 처리하고 작업량에 맞춰 수평 확장함
  • Apache Hadoop은 초기 대표 도구지만 현재는 레거시로 간주되며 오래된 환경에서 볼 수 있음
  • Apache Spark는 현재 사실상의 표준으로 데이터 로딩·변환·병렬화·최적화를 담당함
    • PySpark는 DataFrame API와 pandas 호환 계층을 제공함
    • SparkR은 최근 폐기됐으며 Java·Scala 바인딩도 제공됨
    • 다양한 저장소를 읽고 쓸 수 있어 데이터 레이크 쿼리 엔진과 대규모 변환 작업 모두에 사용됨
  • Dask는 익숙한 pandas·numpy API에 가깝게 Python 코드를 클러스터로 확장함
  • Ray는 범용 분산 연산 프레임워크로 특히 ML 학습에 많이 쓰임
  • Apache Flink는 배치도 처리하지만 스트림 처리가 주력임

이벤트 스트리밍과 Kafka

  • 스트림 처리는 신용카드 사기 탐지처럼 결과가 즉시 필요하거나, 웹 분석 이벤트를 도착 시 검증하고 IP 지리 정보로 보강해 ClickHouse에 넣는 작업에 적합함
  • 도착 즉시 처리하면 다음 배치 실행 전까지 원시 페이로드를 별도로 보관하지 않아도 될 수 있음
  • Apache Kafka는 생산자의 이벤트를 받아 저장하고 소비자가 읽도록 하는 분산·내결함성 이벤트 스트리밍 플랫폼임
    • 메시지 큐와 달리 소비자가 확인해도 이벤트가 삭제되지 않으며, 보존 규칙이 만료될 때까지 여러 소비자가 반복해서 읽을 수 있음
    • Kafka 자체는 데이터를 처리하지 않고 별도 작업자가 소비자로서 처리함
  • Kafka Connect는 Kafka를 데이터베이스 같은 외부 시스템에 연결함
  • Kafka Streams는 Kafka 위에서 상태 기반 변환, 윈도 집계, 조인을 수행하는 Java·Scala 라이브러리임
    • 애플리케이션에 내장되어 실행되며 Kafka에서만 동작함
  • 다른 이벤트 스트리밍 플랫폼에는 Apache Pulsar, Redpanda, AWS Kinesis Data Streams가 있음

스트림 처리 엔진

  • Apache Flink는 이벤트 원천과 처리 절차를 정의받아 클러스터 배포, 확장, 장애 복구를 담당함
  • 파이프라인은 필터링, 필드 매핑, 윈도 집계, 중복 제거, 다른 Kafka 토픽이나 데이터베이스로의 출력을 포함할 수 있음
  • 배포된 작업은 종료되는 배치가 아니라 새 이벤트를 계속 처리함
  • 다른 선택지에는 Spark Structured Streaming, Google Cloud Dataflow, Azure Stream Analytics가 있음

작업 오케스트레이션

  • dbt 변환, Spark 작업, 사용자 정의 스크립트가 늘어나면 오케스트레이터가 개별 단계를 하나의 파이프라인으로 조합함
  • 각 작업과 의존성을 코드, 주로 Python으로 정의하면 방향성 비순환 그래프인 DAG를 만듦
  • 오케스트레이터는 직접 데이터를 처리하지 않고 Spark 스크립트 실행, dbt 변환 호출, HTTP 요청 등을 조정함
  • 스케줄, Kafka 이벤트, UI의 수동 실행, HTTP 요청, 플러그인으로 만든 트리거를 사용할 수 있음
  • 독립 작업을 병렬 실행하고 실패한 단계만 재시도한 뒤 그 지점부터 재개할 수 있음
  • 시작부터 종료까지 실행되는 배치 처리용이므로 계속 살아 있는 스트림 파이프라인에는 잘 맞지 않으며, 이 경우 Flink 같은 처리 엔진 자체에 의존함
  • 대표 제품은 Apache Airflow, Dagster, Prefect, Luigi임
    • Luigi는 더 오래됐고 현재 인기는 낮음

관측성과 품질 모니터링

  • 데이터 관측은 파이프라인 상태와 데이터 자체의 품질로 나뉨
    • 파이프라인 모니터링은 실행 여부, 실패, 소요 시간을 확인함
    • 데이터 모니터링은 최신성, 데이터량 이상, 예고 없는 스키마 변경 등을 확인함
  • 파이프라인에는 Prometheus, Grafana, ELK 같은 일반 애플리케이션 관측 도구와 오케스트레이터 자체 기능을 사용할 수 있음
  • 데이터 품질 검사는 예상 형식을 직접 정의하는 Great Expectations와 dbt tests로 구현할 수 있음
  • 자동화 제품은 정상 데이터 패턴을 학습한 뒤 이상을 감지하며 Monte Carlo, Bigeye, Metaplane가 예시임

파이프라인에서 반복되는 적재

  • ETL의 마지막 적재 대상은 웨어하우스·레이크·레이크하우스지만, 데이터는 파이프라인 끝에 한 번만 저장되지 않고 서로 다른 형태로 여러 번 저장됨
  • 메달리온 아키텍처는 같은 저장소 안의 정제 수준을 세 계층으로 나눔
    • Bronze는 원천에서 그대로 들어온 원시 데이터임
    • Silver는 타입 수정, 중복 제거, 원천 결합 등을 거친 정제·표준화 데이터임
    • Gold는 대시보드나 보고서 같은 특정 목적에 맞게 집계·모델링한 데이터임
  • 분석가는 주로 Gold 테이블을 조회하고 엔지니어는 파이프라인 디버깅을 위해 Bronze까지 내려갈 수 있음

차원 모델링

  • 메달리온 구조가 데이터의 정제 수준을 나타낸다면 차원 모델링은 웨어하우스 테이블의 형태를 구성함
  • Ralph Kimball의 《The Data Warehouse Toolkit》이 대중화한 방식으로 사실 테이블과 차원 테이블을 구분함
  • 사실 테이블은 주문·결제·페이지 조회처럼 행 하나당 하나의 사건이나 측정값을 저장함
    • 길고 좁으며 숫자와 차원 테이블 외래 키가 많고 계속 커짐
  • 차원 테이블은 고객·제품·날짜처럼 사건이 발생한 맥락을 저장함
    • 더 넓고 상대적으로 천천히 변함
  • 중앙의 사실 테이블을 차원 테이블이 둘러싸면 스타 스키마가 됨
  • 그레인(grain) 은 한 행이 주문 하나, 주문 품목 하나, 고객별 일일 주문 하나 중 무엇을 나타내는지 정의함
  • 데이터 마트는 마케팅·재무처럼 특정 팀이나 주제에 맞춘 웨어하우스 일부이며 보통 Gold 계층에 위치함
  • 모든 팀이 엄격히 따르지는 않으며, 빠른 현대 웨어하우스와 저렴한 저장 비용을 활용해 목적별로 넓게 비정규화한 하나의 큰 테이블을 만들기도 함

애플리케이션용 실시간 OLAP

  • 내부 대시보드에는 웨어하우스의 Gold 테이블이 충분하지만, 다수 사용자에게 밀리초 단위로 제공할 때는 쿼리 지연과 건당 비용이 부적합할 수 있음
  • 사용자 대상 분석, 실시간 내부 모니터링, 리더보드, 인기 항목, 사용량 측정처럼 높은 동시성과 빠른 응답이 필요한 데이터는 실시간 OLAP 데이터베이스로 옮김
  • Apache Druid, Apache Pinot, ClickHouse, Apache Doris가 해당하며 ClickHouse가 널리 쓰임

역방향 ETL

  • 역방향 ETL은 웨어하우스에서 처리한 데이터를 CRM 같은 운영 도구로 되돌려 보냄
  • Stripe 데이터로 고객 생애 가치를 계산해 HubSpot에 넣으면 영업팀이 고가치 고객을 바로 확인할 수 있음
  • 전용 도구는 테이블·열과 목적지 필드를 연결하고 실패, 재시도, 속도 제한, 경고, 증분 동기화를 처리함
  • 선택지에는 Airbyte Data Activation, Fivetran Activations, Hightouch, RudderStack이 있음
    • Fivetran Activations는 인수 전 Census라는 이름이었음

데이터 카탈로그와 시맨틱 계층

  • 사람을 위한 데이터 카탈로그는 데이터의 원천, 소유자, 접근 정책, 검색 정보를 담아 테이블과 열에 비즈니스 맥락을 부여함
  • 시맨틱 계층은 비즈니스 엔터티, 관계, 지표의 표준 정의를 보관함
    • 고객 모델이 어느 테이블과 열에서 오는지, EMEA에 어떤 시장이 속하는지, 매출에서 환불을 제외하는지 등을 통일함
    • BI 도구나 AI 에이전트에서 올바른 엔터티와 지표를 고르면 필요한 쿼리로 변환하거나 쿼리 생성에 필요한 정보를 제공함
  • Looker의 LookML, Cube, dbt Semantic Layer, Unity Catalog의 시맨틱 기능이 예시임

데이터 계보

  • 데이터 계보(data lineage) 는 파이프라인을 거치며 데이터가 어떻게 변환됐는지 추적함
  • 오케스트레이터 DAG, 변환 SQL 파싱, 처리 작업이 내보내는 이벤트·메타데이터에서 자동 수집할 수 있음
  • 테이블 수준에서는 gold.orders가 silver.orders와 silver.customers에서 만들어졌다는 관계를 기록함
  • 열 수준에서는 customers.life_time_value가 orders.total과 subscription_payments.amount에서 계산됐다는 관계까지 추적함
  • 열 삭제의 하류 영향 평가, 잘못된 지표의 근본 원인 분석, 개인 식별 정보 사용에 대한 규정 준수에 활용함
  • Unity Catalog, DataHub, OpenMetadata가 계보 시각화를 지원하지만 전체 파이프라인이 커넥터나 수동 이벤트로 추적 데이터를 제공해야 함
  • 공급자별 형식 대신 여러 카탈로그와 처리 도구가 지원하는 OpenLineage 표준을 사용할 수 있음

BI 대시보드와 보고서

  • 대시보드와 보고서는 데이터 파이프라인의 가장 흔한 소비처이며, 작은 회사에서는 사실상 유일한 활용 사례일 수도 있음
  • BI 도구는 웨어하우스·레이크하우스·애플리케이션 데이터베이스에 연결해 코드를 작성하지 않고 차트와 대시보드를 만들게 함
  • 핵심은 비기술 사용자가 분석가에게 매번 요청하지 않고 UI에서 직접 차트를 만들거나 탐색하는 셀프서비스임
  • 예약 보고서를 이메일·Slack으로 보내거나 지표가 임계값을 넘으면 경고할 수 있음
  • Tableau와 Power BI는 대기업에서 널리 쓰이며 강력하고 유연한 시각화에 초점을 둠
  • Looker는 LookML 시맨틱 계층을 중심으로 기술 조직에 맞춰져 있음
  • Metabase는 자체 호스팅을 포함해 빠르게 설정할 수 있고 비기술 사용자에게 접근하기 쉬움
  • Looker Studio는 LookML을 사용하지 않고 Looker보다 기능이 적은 별도 제품이며 최근 다시 Data Studio로 이름이 바뀜

운영 분석

  • 운영 분석은 경영진 보고서가 아니라 비분석 직군이 매일 사용하는 애플리케이션 안에 데이터를 제공함
  • 활용 예시는 다음과 같음
    • 사용량 집계를 HubSpot에 동기화해 영업팀이 적절한 고객에게 상향 판매함
    • 최근 주문·지원 티켓·요금제를 Zendesk에 동기화해 지원팀이 고객 맥락을 확인함
    • 고객 성공팀을 위해 고객별 제품 도입 현황을 보여주는 내부 앱을 만듦
  • 역방향 ETL이 대표적인 전달 방법이지만, 웨어하우스를 직접 조회하는 내부 Customer 360 앱도 운영 분석에 해당함

임시·탐색 분석과 노트북

  • 임시 분석(ad-hoc analysis) 은 가입 감소 원인이나 환불을 유발한 코호트처럼 일회성 질문을 기존 데이터로 조사함
  • 탐색 분석은 미리 정해진 질문 없이 데이터를 살펴보며 인사이트를 찾음
  • 결과에 따라 다음 연산이 달라지고 단순 필터·집계보다 복잡하므로 일반 보고 도구만으로는 부족할 수 있음
  • Python과 pandas·Polars, 웨어하우스 SQL UI, Spyder, RStudio 등을 사용할 수 있음
  • 노트북은 Markdown, 코드, SQL 같은 셀을 한 파일에 결합하고 이미지·대화형 차트·테이블 출력을 코드 옆에 배치함
    • 실행 결과를 보며 단계적으로 탐색하고 결과를 발표하기 좋음
    • Jupyter, Google Colab, Deepnote, marimo가 대표적임
    • Databricks와 Snowflake 같은 플랫폼도 자체 노트북을 제공함

머신러닝의 데이터 소비

  • ML은 기능 저장소, 학습, 추적, 배포 도구를 갖춘 별도 분야지만 데이터의 주요 소비처임
  • LLM 외에도 이탈 예측, 추천, 수요 예측, 고객 세분화 같은 전문 모델이 있으며 프로덕션 투입 전에 정제된 학습 데이터가 필요함
  • Data scientist나 ML engineer는 최근 30일 주문 수, 마지막 로그인 후 경과일 같은 특징(feature)을 웨어하우스에서 가져와 모델을 학습·배포함
  • 예측 결과는 CRM의 이탈 점수 같은 운영 분석이나 사용자 대상 제품 추천으로 다시 이어짐

임베디드 분석

  • 임베디드 분석은 마켓플레이스 판매자에게 인기 상품, 고객 지역, 검색 순위 같은 분석을 애플리케이션 안에서 제공함
  • 미리 정의된 차트 5개와 제한적인 필터 정도라면 쿼리·UI·차트 라이브러리를 직접 구현할 수 있음
  • 사용자가 복잡한 질의를 해야 한다면 Metabase, Looker, Tableau 같은 BI 도구나 Sisense, Luzmo 같은 임베드 중심 제품을 사용할 수 있음
  • 호스트 애플리케이션은 인증·권한 부여를 담당하고 임베디드 도구는 질의 UI와 차트 렌더링을 처리함

데이터 자체를 상품으로 판매하기

  • 데이터는 기능의 재료를 넘어 제품 자체가 될 수 있음
  • 여러 암호화폐 블록체인의 데이터를 수집·변환·색인해 분석가에게 접근권을 팔거나, Google 검색 결과를 수집해 SEO 전문가에게 판매할 수 있음
  • 데이터와 질의 접근권을 판매하려면 적시에 수집하는 견고한 파이프라인과 고성능 질의 기능이 필요함

데이터 거버넌스

  • 데이터 거버넌스는 개인 식별 정보, 건강 정보 등 민감 데이터에 누가 접근할 수 있는지와 접근 기록을 관리함
  • 데이터 소유권, 잊힐 권리 같은 개인정보 처리, 물리적 저장 위치, 보존 기간도 포함함
  • 웨어하우스의 역할·접근 제어, 카탈로그의 소유권 정보, 계보를 통한 PII 사용 추적 같은 기술이 지원할 수 있음
  • 기술만의 문제가 아니라 사람과 프로세스의 비중이 크며 법무·규정 준수·보안 조직과 밀접하게 연결됨
  • 전체 데이터 지형은 원천에서 수집해 저장·처리하고 활용하는 흐름으로 볼 수 있으며, 각 범주 아래에는 더 많은 도구와 세부 선택지가 계속 생겨남

함께 보면 좋은 글 β