Finding Isn't Understanding: 데이터 인프라에 돈을 써도 AI가 데이터를 못 믿는 이유

데이터 인프라와 탐색 도구에 돈을 더 써도 AI가 데이터를 믿고 쓰게 되지는 않습니다. 찾은 데이터의 정의, 출처, 소유자, 권한을 AI가 읽을 수 있게 붙여야 하고, 그 일은 전사가 아니라 AI 과제 단위로, 정해진 사람이 맡아야 굴러갑니다.

요약

TechTarget의 Mary K. Pratt 기자는 기업이 AI용 데이터에 돈을 크게 쓰는데도 데이터를 믿지 못하는 이유를 짚었습니다. 지출 규모부터 보면, Fortune Business Insights는 세계 데이터 마이닝 도구 시장을 2026년 14.4억 달러, 2034년 34.9억 달러로 봤습니다. 데이터 거버넌스 시장은 2026년 53.8억 달러에서 240억 달러 남짓까지 커진다고 내다봤습니다. 기자는 FTI Consulting, Ducker Carlisle, Gartner의 전문가 세 명의 설명에 KPMG 보고서와 여러 조사 결과를 엮었습니다. 결론은 데이터를 찾는 일(data discovery)에는 투자가 늘었지만, 그 데이터의 이력과 뜻과 품질을 이해하는 일은 따라오지 못했다는 것입니다.

숫자가 이 간극을 보여 줍니다. IBM 기업가치연구소(IBM Institute for Business Value)는 2025년 11월 CDO 조사를 냈습니다. 여기서 최고데이터책임자(CDO)의 81%는 AI를 앞당기는 투자를 우선한다고 답했습니다. 그런데 자기 데이터가 AI로 수익을 내는 일을 받쳐 줄 수 있다고 확신한 비율은 26%였습니다. Grant Thornton이 2026년 기업 리더 950명에게 물은 조사에서는 AI 과제가 기대에 못 미치거나 실패한 이유 가운데 데이터 준비 부족이 23%로 세 번째였습니다. 원인으로 기자가 꼽은 것은 맥락의 부재입니다. 이 노트는 찾기와 이해의 차이, AI가 쓸 수 있는 데이터의 세 조건, 전사 정비가 아니라 과제별 정제로 가는 이유, 거버넌스를 맡을 역할을 차례로 풀고 실제로 돌리는 방법을 덧붙였습니다.

핵심 메커니즘

Data Discovery vs Understanding: 찾는 것과 이해하는 것의 차이

Data discovery(데이터 탐색)는 정형·비정형 데이터를 모으고 위치를 지도로 그려, 어떤 정보가 어디에 있는지 아는 일입니다. 예전의 데이터 마이닝, 데이터베이스 지식 발견(knowledge discovery in databases)도 이 범주에 들어갑니다. BI와 분석 도구를 쓰는 회사에는 지금도 꼭 필요합니다. 그러나 FTI Consulting의 Tim Anderson은 “Finding the data doesn’t mean the same as that data being understood.”라고 말했습니다. 그가 든 예는 ‘활성 고객(active customer)‘입니다. 사용자는 이 말이 어떻게 정의됐는지, 회사의 모든 데이터셋에서 같은 뜻으로 쓰이는지 모르는 경우가 많습니다. 기사는 데이터를 AI에 쓰려면 소유자, 정의, 문서, 계보(lineage, 데이터가 어디서 와서 어떻게 바뀌었는지의 기록), 사용 이력을 정확하게, 바로 꺼낼 수 있어야 한다고 봤습니다. 이 정보가 있어야 정확성, 완전성, 일관성, 적시성, 유효성, 유일성의 여섯 가지 품질 차원을 판단할 수 있습니다. Modern Data Company 조사도 같은 장애를 짚었습니다. 문서가 없거나 낡았고, 이름 규칙이 엉망이며, 탐색 도구가 부족하다는 것입니다. 데이터를 찾아도 자신 있게 쓸 맥락이 없는 셈입니다.

AI-ready Data: KPMG가 말한 세 조건

KPMG 보고서는 대부분의 기업 데이터가 대시보드, 보고, 고급 분석에는 충분하지만 AI 모델에는 모자란다고 봤습니다. AI에 맞는 데이터(AI-ready data)는 세 조건을 갖춰야 합니다. Searchable(찾을 수 있음)은 AI가 맞는 데이터를 찾아 서로 연결할 수 있다는 뜻입니다. Contextual(맥락이 있음)은 AI가 레코드를 꺼내는 데서 그치지 않고 그 뜻을 이해한다는 뜻입니다. Trusted(믿을 수 있음)는 AI의 행동을 추적하고 감사할 수 있다는 뜻입니다. 이를 위해 계보가 분명해야 하고, 권한은 기계가 읽을 수 있는 형태(machine-readable permissions)여야 하며, 결정 논리가 남아 있어야 합니다. 사람이 대시보드를 볼 때는 숫자가 이상하면 담당자에게 물어보면 됩니다. AI는 물어볼 상대가 없으니 그 답이 데이터 옆에 미리 붙어 있어야 합니다. 세 조건 가운데 앞의 하나는 탐색 투자로 채워지지만, 뒤의 둘은 정의와 권한과 기록을 만드는 일이라 도구만으로는 채워지지 않습니다.

Task-by-Task Refinement: 전사 라벨링 대신 과제별 정제

Gartner의 Nader Henein은 기업들이 전사 데이터를 라벨링한 적이 없는 이유를 설명했습니다. 그동안 데이터를 어떻게 정리하고 저장하고 누구에게 열지는 사이버보안, 개인정보, 규제 준수가 정했습니다. AI나 분석이 기준이 아니었습니다. 전사 데이터를 목록화하고 라벨을 붙이는 일은 비싸고 사람이 많이 들었습니다. BI, 분석, 머신러닝에 꼭 필요하지도 않아 ROI를 보여 주기 어려웠습니다. 그래서 회사들은 아예 하지 않거나 캐고 싶은 데이터에만 했습니다. Henein은 앞으로도 정제가 과제 단위로 갈 것으로 봅니다. 기업은 특정 AI 과제에 묶인 데이터만 다듬어 라벨을 붙이고, 과제가 쌓이면 가치 있는 데이터가 자연히 위로 떠오른다는 것입니다. 전사 데이터를 한꺼번에 AI에 맞추려는 계획은 비용과 인력에서 막히기 쉽습니다. 첫 과제의 데이터부터 다듬는 편이 현실적입니다.

Governance ROI and Roles: 거버넌스의 ROI가 계산되기 시작했다

Ducker Carlisle의 최고데이터·AI책임자 Fabien Cros는 데이터 거버넌스가 이제 있으면 좋은 것이 아니라 필수라고 봤습니다. 예전에는 거버넌스와 데이터 품질 작업의 ROI를 설득하기 어려웠습니다. AI가 들어오면서 사정이 바뀌었습니다. 데이터 품질이 AI 결과를 바로 바꾸니, 품질을 올린 효과를 숫자로 계산할 수 있게 됐다는 것입니다. 그는 벤더의 기술 발전만으로는 메타데이터 관리와 거버넌스가 해결되지 않는다고도 했습니다. 프로세스와 관행을 만들고 맡을 사람을 정해야 합니다. 그가 꼽은 역할은 데이터 소유자(data owner), 데이터 스튜어드(data steward, 정의와 품질을 관리하는 담당), 데이터 챔피언(data champion, 현업에서 데이터 활용을 이끄는 사람)입니다. Anderson은 데이터가 너무 빨리 바뀌어 특정 시점의 실제 모습을 잡기 어렵다고 덧붙였습니다. 한 번 정리하고 끝나는 프로젝트가 아니라 계속 돌아가는 역할이 필요하다는 뜻입니다.

Commoditized Refinement: 2030년의 정제 기능

Henein은 데이터 정제 기능이 지금처럼 비싸고 범위가 좁은 별도 제품으로 남지 않을 것으로 봤습니다. 벤더들이 표준 제품에 기본으로 넣어 2030년쯤에는 범용 기능이 될 수 있다는 전망입니다. 이 전망은 투자 순서에 영향을 줍니다. 도구는 시간이 지나면 싸지고 흔해지지만, 무엇을 ‘활성 고객’으로 볼지 정하고 그 정의를 지키는 사람은 도구가 대신하지 않습니다. 비싼 정제 도구를 서둘러 전사에 까는 것보다, 정의와 소유와 역할을 먼저 갖춰 두는 편이 나중에 들어올 범용 기능도 제대로 쓰게 합니다.

통념과 다른 주장

기술 디테일: 과제 데이터에 맥락을 붙이려면

아래 필드, 설정값, 기준은 원문에 없는 실행 제안입니다.

Understanding을 AI가 읽게 하려면 데이터 자산마다 맥락 카드를 하나씩 붙입니다. 기사가 꼽은 다섯 정보(소유자, 정의, 문서, 계보, 사용 이력)와 여섯 품질 차원, KPMG의 권한 조건을 한 레코드에 담습니다. 범위는 전사가 아니라 AI 과제 하나가 읽는 테이블과 문서로 한정합니다. 에이전트나 RAG 파이프라인은 카드가 있고 status가 approved인 자산만 읽게 막습니다. 카드는 데이터 카탈로그에 두되, AI가 호출할 수 있게 API나 MCP 도구로 노출합니다.

{
  "asset_id": "crm.customer_status_daily",
  "use_case": "CHURN-OUTREACH-AGENT",
  "owner": "고객경험본부장",
  "steward": "CRM 데이터 스튜어드",
  "glossary_terms": [{"term": "active_customer", "definition_id": "GL-014", "version": 3}],
  "lineage_upstream": ["erp.billing_invoice", "app.login_events"],
  "usage_last_90d": {"queries": 412, "consumers": ["churn_model_v2", "sales_dashboard"]},
  "quality": {"accuracy": 0.97, "completeness": 0.93, "consistency": 0.88,
              "timeliness_hours": 20, "validity": 0.99, "uniqueness": 0.995},
  "permissions": {"allowed_purposes": ["retention_marketing"], "pii": true, "mask": ["email", "phone"]},
  "status": "approved",
  "verified_at": "2026-11-12"
}

Contextual 조건을 채우려면 같은 용어가 데이터셋마다 다르게 정의된 곳부터 찾습니다. Anderson이 든 ‘활성 고객’처럼 과제의 핵심 용어 10개 안팎을 고르고, 그 용어를 계산하는 SQL, dbt 모델, 대시보드 지표 정의, 컬럼 설명을 모읍니다. LLM에는 정의 하나씩 넣어 {"term", "source", "rule", "time_window", "filters"} 형태로 규칙을 뽑게 하고 temperature는 0으로 둡니다. 같은 입력을 3회 돌려 추출 결과가 다르면 그 항목은 사람 검토로 보냅니다. 출처별 규칙을 나란히 놓으면 “최근 30일 로그인”과 “최근 90일 결제”처럼 다른 정의가 드러납니다. 표준 정의는 LLM이 정하지 않고 steward가 승인합니다. 승인한 정의는 시맨틱 레이어(semantic layer, 지표와 용어를 한 곳에서 정의하는 계층)에 올려 AI와 대시보드가 같은 정의를 읽게 합니다.

Trusted 조건을 채우려면 계보, 권한, 결정 로그를 따로 챙깁니다. 계보는 파이프라인 실행 때 입력과 출력 자산을 자동으로 기록하게 합니다(OpenLineage 같은 공개 표준을 쓸 수 있습니다). 권한은 문서가 아니라 정책으로 둡니다. 자산에 pii, allowed_purposes 같은 태그를 달고 AI가 데이터를 읽기 전에 과제 목적과 대조합니다. AI가 행동할 때마다 읽은 asset_id, 정의 버전, 권한 검사 결과, 모델 버전을 결정 로그에 남깁니다. 그래야 나중에 “왜 이 고객에게 연락했나”를 거꾸로 따라갈 수 있습니다.

데이터가 빨리 바뀌는 문제에 대응하려면 Anderson이 말한 변화 속도를 측정값으로 다룹니다. 품질 점수는 한 번 재고 끝내지 않고 매일 다시 계산합니다. verified_at에서 30일이 지나거나 점수가 기준 아래로 떨어지면 status를 review로 바꾸고, AI 출력에 경고를 붙입니다.

막히는 경우	증상	대응
정의 충돌	같은 지표가 보고서마다 다름	용어별 규칙 추출 후 steward 승인
카드 없는 자산	AI가 출처 모를 테이블을 읽음	승인된 자산만 읽도록 접근 차단
권한이 문서로만 있음	개인정보가 목적 밖으로 쓰임	목적 태그와 사전 정책 검사
맥락이 낡음	바뀐 정의로 AI가 답함	30일 재검증, 만료 시 경고
추출 편차	LLM이 같은 정의를 다르게 읽음	temperature 0, 3회 실행 후 불일치는 사람 검토

현업 실행 디테일: 누가, 언제, 무엇을

Cros가 꼽은 세 역할을 AI 과제 하나에 붙이면 아래처럼 나뉩니다. 역할 이름은 원문에서, 맡는 일은 실행 제안으로 새로 썼습니다.

역할	맡는 일
CDO·CIO	진단할 AI 과제 선정, 진행 여부 결정
Data owner(현업 임원)	용어 정의 최종 승인, 권한 목적 결정
Data steward	맥락 카드 작성, 정의 충돌 정리, 품질 기준 관리
Data champion(현업 실무 리더)	현업 용어 수집, AI 출력 검토와 피드백
데이터 엔지니어	계보 수집, 품질 자동 측정, 접근 통제
재무 컨트롤러	데이터 품질 개선 전후의 과제 효과 금액 확인

준비물. 진행 중인 AI 과제 하나와 그 과제가 읽는 테이블·문서 목록, 과제에 나오는 핵심 업무 용어 목록, 용어를 계산하는 SQL이나 지표 정의, 기존 보안·개인정보 분류표가 필요합니다. Henein의 지적대로 기존 분류는 보안과 규제 기준으로 만들어졌을 가능성이 크니, AI 목적 기준으로 다시 봐야 할 항목을 미리 표시해 둡니다.

기간	할 일	산출물
1주	과제 하나 선정, 읽는 자산 목록화, owner·steward·champion 지정	과제·자산 대응표, 역할표
2주	핵심 용어 10개 정의 수집과 충돌 정리	승인된 용어 정의, 충돌 목록
3주	맥락 카드 작성, 6차원 품질 측정, 계보 기록	자산별 맥락 카드, 품질 점수
4주	정제 전후 AI 출력 비교, 효과 금액 확인	거버넌스 ROI 1장 보고, 확대 여부 결정

현업에 물을 것.

1. 이 과제의 핵심 용어(예: 활성 고객, 매출, 납기 준수)를 부서마다 어떻게 계산하나요?
2. 이 테이블이 틀렸을 때 누가 고치고, 누구에게 물어보나요?
3. 이 데이터를 AI가 읽어도 되는 목적과 안 되는 목적은 무엇인가요?
4. AI 출력을 사람이 고치는 데 건당 몇 분이 들고, 고친 이유는 주로 데이터인가요 모델인가요?
5. 지난 분기에 정의가 바뀐 지표가 있나요? 바뀐 사실을 누가 알렸나요?

진행 판정 기준(예시). 핵심 용어 가운데 승인된 정의가 80% 미만이면 모델이나 기능을 늘리지 않고 정의 작업을 먼저 끝냅니다. 맥락 카드가 승인된 자산만 AI가 읽게 막은 뒤, 사람 검토 시간이나 정정 건수가 20% 이상 줄면 같은 방식으로 다음 과제로 넓힙니다. 줄지 않으면 모델 문제인지 정의 문제인지 결정 로그로 다시 봅니다.

AX 적용 제언. 데이터 카탈로그나 플랫폼 구매를 검토 중인 회사라면, 구매 전에 AI 과제 하나를 골라 위 4주 진단을 먼저 돌려 보는 편이 낫습니다. 막히는 지점이 도구가 아니라 정의와 소유라면 도구 예산 일부를 steward 인력과 시맨틱 레이어로 돌립니다. 거버넌스 투자를 설득할 때는 Cros의 말처럼 AI 과제의 결과를 근거로 씁니다. 정제 전후로 검토 시간, 오류 건수, 효과 금액을 같은 표에 놓으면 경영진이 거버넌스를 비용이 아니라 AI 수익의 선행 투자로 볼 수 있습니다. 과제가 쌓일수록 승인된 용어와 맥락 카드도 쌓이니, 두 번째 과제부터는 진단 기간이 짧아집니다.

원문 사례

항목	내용
기사	TechTarget, Mary K. Pratt 기자, 2026년 11월 3일
시장 규모	데이터 마이닝 도구 2026년 14.4억 달러, 2034년 34.9억 달러 / 데이터 거버넌스 2026년 53.8억 달러, 240억 달러 남짓 전망(Fortune Business Insights)
CDO 조사	IBM IBV 2025년 11월, AI 가속 투자 우선 81%, 데이터가 AI 수익을 받쳐 준다고 확신 26%
실패 원인	Grant Thornton 2026 AI Impact Survey, 리더 950명, 데이터 준비 부족 23%로 3위
장애 요인	Modern Data Company 조사, 문서 부재·노후, 이름 규칙 부실, 탐색 도구 부족
AI-ready 조건	KPMG, Searchable·Contextual·Trusted
Tim Anderson	FTI Consulting senior managing director, 찾기와 이해의 차이, ‘활성 고객’ 정의 예, 빠른 데이터 변화
Fabien Cros	Ducker Carlisle 최고데이터·AI책임자, 거버넌스 필수화, ROI 계산 가능, owner·steward·champion
Nader Henein	Gartner VP 애널리스트, 전사 라벨링 부재의 이유, 과제별 정제, 2030년 범용화 전망

핵심 개념

data discovery

정형·비정형 데이터를 모으고 위치를 파악해 무엇이 어디 있는지 아는 일입니다.

metadata management

데이터의 정의, 소유자, 출처, 품질 같은 '데이터에 대한 데이터'를 만들고 최신으로 유지하는 일입니다.

machine-readable permissions

사람이 읽는 규정 문서가 아니라 시스템이 읽고 자동으로 집행하는 접근 규칙입니다.

auditable decision logic

AI가 왜 그렇게 행동했는지 나중에 거꾸로 따라가 확인할 수 있게 남긴 기록입니다.

six dimensions of data quality

정확성, 완전성, 일관성, 적시성, 유효성, 유일성의 여섯 가지 품질 판단 기준입니다.

data champion

현업에서 데이터 정의와 활용을 앞장서 이끄는 사람으로, owner·steward와 함께 거버넌스를 굴립니다.

내 메모

TODO: 내 생각 추가

원문은 TechTarget에 실린 Mary K. Pratt 기자의 기사 “Why infrastructure spending won’t fix the real AI problem”(2026.11.3)입니다. 요약, 핵심 메커니즘의 원문 내용, 통념과 다른 주장, 원문 사례 표는 기사에 나온 전문가 설명과 조사 수치를 AX Review가 다시 정리한 것입니다. 기술·현업 실행 디테일, JSON 예시, 실패 대응표, 4주 일정, 질문과 판정 기준, 인포그래픽은 원문에 없는 내용으로 새로 작성했으며 그 안의 필드명과 숫자는 가상 예시입니다. 기사 전문은 원문 페이지에서 볼 수 있습니다.