AI는 왜 자꾸 실패할까요? 답은 모델이 아니라 데이터입니다.

실패율 수치보다 중요한 건 실패의 '위치'입니다. AI 프로젝트가 멈추는 지점을 짚어보고, 데이터를 AI가 쓸 수 있는 상태로 만드는 방법을 살펴봅니다.

생성형 AI가 일상 업무 도구로 자리잡은 지 몇 년이 지났습니다. 그럼에도 여전히 비슷한 이야기가 반복됩니다. 파일럿, 즉 개념 검증(PoC, Proof of Concept) 단계에서는 결과가 그럴듯했는데, 막상 현업에 붙이자 흐지부지됐다는 이야기입니다. 회의실 시연에서는 박수를 받은 챗봇이, 실제 데이터를 만나는 순간 엉뚱한 답을 내놓는 경우도 흔합니다.

이런 일이 생기면 조직은 대개 원인을 모델이나 인프라에서 찾습니다. "더 큰 모델을 써야 하나", "프롬프트를 다시 짜야 하나", "GPU가 부족한가"라는 질문이 먼저 나옵니다. 그런데 정작 여러 프로젝트를 들여다보면 병목은 다른 곳에 있는 경우가 많습니다. 바로 데이터입니다. 이번 글에서는 AI가 실패하는 지점을 하나씩 짚어보고, 'AI Ready Data'라는 개념이 왜 그 답이 될 수 있는지 살펴보겠습니다.

실패율보다 봐야 할 것은 '실패 지점'입니다

AI 프로젝트의 실패율을 다루는 자료는 많습니다. 이런 수치는 조사 기관과 정의에 따라 편차가 커서, 특정 숫자 하나를 인용해 단정하기는 조심스럽습니다. 대신 여러 조사와 현장 사례에서 공통으로 반복되는 패턴에 주목할 필요가 있습니다. 바로 "파일럿은 통과했는데 확산 단계에서 멈춘다"는 패턴입니다.

이 지점에서 조직들이 흔히 던지는 질문은 "우리 모델이 부족한가"입니다. 그래서 더 성능 좋은 대형언어모델(LLM, Large Language Model)로 갈아타거나, 파라미터가 큰 모델을 도입하는 데 예산을 씁니다. 물론 모델 성능이 결과에 영향을 주는 것은 사실입니다. 하지만 그렇게 갈아탄 뒤에도 문제가 그대로인 경우가 적지 않습니다.

왜 그럴까요? 모델은 입력받은 데이터 안에서만 판단합니다. 아무리 뛰어난 모델도 자신에게 주어진 데이터가 무엇을 뜻하는지, 어디까지 믿을 수 있는지, 다른 데이터와 어떻게 연결되는지 스스로 알아내지는 못합니다. 이 지점을 두고 "AI 실패의 상당 부분은 모델 이전 단계, 즉 데이터 단계에서 이미 결정된다"는 평가가 나옵니다. 이 글에서 살펴볼 세 가지 이유도 결국 이 지점으로 수렴합니다.

논의를 조금 더 구체적으로 만들기 위해, 하나의 장면을 상상해 보겠습니다. 이사를 앞두고 짐을 잔뜩 박스에 담았습니다. 그런데 박스 겉면에 아무 라벨도 붙이지 않았고, 어느 박스를 어느 방에 둘지 알려줄 배치도도 그리지 않았습니다. 이삿짐센터 직원이 아무리 유능해도, 라벨 없는 박스 더미 앞에서는 최선의 판단을 내리기 어렵습니다. AI에게 데이터를 던져주는 일도 이와 비슷합니다. 지금부터 이 비유를 데이터로 이어가 보겠습니다.

이유 하나 — 데이터는 있는데 정보는 없습니다

가장 먼저 짚을 것은 '데이터'와 '정보'의 차이입니다. 데이터는 시스템 안에 쌓여 있는 값 자체이고, 정보는 그 값이 무엇을 의미하는지까지 포함한 것입니다. 예컨대 데이터베이스 컬럼에 STAT_CD = 3이라는 값이 있다고 해 보겠습니다. 이 값은 데이터입니다. 그런데 3이 무엇을 뜻하는지는 별도의 정의를 찾아보기 전까지는 아무도 알 수 없습니다. 그 정의까지 갖춰야 비로소 정보가 됩니다.

사람은 이런 상황에서 동료에게 물어보거나, 오래된 위키 문서를 뒤지거나, 감으로 짐작해서 넘어갑니다. 그런데 LLM에게는 그런 여지가 없습니다. 컬럼명과 값만 보고 그럴듯한 답을 만들어 냅니다. 예를 들어 어느 회사가 고객 데이터를 LLM에 연결해 "이탈 가능성이 높은 고객을 찾아 달라"고 요청했다고 가정해 보겠습니다. 코드값의 의미를 담은 메타데이터가 없다면, 모델은 컬럼명의 겉모습만 보고 추론하다가 이미 해지한 고객을 여전히 활성 고객으로 분류하는 식의 오류를 낼 수 있습니다. 겉으로는 자신 있게 답하기 때문에, 오류를 알아채기까지 시간이 더 걸리는 경우도 많습니다.

현장에서 프로젝트를 들여다보면, 이런 맥락 정보가 사람의 머릿속에만 있는 경우를 자주 봅니다. 담당자가 바뀌거나 조직이 개편되면 그 맥락은 함께 사라집니다. 데이터는 그대로 남아 있지만, 그 데이터를 해석할 열쇠는 사라지는 셈입니다. 다시 이삿짐 비유로 돌아가면, 박스는 그대로 쌓여 있는데 라벨이 붙어 있지 않은 상태입니다. 박스 안에 무엇이 들었는지는 오직 짐을 싼 사람만 기억합니다.

이 문제를 다루는 영역이 바로 메타데이터 관리입니다. 메타데이터란 데이터에 대한 데이터, 즉 "이 컬럼은 무엇을 뜻하고, 어디서 왔고, 누가 관리하는가"를 기록한 정보입니다. 메타데이터를 체계적으로 관리한다는 것은, 결국 모든 박스에 라벨을 붙이는 작업과 같습니다. 사람에게는 사소해 보일 수 있는 이 작업이, AI 앞에서는 결과의 신뢰도를 가르는 첫 번째 관문이 됩니다.

이유 둘 — 품질을 신뢰할 수 없습니다.

두 번째 이유는 데이터 품질입니다. 데이터 품질이란 데이터가 정확하고, 최신 상태이며, 중복이나 결측 없이 일관된 정도를 말합니다. 과거에는 품질 낮은 데이터의 대가가 제한적이었습니다. 리포트 한 장이 틀리거나, 담당자가 엑셀에서 오류를 발견하고 수정하는 정도로 끝나는 경우가 많았습니다. 사람이 중간에서 이상한 값을 걸러내는 역할을 했기 때문입니다.

그런데 이제는 사정이 다릅니다. AI는 사람이 중간에서 걸러주지 않는 값을, 걸러내지 않은 채로 대량 생산합니다. 중복된 고객 레코드가 섞여 있으면 AI는 같은 고객을 서로 다른 사람으로 취급해 통계를 왜곡합니다. 몇 년 전 갱신이 멈춘 값이 최신 값처럼 입력돼 있으면, AI는 그 값을 의심 없이 근거로 삼아 답을 만들어 냅니다. 사람이라면 "이 숫자 좀 이상한데"라고 멈칫할 지점에서, AI는 멈추지 않고 그럴듯한 문장으로 포장해 넘어갑니다. 결과물의 오류가 규모의 오류로 번지는 셈입니다.

다시 이삿짐 비유를 가져오면, 박스 안에 예전에 버렸어야 할 고장 난 물건과 멀쩡한 새 물건이 뒤섞여 있는 상태입니다. 라벨이 붙어 있다 해도 박스를 열었을 때 안에 든 물건이 라벨과 같지 않다면 소용이 없습니다. 데이터 품질이 낮은 상태에서 AI를 붙이는 일은 정리되지 않은 박스를 그대로 새집으로 옮기는 일과 비슷합니다. 짐은 옮겼지만 정작 필요할 때 원하는 물건을 찾을 수 없습니다.

다만 품질 관리만으로 문제가 다 풀리는 것은 아닙니다. 컬럼 하나하나의 값이 정확하고 최신이라 해도, 그 데이터가 다른 데이터와 어떻게 이어지는지는 또 다른 차원의 문제이기 때문입니다. 값 자체는 깨끗한데, 값과 값 사이의 연결고리가 끊어져 있는 경우가 그렇습니다. 이 지점이 다음으로 짚어볼 세 번째 이유입니다.

이유 셋 — 데이터 사이의 관계를 모릅니다

세 번째 이유는 관계, 조금 더 정확히 말하면 의미(semantics)의 문제입니다. 같은 고객 하나를 두고도 영업 시스템에서는 '거래처 코드'로, 배송 시스템에서는 '수령인 ID'로, 고객센터 시스템에서는 '상담 고객번호'로 각각 다르게 부르는 경우가 흔합니다. 사람은 이 세 값이 결국 같은 고객을 가리킨다는 사실을 문서와 경험으로 짜맞춰 알아냅니다. 그런데 이 연결고리를 표시해 두지 않으면, AI는 이 셋을 서로 무관한 별개의 값으로 취급합니다.

이삿짐 비유에 마지막 조각을 더해 보겠습니다. 박스마다 라벨을 붙였고, 안에 든 물건도 깨끗이 정리했습니다. 그런데 이 박스를 어느 방에 둬야 하는지 알려줄 배치도가 없습니다. AI는 접시 박스와 주방도구 박스가 서로 짝을 이룬다는 사실을 라벨만 가지고는 알 수 없습니다. 데이터도 마찬가지입니다. 개별 항목의 의미를 알아도 그 항목들이 서로 어떻게 얽혀 있는지 표시해 두지 않으면, AI의 머리 속에서 전체 그림은 조각난 채로 남습니다.

이 문제는 정형화된 표(테이블) 구조로는 풀기 어렵습니다. 관계형 데이터베이스는 정해진 틀 안에서 데이터를 담는 데는 강하지만, 시스템을 넘나드는 느슨하고 다양한 연결 관계를 표현하는 데는 서툽니다. 그래서 최근 주목받는 접근이 그래프DB(Graph Database)와 온톨로지(ontology)입니다. 그래프DB는 데이터를 점(개체)과 선(관계)으로 표현해, "이 고객이 이 상품을 샀고, 이 상담을 받았다"는 식의 연결을 있는 그대로 저장하는 데이터베이스입니다. 온톨로지는 한 걸음 더 나아가, 개체와 관계에 이름과 규칙을 부여해 조직 전체가 같은 언어로 데이터를 이해하도록 돕는 체계를 말합니다.

물론 그래프DB나 온톨로지를 도입한다고 관계 문제가 자동으로 풀리는 것은 아닙니다. 결국 누군가는 "이 값과 저 값이 같은 고객을 가리킨다"는 지식을 처음 한 번은 정의해 줘야 합니다. 다만 그 정의를 한 번 만들어 두면 이후로는 사람이 매번 기억을 더듬는 대신 시스템이 그 관계를 일관되게 참조할 수 있습니다. 배치도를 한 번 그려 두면, 다음 이사부터는 짐을 쌀 때마다 헤매지 않아도 되는 것과 같은 이치입니다.

'AI Ready Data', 그러면 무엇이 달라질까요

지금까지 살펴본 세 가지 이유, 즉 맥락 부재, 품질 저하, 관계 단절을 한데 모아 해결하려는 개념이 바로 'AI Ready Data'입니다. AI Ready Data란, AI가 곧바로 활용할 수 있도록 의미와 맥락이 정돈된 데이터를 말합니다. 라벨을 붙이고, 내용물을 정리하고, 배치도까지 그려서 이삿짐센터에 넘기는 것과 같은 상태라고 보면 됩니다. 이 개념이 왜 중요한지는 앞선 세 섹션에서 이미 답했습니다.

그렇다면 실제로 조직이 할 수 있는 일은 무엇일까요? 크게 두 갈래로 나눌 수 있습니다. 하나는 기존에 해오던 데이터 거버넌스를 다시 다잡는 일입니다. 메타데이터 관리, 데이터 표준화, 데이터 품질 진단과 정제, 데이터가 어디서 와서 어디로 흘러가는지 추적하는 리니지(lineage) 관리가 여기 해당합니다. 다른 하나는 그래프DB와 온톨로지를 활용해 데이터 사이의 관계, 즉 의미를 발굴하고 연결하는 작업입니다. 엔코아는 이 두 갈래를 잇는 결과물을 '데이터 맥락 지도'라고 부릅니다. 라벨과 배치도를 한 장의 지도로 합쳐 놓은 셈입니다.

이 작업이 끝나면 무엇이 좋아질까요? AI가 질문에 답할 때, 참조하는 데이터의 의미를 스스로 짐작할 필요가 없어집니다. 컬럼값의 뜻, 데이터의 신선도, 다른 시스템과의 연결 관계를 이미 정돈된 형태로 건네받기 때문입니다. 최근 논의되는 MCP(Model Context Protocol, LLM이 외부 도구나 데이터에 접근하는 방식을 표준화한 프로토콜)와 같은 연결 기술도, 결국 그 너머에 있는 데이터가 정돈돼 있지 않으면 반쪽짜리 파이프라인에 그칩니다. 통로를 아무리 잘 뚫어도 통로 끝에 있는 창고가 엉망이면 꺼내 오는 물건도 엉망일 수밖에 없습니다.

'AI Ready Data'도 만능열쇠는 아닙니다

다만 여기서 균형을 잡을 필요가 있습니다. AI Ready Data를 갖춘다고 해서 AI 프로젝트가 자동으로 성공하는 것은 아닙니다. 데이터를 아무리 잘 정돈하고 지도를 만들어도, 그 위에서 무엇을 할지에 대한 목표가 없으면 프로젝트는 여전히 표류합니다. 데이터는 필요조건이지 충분조건은 아니라는 뜻입니다.

조직 안의 문제도 여전히 남아 있습니다. 부서마다 데이터를 다른 이름으로 부르는 관행, 데이터 정의를 문서화하지 않는 습관, 데이터 소유권을 둘러싼 부서 간 이해관계 등은 기술로 단번에 해결되지 않습니다. 메타데이터 체계를 아무리 잘 설계해도 현업 담당자가 그 정의를 계속 최신 상태로 유지하지 않으면, 시간이 지나며 다시 낡은 정보가 됩니다. 라벨을 붙이는 일도, 배치도를 그리는 일도 결국 사람이 꾸준히 관리해야 유지되는 작업입니다.

또한 이 작업에는 시간과 비용이 듭니다. 기존 시스템 전반에 흩어진 메타데이터를 모으고, 관계를 정의하고, 품질 기준을 세우는 일은 몇 주 만에 끝나는 프로젝트가 아닙니다. 빨리 AI부터 붙여서 성과를 내고 싶은 조직 입장에서는 더디게 느껴질 수 있습니다. 그럼에도 이 과정을 건너뛴 채 AI 도입을 서두르면, 앞서 살펴본 세 가지 문제가 그대로 재현될 가능성이 큽니다. 당장 지름길처럼 보이는 길이 사실은 더 멀리 돌아가는 길인 셈입니다.

그렇다면 무엇부터 점검해야 할까요

이번에는 실무에서 바로 적용할 수 있는 점검 항목을 짚어보겠습니다. AI 도입을 검토하고 있다면 모델을 고르기 전에 아래 질문에 먼저 답해보시길 권합니다.

• 맥락: 우리 데이터의 컬럼명과 코드값에는 그 의미를 설명하는 메타데이터가 붙어 있습니까? 담당자가 바뀌어도 그 정의를 확인할 수 있는 곳이 있습니까?
• 품질: 중복된 레코드, 갱신이 멈춘 값, 결측치는 어느 수준으로 관리되고 있습니까? 그 수준을 수치로 파악하고 있습니까?
• 관계: 서로 다른 시스템에 흩어진 데이터가 같은 대상을 가리킬 때, 그 연결 관계를 정의해 두었습니까? 아니면 담당자의 경험에만 의존하고 있습니까?

세 질문에 대해 하나라도 "잘 모르겠다"는 답이 나온다면, 그 지점이 바로 다음 AI 프로젝트가 멈출 후보 지점입니다. 모델을 바꾸기 전에 이 세 가지부터 손을 대는 편이 장기적으로는 훨씬 적은 시행착오로 이어집니다.

결국, 실패는 모델이 아니라 그 이전 단계에서 정해집니다

다시 처음의 질문으로 돌아가 보겠습니다. AI는 왜 자꾸 실패할까요. 이 글에서 짚은 세 가지 이유를 한 문장씩으로 압축하면 이렇습니다. 데이터는 있어도 그 의미를 알려줄 맥락이 없고, 값은 쌓여 있어도 믿을 수 있는 품질이 아니며, 여러 시스템에 흩어진 데이터 사이의 관계가 정의돼 있지 않습니다. 세 가지 모두 모델의 문제가 아니라 데이터의 문제입니다.

이삿짐 비유로 정리하면 더 분명해집니다. 라벨 없는 박스, 뒤섞인 물건, 배치도 없는 이사는 아무리 유능한 이삿짐센터를 불러도 새집을 어수선하게 만듭니다. AI도 다르지 않습니다. 아무리 성능 좋은 모델을 데려와도 라벨과 배치도가 없는 데이터 앞에서는 제 실력을 발휘하지 못합니다. AI Ready Data는 이 라벨과 배치도가 미리 준비된 데이터이고, 그 결과물을 만들기 위한 방법으로 엔코아는 '데이터 맥락 지도'를 사용합니다.

물론 이 작업이 AI 성공을 보장하는 만능열쇠는 아닙니다. 명확한 목표, 현업의 관심, 꾸준한 관리가 함께 뒷받침돼야 합니다. 그럼에도 순서는 분명합니다. GPU 서버를 구축하거나 모델을 고르기 전에, 우리 데이터가 누가 봐도 이해할 수 있고 서로 연결되어 있는지부터 점검해 보시길 권합니다. 그 점검에서 출발한 AI 프로젝트라야, 회의실을 넘어 현업까지 무사히 도착할 가능성이 높아집니다.