이 글은 누구를 위한 것인가
챗봇 파일럿까지는 순조로웠습니다. 그런데 전사 배포를 앞두고 딱 멈췄습니다. 이미 사내 챗봇 파일럿을 진행했지만 실제 배포 단계에서 막힌 경험이 있는 분, 혹은 “우리도 회사 데이터로 챗봇을 만들어보자”는 요청을 받은 실무자를 위한 글입니다.
개인 생산성 AI는 성공했는데, 왜 다음 단계는 안 될까
온톨로지란 무엇인가에서 온톨로지를 “회사의 현실을 소프트웨어와 AI가 이해할 수 있게 옮겨놓은 지도”라고 정리했습니다. 이번 글에서는 이 지도가 왜 필요한지를, 많은 기업이 실제로 부딪히는 지점인 “챗봇형 기업 AI”의 한계를 통해 살펴보겠습니다.
요즘 기업들은 코딩 보조, 문서 요약, 회의록 정리 같은 개인 생산성 AI는 빠르고 성공적으로 도입하고 있습니다. 이 영역은 LLM이 잘하는 것, 즉 “언어”만 잘 다루면 되는 일이기 때문입니다. 코드도, 문서도 결국 텍스트입니다.
문제는 그다음 단계입니다. “우리 회사 데이터를 챗봇에 물어보면 알아서 분석해주는 AI”는 전혀 다른 게임입니다. 많은 기업이 이 단계에서 파일럿을 넘지 못하고 멈춥니다.
기업 AI가 챗봇에서 멈추는 진짜 원인
이 정체를 두고 “아직 모델이 부족해서”라고 생각하기 쉽지만, 실제 원인은 다른 곳에 있는 경우가 대부분입니다. 세 가지로 정리할 수 있습니다.
첫째, 데이터가 여러 시스템에 흩어져 있습니다. ERP, CRM, 사내 문서함이 각자 따로 존재하고, 같은 “고객”이라는 개념도 시스템마다 이름과 형식이 다릅니다.
둘째, 테이블과 컬럼의 “의미”가 정의돼 있지 않습니다. TB_CUSTOMER, CUST_ID 같은 이름만으로는 사람도, AI도 이게 정확히 무엇을 뜻하는지 알 수 없습니다.
셋째, 답을 찾아도 실제 행동(승인, 실행, 반영)으로 이어지지 않습니다. 분석 결과를 챗봇 창에서 확인하는 것과, 그 결과가 업무 시스템에서 실제로 처리되는 것 사이에는 큰 간극이 있습니다.
가트너는 2026년까지 “AI에 활용 가능한(AI-ready) 데이터”를 갖추지 못한 AI 프로젝트의 60%가 폐기될 것으로 전망했습니다. 문제의 무게중심이 모델이 아니라 데이터 쪽에 있다는 뜻입니다.
가장 흔한 실패 패턴: 일단 사내 문서에 RAG부터 붙이기
기업들이 가장 먼저 시도하는 방법은 사내 문서에 검색증강생성(RAG, 문서를 검색해 LLM에 함께 넣어주는 방식)을 붙이는 것입니다. 데모 단계에서는 꽤 그럴듯해 보입니다.
일반적인 RAG 파이프라인의 흐름 사내 문서·DB → 검색(Retrieval) → LLM 컨텍스트에 주입 → 답변 생성
이 흐름 어디에도
TB_CUSTOMER나CUST_ID같은 컬럼·코드값이 실제 업무에서 무엇을 뜻하는지는 정의되어 있지 않습니다.
문제는 실무에 배포하는 순간 드러납니다. LLM은 TB_CUSTOMER나 CUST_ID 같은 컬럼명을 문맥상 “추측”할 뿐, 이게 실제 업무에서 어떤 의미이고 어떤 예외 규칙이 있는지는 모릅니다. 데모에서는 몰라도 넘어가지만, 실무자는 틀린 답을 바로 알아챕니다.
이 문제는 실제로 겪어본 적이 있습니다. 생성형 AI가 등장했을 무렵, 비즈니스 질문에 곧바로 답하게 만들 수 있을 거라 생각하고 쉽게 접근했습니다. 원하는 결과가 나오지 않자 질문들을 유형화하고, 업무 영역별로 서브 쿼리를 만들고, 이를 아우르는 범용 유니온 테이블을 별도로 구성해 질문마다 적절한 쿼리로 연결되도록 오케스트레이션을 짰습니다. 테이블을 이해시키기 위한 메타 정보까지 별도로 학습시켰지만, 그래도 만족할 만한 답은 나오지 않았습니다. 돌아보면 질문 하나하나에 대응하는 쿼리를 끝없이 만들어낸 것에 가까웠습니다.
RAG와 온톨로지, 무엇이 근본적으로 다른가
| 구분 | 단순 RAG | 온톨로지 기반 |
|---|---|---|
| 컬럼·테이블 의미 | LLM이 문맥으로 추측 | 미리 업무 용어로 정의됨 |
| 테이블 간 관계 | 매번 쿼리로 새로 탐색 | 미리 정의된 Link를 따라 탐색 |
| 답변의 일관성 | 같은 질문도 매번 다른 경로로 답할 수 있음 | 같은 관계 구조를 따르므로 상대적으로 일관됨 |
| 실행 가능성 | 답만 제공, 실행은 별도 시스템 필요 | Action Type을 통해 답이 바로 실행으로 이어질 수 있음 |
| 초기 구축 비용 | 낮음(문서만 있으면 시작 가능) | 높음(온톨로지 설계·유지보수 필요) |
이 표에서 중요한 건 “온톨로지가 항상 더 낫다”는 결론이 아닙니다. RAG는 초기 비용이 낮아 문서 기반 질의응답처럼 정확성 요구가 상대적으로 낮은 영역에는 여전히 유효합니다. 문제는 “회사 데이터를 정확하게, 반복적으로, 실행까지 이어지게” 다뤄야 하는 상황에서 RAG만으로 해결하려 할 때 생깁니다.
해법의 방향: 더 좋은 모델이 아니라 먼저 의미 구조를 입히는 것
RAG가 컬럼명을 “추측”하는 데서 멈추는 이유는 애초에 그 컬럼이 무엇을 의미하는지 알려주는 사전 정보가 없기 때문입니다. 그래서 방향을 바꿔야 합니다. “더 큰 모델을 쓰자”가 아니라, 데이터에 의미 구조를 먼저 입히는 것입니다. 이 의미 구조를 만드는 방법은 온톨로지 외에도 지식 그래프, 데이터 카탈로그, 비즈니스 용어집 등 여러 갈래가 있는데, 이 글에서는 그중 온톨로지를 다룹니다. 온톨로지는 TB_CUSTOMER, CUST_ID 같은 기술적인 이름을 고객, 고객 ID처럼 업무 용어로 정의하고, 테이블 간의 관계도 “고객이 주문한다”처럼 사람이 이해하는 형태로 미리 정리해둡니다.
이 지도가 있으면 AI는 컬럼명을 추측하는 대신, 이미 정의된 객체와 관계를 따라 답을 찾습니다. 그리고 그 답이 온톨로지 위에 정의된 “행동(액션)”과 연결돼 있다면, 단순 응답을 넘어 승인·실행 같은 실제 업무로도 이어질 수 있습니다.
아직 운영 중인 온톨로지가 전 영역을 커버할 정도로 확장되지는 않았지만, 정의가 잘 되어 있는 특정 영역 안에서는 이미 구성된 관계와 모델링을 기반으로 의미 있는 분석이 이루어지고 있습니다. 이게 LLM 자체의 성능이 좋아진 덕분인지, 모델링이 잘 되어 있어서인지는 아직 명확히 구분하지 못했고, 앞으로 계속 살펴보며 정리해볼 생각입니다.
언제 온톨로지 투자가 정당화되는가
물론 온톨로지도 공짜는 아닙니다. 누가 설계하고 누가 유지보수할지, 업무가 바뀔 때마다 어떻게 갱신할지 같은 거버넌스 문제가 함께 따라옵니다. 판단 기준은 다음과 같습니다.
- 보고서 몇 개만 뽑으면 되는 단순한 상황이라면 이 정도 구조까지는 과할 수 있습니다.
- 여러 시스템에 흩어진 데이터를 AI가 지속적으로, 정확하게 다뤄야 하는 상황이라면 투자할 가치가 커집니다.
- 답이 실제 업무 행동(승인, 실행)으로 이어져야 하는 상황이라면 온톨로지의 Action Type이 아니면 이 연결 자체가 어렵습니다.
자주 반복되는 실무 실패 패턴
- RAG가 안 되면 더 큰 모델로 바꿔보기: 문제의 원인이 데이터 의미 구조 부재인데 모델만 바꾸면, 같은 문제가 다른 모델에서 반복됩니다.
- 질문 유형별로 쿼리를 끝없이 늘리기: 이 글에서 다룬 실패 경험처럼, 질문에 대응하는 쿼리를 계속 추가하는 방식은 확장성이 없습니다. 근본적으로는 관계를 온톨로지로 미리 정의해두는 것이 이 문제를 구조적으로 해결합니다.
- 파일럿 성공을 전사 배포 가능성과 동일시하기: 특정 부서, 특정 질문 유형에서 잘 되던 챗봇이 전사로 확장되면 갑자기 오답률이 올라가는 경우가 흔합니다. 파일럿 범위 밖의 데이터에는 같은 수준의 의미 구조가 없기 때문입니다.
마무리
기업 AI가 챗봇 단계에서 멈추는 건 모델이 부족해서가 아니라, 데이터에 아직 의미가 입혀지지 않았기 때문입니다. 온톨로지는 이 간극을 메우는 실용적인 방법이며, 온톨로지란 무엇인가에서 정리한 “회사의 현실을 옮긴 지도”가 바로 이 단계에서 진가를 발휘합니다.
참고: Gartner 보도자료 “Lack of AI-Ready Data Puts AI Projects at Risk” (2025-02-26) 등 AI-ready 데이터 관련 전망 보고서 (Gartner 자료는 로그인 후 열람 가능)
다음으로 읽을 글
이 문제를 플랫폼 차원에서 어떻게 해결하는지는 기업 데이터 플랫폼을 선택할 때의 판단 기준에서, 실제 온톨로지 설계는 온톨로지 핵심 구성요소에서 이어서 다룹니다.