ETL과 ELT — 데이터 수집·변환·적재의 기본 패턴

​

왜 ETL/ELT를 알아야 하나요?

​

ETL (Extract → Transform → Load) — 20년간의 표준

​

개념

💡 ETL(Extract-Transform-Load) 은 데이터를 소스에서 추출(Extract) 한 후, 별도의 처리 서버에서 변환(Transform) 하고, 변환이 완료된 데이터를 최종 저장소에 적재(Load) 하는 패턴입니다.

​

왜 ETL이 20년간 표준이었나

​

ETL 시대의 대표 도구들

💡 현업에서 기존 ETL 시스템을 마이그레이션하는 프로젝트를 많이 만나게 됩니다. 이 도구들의 이름을 알아두면 고객과의 대화가 수월해집니다.

​

ETL의 치명적 단점 — “원본이 사라진다”

⚠️ 이것이 ETL → ELT 전환의 가장 큰 동기입니다.”지금 당장 필요 없는 데이터”가 6개월 후에 반드시 필요해집니다. 원본을 보존하지 않으면 되돌릴 수 없습니다.

​

ETL이 여전히 적합한 경우

• 개인정보 마스킹이 적재 전에 필수인 경우: GDPR/개인정보보호법 때문에 원본에 주민번호, 카드번호가 있으면 저장 자체가 불가능합니다. 변환(마스킹) 후 적재해야 합니다
• 소스 시스템의 데이터를 네트워크 밖으로 보내기 전에 집계해야 하는 경우: 대역폭이 제한된 환경
• 임베디드/IoT 엣지 처리: 센서 데이터를 모두 전송할 수 없어서 엣지에서 변환 후 전송

​

ELT (Extract → Load → Transform) — 현대의 표준

​

개념

💡 ELT(Extract-Load-Transform) 은 데이터를 소스에서 추출(Extract) 한 후, 원본 그대로 먼저 저장소에 적재(Load) 하고, 저장소 내부의 강력한 컴퓨팅 파워를 활용하여 변환(Transform) 하는 패턴입니다.

​

ETL → ELT 전환이 일어난 진짜 이유

​

”일단 넣고, 나중에 정리” — 이것이 왜 합리적인가

1. 원본을 보존합니다— 변환 로직이 잘못되어도 원본에서 다시 시작할 수 있습니다
2. 변환 로직을 나중에 바꿀 수 있습니다— 비즈니스 요구사항은 반드시 변합니다
3. 여러 팀이 같은 원본에서 서로 다른 변환을 할 수 있습니다— 마케팅팀과 재무팀이 같은 데이터를 다르게 가공

💡 “원본을 보존한다”는 것은 보험입니다. 보험을 안 들면 당장은 저축이지만, 사고가 나면 파산합니다. 데이터도 마찬가지입니다. 원본 보존 비용은 S3 기준 TB당 월 23달러 — 이 보험료는 누가 봐도 저렴합니다.

​

ELT와 Medallion 아키텍처 — 자연스러운 연결

• Bronze가 잘못되면? 소스에서 다시 수집합니다
• Silver가 잘못되면? Bronze에서 다시 변환합니다
• Gold가 잘못되면? Silver에서 다시 집계합니다

​

ETL vs ELT 비교

​

실전: 기존 ETL을 ELT로 마이그레이션하는 전략

​

빅뱅 vs 점진적 마이그레이션

💡 현업에서는 반드시 점진적 마이그레이션을 합니다. 영향도가 낮은 파이프라인부터 시작하여, 팀이 Databricks에 익숙해진 후 핵심 파이프라인을 전환합니다. “이번 주에 100개 파이프라인을 한 번에 옮기겠습니다”라고 하면, 99% 확률로 재앙입니다.

​

마이그레이션 우선순위

1단계: 리포트/대시보드용 배치 파이프라인 (영향도: 낮음)
   → 실패해도 리포트가 하루 늦어지는 정도

2단계: 데이터 사이언스 팀용 피처 파이프라인 (영향도: 중간)
   → ML 모델 재학습에 영향

3단계: 비즈니스 크리티컬 파이프라인 (영향도: 높음)
   → 실시간 매출, 재고 관리, 고객 대면 서비스
   → 반드시 이중 운영(parallel run)을 2~4주 진행

​

Databricks에서의 ELT

​

왜 Databricks가 ELT에 적합한가

1. Apache Spark: 수 TB의 데이터를 수백 대의 서버에 분산 처리. ETL 서버 한 대에서 8시간 걸리던 작업이 Spark 클러스터에서 15분에 끝납니다
2. Delta Lake: 데이터 레이크 위에 트랜잭션, 스키마 관리를 추가. “데이터 늪(Data Swamp)“을 방지합니다
3. Serverless 컴퓨팅: 변환 작업이 필요할 때만 리소스를 할당하여 비용 최적화. 새벽 2시에 30분 돌리고 꺼집니다
4. SDP (Spark Declarative Pipelines): 변환 로직을 선언적으로 정의하면, 실행 순서와 의존성을 자동 관리. “이 테이블은 저 테이블에서 만든다”만 정의하면 됩니다

🆕 최신 트렌드: Databricks Lakeflow Connect 를 통해 Extract(수집) 단계가 관리형 서비스로 제공됩니다. Salesforce, SAP, Oracle DB 등에서 데이터를 자동으로 수집하는 커넥터를 제공하여, 데이터 엔지니어가 변환 로직에만 집중할 수 있습니다. 예전에는 Extract 코드를 짜는 데 전체 작업 시간의 40%를 썼는데, 이제는 커넥터 설정만 하면 됩니다.

​

실무 예시: 온라인 쇼핑몰 데이터 파이프라인

​

1단계: Extract & Load (Bronze)

-- Auto Loader로 S3에서 주문 JSON 파일을 원본 그대로 수집
-- 핵심: 데이터를 절대 변환하지 않습니다. 원본 그대로 넣습니다.
CREATE OR REFRESH STREAMING TABLE bronze_orders
AS SELECT
  *,
  _metadata.file_path AS source_file,      -- 어디서 온 파일인지 추적
  _metadata.file_modification_time AS ingested_at  -- 언제 수집했는지 기록
FROM STREAM read_files(
  's3://my-bucket/orders/',
  format => 'json'
);

💡 source_file과 ingested_at을 기록하는 이유: 나중에 “이 데이터가 어디서 왔는지”, “특정 파일에 문제가 있었는지” 추적할 수 있어야 합니다. 이것을 데이터 리니지(Data Lineage) 라고 하며, 문제 발생 시 디버깅에 필수적입니다.

​

2단계: Transform (Silver)

-- 정제: 중복 제거, 타입 변환, 유효성 검증
-- 이 단계에서 "깨끗한 데이터"를 만듭니다
CREATE OR REFRESH STREAMING TABLE silver_orders (
  -- 데이터 품질 규칙: 위반 시 해당 행을 버립니다
  CONSTRAINT valid_order_id EXPECT (order_id IS NOT NULL) ON VIOLATION DROP ROW,
  CONSTRAINT valid_amount EXPECT (amount > 0) ON VIOLATION DROP ROW
)
AS SELECT
  CAST(order_id AS BIGINT) AS order_id,
  CAST(customer_id AS BIGINT) AS customer_id,
  CAST(order_date AS TIMESTAMP) AS order_date,
  CAST(amount AS DECIMAL(10,2)) AS amount,
  UPPER(TRIM(status)) AS status  -- "pending", " PENDING", "Pending" → 모두 "PENDING"
FROM STREAM(bronze_orders);

⚠️ amount > 0 제약 조건을 넣을 때 주의: 앞서 말한 “환불 데이터 삭제” 실수를 기억하세요. 환불(음수 금액)이 비즈니스에서 발생하는지 반드시 확인한 후 규칙을 설정하세요. 확실하지 않으면 DROP ROW 대신 태그만 달아두는 것 이 안전합니다.

​

3단계: Transform (Gold)

-- 비즈니스 집계: 일별/상품별 매출 요약
-- 대시보드에서 바로 사용할 수 있는 형태
CREATE OR REFRESH MATERIALIZED VIEW gold_daily_sales
AS SELECT
  DATE(order_date) AS sale_date,
  product_category,
  COUNT(*) AS order_count,
  SUM(amount) AS total_revenue,
  AVG(amount) AS avg_order_value
FROM silver_orders
GROUP BY DATE(order_date), product_category;

​

현업 사례: Informatica 라이선스 비용이 연 5억인 기업이 ELT로 전환한 이유

​

배경

​

전환 동기 — “비용”만이 아니었습니다

​

ELT 전환 후 결과 (18개월 후)

​

ETL에서 ELT로 전환할 때 가장 어려운 점

​

1. 조직 문화의 저항

DBA/ETL 팀의 전형적인 반응:
"10년간 잘 돌아가는 ETL을 왜 바꿉니까?"
"Spark는 배워본 적이 없는데요"
"원본을 그대로 넣으면 데이터 품질은 누가 보장합니까?"

💡 현업에서는 이렇게 합니다: 기존 ETL 팀을 “적”이 아니라 “주인공”으로 만들어야 합니다. 이 팀이 가장 잘 아는 것은 비즈니스 로직입니다. Informatica 매핑에 들어있는 변환 로직을 SQL로 재작성하는 역할을 맡기면, 자연스럽게 Databricks에 익숙해지면서 동시에 기존 지식이 보존됩니다.

​

2. 기존 코드 자산의 처리

⚠️ 이것을 안 하면: 2,300개를 전부 1:1로 변환하려다가 2년이 걸리고, 결국 이중 운영 비용만 늘어납니다. 반드시 사용 빈도를 분석 하세요. 대부분의 기업에서 전체 ETL 매핑의 30%는 아무도 사용하지 않는 좀비 파이프라인입니다.

​

3. 데이터 정합성 신뢰 확보

-- 정합성 비교 쿼리 패턴
-- 기존 DW와 신규 Lakehouse의 결과를 비교합니다
SELECT
    'DW' AS source,
    COUNT(*) AS row_count,
    SUM(amount) AS total_amount,
    COUNT(DISTINCT customer_id) AS unique_customers
FROM oracle_dw.sales.daily_summary
WHERE date = '2025-03-30'

UNION ALL

SELECT
    'Lakehouse' AS source,
    COUNT(*) AS row_count,
    SUM(amount) AS total_amount,
    COUNT(DISTINCT customer_id) AS unique_customers
FROM catalog.gold.daily_summary
WHERE date = '2025-03-30';

​

Databricks에서 ELT 구현 실전 패턴

​

패턴 1: CDC 기반 실시간 ELT

-- Lakeflow Connect로 MySQL CDC 수집 (Bronze)
-- 변경분만 자동으로 캡처하여 Delta 테이블에 적재

-- Silver: CDC 이벤트를 최신 상태로 MERGE
CREATE OR REFRESH STREAMING TABLE silver_customers
AS SELECT *
FROM STREAM(bronze_customers_cdc)
-- SDP APPLY CHANGES INTO를 사용하면 CDC MERGE를 자동 처리

​

패턴 2: 멀티 소스 조인 ELT

-- Gold: 여러 Silver 테이블을 조인하여 비즈니스 뷰 생성
CREATE OR REFRESH MATERIALIZED VIEW gold_customer_360
AS SELECT
    c.customer_id,
    c.name,
    c.segment,
    o.total_orders,
    o.total_revenue,
    o.last_order_date,
    s.nps_score,
    s.last_survey_date
FROM silver_customers c
LEFT JOIN (
    SELECT customer_id,
           COUNT(*) AS total_orders,
           SUM(amount) AS total_revenue,
           MAX(order_date) AS last_order_date
    FROM silver_orders
    GROUP BY customer_id
) o ON c.customer_id = o.customer_id
LEFT JOIN silver_surveys s ON c.customer_id = s.customer_id;

💡 현업 팁: ELT에서 가장 중요한 것은 Bronze를 절대 건드리지 않는 것 입니다. Bronze는 “금고에 넣어둔 원본”입니다. 변환 로직이 잘못되면 Silver를 Drop하고 Bronze에서 다시 만들면 됩니다. ETL에서는 이것이 불가능했습니다.

​

정리

​

참고 링크

• Databricks: Medallion Architecture
• Databricks: Data Engineering
• Databricks Blog: ETL vs ELT
• Databricks: Lakeflow Connect
• Databricks: Auto Loader