ETL

숫자를 하나 보려면 데이터가 한곳에 모여 있어야 하는데 실제로는 늘 흩어져 있습니다. 결제 기록은 결제 대행사 쪽에, 가입과 사용 기록은 서비스 데이터베이스에, 광고비는 광고 플랫폼에 있습니다. 모양도 제각각입니다. 한쪽은 날짜를 2026-09-16으로 적고 다른 쪽은 09/16/26으로 적습니다. 결제는 달러로 들어오는데 보고는 원화로 하고, 사내 테스트 계정이 사용자 목록에 섞여 있습니다.

그래서 초기에는 사람이 그 일을 했습니다. 지현이 "지난달 유료 전환율" 을 알고 싶어 하면 세 군데에서 파일을 내려받아 날짜를 맞추고 테스트 계정을 지운 다음 숫자를 냈습니다. 반나절이 걸렸고 다음 달에 같은 질문이 오면 처음부터 다시 했습니다. 더 곤란한 건 두 사람이 각자 맞춘 숫자가 달랐다는 점입니다. 누가 어떤 계정을 걸렀는지에 따라 전환율이 3.8퍼센트가 되기도 4.1퍼센트가 되기도 했습니다.

ETL은 이 손작업을 코드로 굳힌 것입니다. 매번 사람이 정하던 규칙을 한 번 적어 두고 기계가 같은 순서로 반복하게 만듭니다. 변환이 저장소에 넣기 전에 오는 데는 이유가 있습니다. 이 방식이 자리 잡던 시절에는 분석용 저장소의 보관 값과 계산 값이 비쌌습니다. 쓰지도 않을 데이터를 통째로 넣는 것이 낭비였으니 밖에서 줄여 필요한 만큼만 넣었습니다.

이름의 세 글자가 그대로 순서이고, 실무에서는 뒤에 두 단계가 더 붙습니다.

1. 추출(Extract)입니다. 원천에서 데이터를 꺼냅니다. 결제 대행사는 API로 주고, 서비스 데이터베이스는 복제본을 읽게 해 주고, 광고 플랫폼은 파일로 내려받게 합니다. 매번 전부 가져오면 값이 커지니 대개 지난번 이후 바뀐 것만 가져옵니다.
2. 변환(Transform)입니다. 저장소 바깥의 작업 서버에서 모양을 맞춥니다. 날짜 표기를 하나로 통일하고, 달러 결제를 그날 환율로 원화로 바꾸고, 사내 테스트 계정을 걸러 내고, 결제 기록과 사용자 기록을 같은 키로 이어 붙입니다. 개인 식별 정보처럼 저장소에 들이면 안 되는 값을 가리는 것도 이 단계입니다.
3. 적재(Load)입니다. 다듬은 결과를 데이터 웨어하우스에 넣습니다. 웨어하우스는 분석용 데이터를 정리된 구조로 모아 둔 저장소입니다. 넣는 방식은 대개 해당 날짜 구간을 지우고 새로 쓰는 쪽인데, 그래야 재실행 안전성이 생겨 같은 날을 두 번 돌려도 매출이 두 배로 잡히지 않습니다.
4. 돌리기입니다. 세 단계는 작은 작업 수십 개로 쪼개져 있고 그 사이에 선후가 있습니다. 워크플로 오케스트레이터가 그 순서를 들고 있다가 앞이 실패하면 뒤를 시작하지 않습니다. 주기는 보통 배치 처리로 새벽 세 시에 전날치를 돌립니다.
5. 확인입니다. 돌린 뒤 행 수와 합계가 원천과 맞는지 비교하고 어긋나면 담당자에게 알립니다. 조용히 실패한 구간이 나중에 발견되면 백필로 그 기간을 다시 처리해 채웁니다.

원천 데이터가 크고 그중 실제로 쓰는 부분이 작을 때 가장 잘 맞습니다. 하루에 서버 기록이 4억 줄씩 쌓이는데 분석에 쓰는 건 결제와 관련된 200만 줄뿐이라면, 밖에서 줄여 넣는 쪽이 저장소 값을 아낍니다. 저장소에 들이는 것 자체가 문제가 되는 값이 섞여 있을 때도 이 순서라야 합니다. 들어간 뒤에 지우는 것과 애초에 안 들어가는 것은 규제 앞에서 다른 이야기입니다.

한계는 네 가지입니다.

1. 버린 것은 되살릴 수 없습니다. 반년 뒤에 "그때 걸러 낸 테스트 계정도 한번 세어 보자" 는 요구가 오면 저장소에는 없고 원천에서 다시 가져와야 합니다. 원천이 90일치만 보관하는 곳이면 그마저 안 됩니다.
2. 기준이 바뀔 때마다 값이 큽니다. 환율 적용 방식을 바꾸면 코드를 고치고 지난 구간 전체를 다시 돌려야 합니다.
3. 변환할 자리를 따로 둬야 합니다. 저장소 바깥에 작업 서버가 필요하고 데이터가 늘면 그 서버도 키워야 합니다.
4. 새 지표 하나를 만드는 시간이 깁니다. 파이프라인을 고치고 백필까지 마쳐야 숫자가 나옵니다.

그래서 무엇을 셀지 아직 흔들리는 초기 팀은 대개 ELT로 시작합니다. 첫해에는 지표 정의가 바뀌는 횟수가 데이터가 늘어나는 속도보다 빠릅니다.

"그 컬럼은 ETL 단계에서 걸러져서 창고에 없어요. 원천에서 다시 받아야 합니다."

변환 때 버린 값이라 저장소를 뒤져 봐야 안 나온다는 뜻입니다.

"환율 기준을 바꾸면 변환 코드만 고쳐서 끝나는 게 아니라 지난 1년치를 다시 돌려야 해요."

기준 변경이 과거 데이터 전체의 재처리로 번진다는 말입니다.

"새벽 파이프라인이 세 시에 끝나니까 아침 대시보드는 전날까지만 맞아요."

주기가 하루라 오늘 숫자는 내일 나온다는 안내입니다.

페이지덱에서는 태오가 이 흐름을 만들고 지현이 그 결과로 대시보드를 봅니다. 유료 전환율의 정의를 "가입 후 30일 안에 결제" 에서 "14일 안에 결제" 로 바꾸기로 한 날, 지현은 숫자가 바로 바뀔 줄 알았습니다. 실제로는 변환 코드를 고치고 지난 1년 구간을 백필하는 데 이틀이 걸렸습니다. 기준을 바꾸는 값이 ELT보다 비싼 대목이 여기입니다.

ELT가 나온 뒤로 이쪽은 낡은 방식이라고 여기는 경우가 많습니다. 새 방식이 뒤에 나왔으니 그렇게 읽히지만 둘은 세대가 아니라 선택지입니다. 저장소의 계산 값이 싸진 것이 ELT를 밀어 준 것은 맞습니다. 그래도 개인정보를 저장소에 들이면 안 되거나, 원천이 하루 수억 줄인데 쓰는 건 극히 일부이거나, 계산 값을 한 푼이라도 줄여야 하는 자리에서는 여전히 이쪽입니다. 한 회사가 둘을 자리에 따라 섞어 쓰기도 합니다.

데이터를 옮기는 일이 전부라고 생각하는 것도 흔한 오해입니다. 하지만 파이프라인을 만드는 시간의 절반쯤은 옮기는 코드가 아니라 결과가 이상할 때 사람이 알아차리게 만드는 장치에 들어갑니다. 중간의 한 단계가 조용히 어긋나면 그 위에서 돌린 계산이 전부 조금씩 틀어지고, 아무도 모르는 채로 회의에 올라갑니다. 데이터 품질을 지키는 장치를 빼고 만든 파이프라인은 돌아가는 동안에는 멀쩡해 보이다가 틀린 숫자를 몇 달치 쌓아 둡니다.