AI-ready 데이터와 기업 지식 시스템

모델보다 먼저 무너지는 곳

8장에서 우리는 엔터프라이즈 AI의 성패가 "도입했는가"가 아니라 "성과를 냈는가"로 판가름 난다는 사실을 살펴보았다. 그런데 막상 기업 현장에 들어가 보면 ROI를 가로막는 첫 번째 벽은 의외로 모델이 아니다. 최신 추론 모델을 붙였고, 멋진 챗봇 화면도 만들었고, 임원 시연도 성공했는데 실제 업무에 투입되는 순간 답변이 흔들린다. 고객에게 예전 환불 규정을 안내하고, 이미 폐기된 영업 자료를 근거로 제안서를 만들며, 접근 권한이 없는 인사 정보를 요약해 버린다.

이때 많은 조직은 "더 좋은 모델을 써야 하나?"라고 묻는다. 하지만 더 정확한 질문은 따로 있다. "우리 회사의 데이터와 지식은 AI가 믿고 사용할 수 있는 상태인가?"

AI는 마법의 독심술사가 아니다. 기업 내부 문서가 흩어져 있고, 같은 정책의 버전이 세 개씩 존재하며, 고객 데이터의 필드명이 부서마다 다르고, 파일 권한이 실제 조직 권한과 맞지 않는다면 아무리 뛰어난 모델도 안정적으로 일하기 어렵다. 모델은 말을 유창하게 만들 수 있지만, 그 말이 회사의 최신 사실에 근거했는지는 데이터와 지식 시스템이 결정한다.

그래서 2026년의 기업 AI 논의는 점점 "모델을 무엇으로 고를 것인가"에서 "AI가 사용할 수 있는 데이터 기반을 어떻게 만들 것인가"로 이동하고 있다. IBM은 AI-ready data를 고품질이고 접근 가능하며 신뢰할 수 있어 AI 학습과 활용에 자신 있게 쓸 수 있는 정보로 설명한다. 또한 2024년 IBM Institute for Business Value 조사에서 기술 리더 중 자사 데이터가 생성형 AI를 확장하기에 필요한 품질, 접근성, 보안 기준을 충족한다고 강하게 동의한 비율은 29%에 그쳤다고 밝혔다.¹ 이 숫자는 기업 AI의 병목이 GPU나 모델 API만이 아니라, 훨씬 오래된 문제인 데이터 관리에 있다는 사실을 보여준다.

좋은 모델은 가능성을 열어 준다. 그러나 좋은 데이터는 그 가능성을 업무로 바꾼다. 이 장의 핵심은 바로 여기에 있다. 기업 AI의 실제 성능은 모델의 파라미터 수보다 데이터의 정확성, 계보, 권한, 신선도, 구조화 수준에 의해 더 자주 결정된다.

AI-ready 데이터란 무엇인가

AI-ready 데이터는 단순히 "깨끗한 데이터"가 아니다. 엑셀의 빈칸을 채우고, 중복 행을 지우고, 날짜 형식을 맞추는 일도 중요하지만 그것만으로는 부족하다. AI-ready 데이터란 AI가 학습하거나 추론하거나 검색하거나 행동할 때 바로 사용할 수 있도록 의미, 맥락, 권한, 출처가 함께 정리된 데이터다.

예를 들어 고객 상담 AI를 만든다고 해 보자. 고객명, 상품명, 계약일, 문의 이력, 환불 정책, 내부 처리 매뉴얼이 모두 어딘가에는 있다. 하지만 CRM에는 고객명이 있고, ERP에는 계약 정보가 있고, 콜센터 시스템에는 상담 기록이 있고, 사내 위키에는 정책 문서가 있으며, 법무팀 드라이브에는 최신 약관 PDF가 있다. 이 데이터들이 서로 연결되어 있지 않다면 AI는 "알고 있는 것처럼" 답할 뿐 실제로는 조직의 기억에 접근하지 못한다.

AI-ready 데이터에는 몇 가지 기본 조건이 필요하다.

• 품질: 값이 정확하고, 중복과 오류가 적으며, 결측과 이상치가 관리되어야 한다.

• 맥락: 데이터가 무엇을 의미하는지 설명하는 메타데이터가 있어야 한다.

• 계보: 누가, 언제, 어떤 과정으로 만들고 수정했는지 추적할 수 있어야 한다.

• 권한: 누가 볼 수 있고, 어떤 모델이나 에이전트가 사용할 수 있는지 통제되어야 한다.

• 신선도: 오래된 데이터와 최신 데이터를 구분하고, 갱신 주기와 변경 이력을 알 수 있어야 한다.

• 재사용성: 특정 프로젝트 한 번에만 쓰고 버리는 데이터가 아니라 여러 AI 서비스가 공통 기반으로 활용할 수 있어야 한다.

특히 계보와 권한은 생성형 AI 시대에 더 중요해졌다. 기존 데이터 분석에서는 잘못된 데이터가 들어가면 잘못된 리포트가 나왔다. 생성형 AI에서는 잘못된 데이터가 들어가면 그럴듯한 문장, 자동 작성된 이메일, 승인 요청, 고객 안내, 코드 변경으로 이어질 수 있다. 오류가 단순한 숫자 하나에 머물지 않고 업무 행동으로 확장된다.

데이터 계보는 "이 답변이 어디에서 왔는가"를 추적하는 장치다. AI가 "이 고객은 프리미엄 등급입니다"라고 말했을 때, 그 판단이 어제 동기화된 CRM에서 온 것인지, 6개월 전 추출한 CSV에서 온 것인지 알 수 있어야 한다. 권한은 "이 AI가 이 정보를 봐도 되는가"를 결정하는 장치다. 사원이 인사 평가 정보를 볼 수 없다면, 그 사원이 사용하는 AI 비서도 그 정보를 볼 수 없어야 한다. AI는 사람보다 빠르게 검색하고 결합하므로, 권한 설계가 느슨하면 데이터 유출의 속도도 빨라진다.

한국에서도 이런 흐름은 공공데이터 정책으로 나타나고 있다. 행정안전부는 AI가 학습·분석·추론에 쉽게 활용할 수 있도록 정제·가공된 'AI-Ready 공공데이터' 개념을 도입하며, AI가 직접 읽고 이해할 수 있는 포맷, 풍부한 메타데이터, 표준코드, 품질 기준 등을 강조했다.² 이는 공공 영역만의 이야기가 아니다. 기업 역시 AI 시대의 데이터 정책을 "사람이 내려받아 가공하는 데이터"에서 "기계가 즉시 이해하고 사용할 수 있는 데이터"로 바꾸어야 한다.

RAG는 기업 AI의 기억 연결 장치다

기업이 생성형 AI를 업무에 붙일 때 가장 먼저 만나는 기술이 RAG다. RAG는 Retrieval-Augmented Generation, 즉 검색 증강 생성이다. 말 그대로 답변을 만들기 전에 외부 지식 저장소에서 관련 정보를 검색하고, 그 검색 결과를 모델에게 함께 제공해 답변을 생성하는 방식이다.

일반적인 LLM은 훈련 시점에 배운 지식을 바탕으로 답한다. 그래서 회사 내부 문서, 어제 바뀐 규정, 특정 고객의 최신 계약 조건은 알 수 없다. 반면 RAG는 질문이 들어온 순간 사내 문서, 매뉴얼, 규정, 티켓, 고객 기록을 검색한 뒤 "이 자료를 근거로 답하라"고 모델에게 지시한다. 모델의 기억에만 의존하지 않고 기업의 지식 저장소에 접속시키는 셈이다.

예를 들어 직원이 "육아휴직 복귀 후 단축근무 신청 절차가 어떻게 되나요?"라고 묻는다. RAG가 없다면 모델은 일반적인 노동 제도 지식을 바탕으로 답할 가능성이 높다. 그러나 기업마다 내부 승인 절차, 양식, 제출 기한, 담당 부서가 다르다. RAG 시스템은 최신 인사 규정 문서와 HR 포털 안내문을 검색하고, 그 내용을 바탕으로 "사내 포털의 A 양식을 작성해 팀장 승인 후 HR 운영팀에 제출해야 하며, 복귀 예정일 30일 전까지 신청해야 합니다"처럼 회사별 답변을 만든다. 중요한 것은 답변 끝에 출처 문서가 붙는다는 점이다.

RAG의 기본 구조는 두 개의 파이프라인으로 나눌 수 있다. 첫째는 색인 파이프라인이다. 문서를 수집하고, 적절한 단위로 쪼개고, 임베딩이라는 숫자 표현으로 바꾸어 벡터 데이터베이스에 저장한다. 임베딩은 문장의 의미를 숫자 좌표로 표현한 것이다. 둘째는 검색·생성 파이프라인이다. 사용자의 질문을 같은 방식으로 숫자화한 뒤 의미가 가까운 문서 조각을 찾고, 그 조각을 프롬프트에 넣어 LLM이 답변하게 한다. 엔터프라이즈 RAG 구현 가이드들은 이처럼 색인과 검색·생성을 분리해야 지식베이스를 업데이트해도 모델을 다시 훈련하지 않고 최신 답변을 만들 수 있다고 설명한다.³

RAG가 환각을 줄이는 이유는 모델에게 "상상하지 말고 이 근거 안에서 답하라"고 맥락을 제공하기 때문이다. 물론 RAG가 환각을 완전히 없애지는 않는다. 엉뚱한 문서를 검색하면 엉뚱한 답이 나오고, 관련 문서를 너무 작게 자르면 맥락이 끊기며, 오래된 문서가 섞이면 예전 정책이 최신처럼 제시된다. 그래서 RAG의 품질은 모델보다 검색 품질, 문서 구조, 메타데이터, 평가 체계에 더 크게 좌우된다.

초기 RAG는 "벡터 검색으로 비슷한 문서 몇 개 찾아 넣기"에 가까웠다. 하지만 기업 환경에서는 이것만으로 부족하다. 사내 용어, 제품 코드, 계약 번호, 법 조항, 고객 ID처럼 정확히 일치해야 하는 표현이 많기 때문이다. 그래서 현대 RAG는 의미 기반 벡터 검색과 키워드 검색을 결합하는 하이브리드 검색으로 진화하고 있다. 여기에 재순위화 모델을 붙여 검색 결과를 다시 평가하고, 문서의 부서·날짜·보안 등급·버전 같은 메타데이터로 필터링한다. NVIDIA는 기업 문서가 텍스트뿐 아니라 표, 차트, 그래프, 이미지, 다이어그램, 스캔 페이지 등으로 구성되어 있기 때문에 현대 RAG가 멀티모달이어야 하며, 메타데이터 필터링과 시각 추론이 정확도와 관련성을 높인다고 설명한다.⁴

결국 RAG는 "챗봇 기술"이 아니다. RAG는 기업 지식에 대한 접근 계층이다. 직원이 찾지 못하던 문서를 AI가 찾아 주고, 고객 상담원이 외우지 못하던 정책을 근거와 함께 제시하며, 개발자가 오래된 런북 대신 최신 장애 대응 절차를 확인하게 해 준다. 잘 만든 RAG는 조직의 기억을 검색 가능한 형태로 바꾸고, 그 기억을 대화형 인터페이스로 꺼내 쓰게 만든다.

청킹 하나가 답변의 운명을 바꾼다

RAG를 구축하는 팀들이 가장 자주 과소평가하는 단계가 문서 쪼개기, 즉 청킹이다. 청킹은 긴 문서를 검색 가능한 작은 조각으로 나누는 작업이다. 겉보기에는 단순하다. 1,000자마다 자르면 되지 않을까? 하지만 실제로는 이 결정 하나가 답변 품질을 크게 좌우한다.

사내 환불 정책 문서에 이런 내용이 있다고 해 보자.

"연간 구독 상품은 결제 후 14일 이내에 환불을 신청할 수 있다. 단, 기업 맞춤형 구축 서비스를 포함한 계약은 구축 착수 후 환불 대상에서 제외된다."

만약 청킹이 첫 문장과 두 번째 문장을 갈라 버리면 AI는 "14일 이내 환불 가능"이라는 절반의 사실만 검색할 수 있다. 고객이 기업 맞춤형 구축 서비스를 구매했는데도 환불 가능하다고 안내할 수 있다. 반대로 청크가 너무 크면 여러 정책이 한 덩어리에 섞여 검색의 초점이 흐려진다.

좋은 청킹은 문서의 의미 단위를 존중한다. 제목, 소제목, 단락, 표, 조항, 주석, 이미지 캡션, 부록을 구분해야 한다. 법무 문서는 조항 단위가 중요하고, 제품 매뉴얼은 절차 단계가 중요하며, 재무 보고서는 표와 주석의 연결이 중요하다. "몇 토큰으로 자를 것인가"보다 "이 문서에서 의미가 완결되는 단위가 어디인가"가 더 중요하다.

이 때문에 최근에는 에이전틱 파싱이 주목받고 있다. 에이전틱 파싱은 문서를 하나의 평평한 텍스트로 보지 않고, AI 에이전트가 문서의 구성 요소를 파악해 각 요소를 알맞은 전문 처리기로 보내는 방식이다. PDF 한 장 안에도 제목, 본문, 표, 차트, 서명란, 주석, 이미지, 각주가 섞여 있다. 이를 모두 OCR로 긁어낸 텍스트 덩어리로 만들면 정보의 구조가 사라진다. 에이전틱 파싱은 먼저 "이 영역은 표다", "이 부분은 다이어그램이다", "여기는 본문 단락이다", "이 이미지는 제품 배선도다"라고 구분한 다음, 표는 표 추출 모델로, 이미지는 비전 모델로, 본문은 언어 모델로, 수식은 수식 인식 모델로 보내는 식으로 처리한다.

이 변화는 단순한 문서 자동화가 아니다. AI가 기업 지식의 물리적 형태를 이해하기 시작했다는 뜻이다. 과거 OCR은 종이 위의 글자를 디지털 문자로 바꾸는 데 집중했다. 현대 문서 AI는 글자뿐 아니라 레이아웃, 읽기 순서, 표 구조, 체크박스 상태, 이미지 품질까지 해석한다. Google Cloud의 Enterprise Document OCR도 PDF와 이미지에서 블록, 단락, 행, 단어, 기호를 감지하고, 회전 보정, 이미지 품질 점수, 언어 감지, 체크박스 추출, 수학 OCR 같은 기능을 제공한다.⁵ 이런 기능들은 RAG나 에이전트가 문서를 더 정확히 읽도록 만드는 기반이다.

기업 문서의 핵심 정보는 종종 본문보다 표와 이미지에 숨어 있다. 보험 청구서의 금액은 표에 있고, 제조 매뉴얼의 위험 구역은 도면에 있으며, 병원 기록의 중요한 단서는 스캔 이미지의 작은 체크박스에 있다. 텍스트만 읽는 RAG는 이 정보를 놓친다. 그래서 문서 처리는 이제 "텍스트 추출"에서 "구조 보존"으로 이동하고 있다. AI가 사용할 수 있는 데이터는 단순한 문자열이 아니라, 원래 문서의 의미 구조를 가능한 한 보존한 데이터여야 한다.

지식 시스템은 위키, RAG, 메모리, 그래프의 조합이다

기업은 오래전부터 지식 관리를 해 왔다. 사내 위키를 만들고, 문서 관리 시스템을 도입하고, 파일 서버를 정리하고, 검색 엔진을 붙였다. 그런데 생성형 AI가 들어오면서 지식 관리의 역할이 달라졌다. 과거의 지식 관리는 사람이 찾아 읽기 위한 것이었다. 이제 지식 관리는 AI가 검색하고 해석하고 실행하기 위한 기반이 되었다.

이때 혼동하기 쉬운 개념이 있다. 위키, RAG, AI 메모리, 지식 그래프는 모두 "지식"을 다루지만 같은 것이 아니다.

위키는 조직이 합의한 정본 지식을 저장하는 곳이다. "우리 회사의 휴가 규정은 무엇인가", "서비스 장애 대응 절차는 무엇인가", "이 API의 공식 사용법은 무엇인가"처럼 안정적인 참조 정보를 담는다. 위키는 사람이 읽고 유지해야 하므로 소유자와 갱신 주기가 중요하다.

RAG는 AI가 답변을 만들 때 필요한 지식을 검색하는 접근 계층이다. RAG는 위키를 대체하지 않는다. 오히려 좋은 위키가 있을수록 RAG가 강해진다. 위키가 오래되고 중복되어 있으면 RAG는 그 혼란을 그대로 가져와 자연스러운 말투로 재생산한다.

AI 메모리는 에이전트가 시간에 따라 문맥을 유지하기 위한 장치다. 예를 들어 코딩 에이전트가 "이 프로젝트는 PostgreSQL을 쓰고, 테스트는 make test로 실행하며, 외부 의존성 추가를 싫어한다"는 사실을 기억하는 것이다. 메모리는 문서 검색과 다르다. RAG가 "지식베이스가 무엇을 말하는가"에 답한다면, 메모리는 "이 사용자나 작업에 대해 무엇을 계속 기억해야 하는가"에 답한다.

지식 그래프는 개념과 개념 사이의 관계를 명시적으로 저장한다. 고객 A가 계약 B와 연결되어 있고, 계약 B는 제품 C에 의존하며, 제품 C는 규정 D의 적용을 받는다는 식이다. 일반 벡터 검색은 의미가 비슷한 문서를 찾는 데 강하지만, 여러 개체의 관계를 따라가야 하는 질문에는 약하다. "프로젝트 지연이 APAC 3분기 마진에 어떤 영향을 주었는가" 같은 질문은 문서 하나를 찾는 문제가 아니라 프로젝트, 지역, 매출, 비용, 일정의 관계를 따라가는 문제다. Atlan은 RAG, AI 메모리, 지식 그래프가 서로 대체재가 아니라 기업 AI의 컨텍스트 스택에서 각기 다른 역할을 하며 함께 쓰인다고 설명한다.⁶

성숙한 기업 지식 시스템은 대체로 네 층으로 구성된다. 먼저 데이터와 문서의 원천 시스템이 있다. CRM, ERP, 데이터 웨어하우스, 사내 위키, 문서 저장소, 티켓 시스템이 여기에 해당한다. 그 위에는 정제와 거버넌스 계층이 있다. 메타데이터, 권한, 계보, 품질 검증, 버전 관리가 이곳에서 작동한다. 그 다음에는 검색과 컨텍스트 계층이 있다. 벡터 검색, 키워드 검색, 지식 그래프, RAG, 메모리가 결합된다. 마지막에는 업무 인터페이스가 있다. 직원용 AI 비서, 고객 상담 에이전트, 개발 도구, 자동 보고서, 승인 워크플로가 여기에 붙는다.

중요한 것은 "AI 지식 시스템"을 챗봇 프로젝트로 시작하면 실패하기 쉽다는 점이다. 챗봇은 맨 위의 얇은 인터페이스일 뿐이다. 아래쪽의 문서 정리, 데이터 표준화, 권한 모델, 검색 평가, 소유자 지정, 갱신 프로세스가 없다면 챗봇은 곧 오래된 사내 검색창의 화려한 버전이 된다.

살아 있는 지식에는 소유자가 있다

기업 지식 시스템의 가장 큰 적은 기술 부족이 아니라 방치다. 문서는 만들어지는 순간부터 낡기 시작한다. 제품 가격이 바뀌고, 법규가 개정되고, 담당자가 바뀌고, 시스템 화면이 업데이트된다. 그런데 문서의 소유자가 없으면 아무도 고치지 않는다. AI는 그 낡은 문서를 친절하게 읽고 자신감 있게 답한다.

그래서 AI-ready 지식 시스템에는 기술적 파이프라인만큼 운영 원칙이 필요하다. 각 문서에는 소유자가 있어야 하고, 만료일이나 검토 주기가 있어야 하며, 같은 주제의 정본 문서가 무엇인지 정해야 한다. 문서가 수정되면 색인이 갱신되어야 하고, 권한 변경이 검색 시스템에 반영되어야 한다. 사용자가 "이 답변은 틀렸다"고 표시하면 그 피드백이 지식베이스 개선으로 이어져야 한다.

기업 AI의 지식 운영은 도서관 운영과 닮았다. 책을 많이 들여놓는 것만으로 좋은 도서관이 되지 않는다. 분류 체계가 있어야 하고, 오래된 책을 폐기해야 하며, 대출 권한을 관리해야 하고, 이용자가 찾는 책이 어디 있는지 안내해야 한다. AI 지식 시스템도 마찬가지다. 문서를 많이 넣는 것보다 어떤 문서가 신뢰할 수 있는지, 어떤 문서는 폐기해야 하는지, 어떤 답변은 반드시 출처를 요구해야 하는지를 정하는 일이 중요하다.

실무적으로는 AI 지식 운영에 다음과 같은 역할이 등장한다.

• 지식 소유자는 특정 정책, 제품, 업무 절차 문서의 정확성과 최신성을 책임진다.

• 데이터 스튜어드는 데이터 품질, 표준, 메타데이터, 계보를 관리한다.

• AI 제품 책임자는 어떤 업무 흐름에서 어떤 지식을 AI가 사용할지 결정한다.

• 보안·법무 담당자는 권한, 개인정보, 저작권, 규제 준수를 검토한다.

• 현업 검수자는 AI 답변이 실제 업무 맥락에서 유용한지 평가한다.

이 역할들이 없으면 AI 프로젝트는 PoC에서는 빛나지만 운영에서는 흐려진다. 반대로 지식 운영 체계가 잡힌 조직은 모델을 바꾸어도 성과를 이어갈 수 있다. 오늘은 GPT 계열 모델을 쓰고 내일은 오픈소스 모델을 쓰더라도, 신뢰할 수 있는 지식 기반이 있으면 AI 서비스의 핵심 자산은 조직 안에 남는다.

합성 데이터는 부족한 데이터를 메우지만 만능 방패는 아니다

AI-ready 데이터 논의에서 빠질 수 없는 흐름이 합성 데이터다. 합성 데이터는 실제 데이터를 직접 복사한 것이 아니라, 실제 데이터의 통계적 특성과 패턴을 참고해 인공적으로 만든 데이터다. 의료 영상, 금융 거래, 제조 불량 사례, 자율주행 시나리오처럼 실제 데이터를 충분히 모으기 어렵거나 민감한 분야에서 특히 주목받는다.

합성 데이터가 필요한 이유는 분명하다. 첫째, 데이터가 부족하다. 드문 질병 사례, 희귀한 사고 장면, 특정 장비의 고장 패턴은 실제로 많이 발생하지 않는다. 둘째, 개인정보와 영업비밀 문제가 있다. 실제 고객 기록이나 환자 정보를 그대로 모델 학습에 쓰기 어렵다. 셋째, 규제 준수가 필요하다. 데이터 이동과 공유가 제한된 산업에서는 실제 데이터를 외부 개발팀이나 파트너에게 제공하기 어렵다.

합성 데이터는 이 문제를 완화할 수 있다. 예를 들어 은행은 실제 고객의 거래 내역을 노출하지 않고도 사기 탐지 모델을 테스트할 수 있는 가상 거래 데이터를 만들 수 있다. 병원은 환자 개인정보를 직접 공유하지 않고도 특정 질환 패턴을 반영한 학습 데이터를 만들 수 있다. 제조사는 실제 공장에서 거의 발생하지 않는 결함 이미지를 합성해 비전 검사 모델을 강화할 수 있다.

하지만 합성 데이터는 "개인정보가 완전히 사라진 안전한 데이터"라고 단정할 수 없다. 생성 모델이 원본 데이터의 일부를 지나치게 기억하거나, 특정 개인의 특성을 재현하거나, 공격자가 합성 데이터에서 원본 정보를 추론할 수 있는 가능성이 있기 때문이다. 2025년 ICLR에 채택된 연구는 합성 데이터를 이용한 학습 방식들이 프라이버시 보호에 대해 서로 다른 결과를 보이며, 형식적 차등프라이버시 보장 없이 경험적으로만 안전하다고 주장하는 접근은 거짓 안전감을 줄 수 있다고 경고했다.⁷

여기서 차등프라이버시는 특정 개인의 데이터가 포함되었는지 여부가 결과에 큰 영향을 주지 않도록 수학적으로 보호하는 방법이다. 쉽게 말해 "이 데이터셋에 김 과장의 정보가 들어갔는지 밖에서 알아내기 어렵게 만드는 기술적 약속"이다. 합성 데이터가 진짜로 프라이버시를 보호하려면 단순히 가짜 데이터를 만들었다는 사실만으로는 부족하고, 재식별 위험, 멤버십 추론 공격, 속성 추론 공격을 평가해야 한다.

프라이버시 보존 학습도 함께 발전하고 있다. 연합학습은 데이터를 한곳으로 모으지 않고 각 기관 내부에서 모델을 학습한 뒤 업데이트만 공유하는 방식이다. 병원이 환자 데이터를 외부로 보내지 않고도 공동 모델을 만들 수 있다는 장점이 있다. 보안 다자간 계산이나 동형암호는 데이터를 암호화한 상태에서 계산하려는 접근이다. 데이터 재프로그래밍처럼 데이터 표현을 바꾸어 예측 성능과 프라이버시 사이의 균형을 맞추려는 연구도 진행되고 있다.⁸

다만 이 기술들은 모두 비용과 복잡성을 동반한다. 연합학습은 참여 기관의 데이터 분포가 다르면 모델이 불안정해질 수 있고, 암호화 계산은 느릴 수 있으며, 합성 데이터는 현실의 미묘한 편향과 예외를 제대로 담지 못할 수 있다. 따라서 기업은 합성 데이터를 "규제 회피용 지름길"이 아니라 "데이터 부족과 프라이버시 위험을 함께 줄이는 보조 수단"으로 봐야 한다.

AI 데이터 생태계의 균열

기업 내부 데이터만큼이나 중요한 이슈가 AI 산업 전체의 학습 데이터 생태계다. 대형 모델의 초기 성장은 공개 웹의 방대한 텍스트, 이미지, 코드, 영상에 크게 의존했다. 하지만 2026년 현재 그 방식은 여러 방향에서 압박을 받고 있다.

첫째, 저작권과 출처 문제가 커졌다. 창작자와 언론사, 출판사, 플랫폼은 자신들의 콘텐츠가 허락 없이 모델 학습에 사용되었는지 묻고 있다. 생성형 AI가 원작자의 시장을 대체하거나, 콘텐츠의 일부를 재현하거나, 출처 표시 없이 가치를 흡수한다는 문제 제기다. OECD는 AI 데이터 조달 방식이 여전히 대규모 공개 콘텐츠 스크래핑에 의존하는 경우가 많고, 전 세계적으로 저작권과 데이터 보호 관련 소송이 50건 이상 제기되었으며, 웹사이트들이 스크래핑을 막기 위한 기술적·계약적 장벽을 늘리고 있다고 분석했다.⁹

둘째, 크롤링 부담이 커졌다. 과거 검색 엔진은 웹페이지를 크롤링하고, 검색 결과를 통해 다시 트래픽을 돌려보냈다. 콘텐츠 제공자는 크롤링을 허용하는 대신 방문자 유입이라는 보상을 기대할 수 있었다. 그러나 생성형 AI 시대에는 AI가 웹 콘텐츠를 읽고 요약해 사용자에게 직접 답을 제공한다. 사용자는 원문 사이트를 클릭하지 않을 수 있다. 콘텐츠 제공자 입장에서는 서버 비용과 데이터 사용 부담은 늘지만 방문자는 줄어드는 구조가 된다. 이른바 "크롤 투 클릭 격차"가 커지는 것이다.

셋째, 공개 지식 저장소의 품질과 양이 한계에 부딪히고 있다. 인터넷에는 여전히 엄청난 데이터가 있지만, AI 학습에 쓸 수 있는 고품질 데이터는 제한적이다. 이미 많이 수집된 공개 텍스트는 중복되어 있고, 저품질 SEO 콘텐츠와 AI가 다시 생성한 'AI 슬롭'이 늘어나며, 최신 고품질 데이터는 유료 장벽이나 접근 제한 뒤로 이동하고 있다. OECD는 전 세계 데이터가 풍부해지는 동시에 AI 개발자들이 사용할 수 있는 고품질 데이터는 부족해지는 역설을 'AI 데이터 패러독스'로 설명한다.⁹

넷째, 데이터 출처 투명성이 경쟁력이 되고 있다. 앞으로 모델 제공자는 "얼마나 큰 모델인가"뿐 아니라 "어떤 데이터로 학습했는가", "저작권과 개인정보를 어떻게 처리했는가", "데이터 라이선스는 적법한가"를 설명해야 한다. 기업 고객도 이를 요구하게 된다. 규제 산업의 기업이 출처가 불분명한 모델을 핵심 업무에 쓰기는 어렵기 때문이다.

이 변화는 AI 산업의 비용 구조를 바꾼다. 과거에는 공개 웹을 대규모로 긁어 학습 데이터로 삼는 것이 빠른 성장의 지름길이었다. 앞으로는 데이터 라이선스 계약, 콘텐츠 파트너십, 도메인 전문 데이터 구축, 합성 데이터 검증, 데이터 필터링, 출처 추적에 더 많은 비용이 들어갈 가능성이 높다. 모델 경제학이 연산 비용만의 문제가 아니게 되는 것이다. 데이터도 자본이 되고, 권리가 되고, 공급망이 된다.

AI-ready 기업으로 가는 실무 로드맵

그렇다면 기업은 어디서부터 시작해야 할까? 모든 데이터를 한 번에 정리하고, 모든 문서를 완벽하게 구조화한 뒤 AI를 도입하겠다는 계획은 대개 실패한다. 데이터 정리는 끝이 없는 일이기 때문이다. 더 현실적인 접근은 가치가 높은 업무 흐름 하나를 정하고, 그 업무에 필요한 데이터와 지식을 AI-ready하게 만드는 것이다.

예를 들어 고객 지원을 개선하려는 기업이라면 먼저 상위 20개 문의 유형을 고른다. 그 문의에 답하기 위해 상담원이 실제로 보는 문서, 시스템, 고객 기록을 조사한다. 중복되거나 오래된 문서를 제거하고, 최신 정책의 정본을 정한다. 문서 소유자를 지정하고, 답변에 반드시 인용해야 할 근거 문서를 정한다. 고객 개인정보와 계약 정보에 대한 권한을 설정한다. 그 다음 RAG 시스템을 만들고, 실제 상담 질문으로 평가한다. 답변 정확도뿐 아니라 검색된 문서의 관련성, 출처 표시, 최신성, 권한 준수 여부를 함께 본다.

AI-ready 데이터 로드맵은 대략 다음 순서로 진행할 수 있다.

• 업무 기준 선정: "어떤 데이터를 정리할 것인가"가 아니라 "어떤 업무 성과를 만들 것인가"에서 출발한다.

• 지식 원천 파악: 해당 업무에 필요한 문서, 데이터베이스, 시스템, 담당자 지식을 목록화한다.

• 정본과 폐기 기준 수립: 같은 주제의 문서가 여러 개라면 공식 버전을 정하고 오래된 버전을 숨기거나 폐기한다.

• 메타데이터와 권한 부여: 작성자, 부서, 날짜, 보안 등급, 문서 유형, 갱신 주기, 접근 권한을 붙인다.

• 문서 파싱과 색인 구축: 제목, 단락, 표, 이미지, 첨부 파일을 의미 단위로 처리하고 검색 인덱스를 만든다.

• 평가 세트 구축: 실제 사용자가 물을 질문과 기대 답변, 허용 가능한 출처를 준비한다.

• 운영 피드백 루프 설계: 틀린 답변 신고, 문서 수정, 재색인, 모델 평가가 반복되도록 만든다.

여기서 중요한 것은 "평가 세트"다. 많은 기업이 RAG를 구축한 뒤 몇 가지 질문을 던져 보고 "잘 되네"라고 판단한다. 하지만 운영에서는 다양한 표현, 애매한 질문, 권한이 걸린 질문, 최신 정책과 과거 정책이 충돌하는 질문이 들어온다. 따라서 기업은 대표 질문 목록을 만들고, 질문마다 정답 근거와 금지 답변을 정해야 한다. AI가 모르면 모른다고 답해야 하는 경우도 평가해야 한다.

또한 데이터 품질 지표와 비즈니스 지표를 연결해야 한다. 검색 정확도가 높아졌다는 기술 지표만으로는 경영진을 설득하기 어렵다. 고객 응대 시간이 줄었는지, 신규 직원 온보딩 기간이 짧아졌는지, 감사 준비 시간이 감소했는지, 잘못된 정책 안내가 줄었는지를 함께 측정해야 한다. 데이터 기반은 보이지 않는 인프라이지만, 그 성과는 업무 시간과 오류 비용에서 드러난다.

데이터 기반이 곧 AI 기반이다

생성형 AI 열풍의 첫 단계에서는 모두가 모델을 바라보았다. 더 큰 모델, 더 빠른 모델, 더 똑똑한 모델이 화제의 중심이었다. 그러나 기업 AI가 실제 업무로 들어오면서 시선은 점점 아래로 내려가고 있다. 문서가 제대로 파싱되는가. 데이터의 출처를 추적할 수 있는가. 권한이 반영되는가. 검색 결과가 최신인가. 지식의 소유자가 있는가. 합성 데이터의 프라이버시 위험을 평가했는가. 학습 데이터의 저작권과 라이선스를 설명할 수 있는가.

이 질문들은 화려하지 않다. 하지만 기업 AI의 성패를 결정한다. 좋은 모델은 나쁜 지식 시스템 위에서 오래 버티지 못한다. 반대로 정제된 데이터, 살아 있는 문서, 신뢰할 수 있는 검색, 명확한 권한, 지속적인 평가 체계를 갖춘 조직은 모델이 바뀌어도 계속 성과를 낸다.

AI-ready 데이터는 단순한 전처리 작업이 아니다. 그것은 기업이 자기 자신을 AI가 이해할 수 있는 형태로 다시 정리하는 과정이다. 흩어진 문서를 연결하고, 암묵지를 명시지로 바꾸고, 권한과 책임을 코드와 메타데이터에 새기며, 조직의 기억을 살아 있는 시스템으로 만드는 일이다.

다음 장에서는 이 데이터와 지식 시스템을 실제로 움직이게 하는 물리적 기반으로 내려간다. AI-ready 데이터가 연료라면, AI 인프라는 그 연료를 태워 업무를 움직이는 엔진이다. GPU, 데이터센터, 클라우드, 전력, 냉각, 네트워크, 지속가능성의 문제가 이제 AI 전략의 중심으로 들어온다.

참고

¹IBM, What Is AI-Ready Data?

²행정안전부 AI-Ready 공공데이터 도입 관련 보도자료 요약

³Grounding Your LLM: A Practical Guide to RAG for Enterprise Knowledge Bases

⁴NVIDIA, Build AI-Ready Knowledge Systems Using 5 Essential Multimodal RAG Capabilities

⁵Google Cloud, Enterprise Document OCR

⁶Atlan, AI Memory vs RAG vs Knowledge Graph: Enterprise Context Guide

⁷Does Training with Synthetic Data Truly Protect Privacy?

⁸Nature npj Artificial Intelligence, Privacy-preserving data reprogramming

⁹OECD.AI, Rethinking AI data: From scraping to sustainable and ethical data sharing