ELT

회사가 쓰는 데이터는 처음부터 분석하기 좋은 모양으로 있지 않습니다. 결제 기록은 결제 데이터베이스에, 화면을 누른 기록은 이벤트 로그에, 광고 성과는 광고 플랫폼 쪽에 따로 있고 날짜 표기도 통화 단위도 제각각입니다. 이것들을 한자리에 모아 같은 기준으로 맞추는 일이 필요했습니다.

예전에는 그 작업을 옮기는 도중에 했습니다. 원천에서 꺼내고, 중간 서버에서 정리하고, 정리된 것만 데이터 웨어하우스에 넣는 순서입니다. 데이터 웨어하우스는 분석용 데이터를 정리된 구조로 모아 둔 저장소인데, 당시에는 이 저장소의 용량과 계산이 비싸서 이미 다듬어진 데이터만 넣는 편이 합리적이었습니다.

문제는 나중에 생깁니다. 페이지덱에서 반년쯤 지나 지현이 "내부 테스트 계정까지 포함한 가입 수도 한번 보자" 고 했을 때, 저장소에는 테스트 계정이 이미 걸러진 뒤의 숫자만 있었습니다. 걸러 낸 것은 어디에도 남아 있지 않아서 답을 하려면 원천에서 1년치를 다시 가져와야 했고, 그 작업만 사흘이 걸렸습니다.

저장소의 값이 싸지고 빨라지면서 순서를 뒤집을 여지가 생겼습니다. 일단 원본에 가까운 상태로 다 넣어 두고 다듬는 일은 저장소 안에서 하자는 것이 ELT입니다. 기준이 바뀌면 원천을 다시 건드리지 않고 저장소 안에서 다시 계산하면 됩니다.

세 단계이고 이름이 곧 순서입니다.

1. 추출 — 원천에서 데이터를 꺼냅니다. 결제 데이터베이스, 앱 이벤트 로그, 광고 플랫폼이 제공하는 조회 창구가 대표적인 원천입니다. 이 단계에서는 값을 고치지 않고 있는 그대로 읽어 냅니다.
2. 적재 — 꺼낸 것을 저장소에 그대로 넣습니다. 보통 원본만 두는 영역을 따로 만들어 두고 거기에 쌓습니다. 컬럼 이름도 원천이 쓰던 그대로 둡니다. 나중에 원천의 어떤 값이 어떻게 들어왔는지 되짚을 수 있게 하려는 것입니다.
3. 변환 — 저장소 안에서 SQL로 다듬습니다. SQL 은 저장된 데이터를 조건에 맞게 꺼내고 계산하는 표준 언어입니다.

변환은 대개 한 번에 끝내지 않고 층을 쌓습니다.

1. 원본 층 — 적재된 그대로입니다. 여기는 아무도 고치지 않습니다.
2. 정제 층 — 날짜 표기를 하나로 맞추고, 달러 결제를 원화로 환산하고, 테스트 계정에 표시를 답니다. 지우지 않고 표시만 다는 것이 요령입니다. 지우면 처음의 문제로 돌아갑니다.
3. 지표 층 — 실제로 화면에 나가는 표를 만듭니다. 월별 매출, 채널별 가입자처럼 지표 정의가 정한 기준을 그대로 옮겨 놓은 자리입니다.

돌리는 방식은 두 가지를 정해야 합니다. 얼마나 자주 도는지와, 매번 전체를 다시 가져올지 늘어난 만큼만 가져올지입니다. 결제 기록이 3억 건이면 매일 전체를 다시 넣을 수 없으니 어제 이후에 생긴 것만 가져오게 짭니다. 대신 원천에서 과거 기록이 수정되는 경우가 있으면 그 수정을 놓치게 되므로, 주에 한 번쯤은 최근 한 달치를 통째로 다시 계산해 덮어씁니다.

무엇을 셀지가 아직 흔들리는 팀에 맞습니다. 창업 첫해에는 가입자를 어느 시점 기준으로 셀지, 휴면 계정을 뺄지 같은 질문이 계속 바뀝니다. 원본이 저장소에 남아 있으면 기준이 바뀔 때마다 쿼리 한 벌을 다시 돌리면 끝나지만, 원본이 없으면 그때마다 원천에서 다시 가져오는 일이 붙습니다.

원천이 여러 개일 때도 유리합니다. 원천마다 중간 변환 코드를 따로 만드는 대신 가져오는 부분만 만들고 다듬는 일은 저장소 안에서 같은 언어로 처리합니다. 분석하는 사람이 직접 변환을 고칠 수 있다는 점도 큽니다. 중간 서버의 코드를 고치려면 엔지니어가 필요하지만 저장소 안의 쿼리는 분석 쪽에서 바로 손댑니다.

한계는 셋입니다.

1. 값이 듭니다. 쓰지 않을 데이터까지 전부 넣고 변환을 저장소 안에서 돌리므로 보관료와 계산료가 함께 늘어납니다. 원천이 아주 크고 그중 쓰는 부분이 일부뿐이면 미리 줄여서 넣는 쪽이 쌉니다.
2. 개인 정보가 그대로 들어갑니다. 개인 식별 정보는 이름이나 전화번호처럼 개인을 특정할 수 있는 데이터인데, 원본을 그대로 적재하면 이것들이 저장소에 쌓입니다. 적재 단계에서 가려 넣거나 저장소 안에서 접근 권한을 나눠 두는 장치가 따로 필요합니다.
3. 저장소에 묶입니다. 변환 로직이 그 저장소의 언어와 기능 위에 얹히므로 나중에 저장소를 바꾸면 변환도 함께 옮겨야 합니다.

"이건 ELT 라 원본이 남아 있어요. 기준 바꿔서 다시 뽑아 드릴게요."

원천을 다시 건드릴 필요 없이 저장소 안에서 재계산하면 된다는 뜻입니다.

"로그는 일단 다 넣고 변환은 나중에 합시다."

적재를 먼저 하고 다듬는 일을 뒤로 미루자는 ELT 방식의 제안입니다.

"이번 달 저장소 요금이 두 배예요. 안 쓰는 원천부터 적재를 끄죠."

전부 넣는 방식의 대가가 요금으로 나타났다는 말입니다.

페이지덱에서는 태오가 원천별 적재 작업을 만들어 두고, 지현이 지표 층의 쿼리를 직접 고칩니다. 지현이 "가입 완료 기준을 이메일 인증까지로 바꾸자" 고 하면 태오를 거치지 않고 정제 층 쿼리 한 줄을 고쳐 지난 1년치를 다시 계산합니다. 과거 구간을 다시 돌려 채워 넣는 이 작업을 백필이라고 부릅니다.

ELT 가 ETL의 다음 세대라서 언제나 낫다고 읽는 경우가 많습니다. 나중에 나왔고 요즘 도구가 이쪽을 밀어 주니 그렇게 보입니다. 하지만 둘을 가르는 건 시기가 아니라 저장소의 계산 값과 기준이 바뀔 가능성입니다. 기준이 굳어 있고 원천이 수십 테라바이트인 곳에서 전부 적재하면 요금이 몇 배로 뜁니다. 유행을 따라 옮겼다가 첫 달 청구서를 보고 되돌리는 일이 실제로 생깁니다.

원본을 넣어 두었으니 다듬는 일을 안 해도 된다고 읽는 것도 흔합니다. 적재가 끝나면 데이터가 저장소에 있으니 이미 쓸 수 있는 것처럼 보이기 때문입니다. 실제로는 변환이 사라진 게 아니라 자리를 옮겼을 뿐이고, 정제 층 없이 원본에 바로 쿼리를 붙이면 사람마다 테스트 계정을 다르게 걸러 같은 지표에 서로 다른 숫자가 나옵니다. 데이터 품질은 어느 순서를 쓰든 따로 지켜야 하는 것입니다.