AI가 안 되는 건 모델 탓이 아니다 — AI-Ready Data의 조건

“데이터가 좀 지저분한데, AI 붙이면 알아서 정리해주겠지.” “RAG 연결하면 사내 문서도 다 검색될 거야.” “LLM이 똑똑하니까 구조화 안 된 데이터도 이해하겠지.”

이런 기대로 시작한 프로젝트가 어떻게 되는지, 이미 겪어본 사람이 많을 것이다. 안 된다. 그리고 왜 안 되는지 모르겠다. 모델을 바꿔봐도, 프롬프트를 고쳐봐도, RAG를 붙여봐도 근본적으로 나아지지 않는다.

Metadata Weekly는 이걸 “2026 AI Reality Check”라고 불렀다 — 문제는 모델이 아니라 기반(Foundation)이다. 그리고 그 기반의 핵심은 데이터다.

숫자가 말하는 현실

이건 스타트업만의 문제가 아니다. 엔터프라이즈도 같은 벽에 부딪히고 있다.

”AI 붙이면 된다” 사고의 함정

함정 1: LLM이 지저분한 데이터를 “이해”할 거라는 착각

LLM은 패턴 매칭 엔진이다. 입력이 일관되고 구조적이면 놀라운 결과를 내지만, 입력이 모순적이고 불완전하면 **“그럴듯하게 틀린 답”**을 만들어낸다. 연구에 따르면, 프롬프트에 무관한 정보가 섞이면 정답률이 95%에서 60%대로 떨어진다. 모델은 노이즈를 걸러내지 않는다 — 노이즈도 패턴의 일부로 학습한다.

함정 2: RAG를 붙이면 다 해결될 거라는 착각

RAG는 마법이 아니다. RAG의 품질은 검색 품질에 의존하고, 검색 품질은 데이터 품질에 의존한다. Atlan은 이걸 명확히 짚는다 — “데이터 품질 문제는 모델 문제가 아니라 컨텍스트 문제다.” RAG가 안 되는 이유를 정리하면:

RAG 실패 원인	근본 문제
관련 문서가 검색되지 않음	청킹이 의미 단위가 아님, 메타데이터 부재
검색되지만 답이 틀림	원본 데이터 자체가 모순적이거나 오래됨
할루시네이션 발생	핵심 필드가 null, 비즈니스 정의가 없음
답이 들쭉날쭉	같은 개념에 대한 용어가 문서마다 다름
보안·권한 문제	접근 제어 없이 모든 문서를 색인

함정 3: “나중에 정리하면 된다”는 착각

데이터 정리를 나중으로 미루면, AI 파이프라인 위에 기술 부채가 쌓인다. 처음에 “대충 돌아가는” 프로토타입을 만들고, “나중에 데이터 정리하면 되겠지”라고 생각하면 — 그 “나중”은 오지 않는다. 프로토타입이 프로덕션이 되고, 데이터 문제가 시스템 전체에 전파된다.

개발자 인사이트

Garbage In, Garbage Out은 AI 시대에 더 위험하다. 전통적인 시스템은 잘못된 데이터가 들어오면 에러를 뱉었다. AI는 잘못된 데이터가 들어와도 “그럴듯한 답”을 만들어낸다. 에러가 보이지 않기 때문에 문제를 더 늦게 발견하고, 더 깊이 전파된다.

AI-Ready Data의 5가지 기준

Deloitte의 AI Data Readiness 프레임워크와 IBM의 데이터 품질 가이드를 기반으로, AI-Ready Data의 핵심 기준을 정리하면:

1. 가용성 (Availability)

AI가 데이터에 접근할 수 있는가?

데이터가 사일로에 갇혀 있지 않은가?
API, DB, 파일 시스템 등으로 프로그래매틱하게 접근 가능한가?
실시간성이 필요한 데이터인가, 배치로 충분한가?

흔한 문제: “데이터는 있는데 SharePoint 어딘가에 PDF로 묻혀 있다.” 이건 있는 게 아니라 없는 거다.

2. 품질 (Quality)

데이터가 정확하고 일관되고 완전한가?

정확성: 현실을 반영하는가? 오래된 정보는 없는가?
일관성: 같은 개념을 같은 용어로 표현하는가? “고객”, “사용자”, “유저”가 같은 걸 가리키는가?
완전성: 핵심 필드에 null이 없는가? 필수 정보가 빠져 있지 않은가?
중복: 같은 데이터가 여러 곳에 다른 버전으로 존재하지 않는가?

흔한 문제: “고객사 이름이 문서마다 다르다 — (주)ABC, ABC주식회사, ABC.” AI는 이걸 같은 회사로 인식하지 못할 수 있다.

3. 구조 (Structure)

데이터가 AI가 소비할 수 있는 형태인가?

스키마가 정의되어 있는가?
비정형 데이터(PDF, 이미지, 자유 텍스트)는 파싱 및 구조화 전략이 있는가?
관계가 명시적인가? (A는 B에 속한다, C는 D를 참조한다)

흔한 문제: “모든 정보가 자연어 문서 안에 녹아 있다.” 사람은 읽으면 이해하지만, AI가 특정 정보를 추출하려면 구조가 필요하다.

4. 거버넌스 (Governance)

데이터의 출처, 권한, 생명주기가 관리되는가?

누가 이 데이터를 만들었고, 언제 마지막으로 업데이트됐는가?
누가 접근해도 되는 데이터인가?
데이터의 유효 기간은 언제까지인가?

흔한 문제: “2년 전 내부 매뉴얼을 RAG에 넣었는데, 현재 정책과 다르다.” AI는 오래된 데이터와 최신 데이터를 구별하지 못한다.

5. 유스케이스 정렬 (Use-Case Alignment)

데이터가 실제 AI 활용 목적에 맞게 설계되었는가?

AI에게 무엇을 시키려는가? 그 작업에 필요한 데이터가 충분한가?
데이터의 granularity(세분화 수준)가 유스케이스에 맞는가?
평가 기준이 정의되어 있는가? (AI가 “잘” 했는지를 어떻게 아는가?)

흔한 문제: “전사 데이터를 다 넣었는데 원하는 답이 안 나온다.” 모든 데이터를 넣는 것보다 목적에 맞는 데이터만 정확하게 넣는 것이 낫다.

실전: “안 될 때” 진단 플로우

AI가 기대한 결과를 내지 않을 때, 어디가 문제인지 진단하는 순서:

AI 결과가 이상하다
  │
  ├─ 1단계: 입력 데이터 확인
  │   ├─ 원본 데이터에 답이 있는가? → 없으면 데이터 수집 문제
  │   ├─ 데이터가 정확한가? → 틀리면 데이터 품질 문제
  │   └─ 데이터 형태가 AI가 소비 가능한가? → 아니면 구조화 문제
  │
  ├─ 2단계: 검색/컨텍스트 확인 (RAG인 경우)
  │   ├─ 관련 문서가 검색되는가? → 안 되면 임베딩/청킹 문제
  │   ├─ 검색된 문서가 실제로 관련 있는가? → 아니면 메타데이터/필터링 문제
  │   └─ 컨텍스트 윈도우에 적절한 양이 들어가는가? → 아니면 청킹 크기 문제
  │
  └─ 3단계: 모델/프롬프트 확인
      ├─ 프롬프트가 명확한가?
      ├─ 모델이 이 태스크에 적합한가?
      └─ 출력 형식이 정의되어 있는가?

대부분의 문제는 1단계에서 발견된다. 모델이나 프롬프트를 고치기 전에 데이터를 먼저 봐야 한다.

데이터 구조화: 단계별 접근

Step 1: 데이터 인벤토리 — 뭐가 있는지부터 파악

AI 프로젝트의 첫 번째 단계는 코드를 쓰는 게 아니라 데이터를 파악하는 것이다.

어떤 데이터 소스가 있는가? (DB, 문서, API, 스프레드시트)
각 소스의 형태는? (정형, 반정형, 비정형)
데이터의 양은? 업데이트 빈도는?
소유자는 누구이고, 접근 권한은?

Step 2: 스키마 설계 — 관계와 규칙을 명시적으로

데이터의 구조를 정의한다. 이건 DB 테이블 설계만 의미하는 게 아니다.

엔티티 정의: 핵심 개체는 무엇인가? (고객, 제품, 주문, 문서)
관계 정의: 엔티티 간 관계는? (고객은 주문을 한다, 문서는 제품에 속한다)
속성 정의: 각 엔티티의 핵심 속성은? (고객명, 등급, 가입일)
제약 조건: 필수 필드, 유효 범위, 유니크 키

비정형 데이터(문서, PDF)도 구조를 부여할 수 있다:

문서 유형별 분류 (계약서, 매뉴얼, FAQ)
섹션별 태깅 (제목, 본문, 표, 부록)
메타데이터 부여 (작성일, 작성자, 버전, 적용 범위)

Step 3: 정규화와 정제 — 일관성을 만든다

용어 통일: “고객” = “사용자” = “유저” → 하나로 통일
형식 표준화: 날짜 형식, 전화번호 형식, 주소 형식
중복 제거: 같은 엔티티의 여러 버전 → 하나의 정본(golden record)
결측값 처리: null인 필드는 채울 수 있는가, 아니면 명시적으로 “없음”인가?

Step 4: AI 소비 형태로 변환

데이터가 정리되면, AI가 사용할 형태로 변환한다:

RAG용: 의미 단위 청킹 + 메타데이터 태깅 + 임베딩
에이전트용: 구조화된 API/DB 접근 + 명확한 스키마 문서
파인튜닝용: 입력-출력 쌍 데이터셋 + 품질 검수

온톨로지와 지식 그래프 — 다음 단계의 예고

데이터 구조화를 더 깊이 가면, **온톨로지(Ontology)**와 **지식 그래프(Knowledge Graph)**를 만나게 된다.

온톨로지: 도메인의 개념과 관계를 형식적으로 정의한 체계. “고객은 주문을 하고, 주문은 제품을 포함하고, 제품은 카테고리에 속한다”를 기계가 이해할 수 있는 형태로 표현한다.
지식 그래프: 온톨로지를 기반으로 실제 데이터를 노드와 엣지로 연결한 그래프 구조.

최근 연구에 따르면, 온톨로지 기반 지식 그래프를 RAG에 적용하면 벡터 검색만 사용한 경우보다 성능이 크게 향상되며, 특히 DB 스키마에서 온톨로지를 추출하는 방식이 비용 효율적이고 유지보수가 쉽다는 결과가 나오고 있다.

이 주제는 별도 가이드로 정리했다. **온톨로지 & 지식 그래프 가이드**에서 스펙트럼, 트리플, GraphRAG 벤치마크, 도구 생태계, 실전 시작법을 다룬다. 여기서는 **“데이터 구조화의 끝판왕은 온톨로지와 지식 그래프”**라는 것만 기억하자. 데이터를 잘 구조화하는 것이 결국 온톨로지를 향한 첫 걸음이다.

개발자 인사이트

데이터 구조화는 스펙트럼이다. 태그 하나 붙이는 것부터 온톨로지를 설계하는 것까지. 처음부터 온톨로지를 만들 필요는 없다. 하지만 데이터에 이름을 붙이고, 관계를 정의하고, 일관성을 부여하는 첫 번째 단계를 건너뛰면 — AI를 아무리 좋은 모델로 바꿔도 결과는 나아지지 않는다.

결론: AI 프로젝트의 80%는 데이터에서 결정된다

모델은 매달 더 좋아지고 있다. 프롬프트 기법은 매주 새로운 것이 나온다. 하지만 데이터가 준비되지 않으면, 이 모든 발전이 무의미하다.

VentureBeat가 “RAG is dead, what’s old is new again”이라고 선언한 건, RAG 기술 자체가 죽었다는 뜻이 아니다. 데이터 기본기 없이 RAG만 붙이는 접근이 죽었다는 뜻이다. “옛날 것이 다시 돌아온다”는 건, 데이터 모델링, 스키마 설계, 품질 관리 같은 기본기가 다시 중요해졌다는 뜻이다.

AI를 잘 쓰려면 개발을 잘 해야 하고, 개발을 잘 하려면 데이터를 잘 다뤄야 한다. DX → Data → AX, 이 순서를 건너뛸 수 없다.

참고 자료

체크리스트: 내 데이터는 AI-Ready인가?

데이터 소스를 전수 파악했는가? (인벤토리)
핵심 엔티티와 관계가 정의되어 있는가? (스키마)
용어와 형식이 통일되어 있는가? (정규화)
핵심 필드에 null이나 중복이 없는가? (품질)
데이터의 출처와 갱신일이 추적되는가? (거버넌스)
AI 활용 목적에 맞는 데이터만 선별했는가? (유스케이스 정렬)
비정형 데이터에 메타데이터를 부여했는가? (구조화)
AI가 안 될 때 데이터부터 확인하는 습관이 있는가? (진단)