데이터 검증

데이터가 틀렸다는 사실은 대개 가장 늦게, 가장 나쁜 자리에서 드러납니다. 숫자는 항상 나오기 때문입니다. 빈 칸이 섞여 있어도 평균은 계산되고, 같은 사용자가 두 줄로 들어가 있어도 합계는 떨어집니다. 화면에 뜬 값이 틀렸다고 알려 주는 장치가 없으면 틀린 값도 맞은 값과 똑같이 생겼습니다.

페이지덱에서 실제로 이런 일이 있었습니다. 월간 보고 자리에서 규원이 지난달 유료 전환율이 두 배로 뛴 것을 보고 무엇이 달라졌는지 물었고, 지현은 그 자리에서 답하지 못했습니다. 사흘을 거슬러 올라가 찾아낸 원인은 결제 기록을 옮기는 데이터 파이프라인이 열흘 전부터 일부 줄을 두 번씩 넣고 있었다는 것이었습니다. 알아차리기까지 열흘 동안 아무 경고도 뜨지 않았고, 그사이 세 번의 회의에서 그 숫자가 근거로 쓰였습니다.

데이터 검증은 이 열흘을 없애려고 두는 장치입니다. 사람이 이상한 숫자를 알아보는 데 기대지 않고, 값이 갖춰야 할 조건을 미리 글로 적어 둔 다음 데이터가 들어올 때마다 기계가 대조하게 만듭니다. 조건에 어긋나는 줄이 나오면 그 자리에서 멈추거나 알립니다.

검증은 규칙을 적고, 그것을 데이터가 지나는 길목에 걸고, 걸린 줄을 처리하는 세 덩어리로 돌아갑니다. 실제 작업은 다섯 단계입니다.

1. 검증할 표와 칸을 고릅니다. 모든 표에 거는 것은 관리가 안 되므로, 대시보드와 정산에 쓰이는 표부터 시작합니다. 데이터 계보가 그려져 있으면 뒤쪽에 영향이 큰 표부터 고를 수 있습니다.
2. 칸마다 조건을 적습니다. 조건은 네 종류로 나뉩니다. 형식은 이메일 칸에 골뱅이가 있는지 같은 모양 조건이고, 범위는 결제 금액이 0보다 큰지 같은 값 조건입니다. 허용 목록은 요금제 칸에 무료·팀·기업 말고 다른 값이 들어오지 않는지 보는 조건이고, 유일성은 같은 주문 번호가 두 줄에 나오지 않는지 보는 조건입니다.
3. 돌 자리를 정합니다. 데이터가 들어오는 입구에서 막을지, 저장한 뒤에 훑을지 고릅니다. 입구에서 막으면 나쁜 값이 아예 안 들어오지만 그 줄이 통째로 버려집니다. 저장한 뒤 훑으면 원본은 남지만 이미 그 값으로 계산이 한 번 돈 뒤입니다.
4. 어긋난 줄을 어떻게 할지 정합니다. 선택지는 셋입니다. 통과시키고 알림만 보내기, 그 줄만 빼고 나머지를 진행하기, 전체를 멈추기입니다. 결제 금액이 음수인 줄은 멈출 일이고, 국가 칸이 비어 있는 줄은 빼고 가도 되는 일입니다. 같은 규칙이라도 표마다 판단이 다릅니다.
5. 걸린 줄을 볼 사람을 정합니다. 알림이 가는 곳과 그것을 받는 사람이 정해져 있지 않으면 한 달 안에 알림을 끕니다. 데이터 거버넌스에서 표마다 주인을 적어 두는 이유가 여기서 드러납니다.

규칙은 한 번 적고 끝나지 않습니다. 요금제에 새 이름이 추가되면 허용 목록을 같이 고쳐야 하고, 고치지 않으면 멀쩡한 값이 매일 어긋난 줄로 걸립니다. 헛경보가 몇 주 쌓이면 진짜 경보도 같이 무시됩니다.

이 방법이 잘 듣는 곳은 값이 갖춰야 할 조건을 사람이 미리 말로 적을 수 있는 자리입니다. 결제 금액은 음수일 수 없고, 가입일은 오늘보다 뒤일 수 없고, 상태 칸에 들어갈 값은 정해진 다섯 개뿐입니다. 이런 조건은 한 줄씩 적어 두면 판정이 항상 같게 나옵니다.

반대로 조건을 적을 수 없는 고장에는 듣지 않습니다. 세 가지가 대표적입니다. 첫째, 규칙은 다 지켰는데 값 자체가 틀린 경우입니다. 실수로 단위를 원에서 센트로 바꿔 보내면 모든 줄이 형식과 범위를 통과하면서 금액만 100배가 됩니다. 둘째, 줄이 통째로 안 들어온 경우입니다. 들어온 줄만 보므로 안 들어온 줄은 볼 방법이 없고, 그건 완결성이 맡습니다. 셋째, 값은 멀쩡한데 시점이 늦은 경우입니다. 어제 데이터가 그대로 있어도 규칙은 전부 통과하고, 그건 신선도가 맡습니다.

평소와 다른 값을 잡아내는 이상 탐지와도 역할이 갈립니다. 검증은 사람이 정한 선을 넘었는지 보고, 이상 탐지는 평소 분포에서 벗어났는지 봅니다. 앞의 단위 실수 같은 것은 검증이 놓치고 이상 탐지가 잡습니다.

규칙을 촘촘하게 거는 쪽으로만 밀고 가면 비용이 먼저 듭니다. 칸마다 조건을 다섯 개씩 걸어 두면 매일 걸리는 줄이 수백 건이 되고, 그중 실제로 고칠 것은 몇 건입니다. 처음에는 틀리면 결정이 바뀌는 칸에만 걸고, 사고가 한 번 날 때마다 그 유형의 규칙을 늘리는 쪽이 유지됩니다.

"이 표 검증 규칙에 국가 칸이 빠져 있어서 지난주부터 빈 값이 그냥 들어오고 있었어요."

규칙을 적어 두지 않은 칸이라 아무도 모르고 지나갔다는 뜻입니다.

"검증에서 어제 1,200건 걸렸는데 대부분 새 요금제 이름이에요. 허용 목록 업데이트해 주세요."

데이터가 아니라 규칙이 낡아서 생긴 헛경보라는 말입니다.

"결제 금액 음수는 통과시키지 말고 파이프라인을 멈추게 해 두죠."

이 조건은 알림만으로는 부족하니 뒤쪽 계산 자체를 막자는 제안입니다.

페이지덱에서는 앞의 중복 사고 이후에 태오와 지현이 규칙을 같이 적었습니다. 태오가 먼저 형식과 유일성 조건을 걸어 두자 첫 주에 400건이 걸렸는데, 그중 380건은 테스트 계정이 남긴 줄이었습니다. 테스트 계정을 검증 대상에서 빼고 나니 남은 20건이 실제로 봐야 할 줄이었고, 그 20건에서 결제 실패를 두 번 기록하는 버그가 드러났습니다.

검증을 한 번 걸어 두면 데이터를 믿을 수 있게 된다고 보는 경우가 많습니다. 통과라는 판정이 나오니 그렇게 읽힙니다. 하지만 통과는 적어 둔 조건을 어기지 않았다는 뜻일 뿐이고, 적어 두지 않은 것에 대해서는 아무 말도 하지 않습니다. 단위가 바뀐 금액도, 어제부터 안 들어오는 줄도 전부 통과로 나옵니다. 이 점을 놓치면 검증을 깔아 둔 것만 믿고 다른 점검을 걸지 않게 되고, 정작 사고는 규칙 바깥에서 납니다.

검증을 데이터 담당자만의 일로 보는 것도 자주 나옵니다. 규칙은 데이터 쪽에서 걸지만 조건을 아는 사람은 그 값을 만든 쪽입니다. 요금제 이름이 몇 개인지는 제품과 개발 쪽이 압니다. 이 대화가 없으면 데이터 쪽이 짐작으로 조건을 적게 되고, 제품이 바뀔 때마다 규칙이 어긋나 헛경보가 쌓입니다.