스테이징 레이어

저장소를 처음 만들면 층을 나눌 이유가 보이지 않습니다. 원본을 쌓아 두고 필요할 때 거기서 바로 계산하면 되고, 표가 셋일 때는 그 편이 빠릅니다.

페이지덱에서 그 방식이 어디까지 갔는지가 남아 있습니다. 월 매출을 세는 질의 하나가 200줄이 됐습니다. 그 안에서 날짜 표기를 하나로 맞추고, 사내 테스트 계정을 걸러 내고, 결제가 두 번 기록된 줄을 하나로 합치는 일을 매번 했습니다.

문제는 그 정제를 쓰는 질의가 그 하나가 아니었다는 점입니다. 요금제별 매출, 주간 보고, 이탈 계정 목록까지 여섯 개가 같은 걸러 내기를 각자 안에 품고 있었습니다.

테스트 계정이 세 개 늘어난 날 여섯 곳을 고쳐야 했고 태오가 두 곳을 놓쳤습니다. 그 주 회의에 월 매출이 두 개 들어왔습니다. 같은 데이터에서 나온 숫자인데 걸러 낸 계정이 달랐습니다.

정제를 한 번만 하고 그 결과를 표로 남겨 모두가 그 표에서 시작하게 만든 자리가 이 층입니다.

원본을 건드리지 않은 채 정제만 적용해 둔 중간 결과가 여기 놓입니다. 원천의 표 하나가 이 층의 표 하나에 대응하고, 줄 수와 칸 구성이 대체로 원본과 같습니다. 달라진 것은 값이 깨끗해졌다는 점뿐입니다.

이 층에서 하는 일은 다섯 가지입니다.

1. 형식을 맞춥니다. 어떤 원천은 날짜를 2026-01-05 로 보내고 다른 원천은 01/05/2026 으로 보냅니다. 통화도 마찬가지여서, 달러로 들어온 결제를 원화로 환산해 한 칸에 모읍니다.
2. 이름을 맞춥니다. 같은 값이 원천마다 user_id, account_no, uid 로 들어옵니다. 이 층에서 하나로 정해 두면 뒤에서 표를 붙일 때 어느 칸이 어느 칸인지 확인하지 않아도 됩니다.
3. 걸러 냅니다. 사내 테스트 계정, 취소된 뒤 남아 있는 줄, 금액 칸이 빈 줄을 제외합니다. 무엇을 뺐는지는 규칙으로 적어 두고 그 규칙만 고칩니다.
4. 중복을 지웁니다. 수집이 두 번 돌아 같은 기록이 두 벌 들어오는 일이 실제로 생기므로, 한 사건이 한 줄이 되도록 키를 정해 합칩니다.
5. 타입을 정합니다. 숫자로 써야 할 칸이 글자로 들어와 있으면 여기서 바꿉니다. 뒤에서 더하는 쪽이 매번 변환하지 않게 하려는 것입니다.

하지 않는 일도 분명합니다. 여러 표를 붙여 한 줄로 만드는 일과 집계는 이 층 밖입니다. 그건 바로 분석에 쓰도록 다듬은 마트 레이어의 몫이고, 여기서 미리 붙여 두면 원천 하나가 바뀔 때 어느 표까지 다시 만들어야 하는지가 흐려집니다.

이 층의 성질 하나가 운영을 편하게 만듭니다. 여기 있는 표는 언제든 원본에서 다시 만들 수 있습니다. 손대지 않은 원본을 담아 두는 로우 레이어가 아래에 남아 있기 때문입니다. 그래서 정제 규칙이 틀렸다는 것을 반년 뒤에 알아도 이 층을 지우고 새 규칙으로 다시 만들면 됩니다.

정제를 어디에 적는지도 정해져 있습니다. 원본을 먼저 저장소에 넣고 그 안에서 다듬는 ELT 방식에서는 이 층의 표가 곧 질의 문장 하나입니다. 무엇을 어떻게 정제했는지가 SQL로 남으므로 사람에게 묻지 않고 읽어 확인할 수 있습니다.

마트 레이어로 넘어가는 기준은 이 층의 값이 믿을 만해졌는지입니다. 네 가지를 확인합니다.

1. 검사를 통과합니다. 키가 겹치지 않는지, 필수 칸이 비어 있지 않은지, 값이 있을 수 있는 범위 안인지를 자동으로 확인합니다. 결제 금액이 음수인 줄이 하나 있으면 그 줄이 마트에서 합계를 깎습니다.
2. 칸 이름과 타입이 확정됩니다. 칸 이름을 나중에 바꾸면 그것을 참조하는 마트 표가 한꺼번에 깨지므로, 이름을 정하는 결정은 여기서 끝냅니다.
3. 한 줄의 뜻이 하나입니다. 같은 표에 결제와 환불이 섞여 있고 금액 부호로만 구분된다면, 마트에서 그 표를 그대로 세면 환불이 매출로 잡힙니다. 뜻이 다른 사건은 표를 나눕니다.
4. 무엇을 걸러 냈는지 적어 둡니다. 이 문서가 없으면 반년 뒤에 마트의 숫자가 원본보다 3퍼센트 적은 이유를 아무도 설명하지 못합니다.

넘어가지 말아야 할 때도 있습니다. 원천 쪽 구조가 아직 흔들리는 중이면 이 층에서 버티고 마트를 미룹니다. 원천이 칸을 하나 더 보낼 때 이 층만 고치면 되는 상태와 마트 표 다섯 개를 함께 고쳐야 하는 상태의 차이가 큽니다.

"그 걸러 내기는 스테이징에서 하죠. 지금 질의 여섯 개에 같은 조건이 들어 있어요."

정제를 한 곳으로 모으자는 제안입니다.

"스테이징에서 집계까지 해 두면 안 됩니다. 층이 섞여요."

이 층의 역할 범위를 지키자는 지적입니다.

"이거 원본에서 다시 만들면 되니까 지워도 됩니다."

이 층이 재생산 가능한 층이라는 사실을 확인하는 말입니다.

페이지덱에서는 태오가 원천마다 이 층의 표를 하나씩 둡니다. 이름 규칙도 정해 두어 표 이름 앞에 stg 를 붙이는데, 보는 사람이 이 표가 최종이 아니라는 것을 이름만으로 알게 하려는 것입니다.

지현은 이 층을 직접 쓰지 않고, 마트의 숫자가 이상할 때만 한 단계 내려와 여기를 봅니다. 두 층을 나눠 둔 덕에 문제가 정제 규칙 쪽인지 집계 쪽인지가 한 번에 갈리고, 데이터 파이프라인 전체를 뒤지지 않아도 됩니다.

임시로 쓰고 버리는 자리라고 여기는 경우가 많습니다. 중간 단계라는 말이 붙어 있으니 그렇게 읽힙니다. 하지만 이 층의 표는 계속 유지되고 매일 다시 만들어집니다. 버릴 수 있다는 성질과 버려도 된다는 말은 다릅니다. 마트 표가 이 층을 재료로 삼기 때문에 지우면 그 위가 함께 멈춥니다.

여기서 집계까지 해 두면 나중이 편하다고 보는 것도 흔합니다. 어차피 다듬는 층이니 한 발 더 나가고 싶어집니다. 그런데 집계까지 들어오면 이 층의 표가 원천 한 개에 대응하지 않게 되고, 그 순간 원천이 바뀔 때 무엇을 다시 만들어야 하는지 추적이 어려워집니다. 결국 층을 나눈 이유가 사라져서, 같은 계산이 여러 표에 흩어지고 회의에 숫자가 두 개 들어오는 상태로 돌아갑니다.