AI 에이전트 RAG를 설계할 때 가장 먼저 헷갈리는 질문은 “RAG가 도구인가, 메모리인가, 그냥 프롬프트 앞에 붙는 검색 기능인가”입니다. 답은 하나로 고정하기보다, 에이전트 실행 흐름 안에서 어떤 책임을 맡기는지로 봐야 합니다.
이 글에서는 RAG를 에이전트의 context layer, 즉 필요한 근거를 찾아 모델 입력으로 정리하는 계층으로 보겠습니다. 앞선 3편에서 MCP가 외부 기능 연결 경계였다면, 이번 편의 RAG는 그 기능과 지식을 답변 맥락으로 바꾸는 계층입니다.
OpenAI의 Retrieval 문서는 semantic similarity로 데이터를 검색하는 방법을 설명하고, LangChain의 Retrieval 문서는 query analysis, source selection, routing 같은 검색 워크플로를 다룹니다. 이 글은 특정 프레임워크 사용법보다 설계 위치에 집중합니다.
AI 에이전트 RAG는 답변 기능 하나가 아니다
일반적인 RAG 설명은 “문서를 검색해서 LLM에 넣고 답하게 한다”로 끝나는 경우가 많습니다. 하지만 에이전트에서는 이 설명만으로 부족합니다. 에이전트는 한 번 답하고 끝나는 챗봇보다 작업 목표, 도구 호출, 상태 확인, 실패 복구를 함께 다룹니다.
그래서 RAG는 단순 검색 함수가 아니라 실행 중간에 필요한 지식을 공급하는 layer로 보는 편이 안전합니다. 에이전트가 검색이 필요한지 판단하고, 어떤 소스에서 찾을지 고르고, 찾은 근거를 어떤 순서로 넣을지 정해야 합니다.
RAG를 tool로 볼 때와 context layer로 볼 때
RAG를 tool로만 보면 에이전트가 search_documents 같은 도구를 호출하고 결과를 받는 구조가 됩니다. 이 방식은 단순하고 명확하지만, 검색 결과 품질과 context packing 책임이 모델에게 과하게 넘어갈 수 있습니다.
반대로 RAG를 context layer로 보면 검색은 도구 호출 하나가 아니라 실행 전후의 파이프라인이 됩니다. 검색 후보를 만들고, reranking으로 정렬하고, 중복과 오래된 정보를 제거하고, 모델 입력에 들어갈 근거를 구성합니다.
- tool 관점: 에이전트가 필요할 때 검색 기능을 호출한다.
- memory 관점: 자주 쓰는 지식이나 사용자 맥락을 다시 꺼낸다.
- context layer 관점: 검색된 정보를 답변 가능한 형태로 정리한다.
- evaluation 관점: 답변이 실제 근거에 기대고 있는지 확인한다.
retrieval은 후보를 찾는 단계다
retrieval은 정답을 고르는 단계가 아니라 후보를 찾는 단계입니다. OpenAI embedding 문서는 embedding을 텍스트를 벡터로 바꾸어 search, clustering 등에 활용할 수 있다고 설명합니다. 오늘 발행한 Embedding 글에서도 이 흐름을 먼저 정리했습니다.
검색 결과가 5개 나왔다고 해서 그 5개가 모두 답변에 들어가야 하는 것은 아닙니다. 검색은 넓게 후보를 잡는 단계이고, 이후 단계에서 질문과 작업 목표에 맞게 다시 걸러야 합니다.
user_goal
-> query rewrite
-> retrieve candidate chunks
-> rerank evidence
-> pack context
-> answer with citationsreranking은 근거의 우선순위를 다시 잡는 단계다
embedding 검색은 의미적으로 가까운 문서를 잘 찾지만, 그것이 항상 최종 답변에 가장 좋은 근거라는 뜻은 아닙니다. 문서가 오래되었거나, 질문의 조건과 맞지 않거나, 같은 내용을 반복하는 경우도 있습니다.
그래서 RAG가 에이전트 안에 들어가면 reranking이 중요해집니다. 이전에 발행한 RAG reranking 글에서 다뤘듯이, 검색 결과를 그대로 넣으면 모델은 엉뚱한 근거를 더 강하게 믿을 수 있습니다.
- 질문과 직접 맞는 문서를 우선한다.
- 최신성이 중요한 작업은 날짜와 버전을 본다.
- 같은 내용을 반복하는 chunk는 줄인다.
- 권한이 없는 문서나 개인정보는 context에서 제외한다.
context packing은 모델 입력을 설계하는 단계다
context packing은 검색된 문서를 그냥 이어 붙이는 일이 아닙니다. 어떤 순서로 넣을지, 몇 개까지 넣을지, 서로 충돌하는 근거를 어떻게 표시할지, 모델이 답변에서 어떤 근거를 참조하게 할지를 정하는 단계입니다.
arXiv의 Context Engineering survey는 LLM 성능이 inference 중 제공되는 contextual information에 크게 좌우되며, context retrieval, processing, management가 중요한 구성요소라고 설명합니다. 이 관점에서 보면 RAG는 retrieval 하나가 아니라 context engineering의 일부입니다.
context:
task: "장애 원인 후보를 정리한다"
evidence:
- log excerpt, timestamp, source
- deploy history, service, version
- runbook paragraph, owner
instruction:
- 근거 없는 추정은 후보로만 표시
- 로그와 배포 이력을 구분잘못 설계하면 생기는 문제
첫 번째 문제는 검색 남발입니다. 에이전트가 조금만 모르면 계속 검색 도구를 호출하고, 같은 문서를 반복해서 읽습니다. 비용과 지연 시간이 늘고, 사용자는 답변이 늦다고 느낍니다.
두 번째 문제는 근거 없는 확신입니다. 검색 결과에 답이 없는데도 모델이 그럴듯한 답을 만들면 RAG를 붙인 의미가 줄어듭니다. 이때는 “검색 결과에 근거가 없으면 모른다고 말한다”는 정책이 필요합니다.
세 번째 문제는 권한 경계입니다. 에이전트가 사용할 수 있는 문서와 사용자가 볼 수 있는 문서가 다르면 사고가 납니다. RAG layer는 단순 기술 계층이 아니라 권한, 감사 로그, 개인정보 보호까지 연결된 운영 계층입니다.
Agentic RAG 설계 체크리스트
- 이 작업에서 검색이 항상 필요한가, 조건부로 필요한가를 정한다.
- 검색 대상 source를 문서, 로그, DB, 메모리 중 어디까지 열지 정한다.
- retrieval 결과를 그대로 넣을지 reranking을 거칠지 정한다.
- context packing에서 날짜, 출처, 권한, 충돌 정보를 함께 넣는다.
- 검색 결과가 부족할 때 답변 정책을 정한다.
- RAG 호출 비용과 latency를 추적한다.
- 답변이 어떤 근거를 사용했는지 로그로 남긴다.
이 체크리스트를 적용하면 RAG를 “검색 붙이기”가 아니라 에이전트의 맥락 공급 정책으로 설계할 수 있습니다.
정리
AI 에이전트 RAG는 단순 검색 기능이 아니라 context layer로 보는 편이 좋습니다. retrieval은 후보를 찾고, reranking은 근거 우선순위를 잡고, context packing은 모델 입력을 설계하며, grounding은 답변이 근거에 기대는지 확인합니다.
다음 편에서는 이 흐름에서 더 오래 남는 맥락, 즉 Memory를 다룹니다. Memory는 저장소 하나를 붙이는 문제가 아니라 무엇을 기억하고 언제 잊을지 정하는 정책에 가깝습니다.
