제5장: RAG와 멀티 에이전트에서의 고도화된 루프 설계

AI 에이전트의 적용 영역이 넓어짐에 따라, 단일 에이전트가 도구를 호출하는 단순한 루프만으로는 대응할 수 없는 복잡한 유스케이스가 증가하고 있습니다. 특히, 부정확한 검색 결과를 수정하면서 답변을 생성하는 RAG(검색 증강 생성, Retrieval-Augmented Generation)의 진화형 루프나, 여러 역할을 가진 AI끼리 협상·협력하는 **멀티 에이전트 루프(Multi-agent Loop)**는 현재 실용적인 AI 시스템 설계의 최전선입니다.

본 장에서는 Corrective RAG나 Self-RAG로 대표되는 「검색·평가·생성의 검증 루프」, 복수 에이전트 간의 「합의 형성(Consensus) 루프」, 보안이 확보된 「샌드박스 실행 루프」, 그리고 「태스크의 재귀적 분해와 병렬화」에 대해 구체적인 코드와 Mermaid 다이어그램을 곁들여 기술적으로 해설합니다.

기존의 단순한 RAG (Naive RAG)는 「사용자의 질문 ➔ 벡터 검색 ➔ 검색된 문서를 LLM에 입력하여 답변 생성」이라는 일직선 프로세스였습니다. 하지만 이 접근 방식에는 「검색 결과에 쓰레기(노이즈)가 포함되어 있으면 할루시네이션(Hallucination)을 일으킨다」, 「검색 결과에 필요한 정보가 부족할 경우 거짓말을 한다」라는 큰 약점이 있습니다.

이를 해결하는 것이 검색 문서의 품질 판정을 루프 내에 포함시킨 Corrective RAG (CRAG) 또는 Self-RAG 설계입니다.

평가 (Grading): 검색을 통해 얻은 각 문서가 사용자의 질문에 대해 정말로 「관련이 있는지(Relevant/Irrelevant)」를 LLM으로 이진 판정합니다. -
외부 보강 (Web Search / Fallback): 관련 문서가 없거나 스코어가 임계값 미만인 경우, 기존의 지식 베이스(벡터 DB)만으로는 답변이 불가능하다고 판단하여 Web 검색 API 등을 호출하거나, 쿼리를 리라이트(Rewrite)하여 재검색합니다. -
자기 검증 (Self-Reflection): 생성된 답변이 참조한 문서의 내용과 모순되지 않는지(Groundedness), 그리고 질문에 대한 직접적인 답변이 되는지(Answer Relevance)를 LLM 스스로 판정하게 하여, NG라면 검색·생성 루프를 다시 수행합니다.

이하는 검색 결과의 품질 판정과 쿼리 리라이트(재구성)를 포함한 RAG 재시도 루프의 구현 코드입니다.

from typing import List, Dict, Any, Literal
# =====================================================================
# 모크(Mock)용 데이터·API 정의
...

단일 LLM에 모든 역할(프로그래밍, 코드 리뷰, 테스트, 문서 작성)을 떠맡기면 컨텍스트가 극도로 복잡해져 출력 정밀도가 현저히 저하됩니다.

이를 해결하기 위해, 「특정 태스크에 특화된 복수의 에이전트를 자율적으로 대화시키는 (멀티 에이전트)」 설계 패턴이 유효합니다.

특히, 「제안자」와 「비평가」의 디스커션(대화·컨센서스) 루프를 구축함으로써 결과물의 퀄리티를 자율적으로 극한까지 높일 수 있습니다.

이하는 **「Writer (라이터)」**가 작성한 블로그 기사 초안을 **「Editor (편집자)」**가 리뷰하고, 편집자의 승인(GO 사인)이 나올 때까지 원고 수정을 반복하는 협조 루프의 시퀀스입니다.

이하는 두 에이전트의 클래스를 정의하고, 서로 메시지를 주고받으며 합의에 도달하는 대화 루프의 구현 예시입니다.

class WriterAgent:
def __init__(self):
self.draft_version = 0
...

AI 에이전트에게 「코드 실행 (Python REPL 등)」이나 「쉘 커맨드 실행」 도구를 부여하면, 에이전트는 스스로 프로그램을 작성하여 버그를 자기 수정하며 태스크를 처리할 수 있게 되어 문제 해결 능력이 극적으로 향상됩니다. 하지만 이는 동시에 **극도로 높은 보안 리스크 (악의적인 코드 실행, 무한 루프에 의한 호스트 리소스 고갈, 시스템 파일 변조·유출)**를 야기합니다.

따라서 에이전트가 코드를 실행하는 루프는 호스트 환경으로부터 완전히 격리된 「세큐어 샌드박스 (Secure Sandbox)」 내로 한정해야 합니다.

[ 에이전트 (호스트 환경) ]
│
▼ (코드 생성: "rm -rf /" 또는 무한 루프 코드 등)
...

일회성 환경 (Ephemeral Environment): 실행할 때마다 새롭게 컨테이너나 마이크로 VM (Firecracker 등)을 실행하고, 실행 완료 후 즉시 파기 (클린업)합니다.

네트워크 차단 (Network Isolation): 특별한 이유가 없는 한, 샌드박스 내의 인터넷 접속을 차단하여 에이전트가 코드 실행을 통해 외부로 데이터를 전송 (C2 서버로의 데이터 유출 등)하는 것을 방지합니다.

하드 리소스 제한 (Resource Constraints): CPU 사용률, 메모리 상한, 디스크 쓰기량을 cgroups 등으로 엄격하게 제한하여, AI가 생성한 무한 루프 코드로 인해 서버가 다운되는 것을 방지합니다.

자기 수정 재시도 루프의 융합: 샌드박스의 stderr (표준 에러 출력)와 exit_code를 에이전트에게 반환하고, "Python 에러가 발생했습니다. 수정하여 재실행해 주세요"라는 루프 (제2장에서 해설한 자기 수정)를 결합함으로써, 안전하고 자율적인 코딩 능력을 실현합니다.

샌드박스의 하나의 거대한 태스크를 선형적인 (일직선의) 루프로 처리하는 데에는 한계가 있습니다.

복잡한 개발 프로젝트나 대규모 조사 태스크를 처리할 경우, 에이전트는 태스크를 재귀적으로 분해 (Decomposition) 하여 여러 개의 자식 태스크를 만들고, 이를 병렬로 처리 (Map-Reduce) 한 뒤, 마지막에 결과를 결합 (Join)하는 트리형 루프 처리를 수행합니다.

[ 부모 태스크: 기술 보고서 작성 ]
│
┌──────────────────┼──────────────────┐
...

Decomposer (분해기): LLM이 큰 목표 (예: "3개 경쟁사의 웹사이트 요금제를 비교한다")를 받아, 이를 독립적으로 실행 가능한 자식 태스크 ("A사의 요금 조사", "B사의 요금 조사", "C사의 요금 조사") 리스트로 분해합니다.

Parallel Dispatcher (병렬 디스패처): 분해된 자식 태스크 배열에 대해 비동기 처리 (Python의 asyncio.gather나 LangGraph의 Send 객체)를 이용하여, 각각의 에이전트 인스턴스를 동시에 기동합니다.

Reducer / Synthesizer (집약기): 모든 병렬 처리 노드의 완료를 기다린 후, 모인 결과를 정리하여 하나의 최종 보고서를 작성합니다. 이때 정보가 부족하거나 모순이 있다면, 특정 경쟁사에 대해서만 핀포인트로 "재조사 (리트라이) 루프"를 발생시킵니다.

멀티 에이전트와 병렬 분산 처리를 결합함으로써, 단일 에이전트로는 수십 분이 걸릴 처리를 안전하고 매우 짧은 시간 내에 완수하는 것이 가능해집니다.