RAG가 뭔가요

2026. 06. 27.

AIRAG

ChatGPT나 Claude를 쓰다 보면 이런 상황이 한 번씩 생긴다.

사용자: 우리 회사 휴가 정책 알려줘
LLM: 죄송합니다. 저는 그 정보를 알지 못합니다.

또는 더 곤란한 상황도 있다.

사용자: 우리 회사 휴가 정책 알려줘
LLM: 연 15일이며 분기별로 5일까지 사용 가능합니다.
사용자: ...우리 회사 정책 어디서 본 거야?
LLM: ... (사실은 지어낸 답)

LLM은 똑똑하지만 너의 회사 위키, 사내 PDF, 어제 올라온 공지사항은 모른다. 이걸 해결하려고 나온 게 RAG다.

RAG는 LLM에게 컨닝페이퍼를 주는 것

RAG는 Retrieval-Augmented Generation의 약자다. 직역하면 "검색으로 보강한 생성"이지만, 더 쉬운 비유가 있다.

시험을 치는데
머릿속 지식만 쓰면 → 그냥 LLM
오픈북으로 책을 펴놓고 푸는 거 → RAG

오픈북 시험을 잘 보려면 두 가지가 필요하다.

1. 책 중에서 지금 문제에 맞는 페이지를 빠르게 찾기 (= 검색)
2. 그 페이지를 보고 답을 쓰기 (= 생성)

RAG도 똑같다.

1. 사용자 질문에 맞는 문서 조각을 검색
2. 그 조각을 LLM에게 같이 넘겨서 답을 만들게 함

왜 RAG가 필요한가

LLM이 답을 못 하는 상황은 크게 세 가지다.

1. 학습 시점 이후의 정보

LLM은 어느 시점까지의 데이터로 학습된다. 그 이후에 일어난 일은 모른다.

2026년 6월에 일어난 일을 물으면
2024년에 학습이 끝난 LLM은 모른다

2. 사내 문서

LLM은 공개된 웹 데이터로 학습된다. 우리 회사 노션, 사내 위키, 내부 PDF는 본 적이 없다.

사용자: 우리 결제 모듈 장애 대응 가이드 알려줘
LLM: 일반적인 결제 장애 대응은 다음과 같습니다... (← 우리 거 아님)

3. 환각 (Hallucination)

가장 무서운 경우다. LLM은 "모릅니다"라고 말하지 않고 그럴듯한 답을 지어낸다.

사용자: 우리 회사 휴가 정책 알려줘
LLM: 연 15일이며 분기별로 5일까지... (지어냄)

RAG는 이 세 가지를 모두 한 방에 해결한다. 실제 문서를 찾아서 LLM에게 같이 넘겨주면, LLM은 그 문서를 근거로 답한다.

가장 단순한 RAG 흐름

RAG는 복잡해 보이지만 본질은 5단계다.

글로 쓰면 이렇다.

1. 문서 수집     (사내 위키, PDF, DB 등을 모음)
2. 청크 분할     (긴 문서를 적당한 크기로 자름)
3. 임베딩 생성   (각 청크를 벡터로 변환해서 저장)
4. 검색          (질문에 비슷한 청크를 꺼냄)
5. LLM 호출      (꺼낸 청크와 질문을 함께 보냄)

각 단계를 풀어쓰면 이렇다.

1. 문서 수집

원본 PDF, 노션, Confluence, DB
       ↓
일정한 텍스트 포맷으로 저장

2. 청크 분할

문서를 통째로 LLM에 넣으면 토큰이 폭발한다. 그래서 작은 조각으로 자른다.

긴 PDF (50페이지)
       ↓
청크 1 (500자) | 청크 2 (500자) | ... | 청크 N

3. 임베딩 생성

각 청크의 의미를 벡터로 바꿔서 저장한다.

"휴가는 연 15일이다" → [0.12, -0.87, 0.33, ...]
"점심값은 1만원이다" → [0.91, 0.04, -0.55, ...]

이 벡터를 벡터 DB(Pinecone, Qdrant, pgvector 등)에 넣어둔다.

4. 검색

사용자가 질문하면, 질문도 똑같이 벡터로 만든다. 그러고 가장 가까운 벡터를 가진 청크들을 꺼낸다.

질문: "휴가 며칠이야?"
       ↓
질문 벡터: [0.10, -0.82, 0.35, ...]
       ↓
가장 가까운 청크: "휴가는 연 15일이다"

5. LLM 호출

꺼낸 청크를 프롬프트에 붙여서 LLM에 보낸다.

[프롬프트]
다음 문서를 참고해서 사용자 질문에 답해줘.

문서: "휴가는 연 15일이다"

질문: 휴가 며칠이야?

[LLM 답변]
연 15일입니다.

이게 RAG의 전부다.

RAG는 검색 + 생성이다

여기서 한 가지 중요한 사실을 짚고 가야 한다.

RAG의 품질 = 검색 품질 × 생성 품질

검색이 망하면 답이 망한다. LLM이 아무리 똑똑해도, 잘못된 문서를 받으면 잘못된 답을 한다.

질문: "휴가 며칠이야?"
검색 결과: "점심값은 1만원이다" (← 잘못 가져옴)
LLM 답변: "점심값은 1만원이라고 합니다" (← 질문 자체를 못 알아듣게 됨)

그래서 실무 RAG에서는 검색 시스템을 얼마나 잘 만드냐가 핵심이 된다.

LLM은 이미 잘한다.
싸움은 검색에서 일어난다.

이 시리즈에서 다룰 내용도 결국 이거다.

임베딩이 뭔지, 벡터 검색이 뭔지       → 이 시리즈
검색 품질을 어떻게 끌어올리는지        → 다음 시리즈 (RAG Retriever 실무)
검색이 잘 되는지 어떻게 관찰하는지     → LLM Observability 시리즈

정리

RAG는 LLM에게 **컨닝페이퍼(문서 조각)**를 같이 주는 기법이다
학습 시점 이후 정보, 사내 문서, 환각 문제를 해결한다
본질은 문서 수집 → 청크 → 임베딩 → 검색 → LLM 호출 5단계
품질을 결정하는 건 검색이다

다음 글에서는 RAG의 핵심 부품인 임베딩과 벡터 검색의 직관을 잡는다. "벡터로 검색한다"는 말이 도대체 무슨 뜻인지부터 풀어볼 거다.