데이터 유형과 데이터 품질

1. 데이터 분석의 기본 흐름

데이터 분석은 데이터를 많이 모으는 것보다 문제에 맞는 데이터를 신뢰할 수 있는 상태로 준비하고 올바르게 해석하는 과정이 중요하다.

업무 문제 정의
      ↓
데이터 식별·수집
      ↓
품질 확인·전처리
      ↓
탐색·분석·모델링
      ↓
결과 해석·검증
      ↓
의사결정·운영 반영
      ↓
지속 모니터링

잘못된 데이터로 정교한 모델을 만들면 결과도 신뢰하기 어렵다. 이를 흔히 “Garbage In, Garbage Out”이라고 표현한다.

2. 정형·반정형·비정형 데이터

정형
고객ID | 연령 | 가입일
C01    | 32  | 2026-01-02

반정형
{"customerId":"C01", "age":32, "tags":["new","mobile"]}

비정형
상담 녹취, 계약서 PDF, 상품 사진

비정형 데이터도 텍스트 추출, 임베딩, 특징 추출 등을 거쳐 분석 가능한 형태로 변환할 수 있다.

3. 수치형과 범주형 데이터

수치형

• 이산형: 개수를 세어 얻음. 예: 접속 횟수, 장애 건수
• 연속형: 측정하여 얻음. 예: 응답시간, 온도

범주형

• 명목형: 순서가 없는 범주. 예: 부서, 지역, 장애 유형
• 순서형: 순서가 있는 범주. 예: 낮음·중간·높음, 만족도 1~5

숫자로 저장되었다고 모두 수치형은 아니다. 우편번호나 고객등급 코드 1, 2, 3은 산술 연산의 의미가 없으면 범주형으로 봐야 한다.

4. 측정척도

등간척도에서는 차이는 의미가 있지만 비율 해석은 조심해야 한다. 섭씨 20도가 10도의 두 배로 뜨겁다고 말할 수 없다.

5. 모집단과 표본

• 모집단: 관심 대상 전체
• 표본: 모집단에서 관찰한 일부
• 모수: 모집단의 특성값
• 통계량: 표본에서 계산한 값

모집단: 전체 민원 처리 1,000,000건
   │ 확률표본추출
   ▼
표본: 5,000건
   │ 평균·비율 계산
   ▼
모집단의 처리시간·오류율 추정

표본이 크기만 하다고 대표성이 자동 보장되는 것은 아니다. 특정 시간대나 특정 채널만 수집하면 선택편향이 생길 수 있다.

6. 데이터 생명주기

생성·수집
   ↓
저장·정제
   ↓
이용·공유
   ↓
보존·아카이브
   ↓
파기

각 단계에서 다음을 관리한다.

• 소유자와 처리 목적
• 스키마와 메타데이터
• 접근권한과 보안등급
• 품질규칙
• 보유기간
• 계보와 변경이력
• 파기 기준

7. 데이터 품질 차원

데이터 품질은 “오류가 하나도 없다”가 아니라 업무 목적에 맞는 수준으로 측정·관리하는 활동이다.

8. 품질규칙 예시

Q1. 주문금액 >= 0
Q2. 배송완료일 >= 주문일
Q3. 고객ID는 고객 마스터에 존재
Q4. 거래번호는 유일
Q5. 필수 컬럼 NULL 비율 < 0.1%
Q6. 코드값은 표준 코드 목록 안에 존재

SQL 예:

-- 음수 주문금액 탐지
SELECT order_id, amount
FROM orders
WHERE amount < 0;

-- 중복 거래번호 탐지
SELECT transaction_no, COUNT(*)
FROM transactions
GROUP BY transaction_no
HAVING COUNT(*) > 1;

9. 데이터 프로파일링

프로파일링은 데이터의 분포·결측·중복·최솟값·최댓값·고유값 등을 요약해 실제 상태를 파악하는 활동이다.

컬럼: age
행 수: 100,000
NULL: 1,200
최소: -3      ← 오류 의심
최대: 214     ← 오류 의심
고유값: 173
평균: 42.1

도메인 지식 없이 수치만 보고 오류를 확정하면 안 된다. 예를 들어 거래금액 0은 무료 거래일 수도 있고 누락값 대체일 수도 있다.

10. 데이터 품질 개선 과정

품질규칙 정의
    ↓
프로파일링·측정
    ↓
오류 분류
    ↓
원천·업무·연계 원인 확인
    ↓
정정·재처리
    ↓
입력검증·표준·프로세스 개선
    ↓
품질지표 모니터링

분석용 데이터만 임시 수정하고 원천 시스템을 고치지 않으면 오류가 반복된다.

11. 데이터 품질 지표 계산과 판정

품질 차원은 이름만 외우지 말고 분모와 업무 규칙을 먼저 확인해야 한다.

완전성 = 필수값이 존재하는 건수 / 필수값이 요구되는 전체 건수
유효성 = 도메인·형식·범위 규칙을 만족한 건수 / 검사 대상 건수
유일성 = 중복되지 않은 업무 식별자 건수 / 검사 대상 식별자 건수

예를 들어 전체 1,000건 중 필수 대상이 아닌 50건을 제외하고, 필수값이 채워진 건수가 912건이면 완전성은 912/950=96%이다. 단순히 912/1000으로 계산하면 업무상 미적용 건수를 결측으로 잘못 처리한다.

여러 지표를 가중 합산해 품질점수를 만들 수도 있다.

완전성 98%(가중치 0.4), 유효성 95%(0.35), 유일성 99%(0.25)
가중 점수 = 98×0.4 + 95×0.35 + 99×0.25 = 97.2점

12. SQL을 이용한 프로파일링과 무결성 점검

-- 필수값 누락
select count(*)
from customer
where customer_name is null;

-- 업무키 중복
select resident_hash, count(*)
from customer
where resident_hash is not null
group by resident_hash
having count(*) > 1;

-- 참조 무결성 위반
select o.order_id
from orders o
left join customer c on c.customer_id = o.customer_id
where c.customer_id is null;

customer_id처럼 숫자로 저장되어도 덧셈 대상이 아닌 식별자는 범주형으로 다루는 것이 일반적이다. 우편번호·상품코드의 선행 0을 숫자 변환으로 잃는 문제가 발생할 수 있다.

13. 정확성·유효성·일관성의 구분

• 2026-02-30은 날짜 형식처럼 보여도 존재하지 않는 날짜이므로 유효성 위반이다.
• 형식과 범위를 만족한 주소라도 실제 거주지와 다르면 정확성 위반이다.
• 주문 상태가 취소인데 배송완료일이 존재하면 교차 필드 일관성 위반이다.
• 원천 시스템과 분석 마트의 고객 등급이 서로 다르면 시스템 간 일관성 문제일 수 있다.

14. 스키마 변화·계보·품질 개선의 안전성

컬럼 이름이나 타입이 바뀌는 스키마 드리프트는 파이프라인 오류뿐 아니라 지표 의미 변화를 일으킨다. 데이터 계보는 원천→변환→마트→리포트의 연결을 추적하여 변경 영향과 오류 전파 경로를 찾는다.

탐지 → 원인 분류 → 원본 보존 → 정제 규칙 적용 → 재검증 → 변경 이력·책임자 기록

잘못된 값을 무조건 삭제하면 표본 편향이 커질 수 있다. 오류 원인이 특정 고객군·지역·장치에 집중되어 있다면 삭제 후 분석결과가 모집단을 대표하지 못할 수 있으므로, 보정·별도 플래그·재수집 여부를 검토한다.

확인 문제

1. 필수 대상 950건 중 값이 채워진 건수가 912건일 때 완전성은?
2. 숫자로 저장된 고객번호를 일반적으로 범주형으로 보는 이유는?
3. 형식은 맞지만 실제 주소가 틀린 경우 위반 차원은?
4. 주문이 취소인데 배송완료일이 존재하는 오류는?
5. 정제 전에 원본과 계보를 보존해야 하는 이유는?