배치 처리

데이터를 쓰는 일은 오래도록 사람 손에 달려 있었습니다. 아침마다 누군가 결제 시스템에서 어제 내역을 내려받고, 가입자 명부를 따로 뽑고, 두 파일을 엑셀에서 맞붙여 매출 표를 만들었습니다. 30분이면 끝나는 일이라 처음에는 아무도 문제라고 여기지 않았습니다.

문제는 그 30분이 매일 돌아온다는 데 있었습니다. 담당자가 휴가를 가면 그 주 숫자가 비었고, 붙이는 순서를 헷갈리면 중복된 행이 섞여 매출이 실제보다 높게 잡혔습니다. 회의에서 "이 숫자 맞아요?" 가 나오면 파일을 다시 열어 처음부터 맞춰 봐야 했습니다.

여기서 눈에 띈 건 그 30분의 내용이 매일 똑같다는 사실이었습니다. 가져오는 곳도 같고 붙이는 순서도 같고 걸러 내는 조건도 같습니다. 다른 것은 날짜뿐입니다. 그렇다면 같은 절차를 글로 적어 두고 정해진 시각에 기계가 대신 돌리게 하면 됩니다. 배치 처리는 그 발상을 이름으로 굳힌 것입니다.

주기를 정하고, 그 주기에 처리할 구간을 정하고, 구간을 처리하는 작업을 순서대로 엮은 다음, 실행 시각을 걸어 두는 순서로 만듭니다. 다섯 단계로 나누면 이렇습니다.

1. 주기를 정합니다. 매일 한 번인지 한 시간에 한 번인지를 정하는 일인데, 기준은 데이터가 얼마나 자주 바뀌느냐가 아니라 그 숫자를 보는 사람이 얼마나 늦게 받아도 되느냐입니다. 매일 아침 회의에서 쓰는 매출 표라면 하루 한 번으로 충분합니다.
2. 처리할 구간을 정합니다. 새벽 세 시에 도는 작업이라면 전날 0시부터 24시까지입니다. 구간을 시각으로 못 박아야 어제 것을 두 번 세거나 자정 직전 건을 빠뜨리지 않습니다.
3. 원천에서 그 구간의 데이터를 꺼내 저장소에 넣습니다. 원천은 결제 시스템이나 서비스 데이터베이스처럼 데이터가 처음 만들어지는 곳이고, 저장소는 분석용으로 따로 둔 데이터 웨어하우스입니다. 운영 중인 서비스에서 직접 계산하지 않고 옮겨 오는 이유는, 무거운 집계 질의가 실제 사용자가 쓰는 화면을 느리게 만들기 때문입니다.
4. 저장소 안에서 돌릴 작업을 순서대로 엮습니다. 결제 내역을 사용자와 잇는 작업이 끝나야 매출 표를 만들 수 있는 식으로 선후가 있으므로, 이 관계를 들고 있다가 앞이 실패하면 뒤를 멈추는 워크플로 오케스트레이터에 맡깁니다.
5. 실행 시각을 겁니다. 매일 새벽 세 시처럼 고정된 시각이면 크론 잡으로 충분하고, 원천 파일이 올라온 뒤에 돌아야 한다면 그 사건을 신호로 삼습니다.

여기에 하나를 더 붙여 둡니다. 같은 구간을 두 번 돌려도 결과가 어긋나지 않는 재실행 안전성입니다. 배치는 실패하기 마련이고, 실패하면 그 구간을 다시 돌리게 됩니다. 5월 1일치를 두 번 돌렸을 때 그날 매출이 두 배로 잡히는 구조라면 고치는 일이 사고를 부릅니다. 지난 구간을 다시 처리해 채워 넣는 백필도 이 성질 위에서만 안전합니다.

맞는 자리는 숫자가 몇 시간 늦어도 아무도 곤란하지 않은 곳입니다. 어제 매출, 주간 활성 사용자 수, 월말 정산, 이탈 위험이 높은 고객 명단 같은 것들이고 회의에서 쓰는 지표는 대부분 여기 들어갑니다. 아침 열 시 회의에 어제 숫자가 올라와 있으면 되지, 그게 새벽 세 시에 계산됐는지 여섯 시에 계산됐는지는 아무도 묻지 않습니다.

구조가 단순하다는 점도 큽니다. 처리 구간이 닫혀 있으니 결과를 검산하기 쉽고, 틀리면 그 구간만 다시 돌리면 됩니다.

한계는 세 가지 모양으로 나타납니다.

1. 신선도의 천장이 주기와 같습니다. 하루 한 번 도는 흐름에서 가장 오래된 숫자는 24시간 전 것입니다. 결제가 승인된 지 몇 초 안에 화면의 숫자가 올라가야 하는 자리에는 쓸 수 없습니다.
2. 실패가 통째로 옵니다. 한 건씩 처리하는 흐름에서 한 건이 실패하면 한 건만 비지만, 배치는 중간에 멈추면 그날치 전부가 비어 있거나 절반만 채워진 상태로 남습니다. 그래서 실패 알림과 다시 돌리는 절차가 반드시 붙습니다.
3. 일이 한 시각에 몰립니다. 새벽 세 시부터 네 시까지만 저장소가 뜨겁게 돌고 나머지 시간은 놉니다. 팀 전체가 같은 시각에 작업을 걸어 두면 서로 밀려 완료가 아침을 넘깁니다.

그래서 대부분의 팀은 배치로 시작합니다. 몇 초 안에 알아야 하는 자리가 생겼을 때 그 부분만 스트림 처리로 떼어 내고, 나머지는 그대로 둡니다.

"이 숫자 배치로 도는 거라 오늘 오전 건은 아직 안 잡혀 있어요."

지금 화면에 보이는 값이 어제까지의 집계라는 뜻입니다.

"새벽 배치가 실패해서 대시보드가 어제에 멈춰 있습니다. 다시 돌리고 있어요."

정해진 시각의 작업이 중간에 죽었고, 같은 구간을 재실행 중이라는 보고입니다.

"그거 굳이 실시간으로 안 가도 되지 않아요? 하루 한 번 배치면 충분할 것 같은데요."

요구사항을 낮춰 만드는 값과 운영 부담을 줄이자는 제안입니다.

페이지덱에서는 지현이 아침 회의 전에 보는 지표 대부분이 새벽 세 시 배치에서 나옵니다. 어느 날 회의에서 전날 가입자 수가 0으로 찍혀 있었고, 확인해 보니 결제 시스템 점검 때문에 데이터를 꺼내는 첫 단계가 실패해 뒤 작업이 전부 멈춘 상태였습니다. 태오가 점검이 끝난 뒤 같은 구간을 다시 돌려 오전 중에 숫자를 채웠습니다.

그 뒤로 실패하면 알림이 오게 했고, 대시보드 상단에 마지막으로 계산된 시각을 적어 두었습니다. 숫자가 비어 있는 것보다 낡은 숫자를 새것으로 착각하는 쪽이 위험하다고 봤기 때문입니다.

배치가 실시간보다 뒤떨어진 옛 방식이라는 오해가 가장 흔합니다. 기술 소개 글이 대개 실시간 처리를 앞세우니 그런 인상이 생깁니다. 실제로는 둘 중 무엇을 쓸지가 기술 수준이 아니라 요구사항으로 갈립니다. 월말 정산처럼 하루가 닫혀야 계산이 되는 일은 실시간으로 만들 수가 없습니다. 이 오해를 그대로 두면 하루 한 번이면 될 흐름을 몇 배의 값을 들여 짜고, 장애가 났을 때 어제 구간만 다시 돌리는 간단한 복구조차 어려워집니다.

배치를 밤에만 도는 것으로 아는 경우도 있습니다. 새벽 예시가 많아서 생기는 인상인데, 주기는 하루 한 번일 수도 5분에 한 번일 수도 있습니다. 모아서 한 번에 처리하느냐가 갈림길이지 시각이 갈림길은 아닙니다.