Reddit의 공개 질문을 읽다가 익숙한 혼란을 봤다. RAG를 배우려는데 LangChain, 벡터 데이터베이스, 임베딩부터 한꺼번에 나와 어디서 시작해야 할지 모르겠다는 내용이었다.

질문에 나온 도구를 한 줄씩 적어보니 LangChain → 임베딩 → 벡터 데이터베이스만 남았다. 정작 어디에서 자료를 찾고, 언제 모델이 답하는지는 보이지 않았다. 나도 RAG를 벡터 데이터베이스로 문서 챗봇을 만드는 기술이라고 좁게 보고 있었다.

원 논문과 공식 문서는 제품 이름보다 두 동작을 먼저 보여줬다. 질문과 관련된 자료를 찾고, 그 내용을 질문에 붙여 AI가 답하게 한다. 이 흐름만 잡으면 낯선 도구가 어느 단계에 쓰이는지 구분된다.

질문에서 관련 자료를 찾고 근거를 붙여 답변하는 RAG 흐름

검색한 뒤 답한다

RAG의 세 단어를 동작 순서대로 놓으면 Retrieval(찾기), Augmented(붙이기), Generation(답하기)이다.

흐름은 세 단계다.

질문과 관련된 자료를 찾는다
→ 찾은 내용을 질문에 붙인다
→ 모델이 그 내용을 바탕으로 답한다

예를 들어 사내 휴가 규정을 묻는 챗봇이 있다고 해보자. 모델이 학습할 때 그 회사의 최신 규정을 보지 못했다면, 그냥 질문만 받아서는 정확히 답하기 어렵다.

RAG를 붙이면 먼저 규정 문서에서 관련 부분을 찾는다. “입사 첫해 연차”와 관련된 문단을 질문 옆에 넣고, 모델에게 이 자료를 근거로 답하라고 한다.

RAG 원 논문은 모델 안에 학습된 지식과 바깥에서 검색한 자료를 함께 쓰는 구조를 제안했다. 지금의 제품 구현은 다양해졌지만, 찾고 붙인 뒤 답한다는 중심은 그대로다.

문서는 먼저 찾기 좋은 모양으로 만든다

문서가 수천 장이라면 질문할 때마다 전부 모델에게 보낼 수는 없다. 그래서 질문을 받기 전에 자료를 검색하기 좋은 모양으로 준비한다.

흔한 순서는 이렇다.

  1. PDF, 웹페이지, 데이터베이스 같은 자료를 가져온다.
  2. 긴 문서를 문단이나 작은 덩어리로 나눈다.
  3. 각 덩어리를 검색할 수 있게 색인에 넣는다.
  4. 질문이 들어오면 관련성이 높은 덩어리만 꺼낸다.

Google Cloud의 RAG Engine 문서와 AWS의 Knowledge Bases 문서는 자료 가져오기, 문서 나누기, 색인, 검색, 답변 생성을 이 순서로 설명한다.

여기서 자주 나오는 말이 임베딩이다. 임베딩은 문장의 뜻을 숫자 묶음으로 바꾼 표현이다. 뜻이 비슷한 문장을 가까이 찾는 벡터 검색에 쓴다.

하지만 RAG가 곧 임베딩이나 벡터 데이터베이스라는 뜻은 아니다.

벡터 검색만 써야 하는 것은 아니다

“환불 규정”과 “결제 취소 기준”처럼 표현은 달라도 뜻이 비슷한 문장을 찾을 때 벡터 검색이 유용하다. 반대로 제품 코드 TS-999처럼 글자가 정확히 같아야 하는 질문은 키워드 검색이 더 잘 잡는다.

Anthropic의 Contextual Retrieval 설명은 의미가 비슷한 내용을 찾는 임베딩 검색과 정확한 단어를 찾는 BM25 검색을 함께 사용한다. Elastic의 하이브리드 검색 문서도 키워드 검색과 벡터 검색 결과를 하나의 순위로 합친다.

Microsoft Foundry의 RAG 문서는 검색 방식을 키워드, 의미 기반, 벡터, 혼합 검색으로 나눈다. 중요한 것은 특정 데이터베이스를 고르는 일이 아니라, 질문에 필요한 자료를 빠르고 정확하게 찾는 일이다.

그래서 처음에는 이렇게 보면 된다.

  • 정확한 이름, 코드, 날짜가 중요한가? 키워드 검색을 먼저 본다.
  • 표현이 달라도 비슷한 뜻을 찾아야 하는가? 벡터 검색을 검토한다.
  • 둘 다 필요한가? 두 결과를 합치는 혼합 검색을 검토한다.

RAG는 모델을 다시 학습시키는 일이 아니다

RAG와 미세조정(fine-tuning)도 자주 섞인다. 미세조정은 예시 데이터로 모델의 행동이나 답변 형식을 학습시키는 방법이다. RAG는 질문할 때 바깥 자료를 찾아 입력에 넣는 방법이다.

새 규정 문서가 생기면 모델을 매번 다시 학습시키는 대신 검색 대상 문서를 갱신한다. AWS 문서도 개인 자료를 계속 학습시키지 않고 검색해 답변에 보태는 흐름을 설명한다.

그렇다고 RAG가 항상 미세조정보다 낫지는 않다. 최신 사내 문서나 출처가 필요한 답에는 RAG가 잘 맞는다. 일정한 문체나 특정 출력 형식을 익히게 하려는 목적이라면 미세조정이 더 가까운 선택이다.

검색이 틀리면 답도 틀린다

RAG를 붙였다고 답이 자동으로 정확해지는 것은 아니다.

질문과 무관한 문단을 찾으면 모델은 잘못된 근거로 답한다. 관련 문단을 찾았어도 문서를 너무 잘게 잘라 회사명이나 날짜가 빠지면 뜻을 오해한다. 검색 결과에 답이 없는데도 빈틈을 추측으로 채우기도 한다.

그래서 RAG는 두 구간을 따로 확인해야 한다.

  • 검색: 질문에 필요한 자료가 실제로 검색 결과에 들어왔는가?
  • 생성: 모델이 찾은 자료를 벗어나지 않고 답했는가?

Amazon Bedrock의 평가 문서도 관련 자료를 잘 찾았는지와 유용한 답을 만들었는지를 나눠 평가한다. 최종 답만 보면 검색이 실패했는지, 모델이 근거를 잘못 읽었는지 알기 어렵다.

한 문장으로 정리하면

RAG는 모델에게 모든 문서를 외우게 하는 기술이 아니다.

질문에 필요한 자료를 먼저 찾고,
찾은 내용을 질문에 붙여,
그 근거 안에서 답하게 하는 방식이다.

처음에는 벡터 데이터베이스나 프레임워크부터 고르지 않아도 된다. 작은 문서 몇 개에서 관련 문단을 찾고, 그 문단과 질문을 함께 모델에게 보내는 최소 흐름부터 보면 된다.

모델이 한 번에 볼 수 있는 입력 범위가 궁금하다면 LLM 세션을 기억처럼 믿으면 작업이 흔들린다를 함께 읽어도 좋다. 저장한 정보를 다시 불러오는 흐름은 AI 에이전트 메모리는 어떻게 작동할까?에서 이어진다.

확인한 공식·원 자료

아래 자료는 2026년 8월 28일에 확인했다.

관심 신호로는 X의 RAG 쉬운 설명 게시물과 Reddit의 RAG 입문 질문, 첫 RAG 다음 학습 순서 질문을 읽었다. 기술 사실의 근거로는 사용하지 않았다.