RAG 검색봇을 만들기 위한 프레임워크 비교

LangChain 비슷한 “에이전트/워크플로우 프레임워크”
회사용 RAG 검색봇을 멀티에이전트 구조로 설계하는 추천 방법

1. LangChain과 유사한 에이전트 / 오케스트레이션 프레임워크들

1-1. LlamaIndex

포지션: RAG + 에이전트 + 툴 사용에 강함
특징
- 문서 인덱싱/쿼리/RAG에 특화 (LangChain보다 RAG 쪽이 더 구조화된 느낌)
- AgentRunner, ReActAgent, FunctionCallingAgent 등을 이용해서 에이전트 구성
- 멀티에이전트도 가능 (router, sub-agent, tool agent 등)
장점
- 회사용 문서 검색/RAG 구현이 목적이면, LlamaIndex + LangChain 조합도 많이 씀
- Prompt/Graph/Query 구조가 비교적 명확함

1-2. Semantic Kernel (Microsoft)

포지션: .NET, C#, Python 중심의 에이전트/플러그인 프레임워크
특징
- “스킬(plugins)” 개념으로 함수/툴을 관리
- Planner 개념으로 작업 계획 세우고, 여러 기능을 조합
- Azure OpenAI / OpenAI / 기타 LLM 연동에 최적화
장점
- MS 스택(.NET, Azure) 쓰는 회사라면 엔터프라이즈 통합이 편함
- 강한 형식(Type-safe) 환경을 선호하면 꽤 괜찮음

1-3. Autogen (Microsoft)

포지션: 멀티에이전트 협업 시스템에 거의 특화된 프레임워크
특징
- 여러 에이전트를 정의하고, 서로 메시지 주고받게 하는 구조
- 예: “UserProxyAgent, AssistantAgent, CodeExecutorAgent”들이 협업
- RAG, 코드 실행, 툴 사용, 리뷰 에이전트 등 구성하기 좋음
장점
- “멀티에이전트” 관점에서는 오히려 LangChain보다 컨셉이 직관적
- 회사 내에서 “검색 담당”, “요약 담당”, “검수 담당” 같은 에이전트를 나눠 구현하기 좋음

1-4. CrewAI, AutoGen-like 프로젝트들

CrewAI (Python)
- 여러 에이전트를 “팀(Crew)”으로 묶어서 협업시키는 프레임워크
- 역할 배분/작업 분해 중심
기타
- Haystack (deepset) – 원래는 검색/RAG 프레임워크, 요즘은 에이전트 기능도 강화 중
- IBM Granite Agents, OpenAI Assistant API 기반 자체 프레임워크 등

1-5. 상용/플랫폼 쪽

OpenAI Assistants API / Anthropic Workflows (출시 영역에 따라 상이)
- 서버리스하게 “에이전트 + 툴 + 파일 + RAG”를 플랫폼 수준에서 제공
- 코드 구현량 줄이고 싶은 경우 유리
LangGraph (LangChain 팀에서)
- 에이전트/툴 호출을 “상태 머신 / 그래프”처럼 정의해서 복잡한 플로우 설계에 좋음

2. 회사용 RAG 검색봇을 “멀티에이전트”로 구현하는 관점

2-1. 멀티에이전트로 나눌 수 있는 전형적인 역할들

회사에서 자주 쓰는 패턴은 아래처럼 “역할 기반”으로 나누는 겁니다.

Router / Intent Agent (라우터 에이전트)
- 사용자 질문이:
  - 단순 지식 검색인지
  - 사내 정책/HR 관련인지
  - 코드/기술 문서 관련인지
  - FAQ 수준인지
- 를 구분해서, 어느 RAG 파이프라인 또는 도메인 에이전트에 보낼지 결정
Retriever Agent (검색 담당)
- 벡터 검색 + 키워드 검색 + 필터링(부서, 시점, 문서 타입) 조합
- 여러 인덱스에서 검색 후, 스코어 통합/재랭킹
- 예: HR 문서 인덱스, 기술 위키 인덱스, 제품 매뉴얼 인덱스 등 각각 쿼리
Summarizer / Answer Composer Agent (응답 작성 담당)
- 검색된 문서를 바탕으로:
  - 답변 생성
  - 출처 링크, 문서명, 버전 정보 명시
- “사실에 없는 내용은 추측하지 않는다” 같은 정책 프롬프트를 강하게 적용
Policy / Guardrail Agent (검수/필터 담당)
- 보안/개인정보/규정 위반 여부 체크
- 외부로 나가면 안 되는 키워드/패턴(예: 고객 개인정보, 내부 코드) 필터링
- 민감 내용은 마스킹하거나 “담당자에게 문의하라”로 응답
Tool / Action Agent (실행 담당 – 선택)
- 단순 검색이 아니라:
  - 티켓 생성(Jira, ServiceNow)
  - 권한 요청 워크플로우 시작
  - 사내 시스템에서 정보 조회(예: 재직증명서 발급 여부)
- 까지 하고 싶다면, 별도 툴 에이전트를 두고 RAG 결과를 기반으로 액션 수행

멀티에이전트의 핵심은 “역할/책임을 명확히 나누고, 메시지 전달 구조를 설계”하는 것입니다.

3. 멀티에이전트 RAG 검색봇 설계 패턴

패턴 A: LangChain / LangGraph 기반 상태 머신 + RAG

추천 상황: 이미 Python + LangChain을 쓰고 있거나, 복잡한 흐름(재시도, 에러 처리)을 명시적으로 설계하고 싶을 때

구조 예시:

User → Router Agent
- 질문 → 라우터 (LLM 기반 분기 + 규칙 기반 분기)
라우터 결과에 따라:
- HR 에이전트, Tech 에이전트, FAQ 에이전트 등으로 전달
각 도메인 에이전트 내부:
- Retriever → Answer Agent 플로우
마지막에 Policy Agent를 거쳐 최종 응답 반환

구현 스택:

LangChain (chains, tools, agents)
LangGraph (state.machine/graph로 에이전트 간 연결 설계)
백엔드: FastAPI / Django 등으로 API 래핑

장점:

파이프라인이 시각적으로/논리적으로 명확
복잡해질수록 그래프형 설계가 유리

패턴 B: Autogen / CrewAI로 “에이전트 간 대화” 모델링

추천 상황:

“에이전트들끼리 협의/토론” 구조를 실험해 보고 싶거나,
작업을 “대화형 협업”으로 자연스럽게 표현하고 싶을 때

예시 플로우:

UserProxyAgent가 사용자 질문을 받음
RouterAgent가 어느 에이전트가 적합한지 제안
RetrieverAgent가 RAG 수행
AnswerAgent가 초고 작성
PolicyAgent가 검토 후 수정 제안
AnswerAgent가 수정/최종 확정

장점:

에이전트 추가/역할 변경이 상대적으로 쉽고 유연
PoC/실험용으로 빠르게 구조 바꿔보기 좋음

주의:

너무 많은 에이전트/턴을 쓰면 **비용과 지연(latency)**가 커질 수 있음 → 역할 최소화 필요

패턴 C: LlamaIndex 중심의 “Graph RAG + 멀티에이전트”