사내 RAG, 왜 답이 시원치 않을까? 답변 품질을 가르는 5가지 요소 (2026)

"우리도 사내 문서 검색 AI 하나 들였는데, 막상 써보니 기대만큼은 아니더라."

사내 RAG를 도입한 조직에서 의외로 자주 나오는 말입니다. 분명 우리 회사 문서를 연결했고 데모에서는 그럴듯하게 답하던 AI가, 실무에서 진짜 질문을 던지면 엉뚱한 페이지를 가리키거나 두루뭉술한 답을 내놓습니다. 어디서부터 잘못된 걸까요?

결론부터 말하면, RAG는 모델만 붙인다고 성과가 나는 기술이 아닙니다. 답변 품질은 모델 그 자체보다, 그 앞뒤를 둘러싼 여러 요소가 얼마나 정교하게 맞물려 있느냐로 결정됩니다. 실제로 같은 LLM을 쓰더라도, 데이터 정제와 검색 파이프라인 설계에 따라 정답률은 수십 퍼센트포인트씩 벌어집니다. 이 글은 RAG가 무엇인지 짧게 짚은 뒤, 도입하고도 답이 시원치 않은 진짜 이유 다섯 가지를 실무자 눈높이에서 풀고, 마지막에 이 다섯 가지를 잘 구현한 시스템 세 가지를 살펴봅니다. 이미 도입한 조직에는 점검표가, 도입을 검토 중인 조직에는 실패를 피하는 사전 체크리스트가 될 것입니다.

먼저, RAG가 정확히 무엇인가요

본론에 들어가기 전에 용어부터 짧게 정리하겠습니다. RAG(검색 증강 생성, Retrieval-Augmented Generation)는 AI가 답을 만들기 전에, 지정된 자료를 먼저 검색해 참고하도록 만드는 기술입니다.

원래 ChatGPT 같은 거대 언어 모델(LLM)은 인터넷의 공개 데이터로 학습되어, 외부에 공개되지 않은 우리 회사 규정이나 최신 보고서는 알지 못합니다. 그래서 사내 규정을 물으면 "모른다"고 하는 대신 그럴듯하게 지어낸 답, 즉 환각(Hallucination)을 내놓죠. RAG는 이 문제를, 회사 자료를 통째로 다시 학습(파인튜닝)시키는 무겁고 비싼 방법 대신, 질문이 들어올 때마다 관련 문서를 찾아 LLM에게 함께 건네주는 방식으로 풉니다. 데이터베이스만 갱신하면 되니 문서가 바뀌어도 모델을 재학습할 필요가 없다는 점이 RAG가 기업 현장에서 사실상 표준이 된 이유입니다.

용어 정의

• LLM(거대 언어 모델): 방대한 텍스트를 학습해 사람처럼 문장을 이해하고 생성하는 AI.

• 환각(Hallucination): 학습하지 않은 내용을 그럴듯하게 지어내는 현상.

• 임베딩/벡터화: 문서를 의미가 비슷할수록 가까운 위치에 놓이도록 숫자 좌표(벡터)로 바꾸는 작업.

• 청킹(Chunking): 긴 문서를 검색하기 좋은 작은 단위(청크)로 쪼개는 작업.

• 벡터DB: 이렇게 만든 벡터를 저장하고 빠르게 유사도 검색을 해주는 데이터베이스.

동작은 크게 두 단계로 나뉩니다. 먼저 평소에 사내 문서를 잘게 쪼개(청킹) 벡터로 바꿔 벡터DB에 쌓아두는 색인(인덱싱) 작업이 있고, 사용자가 질문하면 ⓐ 질문과 관련된 자료를 벡터DB에서 찾아내는 검색(Retrieval) 단계와 ⓑ 찾아낸 자료를 근거로 답을 만드는 생성(Generation) 단계가 실시간으로 이어집니다. 도서관에서 사서가 먼저 필요한 책을 찾아다 주고, 그 책을 펼쳐 답을 정리해 주는 과정과 비슷합니다.

여기서 가장 중요한 통찰이 나옵니다. 답변 품질은 '생성'을 맡는 LLM의 똑똑함만으로 정해지지 않는다는 점입니다. 사서가 엉뚱한 책을 가져오면, 아무리 똑똑한 사람도 제대로 답할 수 없습니다. 도입 후 답이 시원치 않은 이유 대부분이 바로 이 색인과 검색 단계, 그리고 그 주변 설계에 숨어 있습니다. 지금부터 그 다섯 군데를 차례로 들여다보겠습니다.

요소 ① 사내 데이터가 정리돼 있지 않다

가장 흔하고, 가장 과소평가되는 원인입니다. RAG는 우리가 가진 문서에서 답을 찾는 기술이라, 그 문서가 엉망이면 답도 엉망일 수밖에 없습니다. 컴퓨터 과학의 오랜 격언 그대로, "쓰레기를 넣으면 쓰레기가 나옵니다(Garbage In, Garbage Out)". 업계에서 RAG 프로젝트 공수의 절반 이상이 모델이 아니라 데이터 전처리에 들어간다고 말하는 것도 이 때문입니다.

실무 현장의 사내 문서는 생각보다 험난합니다. 같은 규정의 2021년 판과 2024년 개정판이 폴더 여기저기에 흩어져 있고, 제목만 다르고 내용은 같은 중복 문서가 쌓여 있으며, 스캔만 떠놓아 글자 인식이 안 되는 PDF, 표가 이미지로 박혀 있는 보고서, 머리말·꼬리말·페이지 번호 같은 잡음이 본문에 섞인 문서도 흔합니다. 이 상태로 AI에 통째로 넣으면, AI는 옛날 규정과 최신 규정을 구분하지 못한 채 둘 다 그럴듯하게 인용하고, 스캔 문서는 아예 검색 대상에서 빠집니다.

특히 한국 기업 환경에서는 .hwp/.hwpx 한글 파일이라는 변수가 하나 더 붙습니다. 상당수 도구가 한글 파일을 제대로 추출하지 못해, 변환 과정에서 표나 서식이 깨진 채 색인되는 경우가 많습니다. 그래서 도입 효과는 데이터 정리 수준과 거의 비례합니다. 아래처럼 진단해 보면 우리 조직의 현재 위치가 보입니다.

요소 ② 문서를 쪼개는 방식(청킹)이 거칠다

RAG는 긴 문서를 통째로 검색하지 않고, 작은 조각(청크)으로 쪼개 둔 뒤 질문과 가장 비슷한 조각을 찾아옵니다. 그런데 이 쪼개는 방식이 거칠면, 정작 필요한 정보가 조각 경계에서 잘려 나갑니다. 청킹은 RAG에서 가장 지루해 보이지만 답변 품질에 가장 직접적으로 영향을 주는 단계입니다.

가장 흔한 실수는 의미를 무시하고 글자 수로만 자르는 것입니다. 예를 들어 "출장비 식대 한도는 얼마인가요?"라는 질문에서, 정답이 표 한가운데 있는데 청킹이 500자 단위로 표를 가로질러 잘라버리면 '식대 한도'라는 항목명과 실제 금액이 서로 다른 조각으로 흩어집니다. AI는 둘을 연결하지 못하고 엉뚱한 답을 내놓죠. 표가 많은 규정집, 조항 번호가 의미를 갖는 계약서, 도면과 캡션이 짝을 이루는 기술 문서일수록 이 문제가 자주 터집니다.

그래서 잘 만든 RAG는 몇 가지 장치를 둡니다. 첫째, 글자 수가 아니라 문단·조항·표 같은 의미 단위를 존중해 쪼갭니다. 둘째, 조각끼리 앞뒤 문맥이 끊기지 않도록 일부를 겹쳐서 자르는 오버랩을 둡니다. 셋째, 각 조각에 "이건 2024년 취업규칙 3장 15조"라는 메타데이터(출처 정보)를 함께 저장해, 검색 후에도 어디서 나온 내용인지 추적할 수 있게 합니다. 도입한 시스템의 답이 유독 표나 목록, 조항에서 부정확하다면 청킹 전략을 가장 먼저 의심해 볼 만합니다.

요소 ③ 검색이 '비슷한 말'을 못 찾거나, 너무 헐겁게 찾는다

직원들은 규정집에 적힌 공식 용어로 질문하지 않습니다. "출장 가서 밥값 얼마까지 써도 돼요?"라고 묻지, "국내 출장 식비 지급 한도"라고 묻지 않죠. 여기서 검색 방식의 차이가 답을 가릅니다.

단어가 정확히 일치해야 찾는 키워드 검색만 쓰면, 질문과 문서의 표현이 다를 때 답이 분명히 있는데도 "찾을 수 없다"가 나옵니다. 반대로 의미의 유사도만 보는 벡터(의미) 검색만 쓰면, '식대'와 '회식비', '연차'와 '월차'처럼 비슷하지만 다른 개념을 헷갈려 엉뚱한 조각을 가져옵니다. 또 긴 문서에서는 정답이 중간에 묻혀 검색 순위가 밀리는 "중간이 사라지는(lost in the middle)" 현상도 나타납니다.

그래서 품질 좋은 RAG는 이 둘을 함께 쓰는 하이브리드 검색을 택합니다. 키워드 검색(정확한 용어·고유명사·숫자에 강함)과 벡터 검색(표현이 달라도 의미로 잡아냄)을 동시에 돌린 뒤, 두 결과를 합쳐 순위를 다시 매기는 리랭킹(reranking) 단계를 둡니다. 이렇게 하면 "정확히 이 단어"와 "비슷한 뜻" 양쪽을 모두 놓치지 않습니다. 검색해 온 조각 수(top-k)를 몇 개로 둘지, 관련성 점수가 일정 기준에 못 미치는 조각은 버릴지도 품질을 좌우하는 설정값입니다.

한 단계 더 나아간 시스템은, 질문이 모호할 때 멈추지 않고 되묻습니다. "작년 기준인가요, 올해 개정안 기준인가요?", "A사 계약인가요 B사 계약인가요?"처럼요. 일반 검색기가 '검색 결과 없음'을 띄우고 멈추는 자리에서, 능동적으로 질문을 좁혀 가는 것이죠. 도입한 도구가 모호한 질문에 쉽게 포기하거나 매번 빗나간 답을 준다면, 검색 설계가 단순하다는 신호입니다.

요소 ④ 출처를 못 짚으면, 결국 못 믿는다

답이 맞아 보여도 그 근거를 확인할 수 없으면, 실무자는 결국 원본을 다시 뒤집니다. 그러면 RAG를 도입한 의미가 사라지죠. 특히 법무·컴플라이언스·감사·연구처럼 수치나 조항 하나가 틀리면 안 되는 업무에서는, 출처 제시가 부가 기능이 아니라 신뢰의 전제 조건입니다.

잘 만든 RAG는 두 가지를 합니다. 하나는 출처의 정밀성입니다. "어떤 문서를 참고했다" 수준이 아니라 "2024년도 취업규칙 15페이지 3항"처럼 답이 나온 정확한 위치를 짚어, 클릭 한 번으로 원문 해당 구절을 띄워 눈으로 검증하게 해줍니다. 인용한 부분이 실제 문서의 어느 문장인지 하이라이트로 보여주는 것이 이상적입니다.

다른 하나는, 똑같이 중요한 없는 내용을 지어내지 않는 정직함(source-grounding)입니다. 문서에 근거가 없으면 빈칸을 그럴듯하게 메우는 대신 "해당 자료에서는 내용을 찾을 수 없습니다"라고 분명히 선을 긋는 설계라야, 잘못된 정보로 의사결정을 내리는 사고를 막습니다. 실제로 출처 그라운딩을 강하게 거는 도구가 법률·학술 분야에서 선호되는 이유가 여기 있습니다.

도입한 AI가 출처를 두루뭉술하게 대거나, 엉뚱한 페이지를 가리키거나, 모르는 걸 아는 척한다면 실무 신뢰를 깎는 가장 치명적인 증상입니다.

요소 ⑤ 보안 설계가 답변 범위와 품질의 상한선을 정한다

마지막은 보안입니다. 답변 품질과 무관해 보이지만, 실제로는 깊이 얽혀 있습니다. 보안 정책상 가장 민감하고 중요한 문서를 아예 시스템에 넣지 못하면, AI는 그 문서에 대해 답할 수 없으니까요. "왜 그 핵심 계약서 내용은 모르지?"의 답이 사실은 "보안 때문에 색인에서 뺐다"인 경우가 적지 않습니다. 즉 보안 설계가 곧 'AI가 다룰 수 있는 문서의 범위', 다시 말해 답변 품질의 상한선을 정합니다.

여기서 조직은 익숙한 딜레마에 빠집니다. 문서를 외부 클라우드 서버로 보내 색인하는 방식은 편하고 성능도 좋지만, 원본이 회사 밖으로 나간다는 점에서 보안 감사에 걸리고 데이터 주권·규제(개인정보보호법 등) 이슈가 생깁니다. 그렇다고 모든 것을 사내 폐쇄망에 가두는 온프레미스 방식은 가장 안전하지만 GPU 서버 비용과 운영 인력 부담이 큽니다. 이 트레이드오프를 어떻게 푸느냐가 도구 선택의 핵심이 됩니다. 최근에는 문서 검색은 내 PC나 사내에서 처리하고 답변 생성에만 외부 AI를 빌리는 절충형(하이브리드) 설계도 등장해, 보안과 성능 사이의 선택지를 넓히고 있습니다.

도입 후 품질 점검 체크리스트

• [ ] 최신본·구버전이 섞여서 답하지 않는가 (데이터 정리)

• [ ] 한글·표·스캔 문서가 검색에서 누락되지 않는가 (전처리)

• [ ] 표·목록·조항에서 답이 부정확하지 않은가 (청킹)

• [ ] 일상 표현으로 물어도 잘 찾아내는가 (하이브리드 검색)

• [ ] 모호한 질문에 되물어 좁혀 가는가 (능동적 검색)

• [ ] 답의 출처를 페이지·항목 단위로 짚어주는가 (출처 정밀성)

• [ ] 모르는 건 모른다고 하는가 (출처 그라운딩)

• [ ] 보안 때문에 핵심 문서가 빠지지 않았는가 (보안 설계)

그렇다면, 잘 만든 RAG는 어떻게 다를까? 시스템 사례 3가지

앞의 다섯 요소를 실제로 잘 구현한 시스템은 어떤 모습일까요. 성격이 뚜렷하게 다른 세 가지를 살펴보면, 우리 조직에 맞는 방향을 가늠하는 데 도움이 됩니다. 각자 강점이 다르므로, 정답이 아니라 참고 좌표로 보시면 됩니다.

① 글린(Glean): 전사 통합 검색에 강한 엔터프라이즈형

글린은 구글 드라이브, 슬랙, Jira, Confluence 등 100개가 넘는 사내 앱을 한곳에서 검색하는 엔터프라이즈 Work AI 플랫폼입니다. 키워드와 의미 검색을 결합한 하이브리드 검색에, 사내 정보들의 관계를 지도처럼 엮은 자체 지식 그래프를 더해 개인 맞춤형 결과를 줍니다.

가장 큰 특징은 권한 인식(permissions-aware) 설계로, 각 사용자가 원래 접근 권한이 있는 문서만 검색 결과에 노출시켜 정보 유출을 막습니다. 검색 결과는 출처와 함께 제시되고, 회사 데이터로 모델을 학습시키지 않습니다. 다만 공개 가격이 없는 엔터프라이즈 계약 기반이라 사용자당 월 수십 달러 수준에 최소 계약 규모가 크고, 수십 개 소스를 연동·권한 매핑하는 초기 구축이 복잡한 편이라 주로 대기업에 적합합니다.

② 노트북LM(NotebookLM): 출처 그라운딩에 강한 소스 기반형

구글의 노트북LM은 "내가 올린 자료 안에서만 답한다"는 소스 그라운딩 철학을 가장 분명하게 구현한 도구입니다. 모든 답변에 인라인 번호 인용이 붙고, 인용을 클릭하면 원문의 정확한 구절로 이동해 바로 검증할 수 있습니다. 자료에 근거가 없으면 답을 만들어내지 않고 멈추기 때문에 환각이 적어, 변호사·연구자처럼 정확성이 생명인 사용자에게 선호됩니다.

마인드맵·오디오 개요 같은 부가 기능도 강점입니다. 다만 노트북당 소스 수(무료 50개, Plus 300개)와 용량에 제한이 있고, 웹 기반이라 인터넷 연결이 필요하며 자료가 구글 클라우드에 저장된다는 점은 사내 기밀 문서를 다루는 조직에서는 따져봐야 할 지점입니다.

③ 로컬독스: 출처 검증에 특화된 소스 기반형

로컬독스는 앞의 다섯 요소 중 출처 검증을 가장 깊게 파고든 RAG 시스템입니다. 답이 나온 위치를 "어느 문서"가 아니라 페이지·항목 단위까지 정확히 짚어주고, 내장 뷰어에서 원문의 해당 구절을 하이라이트로 띄워 클릭 한 번에 눈으로 검증할 수 있습니다. 답변과 근거 원문을 나란히 놓고 대조하는 방식이라, 실무자가 인용을 그대로 믿지 않고 바로 확인하는 검증 흐름이 자연스럽게 이어집니다.

자료에 근거가 없으면 빈칸을 그럴듯하게 메우는 대신 "해당 자료에서는 찾을 수 없습니다"라고 선을 긋는 점도 강점입니다. 여기에 한글(HWP) 파일과 대용량 문서 처리, 모호한 질문에 되묻는 능동적 검색을 더해, 출처가 정확해야 하는 법무·감사·연구 같은 업무에 맞춰져 있습니다. 다만 글린 같은 전사 앱 통합 검색이나 노트북LM의 오디오·마인드맵 같은 부가 기능보다는 사내 문서 검색과 출처 검증이라는 본연의 기능에 집중한 도구라는 점은 참고하실 만합니다.마무리: RAG의 성패는 '모델'이 아니라 '주변'에 있다

마무리: RAG의 성패는 '모델'이 아니라 '주변'에 있다

정리하면, 사내 RAG의 답이 시원치 않은 이유는 대개 모델이 멍청해서가 아닙니다. 데이터가 정리되지 않았거나, 문서를 거칠게 쪼갰거나, 검색이 비슷한 말을 못 찾거나, 출처를 못 짚거나, 보안 설계가 문서 범위를 좁혔기 때문입니다. 이 다섯 가지가 정교하게 맞물려야 비로소 "믿고 쓰는" 사내 문서 검색 AI가 됩니다.

그래서 도구를 고를 때는 "어떤 LLM을 쓰나"만 물을 게 아니라, 데이터 전처리·청킹·하이브리드 검색·출처 검증·보안 설계 다섯 가지를 각각 어떻게 다루는지 확인하시는 편이 좋습니다. 위에서 본 글린·노트북LM·로컬독스가 서로 다른 강점을 가진 것처럼, 정답은 조직이 무엇을 가장 중시하느냐에 따라 달라집니다. 이미 도입했다면 위 체크리스트로 어느 단계가 약한지 진단해 보시고, 여러분의 필요에 꼭 맞는 현명한 선택으로 조직의 생산성을 높이시길 바랍니다.

참고자료

1. RAG(검색 증강 생성)란? AI가 사내 자료 활용하게 만들기 (위시켓)

2. RAG 기반 '사내 지식 챗봇' 이렇게 구축했습니다 (요즘IT)

3. 검색 증강 생성(RAG)을 구현하는 방법 (Intel)

4. 로컬 RAG vs 클라우드 RAG: 대기업을 위한 선택 가이드 (Wissly)

5. Glean Review 2026: Features, Pricing (Fritz AI)

6. What Is NotebookLM? Features and How to Use It in 2026 (DigitalOcean)