ETL 뜻과 데이터 웨어하우스, 레이크 차이

🤔 매주 같은 파일을 다시 만들고 있을 때

월요일 오전마다 구글 광고에서 CSV를 내려받고, 메타 광고에서 한 번 더 내려받고, GA4에서 세션과 전환을 뽑아 시트 한 장에 붙여 넣다 보면 오전이 그대로 지나갑니다. 다음 주에도 같은 순서로 같은 파일을 다시 만들고, 누군가 열 하나를 옮겨 두면 수식이 어긋나 숫자가 달라집니다.

이 과정을 추출, 변환, 적재로 나누어 부르는 말이 ETL입니다. 아래 중복된 두 파일을 세 주문으로 정리하기에서 프로그램 설치 없이 구분해 봅니다.

🔑 ETL의 정의

ETL은 흩어진 곳에서 데이터를 꺼내고(Extract) 쓸 수 있는 모양으로 바꾸고(Transform) 모아 두는 곳에 넣는(Load) 세 단계를 가리키는 말입니다.

기술 용어처럼 들리지만 마케터가 손으로 하던 일에 붙은 이름입니다. 광고 계정에서 성과를 내려받는 것이 꺼내기이고, 날짜 형식과 캠페인 이름을 맞추는 것이 바꾸기이고, 정리한 값을 시트에 붙여 넣는 것이 넣기입니다. 손으로 수행하더라도 추출, 변환, 적재라는 과정으로 설명할 수 있습니다.

자료를 이동하고 처리하는 연결된 과정을 데이터 파이프라인이라고 부릅니다. ETL은 그 한 방식이며 일정 실행, 오류 처리와 결과 확인도 함께 설계합니다.

🥛 ETL 세 단계, 목장 우유가 창고에 들어가기까지

집유차가 아침마다 목장을 돌며 탱크에 우유를 받아 오듯, 파이프라인도 광고 계정과 GA4와 쇼핑몰 관리자 화면을 돌며 어제치 숫자를 받아 옵니다. 받아 온 우유를 그대로 팔지 않고 이물질을 거른 뒤 살균해 같은 크기 용기에 담듯, 받아 온 데이터도 날짜 형식을 맞추고 통화를 환산해 같은 표 모양으로 만듭니다.

규격을 맞춘 것만 제품 창고에 줄 맞춰 쌓아 두고, 주문이 들어오면 그 창고에서 꺼냅니다. 데이터도 같은 순서로 움직여서, 정리를 마친 표만 모아 두는 곳이 따로 있고 리포트와 대시보드는 그곳에서 값을 꺼내 씁니다.

이 비유에서 눈여겨볼 곳은 우유를 거르고 살균하는 공정입니다. 무엇을 거르고 남길지는 미리 정한 규칙에 따라 달라집니다. 원본을 가져올 수 없는 상황이나 저장 실패도 별도로 확인해야 합니다.

📥 세 단계에서 실제로 하는 일

변환 규칙은 날짜, 통화와 캠페인 표기처럼 업무의 약속을 반영합니다. 약속이 바뀌면 규칙도 검토합니다. 추출 단계의 인증이나 API 변경, 적재 단계의 표 구조 변경도 실패 원인이 될 수 있습니다. API는 프로그램이 다른 시스템에 자료를 요청하는 연결 방식입니다.

캠페인 이름을 0901_신상_리타겟처럼 적기로 했다가 누군가 신상리타겟0901로 적으면, 이름에서 날짜와 상품군을 잘라 내던 규칙이 그 행에서만 빈값을 내놓습니다. 규칙은 멀쩡한데 들어온 값이 약속과 달라 생긴 문제입니다.

본문의 ETL 예시입니다. 원본 보관과 변환 규칙을 함께 관리해야 결과를 다시 확인할 수 있습니다.

🔄 ETL과 ELT의 차이

같은 세 글자를 순서만 바꿔 ELT라고 적는 경우가 늘었습니다. 차이는 하나로, 바꾸는 시점이 넣기 앞이냐 뒤냐입니다.

• ETL: 꺼낸 값을 먼저 정리한 뒤 정리된 것만 넣습니다. 쌓이는 양이 줄고 들어가는 표가 깔끔하지만, 원본을 별도로 보관하지 않았다면 다른 변환이 필요할 때 다시 가져와야 합니다
• ELT: 꺼낸 값을 일단 원본 그대로 넣어 두고, 필요할 때 그 안에서 바꿉니다. 원본이 남아 있어 나중에 다른 질문을 던지기 쉬운 대신 쌓이는 양이 커집니다

두 방식 모두 원본 보관과 접근 권한, 변환 비용을 설계해야 합니다. 자료를 얼마나 보관하고 어디서 변환할지에 따라 선택합니다.

🏗️ 데이터 웨어하우스, 레이크, 마트 비교

데이터가 모이는 곳에는 이름이 셋 있습니다. 우유 비유로 옮기면 레이크는 걷어 온 그대로 받아 둔 집유 탱크이고, 웨어하우스는 규격에 맞춰 담아 쌓아 둔 제품 창고이고, 마트는 오늘 나갈 것만 골라 담아 둔 출고대입니다.

각 도구의 요금과 기능 한도는 시점마다 달라져서 이 글에서는 이름만 적어 둡니다. 실제로 고를 때는 그날의 공식 요금 문서를 확인하는 편이 맞습니다.

세 용어는 저장과 활용 목적을 설명합니다. 모두를 순서대로 갖춰야 하는 것은 아닙니다. 데이터 마트는 특정 업무에 필요한 자료를 모은 것으로, 웨어하우스에서 만들 수도 있고 다른 원본에서 직접 구성할 수도 있습니다. 작은 업무는 한 저장소 안에 원본 표와 정리한 표를 구분하는 것부터 시작할 수 있습니다.

🧭 마케터가 데이터 쌓이는 곳을 알아야 하는 이유

데이터를 직접 다루지 않아도 이 구조를 알아 두면 세 가지가 달라집니다.

• 틀린 숫자의 원인을 좁힐 수 있습니다: 리포트 값이 이상하면 원본이 안 들어왔는지, 정리 규칙이 어긋났는지, 요약 표만 오래됐는지를 나눠 물어볼 수 있습니다
• 새 지표를 요청할 때 필요한 것을 말할 수 있습니다: 원본에 그 값이 없으면 리포트에도 생기지 않으므로, 요청은 화면이 아니라 수집 단계부터 시작해야 합니다
• 자동화를 맡길 때 범위를 정할 수 있습니다: 꺼내기만 맡길지, 정리 규칙까지 맡길지에 따라 걸리는 기간과 이후 관리 방법이 달라집니다

KPI를 정해 두고도 매주 값이 달라진다면 수집과 변환 이력, 집계 기준을 함께 대조합니다. GA4 데이터를 BigQuery로 내보내 정리한 사례는 GA4 데이터 유실, BigQuery로 자동 해결에 적어 두었습니다.

⏱️ 손으로 하던 정리를 자동화로 넘기는 시점

모든 반복 작업을 자동화할 필요는 없습니다. 아래 상황에서 반복에 드는 시간과 오류의 영향, 자동화 유지 비용을 비교해 봅니다.

• 매주 몇 시간이 넘게 들 때: 한 달이면 하루치 업무가 그 정리에만 들어갑니다
• 사람마다 다른 파일이 생길 때: 같은 이름의 지표가 두 파일에서 다른 값으로 나오면 회의가 숫자 맞추기로 끝납니다
• 같은 실수가 반복될 때: 붙여 넣는 순서를 한 번 틀려 생긴 오류가 분기마다 다시 나온다면 사람 문제가 아니라 절차 문제입니다

넘길 때도 처음부터 크게 만들지 않는 편이 낫습니다. 가장 자주 하는 정리 하나만 골라 자동으로 돌려 보고, 원본과 행 수 및 합계를 여러 번 대조하고 실패 후 재실행도 확인한 뒤 다음 작업을 추가합니다. 열 가지를 한 번에 옮기면 어느 부분이 틀렸는지 찾는 데 더 오래 걸립니다.

⚠️ 파이프라인이 자주 깨지는 세 곳

• 소스 쪽 열 이름이 바뀔 때: 광고 플랫폼이 보고서 열 이름을 바꾸거나 항목을 하나 더하면, 그 이름을 그대로 찾던 규칙이 빈값을 돌려줍니다. 열 이름을 코드 안에 흩어 두지 않고 한곳에 모아 두면 고칠 곳이 한 군데로 줄어듭니다
• 기간이 겹쳐 중복으로 들어갈 때: 같은 자료를 단순 추가하면 매출이 중복될 수 있습니다. 주문번호 같은 고유 기준으로 같은 기록을 구분하고, 재실행해도 결과가 같도록 갱신합니다. 기간 전체를 교체한다면 새 자료 검증과 실패 시 복구 방법을 갖춘 뒤 적용합니다
• 실패했는데 아무도 모를 때: 가장 위험한 경우입니다. 어제 작업이 멈췄는데 화면에는 그제까지 숫자가 그대로 떠 있으면 값이 줄어든 것으로 보고 판단을 내리게 됩니다. 마지막 성공 시각과 처리 건수를 남기고 실패하거나 자료가 오래되면 알 수 있도록 합니다.

❓ 자주 묻는 질문

ETL과 데이터 파이프라인은 같은 말인가요?

데이터 파이프라인이 더 넓은 말입니다. ETL은 추출 후 변환하고 적재하는 방식이며, 파이프라인은 다른 처리 순서나 실시간 전달도 포함할 수 있습니다.

데이터 웨어하우스 없이 구글 시트만 써도 되나요?

자료 크기뿐 아니라 수식 복잡도와 갱신 주기, 접근 권한에 따라 판단합니다. 작은 자료를 수동으로 확인하는 일은 시트부터 시작할 수 있습니다. 파일이 느려지거나 지표가 서로 다르면 먼저 수식과 집계 기준을 확인합니다. 그 문제를 고쳐도 필요한 크기와 갱신 주기를 감당하지 못할 때 다른 저장소를 검토합니다.

마케터가 직접 ETL을 만들 수 있나요?

간단한 것은 코드 없이도 만듭니다. 광고 플랫폼이 제공하는 시트 연동 부가기능이나 예약 내보내기로 꺼내기와 넣기를 걸어 두고, 바꾸기만 시트 함수로 처리하는 방식이 흔합니다. 소스가 늘고 정리 규칙이 복잡해지면 그때 개발 담당과 범위를 나눕니다.

GA4를 BigQuery로 내보내면 바로 분석되나요?

GA4의 BigQuery 내보내기에서는 이벤트가 행으로 저장되고 매개변수나 상품 목록은 한 행 안의 반복 필드에 들어갈 수 있습니다. 반복 필드는 여러 값을 담는 구조입니다. 이를 펼치면 행이 늘 수 있으므로 주문이나 세션을 집계할 때 중복을 확인해야 합니다. 저장된 자료를 보고 목적에 맞게 정리하는 단계가 별도로 필요합니다.

✏️ 중복된 두 파일을 세 주문으로 정리하기

종이나 메모장에 아래 두 자료를 적습니다. 모두 같은 상점의 가상 주문이고 금액은 원입니다.

1. 추출: 두 파일의 네 행을 원본 영역에 그대로 둡니다.
2. 변환: 복사본에서 날짜를 2026-10-01처럼 통일합니다. 날짜 표기를 맞춘 뒤 주문번호, 날짜와 금액이 모두 같은 O2는 한 건만 남깁니다.
3. 적재: 새 보고용 표에 O1, O2, O3 세 행을 적습니다.

결과는 3건, 합계 60,000원입니다. 80,000원이면 O2를 두 번 더했는지 확인합니다. 이 예제의 중복 기준은 날짜가 아니라 주문번호입니다.

혼자 반복하려면 같은 원본을 다시 읽었다고 가정합니다. 기존 표에 네 행을 무조건 추가하지 않고 주문번호로 대조하면 결과는 여전히 3건, 60,000원입니다. 같은 번호인데 날짜나 금액이 다르면 자동 삭제하지 말고 변경된 주문인지 원본에서 확인할 항목으로 남깁니다. 실제 업무에서는 주문 한 건이 상품별 여러 행일 수도 있으므로 표의 한 행이 무엇을 뜻하는지도 먼저 정합니다.

📋 3줄 요약

1. ETL은 흩어진 곳에서 데이터를 꺼내고(Extract) 쓸 수 있는 모양으로 바꾸고(Transform) 모아 두는 곳에 넣는(Load) 세 단계를 가리키는 말입니다.

2. ETL은 변환 후 적재하고 ELT는 적재 후 변환하며, 두 방식 모두 원본 보관과 처리 결과 확인을 설계해야 합니다.

3. 저장소 종류를 모두 갖추기보다 자료의 목적과 크기에 맞춰 선택하고 재실행 때 중복이 생기지 않는지 확인합니다.

📚 참고 자료

• AWS: ETL의 단계
• AWS: 데이터 웨어하우스, 레이크와 마트의 차이
• Google: GA4 BigQuery 내보내기 구조