데이터 품질

데이터를 모아 두기만 하면 답이 나온다고 여기던 시기가 있었습니다. 흩어진 원천에서 값을 끌어와 형태를 맞춰 옮기는 데이터 파이프라인을 깔고, 그것을 담아 둘 분석용 데이터 저장소를 마련하면 남은 일은 꺼내 보는 것뿐인 줄 알았습니다.

실제로 자주 벌어진 일은 이랬습니다. 월요일 지표 회의에서 대시보드에 찍힌 지난주 신규 가입이 1,240명인데, 영업이 따로 세어 온 숫자는 1,190명이었습니다. 어느 쪽이 맞느냐를 두고 20분을 쓰고도 결론이 안 났고, 사흘이 지나서야 토요일 새벽에 연동 작업 하나가 실패해 그날 가입 50건이 통째로 빠졌다는 것이 드러났습니다.

이 일의 성가신 점은 숫자가 비어 있지 않았다는 데 있습니다. 화면은 1,240이라는 값을 아무 표시 없이 보여 줬고, 그 값을 본 사람은 온전한 숫자라고 여길 수밖에 없었습니다. 줄이 빠져 있으면 덜 세고, 같은 사용자가 두 줄로 들어와 있으면 두 번 세고, 금액 칸이 비어 있으면 0으로 셉니다. 계산은 언제나 성공하고 결과도 언제나 나옵니다. 틀렸다는 신호만 안 나옵니다.

빠진 50건 자체는 큰 손해가 아닙니다. 값이 새는 동안 아무 표시도 없었다는 사실이 비용입니다. 그 주에는 가입이 줄었다는 말이 회의록에 남았고, 광고 예산을 조금 줄이자는 이야기가 따라 나왔습니다. 사흘 뒤에 원인이 밝혀졌지만 그동안 오간 판단을 되돌려 다시 하지는 않았습니다. 틀린 숫자는 고치면 되지만 그 숫자를 보고 한 결정은 그대로 남습니다.

한 번 이런 일을 겪은 조직은 회의에서 숫자부터 의심하기 시작합니다. 의심이 습관이 되면 대시보드를 만들어 둔 보람이 없어집니다. 볼 때마다 따로 확인해야 하는 숫자는 없는 숫자와 크게 다르지 않습니다.

데이터 품질은 그 확인을 사람이 그때그때 하는 대신, 값이 믿을 만한 상태로 있는지를 계속 지켜보는 일로 떼어 낸 것입니다. 틀린 값을 찾아내는 데서 그치지 않고, 무엇을 틀렸다고 부를지 미리 적어 두고 어긋나면 알림이 오게 만들어 두는 쪽에 무게가 있습니다.

데이터 품질 아래 묶인 용어는 세 갈래입니다. 값 자체가 쓸 만한지를 재는 갈래(점검), 그 값이 어디서 와서 어디에 있는지를 따라가는 갈래(추적), 누가 무엇을 어디까지 쓸 수 있는지를 정해 두는 갈래(관리)입니다.

점검은 값을 재는 갈래이고 세 자리가 있습니다.

1. 데이터 검증 — 값이 미리 정한 규칙에 맞는지 확인합니다. 이메일 칸에 골뱅이가 들어 있는지, 결제 금액이 음수가 아닌지, 요금제 칸에 정해 둔 세 값 말고 다른 것이 섞이지 않았는지 같은 조건을 적어 두고 매일 돌립니다. 어긋난 줄은 통과시키지 않고 따로 모아 사람이 봅니다.
2. 신선도 — 지금 보고 있는 값이 언제까지 반영된 것인지를 잽니다. 매시간 갱신하기로 한 표가 아홉 시간째 그대로라면 화면의 숫자는 틀린 게 아니라 늦은 것이고, 어제 상태로 오늘 결정을 내리게 됩니다. 이 자리에서 정하는 것은 표마다 몇 시간까지 늦어도 괜찮은지입니다.
3. 완결성 — 있어야 할 줄과 칸이 실제로 채워져 있는지를 봅니다. 하루 평균 3,000줄이 들어오던 표에 어제만 1,900줄이 들어왔다면 무언가 빠진 것이고, 결제 국가 칸이 지난주부터 12퍼센트 비어 있다면 그 칸으로 나눈 계산이 전부 같이 어긋납니다.

셋은 서로 다른 방향의 고장을 잡습니다. 검증은 값이 이상한 경우를, 신선도는 값이 늦는 경우를, 완결성은 값이 모자란 경우를 봅니다. 하나만 걸어 두면 나머지 두 방향은 그대로 열려 있습니다. 규칙은 다 통과했는데 하루치가 통째로 안 들어온 표가 대표적인 예입니다.

추적은 값의 출처와 위치를 다루는 갈래이고 두 자리가 있습니다.

1. 데이터 계보 — 이 값이 어느 원천에서 나와 어떤 가공을 거쳐 지금 화면까지 왔는지의 경로입니다. 대시보드의 매출이 이상할 때 이 경로가 적혀 있으면 어느 단계에서 틀어졌는지 거슬러 갈 수 있고, 반대로 원천 하나를 고칠 때 그 값을 쓰는 표와 화면이 몇 개인지도 미리 셀 수 있습니다.
2. 데이터 카탈로그 — 회사 안에 어떤 데이터가 어디에 있고 각 칸이 무엇을 뜻하는지 정리해 둔 목록입니다. 이름이 비슷한 표가 넷 있을 때 어느 것을 써야 하는지 매번 만든 사람에게 물어보지 않으려고 둡니다. 물어볼 사람이 회사를 떠나면 그 표는 아무도 못 쓰는 표가 됩니다. 목록에 적히는 것은 표 이름만이 아니라 각 칸의 뜻과 주인, 마지막으로 갱신된 때입니다. 활성 계정이라고 적힌 칸이 접속 기준인지 문서 생성 기준인지가 여기 적혀 있지 않으면 같은 이름의 칸 둘을 서로 다른 뜻으로 쓰는 일이 생깁니다.

관리는 쓰는 규칙을 정하는 갈래이고 세 자리가 있습니다.

1. 데이터 거버넌스 — 어떤 데이터를 누가 책임지고 누구까지 열어 줄지, 얼마나 오래 두고 언제 지울지를 정해 둔 체계입니다. 표마다 주인을 한 명 적어 두는 것이 여기서 가장 먼저 하는 일입니다. 주인이 없는 표는 틀려도 고칠 사람이 없습니다.
2. 개인 식별 정보 — 이름, 연락처, 주소처럼 한 사람을 특정할 수 있는 데이터입니다. 어느 칸이 여기 해당하는지 표시해 두면 그 칸에만 다른 규칙이 붙습니다. 열람 권한을 좁히고, 보관 기간을 따로 두고, 밖으로 내보내는 파일에서는 빼는 식입니다.
3. 비식별 처리 — 그런 칸을 누구인지 알아볼 수 없는 형태로 바꿔 두는 일입니다. 생년월일을 연 단위로 뭉개거나 이메일을 되돌릴 수 없는 값으로 바꿔 두면, 같은 사람인지는 여전히 셀 수 있으면서 그 사람이 누구인지는 남지 않습니다.

세 갈래에 손대는 순서는 대개 반대입니다. 눈에 먼저 띄는 것은 점검이지만, 점검을 걸려면 무엇을 재야 하는지부터 정해야 하고 그건 관리가 정해 둔 주인이 답할 몫입니다. 주인이 없는 표에 규칙을 걸면 알림이 울려도 받을 사람이 없어 한 달 안에 꺼집니다.

세 갈래는 한 줄로 이어집니다. 점검이 지금 값이 쓸 만한지를 알려 주고, 추적이 쓸 만하지 않을 때 어디를 고쳐야 하는지와 고치면 무엇이 같이 바뀌는지를 알려 주고, 관리가 애초에 누가 무엇을 넣고 꺼낼 수 있는지를 정합니다. 점검만 깔아 둔 조직에서는 알림이 울려도 누가 받아 무엇을 할지가 정해져 있지 않아 알림을 끄는 것으로 끝납니다.

"이 표 신선도 경보 떴어요. 어제 열한 시 이후로 안 들어왔습니다."

화면의 숫자가 틀린 게 아니라 하루치가 덜 반영된 상태이니 지금 이 표로 결정하지 말라는 신호입니다.

"그 매출 숫자 계보 한번 따 볼게요. 어느 단계에서 갈라지는지 보고 이야기하죠."

결과를 놓고 다투는 대신 값이 지나온 경로를 거슬러 올라가 틀어진 지점을 먼저 찾자는 제안입니다.

"이 칸은 개인 식별 정보라 그대로는 못 내려 드려요. 비식별 처리한 사본으로 드릴게요."

요청을 막는 말이 아니라 권한 규칙에 맞는 다른 형태로 주겠다는 답입니다.

페이지덱에서는 이런 일이 있었습니다. 월요일 대시보드에서 주간 활성 계정이 전주보다 14퍼센트 떨어진 것을 보고 지현이 태오에게 물었습니다. 태오가 먼저 연 것은 화면이 아니라 그 화면이 쓰는 표였습니다. 사흘 전부터 검증 규칙 하나가 매일 2,000줄 남짓을 걸러 내고 있었고, 걸러 낸 줄은 어디에도 남지 않고 버려지고 있었습니다. 앱 업데이트에서 요금제 이름 하나가 바뀌었는데 규칙에 적힌 목록은 예전 세 값 그대로였기 때문입니다.

떨어진 14퍼센트 중 실제 감소는 3퍼센트였고 나머지는 걸러진 줄이었습니다. 그 사흘 동안 지현은 활성 계정이 줄어든 원인을 새 온보딩 화면에서 찾고 있었고, 되돌릴지를 두고 민서와 두 번 회의를 했습니다. 표가 틀렸다는 것을 몰랐으니 화면을 의심할 수밖에 없었습니다.

고친 뒤 두 사람이 정한 것은 규칙의 목록이 아니라 절차였습니다. 걸러 낸 줄을 버리지 않고 따로 쌓아 두고, 하루에 걸러진 줄이 평소의 다섯 배를 넘으면 지현과 태오 모두에게 알림이 가게 했습니다. 규칙이 현실보다 늦는 일은 앞으로도 생기지만, 그때 조용히 지나가지는 않습니다.

한 번 손보면 끝나는 정리 작업으로 여기는 경우가 가장 많습니다. 처음 손을 대면 눈에 띄게 좋아지니 그렇게 보입니다. 중복된 줄을 지우고 빈 칸을 메우고 나면 그 주부터 회의에 들어오는 숫자가 맞기 시작하고, 그러면 일이 끝난 것처럼 느껴집니다. 그러나 데이터는 제품이 바뀔 때마다 같이 바뀝니다. 결제 화면에 요금제가 하나 늘면 그날부터 예전에 없던 값이 들어오고, 가입 단계를 하나 줄이면 그 단계를 세던 기록이 사라집니다. 정리한 상태는 그때의 제품에 맞춰진 것이라 제품이 움직이면 같이 어긋납니다. 그대로 두면 반년 뒤에 똑같은 회의가 다시 열리고, 그사이에 어긋난 숫자로 내린 결정들은 아무도 되짚지 않습니다.

데이터를 다루는 사람만의 일로 미루는 것도 흔합니다. 문제를 발견하고 알리는 쪽이 늘 그쪽이라 책임도 그쪽에 있는 것처럼 보입니다. 하지만 어긋남이 생기는 지점은 대개 훨씬 앞입니다. 칸 이름을 바꾸거나 값을 하나 더하는 결정은 제품과 개발에서 나고, 그 결정이 어떤 표를 건드리는지는 결정하는 자리에서 잘 안 보입니다. 앞의 페이지덱 사례가 그랬습니다. 요금제 이름을 바꾼 쪽은 값을 하나 고쳤을 뿐이고, 그 이름이 검증 규칙 안에 적혀 있다는 것은 고친 사람이 알 길이 없었습니다. 이 구조를 그대로 두면 데이터 쪽은 계속 뒤에서 메우는 일만 하게 되고, 같은 종류의 사고가 분기마다 되풀이됩니다. 기능을 만들 때 어떤 값이 어떤 형태로 남을지를 함께 정해 두는 편이 나중에 수습하는 것보다 품이 적게 듭니다.