RAG 완전 이해
사내 문서 챗봇은 어떻게 만들어지나
① RAG(검색 증강 생성)는 모델에 새 지식을 학습시키는 게 아니라, 질문이 들어올 때마다 관련 문서를 검색해 참고자료로 붙여주는 방식이다. 모델 자체는 그대로다.
② 그래서 문서만 바꾸면 즉시 반영된다. 재학습이 필요 없다는 게 사내 문서 챗봇에 RAG가 표준으로 쓰이는 이유다.
③ 다만 답의 정확도는 결국 검색이 맞는 문서를 찾아왔는지에 달려 있다. 검색이 엉뚱한 조각을 가져오면, 모델은 그걸 근거로 그럴듯하게 틀린 답을 만든다.
① RAG가 필요한 이유 — 지식 컷오프와 사내 문서
모델이 답을 못 하는 이유는 크게 두 가지다. 하나는 지식 컷오프 — 학습이 끝난 시점 이후의 일은 애초에 배운 적이 없다. 다른 하나는 애초에 학습 데이터에 없던 것 — 회사 내부 문서, 개인 자료처럼 공개된 적 없는 정보다. 둘 다 결국 "모델이 모르는 것"이라는 점은 같다.
"그럼 우리 회사 문서로 파인튜닝하면 되지 않나?"는 자연스러운 발상이지만 AI는 어떻게 만들어지나에서 다뤘듯 잘 안 된다. 파인튜닝 데이터는 사전학습에 비하면 극히 적어 새 사실을 안정적으로 심기 어렵고, 어설프게 들어간 지식은 오히려 환각의 재료가 된다. 게다가 문서가 하루만 바뀌어도 매번 다시 학습시켜야 한다면 비용도 시간도 감당이 안 된다.
RAG는 접근 자체를 바꾼다. 모델의 머릿속 지식을 늘리는 대신, 질문할 때마다 필요한 문서를 찾아 옆에 놓아주는 것이다. 모델은 "기억해서" 답하는 게 아니라 "보고" 답한다.
② 작동 원리 — 검색 4단계
이름 그대로 검색(Retrieval) + 증강(Augmented) + 생성(Generation)이다. 실제로는 이런 순서로 진행된다.
| 단계 | 하는 일 |
|---|---|
| ① 쪼개기 | 긴 문서를 문단·섹션 단위의 작은 조각(청크)으로 나눈다 |
| ② 좌표로 바꾸기 | 각 조각을 임베딩이라는 숫자 좌표로 바꿔 벡터 DB에 저장해둔다 |
| ③ 검색 | 질문이 들어오면 질문도 같은 방식으로 좌표로 바꾸고, 가장 가까운 좌표에 있는 문서 조각들을 찾는다 |
| ④ 생성 | 찾은 조각을 "참고 자료"로 프롬프트에 붙여 모델에 전달 → 모델이 그 자료를 근거로 답을 생성한다 |
②의 임베딩은 LLM 작동 원리에서 다룬 그 개념과 정확히 같다 — 비슷한 의미의 텍스트는 좌표 공간에서 가까이 놓인다는 성질을 그대로 이용한다. "휴가 규정"이라는 질문과 "연차 사용 안내" 문서가 글자는 다르지만 좌표는 가깝기 때문에 검색이 된다. RAG는 새로운 기술이라기보다, 이미 있던 임베딩 성질을 검색에 응용한 것에 가깝다.
RAG를 도입해도 모델의 파라미터는 단 하나도 바뀌지 않는다. 매번 다른 참고자료가 프롬프트 앞에 붙을 뿐이다. 그래서 문서를 새로 추가하거나 고치면 다음 질문부터 바로 반영된다 — 재학습을 기다릴 필요가 없다.
③ 왜 환각이 줄어드나 — 그리고 왜 완전히는 안 줄어드나
환각 가이드에서 다뤘듯, 환각은 모델이 사실 확인 없이 확률 높은 문장을 만들기 때문에 생긴다. RAG는 모델이 기억에서 끌어내는 대신 눈앞에 놓인 문서를 보고 답하게 만들어서 이 문제를 크게 줄인다. "지어낼 필요 없이 베낄 자료가 있다"는 뜻이다.
그런데 완전히 없어지지는 않는다. 세 가지 지점에서 여전히 틀릴 수 있다.
- 검색이 엉뚱한 조각을 가져올 때 — 좌표는 가까운데 실제로는 질문과 무관한 문서. 모델은 이걸 근거로 그럴듯하게 답을 만든다.
- 가져온 조각들이 서로 모순될 때 — 오래된 규정과 새 규정이 둘 다 검색되면, 모델이 어느 쪽을 우선할지는 보장되지 않는다.
- 애초에 답이 어느 문서에도 없을 때 — 검색 결과가 없거나 부실해도, 모델은 여전히 그럴듯한 답을 지어낼 위험이 있다.
그래서 RAG 기반 챗봇에 출처(어느 문서, 어느 구간)를 같이 표시하도록 요구하는 게 중요하다. 프롬프트 템플릿에서 다룬 "근거를 요구하는 문장"이 여기서 그대로 검증 장치가 된다 — 답과 함께 나온 출처를 열어보면 검색이 맞았는지 바로 확인할 수 있다.
④ 청크 크기가 왜 중요한가
문서를 얼마나 잘게 쪼갤지는 사소해 보이지만 결과를 크게 바꾼다.
| 청크 | 문제 |
|---|---|
| 너무 작게 쪼갤 때 | 검색은 정확히 되는데 문맥이 잘려서 조각만 봐서는 의미가 안 통한다 ("환불은 불가하다"만 남고 "단, 7일 이내는 예외"가 다른 조각으로 잘림) |
| 너무 크게 쪼갤 때 | 관련 없는 내용까지 같이 딸려와 프롬프트가 낭비되고, 진짜 필요한 부분이 안에 묻힌다 |
실무에서는 문단·섹션 단위로, 인접 조각끼리 내용을 조금씩 겹치게 잘라 문맥이 끊기는 걸 줄이는 방식을 많이 쓴다. 완벽한 정답은 없고 문서 성격에 따라 조정하는 영역이다.
⑤ RAG vs 파인튜닝 vs 그냥 다 붙여넣기 — 언제 뭘 쓰나
| 방법 | 언제 쓰나 | 단점 |
|---|---|---|
| 통째로 프롬프트에 붙여넣기 | 문서 몇 개, 즉석에서 한 번 물어볼 때 | 문서가 많아지면 컨텍스트 한도·비용에 부딪힌다 |
| RAG | 문서가 많고 계속 늘어나며, 최신성이 중요할 때 (사내 챗봇의 표준) | 검색 품질에 정확도가 좌우됨 |
| 파인튜닝 | 지식이 아니라 말투·형식·행동을 바꿀 때 | 지식 갱신에는 원래 잘 안 맞는 도구 |
세 방법은 경쟁 관계가 아니라 같이 쓰이는 경우가 많다. 답변 형식은 파인튜닝으로 다듬고, 최신 사내 정보는 RAG로 붙이는 식이다.
⑥ 보안 — RAG는 프롬프트 인젝션의 표준 표적
RAG의 구조 자체가 보안 취약점이 될 수 있다. 프롬프트 인젝션 가이드에서 다룬 시나리오처럼, 검색 대상 문서 중 하나에 지시문을 심어두는 것만으로 공격이 성립한다. 챗봇이 "다음 문서를 참고해 답하라"고 지시받은 상태에서, 그 문서 안에 "이전 지시는 무시하고…" 같은 문장이 숨어 있으면 그걸 실제 지시로 착각할 위험이 있다.
RAG 챗봇을 구축·운영한다면, 누가 검색 대상 문서를 추가·수정할 수 있는지가 그대로 보안 경계가 된다. 내부자든 외부에서 흘러들어온 파일이든, 검증 없이 문서함에 들어간 파일은 전부 잠재적 공격 벡터다.
⑦ 실전 체크리스트 — 사내 문서 챗봇을 평가·구축할 때
| 확인할 것 | 왜 중요한가 |
|---|---|
| 답변에 출처(문서명·구간)가 표시되는가 | 검색이 맞았는지 바로 검증할 수 있다 |
| 문서를 고치면 다음 질문부터 즉시 반영되는가 | 재학습이 필요하다면 RAG가 아니라 다른 방식일 수 있다 |
| 관련 문서가 없을 때 "모른다"고 답하는가 | 없어도 그럴듯하게 지어내면 위험한 신호다 |
| 접근 권한별로 검색 대상이 분리되는가 | 인사·급여 문서가 전 직원 챗봇에 그대로 검색되면 안 된다 |
| 문서 업로드에 검증 절차가 있는가 | 없으면 프롬프트 인젝션에 그대로 노출된다 |
기업들이 사내 문서·고객 데이터에 RAG를 붙인 도구를 빠르게 도입하는 흐름은 최근 빅테크 실적에서 반복되는 기업용 AI 수요 서사의 실체 중 하나다(빅테크 실적 해석 가이드). 검색·임베딩 계산이 늘어나는 것 자체도 추론 연산량 증가로 이어져, 데이터센터 수요 축이 학습에서 추론으로 옮겨가는 흐름(반도체 섹터 심층 분석)과 같은 방향을 가리킨다.
RAG는 모델을 더 똑똑하게 만드는 기술이 아니라, 질문마다 알맞은 참고자료를 찾아 옆에 놓아주는 검색 시스템이다. 모델은 그 자료를 보고 답할 뿐이다. 그래서 결과의 정확도는 결국 검색이 얼마나 정확한지에 달려 있고, 출처 표시는 그걸 확인하는 유일한 창구다.
※ 본 글은 2026년 9월 기준 일반 원리를 설명한 교육 자료입니다. 실제 구현 방식(청크 크기, 검색 알고리즘, 벡터 DB 종류 등)은 서비스와 도구마다 다르며, 본문은 개념적인 흐름을 다룹니다.
※ 본 가이드는 일반 교육 목적의 참고 자료이며, 이해를 돕기 위해 기술적 세부사항을 단순화했습니다.
새 가이드가 나오면 알려드립니다
AI 리터러시 가이드는 주 2회 발행합니다. 구독하시면 다음 편을 메일로 보내드립니다. 무료이고 언제든 해지할 수 있습니다.