LLM 개발에서 AI-Ready Data가 중요한 이유

한상우·2026년 4월 23일
AILLM

AI

목록 보기
7/11
post-thumbnail

LLM 개발에서 AI-Ready Data가 중요한 이유 — 메타데이터와 시멘틱 데이터 이야기

"비싼 AI를 썼는데도 우리 회사 챗봇은 왜 이렇게 바보 같죠?"
"RAG 붙였는데 엉뚱한 문서만 가져와요."
"Text-to-SQL 붙였더니 매출을 이상하게 집계해요."

LLM 프로젝트가 막힐 때 열에 아홉은 모델 문제가 아닙니다. 데이터 문제입니다. 그리고 그 데이터 문제의 본질은 대개 이것으로 요약됩니다.

"우리 데이터는 사람이 읽을 수는 있지만, AI가 이해할 수 있는 상태는 아니다."

이 글에서는 AI-Ready Data(AI가 바로 쓸 수 있는 데이터) 가 왜 중요한지, 그 핵심인 메타데이터(Metadata) 와 시멘틱 데이터(Semantic Data) 가 LLM 파이프라인에서 어떤 역할을 하는지 정리합니다.

1. AI-Ready Data란 무엇인가

흔히 "데이터가 있다"고 말할 때, 우리가 가진 건 대개 이런 것들입니다.

  • 수십 개의 테이블이 있는 데이터 웨어하우스
  • 사내 위키, Confluence, Notion, PDF가 뒤섞인 문서 저장소
  • CRM·ERP·분석 시스템에 분산된 고객/매출 정보

문제는 이 데이터들이 "사람이 열어보고 맥락을 짐작해야 쓸 수 있는" 상태라는 점입니다. TBL_CUST_MST_2024_V3라는 테이블명, col_a, col_b라는 컬럼명, 파일명만 보면 내용을 알 수 없는 PDF들 — LLM에게는 암호문이나 다름없습니다.

AI-Ready Data는 한 줄로 이렇게 정의할 수 있습니다.

AI가 추가 해석 없이도 정확하게, 안전하게, 추적 가능하게 사용할 수 있도록 구조화·문서화·표준화된 데이터.

구체적으로는 네 가지 속성을 갖춥니다.

속성의미
Contextual데이터의 의미·출처·용법이 명시되어 있음
Structured스키마·타입·관계가 일관되게 정의됨
Governed권한·민감도·품질이 관리됨
Discoverable카탈로그·검색을 통해 쉽게 찾을 수 있음

이 네 가지를 가능하게 만드는 핵심 재료가 바로 메타데이터 와 시멘틱 데이터 입니다.

2. 메타데이터 — "데이터에 대한 데이터"

메타데이터는 데이터 자체가 아니라 데이터를 둘러싼 설명입니다. "이 데이터가 무엇인지, 어디서 왔는지, 어떻게 써야 하는지"를 말해주는 라벨입니다.

2.1 메타데이터의 4가지 유형

① 기술 메타데이터 (Technical)
스키마, 컬럼 타입, 포맷, 크기, 파티션 키 등 시스템이 처리하는 데 필요한 정보.
예: customer_id: BIGINT NOT NULL, PRIMARY KEY

② 비즈니스 메타데이터 (Business)
도메인 용어, 정의, 소유자, 관련 KPI 등 사람과 LLM이 의미를 이해하는 데 필요한 정보.
예: customer_id는 "결제를 완료한 고객의 고유 식별자이며, 환불·탈퇴 고객 포함".

③ 운영 메타데이터 (Operational)
생성/수정 시각, ETL 파이프라인 이름, 업데이트 주기, 데이터 계보(Lineage).
예: "이 테이블은 매일 새벽 3시 sales_etl_daily 잡으로 갱신됨".

④ 거버넌스 메타데이터 (Governance)
접근 권한, 민감도 등급(PII 여부), 보존 정책, 라이선스.
예: "이 컬럼은 PII, 마스킹 없이 LLM 프롬프트에 넣지 말 것".

2.2 메타데이터가 LLM에게 하는 일

LLM이 데이터를 다룰 때 메타데이터가 없으면 벌어지는 일들:

  • 환각: 컬럼명을 보고 "아마 이런 뜻일 것"이라고 추측해서 답변 생성
  • 엉뚱한 조인: 관계가 명시되지 않아 FK 없는 테이블을 임의로 연결
  • 정의 충돌: "활성 고객"의 정의가 부서마다 달라 잘못된 집계
  • 보안 사고: PII가 마스킹 없이 프롬프트에 흘러들어 로그에 남음

반대로 메타데이터가 잘 정비되어 있으면 LLM은 이렇게 작동합니다.

  • orders.status = 'completed'가 "결제 완료이고 환불되지 않은 상태"라는 정의를 알고
  • orders.customer_id → customers.id라는 관계를 알고
  • customers.email이 PII라서 답변에 포함하면 안 된다는 정책을 알고
  • 데이터가 어제 03:17 기준으로 업데이트됐다는 신선도를 알고 답합니다.

이 차이가 프로토타입과 프로덕션의 차이를 만듭니다.

3. 시멘틱 데이터 — "의미의 표준화"

메타데이터가 "각 데이터가 무엇인지"를 설명한다면, 시멘틱 데이터는 한 걸음 더 나아가 "조직 전체가 같은 의미를 공유하도록" 만듭니다.

3.1 시멘틱 데이터가 해결하는 문제

같은 회사 안에서도 이런 혼란이 흔합니다.

  • 마케팅팀의 "매출"은 VAT 포함, 재무팀의 "매출"은 VAT 제외
  • "활성 사용자"가 누군가에겐 "7일 내 로그인", 누군가에겐 "30일 내 결제"
  • revenue, sales, gmv, net_sales 컬럼이 DB 곳곳에 흩어져 있음

사람이 회의에서 조율해도 헷갈리는 이 정의들을, LLM은 스스로 해결할 수 없습니다. 누군가가 의미의 단일 출처(Single Source of Truth) 를 만들어 AI에게 제공해야 합니다.

3.2 시멘틱 레이어 (Semantic Layer)

최근 데이터 플랫폼에서 뜨거운 개념이 바로 시멘틱 레이어입니다. 원본 테이블과 사용자(또는 AI) 사이에 의미를 표준화한 중간 층을 두는 것이죠.

[원본 DB]  ──  [시멘틱 레이어]  ──  [LLM / BI / API]
 raw tables    Metric 정의 중앙화    질문 → 올바른 쿼리

시멘틱 레이어에서는 다음과 같은 것들을 한 곳에 정의합니다.

  • Entity: customer, order, product...
  • Dimension: 지역, 카테고리, 기간...
  • Metric: monthly_active_users, net_revenue, churn_rate...
  • Relationship: order ↔ customer (many-to-one)

대표 도구로는 dbt Semantic Layer, Cube, LookML, MetricFlow 등이 있습니다. 이런 레이어가 있으면 LLM이 "지난 분기 순매출"이라는 질문을 받아도 net_revenue라는 단일 정의에 매핑해 늘 일관된 답을 냅니다.

3.3 지식 그래프와 온톨로지

비정형 데이터 영역에서 시멘틱 데이터는 지식 그래프(Knowledge Graph) 와 온톨로지(Ontology) 형태로 구현됩니다.

  • 온톨로지: 도메인의 개념·관계를 정식으로 정의한 모델 (예: "의사는 환자를 진료한다")
  • 지식 그래프: 실제 엔티티들을 노드와 엣지로 연결한 데이터 (예: Dr.김 - 진료 - 환자A)

지식 그래프 기반 RAG(GraphRAG)는 단순 벡터 검색보다 "여러 문서에 걸친 관계형 질문"에 훨씬 강합니다. 예를 들어 "A 프로젝트에 참여했던 사람들이 과거에 함께 썼던 기술 스택은?" 같은 질문이 그런 경우입니다.

4. RAG 파이프라인에서 메타데이터가 일하는 방식

앞선 글에서 다룬 RAG를 다시 떠올려보죠. 메타데이터는 RAG의 모든 단계에서 성능을 끌어올립니다.

[인덱싱 시]
문서 + 메타데이터(부서, 날짜, 작성자, 문서유형, 권한) → 벡터DB

[검색 시]
질문 → 임베딩 → 벡터 유사도 검색
                    +
            메타데이터 필터 (날짜 ≥ 2024, 부서 = 영업)
                    ↓
              관련성 ↑ 노이즈 ↓

[생성 시]
프롬프트에 출처·날짜 메타데이터 포함 → LLM이 인용 가능

4.1 메타데이터 필터링의 힘

"작년 1분기 영업팀 회의록에서 가격 정책 얘기 찾아줘"

순수 벡터 검색만으론 이 질문을 제대로 풀기 어렵습니다. '2024년 1분기', '영업팀', '회의록'이라는 구조적 조건이 핵심인데, 임베딩은 의미 유사도만 봅니다. 반면 메타데이터 필터를 걸면:

retriever.search(
    query="가격 정책",
    filter={
        "department": "sales",
        "doc_type": "meeting_minutes",
        "date": {"$gte": "2024-01-01", "$lte": "2024-03-31"}
    }
)

후보 공간을 수백 배 줄이고, 의미 검색은 그 안에서만 돌아갑니다. 정확도·속도·비용이 모두 개선됩니다.

4.2 권한 기반 검색 (Access-Aware Retrieval)

엔터프라이즈 RAG에서 빠질 수 없는 요소입니다. 각 청크에 acl: ["team-sales", "role-manager"] 같은 메타데이터를 붙여두면, 사용자의 토큰에 맞춰 사전 필터링 후 검색할 수 있습니다. 이걸 안 하면 LLM이 "보면 안 되는 문서"를 요약해 보여주는 사고가 납니다.

4.3 인용과 신뢰성

"이 답변은 2024 Q2 제품전략_v3.pdf의 12페이지를 근거로 했습니다." — 이런 인용이 가능한 이유는 메타데이터 덕분입니다. 사용자가 검증할 수 있고, 환각 여부를 확인할 수 있으며, 법적·규제 요구사항에도 대응할 수 있습니다.

5. Text-to-SQL에서 시멘틱 데이터의 결정적 역할

LLM이 가장 많이 실수하는 영역 중 하나가 Text-to-SQL입니다. 이유는 단순합니다 — 스키마만으로는 비즈니스 의미를 모르기 때문입니다.

5.1 순수 스키마만 줄 때의 한계

-- LLM이 보는 것
CREATE TABLE orders (
  id BIGINT,
  cust_id BIGINT,
  amt DECIMAL,
  st VARCHAR,
  created_at TIMESTAMP
);

"이번 달 매출 알려줘"라는 질문에, LLM은:

  • amt가 세전인지 세후인지 모릅니다.
  • st 컬럼에 어떤 값들이 있고 어떤 게 '완료'인지 모릅니다.
  • 환불은 어떻게 처리해야 하는지 모릅니다.
  • '이번 달'이 회계월인지 캘린더월인지 모릅니다.

5.2 시멘틱 레이어가 주어졌을 때

metric:
  name: monthly_net_revenue
  description: 월별 순매출 (환불 차감, VAT 제외)
  sql: |
    SUM(CASE WHEN o.status = 'completed' THEN o.amount_excl_vat ELSE 0 END)
    - SUM(COALESCE(r.refund_amount, 0))
  dimensions: [calendar_month, region, product_category]
  owner: finance-team

이제 LLM은 "이번 달 매출"이라는 질문을 monthly_net_revenue 라는 정의된 메트릭에 매핑하기만 하면 됩니다. 쿼리를 지어내지 않고 참조합니다. 환각이 사라지고, 전사적으로 숫자가 일치하기 시작합니다.

6. AI-Ready Data를 구축하기 위한 실무 체크리스트

완벽한 AI-Ready 상태를 한 번에 만들 수는 없습니다. 단계적으로 접근하는 게 현실적입니다.

6.1 데이터 카탈로그부터 시작하기

DataHub, OpenMetadata, Amundsen, Collibra 같은 카탈로그 도구로 무엇이 어디에 있는지부터 가시화하세요. 카탈로그 자체가 LLM의 지식 소스가 되어 "어떤 테이블을 써야 하지?"에 답할 수 있게 됩니다.

6.2 메타데이터 품질의 최소 기준 정하기

모든 테이블에 다음은 필수로 요구해볼 만합니다.

  • 테이블·컬럼 설명 (한국어/영어)
  • 데이터 소유자(Owner)
  • 업데이트 주기
  • PII/민감도 태그
  • 주요 관계(FK) 명시

6.3 시멘틱 레이어 도입 검토

BI 도구마다 지표가 다르게 계산되는 문제가 있다면 시멘틱 레이어 도입을 진지하게 고려할 때입니다. dbt를 이미 쓴다면 dbt Semantic Layer가 자연스러운 출발점입니다.

6.4 비정형 문서에도 메타데이터 붙이기

사내 문서 저장소에도 최소한의 메타데이터 규칙을 적용하세요.

  • 문서 유형 (정책 / 회의록 / 매뉴얼 / 제안서)
  • 작성일·수정일
  • 작성자·부서
  • 공개 범위
  • 버전·상태(초안/최종/폐기)

이 정보가 없으면 RAG는 "10년 전 폐기된 정책 문서"를 근거로 답변하게 됩니다.

6.5 데이터 품질·신선도 모니터링

AI-Ready Data는 한 번 만들고 끝나는 것이 아닙니다. Great Expectations, Soda, Monte Carlo 같은 도구로 지속적인 품질 검증을 붙이세요. LLM은 "데이터가 지금 깨져 있다"는 걸 혼자 알아채지 못합니다.

6.6 Feedback Loop 만들기

LLM 응답이 틀렸을 때, 그 원인이 데이터 문제인지 모델 문제인지 구분할 수 있어야 합니다. 로깅·추적·평가(LangSmith, RAGAS 등)를 통해 문제가 데이터로 피드백되는 고리를 만들어야 AI-Ready 상태가 유지됩니다.

7. 관점 바꾸기 — "모델 성능"에서 "데이터 준비도"로

많은 팀이 여전히 "더 좋은 모델만 있으면" 문제가 풀릴 거라 기대합니다. 하지만 현업에서 체감하는 현실은 이쪽에 가깝습니다.

같은 LLM 모델을 쓰더라도, AI-Ready Data를 갖춘 팀과 그렇지 않은 팀의 결과물은 체감상 전혀 다른 제품이다.

모델은 상향 평준화되고 있고, 앞으로 더 그럴 겁니다. 차별화는 점점 "우리 조직의 지식과 데이터를 얼마나 AI가 잘 쓰도록 준비했는가" 로 이동하고 있습니다. 오랫동안 데이터 엔지니어링·거버넌스·시맨틱 모델링을 해온 조직이 갑자기 LLM 시대에 유리한 고지를 점하는 이유입니다.

8. 정리

개념역할LLM에서 얻는 효과
메타데이터데이터의 맥락·소유·정책·계보 기술정확한 검색, 인용, 권한 제어, 환각 감소
시멘틱 데이터조직 전체가 공유하는 의미의 표준화일관된 지표, Text-to-SQL 신뢰성, 관계 추론
AI-Ready Data위 둘을 포함해 AI가 바로 쓸 수 있게 정돈된 상태프로토타입 → 프로덕션으로 넘어가는 전제 조건

LLM 시대의 경쟁력은 "어떤 모델을 쓰느냐" 가 아니라 "그 모델에게 무엇을 먹이느냐" 에서 갈립니다. 그리고 무엇을 먹일지를 결정하는 건 모델이 아니라, 우리가 준비한 데이터입니다.

Garbage in, Garbage out은 AI 시대에도 유효합니다.
오히려 LLM은 쓰레기도 그럴듯한 쓰레기로 포장해주기 때문에 더 위험합니다.

profile
한상우
안녕하세요
이전 포스트

WelFareAI 프로젝트

다음 포스트

MCP 만들기 3편

0개의 댓글