멀티 에이전트로 갈아타는데 기존 RAG는 살려뒀습니다

잘 도는 RAG에 새 구조를 도입한다는 것

운영하던 RAG 파이프라인이 있었습니다. 사용자 질문이 들어오면 의도 분석 → 검색 도구 선택 → 검색 병렬 실행 → 리랭크 → CRAG → 답변 생성으로 이어지는 구조였어요.

이 구조가 단순한 질문에는 잘 동작했지만, 복합 질문에서 한계가 보였습니다. "특정 시스템의 장애 영향 + 담당자 + 복구 절차" 같은 질문이 들어오면 한 번의 검색으로는 정보가 부족했어요. 그래프 검색이 필요한 부분과 텍스트 검색이 필요한 부분이 섞여 있는데, 단일 파이프라인에서 두 결을 모두 깊이 처리하기 어려웠습니다.

해결 방향은 멀티 에이전트 였습니다. 매니저 LLM이 질문을 분해해서 검색 전문 에이전트와 그래프 전문 에이전트에게 분배하고, 결과를 리포트 에이전트가 종합하는 구조입니다. 복합 질문에서 각 전문 에이전트가 자기 영역을 깊이 있게 처리할 수 있어요.

여기서 고민이 시작됐습니다. 잘 돌고 있는 기존 RAG를 그냥 갈아타도 될까?

새 구조가 모든 질문에 더 잘 작동한다는 보장이 없었습니다. 단순 질문은 오히려 매니저 LLM 호출이 추가되어 1.5초 정도 느려질 수 있었어요. 그리고 운영 중인 시스템에서 한 번에 갈아타는 건 위험했습니다. 새 구조에 버그가 있으면 사용자가 바로 영향을 받으니까요.

두 그래프를 동시에 두고 토글로 전환했습니다

선택한 방식은 기존 그래프와 새 그래프를 동시에 코드에 두고, 설정 토글로 전환 하는 것이었습니다.

# config.py
USE_MULTI_AGENT = False  # True로 바꾸면 멀티 에이전트 사용

# chat.py
if USE_MULTI_AGENT:
    active_graph = multi_agent_graph
else:
    active_graph = search_graph

기본값은 False입니다. 평소에는 기존 RAG가 그대로 돌고, 토글을 True로 바꾸는 순간 멀티 에이전트 구조로 전환됩니다. 다시 False로 돌리면 즉시 기존 구조로 복귀해요.

이 패턴의 장점은 명확했습니다.

위험 통제: 새 구조에 문제가 생기면 토글 한 번으로 즉시 롤백

A/B 검증: 같은 질문을 두 구조에 던져서 답변 품질을 비교 가능

점진 전환: 처음에는 내부 테스트, 다음은 일부 사용자, 마지막에 전체 전환

이해 가능한 코드: 두 구조가 같은 코드베이스에 있으니 차이를 직접 비교

새 코드를 만들면서 기존 코드를 지우지 않은 게 핵심이었어요. 두 구조가 한 코드베이스에 공존하는 구간이 길어졌지만, 안정적으로 옮겨가는 데는 이 방식이 가장 안전했습니다.

멀티 에이전트는 어떻게 다른가

토글 전환의 핵심은 두 구조가 어떻게 다른지를 명확히 아는 것이었어요.

기존 RAG 구조

질문 → 의도분석 → 도구 선택 → 검색(병렬) → 리랭크 → CRAG → 답변

의도 분석이 1회 일어나고, 거기서 결정된 도구들이 병렬로 실행됩니다. 검색 결과를 모아 리랭크하고 답변을 생성해요. 단순하고 빠릅니다.

멀티 에이전트 구조

질문 → 의도분석 → 매니저(질문 분해)
         ├→ 검색 에이전트 (병렬) ─┐
         └→ 그래프 에이전트 (병렬) ─┤→ 리포트 에이전트 → 답변

의도 분석 다음에 매니저 LLM이 들어옵니다. 매니저가 "이 질문은 어떤 에이전트에게 맡길지"를 결정해요. 단순 질문은 한 에이전트에게만, 복합 질문은 여러 에이전트에게 분배합니다.

각 에이전트는 자기 영역의 도구만 다룹니다.

매니저가 분배할 때는 LLM에 프롬프트를 보내 판단합니다.

질문: "특정 서버의 IP 주소"           → graph_agent
질문: "장애 영향 + 담당자 + 복구"     → graph_agent + search_agent
질문: "보안 이슈 정리"                → search_agent
질문: "안녕"                          → report_agent (chitchat)

흥미로운 점은 chitchat과 후속 질문은 매니저를 거치지 않고 리포트 에이전트가 직접 처리한다는 것이었어요. 매니저 LLM 호출은 1.5초 정도 걸리는 비용이 있어서, 매니저가 필요 없는 케이스는 우회시켜서 응답 속도를 보존했습니다.

검색 에이전트 안에 CRAG가 들어갔습니다

기존 RAG에서 CRAG는 전체 파이프라인의 한 단계로 동작했습니다. 검색 결과 품질이 부족하면 자동으로 쿼리를 재작성해서 다시 검색하는 보정 장치였어요.

멀티 에이전트로 옮기면서 CRAG의 위치가 바뀌었습니다. 전체 파이프라인이 아니라 검색 에이전트 내부에 들어갔어요.

[검색 에이전트 내부]
1. 5개 소스 검색 → 리랭크
2. top_score < 0.5 → LLM이 쿼리 리라이팅
3. 리라이팅된 쿼리로 재검색 → 결과 합산 → 재리랭크

예: "지난달 보안 이슈"
   → "보안 취약점 사이버 공격 랜섬웨어 정보유출 이슈 정리"

이렇게 한 이유는 책임 분리였습니다. CRAG는 검색 품질에 대한 보정 로직이고, 그건 검색 에이전트의 책임 영역이에요. 그래프 에이전트나 리포트 에이전트가 신경 쓸 게 아닙니다.

각 에이전트가 자기 영역의 보정·검증·리트라이를 책임지는 구조가 만들어졌어요. 이게 멀티 에이전트의 진짜 장점이었습니다. 단일 파이프라인이었을 땐 모든 보정이 메인 흐름에 흩어져 있었는데, 에이전트로 분리되니 각 영역의 책임이 명확해졌습니다.

LangGraph의 Send 패턴으로 병렬 분배를 구현했습니다

매니저가 여러 에이전트에게 동시에 분배할 때 사용한 게 LangGraph의 Send 패턴입니다.

# 매니저 노드 후 _dispatch_agents에서
return [
    Send("search_agent_node", state),
    Send("graph_agent_node", state),
]

Send는 동시에 여러 노드를 호출하고, 각 노드의 결과가 같은 state 필드에 누적되도록 합니다. 핵심은 state 정의에 있어요.

class GraphState(TypedDict):
    agent_results: Annotated[list, operator.add]  # 자동 누적

operator.add 리듀서가 붙어 있어서 여러 에이전트가 동시에 결과를 추가해도 자동으로 합쳐집니다. 동기화 로직을 직접 짤 필요가 없어요.

리포트 에이전트는 agent_results가 채워진 다음에 실행됩니다. LangGraph가 모든 Send가 완료된 후에 다음 노드를 실행하도록 동기화 처리를 해줘요.

이 패턴 덕분에 매니저-에이전트-리포트 구조를 명령형 코드 없이 그래프 정의만으로 구현할 수 있었습니다.

검증은 토글 덕분에 쉬웠습니다

토글 구조의 진짜 장점은 검증 단계에서 드러났어요. 같은 질문을 두 구조에 던져서 결과를 비교할 수 있었거든요.

복합 질문에서는 멀티 에이전트가 확실히 더 깊이 있는 답변을 만들었습니다. 단순 질문이나 chitchat에서는 두 구조의 답변 품질이 비슷했지만 멀티 에이전트가 약간 느렸어요.

이 결과를 보고 정한 운영 방침은 "기본은 멀티, 다만 chitchat은 매니저 우회"였습니다. 그리고 토글은 한동안 유지하기로 했어요. 멀티 에이전트에 새 기능을 추가할 때 기존 RAG와 비교 검증할 수 있는 안전망이거든요.

마무리

기존 RAG에서 멀티 에이전트로 전환할 때, 새 코드를 만들면서 기존 코드를 지우지 않았습니다. 두 그래프를 코드에 동시에 두고 USE_MULTI_AGENT 토글 하나로 전환하는 구조로 갔어요. 검증과 점진 전환과 즉시 롤백을 모두 지원하는 패턴이었습니다.

멀티 에이전트는 매니저 LLM이 질문을 분해해서 검색·그래프·리포트 에이전트에게 분배하는 구조입니다. 매니저 LLM 호출이 1.5초 정도 추가되지만, 복합 질문에서는 각 전문 에이전트가 자기 영역을 깊이 있게 처리할 수 있어 답변 품질이 올라갔어요. 단순 질문이나 chitchat은 매니저를 우회시켜서 속도 손실을 최소화했습니다.

운영 중인 시스템에 새 구조를 도입해야 한다면, 기존 코드를 지우는 것을 마지막에 두는 걸 추천합니다. 토글 한 줄로 두 구조가 공존하게 만드는 게 안전한 점진 전환의 시작이었습니다.