입문자를 위한 RAG, LLM, 벡터DB, 청킹, 임베딩 이해하기

AI 서비스를 개발하려고 하면 RAG, LLM, 벡터DB, 임베딩, 청킹 같은 용어를 자주 접하게 된다. 이 용어들은 각각 따로 존재하는 개념처럼 보이지만, 실제 서비스에서는 하나의 파이프라인 안에서 함께 동작하는 경우가 많다.

예를 들어 “회사 내부 문서를 기반으로 답변하는 챗봇”을 만든다고 하자. 이때 LLM만 사용하면 회사 내부 문서를 모르는 상태에서 답변할 수 있다. 반면 RAG 구조를 사용하면 사용자의 질문과 관련된 문서를 먼저 검색한 뒤, 그 문서를 LLM에게 전달해 답변을 생성하게 만들 수 있다.

이 글에서는 개발자 입문자를 대상으로 RAG 시스템을 구성하는 주요 개념을 기술적인 관점에서 정리한다.

1. LLM이란 무엇인가

LLM은 Large Language Model의 약자다. 한국어로는 대규모 언어 모델이라고 한다. ChatGPT, Claude, Gemini, Llama 계열 모델 등이 대표적인 LLM이다.

LLM은 대량의 텍스트 데이터를 학습해, 입력된 문맥을 바탕으로 다음에 올 토큰을 예측하는 방식으로 동작한다. 사용자가 질문을 입력하면 모델은 그 질문의 의미와 문맥을 바탕으로 답변을 생성한다.

개발 관점에서 LLM은 보통 API 형태로 사용한다. 애플리케이션 서버는 사용자의 입력을 받아 LLM API에 요청을 보내고, 응답으로 생성된 텍스트를 받아 사용자에게 보여준다.

기본적인 흐름은 다음과 같다.

사용자 입력
  → 애플리케이션 서버
  → LLM API 호출
  → LLM 응답
  → 사용자에게 출력

LLM은 다음과 같은 작업에 활용할 수 있다.

• 질문 답변
• 문서 요약
• 문장 분류
• 번역
• 코드 생성
• 코드 설명
• 이메일, 보고서, 블로그 글 작성
• 대화형 인터페이스 구성

하지만 LLM에는 중요한 한계가 있다.

첫째, 학습 데이터에 없는 정보는 정확히 알지 못한다.
둘째, 최신 정보나 내부 문서에 접근하지 못한다.
셋째, 사실이 아닌 내용을 그럴듯하게 생성할 수 있다.
넷째, 긴 문서 전체를 한 번에 처리하는 데 제한이 있다.

이런 한계를 보완하기 위해 RAG 구조가 자주 사용된다.

2. RAG란 무엇인가

RAG는 Retrieval-Augmented Generation의 약자다. 검색 증강 생성이라고도 한다.

RAG는 LLM이 답변을 생성하기 전에 외부 데이터에서 관련 정보를 검색하고, 검색된 정보를 함께 참고해 답변하도록 만드는 구조다.

일반 LLM 호출은 다음과 같다.

질문
  → LLM
  → 답변

RAG 구조는 다음과 같다.

질문
  → 관련 문서 검색
  → 검색된 문서를 프롬프트에 포함
  → LLM
  → 문서 기반 답변

즉, RAG는 LLM 자체를 새로 학습시키는 방식이 아니라, 답변 시점에 필요한 정보를 찾아서 LLM에게 제공하는 방식이다.

예를 들어 사용자가 “우리 회사의 재택근무 규정은 어떻게 되나”라고 질문한다고 하자. LLM은 회사 내부 규정을 모를 수 있다. RAG 시스템은 먼저 사내 규정 문서에서 관련 내용을 검색하고, 검색된 문단을 LLM에게 전달한다. LLM은 그 문단을 바탕으로 답변을 생성한다.

RAG는 다음과 같은 서비스에 적합하다.

• 사내 문서 기반 챗봇
• 고객센터 FAQ 챗봇
• 제품 매뉴얼 검색 서비스
• 법률 문서 검색 및 요약 서비스
• 논문 검색 기반 질의응답 서비스
• 사용자가 업로드한 PDF 기반 챗봇
• 개발 문서 기반 코딩 어시스턴트

RAG의 핵심은 LLM이 답변을 만들기 전에 외부 지식을 검색한다는 점이다.

3. RAG 시스템의 기본 아키텍처

RAG 시스템은 크게 두 가지 단계로 나눌 수 있다.

첫 번째는 인덱싱 단계다. 문서를 미리 처리해서 검색 가능한 형태로 저장하는 과정이다.

두 번째는 질의 단계다. 사용자의 질문이 들어왔을 때 관련 문서를 검색하고 답변을 생성하는 과정이다.

4. 인덱싱 단계

인덱싱 단계는 문서를 벡터DB에 저장하기 위한 준비 과정이다.

전체 흐름은 다음과 같다.

원본 문서 수집
  → 텍스트 추출
  → 전처리
  → 청킹
  → 임베딩 생성
  → 벡터DB 저장

각 단계는 다음과 같다.

4.1 문서 수집

먼저 검색 대상으로 사용할 문서를 모은다.

예를 들면 다음과 같은 데이터가 될 수 있다.

• PDF
• Word 문서
• Notion 페이지
• Google Docs
• HTML 문서
• Markdown 문서
• 데이터베이스에 저장된 게시글
• 고객센터 FAQ
• Slack, Jira, Confluence 데이터

서비스 목적에 따라 어떤 데이터를 검색 대상으로 삼을지 결정해야 한다.

4.2 텍스트 추출

문서에서 실제 텍스트를 추출한다. PDF, DOCX, HTML처럼 파일 형식이 다르면 텍스트를 추출하는 방식도 달라진다.

이 단계에서는 표, 제목, 목록, 코드 블록 같은 구조를 최대한 보존하는 것이 좋다. 단순히 텍스트만 긁어오면 문맥이 깨질 수 있다.

예를 들어 다음 정보는 이후 검색 품질에 영향을 준다.

• 문서 제목
• 섹션 제목
• 문단 구조
• 표의 행과 열
• 코드 블록
• 링크
• 작성일
• 작성자
• 문서 카테고리

문서 구조를 잘 보존하면 검색 결과의 품질과 답변의 정확도가 좋아질 수 있다.

4.3 전처리

전처리는 문서를 검색하기 좋은 형태로 정리하는 작업이다.

예를 들어 다음과 같은 작업을 할 수 있다.

• 불필요한 공백 제거
• 깨진 문자 제거
• 중복 문서 제거
• 너무 짧은 문단 제거
• 개인정보 마스킹
• HTML 태그 정리
• 표를 텍스트 형태로 변환
• 문서의 메타데이터 정리

전처리를 과하게 하면 중요한 정보가 사라질 수 있다. 반대로 전처리가 부족하면 검색 품질이 떨어질 수 있다.

4.4 청킹

청킹은 긴 문서를 작은 단위로 나누는 작업이다. 나누어진 조각을 청크라고 한다.

LLM과 벡터 검색은 보통 문서 전체보다 적절한 크기의 문서 조각을 다룰 때 더 잘 동작한다. 긴 문서를 그대로 임베딩하면 하나의 벡터 안에 너무 많은 주제가 섞일 수 있다. 그러면 특정 질문과 정확히 관련된 부분을 찾기 어려워진다.

예를 들어 30페이지짜리 인사 규정 문서를 하나의 벡터로 저장하는 것보다, “연차”, “병가”, “재택근무”, “퇴직” 같은 섹션 단위로 나누어 저장하는 편이 검색에 유리하다.

청킹 방식에는 여러 가지가 있다.

고정 길이 청킹

문서를 일정한 글자 수 또는 토큰 수로 자르는 방식이다.

문서 전체
  → 500토큰 단위로 분할

구현은 쉽지만 문맥이 중간에 끊길 수 있다.

문단 기준 청킹

문단 단위로 문서를 나누는 방식이다. 문서 구조를 어느 정도 유지할 수 있다.

문단 1
문단 2
문단 3

각 문단이 너무 짧거나 너무 길 경우에는 추가 조정이 필요하다.

제목 기준 청킹

제목과 소제목을 기준으로 문서를 나누는 방식이다. 기술 문서나 정책 문서에 적합하다.

1. 연차 규정
2. 병가 규정
3. 재택근무 규정

사용자의 질문이 특정 섹션과 잘 연결될 가능성이 높다.

오버랩

청크를 나눌 때 앞뒤 내용을 일부 겹치게 하는 방식이다.

예를 들어 500토큰 단위로 자르되, 이전 청크의 마지막 50토큰을 다음 청크에 포함할 수 있다.

청크 1: 1~500토큰
청크 2: 451~950토큰
청크 3: 901~1400토큰

오버랩은 문맥이 끊기는 문제를 줄이는 데 도움을 준다. 다만 오버랩이 너무 크면 저장 용량과 검색 비용이 증가한다.

5. 임베딩이란 무엇인가

임베딩은 텍스트를 숫자 벡터로 변환하는 과정이다.

LLM이나 검색 시스템이 문장의 의미를 계산하려면 텍스트를 숫자 형태로 다룰 수 있어야 한다. 임베딩 모델은 문장, 문단, 문서 조각을 입력받아 고차원 숫자 배열을 출력한다.

예를 들어 다음과 같은 문장이 있다고 하자.

비밀번호를 변경하는 방법
계정 암호를 바꾸는 절차

두 문장은 사용하는 단어가 다르지만 의미가 비슷하다. 임베딩 모델은 두 문장을 서로 가까운 벡터로 변환한다. 이후 벡터DB는 두 벡터 간의 거리를 계산해 유사도를 판단한다.

개발 관점에서 임베딩은 보통 다음과 같이 사용된다.

텍스트 입력
  → 임베딩 모델 호출
  → 숫자 배열 반환

예시 형태는 다음과 같다.

{
  "text": "비밀번호를 변경하는 방법",
  "embedding": [0.012, -0.221, 0.437, ...]
}

실제 임베딩 벡터는 수백 차원에서 수천 차원일 수 있다.

6. 벡터DB란 무엇인가

벡터DB는 임베딩 벡터를 저장하고, 유사한 벡터를 빠르게 검색하기 위한 데이터베이스다.

일반적인 관계형 데이터베이스는 다음과 같은 검색에 강하다.

SELECT * FROM users WHERE id = 10;
SELECT * FROM products WHERE category = 'book';

이런 검색은 정확한 조건을 기준으로 한다.

반면 벡터DB는 “의미적으로 가까운 데이터”를 찾는 데 사용된다.

사용자가 다음과 같이 질문할 수 있다.

퇴사할 때 남은 휴가는 어떻게 되나?

문서에는 다음과 같이 적혀 있을 수 있다.

퇴직 시 미사용 연차는 회사 규정에 따라 정산한다.

두 문장은 단어가 완전히 같지 않지만 의미가 가깝다. 벡터DB는 질문 벡터와 문서 청크 벡터 간의 유사도를 계산해 관련 문서를 찾는다.

벡터DB에 저장하는 데이터는 보통 다음과 같은 형태다.

{
  "id": "chunk_001",
  "text": "퇴직 시 미사용 연차는 회사 규정에 따라 정산한다.",
  "embedding": [0.032, -0.114, 0.827, ...],
  "metadata": {
    "document_id": "hr_policy_2025",
    "title": "인사 규정",
    "section": "퇴직",
    "created_at": "2025-01-01"
  }
}

벡터DB는 단순히 벡터만 저장하는 것이 아니라, 원문 텍스트와 메타데이터도 함께 저장하는 경우가 많다.

대표적인 벡터DB 또는 벡터 검색 도구는 다음과 같다.

• Pinecone
• Weaviate
• Milvus
• Chroma
• FAISS
• Qdrant
• Elasticsearch vector search
• PostgreSQL pgvector

서비스 규모가 작거나 프로토타입 단계라면 Chroma, FAISS, pgvector 같은 선택지가 자주 쓰인다. 대규모 운영 환경에서는 성능, 확장성, 운영 편의성, 권한 관리, 필터링 기능 등을 함께 고려해야 한다.

7. 유사도 검색

벡터DB는 사용자의 질문 벡터와 문서 청크 벡터를 비교해 가까운 벡터를 찾는다. 이를 유사도 검색이라고 한다.

자주 사용되는 유사도 계산 방식은 다음과 같다.

• cosine similarity
• dot product
• Euclidean distance

cosine similarity는 두 벡터의 방향이 얼마나 비슷한지를 계산한다. RAG에서는 cosine similarity가 자주 사용된다.

질의 단계에서는 보통 top-k 검색을 한다.

사용자 질문을 임베딩
  → 벡터DB에서 가장 가까운 청크 k개 검색
  → 상위 k개 문서를 LLM에 전달

예를 들어 top_k = 5라면 질문과 가장 관련성이 높은 청크 5개를 가져온다.

하지만 top-k 값을 크게 한다고 항상 좋은 것은 아니다. 관련 없는 문서가 함께 들어가면 LLM이 혼란스러운 답변을 만들 수 있다. 반대로 top-k 값이 너무 작으면 답변에 필요한 정보가 누락될 수 있다.

8. 질의 단계

질의 단계는 사용자의 질문을 받아 실제 답변을 생성하는 과정이다.

전체 흐름은 다음과 같다.

사용자 질문
  → 질문 임베딩 생성
  → 벡터DB 검색
  → 관련 청크 가져오기
  → 프롬프트 구성
  → LLM 호출
  → 답변 반환

예를 들어 사용자가 다음과 같이 질문한다고 하자.

퇴사할 때 남은 연차는 어떻게 처리되나?

시스템은 먼저 이 질문을 임베딩 모델에 넣어 질문 벡터를 만든다. 그다음 벡터DB에서 이 질문 벡터와 가까운 문서 청크를 찾는다.

검색 결과로 다음 청크가 나올 수 있다.

퇴직 시 미사용 연차는 근로기준법 및 회사 내부 규정에 따라 정산한다.

이제 시스템은 사용자 질문과 검색된 문서를 함께 프롬프트로 구성한다.

아래 참고 문서를 바탕으로 사용자의 질문에 답하라.
문서에 없는 내용은 추측하지 말고 모른다고 답하라.

[참고 문서]
퇴직 시 미사용 연차는 근로기준법 및 회사 내부 규정에 따라 정산한다.

[사용자 질문]
퇴사할 때 남은 연차는 어떻게 처리되나?

LLM은 이 프롬프트를 입력받아 문서 기반 답변을 생성한다.

9. 프롬프트 구성

RAG에서 프롬프트는 매우 중요하다. 검색된 문서를 LLM에게 전달하더라도, LLM이 그 문서를 어떤 방식으로 사용해야 하는지 명확히 알려줘야 한다.

기본적인 RAG 프롬프트 구조는 다음과 같다.

너는 문서 기반 질의응답 assistant다.
아래 참고 문서를 바탕으로 질문에 답하라.
참고 문서에 없는 내용은 추측하지 말고 모른다고 답하라.
답변에는 가능한 한 근거를 포함하라.

[참고 문서]
{retrieved_context}

[질문]
{user_question}

[답변]

프롬프트에서 중요한 점은 다음과 같다.

첫째, 참고 문서를 우선 사용하도록 지시해야 한다.
둘째, 문서에 없는 내용은 추측하지 않도록 해야 한다.
셋째, 답변 형식을 명확히 정해야 한다.
넷째, 필요한 경우 출처를 포함하도록 해야 한다.
다섯째, 여러 문서가 서로 충돌할 때 어떻게 처리할지 정해야 한다.

실제 서비스에서는 프롬프트 하나만으로 답변 품질을 보장하기 어렵다. 검색 품질, 청킹 방식, 임베딩 모델, 문서 품질이 함께 맞아야 한다.

10. 토큰과 컨텍스트 윈도우

토큰은 LLM이 텍스트를 처리하는 기본 단위다. 하나의 단어가 하나의 토큰이 될 수도 있고, 단어의 일부가 하나의 토큰이 될 수도 있다. 한국어는 형태소나 글자 단위에 가깝게 나뉘는 경우도 있다.

컨텍스트 윈도우는 LLM이 한 번에 처리할 수 있는 최대 토큰 수다. 여기에는 사용자의 질문, 시스템 프롬프트, 대화 히스토리, 검색된 문서, 답변 생성에 필요한 공간이 모두 포함된다.

RAG에서는 검색된 문서를 너무 많이 넣으면 컨텍스트 윈도우를 초과할 수 있다. 따라서 검색된 모든 문서를 넣는 것이 아니라, 관련성이 높은 문서를 선별해 넣어야 한다.

예를 들어 컨텍스트 윈도우가 16,000토큰이라고 해도 전부 참고 문서로 사용할 수는 없다.

시스템 지시문
+ 사용자 질문
+ 대화 히스토리
+ 검색된 문서
+ 모델이 생성할 답변 공간
≤ 컨텍스트 윈도우

이 제한 때문에 청킹, top-k 설정, reranking, 요약 등의 전략이 필요하다.

11. Metadata와 필터링

Metadata는 문서나 청크에 붙는 추가 정보다.

예를 들어 사내 문서 검색 시스템에서는 다음과 같은 metadata를 사용할 수 있다.

{
  "document_id": "hr_policy_2025",
  "title": "인사 규정",
  "department": "HR",
  "access_level": "employee",
  "created_at": "2025-01-01",
  "updated_at": "2025-06-01",
  "section": "연차"
}

Metadata는 검색 품질과 권한 관리에 중요하다.

예를 들어 사용자가 인사 문서만 검색하도록 제한할 수 있다.

department = HR

또는 사용자가 접근 권한이 있는 문서만 검색하도록 만들 수 있다.

access_level <= user.access_level

RAG 시스템에서 권한 관리는 매우 중요하다. 사용자가 볼 수 없는 문서가 검색되어 LLM 프롬프트에 들어가면, LLM이 그 내용을 답변으로 노출할 수 있다. 따라서 벡터 검색 전에 권한 필터링을 적용하거나, 검색 시 metadata 조건을 반드시 함께 사용해야 한다.

12. Hybrid Search

벡터 검색은 의미적으로 비슷한 문서를 찾는 데 강하다. 하지만 항상 완벽하지는 않다.

특히 다음과 같은 경우에는 키워드 검색이 더 유리할 수 있다.

• 제품 코드
• 에러 코드
• 주문 번호
• 고유명사
• API 이름
• 함수명
• 법 조항 번호
• 특정 버전명

예를 들어 사용자가 “ERR-5042 해결 방법”을 검색한다면 벡터 검색보다 키워드 검색이 더 정확할 수 있다.

Hybrid search는 벡터 검색과 키워드 검색을 함께 사용하는 방식이다.

벡터 검색 결과
+ 키워드 검색 결과
→ 점수 결합
→ 최종 검색 결과

이 방식은 의미 기반 검색과 정확한 단어 검색의 장점을 함께 사용할 수 있다.

13. Reranking

Reranking은 1차 검색 결과를 다시 정렬하는 과정이다.

벡터DB에서 top-k로 문서를 가져오면, 그 결과가 항상 최적이라고 보장할 수는 없다. 이때 reranker 모델을 사용해 질문과 각 문서의 관련성을 더 정교하게 평가할 수 있다.

흐름은 다음과 같다.

질문
  → 벡터DB에서 top-20 검색
  → reranker로 관련도 재평가
  → 상위 5개만 LLM에 전달

Reranking은 검색 품질을 높이는 데 효과적이지만, 추가 모델 호출이 필요하므로 latency와 비용이 증가할 수 있다.

14. Hallucination과 Grounding

Hallucination은 LLM이 사실이 아닌 내용을 그럴듯하게 생성하는 현상이다.

RAG는 hallucination을 줄이기 위해 사용된다. LLM이 답변할 때 외부 문서를 근거로 삼게 만들기 때문이다. 하지만 RAG를 사용한다고 해서 hallucination이 완전히 사라지는 것은 아니다.

예를 들어 검색 결과가 부정확하거나, 문서가 부족하거나, 프롬프트가 애매하면 LLM은 여전히 추측할 수 있다.

Grounding은 LLM의 답변이 특정 근거에 기반하도록 만드는 것을 의미한다. RAG는 LLM의 답변을 외부 문서에 grounding하는 대표적인 방식이다.

실제 서비스에서는 다음과 같은 방식으로 hallucination을 줄일 수 있다.

• 문서에 없는 내용은 모른다고 답하게 한다.
• 답변에 출처를 포함한다.
• 검색 결과의 유사도 점수가 낮으면 답변하지 않는다.
• 여러 문서가 충돌하면 충돌 사실을 표시한다.
• 중요한 답변은 사람이 검토하도록 한다.
• 로그를 저장하고 실패 사례를 분석한다.

15. RAG와 파인튜닝의 차이

RAG와 파인튜닝은 자주 비교된다.

RAG는 외부 문서를 검색해 LLM에게 제공하는 방식이다. 모델 자체를 다시 학습시키는 것이 아니다.

파인튜닝은 기존 모델을 특정 데이터로 추가 학습시키는 방식이다. 모델의 동작 방식, 답변 스타일, 특정 작업 수행 능력을 바꾸는 데 사용된다.

둘의 차이는 다음과 같이 정리할 수 있다.

RAG
- 외부 지식을 검색해 사용한다.
- 문서가 자주 바뀌는 경우에 유리하다.
- 출처 기반 답변을 만들기 쉽다.
- 내부 문서 QA에 적합하다.

파인튜닝
- 모델을 추가 학습시킨다.
- 특정 형식이나 스타일을 학습시키는 데 유리하다.
- 반복적인 태스크 성능 개선에 적합하다.
- 데이터 준비와 학습 비용이 필요하다.

사내 문서 기반 챗봇을 만든다면 보통 RAG를 먼저 고려한다. 회사 문서는 계속 바뀔 수 있기 때문이다. 문서가 바뀔 때마다 모델을 다시 학습시키는 것은 비효율적이다.

반면 특정 형식으로 답변하게 하거나, 특정 분류 작업을 잘하게 만들고 싶다면 파인튜닝을 고려할 수 있다.

16. 간단한 RAG 구현 흐름

실제 코드 수준에서는 대략 다음과 같은 흐름으로 구현할 수 있다.

문서 저장 단계

documents = load_documents("./docs")

chunks = []
for doc in documents:
    chunks.extend(split_text(doc.text, chunk_size=500, overlap=50))

for chunk in chunks:
    embedding = embedding_model.embed(chunk.text)
    vector_db.insert(
        id=chunk.id,
        vector=embedding,
        text=chunk.text,
        metadata=chunk.metadata
    )

이 단계에서는 문서를 읽고, 청킹하고, 임베딩한 뒤, 벡터DB에 저장한다.

질문 처리 단계

user_question = "퇴사할 때 남은 연차는 어떻게 처리되나?"

question_embedding = embedding_model.embed(user_question)

results = vector_db.search(
    vector=question_embedding,
    top_k=5
)

context = "\n\n".join([result.text for result in results])

prompt = f"""
아래 참고 문서를 바탕으로 질문에 답하라.
문서에 없는 내용은 추측하지 말고 모른다고 답하라.

[참고 문서]
{context}

[질문]
{user_question}
"""

answer = llm.generate(prompt)

이 코드는 단순화된 예시다. 실제 서비스에서는 에러 처리, 권한 관리, 토큰 제한, 캐싱, 로그 저장, 모니터링, 평가 시스템 등이 추가된다.

17. 운영 환경에서 고려할 점

RAG는 개념상 단순해 보이지만 운영 환경에서는 고려할 요소가 많다.

데이터 최신성

문서가 수정되면 벡터DB도 업데이트해야 한다. 원본 문서와 벡터DB 사이에 동기화 전략이 필요하다.

예를 들어 문서가 변경되면 기존 청크를 삭제하고 새로 임베딩할 수 있다. 또는 변경된 부분만 다시 처리할 수도 있다.

권한 관리

사용자가 접근할 수 없는 문서가 검색되면 안 된다. 검색 전에 사용자 권한을 확인하고, metadata 필터를 적용해야 한다.

비용

LLM 호출, 임베딩 모델 호출, 벡터DB 운영에는 비용이 든다. 문서를 자주 다시 임베딩하거나 검색 결과를 너무 많이 LLM에 넣으면 비용이 증가한다.

응답 속도

RAG는 일반 LLM 호출보다 단계가 많다.

질문 임베딩
+ 벡터 검색
+ reranking
+ LLM 호출

각 단계가 latency에 영향을 준다. 캐싱, 비동기 처리, 검색 결과 최적화 등을 고려해야 한다.

평가

RAG 시스템은 답변 품질을 지속적으로 평가해야 한다.

평가할 수 있는 항목은 다음과 같다.

• 질문에 맞는 문서를 검색했는가
• 답변이 문서에 근거하고 있는가
• 문서에 없는 내용을 지어내지 않았는가
• 출처가 정확한가
• 답변이 사용자의 의도에 맞는가
• 응답 속도가 적절한가

RAG의 품질은 LLM 성능만으로 결정되지 않는다. 검색 품질이 매우 중요하다.

18. 전체 개념 연결

이제 각 개념을 하나의 흐름으로 연결할 수 있다.

원본 문서
  → 청킹
  → 임베딩
  → 벡터DB 저장

이것은 문서를 검색 가능한 형태로 준비하는 과정이다.

사용자 질문
  → 질문 임베딩
  → 벡터DB 검색
  → 관련 청크 선택
  → 프롬프트 구성
  → LLM 답변 생성

이것은 사용자의 질문에 답하는 과정이다.

각 개념의 역할은 다음과 같다.

LLM은 최종 답변을 생성한다.
RAG는 검색과 생성을 연결하는 구조다.
임베딩은 텍스트를 의미 기반 벡터로 변환한다.
벡터DB는 임베딩 벡터를 저장하고 유사한 문서를 검색한다.
청킹은 긴 문서를 검색 가능한 작은 단위로 나눈다.
프롬프트는 LLM이 검색된 문서를 어떻게 사용할지 지시한다.
Metadata는 검색 필터링과 권한 관리에 사용된다.
Reranking은 검색 결과의 순서를 더 정교하게 조정한다.
Hybrid search는 벡터 검색과 키워드 검색을 함께 사용한다.
Grounding은 답변이 근거 문서에 기반하도록 만드는 개념이다.

19. 정리

개발자 입문자 관점에서 RAG를 이해할 때 가장 중요한 것은 전체 데이터 흐름이다.

먼저 문서를 수집하고, 텍스트를 추출하고, 청킹한다. 그다음 각 청크를 임베딩해 벡터DB에 저장한다. 사용자가 질문하면 질문도 임베딩하고, 벡터DB에서 관련 청크를 검색한다. 검색된 청크를 프롬프트에 넣고 LLM에게 전달하면, LLM이 문서 기반 답변을 생성한다.

RAG는 LLM의 한계를 보완하는 실용적인 구조다. 특히 내부 문서, 최신 정보, 전문 문서처럼 모델이 기본적으로 알기 어려운 정보를 다룰 때 유용하다.

다만 RAG를 도입한다고 자동으로 좋은 답변이 나오는 것은 아니다. 문서 품질, 청킹 전략, 임베딩 모델, 벡터DB 검색 성능, 프롬프트 설계, 권한 관리, 평가 체계가 함께 맞아야 한다.

결국 RAG 시스템은 단순히 LLM API를 호출하는 기능이 아니라, 검색 시스템과 생성 모델을 결합한 애플리케이션 아키텍처다. 개발자는 LLM뿐 아니라 데이터 처리, 검색, 저장, 권한, 평가까지 함께 고려해야 한다.