1줄 정의

외부 문서를 가져와 프롬프트에 덧붙여, LLM 이 모르는 정보에도 답할 수 있게 만드는 방식의 총칭.

전체 시스템에서 맡는 역할

LLM 은 학습 데이터에 없는 정보를 답할 수 없다. 사내 문서, 최신 뉴스, 특정 분야 전문 지식 — 이런 건 모델 본체의 가중치에 들어 있지 않기 때문이다.

RAG (Retrieval Augmented Generation, 검색 증강 생성) 는 이 빈 정보를 프롬프트에 보태는 단순한 발상으로 푼다.

구조는 3단계로 압축된다.

• Retrieval (검색): 질문에서 관련 문서를 끌어온다
• Augmentation (부가): 끌어온 문서를 프롬프트에 덧붙인다
• Generation (생성): LLM 이 “질문 + 문서” 를 입력으로 답한다

즉 RAG 는 LLM 을 개조하는 기술이 아니라, LLM 에 대한 입력을 준비하는 공정을 설계하는 틀 이다. 모델 파라미터는 건드리지 않는다.

여기가 먼저 오해되기 쉬운 지점. RAG 는 단일 제품도 알고리즘도 아니고, “외부 지식을 어떻게 프롬프트에 흘려 넣을 것인가” 라는 설계 방침의 범주 이름 에 가깝다. 그래서 RAG 의 변형으로 embedding 기반 검색, GraphRAG, agentic retrieval 같은 것들이 나란히 존재할 수 있다.

흔한 오해

RAG 는 말이 넓어서 해상도가 낮은 채로 이야기되기 쉽다.

• 오해 1: RAG 는 죽었다, 라고 뭉뚱그려지기 쉽다.

– 실제로는 “RAG” 라고 한마디로 말할 때 가리키는 대상이 화자마다 다르다. vector DB 만 가리키는 사람도 있고, agentic retrieval 까지 포함하는 사람도 있다. 죽었다고들 하는 건 대개 “로컬 vector DB + 일회성 붙여넣기 retrieval” 이지, RAG 전체가 아니다.

• 오해 2: RAG 는 모델을 똑똑하게 만드는 기술이다, 라고 여겨지기 쉽다.

– 실제로 모델의 똑똑함은 그대로다. 외부에서 올바른 정보를 넣어 주는 것뿐이다. 모델이 원래 잘못 추론하는 문제는 RAG 로 안 풀린다.

• 오해 3: context window 가 커졌으니 RAG 는 필요 없다, 라는 말이 나오기 쉽다.

– 실제로 전체 문서를 매번 입력하면 비용도 응답 시간도 나빠진다. “관련 부분만 골라서 건넨다” 는 역할은 문서량이 많은 한 남는다. 어느 쪽이 이기는 이야기가 아니라 역할 분담의 이야기다.

이 용어가 중요한 이유

RAG 라는 우산 아래에서 지금 일어나는 분화를 4층 으로 정리해서 읽을 수 있느냐에 따라, AI 도구나 논문을 평가하는 속도가 크게 달라진다. 이게 실무 가치다.

• 1층: embedding 기반 기초 검색
• 2층: GraphRAG 등 구조 검색
• 3층: agentic retrieval (모델이 검색을 호출)
• 4층: Doc-to-LoRA 같은 memory adaptation (retrieval 바깥으로 빼내기)

“RAG 인가요?” 라는 Yes/No 질문은 이 4층을 납작하게 만든다. 반대로 “어느 층에서 뭘 하고 있나” 로 보면 경쟁 제품 차이나 논문 신규성이 갑자기 구체적으로 보인다.

일상적으로 Claude 나 Codex 같은 도구를 쓰는 독자에게 RAG 는 “내가 쓰는 도구가 뒤에서 뭘 조합하고 있는지를 언어화하는 입구” 로 기능한다.

이 용어가 나오는 기사

• 당신의 병목은 RAG 가 아니라, retrieval 의 어느 층에 있는가 (※ 발행 후 실제 URL 로 교체)

다음에 읽을 용어 3개

• embedding — RAG 의 최하층, 기초 검색층.
• agentic retrieval — RAG 의 중심이 이동하고 있는 workflow 층.
• Doc-to-LoRA — RAG 의 “바깥” 으로 등장하는 memory adaptation.