AI-ready 데이터의 오해와 준비 방법

들어가며: "AI-ready로 만들어 주세요"는 발굴 질문이다

3편 인테이크 양식의 4번 칸은 "AI가 필요로 하는 정보와 그 포맷"이었다. 고객은 흔히 "우리 데이터를 AI-ready로 만들어 주세요"라고 말한다. 마치 한 번 청소하면 끝나는 작업처럼. 그런데 이건 청소가 아니라 발굴 질문이다.

Gartner는 못을 박는다. 데이터를 사전에, 일반적으로 AI-ready로 만들 방법은 없다. 읽기는 전적으로 어떻게 쓸 것인가에 달려 있고, 그래서 유스케이스마다 필요한 데이터가 완전히 다르다.¹ Snowflake의 AI-Ready Data Framework가 이를 숫자로 보여준다. 62개 요구사항을 점수화하는데, 같은 데이터셋이 워크로드 프로파일마다 다른 점수를 받는다. 단순 조회(Scan)는 8개 기준, RAG는 27개, 모델 학습은 50개, 에이전트는 37개를 본다.² 즉 "AI-ready"는 데이터의 속성이 아니라 데이터와 용도의 관계다.

이 글의 결론을 먼저 적는다.

• AI-ready 데이터는 미리 만들어 두는 게 아니다. 용도가 정해져야 무엇이 ready인지 정의된다. 그래서 "어떤 데이터를 어떤 포맷으로"는 인테이크에서 발견할 대상이다.
• 데모 위의 마법 아래에는 빙산 같은 기반이 있다. 데모는 싸지만 그걸 프로덕션으로 만드는 비용이 진짜 무게다.
• 업스트림(데이터 계약, 시맨틱 레이어)과 다운스트림(컨텍스트 엔지니어링)은 같은 문제의 양 끝이다.
• 그리고 당신이 이미 만든 LLM Wiki와 ADR이 곧 그 조직의 AI-ready 데이터 프로덕트다.

데모 위의 마법, 그 아래의 빙산

고객이 AI를 마법으로 보는 1편의 문제는 데이터에서 가장 비싸게 드러난다. 데모는 마법처럼 보이지만, 그걸 프로덕션으로 만드는 건 보이지 않는 기반이다.

Google의 2015년 논문 "Hidden Technical Debt in Machine Learning Systems"의 유명한 그림 한 장이 이걸 압축한다. 실제 ML 시스템에서 모델 코드는 작은 박스 하나일 뿐이고, 그 주위를 데이터 수집·검증·서빙·모니터링 같은 거대한 인프라가 둘러싼다.³ 저자들은 "이런 빠른 성과가 공짜로 온다고 생각하는 건 위험하다"고 경고하고, 변화 하나가 전체를 바꾼다는 CACE(Changing Anything Changes Everything) 원리로 ML 시스템이 왜 깨지기 쉬운지 설명한다.³ 특히 시간에 쫓기면 사람은 "가장 손쉬운 신호"를 집어 쓰고 부채가 조용히 쌓인다. 결과만 빨리 원하면 기반이 건너뛰어지는, 현장에서 흔히 보는 그 패턴이다.

숫자도 일관된다. 다만 정의가 제각각이라 섞으면 안 된다.

세 수치는 방법론과 "실패"의 정의가 다르지만 가리키는 곳은 같다. 모델이 아니라 데이터·프로세스 기반이 비어 있다.

"AI-ready"는 용도 의존적이다 (업스트림)

그러면 무엇이 ready인가. 업스트림에는 쓸 만한 어휘가 있다. Neil Lawrence의 Data Readiness Levels는 세 밴드로 나눈다.⁷

• 밴드 C (접근성): 기계가 읽을 수 있고 윤리적으로 다룰 수 있는가.
• 밴드 B (충실성): 정확하고 대표성이 있는가, 결측·오류가 처리됐는가.
• 밴드 A (적합성): 이 특정 과제에 적합한가. 라벨링이나 새 수집이 필요할 수도 있다.

핵심은 밴드 A다. "적합하다"는 언제나 어떤 용도에 대해다. 그래서 Gartner의 "용도가 정해져야 ready가 정의된다"는 주장과 정확히 맞물린다. 성공하는 조직이 데이터 기반에 최대 4배 더 투자한다는 Gartner의 2026년 조사도 같은 맥락이다.⁸

용도를 무시한 채 "데이터가 있으니 ready"라고 본 대표적 실패가 Amazon의 채용 도구다. 10년치 이력서로 학습했는데, 그 데이터는 "최고의 인재"가 아니라 **"Amazon이 과거에 뽑은 사람"**을 인코딩하고 있었다. 그 결과 여성 관련 표현을 깎아내려 결국 폐기됐다.⁹ 추상적 목표("top talent")와 데이터가 실제로 담은 것("과거 채용 패턴")을 맞춰 보지 않은 것이다. 그래서 AWS의 GenAI 평가 질문지는 정직한 수치를 강제한다. "이 데이터 중 몇 %가 지금 접근 가능한가(예: 85%), 몇 %가 GenAI 품질 기준을 충족하는가(예: 78%, 목표 95%)."¹⁰

다만 정직하게 덧붙일 게 있다. 이상은 깨끗하지만 실제 프로젝트에서 그 이상을 온전히 지키는 경우는 드물다. 내가 통과한 한 멀티벤더 AI 프로젝트에서도 처음에는 text-to-SQL이 읽기 좋은 깨끗한 스키마를 베이스부터 새로 설계하자고 정했다. 그런데 기존 웹과 API가 레거시 스키마를 그대로 읽고 쓰는 이상, 베이스를 새로 깨끗이 까는 것은 불가능했다. 그 결정은 며칠 만에 회의에서 뒤집혔고, 얼마 지나지 않아 공식 폐기됐다. 최종 전략은 "레거시 스키마는 그대로 두고, AI가 필요한 만큼만 테이블과 뷰로 보강한다"였다. 그 결정 기록은 트레이드오프를 솔직하게 적어 두었다: 레거시 부채(안 쓰는 컬럼, 비표준 날짜 표기, ID 타입 불일치, 모호한 명명)를 그대로 상속하고, 결국 AI가 예외처리하며, text-to-SQL 친화성은 새로 만든 뷰 레이어에서만 부분적으로 확보된다고. 즉 "미리 ready로 만들 수 없다"는 Gartner의 명제는 현장에서 "레거시 때문에 ready로 만들 수도 없다"로 더 가혹하게 나타난다. 깨끗한 시맨틱 레이어는 종종 레거시 위에 얇게 덧댄 정규화 뷰로 시작한다.

그럴듯하게 틀린 침묵보다 명시적 에러가 낫다

"데이터가 어떤 포맷이어야 하나"에 대한 가장 설득력 있는 답은 의견이 아니라 숫자다. dbt의 2026년 벤치마크는 LLM이 데이터를 질의할 때 거버넌스된 시맨틱 레이어가 원시 text-to-SQL을 압도함을 보였다. 모델링된 데이터에서 Claude Sonnet 4.6은 98.2%(시맨틱 레이어) 대 90.0%(text-to-SQL), GPT-5.3-Codex는 100% 대 84.1%였다.¹¹

그런데 결정적 차이는 점수가 아니라 실패 방식이다. text-to-SQL은 그럴듯한 틀린 숫자를 조용히 내놓고, 시맨틱 레이어는 답할 수 없으면 명시적 에러를 던진다. 잘못된 데이터를 절대 반환하지 않는다.¹¹ 이건 이 블로그가 Text-to-SQL 글에서 다룬 문제이자, ADR 철학과 같은 발상이다. 비결정 시스템에서 신뢰는 정답률보다 "틀릴 때 어떻게 틀리는가"에서 나오기 때문이다.

그래서 "포맷"의 진짜 답은 스프레드시트가 아니라 계약이다.

이건 벤치마크 숫자만의 이야기가 아니다. 같은 프로젝트에서 조회의 상당 부분을 LLM이 생성하는 SQL로 처리할 전망이 서자, 데이터 모델 자체를 "text-to-SQL 가독성 1순위"로 설계하기로 했다. 세 가지가 핵심이었다. 첫째, 의미가 드러나는 일관된 테이블·컬럼 명명. 둘째, 행·권한 필터를 DB가 처리하게 해서 LLM이 만드는 SQL에 권한 조건 자체를 넣지 않아도 되게 했다(생성 SQL이 단순해지고, 권한 누락이라는 사고를 DB가 원천 차단한다). 셋째, 외부 소스의 난잡한 명명을 내부로 그대로 끌고 오지 않고 적재 단계에서 정제했다. 타입 선택까지 같은 원리가 내려갔다. status·stage 같은 고정값을 강제할 때 정석으로 보이는 native ENUM을 일부러 피하고 varchar에 CHECK 제약을 붙였는데, 근거가 정확히 LLM 친화성이었다. native ENUM은 생성 SQL에서 캐스팅 마찰을 만들고 허용값이 스키마 텍스트에 드러나지 않는 반면, CHECK 제약은 허용값이 제약 정의에 그대로 노출돼 LLM이 스키마를 읽을 때 함께 읽힌다. "중앙 정의가 없어 테이블마다 반복된다"는 비용을 알고도 덜 우아한 쪽을 택한 것이다. LLM을 위한 설계는 곧 사람을 위한 설계이기도 했다: 의도한 부수효과는 "스키마 자체가 문서가 된다"였다.

Open Data Contract Standard(ODCS, 2025년 12월 v3.1.0, LF AI & Data)는 데이터의 스키마·품질 규칙·SLA·소유자를 기계가 읽을 수 있는 형태로 명시한다.¹² 인테이크 4번 칸이 요청해야 할 것은 "엑셀을 주세요"가 아니라 "계약과 시맨틱 정의를 발행하세요"다.

같은 문제의 다른 끝: 컨텍스트 엔지니어링 (다운스트림)

업스트림에서 데이터를 갖췄어도, 추론 시점에 그걸 어떻게 떠먹이느냐가 남는다. 이게 다운스트림, 즉 컨텍스트 엔지니어링이다. Anthropic은 이를 "추론 중 최적의 토큰 집합을 큐레이팅하는 규율"로 정의하고, 핵심 격언을 **"원하는 결과를 낼 가능성을 극대화하는, 가장 작은 고신호 토큰 집합"**이라 말한다.¹³

여기서 중요한 반전이 context rot다. 토큰이 많아질수록 모델이 그 안의 정보를 정확히 회상하는 능력은 오히려 떨어진다.¹³ 컨텍스트는 공짜가 아니라 비용이다. 그래서 처방은 세 가지다.

• 구조화: 시스템 프롬프트·문서를 마크다운 헤더나 XML 섹션으로 나눈다. ## 섹션 제목은 문단과 의미가 다르고, 마크다운 표는 행-열 관계를 보존한다.
• just-in-time 회수: 모든 데이터를 앞에 쏟지 말고 파일 경로·쿼리 같은 가벼운 식별자로 필요할 때 가져온다.
• self-contained 청크: Anthropic의 Contextual Retrieval은 각 청크 앞에 그 청크만의 설명 맥락을 붙여 검색 실패를 35~49%(리랭커 결합 시 67%) 줄였다.¹⁴

마지막 항목이 익숙할 것이다. 이 시리즈가 계속 말한 **"self-contained ADR이 링크 거미줄보다 낫다"**와 정확히 같은 발견이다. 청크도 ADR처럼 혼자 서 있어야 한다.

이 세 처방은 블로그의 권고로만 끝나지 않는다. 같은 프로젝트는 AI의 상황 인지를 여러 레이어로 쪼개 설계했는데, 핵심 결정 하나만 옮기면 이렇다. 현재 페이지·핵심 상태 요약·최근 액션 같은 "상황 헤더"를 매 턴 대화 메시지로 쌓지 않고, 그 턴에만 합성되고 사라지는 별도 컨텍스트로 주입했다. 헤더를 메시지로 append하는 것은 "매 턴 재전송 안티패턴"으로 못 박아 금지했다. 상세 데이터는 앞에 쏟지 않고 AI가 필요할 때 도구로 당기게 하되, 당겨온 큰 결과가 쌓이면 미들웨어가 자동으로 비웠다. 다만 절약 도구 자체가 새 실패 모드를 만든다는 점도 같이 적혀 있었다: 요약 과정에서 메타데이터가 오히려 컨텍스트를 넘쳐 버린 사례가 있었다는 것이다. 그래서 "확정된 정량값 같은 핵심 도메인 상태는 요약·잘라내기에서 제외하고 보호한다"는 규칙을 함께 뒀다. context rot은 토큰을 무작정 줄이면 풀리는 문제가 아니라, 무엇을 절대 건드리지 않을지를 먼저 정하는 문제였다.

당신의 Wiki와 ADR이 곧 AI-ready 데이터 프로덕트다

여기서 두 끝이 만난다. 업스트림이 요구하는 것(거버넌스, self-contained, 계약, 의미 보존)과 다운스트림이 요구하는 것(마크다운 구조, self-contained 청크, 작은 고신호 집합)은 같다. 그리고 그 교집합을 만족하는 산출물을 당신은 이미 갖고 있다. 마크다운으로, self-contained하게, 거버넌스된 채로, 헤더 구조를 갖춰 유지되는 LLM Wiki와 ADR.

flowchart LR
  subgraph UP["업스트림: 데이터 준비"]
    U1[데이터 계약 ODCS]
    U2[DRL 밴드 C→B→A]
    U3[시맨틱 레이어]
  end
  subgraph MID["AI-ready 데이터 프로덕트"]
    M[당신의 Wiki + ADR<br/>마크다운·self-contained<br/>거버넌스된 mutable]
  end
  subgraph DOWN["다운스트림: 컨텍스트 엔지니어링"]
    D1[가장 작은 고신호 토큰]
    D2[context rot 주의]
    D3[헤더 구조 + JIT 회수]
  end
  UP --> MID --> DOWN

이건 검색 실험에서 다룬 RAG의 윗단이기도 하다.

"마크다운으로, self-contained하게, 거버넌스된 채로"는 듣기 좋은 형용사들이지만, 실제로는 운영 장치가 있어야 유지된다. 또 다른 한 사내 AI 빌더 프로젝트에서 본 패턴이 좋은 예다. 그 팀은 실행자가 안전하게 소비할 핵심 데이터 구조를 Pydantic 모델과 JSON Schema 두 벌로 두고, "둘이 드리프트하면 테스트가 거부한다"와 "모든 중첩 모델은 추가 필드를 금지한다(extra=forbid)"를 불변식으로 문서에 박아 뒀다. 생산자 쪽 정본 하나와 소비자 쪽 미러 하나를 두되 패키지 간 직접 import는 금지해 역할을 명문화했다. 더 흥미로운 건 런타임 동작을 좌우하는 메타데이터(도구의 예상 실행시간, 응답 크기, 폴링 필요 여부)를 코드가 아니라 데이터 컬럼과 카탈로그로 승격한 점이다. 그 결과 "새 도구 추가 = 데이터 한 줄, 이미지 재빌드 불필요"가 됐다. 같은 팀은 사람이 이름으로 검색·감사할 수 없는 표현(난수 ID로만 조회되고, 표시명이 비어 있고, 생성 로그가 없는 레코드)을 "데이터 준비도 결손"으로 버그 등록하기도 했다. 즉 AI-ready 데이터의 실체는 깨끗한 텍스트가 아니라 "계약을 어기면 빌드가 깨진다"까지 내려간 강제 구조다.

RAG가 원문을 회수한다면, 잘 구조화된 Wiki/ADR은 회수 이전에 이미 정제된 의미 레이어다. 그래서 인테이크 4번 칸의 올바른 산출물은 "스프레드시트를 보내라"가 아니라 **"계약 + 시맨틱 정의 + 마크다운 ADR/Wiki를 발행하라"**다. 도구(어떤 벡터DB, 어떤 모델)가 바뀌어도 이 마크다운과 계약은 남는다 - 8편에서 다룰 durable substrate의 핵심이다.

정리

• AI-ready 데이터는 미리 만들 수 없다(Gartner). 용도가 정해져야 무엇이 ready인지 정의된다. 같은 데이터가 워크로드마다 다른 점수를 받는다(Snowflake). 그래서 데이터·포맷은 인테이크에서 발견할 대상이다.
• 데모는 ML 코드라는 작은 박스, 프로덕션은 그 주변 인프라라는 빙산이다(Sculley). 시간에 쫓기면 기반이 건너뛰어지고, PoC의 다수가 프로덕션에 못 간다.
• 업스트림(DRL 밴드, 데이터 계약, 시맨틱 레이어)과 다운스트림(컨텍스트 엔지니어링, context rot, 마크다운 구조)은 한 문제의 양 끝이다.
• 신뢰는 정답률이 아니라 틀리는 방식에서 온다. 그럴듯하게 틀린 침묵보다 명시적 에러가 낫다(dbt 시맨틱 레이어 98100% vs 8490%).
• 당신이 만든 Wiki/ADR이 곧 AI-ready 데이터 프로덕트다. 인테이크는 "엑셀"이 아니라 "계약 + 마크다운"을 요청해야 한다.

다음 글에서는 6번째 주제로 넘어간다. 아무리 인테이크와 데이터를 잘 갖춰도 사양서는 100%를 덮지 못한다. 구현 중에 드러나는 빈틈을 결정 기록으로 흡수하고, 그게 다음 인터뷰의 입력으로 되먹이는 루프 이야기다.

참고 자료

AI-ready 데이터 (용도 의존)

• AI-Ready Data (Gartner)
• Organizations with successful AI invest up to 4x more in data foundations (Gartner, 2026-04)
• Data Readiness Levels (Neil Lawrence) / 360 Survey (arXiv 2404.05779)
• AWS Generative AI workload assessment questionnaire
• Amazon scraps AI recruiting tool that showed bias against women (Reuters)

데모-프로덕션 간극

• Hidden Technical Debt in Machine Learning Systems (Sculley et al., NeurIPS 2015)
• Gartner: 30% of GenAI projects abandoned after PoC by end 2025
• The GenAI Divide: State of AI in Business 2025 (MIT NANDA, via Fortune)
• 88% of AI pilots fail to reach production (IDC/Lenovo, via CIO.com)

포맷 · 시맨틱 · 컨텍스트 엔지니어링

• Semantic Layer vs Text-to-SQL 2026 Benchmark (dbt)
• Open Data Contract Standard (ODCS, Bitol / LF AI & Data)
• Effective context engineering for AI agents (Anthropic)
• Introducing Contextual Retrieval (Anthropic)
• Snowflake AI-Ready Data Framework (Snowflake Labs)