로우 레이어

받아 온 데이터를 바로 다듬어 저장하면 저장 공간이 줄고 표도 깔끔합니다. 문제는 다듬은 규칙이 틀렸다는 사실을 나중에 알았을 때 드러납니다. 되돌릴 원본이 없으면 틀린 값 위에서 계산을 이어 갈 수밖에 없습니다.

페이지덱에서 그 일이 있었습니다. 결제 대행사에서 받은 기록을 변환해 결제 표에만 넣어 두었는데, 환불 건의 금액이 음수로 오는 것을 양수로 바꿔 쌓고 있었습니다. 두 달 뒤 월 매출이 실제보다 높게 잡혀 있다는 것을 재무 쪽에서 발견했습니다. 고치려면 원본이 필요했는데 남아 있는 것은 변환된 값뿐이었고, 대행사의 보관 기간은 90일이라 그보다 앞선 두 달치는 되받을 수 없었습니다.

받은 것을 그대로 한 층에 쌓아 두면 이 사고는 계산을 다시 돌리는 일로 끝납니다. 변환 규칙은 코드에 있고 코드는 고칠 수 있지만, 원본은 한 번 버리면 다시 만들 수 없습니다.

받은 모습을 그대로 두는 것이 이 층의 규칙입니다. 다듬고 싶은 충동을 참는 자리라고 해도 됩니다.

1. 열 이름과 형식을 원천 그대로 둡니다. 대행사가 보낸 열 이름이 대문자와 밑줄이 섞여 있어도 바꾸지 않고, 날짜가 문자열로 와도 문자열로 저장합니다. 이름을 고치는 순간 원본과 대조할 수 없게 됩니다.
2. 덧붙이기만 합니다. 이미 들어온 행을 고치거나 지우지 않고 새로 받은 것을 아래에 쌓습니다. 같은 결제 건이 정정되어 다시 오면 두 행이 함께 남고, 어느 쪽이 맞는지는 다음 층에서 정합니다.
3. 행마다 받은 시각과 출처를 함께 적습니다. 어느 파일에서 왔는지, 언제 적재됐는지, 원천의 어느 시각 기준인지를 열로 붙여 둡니다. 나중에 특정 날짜의 적재만 다시 돌려야 할 때 이 값들이 있어야 골라낼 수 있습니다.
4. 이 층에서는 분석 질의를 돌리지 않습니다. 열 이름이 제각각이고 형식이 통일되지 않아 질의마다 해석을 다시 해야 하고, 그 해석이 사람마다 달라지면 같은 이름의 지표가 갈립니다.
5. 보관 기간을 길게 잡습니다. 대신 저장 비용을 낮추는 형태로 둡니다. 날짜별로 나눠 쌓고 압축해 두면 3년치를 쌓아도 부담이 크지 않습니다.
6. 접근 권한은 좁게 둡니다. 가공 전이라 개인정보가 원본 그대로 들어 있어서, 마스킹은 다음 층에서 하고 이 층은 데이터 담당자만 봅니다.

다음 층은 정제 중간 단계를 담는 스테이징 레이어입니다. 넘어가기 전에 갖춰야 하는 것이 여섯입니다.

1. 열 이름과 형식을 읽을 수 있게 정리합니다. 원천의 이름을 팀의 이름 규칙으로 옮기고, 문자열로 들어온 날짜와 금액을 날짜와 숫자로 바꿉니다.
2. 같은 것이 두 번 들어온 경우를 정하는 열을 고릅니다. 결제 건이라면 대행사가 준 거래 번호가 그 열이고, 그 번호가 같은 행이 둘이면 나중에 받은 것을 씁니다.
3. 시각 기준을 통일합니다. 원천마다 시간대가 다르고 이벤트가 일어난 시각과 우리가 받은 시각이 다릅니다. 둘 중 무엇을 기준으로 집계할지 정하고 그 규칙을 문서에 적습니다.
4. 행 수를 대조합니다. 원천이 보낸 건수와 적재된 건수가 맞는지 보고 어긋나면 그 날짜를 다시 적재합니다. 이 대조가 데이터 품질 점검의 첫 항목입니다.
5. 변환을 여러 번 돌려도 결과가 같게 만듭니다. 원본을 고치지 않고 새 표를 만드는 방식이면 같은 날짜를 두 번 처리해도 같은 결과가 나옵니다. 이 성질이 있어야 사고가 났을 때 마음 놓고 다시 돌립니다.
6. 변환 규칙을 코드로 관리합니다. 먼저 적재하고 창고 안에서 변환하는 순서를 ELT라고 부르는데, 이 순서가 성립하는 것 자체가 원본이 남아 있기 때문입니다.

여기까지 갖추면 그다음은 바로 분석에 쓸 수 있게 다듬은 마트 레이어입니다. 세 층을 나눠 두는 이유는 고칠 자리를 좁히기 위해서입니다. 숫자가 틀렸을 때 원본이 잘못 왔는지, 변환이 잘못됐는지, 마지막 집계가 잘못됐는지를 층으로 나눠 확인할 수 있습니다.

"원본이 남아 있으니 다시 돌리면 됩니다."

변환 규칙을 고친 뒤 과거 값을 재계산할 수 있다는 말입니다.

"그 열 이름은 원천 그대로 두세요. 여기서 고치면 대조가 안 됩니다."

이 층에서 손대지 않는다는 규칙을 짚는 것입니다.

"로우에서 바로 질의하지 말고 스테이징 거쳐 주세요."

정리되지 않은 층에서 지표를 만들면 사람마다 값이 달라진다는 뜻입니다.

태오가 결제 사고 뒤에 데이터 파이프라인을 세 층으로 다시 짰습니다. 대행사 응답을 받은 그대로 로우에 쌓고, 스테이징에서 환불을 음수로 두는 규칙을 코드에 적고, 마트에서 월 매출을 집계했습니다. 석 달 뒤 세금 계산 방식이 바뀌어 규칙을 한 번 더 고쳐야 했는데, 이번에는 코드 한 줄을 고치고 지난 18개월을 다시 돌리는 데 40분이 걸렸습니다. 원본이 남아 있는지가 사고의 크기를 정한다는 것이 그 두 사건의 차이였습니다.

원본을 그대로 쌓아 두는 것이 저장 공간 낭비라고 읽는 경우가 가장 많습니다. 같은 내용이 층마다 반복되니 그렇게 보입니다. 하지만 저장은 싸고 다시 받는 일은 비싸거나 아예 불가능합니다. 대행사의 보관 기간이 90일이면 그 뒤로는 돈을 내도 받을 수 없고, 사용자가 남긴 행동 기록은 지나간 시각을 다시 만들 방법이 없습니다. 날짜별로 나눠 쌓고 압축해 두면 3년치 비용이 담당자 한 사람의 한 달 인건비에 못 미치는 경우가 흔합니다.

이 층이 있으면 데이터가 맞다고 여기는 것도 흔합니다. 원본이 있으니 근거가 확실해 보입니다. 실제로 이 층이 보장하는 것은 되돌릴 수 있다는 것뿐입니다. 대행사가 처음부터 틀린 값을 보냈다면 로우 레이어에는 틀린 값이 그대로 남습니다. 원천이 보낸 건수와 우리가 받은 건수를 대조하는 점검이 따로 필요한 이유이고, 이 층의 값어치는 옳음이 아니라 다시 계산할 수 있다는 데 있습니다.