사내 문서와 DB에 ChatGPT를 연결해봤는데, 막상 써보니 기대에 한참 못 미쳤던 경험이 있으신가요. 이 글은 그 실망이 왜 생기는지, 그리고 무엇을 바꿔야 다음 단계로 넘어갈 수 있는지를 실무 관점에서 정리합니다.
2023~2024년 사이, 많은 기업이 거의 같은 순서로 움직였습니다. ChatGPT나 사내 LLM에 회사 문서를 업로드하거나 연결하고, “이제 우리 회사 데이터에 대해 뭐든 물어볼 수 있겠다”는 기대로 파일럿을 시작했습니다. 초기 데모는 꽤 그럴듯했습니다. 그런데 실제 업무에 투입하는 순간부터 이상한 답, 애매한 답, 혹은 그럴듯하지만 틀린 답이 섞여 나오기 시작했고, 결국 “가끔 쓸만한 검색창” 수준에서 프로젝트가 멈추는 경우가 많았습니다.
왜 데모는 성공하고 실전은 실패할까
이 패턴에는 이유가 있습니다. 데모에서 쓰는 질문은 보통 만든 사람이 미리 예상한 질문입니다. 문서 몇 개, 표 몇 개를 정해두고 “이 안에서 잘 나오는 질문”으로 시연합니다. 반면 실무자는 그 범위 밖의 질문을 던집니다. “이번 달 이탈 고객 중 지난 분기 매출 상위 20%였던 고객은 누구인가” 같은 질문은 문서 한두 개를 검색해서 답할 수 있는 성격이 아닙니다. 여러 테이블에 흩어진 정보를 정확한 규칙으로 연결해야 답이 나옵니다.
여기서 대부분의 회사가 선택하는 첫 번째 방법이 RAG(검색증강생성)입니다. 문서나 테이블을 검색 가능한 형태로 인덱싱해두고, 질문이 들어오면 관련 있어 보이는 조각을 찾아 LLM에 함께 넣어 답을 생성하는 방식입니다. 문서 기반 질의응답에는 꽤 잘 맞습니다. 사규나 매뉴얼처럼 “이 안에 답이 그대로 쓰여 있는” 질문에는 특히 강합니다.
문제는 “테이블”로 넘어가는 순간 시작된다
문제는 정형 데이터, 즉 테이블로 넘어가는 순간부터입니다. 사내 DB의 컬럼명은 대개 TB_CUSTOMER, CUST_ID, ORD_STAT_CD 같은 축약형입니다. 사람도 처음 보면 무슨 뜻인지 짐작만 할 수 있는 이름을, LLM도 마찬가지로 “짐작”합니다. 데모에서는 운 좋게 맞을 수 있지만, 실무자는 결과가 틀리면 바로 알아챕니다.
더 큰 문제는 테이블 간의 관계입니다. “고객”이라는 개념 하나가 CRM에서는 CUSTOMER, ERP에서는 CLIENT, 마케팅 시스템에서는 LEAD로 불리고, 이 셋을 연결하는 키 값의 형식도 시스템마다 다른 경우가 흔합니다. RAG는 매번 질문이 들어올 때마다 이 관계를 다시 “탐색”해야 합니다. 어제는 맞는 답을 찾았던 질문이 오늘은 다른 경로로 검색되어 다른 답이 나오기도 합니다. 이런 비일관성은 몇 번만 겪어도 실무자의 신뢰를 잃습니다.
“더 큰 모델”로는 해결되지 않는 이유
이 시점에서 흔히 나오는 반응이 “지금 모델이 부족해서 그런 것 아니냐”는 겁니다. 그래서 더 큰 모델로 바꿔보고, 프롬프트를 정교하게 다듬고, 예시를 잔뜩 넣어봅니다. 어느 정도는 개선됩니다. 하지만 근본 원인은 모델의 추론 능력이 아니라, 애초에 컬럼과 테이블이 “무엇을 의미하는지”, “서로 어떻게 연결되는지”를 알려주는 정보가 어디에도 정의되어 있지 않다는 데 있습니다. 모델을 아무리 키워도, 없는 정보를 만들어낼 수는 없습니다. 모델은 그 빈틈을 “그럴듯한 추측”으로 채우고, 그 추측이 바로 실무자가 지적하는 오답이 됩니다.
실제로 많은 팀이 이 문제를 질문 유형별로 전용 쿼리를 만들어 대응하는 방식으로 우회합니다. 자주 나오는 질문 패턴을 모아 서브 쿼리를 만들고, 이를 관리하는 오케스트레이션 로직을 추가합니다. 처음 몇 개는 잘 작동하는 것처럼 보이지만, 질문 유형이 늘어날수록 관리해야 할 쿼리와 예외 규칙도 함께 늘어나 결국 유지보수가 감당되지 않는 지점에 도달합니다.
그렇다면 무엇이 다른 접근인가
이 문제의 구조를 뒤집어 보면 방향이 보입니다. 매번 질문이 들어올 때마다 의미를 “추측”하게 만들 게 아니라, 데이터를 쓰기 전에 의미를 먼저 정의해두는 겁니다. TB_CUSTOMER, CUST_ID 같은 기술적인 이름을 “고객”, “고객 ID”처럼 업무 용어로 미리 정리하고, “고객이 주문한다”, “주문이 배송으로 이어진다”처럼 테이블 간의 관계도 사람이 이해하는 형태로 미리 연결해두는 접근입니다. 이런 의미 구조를 만드는 방법에는 온톨로지, 지식 그래프, 데이터 카탈로그 등 여러 갈래가 있는데, 이 블로그에서는 주로 온톨로지 관점에서 다룹니다.
이렇게 의미 구조가 미리 갖춰져 있으면, AI는 컬럼명을 추측하는 대신 이미 정의된 개념과 관계를 따라 답을 찾습니다. 같은 질문을 반복해도 같은 경로로 답을 찾기 때문에 일관성이 높아지고, 그 답이 “행동(승인, 실행 등)”과 연결되어 있다면 단순히 텍스트로 답하는 데서 그치지 않고 실제 업무 처리로 이어질 수도 있습니다.
RAG를 버려야 한다는 뜻은 아니다
오해하지 말아야 할 부분이 있습니다. RAG가 틀렸다는 뜻이 아닙니다. 사규, 매뉴얼, 계약서처럼 “문서 안에 답이 그대로 있는” 질의응답에는 RAG가 여전히 빠르고 효율적인 선택입니다. 초기 구축 비용도 낮습니다. 문제는 “회사 데이터를 정확하게, 반복적으로, 그리고 실행까지 이어지게” 다뤄야 하는 영역에서 RAG 하나로 모든 걸 해결하려 할 때 생깁니다. 두 방식은 경쟁 관계가 아니라, 질문의 성격에 따라 나눠 쓰는 도구에 가깝습니다.
다음으로 무엇을 봐야 할까
정리하면, 회사 데이터에 ChatGPT를 붙였는데 쓸모없게 느껴졌던 이유는 대부분 모델의 한계가 아니라 데이터에 의미 구조가 없었기 때문입니다. 이 구조적인 원인을 조금 더 깊이 들여다보고 싶다면 기업 AI가 챗봇에서 멈추는 이유에서 RAG와 온톨로지 기반 접근을 표로 비교해 다루고 있습니다. “온톨로지가 정확히 뭔데?”라는 질문이 남아 있다면 온톨로지란 무엇인가 — 실무자의 관점에서부터 읽어보시길 권합니다.