기업 AI가 챗봇에서 멈추는 이유

개인 생산성 AI는 성공했는데, 왜 다음 단계는 안 될까

온톨로지란 무엇인가에서 온톨로지를 “회사의 현실을 소프트웨어와 AI가 이해할 수 있게 옮겨놓은 지도”라고 정리했습니다. 이번 글에서는 이 지도가 왜 필요한지를, 많은 기업이 실제로 부딪히는 지점인 “챗봇형 기업 AI”의 한계를 통해 살펴보겠습니다.

요즘 기업들은 코딩 보조, 문서 요약, 회의록 정리 같은 개인 생산성 AI는 빠르고 성공적으로 도입하고 있습니다. 이 영역은 LLM이 잘하는 것, 즉 “언어”만 잘 다루면 되는 일이기 때문입니다. 코드도, 문서도 결국 텍스트입니다.

문제는 그다음 단계입니다. “우리 회사 데이터를 챗봇에 물어보면 알아서 분석해주는 AI”는 전혀 다른 게임입니다. 많은 기업이 이 단계에서 파일럿을 넘지 못하고 멈춥니다.

기업 AI가 챗봇에서 멈추는 진짜 원인

이 정체를 두고 “아직 모델이 부족해서”라고 생각하기 쉽지만, 실제 원인은 다른 곳에 있는 경우가 대부분입니다. 세 가지로 정리할 수 있습니다.

첫째, 데이터가 여러 시스템에 흩어져 있습니다. ERP, CRM, 사내 문서함이 각자 따로 존재하고, 같은 “고객”이라는 개념도 시스템마다 이름과 형식이 다릅니다.

둘째, 테이블과 컬럼의 “의미”가 정의돼 있지 않습니다. TB_CUSTOMER, CUST_ID 같은 이름만으로는 사람도, AI도 이게 정확히 무엇을 뜻하는지 알 수 없습니다.

셋째, 답을 찾아도 실제 행동(승인, 실행, 반영)으로 이어지지 않습니다. 분석 결과를 챗봇 창에서 확인하는 것과, 그 결과가 업무 시스템에서 실제로 처리되는 것 사이에는 큰 간극이 있습니다.

가트너는 2026년까지 AI 프로젝트의 60%가 “AI에 활용 가능한(AI-ready) 데이터”를 갖추지 못한 채 진행될 것으로 전망했습니다. 문제의 무게중심이 모델이 아니라 데이터 쪽에 있다는 뜻입니다.

가장 흔한 실패 패턴: 일단 사내 문서에 RAG부터 붙이기

기업들이 가장 먼저 시도하는 방법은 사내 문서에 검색증강생성(RAG, 문서를 검색해 LLM에 함께 넣어주는 방식)을 붙이는 것입니다. 데모 단계에서는 꽤 그럴듯해 보입니다.

graph LR
    A[사내 문서/DB] --> B[RAG 파이프라인]
    B --> C[데모: 그럴듯한 답변]
    C -->|실무 배포| D[정확도·신뢰도 하락]
    D -->|원인| E[컬럼명 추측, 업무 맥락 없음]

문제는 실무에 배포하는 순간 드러납니다. LLM은 TB_CUSTOMER나 CUST_ID 같은 컬럼명을 문맥상 “추측”할 뿐, 이게 실제 업무에서 어떤 의미이고 어떤 예외 규칙이 있는지는 모릅니다. 데모에서는 몰라도 넘어가지만, 실무자는 틀린 답을 바로 알아챕니다.

이 문제는 실제로 겪어본 적이 있습니다. 생성형 AI가 등장했을 무렵, 비즈니스 질문에 곧바로 답하게 만들 수 있을 거라 생각하고 쉽게 접근했습니다. 원하는 결과가 나오지 않자 질문들을 유형화하고, 업무 영역별로 서브 쿼리를 만들고, 이를 아우르는 범용 유니온 테이블을 별도로 구성해 질문마다 적절한 쿼리로 연결되도록 오케스트레이션을 짰습니다. 테이블을 이해시키기 위한 메타 정보까지 별도로 학습시켰지만, 그래도 만족할 만한 답은 나오지 않았습니다. 돌아보면 질문 하나하나에 대응하는 쿼리를 끝없이 만들어낸 것에 가까웠습니다.

해법의 방향: 더 좋은 모델이 아니라 먼저 의미 구조를 입히는 것

RAG가 컬럼명을 “추측”하는 데서 멈추는 이유는 애초에 그 컬럼이 무엇을 의미하는지 알려주는 사전 정보가 없기 때문입니다. 그래서 방향을 바꿔야 합니다. “더 큰 모델을 쓰자”가 아니라, 데이터에 의미 구조를 먼저 입히는 것입니다. 이 의미 구조를 만드는 방법은 온톨로지 외에도 지식 그래프, 데이터 카탈로그, 비즈니스 용어집 등 여러 갈래가 있는데, 이 글에서는 그중 온톨로지를 다룹니다. 온톨로지는 TB_CUSTOMER, CUST_ID 같은 기술적인 이름을 고객, 고객 ID처럼 업무 용어로 정의하고, 테이블 간의 관계도 “고객이 주문한다”처럼 사람이 이해하는 형태로 미리 정리해둡니다.

이 지도가 있으면 AI는 컬럼명을 추측하는 대신, 이미 정의된 객체와 관계를 따라 답을 찾습니다. 그리고 그 답이 온톨로지 위에 정의된 “행동(액션)”과 연결돼 있다면, 단순 응답을 넘어 승인·실행 같은 실제 업무로도 이어질 수 있습니다.

아직 운영 중인 온톨로지가 전 영역을 커버할 정도로 확장되지는 않았지만, 정의가 잘 되어 있는 특정 영역 안에서는 이미 구성된 관계와 모델링을 기반으로 의미 있는 분석이 이루어지고 있습니다. 이게 LLM 자체의 성능이 좋아진 덕분인지, 모델링이 잘 되어 있어서인지는 아직 명확히 구분하지 못했고, 앞으로 계속 살펴보며 정리해볼 생각입니다.

물론 온톨로지도 공짜는 아닙니다. 누가 설계하고 누가 유지보수할지, 업무가 바뀔 때마다 어떻게 갱신할지 같은 거버넌스 문제가 함께 따라옵니다. 보고서 몇 개만 뽑으면 되는 단순한 상황이라면 이 정도 구조까지는 과할 수 있습니다 — 여러 시스템에 흩어진 데이터를 AI가 지속적으로, 정확하게 다뤄야 하는 상황에서 투자할 가치가 커집니다.

마무리

기업 AI가 챗봇 단계에서 멈추는 건 모델이 부족해서가 아니라, 데이터에 아직 의미가 입혀지지 않았기 때문입니다. 온톨로지는 이 간극을 메우는 실용적인 방법이며, 지난 글에서 정리한 “회사의 현실을 옮긴 지도”가 바로 이 단계에서 진가를 발휘합니다.

참고: Gartner, “Predicts 2024: Data and Analytics Governance and Trust” 등 AI-ready 데이터 관련 전망 보고서