[14일차] 데이터 파이프라인 개념

0520 수업

📊 데이터 파이프라인 기본 개념 완전 정리

PM·DA 통합 과정 13회차 | 핀테크 사례 중심

---

📌 핵심 내용 요약

데이터 파이프라인이란?

데이터가 발생하는 곳부터 최종 목적지(분석·AI·백오피스)까지
자동으로, 정확하고, 안전하게 흐르도록 시스템을 구축하는 것

 

파이프라인이 없으면 어떤 일이 생길까?

• PM의 고통: 이벤트 전환율을 보려면 DA에게 부탁 → SQL → 1시간 뒤 답변 / 결제 직후 잔액이 안 바뀌는 CS 폭주
• DA의 고통: 매출 반토막의 원인이 Batch 적재 실패 / VAN사 가맹점명 표기가 매번 달라 분석 불가

---

📚 내용 정리

1️⃣ 데이터 파이프라인 4단계 여정

단계	이름	설명	핀테크 예시
①	Generation (생성)	앱 이벤트, 서버 트랜잭션, 외부 API 등에서 데이터가 태어남	토스 송금 버튼 탭, 카카오페이 결제 완료
②	Ingestion (수집)	Batch(정해진 주기) vs Streaming(즉시) 두 방식으로 수집	카드 매입 일 1회 정산 / 이상거래탐지 즉시 차단
③	Processing (가공)	조인·필터링·정규화·마스킹 후 Data Lake/Warehouse 저장	GS25역삼점 → GS25 → 편의점 카테고리 정규화
④	Consumption (소비)	BI 대시보드, ML 모델, 자동화 트리거 등	PM 대시보드, 대출 한도 추천 ML 모델

 

Batch vs Streaming 선택 기준

구분	Batch (일괄)	Streaming (실시간)
처리 방식	정해진 주기에 한 번에 모아 처리	발생 즉시, 끊임없이 흘려보냄
핀테크 예시	월간 소비 리포트, 신용점수 일 1회 갱신	FDS 이상거래 즉시 차단, 송금 즉시 수신자 푸시

---

2️⃣ 핵심 이론과 아키텍처

① ETL → ELT (현대 방식으로의 전환)

• ETL (전통): 추출 → 가공 → 적재. 가공 서버가 병목, 원본 보존 안 됨
• ELT (현대): 추출 → 적재 → 가공. 클라우드 DW(BigQuery·Snowflake)에 원본 보존 후 SQL로 변환 → Backfill 용이

② Medallion 아키텍처

Bronze (Raw)  →  Silver (Cleansed)  →  Gold (Mart)
원본 그대로       정규화·표준화·마스킹     비즈니스 지표 집계
raw_card_transactions  →  silver_card_transactions  →  mart_user_monthly_spending

 

③ Lambda 아키텍처

• Hot Path (Streaming): 즉시 알림·실시간 대시보드 → 송금 즉시 1초 이내 푸시
• Cold Path (Batch): 정확한 집계·회계 데이터 → 새벽 Batch로 회계 마감
• 회계 정확도가 핵심인 핀테크는 여전히 Lambda가 표준

④ 운영 안정성 3대 개념

개념	의미	핀테크 예시
CDC (Change Data Capture)	DB 변경을 실시간 캡처	송금 트랜잭션 → 1분 내 분석 DW 자동 반영
Idempotency (멱등성)	같은 작업 여러 번 실행해도 결과 동일	Batch 재실행해도 중복 없음 (PK 기준 MERGE/UPSERT)
Backfill (백필)	과거 데이터를 다시 처리	카테고리 규칙 변경 후 지난 3개월 데이터 재산정

 

⑤ 데이터 품질 6차원

차원	핵심 질문	핀테크 예시
Completeness	Null이 너무 많지 않은가?	merchant_id 비면 카테고리 분류 불가
Accuracy	실제 값과 일치하는가?	1,000원이 10,000원으로 적재 = 회계 사고
Consistency	여러 마트에서 같은 값?	PM·경영진 GMV가 다르면 신뢰 붕괴
Timeliness	SLA 시간 내 도착?	어제 매출은 오늘 오전 8시까지 확정
Uniqueness	PK 중복 없는가?	같은 결제 2번 적재 = 매출 2배
Validity	형식·범위 올바른가?	결제 금액에 음수 금지

---

3️⃣ 핀테크 7개 사례 정리

사례	수집 방식	핵심 교훈
토스 7일 첫 송금 전환율	Streaming + CDC + Batch	이벤트 사전·요구사항이 그대로 파이프라인 입력
가계부 (월간 소비 리포트)	Batch	정해진 주기 + 카테고리 매핑
대출 중도 이탈 리타겟팅	Streaming	이탈 즉시 캐치 + 짧은 윈도우
카카오뱅크 26주 적금 챌린지	Batch	사용자 진행률 집계
토스 신용점수 변동 알림	Batch + 알림	외부 API + 변동 감지
카카오페이 FDS 이상거래탐지	Streaming + ML	결제 직전 위험 점수화
네이버페이 FAST	(도구 진화)	요구사항 정의 → 파이프라인 자동화

모든 사례 공통: Bronze(Raw) → Gold(Mart) 흐름. ML이 끼는 경우 Silver(피처 테이블) 추가

---

4️⃣ PM vs DA, 각자가 파이프라인을 알아야 하는 이유

PM이 알아야 하는 이유

• 데이터 지연(Latency)과 유저 경험을 통제하기 위해 (Batch/Streaming 구분 모르면 CS 폭주)
• 개발팀에게 "이건 Batch로", "이건 반드시 Streaming"이라고 정확히 말할 수 있어야 함
• 어떤 화면에 어떤 데이터를 어떤 주기로 보여줄지 결정하는 사람이 PM

DA가 알아야 하는 이유

• 분석 결과의 신뢰성 = 파이프라인 신뢰성 (매출 반토막 → Batch 장애 먼저 의심)
• Bronze/Silver/Gold 중 어떤 계층에서 분석할지 선택하려면 Lineage 이해 필수
• Null·중복·행수 급변 모니터링 없으면 깨진 숫자가 의사결정에 흘러감

---

⭐ 오늘 기억해야 할 가장 중요한 내용

1. 11-12-13회차는 하나의 순환 구조다

북극성 지표 (11회차)
    ↓
이벤트 사전 + 데이터 요구사항 정의서 (11~12회차)
    ↓
파이프라인 + Bronze/Silver/Gold 테이블 (13회차)
    ↓
대시보드·푸시·ML 모델 → 의사결정
    ↓
다시 북극성 지표 모니터링 → (반복)

11~12회차 산출물이 제대로 작성됐다면, 13회차 파이프라인은 기계적으로 구현 가능하다.

---

2. Batch vs Streaming 결정의 핵심 질문

"이 데이터가 늦으면 사용자·비즈니스에 얼마나 손해인가?"

• 1초라도 늦으면 안 된다 → Streaming (FDS, 송금 푸시)
• 하루 정도 늦어도 괜찮다 → Batch (월간 리포트, 신용점수 갱신)

---

3. Medallion 3계층의 핵심 원칙

• Bronze: 원본을 절대 버리지 않는다 (감사·재가공의 기준)
• Silver: 정규화·표준화로 분석 가능한 상태로 만든다
• Gold: 비즈니스 질문에 즉시 답할 수 있는 집계 테이블

---

4. 네이버페이 FAST가 주는 시사점

"데이터 요구사항 정의서의 품질 = 파이프라인 자동화 수준"

요구사항이 명확할수록 도구의 자동화 효과가 커진다.
12회차에 요구사항을 잘 정의해두면, 13회차 파이프라인은 코드 없이도 만들어진다.

---

5. 핵심 용어 한 줄 정리

용어	한 줄 정의
Source / Sink	데이터 시작점 / 종착점
ETL	추출→변환→적재 (전통 방식)
ELT	추출→적재→변환 (현대 방식, 원본 보존)
CDC	DB 변경사항을 실시간 캡처
Idempotency	같은 작업 여러 번 실행해도 결과 동일 (멱등성)
Backfill	과거 데이터 재처리
SLA	외부 약속 기준 (예: 오전 8시까지 데이터 제공)
Medallion	Bronze→Silver→Gold 계층형 저장 아키텍처
Lambda	Hot Path(실시간) + Cold Path(배치) 병렬 처리 구조

---

오후 개인 실습 - 파이프라인 설계

11-12-13 연결해서 토스 증권 케이스로 작성

노션으로 작성