데이터 품질 지표 계산: 고객 정보의 완전성·유효성·정확성 구분

1장. 빈칸은 줄었는데 왜 고객에게 연락할 수 없을까#

고객 전화번호 누락이 많아 데이터 품질 개선 작업을 시작했다고 하겠습니다.

처음에는 전화번호가 없는 고객이 많았습니다.

담당자는 빈 전화번호를 빠르게 채웠습니다.

품질 대시보드에는:

전화번호 완전성
82%
↓
99%

라고 표시됩니다.

매우 좋아 보입니다.

그런데 배송팀에서는 계속 말합니다.

고객에게 전화가 연결되지 않습니다.

확인해 보니 일부 전화번호는:

000-0000-0000

같은 임시값이었고, 일부는 다른 사람의 번호였습니다.

즉:

값이 있다

와:

실제로 사용할 수 있는 값이다

는 다른 문제입니다.

데이터 품질에서는 이 차이를 여러 품질 차원으로 나눠 측정합니다.

2장. 데이터 품질을 하나의 점수로 표현하면 원인이 사라진다#

다음과 같은 품질 점수가 있다고 하겠습니다.

고객 데이터 품질
92점

숫자는 간단합니다.

하지만 무엇이 문제인지 알 수 없습니다.

전화번호가 비어 있는가?

형식이 틀렸는가?

다른 사람 번호인가?

중복 고객이 있는가?

주소가 너무 오래됐는가?

CRM과 쇼핑몰 값이 다른가?

이 문제들은 해결 방법이 모두 다릅니다.

따라서 품질 차원을 분리해서 보는 것이 중요합니다.

3장. 대표적인 데이터 품질 차원#

이번 글에서는 다음 여섯 가지를 사용하겠습니다.

품질 차원	핵심 질문
완전성	필요한 값이 존재하는가?
유효성	정해진 형식과 규칙을 만족하는가?
정확성	실제 사실과 일치하는가?
유일성	같은 실체가 불필요하게 중복되지 않았는가?
적시성	필요한 시점에 충분히 최신인가?
일관성	서로 비교해야 할 시스템의 값이 같은 의미를 갖는가?

같은 전화번호도 이 여섯 질문에 서로 다른 답을 가질 수 있습니다.

4장. 실습용 고객 다섯 명을 준비하자#

배송 안내를 위해 전화번호가 필수인 활성 고객 다섯 명이 있다고 하겠습니다.

행 ID	고객 ID	전화	우편번호	최종 주소 확인
1	M-1	010-1111-2222	04524	9월 25일
2	M-2	NULL	06236	9월 20일
3	M-3	010-3333-4444	99999	8월 1일
4	M-4	010-3333-4444	99999	8월 1일
5	M-5	abc	03112	9월 24일

이번 예제에서는 전화번호 형식 규칙을 단순하게:

010-####-####

으로 정하겠습니다.

실제 운영에서는 국제번호·대표번호·가상번호·유선번호 등 업무에서 허용하는 유형을 반영해야 합니다.

5장. 측정 전에 대상 집합부터 고정해야 한다#

이번 지표의 대상은:

활성 고객

그리고

배송 안내 전화가 필요한 고객

입니다.

고객 수:

5명

입니다.

이 5명이 완전성의 분모가 됩니다.

이렇게 대상 집합을 먼저 고정해야 다음날 지표가 변했을 때:

실제 데이터가 개선된 것인지

대상 고객 수가 바뀐 것인지

구분할 수 있습니다.

6장. 완전성은 필요한 값이 있는지를 본다#

전화번호가 존재하는 고객은:

M-1

M-3

M-4

M-5

입니다.

M-2는 NULL입니다.

따라서:

전화 입력 고객
4명

전체 대상 고객
5명

완전성은:

4 / 5 × 100
=
80%

입니다.

7장. 완전성이 80%라는 말은 번호가 맞다는 뜻이 아니다#

M-5에는:

abc

가 들어 있습니다.

값은 존재합니다.

따라서 완전성 계산에서는 채워진 값으로 볼 수 있습니다.

하지만 전화번호 형식은 아닙니다.

즉:

완전성
→ 통과

유효성
→ 실패

할 수 있습니다.

8장. 빈 문자열도 누락으로 처리해야 할 수 있다#

다음 값이 있다고 하겠습니다.

phone = ''

SQL NULL은 아니지만 실제 전화번호도 아닙니다.

또:

'   '

처럼 공백만 있는 값도 있을 수 있습니다.

업무 규칙에서는:

NULL

빈 문자열

공백 문자열

을 모두 누락으로 처리할 수 있습니다.

완전성 규칙은 단순 IS NOT NULL보다 업무 의미를 포함해야 합니다.

9장. 유효성은 정해진 규칙을 만족하는지 본다#

전화가 입력된 네 건은 다음과 같습니다.

010-1111-2222

010-3333-4444

010-3333-4444

abc

형식 규칙:

010-####-####

을 만족하는 값은 세 건입니다.

따라서 입력된 전화만 분모로 사용한다면:

유효성
=
3 / 4 × 100
=
75%

입니다.

10장. 완전성과 유효성의 분모가 다르다#

완전성:

4 / 5
=
80%

유효성:

3 / 4
=
75%

입니다.

왜 유효성의 분모가 4일까요?

이번 정의에서는 값이 입력된 전화 가운데 형식 규칙을 통과한 비율을 측정했기 때문입니다.

그래서 두 지표를 단순히:

80%와 75%

로 비교하면서 어느 쪽이 더 나쁘다고 판단하면 안 됩니다.

질문과 분모가 다릅니다.

11장. “전체 고객 중 유효한 전화 보유 비율”도 별도로 계산할 수 있다#

다른 질문을 만들 수도 있습니다.

전체 필수 대상 고객 가운데 형식에 맞는 전화번호를 가진 고객은 몇 명인가?

유효한 전화:

3건

전체 대상:

5건

이므로:

3 / 5
=
60%

입니다.

이 지표는 앞의 유효성 75%와 다른 질문입니다.

12장. 세 숫자를 나란히 보면 문제 위치가 보인다#

지표	계산	결과
전화 완전성	4 / 5	80%
입력 전화 형식 유효성	3 / 4	75%
전체 대상 중 유효 전화 보유	3 / 5	60%

이 표를 보면:

누락 1건

형식 오류 1건

이 각각 존재한다는 사실을 쉽게 알 수 있습니다.

13장. 정확성은 형식 검사만으로 판단할 수 없다#

M-1 전화번호:

010-1111-2222

형식은 완벽합니다.

하지만 이 번호가 실제 M-1 고객의 번호인지 아직 모릅니다.

다른 사람 번호일 수도 있습니다.

따라서:

형식 유효
=
실제 사실과 일치

가 아닙니다.

14장. 정확성을 측정하려면 외부의 신뢰 가능한 근거가 필요하다#

전화 정확성을 확인할 수 있는 방법은 업무에 따라 다릅니다.

예:

본인 인증

고객 직접 확인

신뢰 가능한 원천 시스템

통화 확인

계약 자료

만약 100건을 확인했고 그중 96건이 실제 고객 번호였다면:

정확성
=
96 / 100
=
96%

처럼 계산할 수 있습니다.

15장. 현재 다섯 행만으로는 정확성을 계산할 수 없다#

M-3과 M-4의 전화번호가 같습니다.

010-3333-4444

그렇다고 이 번호가 틀렸다고 할 수 없습니다.

가족이 같은 연락처를 사용하는 것일 수도 있습니다.

M-3의 우편번호:

도 형식적으로 5자리 숫자입니다.

하지만 실제 주소와 맞는지는 별도의 기준 데이터와 비교해야 합니다.

따라서 현재 표만으로 정확성을 숫자로 계산해서는 안 됩니다.

16장. 모른다는 상태도 품질 측정의 일부다#

품질 보고서에:

정확성
100%

처럼 추정값을 넣는 것보다:

정확성
계산 불가

사유
외부 검증 기준 없음

이라고 표시하는 편이 더 정확합니다.

측정할 근거가 없다는 사실 자체가 개선 과제를 보여줍니다.

17장. 유일성은 단순히 기본키 중복이 없는지를 뜻하지 않을 수 있다#

고객 ID:

M-3

M-4

는 서로 다릅니다.

따라서 데이터베이스 기본키 기준으로는 중복이 없습니다.

고객 ID 유일성
100%

일 수 있습니다.

그런데 실제로 같은 사람이 두 계정을 만든 것이라면 실세계 기준 중복은 존재합니다.

18장. 키 유일성과 실체 유일성을 분리해야 한다#

키 유일성#

customer_id가 중복되지 않는가?

실체 유일성#

같은 사람이 여러 customer_id로 존재하지 않는가?

서로 다른 질문입니다.

MDM에서도 보았듯 실제 동일인을 판단하려면 추가 증거가 필요합니다.

19장. 같은 전화번호 두 건을 바로 중복 고객 두 건이라고 세면 안 된다#

M-3:

010-3333-4444

M-4:

010-3333-4444

입니다.

여기서 계산할 수 있는 것은:

동일 전화번호를 가진 후보

입니다.

아직 계산할 수 없는 것은:

실제 동일 고객 중복

입니다.

두 지표를 구분해야 합니다.

20장. 중복 탐지 결과도 단계별로 보고하는 것이 좋다#

예를 들어 중복 후보가 12쌍 나왔다고 하겠습니다.

수동 검토 결과:

실제 동일인
8쌍

다른 사람
3쌍

판정 보류
1쌍

이었다고 하겠습니다.

보고서는:

중복 고객 12건

이라고 쓰면 안 됩니다.

정확한 표현은:

중복 후보 12쌍

확정 동일인 8쌍

처럼 구분하는 것입니다.

21장. 적시성은 얼마나 최근에 확인됐는지를 본다#

기준일을:

9월 26일

이라고 하겠습니다.

주소가 30일 이내 확인됐어야 한다고 정합니다.

각 고객:

M-1
9월 25일

M-2
9월 20일

M-3
8월 1일

M-4
8월 1일

M-5
9월 24일

입니다.

30일 이내 확인된 고객은 세 명입니다.

22장. 적시성을 계산해 보면#

3 / 5
=
60%

입니다.

하지만 이 숫자도 주의해서 해석해야 합니다.

8월 1일 확인된 주소가 실제로 아직 유효할 수도 있습니다.

따라서 적시성은:

최근 확인 여부

이지:

실제 주소가 틀렸다

는 뜻이 아닙니다.

23장. 최신 정보와 정확한 정보도 서로 다르다#

어제 입력한 주소:

부산

이 실제 고객 주소와 다를 수 있습니다.

반대로 6개월 전에 확인한 주소:

서울

이 아직 정확할 수도 있습니다.

즉:

최근 수정
≠
정확

입니다.

적시성과 정확성은 다른 품질 차원입니다.

24장. 일관성은 비교 가능한 시스템 간의 값이 맞는지를 본다#

같은 고객 M-1이 다음처럼 존재한다고 하겠습니다.

CRM:

주소
서울

쇼핑몰:

주소
부산

둘이 서로 다른 값을 가지고 있습니다.

이것은 일관성 문제 후보입니다.

25장. 값이 다르다고 무조건 오류인 것도 아니다#

CRM 주소가:

현재 거주지

이고 쇼핑몰 주소가:

최근 배송지

라면 두 값이 달라도 정상입니다.

따라서 일관성 비교에서는:

같은 의미의 속성인가?

부터 확인해야 합니다.

비교 대상의 의미가 같을 때만 값 일치 여부가 품질 지표가 됩니다.

26장. 여섯 차원을 현재 예제에 적용하면#

차원	질문	현재 계산
완전성	필수 고객의 전화가 있는가?	4/5 = 80%
유효성	입력 전화가 형식을 만족하는가?	3/4 = 75%
정확성	실제 고객 번호인가?	근거 부족으로 계산 불가
유일성	실제 동일인의 중복 계정이 없는가?	확인 전 계산 불가
적시성	30일 내 주소 확인됐는가?	3/5 = 60%
일관성	다른 시스템의 같은 속성이 일치하는가?	비교 원천 없어 계산 불가

계산할 수 없는 항목까지 명확히 표시해야 합니다.

27장. 프로파일링은 품질 문제를 찾는 출발점이다#

데이터 프로파일링에서는 다음을 먼저 볼 수 있습니다.

NULL 수

빈 문자열 수

최솟값·최댓값

길이 분포

형식 분포

고유값 수

중복값 빈도

최근 수정 시각

예를 들어 전화번호 컬럼에서:

NULL
20%

길이 13
70%

길이 11
5%

기타
5%

같은 결과가 나오면 어디를 조사할지 알 수 있습니다.

28장. 프로파일링은 오류 판정 그 자체가 아니다#

전화번호 값이 많이 중복됐다고 하겠습니다.

프로파일링 결과:

010-1234-5678
120회 등장

이것만 보고 119개를 삭제하면 안 됩니다.

기업 대표번호나 공용 연락처일 수 있습니다.

프로파일링은:

이상해 보이는 지점

을 찾는 단계입니다.

업무 판정은 별도의 규칙과 검토가 필요합니다.

29장. 품질 규칙은 이름만 붙이는 것이 아니라 계약처럼 정의해야 한다#

예:

Q-PHONE-01

이라는 규칙을 만든다고 하겠습니다.

다음 정보를 함께 정의합니다.

항목	내용
대상	활성 고객 중 배송 전화 필수 대상
필드	phone
규칙	전화번호 존재
분모	대상 고객 수
목표	누락률 1% 미만
책임	고객 데이터 소유자
검사 주기	매일
실패 처리	고객 확인 요청
규칙 버전	v1.0

이렇게 해야 결과를 재현할 수 있습니다.

30장. 규칙 버전을 남겨야 지표 변화를 설명할 수 있다#

어제 전화번호 규칙:

010만 허용

오늘:

010

유선전화

국제번호

까지 허용하도록 바뀌었다고 하겠습니다.

유효성 지표가:

80%
→
95%

로 올랐습니다.

데이터가 개선된 것이 아니라 규칙이 완화된 것일 수도 있습니다.

그래서 규칙 버전이 필요합니다.

31장. 분모 변경도 반드시 기록해야 한다#

어제 활성 고객:

10만 명

오늘:

8만 명

입니다.

휴면 고객 2만 명을 측정 대상에서 제외했기 때문입니다.

완전성이 상승했다면 원인은:

실제 값 개선

또는

대상 고객 제거

일 수 있습니다.

비교 가능한 지표를 만들려면 대상 정의를 함께 기록해야 합니다.

32장. SQL로 완전성과 유효성을 직접 계산해 보자#

교육용 예제로 다음 데이터를 사용하겠습니다.

WITH customer(id, phone) AS (
    VALUES
        (1, '010-1111-2222'),
        (2, NULL),
        (3, '010-3333-4444'),
        (4, '010-3333-4444'),
        (5, 'abc')
)
SELECT *
FROM customer;

이제 각 행의 존재 여부와 형식 적합 여부를 계산합니다.

33장. 누락 여부를 먼저 계산한다#

WITH customer(id, phone) AS (
    VALUES
        (1, '010-1111-2222'),
        (2, NULL),
        (3, '010-3333-4444'),
        (4, '010-3333-4444'),
        (5, 'abc')
)
SELECT
    id,
    phone,
    CASE
        WHEN phone IS NOT NULL
         AND trim(phone) <> ''
        THEN 1
        ELSE 0
    END AS present
FROM customer;

결과에서 present 합계는 4입니다.

34장. 형식 유효성도 별도 계산한다#

SQLite의 교육용 GLOB을 사용해 보겠습니다.

WITH customer(id, phone) AS (
    VALUES
        (1, '010-1111-2222'),
        (2, NULL),
        (3, '010-3333-4444'),
        (4, '010-3333-4444'),
        (5, 'abc')
)
SELECT
    id,
    phone,
    CASE
        WHEN phone GLOB
            '010-[0-9][0-9][0-9][0-9]-[0-9][0-9][0-9][0-9]'
        THEN 1
        ELSE 0
    END AS format_ok
FROM customer;

형식 통과는 세 건입니다.

실제 운영용 전화번호 검증 규칙으로 이 단순 패턴을 그대로 사용해서는 안 됩니다.

35장. 두 지표를 한 번에 계산하면#

WITH customer(id, phone) AS (
    VALUES
        (1, '010-1111-2222'),
        (2, NULL),
        (3, '010-3333-4444'),
        (4, '010-3333-4444'),
        (5, 'abc')
),
measured AS (
    SELECT
        id,
        phone,
        CASE
            WHEN phone IS NOT NULL
             AND trim(phone) <> ''
            THEN 1
            ELSE 0
        END AS present,
        CASE
            WHEN phone GLOB
                '010-[0-9][0-9][0-9][0-9]-[0-9][0-9][0-9][0-9]'
            THEN 1
            ELSE 0
        END AS format_ok
    FROM customer
)
SELECT
    COUNT(*) AS eligible,
    SUM(present) AS filled,
    SUM(format_ok) AS valid,
    ROUND(
        100.0 * SUM(present) / COUNT(*),
        1
    ) AS completeness_pct,
    ROUND(
        100.0 * SUM(format_ok)
        / NULLIF(SUM(present), 0),
        1
    ) AS validity_pct
FROM measured;

결과:

eligible
5

filled
4

valid
3

completeness
80.0%

validity
75.0%

입니다.

36장. NULLIF는 0으로 나누는 오류를 방지한다#

전화번호가 단 한 건도 입력되지 않은 날을 생각해 보겠습니다.

SUM(present)
=
0

유효성 식:

valid / present

은 0으로 나누게 됩니다.

그래서:

NULLIF(SUM(present), 0)

을 분모로 사용해 0인 경우 NULL로 바꿀 수 있습니다.

37장. 형식 오류를 NULL로 바꾸면 어떤 일이 생길까#

현재:

M-5
phone = abc

입니다.

담당자가 잘못된 형식이라는 이유로:

abc
→ NULL

로 바꿨습니다.

이제 입력 전화는:

3건

입니다.

세 건 모두 형식이 맞습니다.

유효성:

3 / 3
=
100%

입니다.

38장. 유효성은 100%가 됐지만 완전성은 떨어졌다#

전화가 있는 고객:

3명

전체 고객:

5명

이므로:

완전성
=
3 / 5
=
60%

입니다.

변경 전:

완전성
80%

유효성
75%

변경 후:

완전성
60%

유효성
100%

입니다.

39장. 품질 지표 하나만 최적화하면 실제 서비스는 더 나빠질 수 있다#

담당자의 목표가:

유효성 100%

뿐이었다면 abc를 삭제하는 것이 성공처럼 보입니다.

하지만 배송팀 입장에서는:

연락 가능한 고객
증가하지 않음

입니다.

오히려 전화번호가 있는 고객 수는 줄었습니다.

따라서 품질 개선은 여러 품질 차원과 실제 업무 결과를 함께 봐야 합니다.

40장. 임시값으로 채우면 반대 착시가 발생한다#

M-2의 NULL을:

010-0000-0000

으로 채웠다고 하겠습니다.

완전성은:

5 / 5
=
100%

이 될 수 있습니다.

형식 규칙도 통과할 수 있습니다.

하지만 실제 고객 번호는 아닙니다.

즉:

완전성
100%

형식 유효성
100%

정확성
낮음

이라는 상황이 가능합니다.

41장. 실제 업무 KPI와 데이터 품질 KPI를 연결해야 한다#

전화 품질을 개선했다면 다음 업무 지표도 확인할 수 있습니다.

배송 전 연락 성공률

SMS 전송 성공률

고객 확인 완료율

잘못된 연락 신고 건수

예를 들어 전화 완전성이 99%가 됐는데 SMS 성공률이 70%라면 단순 누락 외에 다른 문제가 남아 있을 가능성이 큽니다.

42장. 데이터 품질 개선은 정제 작업에서 끝나지 않는다#

매일 다음 배치를 수행한다고 하겠습니다.

잘못된 전화번호 탐지
↓
수정

그런데 가입 화면에서는 여전히:

abc

를 입력할 수 있습니다.

다음날 다시 같은 오류가 들어옵니다.

이런 구조는:

오류를 계속 만들고

뒤에서 계속 청소

하는 구조입니다.

43장. 좋은 품질 개선은 오류 발생 지점을 수정한다#

M-5의 abc가 가입 화면에서 들어왔다고 하겠습니다.

개선 과정은:

오류 행 찾기
↓
원천 화면 확인
↓
입력 검증 추가
↓
기존 오류 정정
↓
새 오류 발생 여부 측정

으로 이어져야 합니다.

단순 데이터 정제보다 오류 생성 원인을 제거하는 것이 중요합니다.

44장. 품질 문제에는 책임자가 필요하다#

예를 들어:

전화 누락
→ 회원가입팀

주소 코드 오류
→ 주소 연계 시스템 담당

중복 고객
→ 고객 MDM 담당

CRM·쇼핑몰 주소 불일치
→ 데이터 소유자 검토

처럼 책임이 다를 수 있습니다.

품질 대시보드만 만들고 수정 책임이 없다면 지표는 계속 쌓이기만 합니다.

45장. 품질 규칙마다 실패 행을 추적해야 한다#

품질 보고서에:

전화 완전성
80%

만 저장하면 어떤 고객이 문제인지 알 수 없습니다.

다음처럼 실패 행도 관리할 수 있습니다.

rule_id
Q-PHONE-01

customer_id
M-2

detected_at
2026-09-26

status
OPEN

이렇게 하면 실제 수정 업무로 연결할 수 있습니다.

46장. 품질 오류도 상태를 가질 수 있다#

예:

OPEN

IN_REVIEW

CORRECTED

ACCEPTED_EXCEPTION

FALSE_POSITIVE

모든 규칙 위반을 반드시 자동 수정하는 것은 아닙니다.

업무적으로 허용되는 예외도 있을 수 있습니다.

47장. 예외를 분모에서 몰래 제거하면 안 된다#

전화번호를 법적으로 수집하지 않는 고객이 있다고 하겠습니다.

이 고객은 업무적으로 전화가 필요하지 않습니다.

그렇다면 처음부터 대상 정의에서:

전화 필수 고객

에 포함하지 않는 것이 좋습니다.

점수가 낮다고 나중에 실패 행만 임의로 분모에서 빼면 지표 조작처럼 보일 수 있습니다.

48장. ‘해당 없음’을 누락과 구분해야 한다#

고객 100명 중:

국내 배송 대상
80명

해외 전용 고객
20명

이라고 하겠습니다.

국내 우편번호는 국내 배송 대상에게만 필요합니다.

80명 중 72명에게 우편번호가 있습니다.

완전성은:

72 / 80
=
90%

입니다.

전체 100명을 분모로 사용해:

72%

라고 하면 해당 없음 20명까지 오류로 계산한 것입니다.

49장. 대상 집합이 바뀌면 전후 비교도 조심해야 한다#

처음:

대상
80명

완전
72명

90%

이었습니다.

나중에 해외 고객으로 잘못 분류된 두 명을 국내 대상으로 수정했습니다.

새 대상:

82명

두 고객에게 우편번호도 입력했습니다.

완전:

74명

새 완전성:

74 / 82
≈ 90.24%

입니다.

50장. 0.24%만 좋아졌다고 해석하면 틀릴 수 있다#

실제로는 오류 두 건을 수정했습니다.

하지만 분모도:

80
→
82

로 바뀌었습니다.

따라서 단순 퍼센트 변화만 보고:

개선 효과 거의 없음

이라고 판단하면 대상 정의 변경을 놓칩니다.

수치와 함께 분자·분모도 저장하는 이유입니다.

51장. 비율만 저장하지 말고 원시 건수를 함께 저장하자#

다음처럼 저장하는 것이 좋습니다.

eligible_count = 82

success_count = 74

failure_count = 8

score = 90.24%

퍼센트만:

90.24%

저장하는 것보다 훨씬 많은 정보를 제공합니다.

52장. 데이터 품질 이력에는 규칙 버전도 함께 있어야 한다#

예:

일자	규칙	버전	대상	성공	품질
9/25	Q-ZIP-01	v1	80	72	90%
9/26	Q-ZIP-01	v2	82	74	90.24%

이렇게 보면 규칙 변경 여부를 확인할 수 있습니다.

53장. 품질 점수는 데이터 양이 적으면 크게 흔들릴 수 있다#

대상 고객이 5명인 이번 예제에서는 한 명만 바뀌어도:

20%p

가 변합니다.

반면 대상이 100만 명이면 한 건 수정으로는 거의 변하지 않습니다.

따라서 비율뿐 아니라 표본 크기와 건수를 함께 봐야 합니다.

54장. 표본 검사라면 모집단과 표본을 구분해야 한다#

전체 고객:

100만 명

중 전화 정확성을 실제 확인한 고객:

1,000명

이라고 하겠습니다.

960명이 맞았다면 표본 정확도는:

96%

입니다.

이를:

전체 고객 중 96만 명이 정확하다

라고 확정해서는 안 됩니다.

표본 추정에는 표본 추출 방식과 불확실성이 존재합니다.

55장. 품질 규칙도 중요도에 따라 우선순위를 나눌 수 있다#

예:

Critical#

결제 고객 ID 누락

주문 금액 음수

High#

배송 주소 누락

전화번호 형식 오류

Medium#

마케팅 선호값 누락

모든 오류를 같은 심각도로 처리할 필요는 없습니다.

56장. 데이터 품질 문제는 서비스 영향과 연결해 우선순위를 정할 수 있다#

예:

품질 오류	오류 건수	업무 영향
배송 주소 누락	20	배송 불가
전화 형식 오류	200	연락 실패 가능
마케팅 성별 누락	5,000	일부 분석 제한

단순 오류 수가 많은 문제부터 해결하는 것이 항상 최선은 아닙니다.

배송 주소 누락 20건이 더 긴급할 수 있습니다.

57장. 품질 측정에서 NULL을 0이나 빈 문자열로 치환하면 의미가 바뀔 수 있다#

분석 편의를 위해:

COALESCE(phone, '000-0000-0000')

을 사용했다고 하겠습니다.

이 값을 품질 검사 데이터에 다시 저장하면 누락이 사라진 것처럼 보일 수 있습니다.

하지만 실제로는:

NULL
→ 모름

000-0000-0000
→ 존재하는 문자열

로 의미가 바뀐 것입니다.

표시용 치환과 원본 품질 상태를 분리해야 합니다.

58장. 유효성 규칙이 잘못되면 정상 데이터까지 오류가 된다#

형식 규칙:

010-####-####

만 허용했다고 하겠습니다.

그런데 업무에서는 국제전화도 허용합니다.

+82-10-1234-5678

정상적인 번호인데 현재 규칙에서는 실패합니다.

이런 경우는 데이터 오류가 아니라 품질 규칙 오류입니다.

59장. 품질 규칙 자체도 검증 대상이다#

따라서 품질 운영에서는:

False Positive

False Negative

도 볼 수 있습니다.

False Positive#

정상 데이터인데 오류라고 탐지.

False Negative#

실제 오류인데 규칙을 통과.

규칙을 만든다고 데이터 품질 문제가 완전히 자동화되는 것은 아닙니다.

60장. 데이터 품질 전체 운영 흐름을 그려보면#

flowchart TD
    A["대상 데이터 정의"] --> B["품질 규칙 정의"]
    B --> C["프로파일링·측정"]
    C --> D["실패 행 식별"]
    D --> E["원인 분석"]
    E --> F["원천 시스템 수정"]
    F --> G["기존 데이터 정정"]
    G --> H["같은 기준으로 재측정"]
    H --> I["업무 KPI 확인"]

중요한 것은 마지막까지 가는 것입니다.

61장. 정제만 하고 원인을 고치지 않으면 품질 부채가 쌓인다#

매일 오류 1,000건을 정제합니다.

하지만 매일 새 오류도 1,000건 들어옵니다.

오류 발생
1,000

오류 수정
1,000

대시보드는 좋아 보일 수 있지만 근본 원인은 그대로입니다.

좋은 품질 관리에서는:

오류 유입률

자체를 낮춰야 합니다.

62장. 품질 지표와 업무 지표를 함께 기록하면 의미가 커진다#

예:

시점	전화 완전성	형식 유효성	배송 연락 성공률
개선 전	80%	75%	68%
개선 후	98%	97%	94%

이런 결과가 나온다면 데이터 품질 개선이 실제 업무 성과와 연결됐다고 설명하기 쉽습니다.

63장. 데이터 품질 대시보드에 최소한 표시할 것#

각 지표마다 다음 정보를 함께 표시하면 좋습니다.

규칙 ID

규칙 설명

기준일

대상 조건

분모

성공 건수

실패 건수

점수

규칙 버전

담당자

최근 개선 시각

점수 하나보다 운영에 훨씬 유용합니다.

64장. 데이터 품질 체크리스트#

품질 대상 데이터는 무엇인가?
업무적으로 필수인 필드는 무엇인가?
완전성의 분모는 누구인가?
NULL·빈 문자열·공백을 어떻게 처리하는가?
유효성 규칙은 실제 허용값을 반영하는가?
정확성을 판단할 외부 기준이 있는가?
동일 값과 동일 실체를 구분하는가?
중복 후보와 확정 중복을 구분하는가?
최신성과 정확성을 혼동하지 않는가?
비교 시스템의 필드 의미가 정말 같은가?
규칙 버전을 기록하는가?
대상 조건 변경을 기록하는가?
비율과 함께 분자·분모를 저장하는가?
실패 행을 추적할 수 있는가?
오류의 원천 시스템을 고치는가?
정제 후 같은 오류가 다시 들어오는지 측정하는가?
업무 KPI도 함께 개선됐는가?
개인정보가 품질 대시보드에 과도하게 노출되지 않는가?
예외와 오류를 구분하는가?
측정 불가능한 품질 차원을 억지로 숫자로 만들지 않는가?

65장. 핵심 정리#

데이터 품질을 제대로 측정하려면 가장 먼저 해야 할 일은 점수를 계산하는 것이 아닙니다.

무엇을 검사하고, 누구를 분모로 삼을 것인가?

를 정하는 것입니다.

이번 고객 다섯 명 예제에서는:

전화 필수 대상
5명

을 분모로 사용했습니다.

전화번호가 있는 고객은 네 명이므로:

완전성
=
4 / 5
=
80%

입니다.

입력된 전화 네 건 중 형식 규칙을 만족하는 값은 세 건이므로:

유효성
=
3 / 4
=
75%

입니다.

여기서 중요한 것은 두 지표의 분모가 다르다는 점입니다.

또 형식이 맞는다고 실제 고객의 전화번호라는 뜻은 아닙니다.

완전성
→ 값이 있는가?

유효성
→ 규칙에 맞는가?

정확성
→ 실제 사실과 맞는가?

세 질문은 서로 다릅니다.

M-3과 M-4의 전화번호가 같다고 해서 실제 같은 고객이라고 확정할 수도 없습니다.

따라서:

동일 전화
→ 중복 후보

확인된 동일인
→ 실제 중복

으로 분리해야 합니다.

품질 개선에서는 지표 하나만 올리는 것도 위험합니다.

abc라는 형식 오류를 NULL로 바꾸면:

유효성
75%
→
100%

이 되지만:

완전성
80%
→
60%

으로 떨어집니다.

실제로 연락 가능한 고객 수가 늘어난 것도 아닙니다.

반대로 임시 전화번호를 채우면 완전성과 형식 유효성은 올라가지만 정확성은 여전히 낮을 수 있습니다.

그래서 데이터 품질에서 가장 중요한 원칙은:

점수를 높이는 것과 실제 업무에서 사용할 수 있는 데이터를 만드는 것을 구분하는 것입니다.

좋은 품질 지표는 단순히:

98%

라고 표시하지 않습니다.

대상 10만 명

성공 9만8천 명

실패 2천 명

규칙 Q-PHONE-01 v3

기준일 2026-10-01

처럼 측정 조건을 함께 설명할 수 있어야 합니다.

그리고 마지막에는 반드시 실제 업무 결과를 확인해야 합니다.

완전성과 유효성이 올라간 뒤 실제 고객 연락 성공률도 좋아졌는가?

이 질문까지 답할 수 있어야 데이터 품질 관리가 단순한 점수 관리가 아니라 실제 서비스 품질 개선으로 이어집니다.

데이터 품질 지표 계산: 고객 정보의 완전성·유효성·정확성 구분

1장. 빈칸은 줄었는데 왜 고객에게 연락할 수 없을까#

2장. 데이터 품질을 하나의 점수로 표현하면 원인이 사라진다#

3장. 대표적인 데이터 품질 차원#

4장. 실습용 고객 다섯 명을 준비하자#

5장. 측정 전에 대상 집합부터 고정해야 한다#

6장. 완전성은 필요한 값이 있는지를 본다#

7장. 완전성이 80%라는 말은 번호가 맞다는 뜻이 아니다#

8장. 빈 문자열도 누락으로 처리해야 할 수 있다#

9장. 유효성은 정해진 규칙을 만족하는지 본다#

10장. 완전성과 유효성의 분모가 다르다#

11장. “전체 고객 중 유효한 전화 보유 비율”도 별도로 계산할 수 있다#

12장. 세 숫자를 나란히 보면 문제 위치가 보인다#

13장. 정확성은 형식 검사만으로 판단할 수 없다#

14장. 정확성을 측정하려면 외부의 신뢰 가능한 근거가 필요하다#

15장. 현재 다섯 행만으로는 정확성을 계산할 수 없다#

16장. 모른다는 상태도 품질 측정의 일부다#

17장. 유일성은 단순히 기본키 중복이 없는지를 뜻하지 않을 수 있다#

18장. 키 유일성과 실체 유일성을 분리해야 한다#

키 유일성#

실체 유일성#

19장. 같은 전화번호 두 건을 바로 중복 고객 두 건이라고 세면 안 된다#

20장. 중복 탐지 결과도 단계별로 보고하는 것이 좋다#

21장. 적시성은 얼마나 최근에 확인됐는지를 본다#

22장. 적시성을 계산해 보면#

23장. 최신 정보와 정확한 정보도 서로 다르다#

24장. 일관성은 비교 가능한 시스템 간의 값이 맞는지를 본다#

25장. 값이 다르다고 무조건 오류인 것도 아니다#

26장. 여섯 차원을 현재 예제에 적용하면#

27장. 프로파일링은 품질 문제를 찾는 출발점이다#

28장. 프로파일링은 오류 판정 그 자체가 아니다#

29장. 품질 규칙은 이름만 붙이는 것이 아니라 계약처럼 정의해야 한다#

30장. 규칙 버전을 남겨야 지표 변화를 설명할 수 있다#

31장. 분모 변경도 반드시 기록해야 한다#

32장. SQL로 완전성과 유효성을 직접 계산해 보자#

33장. 누락 여부를 먼저 계산한다#

34장. 형식 유효성도 별도 계산한다#

35장. 두 지표를 한 번에 계산하면#

36장. NULLIF는 0으로 나누는 오류를 방지한다#

37장. 형식 오류를 NULL로 바꾸면 어떤 일이 생길까#

38장. 유효성은 100%가 됐지만 완전성은 떨어졌다#

39장. 품질 지표 하나만 최적화하면 실제 서비스는 더 나빠질 수 있다#

40장. 임시값으로 채우면 반대 착시가 발생한다#

41장. 실제 업무 KPI와 데이터 품질 KPI를 연결해야 한다#

42장. 데이터 품질 개선은 정제 작업에서 끝나지 않는다#

43장. 좋은 품질 개선은 오류 발생 지점을 수정한다#

44장. 품질 문제에는 책임자가 필요하다#

45장. 품질 규칙마다 실패 행을 추적해야 한다#

46장. 품질 오류도 상태를 가질 수 있다#

47장. 예외를 분모에서 몰래 제거하면 안 된다#

48장. ‘해당 없음’을 누락과 구분해야 한다#

49장. 대상 집합이 바뀌면 전후 비교도 조심해야 한다#

50장. 0.24%만 좋아졌다고 해석하면 틀릴 수 있다#

51장. 비율만 저장하지 말고 원시 건수를 함께 저장하자#

52장. 데이터 품질 이력에는 규칙 버전도 함께 있어야 한다#

53장. 품질 점수는 데이터 양이 적으면 크게 흔들릴 수 있다#

54장. 표본 검사라면 모집단과 표본을 구분해야 한다#

55장. 품질 규칙도 중요도에 따라 우선순위를 나눌 수 있다#

Critical#

High#

Medium#

56장. 데이터 품질 문제는 서비스 영향과 연결해 우선순위를 정할 수 있다#

57장. 품질 측정에서 NULL을 0이나 빈 문자열로 치환하면 의미가 바뀔 수 있다#

58장. 유효성 규칙이 잘못되면 정상 데이터까지 오류가 된다#

59장. 품질 규칙 자체도 검증 대상이다#

False Positive#

False Negative#

60장. 데이터 품질 전체 운영 흐름을 그려보면#

61장. 정제만 하고 원인을 고치지 않으면 품질 부채가 쌓인다#

62장. 품질 지표와 업무 지표를 함께 기록하면 의미가 커진다#

63장. 데이터 품질 대시보드에 최소한 표시할 것#

64장. 데이터 품질 체크리스트#

65장. 핵심 정리#

이 페이지의 목차