RAG란 무엇인가
처음 ChatGPT 같은 AI를 사용하면 보통 이렇게 생각하기 쉽다.
AI는 이미 모든 지식을 알고 있으니 질문하면 바로 답해준다.
하지만 실제로는 그렇지 않다.
AI 모델은 학습된 데이터를 바탕으로 답변을 생성하지만, 최신 정보, 회사 내부 문서, 개인 프로젝트 문서, 특정 서비스의 정책 같은 내용은 모를 수 있다.
예를 들어 다음과 같은 질문을 했다고 하자.
우리 회사의 휴가 정책 알려줘내 프로젝트 API 명세 기준으로 로그인 흐름 설명해줘이번 달 업데이트된 서비스 약관 요약해줘
일반 LLM은 이런 질문에 정확히 답하기 어렵다.
왜냐하면 모델이 학습할 때 그 문서를 본 적이 없을 수 있기 때문이다.
이 문제를 해결하기 위해 등장한 방식이 RAG이다.
1. RAG의 기본 의미
RAG는 Retrieval-Augmented Generation의 약자이다.
한국어로는 보통 검색 증강 생성이라고 부른다.
단어를 나눠보면 다음과 같다.
| 단어 | 의미 |
|---|---|
| Retrieval | 필요한 정보를 검색함 |
| Augmented | 검색한 정보로 보강함 |
| Generation | AI가 답변을 생성함 |
즉, RAG는 쉽게 말하면 다음과 같다.
AI가 바로 대답하는 것이 아니라, 먼저 관련 문서를 검색한 뒤 그 내용을 참고해서 답변하는 방식
AWS는 RAG를 LLM이 응답을 생성하기 전에 학습 데이터 밖의 신뢰할 수 있는 지식 자료를 참조하도록 하는 방식으로 설명한다.
2. RAG가 필요한 이유
LLM은 강력하지만 한계가 있다.
대표적인 한계는 다음과 같다.
최신 정보를 모를 수 있다.회사 내부 문서를 모른다.특정 프로젝트의 정책이나 구조를 모른다.모르는 내용도 그럴듯하게 지어낼 수 있다.답변의 근거를 확인하기 어렵다.
예를 들어 AI에게 다음과 같이 물어봤다고 하자.
우리 코빕 프로젝트의 템플릿 구매 API 흐름을 설명해줘
AI가 코빕 프로젝트의 ERD, API 명세서, 정책 문서를 가지고 있지 않다면 정확히 답하기 어렵다.
그런데도 일반적인 쇼핑몰 구매 흐름을 바탕으로 그럴듯하게 답할 수 있다.
이게 바로 문제다.
정확한 답변이 필요한 상황에서는 “그럴듯한 답변”보다 근거 있는 답변이 중요하다.
RAG는 이런 상황에서 외부 문서를 검색해 LLM에게 함께 제공함으로써 더 관련성 있고 정확한 답변을 만들 수 있게 한다. IBM도 RAG를 외부 지식 베이스와 연결해 AI 모델의 성능을 높이는 아키텍처로 설명한다.
정리하면 RAG가 필요한 이유는 다음과 같다.
AI가 모르는 정보를 외부 문서에서 찾아서, 근거를 기반으로 답변하게 만들기 위해서
3. RAG의 동작 흐름
RAG의 기본 흐름은 어렵지 않다.
문서 준비→ 문서 쪼개기→ 임베딩 생성→ 벡터 DB 저장→ 사용자 질문 입력→ 관련 문서 검색→ 검색 결과를 프롬프트에 추가→ LLM이 답변 생성
조금 더 쉽게 표현하면 다음과 같다.
1. 미리 문서를 저장해둔다.2. 사용자가 질문한다.3. 질문과 관련 있는 문서를 찾는다.4. 찾은 문서를 AI에게 같이 준다.5. AI가 문서를 참고해서 답변한다.
AWS Prescriptive Guidance에서도 RAG 과정을 내부 문서를 임베딩해 벡터 데이터베이스에 저장하고, 사용자의 질문이 들어오면 관련 데이터를 검색해 프롬프트에 추가한 뒤 LLM이 답변을 생성하는 흐름으로 설명한다.
4. RAG를 도서관에 비유하면
RAG를 도서관에 비유하면 이해하기 쉽다.
일반 LLM은 기억력이 좋은 사람과 비슷하다.
하지만 그 사람이 모든 책의 최신 내용을 외우고 있는 것은 아니다.
특정 회사의 내부 문서 나 최근에 바뀐 정책도 모를 수 있다.
RAG는 이 사람에게 도서관 검색 시스템을 붙여주는 것과 비슷하다.
사용자 질문: "우리 회사 연차 정책 알려줘"1. 질문을 받는다.2. 회사 규정 문서에서 연차 관련 내용을 찾는다.3. 찾은 문서를 읽는다.4. 그 내용을 바탕으로 답변한다.
즉, RAG는 AI가 혼자 기억에 의존하지 않게 만든다.
정리하면 다음과 같다.
RAG는 AI에게 검색 능력을 붙여주는 방식이다.
5. RAG의 핵심 구성 요소
RAG 시스템은 보통 다음 요소들로 구성된다.
| 구성 요소 | 역할 |
|---|---|
| 문서 데이터 | PDF, Markdown, Notion, API 문서, DB 데이터 등 |
| Loader | 문서를 불러오는 역할 |
| Splitter | 긴 문서를 작은 단위로 나누는 역할 |
| Embedding Model | 텍스트를 숫자 벡터로 바꾸는 역할 |
| Vector DB | 임베딩된 문서를 저장하고 검색하는 저장소 |
| Retriever | 질문과 관련 있는 문서를 찾아오는 역할 |
| Prompt | 검색 결과와 사용자 질문을 LLM에게 전달하는 형식 |
| LLM | 최종 답변을 생성하는 모델 |
LangChain 문서에서도 RAG의 검색 파이프라인을 문서 로더, 텍스트 분할기, 임베딩 모델, 벡터 저장소, 검색기 같은 모듈로 설명한다.
정리하면 RAG는 단순히 AI API를 호출하는 구조가 아니다.
문서를 저장하고, 검색하고, 검색 결과를 AI에게 잘 전달하는 전체 구조가 RAG이다.
6. 임베딩이란
RAG를 이해하려면 임베딩을 알아야 한다.
임베딩은 텍스트를 숫자 배열로 바꾸는 작업이다.
예를 들어 다음 문장들이 있다고 하자.
JWT는 인증에 사용된다.Access Token은 로그인 상태를 확인할 때 사용된다.강아지는 귀엽다.
사람이 보기에는 첫 번째와 두 번째 문장이 비슷한 주제라는 것을 알 수 있다.
하지만 컴퓨터는 문장을 그대로 이해하지 못한다.
그래서 문장을 숫자로 바꾼다.
"JWT는 인증에 사용된다."→ [0.12, -0.33, 0.87, ...]"Access Token은 로그인 상태를 확인할 때 사용된다."→ [0.15, -0.29, 0.81, ...]
의미가 비슷한 문장은 벡터 공간에서 가까운 위치에 배치된다.
그래서 사용자가 “로그인 인증 방식 알려줘”라고 물으면 JWT나 Access Token 관련 문서를 찾을 수 있다.
정리하면 임베딩은 다음과 같다.
문장의 의미를 비교할 수 있도록 텍스트를 숫자 벡터로 바꾸는 작업
7. 벡터 DB란
벡터 DB는 임베딩된 문서를 저장하고 검색하는 데이터베이스이다.
일반 데이터베이스는 보통 정확한 값을 찾는 데 강하다.
예를 들어 다음과 같은 검색이다.
SELECT * FROM users WHERE email = 'test@example.com';
하지만 RAG에서는 단순히 같은 단어가 들어간 문서만 찾으면 부족하다.
예를 들어 사용자가 이렇게 물어볼 수 있다.
로그인 유지 방식 설명해줘
문서에는 “Refresh Token”, “세션 유지”, “JWT 재발급”이라는 표현이 있을 수 있다.
단어가 완전히 같지 않아도 의미가 비슷한 문서를 찾아야 한다.
이때 벡터 DB가 사용된다.
벡터 DB는 질문 벡터와 문서 벡터를 비교해서 의미적으로 가까운 문서를 찾는다.
정리하면 벡터 DB는 다음과 같다.
의미가 비슷한 문서를 빠르게 찾기 위해 벡터를 저장하고 검색하는 데이터베이스
8. RAG와 일반 검색의 차이
RAG는 단순 검색과 다르다.
일반 검색은 관련 문서를 찾아서 보여주는 것에 가깝다.
사용자 질문→ 관련 문서 검색→ 검색 결과 목록 제공
RAG는 검색한 문서를 바탕으로 AI가 답변까지 생성 한다.
사용자 질문→ 관련 문서 검색→ 검색 결과를 AI에게 전달→ AI가 문서를 참고해서 답변 생성
차이를 표로 정리하면 다음과 같다.
| 구분 | 일반 검색 | RAG |
|---|---|---|
| 목적 | 문서 찾기 | 문서를 참고한 답변 생성 |
| 결과 | 검색 결과 목록 | 자연어 답변 |
| AI 사용 | 필수 아님 | LLM 사용 |
| 근거 문서 | 사용자가 직접 읽음 | AI가 참고해서 요약 |
| 예시 | 구글 검색, 문서 검색 | 문서 기반 챗봇, 사내 지식 QA |
정리하면 다음과 같다.
일반 검색은 문서를 찾아주는 것이고, RAG는 찾은 문서를 바탕으로 답변까지 만들어주는 것이다.
9. RAG와 파인튜닝의 차이
RAG를 처음 배우면 파인튜닝과 헷갈릴 수 있다.
둘 다 AI를 특정 목적에 맞게 개선하는 방법이기 때문이다.
하지만 방향이 다르다.
| 구분 | RAG | 파인튜닝 |
|---|---|---|
| 방식 | 외부 문서를 검색해서 참고 | 모델을 추가 학습 |
| 데이터 반영 | 문서만 업데이트하면 됨 | 다시 학습이 필요할 수 있음 |
| 비용 | 상대적으로 낮음 | 상대적으로 높을 수 있음 |
| 적합한 경우 | 최신 정보, 내부 문서, 정책 QA | 말투, 형식, 특정 작업 패턴 학습 |
| 예시 | 사내 문서 챗봇 | 고객센터 답변 스타일 학습 |
예를 들어 회사의 휴가 정책이 바뀌었다고 하자.
RAG는 휴가 정책 문서만 수정하고 다시 색인하면 된다.
하지만 파인튜닝은 모델에 새 정책을 다시 학습시켜야 할 수 있다.
AWS도 RAG를 사용하면 모델을 재학습하지 않고 조직이나 도메인별 정보를 더 비용 효율적으로 도입할 수 있다고 설명한다.
정리하면 다음과 같다.
지식을 넣고 싶으면 RAG, 행동 방식이나 답변 스타일을 바꾸고 싶으면 파인튜닝에 가깝다.
10. RAG 구현 예시
예를 들어 개발 문서 기반 Q&A 챗봇을 만든다고 하자.
사용자가 다음과 같이 질문한다.
우리 프로젝트에서 Refresh Token은 어디에 저장돼?
RAG가 없다면 LLM은 일반적인 답변을 할 수 있다.
Refresh Token은 보통 Redis나 DB에 저장합니다.
하지만 이 답변은 일반론이다.
우리 프로젝트에서 실제로 Redis를 쓰는지, DB를 쓰는지는 모른다.
RAG를 적용하면 다음과 같은 흐름이 된다.
1. API 명세서, ERD, README, 보안 정책 문서를 저장한다.2. 사용자가 Refresh Token 저장 위치를 질문한다.3. RAG가 관련 문서를 검색한다.4. 검색된 문서에 "Refresh Token은 Redis에 저장한다"는 내용이 있다.5. LLM이 해당 내용을 참고해서 답변한다.
그러면 답변은 이렇게 바뀔 수 있다.
우리 프로젝트에서는 Refresh Token을 Redis에 저장합니다.이유는 토큰 만료 관리와 로그아웃 시 즉시 무효화 처리를 쉽게 하기 위해서입니다.관련 내용은 인증 설계 문서의 Token Storage 섹션에 정의되어 있습니다.
정리하면 다음과 같다.
RAG는 일반적인 답변이 아니라, 내가 가진 문서를 기준으로 답변하게 만든다.
11. RAG를 사용할 수 있는 분야
RAG는 여러 분야에서 사용할 수 있다.
사내 문서 검색 챗봇개발 문서 Q&A법률 문서 요약의료 가이드 검색논문 기반 질의응답고객센터 자동 답변교육용 학습 도우미프로젝트 문서 분석API 명세 기반 챗봇
예를 들어 개발자 입장에서는 다음과 같은 서비스를 만들 수 있다.
README 기반 프로젝트 설명 챗봇API 명세서 기반 백엔드 Q&AERD 기반 테이블 관계 설명 챗봇장애 로그 기반 원인 분석 도우미기술 블로그 기반 검색형 AI
특히 문서가 많고, 사용자가 매번 직접 찾아보기 어려운 서비스에 RAG가 잘 맞는다.
정리하면 다음과 같다.
RAG는 문서가 많고, 그 문서를 바탕으로 정확히 답변해야 하는 서비스에 적합하다.
12. RAG의 한계
RAG를 쓰면 모든 문제가 해결되는 것은 아니다.
RAG에도 한계가 있다.
문서를 잘못 검색하면 답변도 틀릴 수 있다.문서 자체가 오래되었으면 오래된 답변을 한다.문서 쪼개기를 잘못하면 중요한 맥락이 끊긴다.검색 결과가 너무 많으면 LLM이 핵심을 놓칠 수 있다.권한 처리를 잘못하면 민감한 문서가 노출될 수 있다.
예를 들어 사용자에게 권한이 없는 문서까지 검색 결과에 포함되면 보안 문제가 생길 수 있다.
또 문서가 다음처럼 나뉘어 있다고 하자.
1번 조각: Refresh Token은 Redis에 저장한다.2번 조각: 단, 운영 환경에서는 암호화 저장 정책을 적용한다.
만약 1번 조각만 검색되고 2번 조각이 빠지면 답변이 불완전해질 수 있다.
정리하면 다음과 같다.
RAG의 품질은 모델만이 아니라 문서 품질, 검색 품질, 권한 처리, 프롬프트 설계에 크게 좌우된다.
13. 좋은 RAG를 만들기 위해 신경 쓸 점
RAG를 잘 만들기 위해서는 단순히 벡터 DB를 붙이는 것만으로는 부족하다.
중요한 요소는 다음과 같다.
| 항목 | 설명 |
|---|---|
| 문서 품질 | 오래되거나 중복된 문서를 정리해야 함 |
| 청킹 전략 | 문서를 적절한 크기로 나눠야 함 |
| 메타데이터 | 문서 제목, 작성일, 카테고리, 권한 정보 등을 함께 저장 |
| 검색 품질 | 질문과 관련 있는 문서를 잘 찾아야 함 |
| 재랭킹 | 검색 결과 중 더 중요한 문서를 다시 정렬 |
| 프롬프트 설계 | 검색된 문서를 근거로 답변하도록 지시 |
| 출처 표시 | 답변이 어떤 문서를 기반으로 했는지 보여줌 |
| 권한 관리 | 사용자별로 접근 가능한 문서만 검색 |
| 평가 시스템 | 답변 정확도와 검색 품질을 지속적으로 측정 |
특히 실무에서는 “답변이 그럴듯한가”보다 다음이 더 중요하다.
근거 문서를 제대로 찾았는가?문서에 없는 내용을 지어내지 않았는가?최신 문서를 참고했는가?사용자 권한에 맞는 문서만 사용했는가?
정리하면 다음과 같다.
RAG는 AI 기능이 아니라 검색 시스템과 문서 관리 시스템까지 포함한 구조로 봐야 한다.
14. 기본 RAG와 발전된 RAG
처음에는 보통 단순한 RAG 구조로 시작한다.
질문→ 문서 검색→ LLM 답변
하지만 서비스가 복잡해지면 다양한 구조가 필요해진다.
LangChain 문서에서는 RAG 구조를 2-Step RAG, Agentic RAG, Hybrid RAG 등으로 나누어 설명한다.
간단히 정리하면 다음과 같다.
| 구분 | 의미 |
|---|---|
| 기본 RAG | 질문이 들어오면 관련 문서를 검색한 뒤 답변 |
| 2-Step RAG | 검색 후 생성 흐름이 고정된 단순하고 예측 가능한 구조 |
| Agentic RAG | AI가 필요할 때 도구나 검색을 스스로 선택해서 사용 |
| Hybrid RAG | 검색, 검증, 재검색 등을 섞어 답변 품질을 높이는 구조 |
처음부터 복잡한 Agentic RAG를 만들 필요는 없다.
대부분의 프로젝트는 다음 구조로 시작해도 충분하다.
문서 업로드→ 청킹→ 임베딩→ 벡터 DB 저장→ 질문→ 유사 문서 검색→ LLM 답변→ 출처 표시
정리하면 다음과 같다.
처음에는 기본 RAG로 시작하고, 검색 품질과 답변 품질이 부족할 때 고급 구조를 붙이는 것이 좋다.
마무리
RAG는 AI가 모든 것을 외우게 만드는 기술이 아니다.
오히려 반대에 가깝다.
AI가 모르는 내용은 외부 문서에서 찾고, 그 문서를 근거로 답변하게 만드는 방식이다.
간단히 정리하면 다음과 같다.
| 구분 | 설명 |
|---|---|
| RAG | 검색 증강 생성 |
| 목적 | 외부 문서를 참고해 더 정확한 답변 생성 |
| 핵심 흐름 | 검색 → 문서 제공 → 답변 생성 |
| 주요 구성 | 문서, 임베딩, 벡터 DB, Retriever, LLM |
| 장점 | 최신 정보, 내부 문서, 근거 기반 답변에 유리 |
| 한계 | 검색 품질, 문서 품질, 권한 관리가 중요 |
| 적합한 서비스 | 사내 문서 챗봇, 개발 문서 QA, 학습 플랫폼, 고객센터 |
결국 RAG를 이해할 때 가장 중요한 것은 다음이다.
RAG는 AI에게 “기억”을 추가하는 것이 아니라, “필요한 자료를 찾아 읽고 답하는 구조”를 붙이는 것이다.
그래서 RAG를 잘 만들려면 단순히 LLM API를 잘 쓰는 것만으로는 부족하다.
좋은 문서 구조, 검색 품질, 권한 처리, 프롬프트 설계, 출처 표시까지 함께 설계해야 한다.
참고자료
RAG 기본 개념
RAG 동작 흐름 / 아키텍처
- AWS Prescriptive Guidance - 검색 증강 생성 이해
- Microsoft Learn - RAG 및 생성 AI, Azure AI Search
- Google Cloud - RAG를 사용한 생성형 AI