일반 데이터·BI 데이터·AI 데이터의 차이: 같은 원천, 다른 준비 기준
일반 운영 데이터, BI 데이터, AI 데이터가 각각 무엇을 최적화하며 어떤 추가 증거가 필요한지 구분할 수 있다.
같은 원천, 다른 준비 기준
같은 주문 테이블도 운영 화면, 매출 대시보드, 수요예측 모델에 그대로 복사해 쓰면 안 된다. 세 소비자는 서로 다른 질문, 시간 기준, 실패 비용을 갖기 때문이다. 차이는 파일 형식보다 사용 목적과 검증 계약에 있다.
BI 데이터(Business Intelligence data)는 이미 일어난 일을 일관된 지표로 설명하기 위해 다시 설계한 데이터다. 보고서마다 매출 정의가 달라지지 않도록 측정값, 차원, 집계 단위와 기준시각을 고정한다. Microsoft의 Power BI 지침은 필터·그룹화용 차원 테이블과 요약용 사실 테이블, 그리고 일관된 그레인(grain: 사실 한 행이 나타내는 업무 단위)을 강조한다. [S2]
AI 데이터는 모델이 패턴을 학습하거나 검색·생성 과정에서 근거로 사용할 수 있게 준비한 데이터다. 예측 AI에는 입력 특징, 정답 라벨, 학습·검증·테스트 분할과 예측 시점 가용성이 필요하다. 생성형 AI의 RAG에는 문서 구조, 시행일, 권한, 출처, 검색 가능한 조각과 질문-근거-답변 평가셋이 필요하다. ISO/IEC 5259-1도 분석과 ML 데이터 품질을 생애주기와 의도한 목적에 연결한다. [S3]
핵심: 원천이 같아도 운영은 '현재 거래의 진실', BI는 '반복 가능한 집계', AI는 '미래·생성 행동의 검증 가능성'을 우선한다.
세 데이터가 최적화하는 것
| 비교 축 | 일반·운영 | BI | AI |
|---|---|---|---|
| 주된 질문 | 업무가 지금 올바르게 처리되는가 | 무슨 일이 얼마나 일어났는가 | 다음 입력에서 무엇을 예측·검색·생성할 것인가 |
| 핵심 단위 | 거래·이벤트·현재 상태 | 일관된 사실 그레인과 차원 | 예제·특징·라벨·문서 조각·평가 사례 |
| 시간 기준 | 발생·처리·변경 시각 | KPI 귀속일·새로고침 시점 | 관측 가능 시점·분할 시점·서빙 시점 |
| 품질 초점 | 무결성·최신성·복구 | 정의 일관성·집계·비교성 | 대표성·누수·스큐·근거성·재현성 |
| 변경 대응 | 트랜잭션·감사 로그 | 지표 계약·증분 적재 | 버전·드리프트·재학습/재색인·재평가 |
AI 데이터는 집계 정합성에 더해 누수 방지, 대표성, 라벨 정의, 시간 분할, 버전 재현성과 운영 입력 일치가 필요하다. Google은 학습-서빙 스큐(training-serving skew)를 학습과 실제 예측 단계의 데이터 처리·분포 차이로 설명하며, 서빙 시 사용한 특징을 기록하고 학습과 서빙 코드를 가능한 한 공유하며 미래 시점 데이터로 평가하라고 권고한다. [S4] 입력 오류가 파이프라인을 멈추지 않고 모델 품질만 조용히 훼손할 수 있어 ML 전용 데이터 검증이 필요하다는 프로덕션 연구도 있다. [S5]
주문 한 건이 세 갈래로 변한다
가상의 다온커머스에서 주문 1001이 8월 1일 생성되고 8월 3일 취소됐다고 하자. 운영 데이터에는 주문·결제·취소 이벤트와 처리 주체, 시각, 이전·현재 상태가 모두 남는다. 이 기록은 고객 환불과 재고 복구를 재현하는 데 필요하다. 여기서 수치는 설명용 가정이며 실제 기업 통계가 아니다.
BI에서는 같은 주문을 '8월 1일 총주문'과 '8월 3일 취소'로 각각 보여주거나, 확정 순매출에서 제외할 수 있다. 어느 쪽이 맞는지는 대시보드의 질문과 KPI 정의에 달려 있다. 사실 테이블의 그레인, 취소 반영 규칙, 시간대, 지연 도착 데이터 수정 정책이 고정돼야 지난달 보고서를 다시 열어도 같은 설명을 할 수 있다.
수요예측 AI에서는 8월 1일 예측 시점에 알 수 없던 8월 3일 취소 여부를 입력 특징에 넣으면 데이터 누수가 된다. 당시 알 수 있었던 주문 상태만 시점 스냅숏으로 만들고, 취소는 미래에 확정되는 라벨이나 별도 결과로 취급해야 한다. 고객센터 RAG라면 주문행 자체보다 환불 정책 문서의 시행일·접근권한·인용 가능한 근거가 중요하다. NIST는 AI 과업을 분류하고 데이터의 가용성·대표성·적합성을 문서화하며 배치 환경과 유사한 조건에서 평가하도록 권고한다. [S6] 생성형 AI 프로필은 RAG 데이터의 출처와 근거성을 확인하고 출처·인용을 지속 검증하도록 제안한다. [S7]
전문가 판단: '같은 행을 세 곳에 복사'하는 대신 원천 이벤트는 보존하고, BI 의미 모델과 AI 시점 데이터셋을 별도 계약으로 파생해야 한다.
BI가 통과해도 AI에서 실패하는 경계
집계 ≠ 예측
월매출이 정확해도 미래 정보가 섞이면 모델 평가는 과대평가된다.
평균 ≠ 대표성
전체 추세가 안정적이어도 희귀 상품·신규 매장에는 실패할 수 있다.
최신성 ≠ 서빙 일치
BI가 최신이어도 온라인 특징 계산이 다르면 학습-서빙 스큐가 생긴다.
가독성 ≠ 근거성
문서가 읽혀도 시행일·권한·인용·평가셋이 없으면 RAG 품질을 증명하기 어렵다.
따라서 BI 데이터웨어하우스를 버리고 AI 전용 저장소를 새로 만들 필요도, 반대로 BI 골드 테이블을 그대로 학습 데이터로 선언할 이유도 없다. 공통 원천·계보·권한을 재사용하되 소비 목적별 스키마, 시간 규칙, 품질 임계값, 버전과 실패 행동을 따로 둔다. 공유할 것은 진실과 통제이고, 분리할 것은 해석과 검증 계약이다.
데이터셋 이름 앞에 붙일 여덟 질문
데이터셋을 'sales_final_v7'처럼 결과물 이름만으로 승인하지 말자. 아래 질문을 한 장에 답하면 운영용, BI용, 예측 AI용, RAG용 가운데 무엇을 만들고 있는지 드러난다. 답을 쓰지 못한 항목은 단순 문서 누락이 아니라 다음 설계·검증 작업이다.
- 소비자누가 이 데이터를 읽거나 변경하는가?
- 결정어떤 업무 판단·대시보드·모델 행동에 연결되는가?
- 그레인한 행·한 문서 조각·한 예제가 무엇을 뜻하는가?
- 시간발생·처리·집계·예측 시점 중 무엇이 기준인가?
- 정답/근거라벨 또는 인용 근거를 누가 어떤 규칙으로 확정하는가?
- 권한목적별 사용·공유·보존·삭제 범위는 무엇인가?
- 검증집계 정합성, 슬라이스 성능, 검색·답변 품질을 어떻게 재는가?
- 변경스키마·분포·정책이 바뀌면 누가 멈추고 다시 승인하는가?
판정 규칙: 데이터 이름이 아니라 소비자·결정·시점·실패 조건·증거를 함께 승인한다.
마무리와 다음 회차
일반 데이터, BI 데이터, AI 데이터는 서로 우열이 있는 단계가 아니다. 같은 원천을 서로 다른 소비 목적에 맞게 투영한 데이터 제품이다. 운영 데이터가 거래의 진실을 지키고, BI 데이터가 공통 언어를 만들며, AI 데이터가 미래 행동과 생성 결과를 검증할 수 있게 해야 한다. 다음 03회차에서는 데이터 목록을 보기 전에 AI 사용 목적·의사결정·오류 비용을 먼저 정해야 하는 이유를 다룬다.
다음 03회차: 데이터보다 AI 사용 목적을 먼저 정해야 하는 이유 · 2026년 8월 14일
출처 및 읽을거리
확인 기준일: 2026-08-12 KST
- [S1] Microsoft Learn - Use SQL database as an operational data store
Locator: What is an ODS?; Key characteristics of an ODS · 확인일: 2026-08-12 · 제한: Microsoft Fabric의 ODS 구현 지침이다. 여기서 '일반 데이터'는 표준 분류명이 아니라 비교를 위해 운영·원천 데이터로 한정한 저자 정의다. - [S2] Microsoft Learn - Understand star schema and the importance for Power BI
Locator: Star schema relevance to Power BI semantic models; lines 63-74 · 확인일: 2026-08-12 · 제한: Power BI 중심의 제품 지침이며 모든 BI 플랫폼에 강제되는 표준은 아니다. - [S3] ISO - ISO/IEC 5259-1:2024 - Data quality for analytics and machine learning - Part 1
Locator: Overview; What is ISO/IEC 5259-1?; Why is it important? · 확인일: 2026-08-12 · 제한: 공개 소개 페이지만 확인했으며 유료 표준 전문의 세부 조항은 재현하지 않았다. - [S4] Google for Developers - Rules of Machine Learning
Locator: Training-Serving Skew; Rules 29-33 · 확인일: 2026-08-12 · 제한: Google의 경험 기반 ML 엔지니어링 권고이며 규범 표준이나 법적 의무가 아니다. - [S5] Google Research - Data Validation for Machine Learning
Locator: Abstract; production data validation and training/serving skew · 확인일: 2026-08-12 · 제한: Google의 프로덕션 ML 사례를 다룬 2019년 연구다. 규모와 효과를 모든 조직에 일반화하지 않았다. - [S6] NIST - AI Risk Management Framework 1.0 - AI RMF Core
Locator: MAP 2.1-2.3; MEASURE 2.1, 2.3-2.5 · 확인일: 2026-08-12 · 제한: 자발적 프레임워크이며 AI RMF 1.0 개정이 진행 중이다. - [S7] NIST - Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile
Locator: MP-1.1-001 (p.25); MS-2.3-001 and MS-2.5-002-005 (pp.33-34) · 확인일: 2026-08-12 · 제한: NIST AI RMF의 생성형 AI용 자발적 보완 프로필이며 법적 의무가 아니다.
'스페셜 브리핑 > AI-Ready Data' 카테고리의 다른 글
| AI 데이터 생애주기: 수집부터 폐기까지 신뢰와 사용권을 지키는 법 (0) | 2026.08.19 |
|---|---|
| 정형·반정형·비정형·멀티모달: AI가 놓치기 쉬운 의미의 경계 (0) | 2026.08.17 |
| 데이터보다 AI 사용 목적을 먼저: 오류 비용에서 데이터 요구사항을 역산하는 법 (0) | 2026.08.14 |
| AI Ready Data란 무엇인가: 깨끗함을 넘어 목적·근거·운영까지 (0) | 2026.08.10 |
| AI Daily Special 예고|AI Ready Data 완전정복, 36회 연재를 시작합니다 (0) | 2026.08.05 |