LLM 기반 AI 서비스의 가장 큰 한계 중 하나는 최신 정보 부족과 도메인 데이터 부재다.
아무리 강력한 모델이라도 회사 내부 문서, 최신 정책, 특정 업무 매뉴얼, 사내 지식 같은 정보는 기본적으로 알지 못한다.
이 문제를 해결하기 위해 많이 사용하는 구조가 바로 RAG(Retrieval-Augmented Generation) 이다.
RAG는 단순히 “문서를 검색해서 붙여주는 기술”이 아니라,
LLM 서비스의 정확도·신뢰도·업무 활용도를 높이기 위한 아키텍처 패턴이다.
이 글에서는 RAG의 개념을 넘어서, 실제 AI 서비스에서 사용할 수 있는 RAG 시스템 설계 패턴을 백엔드 아키텍처 관점에서 정리해본다.
1. RAG란 무엇인가
RAG는 사용자의 질문에 답하기 전에 관련 문서를 먼저 검색하고,
그 검색 결과를 LLM의 입력 컨텍스트로 제공하여 더 정확한 답변을 생성하는 방식이다.
기본 흐름은 다음과 같다.
User Question
↓
Retriever
↓
Relevant Documents
↓
LLM Prompt Context
↓
Generated Answer
즉, LLM이 자기 머리만 믿고 답하는 것이 아니라
외부 지식 기반을 조회한 뒤 답변하도록 만드는 구조다.
2. 왜 RAG가 필요한가
LLM 단독 서비스는 다음 문제가 있다.
1) 최신 정보를 모른다
모델 학습 이후에 생긴 정보는 알지 못한다.
2) 내부 문서를 모른다
사내 위키, 정책 문서, 업무 가이드, 고객 문서 등은 기본적으로 접근할 수 없다.
3) 환각(Hallucination)이 발생한다
모르는 내용을 그럴듯하게 만들어내는 경우가 있다.
4) 출처 기반 답변이 어렵다
업무 시스템에서는 “왜 그렇게 답했는가”가 중요하다.
RAG는 이 문제를 다음 방식으로 완화한다.
- 최신 정보 반영
- 내부 데이터 활용
- 답변 근거 제공
- 환각 감소
3. RAG의 기본 아키텍처
가장 기본적인 RAG 구조는 다음과 같다.
[문서 수집]
↓
[문서 분할 Chunking]
↓
[Embedding 생성]
↓
[Vector DB 저장]
↓
--------------------------------
[사용자 질문]
↓
[질문 Embedding]
↓
[유사 문서 검색]
↓
[Prompt 구성]
↓
[LLM 응답 생성]여기서 핵심 구성요소는 4개다.
- Ingestion Pipeline
- Embedding Model
- Retriever
- LLM Generation Layer
4. RAG 시스템의 핵심 설계 포인트
RAG는 “붙이면 된다” 수준이 아니다.
실제로 품질 차이는 대부분 아래 설계 포인트에서 갈린다.
4.1 문서 수집 방식
입력 데이터의 품질이 낮으면 검색 품질도 낮다.
대표적인 입력 소스는 다음과 같다.
- HTML
- 사내 위키
- DB 데이터
- FAQ
- 정책 문서
- 매뉴얼
- Jira / Confluence / Notion 문서
이 단계에서 중요한 것은 단순 수집이 아니라 정규화다.
예를 들어 PDF에서 다음 문제가 생긴다.
- 줄바꿈 깨짐
- 표 구조 손실
- 머리글/바닥글 반복
- 목차 노이즈
- OCR 오류
그래서 실제 운영에서는 수집 후 아래 처리가 필요하다.
- 불필요 문구 제거
- 제목/본문 구조 분리
- 표/리스트 보존
- 문서 메타데이터 부여
- 최신 버전 기준 정리
4.2 Chunking 전략
RAG 품질에서 가장 중요한 설계 요소 중 하나가 Chunking이다.
문서를 너무 크게 자르면 검색 정밀도가 떨어지고,
너무 작게 자르면 문맥이 끊긴다.
대표 패턴은 다음과 같다.
1) Fixed-size Chunking
일정 길이 기준으로 자른다.
예:
- 500자
- 1000 tokens
장점:
- 구현이 단순함
단점:
- 문맥 단위가 깨질 수 있음
2) Overlapping Chunking
청크 간 일부 구간을 겹치게 자른다.
예:
- chunk size 800
- overlap 150
장점:
- 문맥 단절 완화
단점:
- 저장량 증가
- 중복 검색 가능성
3) Semantic Chunking
문단, 제목, 섹션 단위 등 의미 기준으로 자른다.
장점:
- 문맥 보존에 유리함
단점:
- 구현 복잡도 증가
4) Hierarchical Chunking
문서 계층 구조를 유지한 채 자른다.
예:
- 문서
- 장
- 절
- 문단
- 절
- 장
장점:
- 큰 문맥과 작은 문맥을 함께 다룰 수 있음
이 방식은 정책 문서, 기술 문서, 메뉴얼에서 특히 효과적이다.
5. RAG 설계 패턴
이제 실제 서비스에서 자주 쓰는 설계 패턴을 정리해보자.
패턴 1. Naive RAG
가장 단순한 형태다.
User Question
↓
Vector Search
↓
Top-K Documents
↓
LLM장점:
- 빠르게 구현 가능
- PoC에 적합
단점:
- 검색 정확도 한계
- 질문 의도 파악 부족
- 불필요 문서 유입 가능
이 구조는 데모 단계에서는 좋지만, 운영 단계로 가면 곧 한계가 보인다.
패턴 2. Query Rewrite RAG
사용자 질문을 그대로 검색하지 않고,
검색에 유리한 형태로 질문을 재작성한다.
User Question
↓
Query Rewriter
↓
Optimized Search Query
↓
Retriever
↓
LLM예:
- “연차 이월 기준이 뭐야?”
→ “연차휴가 이월 조건 및 정책 기준”
장점:
- 검색 품질 향상
- 사용자 표현의 모호성 보완
특히 실무에서는 사용자가 질문을 정확히 안 하기 때문에 매우 유용하다.
패턴 3. Hybrid Search RAG
벡터 검색만 쓰지 않고, 키워드 검색(BM25 등)을 함께 사용한다.
User Question
↓
┌───────────────┬───────────────┐
Vector Search Keyword Search
└───────────────┴───────────────┘
↓
Result Merge / Re-rank
↓
LLM
장점:
- 의미 기반 검색 + 정확한 키워드 검색 결합
- 상품명, 코드, 버전명, 정책 번호 같은 데이터에 강함
예를 들어
- 에러 코드
- 정책 조항 번호
- API endpoint 이름
- 클래스명 / 테이블명
이런 것은 키워드 검색이 훨씬 잘 잡는다.
실무형 RAG는 보통 Hybrid Search가 더 낫다.
패턴 4. Re-ranking RAG
1차 검색 결과를 그대로 LLM에 넘기지 않고,
별도의 Re-ranker가 관련도를 재정렬한다.
User Question
↓
Retriever
↓
Top 20 Chunks
↓
Re-ranker
↓
Top 5 Chunks
↓
LLM장점:
- 최종 컨텍스트 품질 향상
- 노이즈 감소
- 긴 문서군에서 성능 개선
이 패턴은 검색량이 많아질수록 중요해진다.
패턴 5. Multi-step RAG
질문이 복잡하면 한 번의 검색으로 부족하다.
이때는 여러 단계로 검색과 reasoning을 반복한다.
User Question
↓
Question Decomposition
↓
Sub-query 1 / 2 / 3
↓
각각 Retrieval
↓
Result Aggregation
↓
LLM Answer
예:
“우리 회사 육아단축근무 규정이랑 연차 차감 방식, 그리고 급여 반영 기준까지 정리해줘”
이 질문은 사실 하나가 아니라 세 개다.
- 육아단축근무 규정
- 연차 차감 정책
- 급여 계산 기준
이럴 때 질문을 분해해서 각각 찾고, 마지막에 합치는 방식이 훨씬 정확하다.
패턴 6. Agentic RAG
Retriever 하나만 두는 게 아니라,
에이전트가 어떤 도구를 사용할지 선택한다.
User Question
↓
Agent
↓
[Vector Search / SQL Query / API Call / Web Search]
↓
Collected Context
↓
LLM장점:
- 정형 데이터와 비정형 데이터 동시 활용
- 복합 질의 대응 가능
예:
- 문서 내용은 Vector DB에서
- 최신 상태는 DB에서
- 실시간 정보는 API에서 조회
즉 실제 업무형 AI 서비스에 가까워진다.
6. Vector DB 설계 포인트
RAG 품질은 Vector DB 제품보다 인덱싱 설계가 더 중요하다.
대표 선택지는 다음과 같다.
- pgvector
- Elasticsearch
- Pinecone
- Weaviate
- Milvus
- Qdrant
선정 기준은 이렇다.
pgvector
- PostgreSQL 기반
- 기존 RDB 운영 경험이 있다면 접근 쉬움
- 작은 규모나 초기 서비스에 적합
Elasticsearch
- 전문 검색 + 벡터 검색 동시 가능
- Hybrid Search에 강함
Pinecone / Weaviate / Qdrant / Milvus
- 대규모 벡터 검색 특화
- AI 서비스 중심 구조에 적합
르무엘님처럼 백엔드/운영 관점이면 초기에는
PostgreSQL + pgvector 또는 Elasticsearch hybrid가 현실적입니다.
7. Metadata Filtering 패턴
실무에서는 단순 유사도 검색만으로 부족하다.
문서 범위를 줄이는 metadata filter가 매우 중요하다.
예:
- 문서 유형 = 인사정책
- 작성 부서 = HR
- 버전 = 최신
- 국가 = KR
- 제품군 = A 서비스
- 공개 범위 = 내부 전용
구조 예시는 이렇다.
User Question
↓
Metadata Filter
↓
Scoped Retrieval
↓
Top-K Search
장점:
- 검색 정확도 상승
- 노이즈 감소
- 권한 분리 대응 가능
운영형 RAG에서는 거의 필수다.
8. Prompt 구성 패턴
좋은 검색 결과가 있어도 Prompt가 나쁘면 답이 흔들린다.
RAG Prompt는 보통 다음 요소를 포함한다.
- 시스템 역할
- 답변 규칙
- 검색된 문서
- 출처 표기 규칙
- 모르면 모른다고 말하라는 규칙
예시 구조:
너는 사내 정책 문서를 기반으로 답변하는 AI다.
반드시 제공된 문서 내용만 사용하라.
문서에 없는 내용은 추측하지 말고 모른다고 답하라.
가능하면 답변 하단에 참고 문서명을 표시하라.
[검색 문서]
...
[질문]
...
핵심은 이거다.
RAG는 검색 품질 + Prompt 통제가 같이 가야 한다.
9. 운영 관점에서의 문제
RAG는 만들기보다 운영이 어렵다.
대표 이슈는 다음과 같다.
1) 문서 최신화
원본 문서가 변경되면 embedding도 다시 생성해야 한다.
2) 권한 문제
사용자마다 볼 수 있는 문서가 다를 수 있다.
3) 응답 지연
검색 + 재정렬 + LLM 호출로 latency가 커진다.
4) 비용 문제
embedding, retrieval, LLM 호출 모두 비용 요소다.
5) 품질 평가
정확도, 재현율, grounding quality를 측정해야 한다.
즉 RAG는 단순 기능이 아니라 운영 시스템이다.
10. RAG 평가 패턴
실제 서비스에서는 “잘 되는 것 같다”로 끝내면 안 된다.
평가 체계가 필요하다.
대표 평가 항목:
- Retrieval Precision
- Retrieval Recall
- Context Relevance
- Answer Groundedness
- Hallucination Rate
- Latency
- Cost per Request
실무에서는 테스트셋을 만들어서
“질문-정답-근거 문서” 형태로 검증하는 방식이 좋다.
11. 백엔드 관점에서 본 RAG 시스템 구조
백엔드 엔지니어 시각에서 RAG는 다음처럼 볼 수 있다.
Client
↓
API Gateway
↓
FastAPI / Spring Backend
↓
RAG Service
├ Query Rewrite
├ Retriever
├ Re-ranker
├ Prompt Builder
└ LLM Client
↓
Vector DB / Metadata DB / Object Storage
즉 RAG는 단순 AI 기능이 아니라
하나의 검색 + 조합 + 생성 파이프라인 서비스다.
백엔드적으로 보면 다음 고민이 필요하다.
- 캐시 전략
- 비동기 처리
- 재시도 정책
- timeout
- observability
- 권한 필터링
- 문서 인덱싱 배치
이 지점부터 RAG는 “AI 장난감”이 아니라 “서비스 설계”가 된다.
12. 어떤 패턴부터 시작해야 하나
실무에서는 처음부터 복잡하게 가면 실패한다.
보통 다음 순서가 현실적이다.
1단계
Naive RAG
- 빠른 PoC
- 문서 ingest 실험
- chunking 검증
2단계
Hybrid Search + Metadata Filter
- 검색 정확도 향상
- 운영 대응 강화
3단계
Re-ranking + Query Rewrite
- 품질 최적화
4단계
Multi-step / Agentic RAG
- 복잡한 업무 질의 대응
즉 단계적 진화가 맞다.
13. 정리
RAG는 단순히 LLM에 문서를 붙여주는 기술이 아니다.
실제로는 검색 시스템, 데이터 파이프라인, 프롬프트 제어, 운영 체계가 결합된 아키텍처다.
좋은 RAG 시스템을 만들기 위해 중요한 것은 다음과 같다.
- 문서 품질
- Chunking 전략
- Retrieval 방식
- Re-ranking
- Metadata filtering
- Prompt 통제
- 운영 및 평가 체계
결국 RAG의 본질은 이것이다.
“LLM이 잘 답하게 만드는 기술”이 아니라,
“LLM이 근거를 가지고 틀리지 않게 답하도록 설계하는 시스템”
AI 서비스가 업무 시스템으로 들어갈수록,
이 RAG 설계 역량은 점점 더 중요한 백엔드 아키텍처 역량이 될 것이다.
'Python (AI Service)' 카테고리의 다른 글
| AI 서비스 개발 스택 정리: LangChain, FastAPI, Vector Database (0) | 2026.03.06 |
|---|---|
| AI 서비스 개발 환경: PyCharm과 Claude Code의 역할 (0) | 2026.03.06 |
| LangChain이란 무엇인가: LLM 기반 AI 서비스를 만드는 프레임워크 (0) | 2026.03.06 |
| AI 서비스의 다음 단계: Multi-Agent Architecture 이해하기 (0) | 2026.03.06 |
| RAG + Multi-Agent 아키텍처: LLM 서비스가 지식을 사용하는 방식 (0) | 2026.03.06 |
