데이터 품질

데이터 품질은 데이터가 쓰려는 목적에 맞는 정도입니다. 틀린 값이나 빠진 값이 섞인 데이터로 만든 보고서는 틀린 결론을 냅니다. 그래서 데이터를 모으고 옮기는 작업은 중간중간 품질을 재고 검사합니다. 무엇을 결함으로 볼지는 그 데이터를 어디에 쓰느냐가 정합니다.

상세

식당 주방은 들어온 식재료를 바로 쓰지 않고 먼저 살펴봅니다. 주문한 만큼 왔는지, 상한 것은 없는지, 유통기한이 남았는지를 봅니다. 이때 걸러 내지 못한 재료는 요리가 되어 손님 상에 오릅니다.

데이터에도 같은 확인을 합니다. 이 확인이 품질 검사입니다. 품질 검사가 지키려는 것이 데이터 품질입니다. 틀리거나 빠진 데이터가 그대로 흘러가면 그 데이터로 만든 보고서와 판단까지 틀립니다.

이 절은 쇼핑몰의 주문 데이터를 가지고 품질이 무엇이고 어디서 나빠지는지를 봅니다. 그다음 품질을 재는 기준 여섯을 보고, 검사를 코드로 적어 데이터 흐름에 끼우는 방법을 봅니다. 검사를 어디까지 할지로 끝냅니다.

쓰는 목적에 맞는 정도

데이터 품질은 데이터가 쓰려는 목적에 맞는 정도를 말합니다. 같은 데이터라도 어디에 쓰느냐에 따라 쓸 만하기도 하고 못 쓰기도 합니다.

회원 주소에 동과 호수가 빠진 행이 많다고 해 봅니다. 지역별 가입자 수를 세는 데는 시와 구만 있으면 되므로 문제가 없습니다. 택배를 보내는 데는 쓸 수 없습니다.

그래서 품질을 따질 때는 「무엇에 쓸 데이터인가」부터 정합니다. 쓰임이 정해져야 어떤 결함을 견디고 어떤 결함을 막을지가 정해집니다.

품질이 나빠지는 곳

주문 같은 데이터가 처음 기록되는 곳을 원천 시스템이라고 부릅니다. 쇼핑몰이라면 주문 데이터베이스와 회원 데이터베이스가 원천 시스템입니다. 분석하는 사람은 원천을 직접 보지 않습니다. 분석용 저장소로 옮겨 온 복사본을 봅니다.

원천에서 데이터를 꺼내 모양을 바꾸고 분석용 저장소에 넣기까지 이어진 작업을 데이터 파이프라인이라고 부릅니다. 품질은 이 길 위 어디서든 나빠질 수 있습니다. 흔한 경우는 아래와 같습니다.

품질 문제는 원천에서만 생기지 않습니다. 원천이 멀쩡해도 옮기고 바꾸는 과정에서 분석용 저장소의 데이터가 틀릴 수 있습니다.

틀린 데이터는 오류를 내지 않는다

백엔드 코드의 버그는 대개 예외나 오류 응답으로 드러납니다. 데이터 품질 문제는 다릅니다. 금액이 음수인 주문이 세 건 섞여도 합계를 내는 조회는 멀쩡히 돕니다. 결과로 나온 매출이 조금 작을 뿐입니다.

그래서 틀린 데이터는 조용히 퍼집니다. 틀린 일별 매출 표로 만든 월별 표가 틀립니다. 그 표를 보여 주는 대시보드도 틀립니다. 누군가 그 숫자로 광고 예산을 정한 뒤에야 드러나기도 합니다.

늦게 찾을수록 고치는 일도 커집니다. 틀린 값을 고친 뒤 그 값으로 만든 표를 전부 다시 계산해야 합니다. 지난 기간의 데이터를 다시 돌려 채우는 이 작업을 백필이라고 부릅니다. 품질 검사를 데이터 흐름의 앞쪽에 두는 까닭이 이것입니다.

품질을 재는 기준

「품질을 지킨다」는 말만으로는 검사를 짤 수 없습니다. 무엇을 지킬지 기준으로 나눠야 합니다. 아래 여섯이 가장 흔히 쓰이는 기준입니다.

표의 일관성은 같은 사실을 담은 두 데이터가 서로 어긋나지 않는 것을 말합니다. 트랜잭션이나 분산 시스템에서 말하는 일관성과는 다른 뜻입니다.

정확성은 여섯 가운데 재기가 가장 어렵습니다. 고객이 실제로 낸 돈 같은 현실은 데이터 밖에 있습니다. 현실과 견주려면 현실을 따로 알아야 합니다.

정확성은 직접 재는 대신 어림합니다. 먼저 규칙만 보면 되는 유효성과 유일성을 잽니다. 그다음 주문 표와 결제 표처럼 다른 원천과 맞대 보는 일관성으로 정확성을 가늠합니다.

여섯을 늘 다 재지는 않습니다. 쓰는 목적이 고릅니다. 아침 매출 보고서라면 적시성과 완전성이 먼저이고, 정산에 쓰는 데이터라면 정확성과 유일성이 먼저입니다.

데이터베이스 제약 조건과 다른 점

백엔드 개발자에게 익숙한 방어선은 데이터베이스의 제약 조건입니다. 빈 값을 막는 NOT NULL, 겹치는 값을 막는 유니크 제약, 없는 행을 가리키지 못하게 하는 외래 키가 그렇습니다. 이들은 규칙을 어긴 행이 들어오는 순간 쓰기를 거절합니다.

제약 조건이 지키는 성질을 무결성이라고 부릅니다. 데이터가 정해 둔 규칙을 어기지 않은 상태입니다. 무결성은 앞 표의 유효성·유일성과 겹칩니다. 데이터 품질은 여기에 적시성처럼 규칙으로 막을 수 없는 기준까지 더한 넓은 말입니다.

품질 검사가 제약 조건과 다른 점은 둘입니다. 첫째, 이미 들어온 데이터를 나중에 봅니다. 파이프라인은 여러 원천에서 데이터를 받습니다. 그 원천의 쓰기를 막을 권한은 없으니 들어온 뒤에 보고 판단합니다.

둘째, 한 행이 아니라 데이터 묶음 전체를 봅니다. 「어제 주문이 평소의 절반뿐이다」는 행 하나만 봐서는 알 수 없습니다. 제약 조건으로는 이런 규칙을 걸 수 없습니다.

두 방어선은 서로를 대신하지 않습니다. 원천 데이터베이스에서 막을 수 있는 것은 거기서 막습니다. 여러 원천이 모인 뒤에야 보이는 것은 품질 검사가 잡습니다.

검사를 코드로 적기

품질 검사는 대개 데이터에 던지는 조회로 적습니다. 아래는 어제 들어온 주문을 먼저 담아 둔 new_orders 표에 던지는 검사 넷입니다. 각 조회가 돌려준 값을 줄 끝 주석에 적었습니다.

SELECT COUNT(*) FROM new_orders;   -- 9812

SELECT COUNT(*) FROM new_orders
WHERE customer_id IS NULL;         -- 0

SELECT COUNT(*) FROM new_orders
WHERE amount < 0;                  -- 3

SELECT COUNT(*) - COUNT(DISTINCT order_id)
FROM new_orders;                   -- 41

첫 조회는 행 수를 셉니다. 원천에서 읽은 행 수와 견주면 옮기다 빠진 행이 있는지 압니다. 하루 주문이 만 건 안팎인 쇼핑몰이라면 9812 는 평소 범위입니다.

둘째 조회는 고객 번호가 빈 주문을 셉니다. 0 이 나왔으니 완전성 검사를 통과합니다. 셋째 조회는 금액이 음수인 주문을 셉니다. 3 이 나왔으니 유효성 검사에 걸립니다.

넷째 조회는 전체 행 수에서 서로 다른 주문 번호의 수를 뺍니다. 주문 번호가 하나씩만 있으면 0 이 나와야 합니다. 41 은 같은 주문 번호가 여러 번 들어왔다는 뜻입니다. 앞 표에서 본 것처럼 작업이 도중에 실패한 뒤 다시 돌면서 앞서 넣은 행을 또 넣으면 이런 값이 나옵니다.

검사마다 「얼마가 나와야 통과인가」를 함께 적어 둡니다. 둘째·셋째·넷째는 0 이어야 통과입니다. 첫째는 평소 행 수에서 크게 벗어나지 않아야 통과입니다.

검사에 걸렸을 때

검사는 데이터가 다음 단계로 넘어가기 전에 둡니다. 원천에서 막 꺼낸 데이터, 모양을 바꾼 데이터, 분석용 저장소에 넣기 직전의 데이터가 흔한 검사 시점입니다. 걸린 데이터가 다음 단계로 번지지 않게 하려는 것입니다.

걸렸을 때 하는 일은 문제의 무게에 따라 갈립니다. 주문 번호가 대량으로 겹치면 그 묶음의 매출 합계를 통째로 믿을 수 없습니다. 이럴 때는 파이프라인을 멈추고 담당자에게 알립니다.

멈추면 그날 보고서가 늦어집니다. 그래도 늦은 보고서는 기다리면 그만입니다. 틀린 보고서는 퍼진 뒤에 되돌려야 합니다.

음수 금액 세 건처럼 일부 행만 틀리면 그 행만 떼어 냅니다. 떼어 낸 행은 별도 표에 모아 사람이 살펴봅니다. 나머지는 다음 단계로 넘깁니다. 두 갈림을 이어 그리면 아래와 같습니다.

flowchart TD
    A["새로 들어온 데이터"] --> B["품질 검사"]
    B -->|통과| C["다음 단계로 넘긴다"]
    B -->|걸림| D{"묶음 전체를 못 믿나"}
    D -->|예| E["파이프라인을 멈추고 알린다"]
    D -->|아니오| F["걸린 행만 별도 표에 모은다"]
    F --> C

규칙 밖의 문제

적어 둔 검사는 적어 둔 규칙만 봅니다. 아무도 예상하지 못한 방식으로 데이터가 틀리면 모든 검사가 통과합니다. 원천에서 금액 단위를 원에서 천 원으로 바꾸면 음수도 빈 값도 없으니 검사가 조용합니다.

규칙과 별도로 데이터의 생김새(행 수, 빈 값의 비율, 값의 평균)가 평소와 달라졌는지도 지켜봅니다. 이 값들을 날마다 기록합니다. 평소 범위를 크게 벗어나면 알립니다. 이상치는 이렇게 평소 범위에서 동떨어진 값입니다.

금액 단위가 바뀐 앞의 예도 여기서 잡힙니다. 평균 주문 금액이 하루 만에 천분의 일로 떨어지기 때문입니다. 데이터 관측성은 파이프라인의 데이터를 이렇게 늘 지켜보는 일입니다.

어디까지 검사하나

검사에도 비용이 듭니다. 큰 표를 매번 처음부터 끝까지 훑으면 그만큼 시간과 계산이 듭니다. 검사가 끝날 때까지 데이터도 늦게 도착합니다. 그래서 새로 들어온 부분만 검사하거나, 일부 행을 뽑아 검사하기도 합니다.

규칙을 많이 건다고 품질이 오르지도 않습니다. 중요하지 않은 열까지 검사를 걸면 날마다 경고가 수십 건씩 쌓입니다. 사람들은 곧 경고를 읽지 않게 됩니다. 중요한 경고도 함께 묻힙니다.

그래서 검사는 누가 그 데이터에 기대는지부터 따져 겁니다. 매출 보고서나 정산처럼 틀리면 돈과 결정이 걸리는 표에는 촘촘히 겁니다. 한 번 보고 버릴 탐색용 데이터에는 느슨하게 둡니다.

검사에 걸렸을 때 누가 고치는지도 미리 정해 둡니다. 정해 두지 않으면 경고가 쌓이기만 합니다. 원천을 맡은 팀과 데이터를 쓰는 팀이 지킬 규칙을 문서로 합의해 두는 방식을 데이터 계약이라고 부릅니다.

관련 항목

데이터 품질을 나눠 재는 기준

정확성 · 완전성 · 적시성 · 유효성 · 유일성 · 데이터 신선도

데이터 품질과 이름이 겹쳐 헷갈리는 이웃

일관성 · 무결성 · 참조 무결성 · 데이터 정합성

데이터 품질을 원천에서 지키는 데이터베이스 장치

제약조건 · 유니크 제약 · 기본 키 · 외래 키 · NOT NULL · 체크 제약 · 데이터 타입

데이터 품질 검사가 끼어드는 처리 단계

데이터 파이프라인 · ETL · ELT · 추출 · 변환 · 적재 · 데이터 정제 · 스테이징 영역

데이터 품질이 지켜 주는 저장소

데이터 웨어하우스 · 데이터 레이크 · 데이터 마트 · 레이크하우스

데이터 품질을 떨어뜨리는 흔한 장애

중복 적재 · 데이터 누락 · 스키마 드리프트 · 늦게 도착한 데이터 · 낡은 데이터

데이터 품질을 지켜보고 되살리는 방법

데이터 관측성 · 데이터 프로파일링 · 이상치 · 이상 탐지 · 모니터링 · 백필 · 데이터 계보

데이터 품질을 정하고 책임지는 체계

데이터 거버넌스 · 데이터 계약 · 데이터 카탈로그 · 메타데이터 · 마스터 데이터 관리 · 단일 진실 원천

데이터 품질 검사를 적고 돌리는 도구

dbt · Great Expectations · Deequ · Apache Airflow

데이터 품질이 속하는 상위 분류

데이터 엔지니어링 · 데이터 관리 · 데이터 분석