데이터 파이프라인과 저장소 용어

데이터 파이프라인이란

데이터 파이프라인(data pipeline)은 데이터를 만들어지는 곳에서 쓰이는 곳까지 옮기면서 쓸 수 있는 모양으로 바꾸는 과정이다. 앱 DB, 이벤트 로그, 외부 API, 기기 센서에 흩어진 데이터를 모아 정리해야 분석·대시보드·머신 러닝이 같은 데이터를 믿고 쓸 수 있다.

페이지뷰·방문자 수 몇 개만 뽑거나 원본에서 바로 숫자를 읽으면 되는 단계라면 파이프라인은 필요 없다. 여러 데이터를 서로 엮거나 중간에 변환한 결과를 다시 재료로 쓸 때 필요해진다. 추천을 예로 들면 「사용자 행동 집계 → 사용자 성향 점수」, 「추천 결과에 대한 반응 분석」, 「새 글의 성향 평가」, 「사용자별 점수 계산 → 상위 N개 추천」이 각각 하나의 파이프이고, 각 파이프는 자기 결과물을 남기며 다음 파이프의 입력이 된다. 이런 파이프가 수십 개로 늘면 실행 순서·재시도·실패 알림을 맡는 오케스트레이터가 필요하다. 머신 러닝을 위한 것이면 머신 러닝 파이프라인이라고도 부른다(MLOps).

다섯 단계

flowchart LR
  C["수집(Collect)<br/>앱·DB·기기 스트림"] --> I["적재(Ingest)<br/>이벤트 큐에 정리해 넣기"]
  I --> S["저장(Store)<br/>웨어하우스·레이크·DB"]
  S --> P["처리(Compute)<br/>정제·집계·변환"]
  P --> U["활용(Consume)<br/>BI·대시보드·ML·서비스"]

각 단계의 품질이 다음 단계의 상한이다. 수집에서 빠진 이벤트는 아무리 잘 처리해도 대시보드에 나오지 않는다. 그래서 무엇을 어떤 모양으로 남길지부터 정한다(이벤트 로그 설계와 수집).

활용 쪽 결과물은 크게 둘로 갈린다. 「IT 기사를 본 사용자의 연령 비율」처럼 많이 모아 훑는 분석용(OLAP) 결과와, 「이 사용자가 방금 본 기사와 비슷한 기사」처럼 한 사용자를 즉시 조회하는 서비스용(개인화) 결과다. 서비스용은 실시간 이벤트에 분석으로 만든 메타데이터를 조인해 수 초 안에 내놓아야 하므로 저장소와 처리 방식이 따로 필요하다.

단계별 도구 지도 (2026)

도구는 블록처럼 조합하는 것이다. 아래 도구를 다 알 필요는 없고, 단계마다 몇 개를 골라 잇는다. 대신 비슷한 도구 대비 왜 이 도구인지 설명할 수 있어야 한다. 언어와 플랫폼도 문제를 푸는 수단을 고르는 일이다.

도구를 나누는 축 몇 가지는 알아 둔다.

도구를 고르는 원칙

• 사람이 머신보다 비싸다. HDFS와 Hadoop을 직접 설치해 운영하면 그것을 이해하고 업그레이드할 사람을 뽑아야 한다. 객체 저장소 + 관리형 클러스터(EMR, Dataproc)처럼 버튼으로 늘리는 쪽을 먼저 본다. 고민의 결과가 「머신 대신 사람이 더 들어가는」 선택이면 다시 생각한다.
• 빅데이터 도구는 한 서버로 안 될 때 쓴다. 메모리가 모자라거나 디스크가 차서 서버 한 대로 감당할 수 없을 때가 빅데이터다. 그 전에는 분산 시스템의 운영비가 이득보다 크다(분산 데이터 처리).
• 하나의 저장소, 하나의 언어. 데이터를 한곳에 모으고 SQL로 조회하게 하면 엔지니어·분석가·마케터가 같은 언어로 일한다. 저장소마다 전용 질의어(Elasticsearch 쿼리 등)를 배우게 하지 말고, 표현력이 모자라면 함수가 풍부한 SQL 엔진(Trino, BigQuery)으로 메운다. 대시보드·노트북 같은 조회 도구는 그 위에 용도별로 얹는다.
• 배치로 시작하고 필요할 때 스트림을 더한다. 배치는 구조가 단순해 빨리 만들고 싸게 돌린다. 실시간 요구가 확인되면 그때 스트림 파이프라인을 붙인다.
• 요구 사항을 질문으로 확인한다. 기술이 결정을 이끌게 두지 않는다.

배치와 스트림

배치는 이미 저장된 데이터를 통째로 읽으니 전체 그림을 본다. 스트림은 저장되기 전 흘러가는 조각만 보므로 볼 수 있는 범위가 좁은 대신 바로 반응한다.

스트림의 시간과 상태

• 이벤트 시간과 수집 시간은 다르다. 15시 30분에 생긴 로그가 기기의 네트워크 사정으로 16시에 들어오는 일이 흔하다. 시간 단위 파티션을 이벤트 시간으로 나누면 늦게 온 로그를 어디까지 기다릴지 정해야 한다.
• 늦게 오는 데이터는 두 층으로 받는다. 최근 데이터는 1분 안에 보이는 「핫」 영역에 바로 쌓고, 몇 시간 늦게 온 로그까지 반영한 「콜드」 영역을 배치가 뒤따라가며 보정한다. 실시간 결과는 늘 정확하지 않으며, 배치가 최종 정답을 만든다.
• 윈도로 끊어 집계한다. 겹치지 않게 일정 간격으로 자르는 텀블링(tumbling) 윈도, 일정 간격으로 미끄러지며 겹치는 슬라이딩(sliding) 윈도, 활동 사이 공백으로 나누는 세션(session) 윈도가 있다. 늦게 온 데이터를 언제까지 받아 줄지는 워터마크(watermark)로 정한다.
• 상태는 메모리에 있으니 무한히 키울 수 없다. 사용자 ID처럼 키가 계속 늘면 윈도 기간으로 자르거나 TTL로 오래된 키를 지운다. 장애에 대비해 상태를 객체 저장소에 체크포인트로 남긴다.
• 상태를 진실의 원천으로 삼지 않는다. 앱 안의 상태가 깨지거나 모델이 바뀌면 복구할 길이 없다. 원본 로그에서 특정 시점부터 다시 소비해 결과를 다시 만들 수 있게 설계한다.

메시지가 유실되거나 중복되는 수준(at-most / at-least / exactly once)과 단계별 대책은 메시지 큐와 Kafka에 있다. 차량 GPS처럼 타임스탬프가 있어 같은 값을 다시 써도 덮어쓰기로 끝나는 데이터는 at-least once로 충분하고, 결제처럼 빠져도 겹쳐도 안 되는 데이터만 exactly once가 필요하다. 도구마다 지원하는 수준이 달라 설계 단계에서 정한다.

람다와 카파 아키텍처

배치와 스트림을 함께 쓰는 대표 구조다.

서빙 층은 비싸므로 실시간 합산이 꼭 필요한 곳(CPC 광고 과금 등)에만 쓰고, 일반 통계는 배치로 끝낸다. 배치·스트림을 같은 API로 짜는 엔진(Flink, Spark Structured Streaming)과 스트림 쓰기를 받는 테이블 포맷이 자리 잡으면서 두 층을 하나의 코드와 테이블로 합치는 쪽이 흔해졌다.

ETL과 ELT

저장소 용어

정형 정도  높음 ◀───────────────────────────────▶ 낮음
          데이터 마트 ⊂ 데이터 웨어하우스   레이크하우스   데이터 레이크
                                         (레이크 + 테이블 포맷)

레이크를 둘 때 같이 풀어야 하는 문제가 있다. 파일·RDB·객체 저장소에 데이터가 흩어지면 어디에 원하는 데이터가 있는지, RDB와 레이크 중 어느 쪽이 원본인지가 흐려진다. 새 테이블과 컬럼 변경을 카탈로그가 자동으로 찾게 하고(Glue 크롤러 등), 쓰레기 데이터가 쌓이지 않게 수명 주기를 정한다.

데이터 계층과 테이블 이름

가공 단계에 따라 테이블을 계층으로 나누면 쓰는 사람도 관리하는 사람도 편하다. 레이크하우스에서는 같은 생각을 메달리온(medallion) 구조의 브론즈·실버·골드라 부른다.

테이블 이름에 도메인·대상·데이터 성격·기간·주기를 넣으면 이름만 보고 무엇인지 안다. 성격은 시계열 원천(timeseries), 덤프 원천(snapshot), 집계(aggr)로 나눈다.

place_summary_aggr_30d_daily        업체 요약, 최근 30일 집계, 매일 적재
leisure_impression_timeseries_hourly 레저 노출 로그, 시간별 가공
place_order_snapshot_daily          업체 주문 스냅샷, 일별

집계 테이블은 평균을 담지 않는다. 평균의 평균은 실제 평균이 아니므로 합계와 개수를 담아 어떤 기간으로든 다시 나눌 수 있게 한다. 기간 내 고유 사용자 수처럼 하루치를 더해 구할 수 없는 값은 1d, 7d, 28d 테이블을 따로 만든다.

분석 저장소가 커 가는 단계

서비스 초기에는 웨어하우스 없이 시작하는 경우가 많다. 보통 아래 순서로 옮겨 가고, 단계마다 막히는 지점이 다르다.

데이터가 운영 DB가 아니라 여러 외부 SaaS(쇼핑몰 플랫폼, 광고 플랫폼)에 흩어진 통합 대시보드라면 출발점이 다르다. 먼저 플랫폼마다 데이터를 어떤 형태(API, 파일 내보내기, 지표 정의)로 내주는지 파악한다. 규모가 작으면 BI 도구의 커넥터로 바로 붙여도 충분하다. 쿼리가 무거워지거나 출처끼리 조인해야 하면 변경분을 실시간에 가깝게 받아(CDC, 메시지 큐, 서버리스 이벤트 처리) OLAP 저장소에 모으는 단계로 넘어간다. 파이프라인부터 짓기 전에 누가 어떤 지표를 얼마나 자주 보는지를 먼저 정해야 규모를 맞출 수 있다.

사용자 행동 분석이 필요해지면 외부 분석 SDK(Firebase 등)로 결제·노출·클릭을 심는 경우가 많다. 설치는 쉽지만 원본 데이터를 그대로 주지 않거나 요약만 주고, 사내 도구와 붙지 않는 경우가 있다. 결국 클라이언트·서버 로그를 직접 정의·검증·수집하는 체계가 필요해진다(이벤트 로그 설계와 수집).

운영 DB를 자주 통째로 덤프하면 DB에 부하가 걸린다. 변경분만 DB 로그에서 읽는 CDC로 바꾸면 부하를 줄이면서 더 자주 반영할 수 있다(CDC의 동작은 데이터 관리 패턴). 어느 단계를 고를지는 저장·데이터 이동 비용과 운영 인력으로 정하고, 구성원 누구나 SQL로 데이터를 조회할 수 있게 되는 것이 웨어하우스의 가장 큰 효과다.

적재와 운영 원칙

단계와 상관없이 지키는 원칙이다.

오케스트레이터(Airflow 등)는 정해진 시각 실행, 작업 간 의존성, 실패 시 재시도, 특정 파일이 생길 때까지 기다리는 센서, 정한 시간 안에 안 끝나면 알리는 SLA를 맡는다. 하지만 재시작이 코드의 버그를 고쳐 주지는 않는다. 「10개 이상이어야 하는데 9개」인 결과가 정상인지 실패인지는 작업 결과를 검증하는 테스트(행 수 기대치, NULL 비율, 신선도)로 잡는다.

정리

• 파이프라인은 수집 → 적재 → 저장 → 처리 → 활용이고, 앞 단계의 품질이 뒤 단계의 상한이다.
• 도구는 단계별로 블록처럼 몇 개만 고르되, 왜 그 도구인지 설명할 수 있어야 한다. 사람이 머신보다 비싸니 관리형을 먼저 본다.
• 배치로 시작하고 실시간이 필요할 때 스트림을 더한다. 스트림은 늦게 오는 데이터와 상태 관리가 핵심이고, 배치가 최종 보정을 맡는다.
• 지금은 원본을 먼저 넣고 저장소 안에서 변환하는 ELT가 흔하다. 웨어하우스는 정형·분석용, 레이크는 원본 그대로, 레이크하우스는 둘을 합친 것이고, 테이블 포맷(Iceberg·Delta Lake)이 그 둘을 잇는다.
• 테이블은 계층과 이름 규칙으로 정리하고, 배치는 재작업을 전제로 만든다.

관련 노트: 이벤트 로그 설계와 수집, 분산 데이터 처리: MapReduce, Spark, SQL 엔진, MLOps, 파이썬 데이터 분석 프로세스, 머신 러닝 기초: 네 단계 추상화, 데이터베이스 모델, 데이터베이스 고르기, 메시지 큐와 Kafka, Elasticsearch와 ELK 스택