바닐라 RAG를 넘어: 모든 AI 엔지니어가 알아야 할 7가지 현대 RAG 아키텍처
Source: Dev.to
TL;DR
RAG은 죽은 것이 아니라 진화하고 있습니다. 최신 AI 시스템은 기본 “벡터 검색 + LLM” 파이프라인의 한계를 극복하기 위해 더 똑똑하고 특화된 검색 아키텍처를 사용합니다. 알아야 할 일곱 가지 핵심 유형은 Vanilla RAG, Self‑RAG, Corrective RAG, Graph RAG, Hybrid RAG, Agentic RAG, 그리고 Multi‑Agent RAG입니다. 각각은 환각 제어, 개인화, 다단계 추론 등 전통적인 검색의 다른 약점을 해결합니다. Adaptive RAG, Multi‑Hop RAG, Real‑Time RAG와 같은 새로운 변형도 등장하고 있습니다. RAG의 미래는 옛것을 대체하는 것이 아니라, 해결하려는 문제에 맞는 아키텍처를 선택하는 것입니다.
AI 트위터(또는 이번 주에 부르는 이름) 주변을 맴돌았다면 시즌의 뜨거운 의견을 보았을 겁니다:
“RAG은 죽었다.”
아, 2012년에 “JavaScript는 죽었다”, 2018년에 “Python은 죽었다”, 그리고 거의 매주 “Google은 죽었다”고 선언한 같은 인터넷이군요.
스포일러: RAG은 여전히 살아 있습니다.
죽은 것이 아니라 지금은 성장 단계에 있습니다. Retrieval‑Augmented Generation은 진화했고, 새로운 능력을 쌓으며, 개성을 얻고, 어쩌면 팀까지 구성했습니다.
Vanilla RAG를 연필 하나만 들고 등교하는 아이로, Multi‑Agent RAG를 스쿼드, 노트북, 색깔별 플래너, 예비 연필 세 개, 그리고 5년 경력 전략을 가지고 등교하는 아이로 생각해 보세요.
의료 요약부터 기업 검색까지 산업 전반에 걸쳐 RAG은 실용적인 AI 시스템의 핵심 역할을 계속하고 있습니다. 유일한 문제는? 인터넷이 우리의 명명 능력보다 더 빨리 움직였다는 점입니다. 이제 Self‑RAG, Corrective RAG, Graph‑RAG, Hybrid RAG, Agentic RAG, Multi‑Agent RAG… 기본적으로 “RAG” 앞에 접두어만 붙이면 누군가 논문을 썼을 가능성이 높습니다.
“RAG”이 실제로 무엇을 의미하는지—그 기원, 메커니즘, 사용 사례—에 대해 더 깊이 파고들고 싶다면, 저는 이 주제에 대해 전체 블로그 글을 작성했습니다. 여기서 확인해 보세요.
따라서 이 블로그에서는 혼란을 단순화합니다. 모든 AI 엔지니어가 알아야 할 최신 RAG 아키텍처를 쉬운 영어(박사 학위는 필요 없음, 불필요한 이론 덤프도 없음)로 설명합니다.
각 항목에서 배우게 될 내용:
- 무엇인지
- 왜 존재하는지 (해결하려는 문제)
- 장점
- 제한점
- 실제 적용 사례
각 섹션에는 깔끔한 아키텍처 시각화가 함께 제공될 것이며(그 부분은 여러분이 담당!), 설명은 간결하고 초보자 친화적으로 유지됩니다.
마지막까지 읽으면 RAG이 왜 죽지 않았는지 알게 될 뿐 아니라, 왜 이렇게 빠르게 진화하고 있는지도 이해하게 될 것입니다.
1. Vanilla RAG: The “OG” Retrieval‑Augmented Generation
AI가 에이전트, 플래닝, 자기 반성, 그리고 기타 철학적 취미에 집착하기 전, Vanilla RAG가 있었습니다. 가장 단순하고 실용적인 형태의 Retrieval‑Augmented Generation입니다. 모두가 시작하는 직관적인 “검색‑후‑생성” 파이프라인이죠.
Google Search + ChatGPT 조합이라고 생각하면 되지만, 기본적인 일 외에 아무 야망도 없습니다.
What It Is
Vanilla RAG는 한 가지 일을 확실히 수행합니다:
관련 정보를 가져와서 모델이 그 정보를 사용해 질문에 답하도록 합니다.
쿼리 최적화도 없고, 에이전트 간 논쟁도 없으며, 복잡한 루프도 없습니다. 단순히 “질문을 받았다. 검색했다. 여기 답이 있다.”입니다.
RAG 아키텍처가 직원이라면, Vanilla RAG는 지시를 그대로 따르고 절대 즉흥적으로 행동하지 않는 인턴입니다.
Why It Exists
대형 언어 모델은 환각을 많이 합니다. Vanilla RAG는 이를 해결하기 위한 최초의 실용적인 방안으로 도입되었습니다. 모델의 응답을 검색된 문서에 기반하도록 함으로써, 상상에 의존하는 대신 실제 데이터에 의존하게 합니다.
초기 산업 질문에 답을 주었습니다:
“모델이 자신 있게 허구를 만들어내는 것을 어떻게 멈출까?”
How It Works
- 사용자가 질문을 합니다.
- 시스템이 질문을 임베딩으로 변환합니다.
- 벡터 데이터베이스가 가장 가까운 청크들을 찾습니다.
- 해당 청크들이 LLM에 전달됩니다.
- LLM은 검색된 컨텍스트만을 기반으로 답변을 작성합니다.
빠르고, 예측 가능하며, 이해하기 쉽습니다.
Advantages
- 매우 빠르고 지연 시간이 짧음.
- 복잡한 시스템에 비해 비용이 저렴함.
- 구현이 매우 쉬움.
- 단순한 사실 질의에 잘 작동함.
Limitations
- 길거나 다중 파트 질문에 취약함.
- 특히 크거나 지저분한 데이터셋에서는 검색이 빗나갈 수 있음.
- 결과를 비판하거나 반성, 정제할 능력이 없음.
- LLM의 컨텍스트 윈도우 크기에 제한받음.
- 사용자별 혹은 질의 스타일별 맞춤화가 불가능함.
Vanilla RAG는 사용 사례가 단순할 때는 훌륭합니다. 복잡성이 들어오면 더 적응력 있고 지능적인 무언가가 필요하다는 것을 금방 깨닫게 됩니다.
2. Self‑RAG: The RAG That Actually Thinks About Its Own Mistakes
Vanilla RAG가 일을 단순히 수행하는 인턴이라면, Self‑RAG는 갑자기 자각을 얻고 “잠깐… 내가 제대로 했나?”라고 말하는 인턴입니다.
Self‑RAG는 한 가지 핵심 능력을 도입합니다:
모델이 자신의 검색 품질과 답변을 스스로 평가합니다.
검색된 문서가 관련 있는지, 추론이 타당한지, 다른 검색 단계가 필요한지를 검사하는 내장 비평가를 파이프라인에 부여한 셈입니다.
What It Is
LLM이 수동적이 아닌 RAG 파이프라인. 스스로 반성하고, 비평하며, 검색을 동적으로 조정합니다. LLM은 스스로에게 물을 수 있습니다:
- “올바른 문서를 검색했는가?”
- “다시 검색해야 할까?”
- “이 청크는 신뢰할 만한가?”
- “내 답변이 증거와 실제로 일치하는가?”
이렇게 정적인 파이프라인을 피드백 루프로 전환합니다.
Why It Exists
검색은 난잡합니다. 상위 k 청크가 쓰레기이거나 무관할 때가 있습니다. 모델이 문서에 전혀 없는 내용을 자신 있게 답할 때도 있죠. Self‑RAG는 바로 그 문제를 해결하기 위해 만들어졌습니다.
대규모 혹은 비구조화된 데이터셋에서도 RAG 파이프라인을 더 신뢰할 수 있게 합니다. 무작정 검색 결과를 믿는 대신 모델이 수행하게 됩니다:
- 검색 평가
- 답변 검증
- 환각 탐지
- 자체 교정
즉, 양심을 가진 RAG입니다.
How It Works
아키텍처는 Vanilla RAG와 유사하지만 루프가 추가됩니다:
- 문서를 검색합니다.
- LLM이 검색된 청크의 관련성 및 신뢰성을 평가합니다.
- 평가가 실패하면 시스템이 두 번째 검색(또는 재순위 매김)을 트리거합니다.
- LLM이 답변을 생성한 뒤, 그 답변을 증거와 대조합니다.
- 불일치가 발견되면, 만족스러운 답변이 나올 때까지 혹은 최대 반복 횟수에 도달할 때까지 루프를 반복합니다.
이 반복 과정은 환각을 줄이고 답변 정확성을 높이지만, 지연 시간과 계산 비용이 증가한다는 대가를 치러야 합니다.