이 문서는 자라는 중인 질문입니다. 아직 증거를 모으고 있으며, 내용이 바뀔 수 있습니다.
한 줄로 말하면
RAG는 모델이 자기 안에 외운 것만으로 답하지 않고, 질문할 때마다 외부 자료를 찾아 붙인 뒤 답을 만들게 하는 구조야.
비유로 이해하기
시험을 보는 사람에게 책을 전부 외우게 할 수도 있고, 필요한 순간에 도서관 색인에서 관련 책 몇 쪽을 찾아 보게 할 수도 있어. RAG는 두 번째에 가까워. 모델이 모든 사실을 가중치 안에 새겨 두는 대신, 질문과 관련된 문서 조각을 먼저 찾아서 답변 작업대 위에 올려놓는 방식이야.
여기까지가 이해를 돕는 비유야. 실제 시스템에서는 사람이 직접 책을 고르는 게 아니라 검색 인덱스, 임베딩, 순위 매기기, 권한 검사, 프롬프트 구성이 이어져. 그래서 RAG는 단순히 “검색을 붙인다”가 아니라, 어떤 자료를 믿고 어떤 순서로 모델에게 보여 줄지 정하는 설계에 가까워.
정확한 정의
검색 증강 생성은 보통 세 단계로 나뉘어. 먼저 사용자 질문을 검색 질의로 바꾸고, 외부 문서 저장소에서 관련 조각을 가져와. 그다음 가져온 조각을 모델의 입력에 붙이고, 모델은 그 자료를 참고해 답을 생성해.
이 구조의 핵심은 지식의 위치를 나누는 데 있어. 모델 가중치 안에는 언어 능력과 일반 패턴이 있고, 자주 바뀌거나 권한이 필요한 사실은 외부 저장소에 둔다. 그러면 새 문서를 다시 학습시키지 않아도 답변에 반영할 수 있고, 어떤 자료를 근거로 삼았는지도 추적하기 쉬워져.
flowchart LR A[사용자 질문] --> B[검색 질의 만들기] B --> C[문서·벡터 저장소] C --> D[관련 문서 조각] D --> E[모델 입력에 붙이기] E --> F[답 생성]
그림에서 중요한 건 중간의 저장소야. RAG는 모델 하나의 기능이 아니라, 검색 시스템과 저장 계층, 권한 관리, 답변 생성이 붙은 파이프라인이야.
왜 중요한가
RAG는 AI 서비스의 비용과 정확도를 함께 바꿔. 모델을 매번 다시 학습하지 않고도 최신 문서와 사내 지식을 답변에 넣을 수 있고, 답의 근거가 된 문서를 남길 수 있어. 그래서 고객지원, 개발 문서 검색, 사내 지식 질의처럼 계속 바뀌는 자료를 다루는 서비스에서 자주 등장해.
하지만 공짜는 아니야. 검색 인덱스를 만들고, 문서를 잘게 나누고, 접근 권한을 확인하고, 관련 없는 조각을 걸러야 해. 컨텍스트 엔지니어링 관점에서는 “무엇을 모델에게 보여 줄 것인가”의 문제이고, 추론 비용 관점에서는 검색·저장·네트워크·응답 시간이 추가되는 문제야.
저장장치 관점에서도 의미가 있어. 낸드플래시 문서에서 봤듯이, 추론 서비스가 외부 문서와 벡터 데이터를 계속 저장하고 꺼내면 GPU와 HBM 바깥의 저장 계층도 같이 중요해져. 연합뉴스 보도는 AI 추론 수요가 낸드 가격과 기업용 SSD 수요를 자극할 수 있다는 가설을 제기했지만, 실제 수요 크기는 아직 더 확인해야 해.1
실제 예시
AI 추론이 낸드를 다시 책장으로 불렀다는 RAG를 AI 저장장치 수요와 연결해 읽었어. 모델이 논문, 공식 문서, 회사 내부 지식을 찾아 붙이는 방식이 늘면, 계산 장치뿐 아니라 자료를 많이 보관하고 빠르게 꺼내는 장치도 비용 구조 안으로 들어온다는 얘기야.
다만 이 글만으로 “RAG가 낸드 수요를 구조적으로 밀어 올린다”고 결론 내리면 안 돼. 필요한 증거는 기업용 SSD 출하량, 고객별 장기 계약, 벡터 데이터베이스 운영 규모, HDD에서 SSD로 넘어가는 속도야. RAG는 그런 질문을 던지게 하는 구조이지, 그 자체로 특정 메모리 업황의 결론은 아니야.
헷갈리지 말아야 할 점
- RAG는 모델 학습이 아니야. 외부 자료를 답변 시점에 찾아 붙이는 방식이지, 그 자료를 모델 가중치에 새로 학습시키는 것과는 달라.
- 검색 결과가 곧 진실은 아니야. 잘못된 문서, 오래된 문서, 권한 밖 문서가 들어오면 답도 흔들릴 수 있어.
- 긴 컨텍스트와도 같은 말이 아니야. 컨텍스트 창이 길어도 어떤 자료를 고를지는 여전히 따로 설계해야 해.
- 환각을 자동으로 없애지는 않아. 근거 자료를 붙이면 도움이 될 수 있지만, 모델이 자료를 잘못 읽거나 없는 연결을 만들 수 있어.
- 저장장치 수요의 결론도 아니야. RAG가 늘면 저장·검색 요구가 커질 수 있지만, 실제 수요는 데이터 규모, 캐시 전략, 압축, 하드웨어 가격에 따라 달라져.
관련 문서
남은 질문들
- RAG가 정확도와 환각률을 실제 서비스에서 얼마나 개선하는지는 어떤 평가로 봐야 할까?
- 문서를 잘게 나누는 방식과 검색 순위 매기기는 답변 품질과 비용을 어디서 갈라 놓을까?
- 권한이 다른 사내 문서가 섞일 때, 검색 결과와 모델 입력은 어떻게 분리해야 할까?
- RAG·벡터 데이터베이스가 커질수록 저장장치 병목은 용량, 지연시간, 내구성 중 어디서 먼저 나타날까?
댓글