챗GPT가 엉뚱한 답을 줄 때, 무엇이 빠져 있을까?
많은 분들이 이런 경험을 하셨을 것입니다. 분명 그럴듯한 한국어 문장인데, 막상 확인해 보면 숫자가 틀려 있거나, 이미 바뀐 규정을 그대로 말해주는 경우입니다. 모델이 부족해서라기보다, 모델이 참고할 만한 “최신 자료”를 보지 못한 채 머릿속에 있는 기억만 뒤져서 답을 만들기 때문입니다.
사람으로 비유하면 이렇습니다. 예전에 공부한 기억만으로 대답하는 사람과, 답하기 전에 검색이나 문서를 한 번 확인하고 말하는 사람은 신뢰도가 다릅니다. RAG는 LLM을 두 번째 사람처럼 만들어 주는 구조입니다.
RAG란 무엇인가? 한 줄 정의부터 정리하기
RAG(Retrieval-Augmented Generation)는 말 그대로 검색(Retrieval)과 생성(Generation)을 결합한 LLM 활용 방식입니다.모델이 답을 만들기 전에 외부 자료를 검색하고, 그 내용을 입력과 함께 모델에게 넘겨주어 더 정확한 답을 생성하도록 돕는 구조입니다.
조금 풀어서 말하면, “모델이 원래는 모르는 정보라도, 관련 문서를 먼저 찾아서 읽힌 다음 답을 만들게 하는 방식”이라고 이해하시면 됩니다. 그래서 RAG는 LLM의 지식을 무한히 늘리는 기술이 아니라, LLM이 외부 지식을 활용하는 방법에 가깝습니다.
왜 지금 RAG가 중요한가?
요즘 LLM은 매우 똑똑하지만, 세 가지 한계를 피하기 어렵습니다. 훈련 시점 이후의 정보는 모른다는 점, 내부 “기억”이 완벽하지 않다는 점, 그리고 무엇보다도 그럴듯한 거짓말(환각)을 할 수 있다는 점입니다. RAG는 이 세 가지를 한 번에 줄이기 위해 등장했습니다.
특히 기업 문서, 내부 지식, 최근 정책처럼 공개 데이터에 없는 정보는 기본 LLM만으로는 정확한 답을 기대하기 어렵습니다. RAG를 쓰면 회사 문서·매뉴얼·FAQ 같은 내부 자료를 먼저 검색해 모델에 보여줄 수 있기 때문에, “우리 조직 기준”에 맞는 답을 만들 수 있습니다.
RAG의 기본 흐름을 그림 없이 이해해 보기
RAG의 내부 구조는 꽤 복잡해 보일 수 있지만, 입문 단계에서는 네 단계 흐름으로 이해하시면 충분합니다.
- 질문 받기 — 사용자가 자연어로 질문을 합니다. (예: “우리 회사 연차 사용 기준 알려줘”)
- 관련 문서 찾기 — 시스템이 회사 규정집, FAQ, 인트라넷 문서 등에서 이 질문과 가장 관련 있는 문서 몇 개를 골라냅니다.
- 문서와 질문을 함께 모델에 전달 — “사용자 질문 + 찾아온 문서 요약”을 묶어서 LLM에 입력합니다.
- 문서에 근거한 답변 생성 — LLM이 검색된 문서를 참고해 답을 만듭니다. 필요하다면 “이 문서 기준으로”라는 조건도 함께 줍니다.
이 흐름의 핵심은, 모델이 답을 만들기 전에 항상 ‘자료 조사’ 단계를 거친다는 점입니다. 그래서 같은 질문이라도, 어떤 문서를 검색해 넣어 주는지에 따라 답의 품질이 크게 달라집니다.
RAG에서 자주 등장하는 용어를 최소한만 정리하면
RAG를 설명할 때는 벡터DB, 임베딩 같은 용어가 자주 나옵니다. AI 101 단계에서는 이 용어의 역할만 가볍게 알고 계시면 충분합니다.
- 임베딩(Embedding): 문장이나 문서를 숫자 벡터로 바꾼 표현입니다. 의미가 비슷한 문장끼리는 숫자도 서로 비슷해지도록 변환합니다.
- 벡터 DB(Vector DB): 이 숫자 벡터들을 저장해 두고, “이 질문과 가장 가까운 문서가 뭐지?”를 매우 빠르게 찾아주는 전용 데이터베이스입니다.
비유하자면, 임베딩은 문장을 좌표평면에 찍는 작업이고, 벡터 DB는 “이 점 주변에 있는 점들”을 빨리 찾아주는 지도 검색 시스템에 가깝습니다. RAG 시스템은 이 두 가지를 활용해, 질문과 가장 가까운 문서를 골라내고 LLM에게 전달합니다.
기본 LLM 사용과 RAG 사용의 차이를 비교해 보면
같은 질문을 던졌을 때, RAG를 쓰지 않은 경우와 쓴 경우를 비교해 보면 차이가 더 잘 보입니다.
- 일반 LLM: “한국의 최근 개인정보보호법 개정 내용 알려줘.” → 모델이 알고 있는 범위 내에서만 대답, 최신 개정 내용이 빠질 수 있음.
- RAG 기반 LLM: 같은 질문을 받으면 먼저 최신 법령·행정해석 문서를 검색하고, 그 내용을 함께 입력해 답을 생성.
사용자 입장에서는 여전히 “질문 → 답”의 형태로 보이지만, 내부에서는 “질문 → 검색 → 근거 문서 + 질문 → 답”의 과정을 거치고 있습니다. 이 작은 차이가 신뢰도 측면에서 큰 차이를 만듭니다.
어떤 상황에서 RAG가 특히 유용한가?
RAG가 필요한지 판단하는 간단한 기준은 두 가지입니다. “정확해야 하는가?”, “자체 자료를 써야 하는가?”입니다.
- 회사·조직 내부 규정 안내: 인사 규정, 보안 정책, 개발 가이드 등
- 고객 상담·FAQ: 기존 상담 이력, 제품 설명서, 공지사항을 근거로 답해야 하는 경우
- 전문 도메인 지식: 의료, 법률, 회계처럼 근거 문서가 명확한 영역
- 자주 업데이트되는 정보: 요금제, 혜택, 운영 정책, 버전별 기능 등
반대로, 창의적인 글쓰기나 일상 대화처럼 정답이 하나가 아닌 작업에서는 RAG의 중요성이 상대적으로 낮습니다. 이 경우에는 모델의 “생성 능력” 자체가 더 중요한 역할을 합니다.
입문자가 RAG를 볼 때 놓치기 쉬운 오해들
첫 번째 오해는 “RAG를 쓰면 환각이 완전히 사라진다”는 생각입니다. 실제로는 검색된 문서의 품질과 범위에 따라 여전히 틀린 답이 나올 수 있습니다. RAG는 환각을 줄이는 도구이지, 완전히 제거하는 마법이 아닙니다.
두 번째 오해는 “RAG는 아주 복잡한 시스템이라 전문가만 다룰 수 있다”는 인식입니다. 내부 구현은 복잡할 수 있지만, 입문자에게 중요한 것은 질문 → 검색 → 근거 기반 답변이라는 흐름을 이해하는 것입니다. 이 흐름만 이해해도, 어떤 작업에 RAG를 써야 할지 감이 잡히기 시작합니다.
RAG를 직접 쓸 때 무엇을 신경 써야 할까?
앞으로 실전 단계에서 RAG를 직접 구축하거나, RAG 기능이 포함된 서비스들을 사용할 때는 두 가지를 특히 신경 쓰시면 좋습니다.
- 어떤 자료를 검색 대상으로 넣을 것인가? — 오래되었거나 잘못된 문서를 넣으면, 그만큼 틀린 답을 만들 가능성도 함께 올라갑니다.
- 검색된 내용을 어떻게 모델에 전달할 것인가? — 너무 많은 문서를 한꺼번에 넣으면 핵심이 흐려지고, 너무 적게 넣으면 중요한 근거가 빠질 수 있습니다.
AI 101 단계에서는 “좋은 자료를 모아두고, 그 안에서 검색해 답을 만드는 구조” 정도만 이해하시면 충분합니다. 실제로 어떻게 구축하는지는 AI 심화 & 실전 단계에서 다루게 됩니다.
지금 단계에서 기억하면 좋은 RAG의 핵심
정리하면, RAG는 LLM의 능력을 “기억 기반”에서 “자료 조사 기반”으로 확장해 주는 구조입니다. 따라서 LLM이 만능이 아니라는 점을 인정하면서도, 필요한 정보를 스스로 찾아와 더 신뢰도 높은 답을 만들게 하는 하나의 실용적인 방법이라고 보시면 됩니다.
AI 101 입문 단계에서는 RAG의 내부 코드보다, 언제, 왜, 어떤 방식으로 RAG를 써야 하는지를 이해하는 것이 더 중요합니다. 이 인식이 잡혀 있어야 이후 RAG 설계·구축 글을 읽을 때도 훨씬 수월해집니다.
meta_know 인사이트
RAG는 “새로운 모델”이라기보다, 우리가 이미 하고 있던 검색과 확인 과정을 모델에게 맡기는 구조입니다. 그래서 RAG를 이해하면, LLM의 한계를 과장하지도, 과소평가하지도 않고 적절한 선에서 활용하는 감각을 얻을 수 있습니다.
지금은 RAG를 복잡한 기술 용어로 보기보다, “검색하고 나서 말하는 AI” 정도로 인식해 두시는 것이 좋습니다. 이 관점을 바탕으로, 다음 단계에서는 실제 RAG 워크플로우와 구축 사례를 차근차근 살펴보시기를 권합니다.
핵심 정리
- RAG는 검색과 생성을 결합해 LLM이 외부 문서를 참고한 답을 만들게 하는 구조입니다.
- 질문 → 검색 → 근거 문서 + 질문 → 답변 생성의 네 단계 흐름만 이해해도 RAG의 큰 그림을 잡을 수 있습니다.
- 회사 규정, 고객 상담, 전문 지식처럼 정확성과 최신성이 중요한 영역에서 RAG의 효과가 가장 크게 나타납니다.
- AI 101 단계에서는 내부 구현보다 “언제, 왜 RAG를 써야 하는지”를 이해하는 것이 더 중요합니다.