본문
완벽한 AI 에이전트를 위한 6가지 RAG 고도화 기법 총정리 (ReAct, Self-RAG, CRAG)
LLM 기반의 AI 애플리케이션을 직접 개발하다 보면 한 번쯤 마주치는 거대한 벽이 있습니다. 바로 "어떻게 하면 AI가 헛소리(할루시네이션)를 안 하고, 스스로 생각해서 정확하게 행동하게 만들까?" 라는 질문입니다. 특히 단순한 사내 Q&A 봇 수준을 넘어, 실제 서비스에 투입할 수 있을 만큼 안정적이고 똑똑한 AI 에이전트를 구축하려고 할 때 이 고민은 훨씬 더 깊어집니다.
저 역시 AI 어시스턴트와 에이전트 아키텍처를 설계하고 구현하면서 쏟아지는 새로운 논문과 아키텍처들 앞에서 멈칫했던 적이 있습니다. ReAct, Adaptive RAG, Self-RAG... 다들 각자의 자리에서 훌륭한 기술인 건 알겠는데, 막상 "그래서 내 서비스 환경에는 정확히 뭘 적용해야 최적일까?"라고 스스로에게 물으면 머릿속이 꽤 복잡해지더라고요.
이 글에서는 저와 같은 고민을 하며 여러 논문과 기술 문서 사이를 헤매고 계실 분들을 위해, 최근 가장 주목받는 에이전트(Agent) 및 RAG 고도화 기법 6가지의 핵심 개념과 실제 활용법을 알기 쉽게 정리해 보았습니다.
1. 생각하고 행동하는 AI: 추론-행동 기반 ReAct 에이전트 이해하기
과거의 AI는 질문을 받으면 가진 지식 내에서 곧바로 대답만 하는 수동적인 존재였습니다. 하지만 ReAct(Reasoning + Acting) 에이전트는 다릅니다. 이들은 마치 사람처럼 ‘생각(추론)’하고 그에 맞춰 ‘행동’합니다.
예를 들어, "요즘 제일 잘나가는 애플워치 모델의 가격이 얼마야?"라고 물어본다면 ReAct 에이전트는 다음과 같이 작동합니다.
- 생각(Reasoning): '최신 애플워치 모델이 뭔지 먼저 알아봐야겠군. 그다음 그 모델의 가격을 검색해야겠다.'
- 행동(Acting): 인터넷 검색 도구를 사용해 최신 모델을 찾습니다.
- 결과 도출: 검색 결과를 바탕으로 최종 답변을 정리하여 사용자에게 알려줍니다.
단순히 텍스트를 생성하는 것을 넘어, 도구를 사용하고 스스로 계획을 세워 문제를 해결하는 똑똑한 비서가 바로 ReAct 에이전트입니다.
2. 질문의 난이도를 스스로 파악한다! Adaptive RAG 에이전트
Adaptive RAG는 말 그대로 '상황에 맞게 적응하는' RAG 시스템입니다. 병원 응급실의 환자 분류소(Triage)를 생각하면 이해하기 쉽습니다. 가벼운 찰과상 환자와 중증 환자를 다르게 처치하듯, 들어오는 질문의 복잡도에 따라 처리 방식을 다르게 가져가는 것입니다.
- 단순한 질문: "우리 회사 주소가 뭐야?" 같은 질문은 복잡한 검색 없이 내부 문서만 가볍게 찾아서 바로 답변합니다. (속도와 비용 절감)
- 복잡한 질문: "올해 3분기 매출 하락 원인과 경쟁사 동향을 비교해 줘" 같은 질문은 여러 문서를 깊게 분석하거나 외부 웹 검색까지 동원하여 신중하게 답변을 생성합니다.
이처럼 질문의 난이도를 라우터(Router)가 스스로 평가하여 가장 효율적이고 정확한 답변 경로를 선택하는 것이 Adaptive RAG의 핵심입니다.
3. AI와 사람의 완벽한 티키타카: Human-in-the-loop (HITL)
AI가 아무리 똑똑해졌다고 해도, 법률, 의료, 혹은 회사의 중요한 의사결정을 AI에게 100% 맡기기엔 아직 불안한 것이 사실입니다. 이때 필요한 개념이 바로 Human-in-the-loop(HITL)입니다.
직역하면 '루프(작업 과정) 안에 사람이 있다'는 뜻으로, AI가 혼자 모든 것을 끝내는 것이 아니라 중간중간 사람의 피드백을 받거나 최종 승인을 거치는 방식을 말합니다.
- AI가 초안을 작성하면 사람이 검토하고 수정합니다.
- AI가 중요한 이메일을 발송하기 전, 사람이 "승인" 버튼을 눌러야만 발송되도록 설정합니다.
AI는 귀찮고 방대한 작업을 빠르게 처리하는 '유능한 인턴' 역할을 하고, 사람은 최종 퀄리티를 책임지는 '매니저' 역할을 하며 서로의 장점을 극대화하는 소통 방식입니다.
4. AI의 할루시네이션(환각)을 제어하는 방법: LLM 평가(Evaluation)의 중요성
우리가 직원을 채용할 때 면접과 수습 기간을 거치듯, AI 모델을 실제 서비스에 투입할 때도 반드시 '평가(Evaluation)'가 필요합니다. 특히 LLM은 그럴듯한 거짓말을 지어내는 '할루시네이션(환각)' 현상을 일으킬 수 있기 때문에 평가는 선택이 아닌 필수입니다.
안정적인 서비스를 위해 주로 다음과 같은 지표들을 평가합니다.
- 답변의 관련성 (Answer Relevance): 엉뚱한 대답을 하지 않고 질문의 의도를 정확히 파악했는가?
- 사실 기반 (Faithfulness): 주어진 문서 내용만을 바탕으로 답변을 만들었는가? (소설을 쓰지 않았는가?)
- 문맥 정확성 (Context Precision): 검색해 온 문서들이 정말 질문과 관련 있는 유용한 정보인가?
Ragas, TruLens, 그리고 LangSmith와 같은 전문 평가 도구를 활용해 지속적으로 AI의 성적표를 매기고 개선해야만 유저들이 신뢰할 수 있는 서비스를 만들 수 있습니다.
* p.s. 관련 글: 더 똑똑한 RAG 만들기: LangGraph와 LangSmith 도입기
5. 스스로 묻고 따블로 가! 꼼꼼한 AI, Self-RAG
Self-RAG는 한마디로 '자기 객관화가 잘 된 AI'입니다. 일반적인 RAG 시스템은 문서를 검색해서 답변을 만들면 끝이지만, Self-RAG는 자신이 만든 답변을 스스로 비판하고 검증(Critique)합니다.
마치 작가가 글을 쓰고 스스로 교열을 보는 것과 같습니다.
- 답변 생성: 먼저 답변을 만들어 봅니다.
- 자기 검증: "이 답변이 질문에 맞나?", "검색된 문서에 근거가 있나?" 스스로 질문표(Reflection tokens)를 던집니다.
- 수정 및 재검색: 만약 정보가 부족하거나 논리가 이상하면, 답변을 버리고 다시 문서를 검색해서 더 나은 답변을 재작성합니다.
답변을 내보내기 전에 여러 번 꼼꼼하게 자체 검열을 거치기 때문에 답변의 퀄리티가 비약적으로 상승합니다.
6. 틀린 정보는 웹 검색으로 바로잡는다: Corrective RAG (CRAG)
RAG 시스템의 가장 큰 약점은 "애초에 검색해 온 내부 문서가 부실하거나 틀렸을 때"입니다. 재료가 썩었는데 맛있는 요리가 나올 리 없죠. 이를 극복하기 위해 등장한 것이 Corrective RAG (CRAG)입니다.
CRAG는 검색된 문서의 질을 평가자(Evaluator)가 먼저 확인합니다.
- 문서가 정확할 때: 그대로 훌륭한 답변을 생성합니다.
- 문서가 틀렸거나 부족할 때 (Corrective): "우리 DB에는 최신 정보나 정확한 답이 없네?"라고 판단한 뒤, 내부 문서를 버리거나 수정하고 과감하게 외부 웹 검색(Web Search)을 실행하여 빈틈을 채웁니다.
즉, 내부 지식의 한계를 외부 지식으로 유연하게 '교정(Correct)'하여 언제나 가장 최신의, 가장 정확한 답변을 보장하는 강력한 기술입니다.
마치며
이렇게 하나씩 떼어놓고 정리하고 나니까 생각보다 각 기술의 역할과 도입 목적이 명확하게 보이더라고요.
- AI가 도구를 쓰며 능동적으로 문제를 해결하길 원한다면 ReAct
- 질문 난이도에 맞춰 효율적으로 리소스를 분배하려면 Adaptive RAG
- 답변의 신뢰도를 극한으로 끌어올리고 싶다면 Self-RAG와 CRAG
- 그리고 이 모든 과정이 제대로 굴러가는지 감시할 LLM Evaluation과, 최종 안전장치인 HITL까지
결국 이 바닥에 무조건적인 "정답"이나 단 하나의 만능 에이전트 아키텍처는 없는 것 같습니다. 내가 지금 풀고자 하는 비즈니스 문제가 무엇이고, 우리 서비스가 어느 정도의 정확도와 응답 속도를 타협할 수 있는지를 명확히 정의하는 것이 먼저입니다.
저처럼 수많은 RAG 패턴과 에이전트 기법들 사이에서 길을 잃고 헷갈리셨던 분들에게, 이 글이 조금이나마 아키텍처 설계의 나침반이 되었기를 바랍니다 :)
댓글