RAG의 한계: 문서 검색만으로는 기업 업무에 답할 수 없는 이유

문서를 찾는 AI와, 업무를 판단하는 AI는 필요한 구조가 다릅니다

사내 AI 도입의 첫 단계로 RAG(검색 증강 생성) 기반 챗봇을 선택하는 기업이 많습니다. 규정집과 매뉴얼, 보고서를 연결하면 직원들이 자연어로 질문하고 문서에 근거한 답을 바로 받을 수 있기 때문입니다. 실제로 복리후생 문의나 업무 절차 안내처럼 반복되는 질문은 눈에 띄게 줄어듭니다.

문제는 그다음입니다. 경영 회의에서 이번 분기 원가율이 급등한 프로젝트를 물으면, AI는 '지연'이나 '원가'라는 단어가 들어간 주간 보고서 문장을 모아 보여줄 뿐 지금 회사 기준으로 어떤 프로젝트가 위험한지는 말하지 못합니다. 영업 파이프라인, 인력 가용성, 목표 달성률처럼 의사결정에 직결되는 주제일수록 한계는 명확해집니다.

이는 RAG 기술 자체의 한계라기보다, 기업 업무의 본질이 '문서 검색'에만 있지 않다는 점을 보여줍니다.
이번 글에서는 이미 많은 기업이 도입한 RAG가 어디까지 충분하고, 어느 지점부터 다른 구조가 필요해지는지 정리해 보겠습니다.

RAG가 잘하는 일: 답이 문서 안에 있을 때

RAG는 질문과 관련된 자료를 먼저 검색한 뒤, 그 자료를 근거로 LLM이 답변을 생성하는 방식입니다. LLM의 일반 지식이 아니라 회사가 가진 자료에 기대어 답하게 만든다는 점에서 기업 AI의 기본 토대라 할 수 있습니다.

따라서 답의 근거가 문서 안에 있는 업무라면 RAG만으로도 충분한 효과를 볼 수 있습니다.

이런 영역에서 답변 품질이 아쉽다면 온톨로지를 고민하기 전에 문서 정비와 검색 정확도 개선이 먼저입니다.
반면 답이 문서 밖, 즉 업무 시스템의 데이터와 회사의 판단 기준 속에 있다면 이야기가 달라집니다.

RAG가 막히는 지점: 답이 문서 밖에 있을 때

실무에서 RAG의 한계가 드러나는 상황은 크게 다섯 가지로 정리할 수 있습니다.

숫자는 문서가 아니라 원천 시스템에서

같은 매출 관련 질문이라도 매출 인식 기준을 묻는 것과 오늘 기준 누적 매출을 묻는 것은 전혀 다릅니다. 앞의 것은 규정 문서에 답이 있지만, 뒤의 것은 ERP에서 현재 값을 확인해야 합니다. 여기에 회사가 정한 산식까지 적용해야 하는 목표 달성률이나 원가율이라면, LLM이 문장을 읽고 직접 계산하게 두는 것은 위험합니다. 그래서 기업 AI는 자연스럽게 답하는 능력과 정확하게 계산하는 구조를 분리해서 설계해야 합니다.

찾을 수 있는 정보와 보여줘도 되는 정보는 다릅니다

팀장이 다른 조직의 인사 정보를, 프로젝트 담당자가 전사 원가 정보를 볼 수 있어서는 안 되는 경우가 많습니다. RAG에 자료를 많이 연결할수록 이 문제는 오히려 커집니다. 자료를 더 붙이기 전에 AI가 누구에게 무엇을 보여줄 수 있는지부터 설계해야 하는 이유입니다.

판단은 하나의 시스템 안에서 끝나지 않습니다

프로젝트 상태 하나를 판단하려 해도 일정과 진척은 PMS에, 매출과 원가는 ERP에, 투입 인력은 HR에, 계약 조건은 CRM에, 변경 요청은 그룹웨어에 흩어져 있습니다. AI가 알아야 하는 것은 각 시스템의 값보다 그 사이의 관계입니다. 이 프로젝트가 어느 고객의 어떤 계약과 연결되어 있는지, 비용 증가와 검수 지연이 동시에 일어나고 있는지를 이해해야 비로소 '위험'이라는 판단이 가능해집니다. 이 지점에서 기업 AI의 과제는 검색에서 업무의 의미와 관계를 이해하는 일로 바뀝니다.

RAG 위에 '업무를 이해하는 층'을 더하다

그렇다고 RAG를 걷어낼 필요는 없습니다. 문서가 중요한 업무에서 RAG는 여전히 핵심 구성 요소입니다. 필요한 것은 그 위에 업무의 의미와 규칙을 담은 층, 즉 기업 온톨로지를 더하는 일입니다.

RAG가 관련 정보를 찾아오는 역할이라면, 온톨로지는 그 정보가 우리 회사 업무에서 무엇을 의미하고 다른 데이터와 어떻게 연결되며 어떤 규칙으로 판단해야 하는지를 알려주는 역할을 합니다.

U.STRA AWP는 하나의 기술을 일괄 적용하지 않습니다. 고객의 업무와 시스템 환경에 맞춰 RAG, Read-only API, 기존 RDB, 지식그래프·GraphRAG, AI Agent를 필요한 만큼 조합하는 방식을 지향합니다.

같은 요청, 다른 답: '투입 가능 인력' 사례

다음 달 시작하는 AI 프로젝트에 Python과 SQL 경험이 있는 내부 인력을 배치해야 하는 상황을 가정해 보겠습니다.
RAG 기반 챗봇은 인력 투입 요청 절차와 담당 부서를 정확히 안내할 수 있습니다. 하지만 지금 누가 투입 가능한지는 답하지 못합니다. 그 답은 규정집이 아니라 PMS의 프로젝트 종료 예정일, HR 시스템의 경력과 역량 정보, 회사가 정한 가동률 기준, 그리고 요청자의 조회 권한 속에 있기 때문입니다.

두 답변의 차이는 AI 모델의 성능이 아니라 답을 만드는 구조에서 나옵니다.

다음 단계가 필요한 시점을 알려주는 신호

RAG를 운영하면서 아래와 같은 현상이 여러 개 보인다면, 문서를 더 추가하기보다 지식구조와 데이터 연결 방식을 점검할 때입니다.

반대로 대부분의 요청이 규정과 매뉴얼 안에서 해결된다면, 지금은 RAG의 문서 품질과 검색 정확도를 높이는 것이 더 효과적인 투자입니다.

시작점은 기술이 아니라 업무 질문입니다

RAG 다음 단계라고 해서 처음부터 지식그래프나 AI Agent를 구축할 필요는 없습니다. 회사에서 매주 반복되지만 답을 만드는 데 오래 걸리는 업무 질문 5개를 고르고, 각각에 필요한 데이터와 문서, 계산식, 업무 규칙, 권한, 근거를 짚어 보는 것으로 충분합니다.

이 과정을 거치면 우리 회사에 필요한 것이 문서 검색 개선인지, 데이터 연동인지, 온톨로지 설계인지가 자연스럽게 드러납니다. '의사결정을 위한 온톨로지(Ontology-for-Decision)'라고 부르는 접근으로, 질문을 고르는 기준은 지난 글 「기업 AI PoC, 핵심 질문 5개에서 시작해야 하는 이유」에서 자세히 다뤘습니다.

더 많은 문서보다, 답을 만드는 구조

RAG는 앞으로도 기업 AI의 중요한 기반입니다. 다만 기업의 업무에는 문서 외에도 시스템 데이터, KPI 산식, 업무 규칙, 권한, 그리고 담당자의 판단 기준이 함께 얽혀 있습니다.

AI가 자료를 찾아주는 도구를 넘어 실제 의사결정을 돕기를 원한다면, 고민의 출발점도 'RAG를 어떻게 더 잘 만들까'에서 'AI가 답해야 할 업무에 어떤 데이터·규칙·근거가 필요한가'로 옮겨 가야 합니다.

💡 자주 묻는 질문 (FAQ)

🎯 RAG가 막히는 지점부터 진단해 보세요.

문서 검색은 잘 되는데 실무 요청 앞에서 멈춘다면,
문서를 더 넣기 전에 그 답에 필요한 데이터와 규칙, 권한, 근거가 무엇인지부터 확인해 볼 때입니다.

U.STRA AWP와 함께 핵심 업무 질문 5개를 정리하고,
RAG로 충분한 영역과 데이터·온톨로지 연결이 필요한 영역의 경계를 그어 보십시오.
그 경계가 RAG 다음 단계의 출발점이 됩니다.