Agentic RAG는 지금 검색 수요가 뚜렷하지만, 단어만 외우면 실제 판단 기준이 남지 않는 주제입니다. 이 글에서는 Agentic RAG와 기존 RAG의 구조 차이 이해를 목표로 핵심 개념과 실무 판단 기준을 차근차근 정리합니다.
대상 독자는 기본 RAG는 이해했지만 agentic retrieval 구조가 왜 필요한지 알고 싶은 개발자입니다. 처음부터 세부 구현이나 상품명만 따라가기보다, 왜 이 주제가 필요한지와 어디서 실수하는지를 먼저 잡겠습니다.
기존 RAG는 검색 절차가 고정되어 있다
기존 RAG는 대체로 질문을 embedding으로 바꾸고, Vector DB에서 top-k 문서를 가져온 뒤, 그 문서를 context로 넣어 답변을 생성합니다. 이 방식은 단순하고 빠르지만 검색이 한 번 실패하면 뒤에서 회복하기 어렵습니다.
예를 들어 질문이 너무 짧거나, 사용자가 회사 내부 용어를 섞어 말하거나, 문서 제목과 본문 용어가 다르면 top-k 안에 정답 근거가 들어오지 않을 수 있습니다. 이때 기존 RAG는 검색 결과가 약하다는 사실을 스스로 잘 알아차리지 못합니다.
- 질문을 한 번만 검색어로 바꾼다
- 검색 결과가 약해도 그대로 답변 생성 단계로 넘어간다
- 검색 실패 원인이 query인지 chunk인지 평가하기 어렵다
- 답변 품질 개선이 embedding 모델 교체로만 쏠리기 쉽다
Agentic RAG는 검색 전후의 판단을 절차로 만든다
Agentic RAG는 RAG에 에이전트라는 이름을 붙인 마케팅 용어로 끝나면 안 됩니다. 핵심은 검색 과정 중간에 판단 단계를 넣는 것입니다. 질문을 다시 쓰고, 검색된 문서가 충분한지 평가하고, 부족하면 다른 검색을 시도하는 흐름이 생깁니다.
즉, LLM이 무작정 자유롭게 돌아다니는 구조가 아니라, 검색과 평가의 상태를 남기며 다음 행동을 고르는 구조에 가깝습니다. LangGraph 같은 상태 그래프 도구가 자주 언급되는 이유도 여기에 있습니다.
- query rewrite: 질문을 검색에 맞는 형태로 다시 쓴다
- retrieval: 여러 후보 문서를 가져온다
- document grading: 문서가 질문에 답할 근거인지 평가한다
- retry or generate: 부족하면 다시 검색하고 충분하면 답변한다
간단한 흐름으로 보면 이렇게 다르다
차이는 코드보다 흐름을 먼저 보면 이해하기 쉽습니다. 기존 RAG는 직선형 파이프라인이고, Agentic RAG는 중간 판단에 따라 경로가 갈라지는 그래프입니다.
중요한 것은 모든 질문에 복잡한 agent loop를 붙이는 것이 아닙니다. 검색 실패가 자주 발생하는 질문군에만 판단 단계를 넣어도 충분히 가치가 생깁니다.
Traditional RAG
question -> vector search -> context -> answer
Agentic RAG
question -> rewrite query -> search -> grade documents
-> enough? yes -> answer
-> enough? no -> rewrite/search againAgentic RAG가 필요한 신호
Agentic RAG는 멋있어 보여서 도입하는 구조가 아닙니다. 검색 실패가 실제 제품 품질을 흔들 때 검토해야 합니다. 특히 내부 문서, 운영 매뉴얼, 장애 기록, 고객 지원 문서처럼 표현이 제각각인 데이터에서 효과를 기대할 수 있습니다.
반대로 문서가 작고 질문 패턴이 단순하다면 기존 RAG에 reranker나 metadata filter를 붙이는 편이 더 단순할 수 있습니다.
- 질문 표현이 다양해서 같은 의미의 검색어가 자주 달라진다
- 검색 결과 안에 관련 없는 문서가 자주 섞인다
- 답변이 틀렸을 때 검색 실패인지 생성 실패인지 구분하고 싶다
- 검색 과정을 로그로 남겨 평가하고 개선해야 한다
실무에서는 평가 기준부터 잡아야 한다
Agentic RAG를 붙이면 구조가 복잡해집니다. 그래서 도입 전후를 비교할 평가 기준이 필요합니다. 정답 근거가 context 안에 들어왔는지, 답변이 근거를 벗어나지 않았는지, 재검색이 실제로 품질을 올렸는지를 따로 봐야 합니다.
자동 판단 단계가 많아질수록 로그가 더 중요합니다. 어떤 query로 검색했는지, 어떤 문서를 버렸는지, 왜 재검색했는지를 남기지 않으면 운영 중 품질 저하를 추적하기 어렵습니다.
- 대표 질문 30~100개를 먼저 모은다
- 기존 RAG의 검색 결과와 답변을 저장한다
- Agentic RAG에서 rewrite, grading, retry 로그를 남긴다
- context recall과 groundedness를 비교한다
- 비용과 지연시간 증가분을 함께 본다
조금 더 깊게 보면
초안 단계에서 핵심 개념만 잡으면 글이 얕게 끝날 수 있습니다. 그래서 여기서는 실제 적용할 때 확인해야 할 기준과 자주 생기는 오해를 한 단계 더 내려가 보겠습니다.
검색 실패와 생성 실패를 분리해서 봐야 한다
RAG 품질이 나쁠 때 바로 모델을 바꾸거나 prompt를 길게 만드는 경우가 많습니다. 하지만 실제 원인은 검색 단계일 수 있습니다. 정답 근거가 context에 없으면 모델이 아무리 좋아도 안정적인 답을 만들기 어렵습니다.
Agentic RAG를 설계할 때 첫 번째 목표는 검색 실패와 생성 실패를 분리하는 것입니다. 어떤 질문에서 어떤 query가 만들어졌고, 어떤 문서가 선택됐고, 그 문서가 왜 충분하다고 판단됐는지를 남겨야 합니다.
이 로그가 있어야 query rewrite가 필요한지, chunking이 문제인지, reranker가 필요한지, document grading 기준이 너무 느슨한지 알 수 있습니다.
- 정답 근거가 top-k 안에 없으면 검색 실패
- 근거는 있는데 답변이 엉뚱하면 생성 또는 prompt 실패
- 근거가 너무 길어 핵심이 밀리면 context packing 실패
- 근거 평가가 자주 틀리면 grading prompt나 평가셋 문제
Agentic RAG의 최소 상태 설계
처음부터 복잡한 멀티 에이전트 구조를 만들 필요는 없습니다. 최소 상태만 잡아도 운영 품질이 달라집니다. 질문 원문, rewrite된 query, 검색 후보, 채택한 문서, 버린 이유, 최종 답변을 한 번의 실행 기록으로 남기면 됩니다.
상태가 남으면 재현이 가능합니다. 사용자가 틀린 답변을 신고했을 때 같은 질문을 다시 돌려보며 검색 단계가 어디서 흔들렸는지 볼 수 있습니다.
AgenticRagState
- original_question
- rewritten_queries[]
- retrieved_documents[]
- graded_documents[]
- selected_context
- retry_count
- final_answer
- failure_reason재검색 루프에는 종료 조건이 필요하다
Agentic RAG에서 가장 위험한 부분은 모델에게 계속 판단을 맡기는 것입니다. 문서가 부족하면 다시 검색한다는 흐름은 좋아 보이지만, 종료 조건이 없으면 비용과 지연시간이 쉽게 커집니다.
실무에서는 최대 재검색 횟수, 최소 관련성 점수, 특정 도메인 검색 금지, 사람이 확인해야 하는 실패 상태를 미리 정해야 합니다. 실패를 답변 생성으로 덮지 않는 것이 오히려 품질을 높입니다.
- 첫 검색 결과를 평가한다
- 관련 문서가 없으면 query를 한 번만 다시 쓴다
- 두 번째 검색도 실패하면 답변 생성 대신 근거 부족으로 종료한다
- 중요 업무라면 human review queue로 넘긴다
기존 RAG에서 바로 넘어가지 말아야 할 경우
Agentic RAG는 비용이 늘고 구조가 복잡해집니다. 그래서 기존 RAG의 기본기가 부족한 상태에서 바로 넘어가면 문제 원인을 더 찾기 어려워질 수 있습니다.
chunk size가 너무 작거나, 문서 metadata가 없거나, 평가셋이 없거나, 검색 로그가 남지 않는다면 agentic loop보다 기본 검색 파이프라인을 먼저 정리하는 편이 안전합니다.
- 문서가 자주 바뀌는데 index 갱신 정책이 없다
- 질문과 정답 근거를 묶은 평가셋이 없다
- 검색 결과를 저장하지 않아 실패 재현이 안 된다
- 문서 권한 필터가 검색 전에 적용되지 않는다
실전 적용 시나리오
이 주제를 실제 작업에 적용한다면 먼저 작은 범위에서 시작하는 편이 좋습니다. Agentic RAG를 알고 있다는 것과, 프로젝트나 학습 문제 안에서 올바른 판단을 내리는 것은 다른 문제입니다.
기본 RAG는 이해했지만 agentic retrieval 구조가 왜 필요한지 알고 싶은 개발자라면 처음부터 모든 세부 선택지를 외우기보다, 현재 상황에서 무엇을 확인해야 하는지 체크리스트로 좁혀야 합니다. 그래야 글을 읽고 바로 다음 행동으로 옮길 수 있습니다.
- 먼저 Agentic RAG가 필요한 상황인지 문제를 한 문장으로 적는다
- 현재 방식이 실패하는 지점을 로그, 예제, 표, 작은 입력 중 하나로 확인한다
- RAG, LangGraph RAG, query rewrite 중 이번 문제와 직접 관련 있는 기준만 고른다
- 작은 예제로 먼저 검증하고, 그 다음 실제 프로젝트나 긴 입력으로 확장한다
- 결과가 좋아졌는지 주관적 느낌이 아니라 비교 가능한 기준으로 확인한다
이 순서를 따르면 글에서 배운 개념이 단순한 용어 정리로 끝나지 않습니다. 특히 개발 글은 예제 코드가 돌아가는지만 보지 말고, 왜 그 구조를 골랐는지 설명할 수 있어야 합니다. ETF 글도 마찬가지로 분배율이나 수익률 숫자 하나가 아니라 역할과 위험을 함께 설명할 수 있어야 합니다.
검토 체크리스트
마지막으로 실제 적용 전에 아래 항목을 확인하면 실수를 줄일 수 있습니다. 체크리스트는 정답을 대신하지 않지만, 빠뜨리기 쉬운 질문을 다시 꺼내는 데 도움이 됩니다.
- 이 주제를 써야 하는 문제가 정말 맞는가
- 비슷한 대안과 비교했을 때 장점과 비용을 함께 설명할 수 있는가
- 공식 문서나 신뢰할 수 있는 자료로 핵심 전제를 확인했는가
- 작은 예제나 제한된 데이터에서 먼저 검증했는가
- 실패했을 때 되돌릴 수 있는 기준과 로그를 남겼는가
- 초보자가 오해하기 쉬운 지점을 본문에서 따로 짚었는가
정리하면 Agentic RAG 글의 목적은 용어를 하나 더 외우게 하는 것이 아니라, 독자가 다음 선택을 덜 흔들리게 만드는 것입니다. 그래서 본문에서는 개념, 예시, 실수, 체크리스트를 함께 묶어 읽는 편이 좋습니다.
정리
Agentic RAG는 기존 RAG를 버리는 방식이 아니라, 검색 실패를 판단하고 회복하는 단계를 추가하는 방식입니다. 검색 품질 문제가 반복될 때만 필요한 만큼 도입하는 편이 운영하기 쉽습니다.
관련해서 내부 글은 한국어 RAG에서 chunk size는 왜 더 까다로울까, pgvector는 언제 Pinecone이나 Qdrant 대신 쓸 만할까, LangGraph, CrewAI, AutoGen은 무엇이 다를까와 함께 보면 좋습니다.
외부 기준은 LangGraph Docs – Agentic RAG, LangGraph Product, OpenAI Docs – File Search를 기준으로 확인했습니다.
