데이터 기반과 거버넌스
AI 과제의 일정표를 열어 보면 "데이터 정리"가 가장 길고, 가장 자주 늘어난다. 측정값 칸의 "N/A", "-", "재측정", 같은 LOT가 두 번 적재된 행, µm와 mm가 섞인 두께 열. 이 장은 공장 데이터를 AI가 먹을 수 있는 상태로 만드는 기술(품질 차원, 파이프라인, 아키텍처)과, 그 상태를 유지하는 사람의 체계(오너, 스튜어드, 데이터 계약)를 함께 다룬다.
- 데이터 품질 6차원(완전성·정확성·일관성·적시성·유일성·유효성)으로 실제 테이블의 문제를 진단하고 점수화할 수 있다.
- 데이터 오너·스튜어드·커스터디언의 역할과 데이터 계약, 리니지, 카탈로그가 왜 필요한지 설명할 수 있다.
- 데이터 레이크·웨어하우스·레이크하우스, 메달리온(브론즈·실버·골드) 계층, 데이터 메시의 차이와 쓰임을 구분할 수 있다.
- 라벨 오류가 AI 모델 성능에 미치는 영향을 이해하고, "AI-ready data" 체크리스트로 우리 데이터를 점검할 수 있다.
AI가 먹을 수 없는 데이터
A사(글로벌 전자부품 제조사)의 도금 공정에서 "두께 불량 예측" 파일럿을 시작했다. 데이터 과학자는 첫 주에 MES 측정 이력, 검사 장비 결과, 생산팀 일보 엑셀을 받았다. 그리고 다음과 같은 것을 발견했다.
L2-0412 | 3/4 | 11.8 | OK |
L2-0413 | 3/4 | N/A | OK | 재측정 예정
L2-0414 | 3/4 | 0.0131 | OK | 측정기 교체
L2-0414 | 3/4 | 13.1 | NG | 재검
a2603l20415 | 04/03 | 12.7 | OK | 해외 법인 양식
여섯 줄 안에 거의 모든 종류의 문제가 들어 있다. 두께 칸의 "N/A"는 측정을 안 했다는 뜻인지, 장비가 고장 났다는 뜻인지, 나중에 채울 예정이라는 뜻인지 알 수 없다(완전성). 0.0131은 mm로 적은 값이라 µm 기준으로 보면 1000배 작다(정확성). 같은 LOT가 두 번 있고 판정이 다르다(유일성·일관성). 날짜 "04/03"은 4월 3일인지 3월 4일인지 모르고, LOT ID 형식도 다르다(유효성). 그리고 이 파일은 월말에 한꺼번에 공유되었다(적시성).
사람은 이 표를 보고 "아, 측정기 교체해서 mm로 적었구나" 하고 넘어간다. 모델은 넘어가지 못한다. 0.0131을 진짜 두께로 학습하거나, 결측 행을 통째로 버려서 하필 문제가 있던 LOT들을 학습에서 빼 버린다. 데이터 정리 작업이 AI 과제의 가장 큰 덩어리가 되는 이유다. 그리고 그 정리를 매번 사람이 손으로 하면, 다음 과제에서 또 처음부터 다시 해야 한다.
데이터 정리를 "과제 시작 전에 한 번 하는 청소"로 보면 끝이 없다. 이 장은 정리를 파이프라인(자동화된 규칙)과 책임 체계(누가 품질을 보증하는가)로 바꾸는 방법을 다룬다. 앞 장(4장)의 용어·코드·단위 규칙이 여기서 검증 규칙으로 구현된다.
데이터 품질의 6차원
"데이터 품질이 나쁘다"는 말은 너무 넓어서 고칠 수가 없다. 품질을 나눠서 재야 개선 대상이 보인다. 데이터 관리 지식 체계인 DAMA-DMBOK(DAMA International의 Data Management Body of Knowledge)은 여러 품질 차원을 정리하고 있고, 실무에서는 다음 여섯 가지가 가장 널리 쓰인다. 데이터 품질에 관한 국제표준으로는 ISO 8000 시리즈가 있으며, 특히 기준정보(마스터 데이터)의 품질과 교환에 관한 부분이 제조·조달 분야에서 참고된다.
| 차원 | 질문 | 공장에서 보이는 모습 | 측정 규칙 예 |
|---|---|---|---|
| 완전성 Completeness | 있어야 할 값이 있는가? | 두께 칸 "N/A", 설비 ID 빈칸, 야간조 기록 누락 | 필수 열의 비결측 비율 |
| 정확성 Accuracy | 값이 현실과 맞는가? | mm로 적은 µm 값, 소수점 오타, 교정 안 된 계측기 | 물리적 허용 범위·기준값 대비 검사 |
| 일관성 Consistency | 값끼리, 시스템끼리 모순이 없는가? | 두께는 규격 안인데 판정 NG, MES와 ERP 수량 불일치 | 교차 검증 규칙 통과 비율 |
| 적시성 Timeliness | 필요할 때 쓸 수 있는가? | 월말에 몰아 입력하는 일보, 하루 늦은 검사 결과 | 발생–적재 지연이 기준(예: 24시간) 이내인 비율 |
| 유일성 Uniqueness | 같은 것이 두 번 있지 않은가? | 재전송으로 중복된 LOT 행, 같은 고객의 레코드 3개 | 고유 키 수 ÷ 전체 행 수 |
| 유효성 Validity | 정해진 형식·코드를 따르는가? | a2603l20415, "04/03", 코드 목록에 없는 불량명 | 형식(정규식)·허용 코드 검사 통과 비율 |
차원별 점수는 보통 "규칙을 통과한 비율"로 계산한다. 예를 들어 완전성은 다음과 같다.
데이터 품질 스코어카드 — 오류를 주입해 보자
품질은 사람이 책임진다: 오너·스튜어드·커스터디언
품질 규칙을 만들고 대시보드로 점수를 띄워도, 점수가 떨어졌을 때 누가 고치는지가 정해져 있지 않으면 아무 일도 일어나지 않는다. 흔한 실패는 데이터 품질을 IT 부서의 일로 넘기는 것이다. IT는 "두께 0.0131이 틀렸다"는 것을 알 수 없다. 그것을 아는 사람은 도금 공정 엔지니어다.
| 역할 | 누가 (예) | 책임 | 도금 두께 데이터에서 |
|---|---|---|---|
| 데이터 오너 Data Owner | 해당 업무의 부서장·파트장 | 데이터의 의미·품질 기준·접근 권한을 최종 결정하고 책임진다 | 도금 파트장: "두께는 µm, 허용 범위 5~30, 측정 누락 시 출하 보류" |
| 데이터 스튜어드 Data Steward | 업무를 잘 아는 실무 엔지니어 | 정의·규칙을 일상적으로 관리하고, 품질 이슈를 분류·추적한다 | 공정 엔지니어: 규칙 위반 알림을 보고 원인 확인, 코드 추가 요청 처리 |
| 데이터 커스터디언 Data Custodian | IT·데이터 엔지니어 | 저장·적재·백업·보안·파이프라인을 기술적으로 운영한다 | 데이터 엔지니어: 검증 규칙 구현, 적재 지연 모니터링, 접근 통제 적용 |
| 데이터 소비자 Data Consumer | 분석가, AI 과제팀, 타 부서 | 정의에 맞게 쓰고, 이상을 발견하면 신고한다 | AI 과제팀: 학습 데이터 이상 발견 시 스튜어드에게 이슈 등록 |
오너를 부서장으로 지정하면 바빠서 아무것도 못 한다는 반론이 나온다. 오너의 일은 규칙을 직접 만드는 것이 아니라 스튜어드가 올린 결정을 승인하고, 품질 문제를 자기 부서의 성과 문제로 받아들이는 것이다. 분기에 한 번, 핵심 데이터 요소의 품질 점수를 부서 KPI 회의에서 보는 것만으로도 행동이 달라진다.
데이터 계약, 리니지, 카탈로그
월요일 아침, 품질 대시보드의 불량률이 0%로 떴다. 원인을 추적해 보니 지난 금요일 MES 업그레이드 때 검사 결과 테이블의 열 이름이 DEF_CD에서 DEFECT_CODE로 바뀌었고, 대시보드 쿼리는 빈 값을 0으로 처리하고 있었다. 이 변경은 MES 담당자에게는 사소한 정리였지만, 그 열에 기대던 대시보드 3개와 AI 모델 하나를 조용히 망가뜨렸다.
리니지(data lineage)는 데이터가 어디서 와서 어떤 변환을 거쳐 어디로 가는지의 계보다. 데이터 카탈로그(data catalog)는 회사에 어떤 데이터가 있고, 무슨 뜻이며, 누가 오너이고, 품질은 어떤지, 어떻게 접근하는지를 찾아볼 수 있는 목록이다. 둘이 있으면 "그 데이터 어디 있어요?"라는 메일과 "이거 바꿔도 돼요?"라는 회의가 줄어든다.
데이터 계약(data contract)은 데이터를 만드는 쪽(생산자)과 쓰는 쪽(소비자) 사이의 명시적 약속이다. 스키마(열 이름·형식), 의미(단위·코드 체계), 품질 기준, 제공 주기, 그리고 변경 시 사전 통지 절차를 적는다. 법적 계약서가 아니라 기계가 검사할 수 있는 형식(YAML 등)으로 쓰고, 파이프라인이 매번 자동으로 검증하는 것이 요점이다.
모든 테이블에 계약을 쓰려 하지 말고, AI 모델이나 경영 보고에 쓰이는 핵심 데이터 요소(CDE, Critical Data Element) 20~30개부터 시작한다. 계약에 적힌 규칙은 곧바로 위의 스코어카드 같은 품질 점검의 입력이 된다.
레이크·웨어하우스·레이크하우스와 메달리온 계층
데이터를 어디에 어떻게 모으느냐에 대해서는 세 가지 이름이 자주 등장한다. 제품 이름이 아니라 설계 패턴의 이름이라는 점을 기억하자.
데이터 웨어하우스
정제·통합된 정형 데이터를 미리 정한 스키마로 저장. 보고·BI에 강하다. 원본 그대로의 로그·문서·이미지를 담기는 어렵다.
데이터 레이크
원본을 형식에 상관없이 일단 저장(설비 로그, 이미지, 문서). 유연하지만 관리하지 않으면 아무도 못 찾는 "데이터 늪"이 된다.
레이크하우스
레이크의 저렴하고 유연한 저장 위에 웨어하우스의 테이블 관리·트랜잭션·스키마 기능을 얹은 구조. 분석과 AI 학습을 한 곳에서.
어떤 저장 구조를 쓰든, 데이터를 정제 단계에 따라 층으로 나누는 메달리온 아키텍처(medallion architecture)가 실무에서 널리 쓰인다. 브론즈–실버–골드의 세 층이다.
아래 실습에서 세 원천(MES CSV, AOI 검사 장비 내보내기, 생산팀 일보 엑셀)의 실제 같은 행들이 층을 하나씩 올라가며 어떻게 바뀌는지 확인해 보자. 특히 골드 단계에서 "AOI와 수기 기록을 합칠 것인가"라는 질문은 기술이 아니라 업무 규칙이라는 점에 주목하자.
메달리온 파이프라인 단계별 변환
초록 칸은 이전 단계에서 바뀐 값, 빨간 칸은 문제가 있는 원본 값, 취소선은 제거된 행이다.
중앙 집중에서 도메인 소유로: 데이터 메시
전사 데이터 플랫폼 팀이 모든 원천의 정제를 도맡는 구조는 처음에는 빠르지만 곧 병목이 된다. 플랫폼 팀은 도금 두께가 µm인지, 프레스 비가동 사유 코드 17번이 무엇인지 모른다. 요청이 쌓이고, 현업은 기다리다 지쳐 다시 엑셀로 돌아간다.
데이터 메시(data mesh)는 2019년경 Zhamak Dehghani가 제안한 개념으로, 데이터에 대한 책임을 그 데이터를 가장 잘 아는 업무 도메인에 두자는 조직·아키텍처 원칙이다. 흔히 네 가지 원칙으로 요약된다.
도메인 소유
도금 데이터는 도금 파트가, 설비 보전 데이터는 보전 팀이 소유하고 품질을 책임진다.
제품으로서의 데이터
데이터를 남이 쓰기 좋게 만든 "제품"으로 다룬다. 설명서(카탈로그), 품질 약속(계약), 담당자가 있다.
셀프서비스 플랫폼
중앙 팀은 정제를 대신하지 않고, 도메인이 스스로 파이프라인·품질 점검을 만들 수 있는 도구를 제공한다.
연합형 거버넌스
공통 규칙(ID 체계, 보안 등급, 용어 사전, 상호 운용 표준)은 함께 정하고 플랫폼이 자동으로 강제한다.
대기업 제조사에서 순수한 메시를 그대로 적용하는 경우는 드물다. 현실적인 형태는 중앙 플랫폼 + 핵심 도메인 몇 곳의 데이터 제품화다. 품질·보전처럼 AI 과제 수요가 많은 도메인부터 오너와 스튜어드를 세우고, 그 도메인이 자기 골드 테이블을 책임지게 한다. 조직 운영 모델에 대해서는 13장에서 더 다룬다.
데이터 품질이 AI 성능에 미치는 영향
품질 투자를 설득할 때 가장 자주 듣는 질문은 "모델이 좋으면 데이터가 좀 지저분해도 되지 않나?"다. 답은 "어떤 오류냐에 따라 다르다"이다. 특히 지도 학습 모델에서 라벨(정답 표시)의 오류는 직접적인 영향을 준다. 공장에서 라벨 오류는 두 가지 얼굴로 나타난다.
- 무작위 오류: 입력 실수로 양품·불량이 이따금 뒤바뀐다. 방향성이 없어 단순한 모델은 어느 정도 견딘다.
- 체계적 오류: 야간조는 경미한 불량을 기록하지 않거나, 검사 장비가 특정 유형을 놓쳐 불량이 계속 "양품"으로 남는다. 방향성이 있어 모델이 그 편향을 그대로 학습한다. 표면상 정확도는 그럴듯한데 불량을 못 잡는 모델이 된다.
라벨 오류 → 모델 성능 실험
실험이 보여 주는 교훈은 세 가지다. 첫째, 라벨 오류는 데이터 양으로 완전히 상쇄되지 않는다. 특히 체계적 오류는 데이터를 늘려도 편향이 그대로 남는다. 둘째, 복잡한(외우는) 모델일수록 잘못된 라벨까지 외워 무작위 오류에 더 민감하다. 셋째, 정확도 하나만 보면 체계적 오류를 놓친다. 불량 재현율처럼 업무에 의미 있는 지표를 함께 봐야 한다. 이 지표 선택은 11장의 오탐·미탐 비용 논의로 이어진다.
AI-ready data 체크리스트
AI 과제를 시작하기 전에 대상 데이터에 대해 아래 질문에 "예"라고 답할 수 있는지 확인하자. 절반 이상이 "아니오"라면, 모델보다 데이터 기반 작업을 먼저 과제 범위에 넣는 것이 정직한 계획이다.
- 찾을 수 있다: 카탈로그에 있고, 오너·스튜어드가 이름으로 정해져 있다.
- 뜻이 정의되어 있다: 열마다 단위·코드 체계·결측의 의미가 데이터 사전에 있다(4장).
- 품질이 측정된다: 6차원 중 용도에 중요한 차원의 점수와 추세를 볼 수 있다.
- 라벨이 믿을 만하다: 판정 기준이 문서화되어 있고, 검사자 간 일치도를 확인한 적이 있다.
- 연결된다: LOT·설비·품목 ID로 다른 데이터(공정·검사·보전)와 조인할 수 있다.
- 충분한 기간·사례가 있다: 드문 불량·고장의 사례 수가 학습·검증에 쓸 만큼 있다.
- 원본이 보존된다: 브론즈 층에 원본이 있어 규칙이 바뀌면 다시 처리할 수 있다.
- 변경이 통지된다: 상류 스키마·코드 변경이 데이터 계약에 따라 사전 통지된다.
- 접근 권한과 보안 등급이 정해져 있다: 외부 AI 서비스에 보내도 되는지 판단할 수 있다(12장).
- 적시에 들어온다: 모델이 예측해야 하는 시점보다 데이터가 먼저 도착한다.
핵심 정리
- 데이터 품질은 완전성·정확성·일관성·적시성·유일성·유효성의 6차원으로 나눠 "규칙 통과 비율"로 잰다. DAMA-DMBOK과 ISO 8000 시리즈가 참고 틀이다.
- 차원별 점수가 높아도 모든 규칙을 통과하는 행의 비율은 훨씬 낮을 수 있다. 오류는 행 단위로 누적된다.
- 품질의 책임은 IT가 아니라 업무에 있다. 오너는 기준을 결정하고, 스튜어드는 일상 관리하며, 커스터디언은 기술적으로 운영한다.
- 데이터 계약은 스키마·의미·품질·주기·변경 정책을 기계가 검사할 수 있게 적은 약속이다. 리니지와 카탈로그가 있으면 변경 영향을 미리 안다.
- 메달리온 아키텍처: 브론즈는 원본 보존, 실버는 표준화·검증·통합, 골드는 업무 목적별 집계. 골드의 집계 규칙은 업무 오너가 정한다.
- 데이터 메시는 도메인 소유·제품으로서의 데이터·셀프서비스 플랫폼·연합형 거버넌스의 네 원칙이다. 현실에서는 중앙 플랫폼 + 핵심 도메인 제품화로 시작한다.
- 라벨의 체계적 오류는 데이터를 늘려도 사라지지 않고, 정확도보다 불량 재현율을 먼저 무너뜨린다. 업무 지표로 평가해야 한다.
확인 퀴즈
1. MES에서 통신 재시도 때문에 같은 LOT의 측정 행이 두 번 적재되었다. 이 문제가 가장 직접적으로 해치는 품질 차원은?
2. "도금 두께는 µm로 저장하고, 허용 범위는 5~30이며, 측정 누락 시 출하를 보류한다"는 기준을 최종 결정하고 책임지는 역할은?
3. 메달리온 아키텍처의 브론즈 층에 대한 설명으로 옳은 것은?
4. 데이터 계약(data contract)에 들어가기에 가장 거리가 먼 것은?
5. 검사 장비가 특정 유형의 불량을 계속 놓쳐, 불량 일부가 "양품"으로 라벨링된 데이터로 모델을 학습했다. 가장 가능성 높은 결과는?
6. 데이터 메시의 네 가지 원칙에 해당하지 않는 것은?