ELT

ELT 는 흩어진 데이터를 분석용 저장소 한곳에 모아 분석할 수 있게 해 줍니다. 꺼내 온 데이터를 손대지 않고 먼저 넣습니다. 분석에 맞게 다듬는 일은 넣은 뒤에 저장소 안에서 합니다. 넣기 전에 다듬는 방식과 순서를 바꾼 것입니다.

상세

사진가는 찍은 원본 사진을 손대지 않고 보관해 둡니다. 보정은 사진을 어디에 쓸지 정해진 뒤에 합니다. 보정이 마음에 안 들면 원본을 다시 열어 처음부터 하면 됩니다.

ELT(Extract Load Transform, 추출·적재·변환)는 데이터를 이렇게 다룹니다. 이름은 세 단계를 뜻하는 영어 낱말의 머리글자입니다. 데이터를 꺼내는 추출, 저장소에 넣는 적재, 분석에 맞게 다듬는 변환입니다. 원본 사진을 보관하는 것이 적재입니다. 보정하는 것이 변환입니다.

이 절은 쇼핑몰의 주문 데이터를 예로 들어 세 단계를 따라갑니다. 같은 일을 다른 순서로 하는 ETL(Extract Transform Load, 추출·변환·적재)과도 견줍니다.

분석용 저장소에 데이터를 모으는 이유

쇼핑몰 백엔드에서 주문은 주문 데이터베이스에, 회원 정보는 회원 데이터베이스에 있습니다. 결제 내역은 결제 대행사가 날마다 파일로 보내 줍니다. 이렇게 데이터가 처음 생기는 곳을 원천 시스템이라고 합니다.

「지난달 가입 경로별 매출이 얼마였나」에 답하려면 여러 원천을 엮어야 합니다. 그런데 서비스용 데이터베이스는 주문 한 건을 빨리 읽고 쓰도록 맞춰 두었습니다. 한 달 치를 훑는 조회를 여기에 던지면 그동안 주문 처리가 밀립니다.

그래서 분석할 데이터를 따로 복사해 모으는 저장소를 둡니다. 이것이 데이터 웨어하우스입니다. 여러 원천의 데이터를 모아 두고 분석 조회를 빠르게 돌리는 분석 전용 데이터베이스입니다. ELT 와 ETL 은 둘 다 이 저장소를 채우는 방법입니다.

ETL 과 갈리는 순서

ETL 은 다듬는 일을 저장소 밖에서 먼저 끝냅니다. 변환을 맡은 서버가 원천에서 읽은 데이터를 고칩니다. 저장소에는 다 된 결과만 들어가고 원본은 남지 않습니다.

ELT 는 변환을 적재 뒤로 미룹니다. 읽어 온 데이터를 먼저 저장소의 원본 표에 넣습니다. 다듬는 일은 저장소가 스스로 돌리는 조회문이 맡습니다.

두 방식의 차이를 줄로 놓으면 아래와 같습니다.

두 방식을 가르는 것은 순서입니다. 변환을 적재 뒤로 미루면 변환이 저장소 안으로 들어옵니다. 나머지 줄은 전부 여기서 따라 나옵니다.

순서를 바꿀 수 있게 된 까닭

예전의 분석용 저장소는 계산 자원이 넉넉하지 않았습니다. 큰 데이터를 저장소 안에서 다듬으면 분석 조회까지 느려졌습니다. 그래서 다듬는 일을 따로 맡는 서버를 두는 ETL 이 흔했습니다.

요즘 분석용 저장소는 대개 데이터를 행이 아니라 열 단위로 모아 저장합니다. 분석 조회는 대개 열 몇 개만 읽으므로 디스크에서 읽는 양이 크게 줄어듭니다. 이런 저장 방식을 열 지향 저장소라고 합니다.

한 조회를 여러 대의 기계에 나눠 돌리기도 합니다. 데이터가 커지면 기계를 더 붙여 나눠 맡깁니다.

클라우드에서 도는 저장소는 계산할 기계를 필요할 때만 빌려 씁니다. 큰 변환을 돌릴 때는 그 변환에 쓸 기계를 따로 더 빌릴 수 있습니다. 그러면 변환과 분석 조회가 같은 기계를 두고 다투지 않습니다. 큰 변환을 저장소 안에서 돌려도 분석 조회가 덜 밀립니다.

저장 공간도 값이 싸졌습니다. 원본을 쌓아 두는 부담이 줄자 변환을 저장소에 맡기는 ELT 가 흔해졌습니다.

저장소 안에서 도는 변환

ELT 의 변환은 대개 SQL(Structured Query Language, 구조화 질의 언어) 조회문입니다. SQL 은 관계형 데이터베이스에 데이터를 묻고 고치는 언어입니다. 원본 표를 읽어 새 표를 만드는 조회문 하나가 변환 한 단계가 됩니다.

쇼핑몰 주문으로 한 단계를 따라가 봅니다. 적재가 끝난 원본 표 raw_orders 에는 원천에서 온 값이 글자로 들어 있습니다. 금액 열 amt 에는 '12000' 이라는 글자가 있습니다. 주문일 열 dt 에는 '2026-09-01' 이라는 글자가 있습니다.

아래 조회문은 이 원본 표를 읽어 분석용 표 orders 를 만듭니다. 오른쪽 주석은 첫 행이 바뀐 값입니다.

CREATE TABLE orders AS
SELECT id,
  CAST(amt AS INT) AS amt,  -- 12000
  CAST(dt AS DATE) AS day   -- 2026-09-01
FROM raw_orders;

금액은 글자에서 숫자가 됐습니다. 주문일은 글자에서 날짜가 됐습니다. 이제 날짜별로 금액을 더하는 조회가 바로 돌아갑니다. 원본 표 raw_orders 는 손대지 않은 채 남습니다.

변환은 대개 한 단계로 끝나지 않습니다. orders 를 읽어 날짜별 매출 표를 만듭니다. 그 표를 읽어 다시 월별 보고서 표를 만듭니다. 조회문 여럿을 정해진 때에 앞뒤 순서대로 돌려 주는 일은 워크플로우 오케스트레이션 도구가 맡습니다.

원본 레이어와 다듬은 레이어

ELT 로 채운 저장소에는 표가 레이어로 나뉘어 쌓입니다. 레이어는 같은 단계의 표를 한데 묶어 부르는 말입니다. 원본을 담는 레이어와 다듬은 결과를 담는 레이어를 따로 둡니다. 흔히 셋으로 나눕니다.

나누는 방법은 간단합니다. 표 이름 앞에 raw_ 같은 접두어를 붙입니다. 레이어마다 표를 담는 묶음을 따로 만들기도 합니다.

레이어를 나누면 어느 표가 원본이고 어느 표가 다듬은 것인지 이름만 보고 압니다. 분석하는 사람은 분석 레이어만 읽습니다. 원본 레이어는 변환을 다시 돌릴 때 쓰는 재료로 남겨 둡니다.

원본 레이어를 웨어하우스 대신 데이터 레이크에 두기도 합니다. 데이터 레이크는 원천에서 온 데이터를 파일로 쌓아 두는 저장소입니다. 표로 담기 어려운 로그나 이미지도 넣을 수 있습니다.

이때는 웨어하우스가 레이크의 파일을 읽어 정리 레이어를 만듭니다. 원본이 레이크에 있어도 변환은 웨어하우스 안에서 돕니다.

원본 레이어까지 웨어하우스에 둔 경우로 세 단계와 세 레이어를 한 그림에 놓으면 아래와 같습니다.

flowchart TD
    A["원천 시스템"] --> B["추출 · 적재"]
    subgraph W["데이터 웨어하우스"]
        C["원본 레이어"] -->|변환| D["정리 레이어"]
        D -->|변환| E["분석 레이어"]
    end
    B --> C

변환은 전부 웨어하우스 테두리 안에서 돕니다. 테두리 밖에서 하는 일은 꺼내 오고 넣는 것뿐입니다.

표의 모양을 정하는 때

표에 어떤 열이 있고 열마다 어떤 값이 들어가는지 정한 약속을 스키마라고 합니다. ETL 은 이 약속을 먼저 정해 두고 거기에 맞춰 넣습니다. 약속에 없는 값은 넣을 때 버려집니다.

ELT 의 원본 레이어는 원천이 준 모양을 따라가거나 앞의 raw_orders 처럼 글자로만 받아 둡니다. 쓸모에 맞는 모양은 변환할 때 정합니다. 읽거나 변환하는 때에 모양을 정하는 이 방식을 스키마 온 리드라고 합니다.

덕분에 원천에 열이 하나 늘어도 적재는 멈추지 않습니다. 새 열은 원본 레이어에 쌓입니다. 쓸 일이 생기면 그때 변환에 넣습니다.

원본을 남겨 두면 얻는 것

변환 규칙은 자주 바뀝니다. 매출에서 환불을 빼기로 합니다. 가입 경로를 나누는 기준이 바뀝니다. 그러면 지난 기간의 분석 표도 새 규칙으로 다시 만들어야 합니다.

ETL 이었다면 원천에서 지난 데이터를 다시 읽어야 합니다. 그런데 서비스용 데이터베이스는 대개 지금 상태만 들고 있습니다. 석 달 전의 회원 등급은 이미 덮어써져 되살릴 수 없습니다.

ELT 는 원본 레이어에 적재 때마다 읽은 데이터를 쌓아 둘 수 있습니다. 그렇게 쌓아 두었다면 새 규칙으로 변환 조회문만 다시 돌립니다. 지난 데이터를 다시 흘려 결과를 새로 만드는 이 일을 재처리라고 합니다.

재처리를 안심하고 하려면 다시 돌려도 결과가 겹치지 않아야 합니다. 같은 입력으로 여러 번 돌려도 한 번 돌린 것과 결과가 같은 성질을 멱등성이라고 합니다. 결과 표를 지우고 원본에서 처음부터 다시 만드는 변환은 몇 번을 돌려도 같은 표가 나옵니다.

원본이 커지면 결과 표를 매번 처음부터 만드는 데 오래 걸립니다. 그때는 지난번 이후 새로 들어온 원본 행만 변환해 결과 표에 더합니다. 이 방식을 증분 처리라고 합니다.

치르는 값

원본과 다듬은 결과를 둘 다 두므로 저장 공간이 더 듭니다. 변환 조회문도 저장소의 계산 자원을 씁니다. 클라우드 저장소는 대개 계산한 만큼 요금을 매깁니다. 변환이 무거우면 그만큼 요금이 늘어납니다.

민감한 값도 일단 저장소에 들어옵니다. 카드 번호나 주민등록번호가 원본 레이어에 쌓입니다. 그래서 누가 어떤 표를 읽을 수 있는지 정해 두는 접근 제어로 원본 레이어를 읽는 사람을 좁힙니다.

넣기 전에 그 열만 빼거나 알아볼 수 없게 가리기도 합니다. 값을 가리는 일을 데이터 마스킹이라고 합니다. 이만큼은 ETL 처럼 넣기 전에 손보는 셈입니다.

표가 레이어마다 늘어나면 어느 표가 어느 표에서 나왔는지 흐려집니다. 분석 표의 숫자가 이상할 때 원본까지 거슬러 오르려면 이 연결을 기록해 두어야 합니다. 이 연결 기록을 데이터 계보라고 합니다.

언제 안 쓰나

저장소에 들어가면 안 되는 값이 많으면 ETL 이 맞습니다. 넣기 전에 걸러 내는 편이 들어온 뒤에 막는 것보다 새는 길이 적습니다.

대상 저장소가 큰 변환을 감당하지 못하면 안 맞습니다. 서비스용 데이터베이스 하나로 분석까지 하는 작은 시스템이 그렇습니다. 변환 조회문이 서비스 조회를 밀어냅니다. 이럴 때는 변환을 저장소 밖에서 끝내는 ETL 이 맞습니다.

SQL 로 풀기 어려운 변환도 있습니다. 이미지에서 특징을 뽑는 일이 그렇습니다. 주문의 배송 주소를 좌표로 바꿔 주는 바깥 서비스에 물어 위도·경도를 붙이는 일도 그렇습니다. 이런 변환은 저장소 밖의 처리 서버가 맡습니다.

ELT 도 대개 모아 두었다가 정해진 때에 한 번에 돕니다. 이 방식을 배치 처리라고 합니다. 결과를 몇 초 안에 봐야 하는 일은 들어오는 대로 처리하는 스트림 처리가 받습니다.

관련 항목

ELT 가 데이터를 싣는 저장소

데이터 웨어하우스 · 데이터 레이크 · 레이크하우스 · 데이터 마트 · 스테이징 영역 · 객체 스토리지

ELT 가 속하는 상위 분류

데이터 엔지니어링 · 데이터 통합 · 데이터 파이프라인 · 파이프라인

ELT 가 거치는 처리 단계

추출 · 적재 · 변환 · 증분 처리 · 데이터 정제 · 재처리 · 백필

ELT 를 대신하거나 보태는 데이터 통합 방식

ETL · 역방향 ETL · 변경 데이터 캡처 · 데이터 복제 · 데이터 가상화

ELT 의 변환을 담는 데이터베이스 기능

SQL · 뷰 · 구체화 뷰 · 저장 프로시저

ELT 작업을 짜고 돌리는 도구

워크플로우 오케스트레이션 · dbt · Apache Airflow · Apache Spark · cron

ELT 를 받아 주는 분석용 저장소 제품

BigQuery · Amazon Redshift · ClickHouse · Databricks

ELT 를 흔하게 만든 기반 기술

클라우드 · 열 지향 저장소 · 분산 처리 · 대규모 병렬 처리

ELT 가 표의 모양을 정하는 방식

스키마 · 스키마 온 리드 · 스키마 온 라이트 · 스키마 진화

ELT 의 분석 레이어가 따르는 데이터 모델

데이터 모델링 · 차원 모델링 · 스타 스키마 · 메달리온 아키텍처

ELT 작업이 기대는 처리 방식

배치 처리 · 마이크로 배치 · 스트림 처리

ELT 작업이 지켜야 하는 성질

멱등성 · 데이터 품질 · 데이터 계보 · 데이터 신선도

ELT 의 원본 레이어를 지키는 보안 수단

접근 제어 · 데이터 마스킹 · 암호화 · 열 수준 보안

ELT 에서 자주 나는 장애

중복 적재 · 스키마 드리프트 · 늦게 도착한 데이터 · 데이터 누락