이 글의 핵심 요약

🔗 지난주 "검색이 무너지면 AI 검색도 무너진다"고 했던 이야기, 기억하시나요?

🧩 그 '검색'을 실제로 작동하게 만드는 기술이 바로 RAG입니다.

📌 RAG가 정확히 뭔지, 왜 LLM 혼자서는 안되는지 오늘 낱낱이 풀어드립니다.

지난주에 남기고 갔던 질문 하나

지난 글에서 기업 AI검색이 왜 실망스러운 답을 내놓는지 이야기했었는데요. 결론은 늘 같았습니다. 모델이 부족해서가 아니라, 근거 문서를 제대로 못 찾아서라는 거였죠.

그리고 이렇게 정리했었죠. 기업 AI검색 = RAG 라고요. 그런데 막상 "RAG가 뭐예요?"라고 물으면 선뜻 명확한 답변을 듣기 어렵습니다.

어디서는 "검색엔진이랑 비슷한 거"라고 하고, 어디서는 "LLM에 문서를 물려주는 기술"이라고 하고... 다 맞는 말인데, 정작 왜 이게 '꼭' 필요한지는 잘 안 알려주거든요. 오늘은 RAG를 처음부터 끝까지, 특히 "왜 우리 회사에 이게 필요한가"에 초점을 맞춰서 설명해드릴게요.

예를 들어볼게요. HR팀 담당자가 "올해 육아휴직 규정이 어떻게 바뀌었어?"라고 물었다고 가정해보죠. 순수 LLM은 예전에 학습했던 일반적인 내용을 바탕으로, 자신있게 옛날 기준의 답을 내놓습니다. 하지만 RAG가 붙어있다면 달라요. 최신 사내 규정 문서를 먼저 검색해서, 실제로 바뀐 부분을 찾아온 다음, 그걸 근거로 답합니다. 같은 질문이지만 결과는 완전히 다릅니다.

✅RAG, 세 글자를 풀어보면

RAG는 Retrieval-Augmented Generation의 줄임말이에요. 한국어로 옮기면 '검색 증강 생성'. 세 단어를 하나씩 뜯어보면 생각보다 단순합니다.

Retrieval(검색) - 질문이 들어오면 관련된 문서를 먼저 찾아옵니다. '작년에 한 그 계약, 만료일이 언제더라?'라는 질문이 들어오면 사내 위키, 계약서, 게시판 글 중에서 관련 있는 조각들을 끌어오는 단계예요.

Augmented(증강) - 찾아온 문서를 LLM에게 "이거 참고해서 답해줘"라고 넘겨줍니다. LLM이 원래 알고 있던 지식에 방금 찾은 문서라는 '재료'를 더해주는거죠.

Generation(생성) - LLM이 그 문서를 근거로 답을 만들어냅니다. 여기서 중요한 건, LLM은 어디까지나 '넘겨받은 문서를 정리해서 말하는 역할'이라는 점이에요.

정리하면, RAG는 '모르는 걸 검색해서 찾아본 다음, 그걸 보고 답하는' 방식을 AI에게 그대로 시키는 기술이에요. 사람이 정확한 자료를 찾아본 뒤에 답하는 과정을 AI가 그대로 흉내 내는 셈이죠. 방식 자체는 이렇게 단순한데, 실무에서 성패가 갈리는 건 결국 '얼마나 정확한 문서를 찾아오느냐'라는 검색의 영역입니다.

✅왜 LLM 혼자서는 안 되는 걸까

"그냥 잘 만들어진 LLM 쓰면 되는 거 아니에요?"라는 질문, 하고 싶으실텐데요. 결론부터 말씀드리면 LLM 단독으로는 기업 환경에서 구조적인 한계가 있어요.

1. 회사 내부 문서를 애초에 학습한 적이 없어요. ChatGPT나 Claude 같은 범용 LLM은 인터넷에 공개된 데이터로 학습합니다. 우리 회사의 사내 규정, 작년 프로젝트 문서, 고객 계약 조건 같은 건 학습 대상이 아니에요.
   

2. 학습 시점 이후 정보는 원래 알던 지식만으로는 알 수가 없어요. LLM은 특정 시점까지의 데이터로 파라미터(모델 내부 지식)를 고정합니다. 이 파라미터 자체를 업데이트하려면 재학습이나 파인튜닝이 필요해요. 물론 웹 검색 기능이 붙어있는 ChatGPT나 Claude는 최신 공개정보를 가져올 수 있습니다. 문제는 회사 내부 문서는 애초에 웹에 없다는 겁니다. 웹 검색을 켜도 사내 문서를 찾아올 수는 없어요.
   

3. 모르면 "모른다"고 하지 않고 그럴듯하게 지어내요. 이게 가장 위험한 부분인데요. LLM은 근거가 없어도 문장을 자연스럽게 만들어내는 데 능숙합니다. 그래서 모르는 질문에도 '그럴듯한 오답'을 지어내는 현상, 흔히 '환각(hallucination)'이라 부르는 현상이 발생해요. 스탠퍼드 RegLab·HAI의 연구에 따르면, 범용 LLM을 법률 질의에 그대로 썼을 땐 환각률이 최대 82%에 달했던 반면, RAG로 문서 근거를 붙이면 17% 수준까지 내려갔습니다.
   

결국 이 세 가지 한계 때문에, "똑똑한 모델을 붙였는데도 회사 문서는 못 찾는" 그 상황이 벌어지는 거에요.

✅실제로는 어떻게 작동하나요

지난 글에서 '질문 → 검색 → 답변'이라는 큰 흐름을 보여드렸었죠. 이번엔 조금 더 자세히 들어가볼게요. 실제 RAG 파이프라인은 보통 이런 4단계로 움직입니다.

1단계. 질문 이해 - 사용자가 입력한 질문의 의도를 파악합니다. '작년 그 계약 언제까지야?' 같은 애매한 질문도, 핵심 키워드와 맥락을 뽑아냅니다.

2단계. 관련 문서 검색 - 사내 문서 저장소(위키, DB, 파일 서버 등)에서 질문과 관련된 문서 조각들을 찾아옵니다. 이 때 형식이 제각각인 비정형 문서를 미리 검색 가능한 형태로 처리&정리해 두는 게 관건이죠. 문서가 있어도 찾지 못하면 소용이 없으니까요.

3단계. 문서를 LLM에게 전달 - 찾아낸 문서 조각들을 LLM에게 넘겨줍니다. '이 문서들을 참고해서 이 질문에 답해줘'라고 지시하는 셈이에요.

4단계. 근거 기반 답변 생성 - LLM이 전달받은 문서를 바탕으로 답을 정리합니다. 잘 만들어진 RAG 시스템은 "어떤 문서를 근거로 이렇게 답했는지" 출처까지 함께 보여줍니다.

여기서 진짜 중요한 포인트 하나. 2단계(검색)의 품질이 나쁘면, 4단계(생성)이 아무리 잘 만들어져도 소용이 없어요. 엉뚱한 문서를 근거로 넘겨받으면, LLM은 그 엉뚱한 문서를 성실하게 요약해서 틀린 답을 내놓을 뿐이거든요. 지난주에 말씀드린 '검색에서 무너진다'는 이야기가 바로 이 지점입니다.

✅LLM vs RAG, '사내 데이터'에서는 무엇이 다른가

여기서 비교하는 건 어디까지나 회사 내부 문서에 대한 답변이에요. 공개된 웹 정보라면 요즘 LLM들도 웹 검색 기능으로 어느정도 커버하거든요. "나는 ChatGPT한테 출처 알려달라고 하면 잘 알려주던데?" 싶으실텐데요, 그게 바로 웹 검색 기능이 켜져있어서예요. 웹 검색도 사실 '공개된 웹'을 대상으로 하는 RAG의 한 형태거든요. 하지만 회사의 내부 문서는 그 웹 검색 범위 밖에 있기 때문에, 사내 문서를 근거로 검색하려면 RAG를 붙여야만 하는 거예요.

위의 표를 보면 명확해지죠. RAG는 LLM을 대체하는 기술이 아니라, 회사 내부 데이터에 대해 LLM이 믿을 수 있는 근거를 갖고 말하게 만든는 기술입니다.

✅그래서, 기업에는 왜 RAG가 필요한가

1. 사내 문서 기반의 정확한 답변 - 계약서, 매뉴얼, 회의록처럼 외부에 공개되지 않은 정보를 근거로 답할 수 있어요. 지난주 예시처럼 '작년 그 계약서 어디에 있더라?'에 실제로 답할 수 있게 되는 거죠.
   

2. 재학습 없이 최신 정보 반영 - 정책이 바뀌거나 새 문서가 추가돼도 모델을 다시 학습시킬 필요 없이 검색 대상 문서만 업데이트하면 됩니다. 새 문서를 추가하거나 바뀐 규정을 반영하는 일이 모델 자체를 다시 손대는 것보다 훨씬 빠르고 가볍게 끝나서, 속도와 비용 면에서도 유리해요.
   

3. 출처 제시로 신뢰성 확보 - '이 답변은 이 문서를 근거로 했습니다.'라고 보여줄 수 있다는 건, 특히 금융이나 공공 같은 규제 산업에서는 선택이 아니라 필수입니다. 답이 틀렸을 땐 '왜'틀렸는지 추적할 수 있어야 하니까요.
   

4. 검색 정확도를 KPI로 관리할 수 있음 - 지난 주 알려드린 AI검색 도입 전 체크리스트의 마지막 항목이, '검색 정확도를 KPI로 관리한다'였는데요. RAG구조에서는 '어떤 문서를 근거로 어떤 답을 냈는지'가 로그로 남기 때문에, 검색 단계의 정확도를 수치로 추적하고 개선할 수 있어요. LLM에서는 불가능한 관리 방식이죠.
   

✅이미 표준으로 자리잡는 중입니다

"우리 회사도 지금 해야하나" 고민하시나요? 세계 최대 IT 자문 기관인 Gartner는 RAG를 '기업 생성형 AI 배포의 핵심 축'으로 규정하면서, LLM에 사내 데이터를 RAG 방식으로 결합하면 정확도가 크게 향상된다고 분석했습니다. 나아가 2028년까지 기업 생성형 AI 앱의 80%가 기존 사내 데이터 관리 기반 위에서 개발될 것으로 전망했는데, 이는 RAG가 특별한 선택이 아닌 기본값이 되어간다는 신호에요. RAG가 '있으면 좋은 기능'이 아니라, '있어야 하는 기반'으로 자리 잡고 있다는 뜻이죠.

자주 묻는 질문(FAQ)

Q. RAG를 붙이면 무조건 정확한 답이 나오나요?

아니요. RAG는 '검색 품질'에 성능이 좌우됩니다. 검색 단계에서 엉뚱한 문서를 가져오면 틀린 답이 나올 뿐이죠. 사내의 여러 비정형 데이터, 업데이트 되는 자료들의 편리한 관리, 정확성과 신뢰성 높은 하이브리드 검색이 동반된 검색 설계가 성패가 갈리는 기술입니다.

Q. 우리 회사도 RAG를 도입하려면 뭐부터 봐야 하나요?

지난 글에서 '도입 전 점검할 5가지'를 제안해드렸어요. 특히 사내 데이터가 '찾을 수 있는' 상태인지 점검해보시길 권유했는데요. 만약 사내 데이터가 정제되어 있지 않고, 이를 정리하기가 엄두가 나질 않든다면 25년간 축적된 NLP, 데이터 분석 기술을 기반으로 비정형 데이터 처리를 자동화한 다이퀘스트의 Q-RAG를 검토해보세요.

출처

• Stanford RegLab · HAI, "Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools", 2024 — hai.stanford.edu
  

• Gartner, "Gartner Predicts by 2028, 80% of GenAI Business Apps Will Be Developed on Existing Data Management Platforms", 2025 — gartner.com