정의
ETL(Extract Transform Load) 은 여러 소스에 흩어져 있는 데이터를 추출(Extract) 하고, 비즈니스 규칙에 맞게 변환(Transform) 한 뒤, 분석·리포트·CRM 등에서 쓸 수 있도록 목적지 저장소에 적재(Load) 하는 데이터 파이프라인 프로세스입니다.
이커머스 DTC 브랜드에서는 보통 아래 소스가 섞여 있습니다.
- 쇼피파이(Shopify) 주문·고객 데이터
- 메타(Meta)·구글(Google)·틱톡(TikTok) 광고 성과
- 카페24·스마트스토어 등 국내 채널
- Klaviyo·Braze 등 CRM/메시징 툴
- 자체 앱 로그, CS 티켓, 재고(WMS) 데이터
ETL은 이 데이터를 한 곳(예: Snowflake, BigQuery, Redshift) 에 모아 “오늘 ROAS가 얼마인가”, “재구매율이 떨어졌나”를 바로 볼 수 있게 만드는 기반입니다.
비유로 이해하기
ETL을 스무디 가게에 비유해 봅시다.
- Extract = 마트, 농장, 냉동창고에서 과일을 가져오는 것
- Transform = 씻고, 껍질 벗기고, 레시피 비율대로 자르고 섞는 것
- Load = 완성된 스무디를 컵에 담아 진열대에 올리는 것
중요한 건 레시피(Transform) 입니다. 과일만 다 모아놓으면 스무디가 아니라 그냥 과일 바구니입니다. DTC에서 이 레시피는 보통 “통화 통일(USD/KRW)”, “중복 주문 제거”, “광고비와 주문 매칭”, “신규/재구매 고객 구분” 같은 규칙입니다.
공식
ETL의 핵심 계산은 대부분 변환 단계의 지표 정의에서 나옵니다.
ROAS = 광고 기여 매출(Attributed Revenue) / 광고비(Ad Spend)
LTV = 평균 주문 금액(AOV) × 연간 구매 횟수 × 평균 유지 기간(년)
CAC = (광고비 + 프로모션 비용 + 툴 비용) / 신규 고객 수
전환율(CVR) = 주문 수 / 세션 수 × 100
ETL 파이프라인에서는 이 값들을 원천 데이터에서 직접 계산하도록 Transform 로직에 넣습니다. 예를 들어 광고비는 매일 09:00 KST에 API로 추출하고, 주문은 15분마다 증분 추출한 뒤, 통화·시간대를 KST로 통일해 매출과 조인합니다.
비교표: ETL vs ELT
| 구분 | ETL | ELT |
|---|---|---|
| 처리 순서 | 추출 → 변환 → 적재 | 추출 → 적재 → 변환 |
| 변환 위치 | 별도 서버/툴 (예: dbt 이전 단계) | 데이터 웨어하우스 내부 (예: dbt, SQL) |
| 장점 | 보안·정제 후 저장, 레거시 시스템 친화적 | 확장성, 원본 보존, 빠른 실험 |
| 단점 | 변환 서버 비용·병목, 원본 손실 위험 | 저장 비용 증가, 거버넌스 필요 |
| DTC 적합 상황 | 개인정보 마스킹 필수, 규제 산업 | 스타트업·성장 브랜드, 빠른 지표 변경 |
| 대표 도구 | Informatica, Talend, Airflow+Python | Fivetran, Airbyte, BigQuery, Snowflake, dbt |
실무 팁: DTC 브랜드 대부분은 **Fivetran/Airbyte로 추출·적재(EL)** + **dbt로 변환(T)** 하는 하이브리드(ELT)를 씁니다. 그래도 “ETL”이라는 용어는 업계에서 관용적으로 계속 쓰입니다.
DTC/이커머스 적용 시나리오
1) 광고 성과 통합 대시보드
- Extract: 메타·구글·틱톡 광고 API에서 일 1회, 캠페인·광고세트·소재 단위로 추출
- Transform: UTM 파라미터 정규화, 어트리뷰션 윈도우(7일 클릭/1일 뷰) 적용, 통화 KRW 통일
- Load: BigQuery mart_ad_performance 테이블에 적재
- 결과: 오늘 ROAS 3.8, CAC 18,400원, 광고비 2,150만 원 같은 수치를 대시보드에서 즉시 확인
2) 코호트·재구매 분석
- Extract: Shopify 주문, 고객 태그, 이메일 오픈/클릭
- Transform: 첫 구매일 기준 코호트 생성, 30/60/90일 재구매 플래그
- Load: Snowflake cohort_retention 테이블
- 결과: “1월 코호트의 90일 재구매율 22.4%”처럼 확인
3) 재고·발주 자동화
- Extract: WMS 재고, 3PL 입출고, 판매 속도
- Transform: SKU별 일평균 판매량, 리드타임 반영 안전재고 계산
- Load: 발주 시스템에 권장 발주량 전달
- 결과: 품절률 4.1% → 1.9%로 개선
4) CRM 세그먼트 동기화
- Extract: 주문·행동 로그
- Transform: RFM(Recency, Frequency, Monetary) 점수화
- Load: Klaviyo 리스트에 “VIP”, “이탈 위험” 세그먼트 푸시
- 결과: VIP 캠페인 오픈율 41%, 일반 캠페인 19%
자주 하는 실수
1. 정의 없이 숫자부터 모은다
“매출”이 결제 완료인지, 배송 완료인지, 환불 차감인지 정하지 않으면 대시보드마다 값이 다릅니다.
2. 시간대·통화를 나중에 맞춘다
광고는 UTC, 주문은 KST, 정산은 USD면 하루 경계가 어긋나 ROAS가 왜곡됩니다. Transform 단계에서 KST·KRW 기준으로 통일하세요.
3. 중복 적재를 방지하지 않는다
주문 ID 기준 Upsert(Merge) 없이 Append만 하면 매출이 2배로 보입니다.
4. 개인정보를 그대로 적재한다
이메일·전화번호는 해시 처리 또는 별도 보관. 국내는 개인정보보호법, 글로벌은 GDPR/CCPA를 함께 고려해야 합니다.
5. Transform을 너무 일찍 고정한다
DTC는 지표 정의가 자주 바뀝니다. 원본은 그대로 두고 dbt 모델로 변환하는 편이 유지보수에 유리합니다.
6. 모니터링이 없다
파이프라인 실패를 3일 뒤에 알면 광고 최적화가 멈춥니다. 행 수, 지연 시간, null 비율 알림을 필수로 걸어두세요.
관련 용어
- ELT: 추출·적재 후 웨어하우스에서 변환
- Reverse ETL: 웨어하우스 데이터를 다시 SaaS 툴로 보내는 역방향 적재
- Data Warehouse: Snowflake, BigQuery, Redshift
- Data Lake: S3, GCS에 원본 저장
- dbt: SQL 기반 변환·문서화·테스트 도구
- Airflow: 파이프라인 스케줄링·오케스트레이션
- CDC(Change Data Capture): 변경분만 증분 추출
- Upsert/Merge: 중복 없이 적재하는 방식
- Attribution: 광고 기여도 배분(7일 클릭, 1일 뷰 등)
- RFM: Recency·Frequency·Monetary 고객 세그먼트
- Cohort Analysis: 가입·첫 구매 시점 기준 그룹 분석
마무리
ETL은 “데이터를 모으는 기술”이 아니라 비즈니스 정의를 코드로 고정하는 작업입니다. DTC 브랜드에서 ETL이 잘 갖춰지면 광고·CRM·재고가 같은 숫자를 보고 움직일 수 있습니다. 반대로 정의가 흔들리면 채널마다 ROAS가 다르게 나와 의사결정이 갈라집니다. 시작은 거창할 필요 없습니다. 주문·광고비·고객 3개 소스만 KST·KRW 기준으로 통일해 매일 아침 자동 적재하는 것부터 해보세요.