Data Eng Wiki

AI-Ready Data

23 min read

AI-Ready Data

“You don’t ‘upgrade’ analytics-ready data into AI-ready data.” — Modern Data 101

핵심 개념

AI-Ready Data는 모델·에이전트·ML 시스템이 효과적으로 추론할 수 있도록 최적화된 데이터 상태를 말한다. 기존의 analytics-ready data(인간의 의사결정을 위해 압축·집계된 데이터)와는 근본적으로 다른 요구사항을 갖는다.

Analytics-Ready vs AI-Ready

속성Analytics-ReadyAI-Ready
소비자인간 (분석가, 경영진)모델 (LLM, ML, 에이전트)
핵심 질문무슨 일이 있었나?다음에 무엇을 해야 하나?
데이터 처리 방향압축 (variance 제거)확장 (context 보존)
핵심 속성정확성, 집계, 안정성, 설명가능성컨텍스트, 완전성, 적시성, 의미적 풍부함
실패 모드부정확한 숫자 → 신뢰 붕괴불완전한 컨텍스트 → 할루시네이션

AI-Ready Data의 4가지 속성

  1. Context(컨텍스트): 모델은 세상을 경험하지 못하므로, 역사적 상태·사용자 의도·환경 조건·시스템 제약 같은 주변 정보가 필수
  2. Completeness(완전성): 모델은 인간처럼 판단으로 빈 곳을 채우지 못함. 누락 데이터를 “불확실성”이 아닌 “부재”로 처리
  3. Timeliness(적시성): 어제의 진실이 오늘의 부채. 모델 행동을 현재 현실에 고정
  4. Semantic Richness(의미적 풍부함): 관계·계층·의도·제약이 데이터 자체에 명시적으로 인코딩되어야 함

Dashboard Trap

높은 분석 성숙도를 가진 조직이 흔히 빠지는 함정. 대시보드가 신뢰받고 메트릭이 거버넌스되지만, AI가 필요로 하는 variance, edge case, contextual detail이 이미 압축되어 사라진 상태.

“Our data is great, but why doesn’t AI work?”

독립적 성숙도 경로

두 시스템은 수렴하지 않으며 독립적으로 성숙시키되 조정(coordination)해야 한다:

  • 공유 기반: 정확한 이벤트, 신뢰할 수 있는 소스, 보존된 의미
  • 분기점: Analytics는 현실→설명으로, AI는 현실→가능성으로 변환

실무 시사점

  • Semantic Layer와 문서화가 AI-readiness의 기반 (SafetyCulture 사례)
  • Data Governance 레이어가 AI 에이전트의 정확성을 결정 (JET 사례)
  • 이벤트를 먼저 캡처하고, 의미를 보존한 뒤, 분석 뷰를 나중에 도출하는 순서가 중요

다섯 속성 — 사람이 공짜로 해주던 일의 이전

Thoughtworks(Sadalage·Chandrasekaran)의 프레이밍은 위 네 속성을 “인간이 무의식적으로 하던 일 중 무엇이 데이터로 밀려나는가” 로 재정리한다. 인간 소비자에게 데이터는 충분히 좋기만 하면 됐다. 의미, 온전성 확인, 신뢰 판단이 전부 사람 머릿속에 살았기 때문이다.

속성인간이 하던 일이제 데이터가 해야 하는 일
Trusted이상한 숫자에서 멈춘다에이전트가 보기 전에 정확·신선·검증
Contextual”revenue는 이미 반품 제외”, “회계연도는 2월 시작”을 안다의미를 데이터에 명시
Traceable나중에 왜 그랬는지 설명할 수 있다30초 만에 결정하므로 일어나는 순간 포착
Governed역할과 판단이 접근을 한정한다설계로 한정
Operational대시보드를 읽고 가서 뭔가를 한다읽을 수 있는 게 아니라 행동 가능

하나를 놓치면 에이전트는 사람처럼 우아하게 저하되지 않는다. 자신 있게 실패한다.

결정적 행동 격차 — 인간은 멈추고 에이전트는 행동한다

Simon Willison의 표현대로 언어 모델은 gullible하다 — 넘겨받은 것을 믿고 행동한다.

가격 시나리오: 어제 59.99로 올랐는데 데이터 소스가 갱신되지 않았다. 에이전트는 망설이지 않고 10를 잃는다. 에이전트가 밟은 모든 단계가 기술적으로 옳았다. 워크플로를 완벽히 따랐다. 문제는 데이터였다.

인간 영업 담당자였다면 “잠깐, 지난주에 갱신하지 않았나?” 하고 멈췄을 것이다.

조직 수준의 같은 병리: 2026 State of Data Integrity 조사(데이터·분석 리더 505명)에서 87%가 자기 데이터가 AI 준비되었다고 믿었지만 43%가 데이터 준비성을 가치 창출의 가장 큰 단일 장벽으로 지목했다. “확신과 준비성 사이의 그 격차가 pricing 에이전트의 조직 수준 버전 — 자기 확신에 차 있고 틀렸다.”

의존 순서 — 이 스택은 아래에서 위로만 쌓인다

        ┌──────────────────────────────┐
        │  Access (capability / MCP)   │  ← 행동
        ├──────────────────────────────┤
   Obs  │  Context (domain/semantic)   │  ← 의미
   ↕    ├──────────────────────────────┤
        │  Contracts & Quality         │  ← 신뢰
        └──────────────────────────────┘
   Observability는 tier가 아니라 셋 전부를 관통한다

신뢰할 수 없는 데이터에 의미를 붙일 수 없고, 그 의미로 제약하지 않고 에이전트를 안전히 행동시킬 수 없다. 둘 중 하나를 건너뛰면 위의 모든 것이 무너진다. 그것이 그렇게 많은 agentic AI 프로그램이 멈추는 이유다 — 아래 기반 없이 곧장 에이전트 접근으로 뛴다.

⚠️ 성숙도 진단에서 행을 평균 내지 마라. 준비도는 가장 약한 기반 레이어가 상한을 정한다. 신뢰할 수 없는 데이터 위의 완벽한 context layer는 여전히 agent-ready가 아니다.

Observability만 예외다. 자율성은 단계적으로 얻지만 관측성은 전혀 단계적이지 않다 — 자율성 수준이 무엇이든 첫날부터 완전한 강도로. 돌아가는 시스템에 나중에 붙이는 것이 훨씬 어렵기 때문이다.

Layer 1 — Contracts: 에이전트는 나쁜 데이터 냄새를 못 맡는다

“schemaless가 유연하다”는 10년의 사고를 뒤집는다. 인간에게 느슨한 스키마는 불편할 뿐이지만 에이전트에게는 위험하다.

집행은 세 차원 — 스키마 집행 / freshness SLA / CI/CD 품질 게이트.

⚠️ freshness SLA를 값이 마지막으로 바뀐 시점이 아니라 데이터가 마지막으로 성공적으로 적재된 시점에 키잉하라. 그래야 ① 변화 없는 데이터가 stale로 오탐되지 않고 ② 멈춘 파이프라인이 fresh인 척할 수 없다.

quarantine 패턴 — raw 데이터가 에이전트 접근 가능 스토어에 들어가기 전 validation gate를 지나고, 실패하면 dead letter queue로 격리된다. 에이전트는 나쁜 데이터를 결코 보지 않는다. 격리 시 에이전트는 “현재 가격 데이터가 없습니다” 라고 말한다 — 훨씬 나은 실패 모드다.

이것은 모델이 아니라 데이터 아키텍처의 일이다. 더 나은 모델이 나쁜 데이터에서 당신을 구해주지 않는다.

Medallion + Adaptive Gold: 에이전트는 Gold tier 이상에만 접근한다. Bronze·Silver는 리니지·디버깅·인간 조사용. 네 번째 tier Adaptive Gold에서는 에이전트가 소비만 하지 않고 자기 쿼리 패턴을 관찰해 계속 손을 뻗는 조합을 materialize한다 (Apple이 DataHub CONTEXT 2025에서 발표한 카탈로그 “digital steward” 에이전트의 데이터셋 버전). → Medallion Architecture

비정형 데이터도 같은 규칙: stale-price의 쌍둥이는 정책 문서는 갱신됐는데 vector index가 재임베딩되지 않은 것. freshness SLA의 시계는 인덱스가 소스에 대해 마지막으로 성공적으로 재구축된 때를 재야 한다 — 그 heartbeat 하나가 갱신됐지만 인덱싱 안 된 문서와 조용히 멈춘 indexer를 둘 다 잡는다. contract는 콘텐츠에서 주변 메타데이터(source/version/timestamp/access scope)로 옮겨간다.

confidence-threshold routing: 데이터 품질 신호가 임계를 주도해야 한다 — 모델 자신의 confidence가 아니라. 모델은 stale한 답에 확신할 수 있고, freshness SLA가 그 잘못된 확신을 무효화한다. 다만 여러 신호를 단일 점수로 합치는 것은 열린 설계 문제다. 매끄러운 composite보다 hard gate로 시작하라 — 어떤 contract·SLA 위반이든 다른 신호와 무관하게 인간을 강제한다.

Layer 2 — Context: 명사, 숫자, 동사

context layer는 하나가 아니라 세 개의 별도 정의 본체다. → Semantic Control Plane, Semantic Layer

모델무엇을 말하는가실행?
domain model무엇이 존재하는가 — 엔티티·관계·의미 규칙✗ 참조될 뿐 실행되지 않는다
semantic model숫자가 어떻게 계산되는가 — 버전 관리된 공식 하나씩, 매번 같은 SQL로 컴파일✅
capability model에이전트가 무엇을 해도 되는가 — 큐레이션된 읽기/쓰기 연산 + 권한·오너·precondition·reversibility✅

셋을 묶는 것은 다 의미에 관한 것이라서가 아니다 (capability model은 명백히 아니다). 각각이 요청마다 모델이 새로 알아내는 대신 버전 관리에서 한 번 보증이 선언되는 자리라는 점이다. 정의가 곧 레이어이고, 인터페이스는 — 오늘날 MCP는 — 그저 문일 뿐이다.

왜 domain model을 분리하나 (dbt semantic model이 이미 엔티티를 선언하는데): 지표 레이어 안의 엔티티는 지표에 스코프되어 있고, capability model이 같은 어휘로 쓰이지 않으면 둘이 어긋난다. 환불은 revenue 수치가 세는 것과 같은 고객에 작용한다. 아래에 하나의 어휘를 두거나, 두 개를 갖게 되거나.

효과 측정: AtScale text-to-SQL 벤치마크에서 동일 모델로 raw 스키마 정확도 20% 미만 → 시맨틱 레이어 적용 시 92.5% 초과. semantic model은 에이전트를 더 똑똑하게 만들지 않는다. 추측하는 것을 멈추게 한다.

시작 지점: 비즈니스 전체를 모델링하려는 유혹에 저항하라. 충돌하는 지표 정의부터 — 그것이 최대의 에이전트 리스크이자 가장 빠른 승리다. 적대적으로 테스트하고, 모든 환각이 가리키는 빠진 정의를 고쳐라. 프롬프트가 아니라 정의를.

지식 그래프는 domain model의 스토리지 선택이지 네 번째로 만들 것이 아니다. flat 테이블이 잘 못 다루는 것은 쿼리를 쓸 때 깊이를 모르는 순회다. → Ontology-Backed Knowledge Graphs, Knowledge Graph Infrastructure

Layer 3 — Access: searchable에서 actionable로

RAG + MCP-Read + MCP-Write (Microsoft CAF for AI). 대부분의 조직은 1단계에 산다.

  1. Retrieval — 문서를 찾는다
  2. Real-Time Query — 라이브 시스템을 읽는다
  3. Write-Back — 가장 강력하고 가장 위험한 tier

MCP 프리미티브가 그대로 위험 gradient에 매핑된다 — Resources(읽기 전용) → Prompts(행동 형성) → Tools(상태 변경). 안전한 경로는 Resources를 먼저 노출하고 거버넌스 하에서만 Tools로 승격.

안티패턴 — naive API-to-MCP 변환: REST 엔드포인트를 1:1로 감싸면 tool sprawl — 거의 구분되지 않는 도구 50개. 도구 수가 늘수록 LLM 정확도가 급격히 떨어진다 (Thoughtworks Radar HOLD). 엔드포인트가 아니라 capability를 설계하라 — 잘 기술된 5~10개가 얇은 래퍼 50개를 거의 항상 이긴다. → MCP (Model Context Protocol)

행동하는 capability가 선언해야 하는 것:

  • Preconditions — 계획 초기에 읽은 것이 아니라 행동하는 순간의 라이브 상태에 대해 확인
  • Reversibility — 깔끔히 되돌림 / 보상 트랜잭션으로 비용 들여 되돌림 / 되돌릴 수 없음. 거래 금액보다 안전한 자율성의 더 나은 예측 변수다. 되돌릴 수 있는 200 외부 결제보다 자동화하기 안전하다

검색된 텍스트는 informs하지 gates하지 않는다: 규칙은 사전에 문서에서 추출되고 인간이 큐레이션해 capability model의 선언된 precondition으로 저장되며, 각각 유래 구절로의 링크를 갖는다. 행동 시점에 에이전트는 비정형 콘텐츠를 읽어 무엇을 제안할지 알아낼 수 있지만, 선언된 규칙만이 무엇이 허용되는지 결정한다.

이 경계는 보안 속성이기도 하다. 검색된 텍스트를 인가 경로에서 제거하면 오염된 문서가 에이전트에게 원래 없던 권한을 부여할 수 없다 — 하이재킹된 에이전트의 도달 범위를 줄이는 것보다 강한 주장이다.

⚠️ provenance 링크가 사주는 것에 대해 과약속하지 마라. 문서가 바뀐 것을 탐지하기는 쉽지만, 그 변경이 유도된 precondition을 무효화했는지 아는 것은 diff가 아니라 판단이다. 링크가 주는 것은 리뷰 큐다.

선언이 커버하지 않는 상황에서 에이전트는 즉흥 연주하지 않고 에스컬레이션한다. 선언되지 않은 케이스는 에이전트를 autonomous가 아니라 supervised로 격하시킨다.

관통 레이어 — Traceability와 Governance

전통 감사 로그는 무엇이 일어났는지 말할 수 있지만 왜는 말할 수 없다. 에이전트가 30초 만에 $2.4M 거래를 승인하고 6개월 뒤 규제 당국이 “왜 승인되었나?”를 물을 때, 필요한 것은 “14:32:07에 compliance DB에 접근했다” 가 아니라 “KYC를 먼저, 그다음 제재, 그다음 신용 조건을 확인했고 셋 다 통과해서 승인했다” 다.

agentic lineage — 전통 리니지가 어떤 소스가 접근되었는지를 추적한다면, agentic lineage는 왜 에이전트가 X에 접근하기로 결정했는지 — 소스 Z에서 Y를 찾았기 때문에 를 추적한다. traces and spans 모델은 분산 시스템 관측성에서 직접 빌려온다 (Jaeger/Zipkin → Langfuse/Arize Phoenix/OpenTelemetry for AI).

규제의 이빨: EU AI Act Article 12(수명 전체 자동 로깅) + Article 19(최소 6개월 보관), 위반 시 최대 €1,500만 또는 전 세계 연매출 3% 중 큰 쪽. 법은 로그를 요구하고, 그것이 규제 당국의 질문에 답하게 만드는 것은 당신 몫이다.

규제가 어디에 착지할지에 베팅할 필요는 없다. 설명할 수 없는 시스템은 완전히 신뢰하거나 방어하거나 고칠 수 없는 시스템이다.

staged autonomy — Shadow → Supervised → Autonomous with guardrails → Full autonomy. 신입에게 첫날 법인카드를 주지 않는다. 승진은 감이 아니라 증거에 달려야 하고, 그러려면 프로덕션 관찰만이 아니라 각 단계 전 테스트가 필요하다 — 도구·모델 상호작용을 mock/replay해 CI에서 결정적으로. → LLM Evaluation, Replay Testing

세 가지 보안 패턴: Delegated Access(공유 서비스 계정은 귀속을 파괴한다 — “누가 접근했나?”에 “서비스 계정”은 아무것도 말해주지 않는다) / Just-in-time Credentials(5분짜리 스코프된 토큰, 탈취를 기다리는 상시 자격증명 없음) / Least Privilege. 셋이 함께 lethal trifecta(비공개 데이터 접근 + 신뢰할 수 없는 콘텐츠 노출 + 외부 소통 수단)를 깬다. → AI Agent Identity and Security

아무도 소유하지 않으면 전부 표류한다

모든 레이어가 참으로 유지되어야 하는 아티팩트를 만든다 — contract, 지표 정의, 접근 스코프, trace. 아티팩트는 스스로 유지되지 않는다.

  • 오너 없는 contract → 기술하는 소스와 어긋나 표류
  • 오너 없는 “revenue” 정의 → 방금 통합한 세 개의 충돌 버전으로 재분기
  • 오너 없는 접근 스코프 → 조용히 넓어져 다시 상시 서비스 계정

인간 소비자는 오너 없이 표류하는 데이터셋을 알아채고 우회한다. 에이전트는 기계 속도와 규모로 소비하고 오류를 그만큼 빠르게 전파한다. 소비자가 빠르고 자율적일수록 오너 없는 데이터를 감당할 수 없다.

규율은 data as a product — 명명된 오너, 발행된 contract와 SLA, 버전 관리된 라이프사이클. → Data Contracts, Data Mesh and Federation

시작 순서

  1. 첫날부터 계측 — 순서상의 단계가 아니라 모든 것 아래에서 달리는 상수
  2. 모든 것에 contract — 에이전트는 나쁜 데이터 냄새를 못 맡으니 데이터 아키텍처가 대신 맡아야 한다
  3. 모델보다 컨텍스트 — 컨텍스트가 더 큰 모델보다 정확도를 더 멀리 움직인다. 단, 아래 데이터를 신뢰할 수 있을 때만 값을 한다
  4. write보다 read 먼저

에이전트가 데이터의 주 소비자가 될 때, 당신의 데이터 아키텍처가 곧 당신의 AI 아키텍처가 된다.

연관 개념

Source: AI-Ready Data vs Analytics-Ready Data, The Journey to Agentic BI, Daedalus and the Data Labyrinth, Making Your Data Ready for Agentic AI

그래프 뷰

백링크