데이터 파이프라인

이 말이 붙기 전에도 데이터를 옮기는 일은 있었습니다. 다만 그 일을 사람이 손으로 했습니다. 월요일 회의에 쓸 숫자가 필요하면 결제 시스템 관리 화면에서 지난주 결제 내역을 파일로 내려받고, 서버를 맡은 사람에게 접속 기록을 뽑아 달라고 부탁하고, 고객 문의 도구에서 문의 목록을 따로 받아 스프레드시트 한 장에 붙였습니다.

페이지덱도 첫해에는 이렇게 했습니다. 지현이 금요일 오후를 통째로 여기에 썼습니다. 세 파일에서 사용자를 가리키는 칸의 이름과 형식이 제각각이라 셋을 같은 사람으로 이어 붙이는 데만 한 시간이 넘게 걸렸습니다. 결제 쪽은 계정 번호로, 접속 기록은 내부 식별자로, 문의 쪽은 이메일로 사람을 가리키고 있었기 때문입니다.

걸린 시간보다 큰 문제가 셋 있었습니다. 첫째, 같은 숫자를 다시 만들 수 없었습니다. 회의에서 "지난달도 같은 기준으로 보여 주세요" 라는 말이 나오면 지현은 지난달에 자기가 어떤 줄을 지우고 무엇을 무엇에 붙였는지 기억에 의존해야 했습니다. 둘째, 사람이 바뀌면 값이 바뀌었습니다. 다른 사람이 같은 자료로 같은 지표를 뽑아도 환불 건을 빼느냐 마느냐 같은 판단이 갈려 결과가 몇 퍼센트씩 어긋났습니다. 셋째, 그 일을 하던 사람이 휴가를 가면 그 주에는 숫자가 아예 없었습니다.

데이터 파이프라인은 이 손작업을 코드로 한 번 적어 두고 기계가 정해진 시각에 대신 돌리게 만든 것입니다. 어디서 무엇을 가져와, 어떤 규칙으로 형태를 맞추고, 어디에 넣을지를 적어 두면 매일 새벽 네 시에 같은 절차가 같은 순서로 실행됩니다. 그렇게 옮겨진 데이터가 쌓이는 곳이 분석용 데이터 저장소입니다. 사람은 결과를 쓰기만 하다가 실행이 실패한 날에만 들여다봅니다. 판단이 코드에 적혀 있으니 지난달 기준이 무엇이었는지도 기억이 아니라 기록에서 확인합니다.

이 말 아래 묶인 용어는 네 갈래입니다. 데이터를 다듬는 일을 옮기기 전에 하느냐 옮긴 뒤에 하느냐가 방식이고, 그 흐름이 얼마나 자주 도느냐가 주기입니다. 잘게 쪼개진 작업을 무엇이 순서대로 돌리느냐가 도구이고, 돌다가 어긋난 구간을 어떻게 되돌리느냐가 운영입니다.

방식은 변환을 어느 자리에서 하느냐로 갈리는 갈래입니다. 변환은 원천에서 가져온 데이터의 모양을 쓸 수 있게 바꾸는 일을 말합니다. 날짜 표기를 하나로 맞추고, 달러로 들어온 결제를 원화로 환산하고, 내부 테스트 계정을 걸러 내는 작업이 전부 여기 들어갑니다. 갈래는 둘입니다.

1. ETL — 원천에서 꺼내고, 중간에서 바꾸고, 저장소에 넣습니다. 저장소에는 이미 정리된 데이터만 들어가므로 보관 용량과 계산 비용이 적게 듭니다. 대신 반년 뒤에 "그때 걸러 낸 테스트 계정도 한번 세어 보자" 는 요구가 오면 걸러 낸 것은 남아 있지 않아 원천에서 다시 가져와야 합니다.
2. ELT — 순서를 바꿔, 원천의 데이터를 거의 손대지 않은 채로 먼저 저장소에 넣고 그 안에서 바꿉니다. 원본이 그대로 남아 있으니 기준이 바뀌어도 저장소 안에서 다시 계산하면 됩니다. 저장소의 계산 값이 충분히 싸지고 빨라진 뒤에 널리 퍼진 방식입니다.

둘 중 무엇을 고를지는 저장소의 계산 값과 기준이 바뀔 가능성이 정합니다. 기준이 웬만해서는 바뀌지 않고 원천 데이터가 크면 미리 줄여서 넣는 쪽이 낫고, 무엇을 셀지 아직 흔들리는 단계라면 원본을 남겨 두는 쪽이 낫습니다. 초기 팀은 대개 뒤쪽에서 시작합니다. 첫해에 지표 정의가 바뀌는 횟수가 원천 데이터가 늘어나는 속도보다 빠르기 때문입니다.

주기는 이 흐름이 얼마나 자주 도느냐를 가르는 갈래입니다. 둘 중 무엇을 고를지는 그 숫자가 몇 분 늦어도 되느냐가 정합니다.

1. 배치 처리 — 정해진 주기에 그동안 쌓인 것을 한꺼번에 처리합니다. 매일 새벽 세 시에 전날 하루치를 모아 돌리는 식입니다. 만들기 쉽고, 실패해도 아침에 한 번 더 돌리면 되므로 지표 대부분이 여기서 나옵니다.
2. 스트림 처리 — 데이터가 들어오는 즉시 흘려보내며 처리합니다. 결제가 승인된 지 몇 초 안에 화면의 숫자가 올라가야 하는 자리에 씁니다. 대신 한 건씩 계속 도는 흐름이라 어제 오후 두 시부터 세 시까지만 다시 돌리는 식의 부분 재처리가 배치보다 까다롭습니다.

대부분의 팀은 배치로 시작해서, 몇 초 안에 알아야 하는 자리가 생겼을 때 그 부분만 스트림으로 떼어 냅니다. 처음부터 전부 스트림으로 짜면 만드는 값과 고치는 값이 몇 배로 뜁니다.

도구는 이 흐름을 실제로 돌리는 갈래입니다. 워크플로 오케스트레이터는 작업 여러 개를 순서와 의존 관계에 맞춰 실행해 주는 도구입니다. 파이프라인은 대개 한 덩어리가 아니라 작은 작업 수십 개로 쪼개져 있고 그 사이에는 선후가 있습니다. 결제 내역을 가져오는 작업이 끝나야 결제와 사용자를 잇는 작업이 돌 수 있고, 그게 끝나야 매출 표가 만들어집니다. 오케스트레이터는 이 관계를 지도처럼 들고 있다가 앞 작업이 실패하면 뒤 작업을 아예 시작하지 않고 담당자에게 알립니다. 이 장치가 없으면 앞이 실패한 줄 모른 채 뒤가 그대로 돌아 절반만 채워진 표를 만들어 놓습니다.

운영은 이미 돌고 있는 파이프라인을 손보는 갈래이고, 여기 속한 두 용어는 짝입니다. 백필은 과거 구간을 다시 처리해 채워 넣는 작업입니다. 파이프라인이 사흘 동안 조용히 실패했거나, 새 지표를 만들면서 지난 1년치도 같은 기준으로 계산해야 할 때 돌립니다. 재실행 안전성은 같은 구간을 두 번 돌려도 결과가 어긋나지 않는 성질입니다. 이 성질이 없으면 백필 자체가 사고가 됩니다. 5월 1일치를 다시 돌렸을 때 그날 매출이 기존 값 위에 더해져 두 배로 잡히는 식입니다. 그래서 파이프라인은 대개 해당 구간의 결과를 지우고 새로 쓰는 방식으로 짜 둡니다. 그러면 몇 번을 돌리든 그 구간의 값은 하나입니다.

네 갈래는 한 줄로 이어집니다. 방식과 주기를 고르면 파이프라인의 모양이 정해지고, 그 모양을 도구가 돌리고, 돌기 시작하면 실패와 재처리가 따라옵니다. 그리고 이 흐름 전체가 결국 지키려는 것은 데이터 품질입니다. 중간의 한 단계가 조용히 어긋나면 그 위에서 돌린 계산이 전부 조금씩 틀어지기 때문에, 파이프라인을 만드는 일의 절반은 데이터를 옮기는 코드가 아니라 옮겨진 결과가 이상할 때 사람이 알아차리게 만드는 장치입니다.

"그 숫자 파이프라인이 어제 실패해서 오늘 대시보드는 하루 밀려 있어요."

화면의 값이 틀린 것이 아니라 어제까지만 채워져 있다는 뜻입니다. 계산식을 뜯어볼 일이 아니라 실행을 다시 돌리면 풀리는 상황입니다.

"지표 정의를 바꾸면 백필까지 해야 해서 이틀은 봐야 합니다."

새 기준을 앞으로만 적용하면 그래프가 바뀐 날을 기점으로 꺾여 보이니 과거 구간도 같은 기준으로 다시 계산하겠다는 말입니다.

"그건 파이프라인에 안 들어와 있는 데이터라 지금은 못 봅니다."

원천에는 값이 남아 있지만 저장소로 옮겨 오는 흐름이 아직 없다는 뜻입니다. 분석 요청이 아니라 개발 요청에 가깝습니다.

페이지덱에서 이 말이 가장 시끄러웠던 때는 지현이 유료 전환율을 요일별로 보고 싶다고 요청했을 때입니다. 한 시간이면 될 줄 알았던 일이 태오가 데이터를 열어 보면서 멈췄습니다. 가입 시각 칸에 사용자가 실제로 가입한 시각이 아니라 파이프라인이 그 줄을 처리한 시각이 들어 있었습니다. 새벽 네 시에 하루치를 모아 돌렸으니 여덟 달치 가입이 전부 새벽 네 시로 찍혀 있었고, 요일별로 나눠 봐도 의미가 없었습니다.

원천인 서비스 데이터베이스에는 제대로 된 시각이 남아 있었으므로 고칠 수는 있었습니다. 다만 파이프라인을 고친 뒤 지난 여덟 달을 다시 돌려야 했고, 그때의 파이프라인은 다시 돌리면 같은 결제 건이 두 번 쌓이는 상태였습니다. 그래서 순서가 뒤집혔습니다. 먼저 재실행에 안전하도록 처리 방식을 고쳐 쓰고, 그다음에 백필을 돌렸습니다. 한 줄짜리 요청이 일주일이 된 이유는 요청이 어려워서가 아니라 처음 파이프라인을 짤 때 시각을 어느 것으로 남길지 정하지 않아서였습니다.

파이프라인을 한 번 만들어 두면 끝나는 설치물로 여기는 경우가 가장 많습니다. 돌기 시작하면 아무 소리도 나지 않으니 완성된 것처럼 보입니다. 하지만 파이프라인이 기대는 원천은 계속 바뀝니다. 결제 시스템이 응답 칸 이름을 바꾸고, 새 기능이 붙으면서 기록 형식이 하나 늘고, 예전에 없던 빈 값이 섞여 들어옵니다. 이런 변화의 대부분은 실행을 멈추지 않고 결과만 조금 비틀어 놓습니다. 그래서 파이프라인에는 옮긴 줄 수가 평소의 절반 아래로 떨어지면 알려 주는 식의 검사를 함께 붙여 둡니다. 요란하게 실패하는 파이프라인은 그날 고치지만, 반쯤 맞는 값을 조용히 만들어 내는 파이프라인은 분기 회의에서 발견됩니다. 그리고 그때는 이미 그 값으로 내린 결정이 몇 건 쌓여 있습니다.

대시보드 숫자가 이상할 때 계산식부터 의심하는 것도 흔한 오해입니다. 눈에 보이는 것이 계산식뿐이니 자연스러운 반응입니다. 실제로는 원인이 대개 그보다 앞 단계에 있습니다. 확인하는 순서는 원천에 값이 남아 있는지, 파이프라인이 어제 성공했는지, 지표 정의가 최근에 바뀌지 않았는지를 보고 나서야 계산식입니다. 순서를 거꾸로 잡으면 멀쩡한 계산식을 사흘 동안 뜯어보다가 파이프라인이 지난 주말부터 실패해 있었다는 사실을 마지막에 알게 됩니다.