에이전트 운영 설계 노트 (9/9) — 멀티 서브에이전트 RAG는 역할 체계다

-

작은 RAG 유닛을 많이 붙이면 더 똑똑해질 것처럼 보인다. 실제로는 그보다 훨씬 큰 변화가 생긴다. 검색이 여러 번 일어나는 것이 아니라, 누가 무엇을 검색할 권한이 있고 어떤 결과를 언제 장기 기억으로 올릴지를 설계해야 하기 때문이다.

영문판: Multi-Subagent RAG Is Not Many Searches. It Is a Role System.

단일 파이프라인 RAG는 설명하기 쉽다. 질문이 들어오면 검색하고, 관련 문서를 몇 개 붙이고, 모델이 답한다. 이 구조는 문서 질의응답, 사내 위키 탐색, FAQ 같은 문제에서는 여전히 유효하다. 하지만 작업이 길어지고, 문서 공간이 나뉘고, 판단 단계가 여러 개로 갈라지면 단일 파이프라인은 금방 한계를 드러낸다. 검색이 한 번으로 끝나지 않고, 같은 질문 안에서도 서로 다른 전문성이 필요해지기 때문이다.

예를 들어 제품 정책 문서를 읽는 에이전트, 로그를 읽는 에이전트, 코드 변경 이력을 읽는 에이전트, 그리고 이 셋의 결과를 합쳐 사용자에게 설명하는 에이전트가 있다고 하자. 겉으로 보면 "RAG가 4개 있네"라고 말할 수 있다. 하지만 실제 운영 관점에서는 그보다 더 복잡하다. 각 에이전트는 다른 문서 경계를 갖고, 다른 검색 규칙을 쓰고, 서로의 결과를 그대로 믿지 않으며, 어떤 정보만 기억으로 승격할지 따로 판단해야 한다. 이 시점부터 문제는 단순 검색이 아니라 역할 기반 retrieval 시스템이 된다.

왜 단일 파이프라인 RAG는 금방 막히는가

단일 RAG의 장점은 선형성이다. query -> retrieve -> generate가 한 줄로 설명된다. 대신 이 구조는 세 가지를 한 덩어리로 묶어 버린다.

첫째, 질문 해석과 검색 공간 선택이 한 번에 처리된다. 사용자의 질문이 "이 정책이 왜 바뀌었나?"일 때, 실제로 필요한 것은 정책 문서 자체일 수도 있고, 변경 이력일 수도 있고, 회의 기록일 수도 있다. 단일 파이프라인은 이 라우팅 결정을 검색기 내부 점수에 떠넘기기 쉽다.

둘째, 전문성 충돌이 가려진다. 코드 문서를 잘 찾는 retriever와 운영 로그를 잘 찾는 retriever는 보통 같은 방식으로 튜닝되지 않는다. 그런데 단일 파이프라인은 이 차이를 "top-k를 조금 조정하면 되지" 수준으로 축소해 버린다. 실제로는 전혀 다른 스키마와 실패 모드를 다뤄야 한다.

셋째, 결과 검증이 뒤늦게 붙는다. 하나의 검색 결과를 그대로 생성 모델에 넣으면 답은 빨리 나오지만, 그 결과가 틀렸을 때 어디서 잘못됐는지 추적하기 어렵다. 검색이 틀렸는지, 합성이 틀렸는지, 기억이 오염됐는지 구분이 안 된다.

이 한계 때문에 사람들은 자연스럽게 "그럼 작은 전문 RAG를 여러 개 두자"는 방향으로 간다.

왜 많은 작은 RAG 에이전트가 매력적으로 보이는가

이 접근이 매력적인 이유는 분명하다.

첫째, 각 유닛을 좁게 최적화할 수 있다. 법무 문서용 retriever는 조항, 버전, 효력 시점을 잘 잡아야 하고, 코드용 retriever는 함수명, 파일 경로, 커밋 문맥을 잘 잡아야 한다. 하나의 범용 인덱스로 둘을 동시에 잘하기는 어렵다.

둘째, 실패 반경을 줄일 수 있다. 정책 전문 에이전트가 틀려도 로그 전문 에이전트까지 같이 무너지지는 않는다. 문제를 국소화하기 쉬워진다.

셋째, 증거를 분리해서 다룰 수 있다. 서로 다른 출처의 결과를 따로 들고 있다가 마지막 단계에서 합성하면, 최소한 "어느 층에서 무슨 근거가 나왔는지"는 추적 가능해진다.

넷째, 팀 구조와도 잘 맞는다. 현실의 조직은 이미 역할 단위로 일한다. 제품, 운영, 법무, 데이터, 개발이 같은 문서를 같은 방식으로 읽지 않는다. 멀티 서브에이전트 RAG는 이 조직적 현실을 시스템 설계에 반영하는 방식이다.

문제는 여기서부터다. 작은 RAG를 여러 개 둔다고 해서 자동으로 좋은 시스템이 되지는 않는다. 실제로 바뀌는 것은 수량이 아니라 구조다.

실제로 바뀌는 것: 검색이 아니라 역할 체계

멀티 서브에이전트 RAG에서 핵심은 다섯 층이다.

1. Router

첫 단계는 "무엇을 찾을까"가 아니라 "누가 찾아야 하나"를 정하는 일이다. 이 차이는 작지 않다. 질문 라우터는 질의를 의미적으로 분류하는 동시에, 어떤 도메인 경계를 열어도 되는지 결정한다. 즉 라우터는 편의 기능이 아니라 권한 모델에 가깝다.

2. Specialist Retrievers

각 서브에이전트는 자기 소유 문맥만 본다. 여기서 중요한 것은 검색 품질 그 자체보다 검색 경계다. 코드 에이전트가 회의록까지 뒤지기 시작하면 곧 중복 검색과 엉뚱한 연결이 늘어난다. 반대로 너무 좁으면 필요한 증거를 놓친다. 좋은 설계는 "잘 찾는 능력"보다 "어디까지만 찾는지"를 명확히 한다.

3. Synthesis Layer

전문 에이전트 결과를 모으는 합성 단계는 단순 요약기가 아니다. 서로 다른 증거 조각의 충돌을 드러내고, 빠진 연결고리를 표시하고, 불확실성을 보존해야 한다. 멀티 에이전트 시스템에서 가장 위험한 것은 각자 그럴듯한 부분 답을 만든 뒤, 마지막 모델이 그것을 너무 매끄럽게 이어 붙이는 경우다.

4. Verifier

합성 결과를 다시 검증하는 별도 레이어가 필요하다. 검증기는 "답이 좋아 보이는가"가 아니라 "각 주장에 출처가 붙어 있는가", "서로 충돌하는 증거를 덮어쓰지 않았는가", "라우터가 잘못된 도메인을 열지 않았는가"를 본다. 단일 RAG에서는 선택 사항처럼 보이던 검증이, 멀티 서브에이전트 구조에서는 거의 필수 레이어가 된다.

5. Memory Layer

가장 큰 변화는 메모리다. 여러 서브에이전트가 반복적으로 일하면, 매번 검색만 하는 구조는 금방 비싸지고 느려진다. 그래서 시스템은 자꾸 "이번 결과를 다음에도 재사용할 수 없을까?"를 묻게 된다. 바로 여기서 memory promotion 문제가 생긴다. 무엇을 세션 메모리에 남길지, 무엇을 팀 공용 기억으로 승격할지, 무엇은 아예 잊어야 하는지가 중요해진다.

즉 멀티 서브에이전트 RAG는 "여러 검색기의 병렬화"가 아니라 role-based retrieval + orchestration + verification + memory promotion 구조다.

어디서 깨지는가

이 구조는 강력하지만, 대개 생각보다 빨리 망가진다. 대표적인 파손 지점은 다섯 가지다.

중복 retrieval

여러 에이전트가 비슷한 문서를 각자 다시 찾기 시작하면 비용만 늘고 정보 이득은 거의 없다. 더 나쁜 경우, 같은 문서를 다른 청킹 기준으로 가져와 서로 다른 결론을 낸다. 이때 시스템은 다양성이 늘었다고 착각하지만 실제로는 중복 노이즈만 늘어난다.

증거 충돌

전문 에이전트 A는 "정책 변경이 확정됐다"고 말하고, B는 "아직 초안 단계"라고 말할 수 있다. 둘 다 자기 문맥 안에서는 맞을 수 있다. 문제는 오케스트레이터가 이 충돌을 드러내지 못하고 하나를 자연스럽게 덮어쓸 때 생긴다. 합성기의 유창함이 시스템의 정합성을 파괴하는 순간이다.

토큰과 비용 폭증

작은 유닛을 많이 두면, 처음엔 효율적일 것 같지만 실제로는 라우팅 프롬프트, 각 에이전트 컨텍스트, 중간 결과 요약, 검증 호출까지 붙으면서 토큰이 급격히 불어난다. "작게 쪼갰으니 싸겠지"는 흔한 착각이다. 분해가 곧 절감은 아니다.

stale memory

한 번 잘 작동한 결과를 기억으로 올리면 이후 속도는 빨라진다. 대신 오래된 기억이 새 검색보다 더 강한 priors가 되기 시작한다. 그러면 시스템은 retrieval-augmented가 아니라 memory-biased로 바뀐다. 특히 역할별 메모리가 제각각 갱신되면 어떤 에이전트는 최신 정책을 기억하고 다른 에이전트는 구버전을 기억하는 비대칭이 생긴다.

약한 orchestrator

가장 흔한 실패는 중앙 오케스트레이터가 사실상 "모아서 붙이는 모델"에 머무르는 경우다. 멀티 서브에이전트 구조는 중앙 조정자가 약하면 오히려 단일 RAG보다 나빠진다. 단일 파이프라인은 적어도 책임 위치가 한 군데인데, 멀티 구조는 조정이 약할수록 오류가 분산되고 디버깅이 어려워진다.

그래서 설계 원칙은 무엇인가

이 구조를 안정적으로 굴리려면 기능보다 소유권을 먼저 설계해야 한다.

1. 문맥 소유권을 먼저 나눈다

에이전트는 능력으로 나누기보다 책임지는 문맥 단위로 나누는 편이 낫다. "요약 에이전트" 같은 추상 역할보다 "정책 문서 소유 에이전트", "로그 소유 에이전트" 같은 경계가 운영상 훨씬 강하다.

2. retrieval boundary를 명시한다

각 에이전트는 어디를 볼 수 있고 어디는 보면 안 되는지 분명해야 한다. 좋은 시스템은 자유 탐색보다 제한 탐색을 더 많이 사용한다. 이 제약이 있어야 중복 검색과 책임 붕괴를 줄일 수 있다.

3. 합성과 검증을 분리한다

합성기는 이야기를 만드는 역할이고, 검증기는 이야기에 제동을 거는 역할이다. 둘을 같은 호출로 처리하면 보기 좋은 답이 검증을 이겨 버린다. 멀티 에이전트에서는 특히 이 분리가 중요하다.

4. memory promotion 규칙을 둔다

모든 유용한 중간 결과를 기억으로 올리면 결국 기억이 쓰레기장이 된다. 기억 승격은 최소한 다음 질문에 답할 수 있어야 한다. 이것이 반복 재사용 가능한 사실인가? 출처가 안정적인가? 만료 조건이 있는가? 덮어쓰기 규칙이 있는가? 승격보다 폐기 규칙이 더 중요할 때가 많다.

5. 오케스트레이터의 책임을 줄이지 않는다

중앙 조정자는 단순 배차기가 아니다. 라우팅 이유, 호출 순서, 중복 제거, 충돌 표면화, 재질문 여부, 메모리 승격 후보 선별까지 책임져야 한다. 이 층이 약하면 전문 에이전트를 아무리 잘 만들어도 시스템 전체는 뭉개진다.

이 구조의 진짜 업사이드는 무엇인가

잘 설계된 멀티 서브에이전트 RAG의 장점은 단순 정확도 향상보다 더 운영적이다.

첫째, 어떤 답이 어떤 문맥 소유자에게서 왔는지 추적 가능하다. 둘째, 검색 실패와 합성 실패를 분리해 디버깅할 수 있다. 셋째, 반복 업무에서 기억 승격을 통해 검색 비용을 선택적으로 줄일 수 있다. 넷째, 조직의 실제 역할 구조를 반영하기 때문에 장기적으로는 단일 거대 프롬프트보다 유지보수가 쉽다.

하지만 이 장점은 자동으로 생기지 않는다. 역할 경계, 검증 층, 승격 규칙이 없는 멀티 구조는 "서브에이전트가 많은 단일 혼란 시스템"이 되기 쉽다.

결론

많은 작은 specialized subagent RAG 유닛을 조합하는 순간, 우리는 더 이상 "RAG를 몇 개 썼는가"를 묻는 단계에 있지 않다. 진짜 질문은 이것이다.

누가 어떤 문맥을 소유하는가.
누가 어떤 검색을 할 권한이 있는가.
서로 충돌하는 증거를 누가 드러내는가.
무엇을 기억으로 올리고, 무엇은 잊는가.

이 네 가지가 설계되지 않았다면, 멀티 서브에이전트 RAG는 고급 아키텍처처럼 보여도 실제로는 비용이 큰 다중 검색 파이프라인에 불과하다. 반대로 이 네 가지가 설계돼 있다면, 그것은 단순한 "many RAGs"가 아니라 역할 기반 retrieval system이 된다.

앞으로의 에이전트 시스템은 검색 품질 경쟁만으로는 설명되지 않을 가능성이 크다. 더 중요한 축은 역할, 조정, 검증, 기억의 운영 설계다. 멀티 서브에이전트 RAG는 그 전환이 가장 먼저 드러나는 지점이다.

함께 읽으면 좋은 글

참고 자료

  • 내부 연속 글 기준: 메모리, 라우팅, 검증, 소유권을 따로 설계해야 한다는 문제의식 위에서 작성
  • 이 글은 외부 제품 비교보다 아키텍처 관점의 설계 메모에 가깝다

시리즈 전체 안내: 시리즈 목차

댓글

댓글 쓰기

이 블로그의 인기 게시물

"LLM 핵심 학습 (1/6) — 기본: 토큰화·임베딩·어텐션·위치 인코딩"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/6 파인튜닝 → 트랜스포머 한 블록의 데이터 흐름을 문자열 → 토큰 → 임베딩 → 어텐션 → 출력 표현 까지 손으로 풀어 본다. 이번 편이 끝나면 "왜 \(\sqrt{d_k}\)로 나누는가", "RoPE는 무엇을 회전시키는가", "한국어가 영어보다 토큰이 많은 까닭은 무엇인가"가 한 줄로 설명될 수 있다. 0. 학습 목표 이 편을 마치면 다음을 직접 할 수 있다. BPE 토크나이저 가 어휘를 어떻게 학습하고 새 문자열을 어떻게 자르는지 종이 위에서 시뮬레이션한다. 임베딩 행렬 의 모양과 초기화, weight tying의 의미를 한 줄로 설명한다. Scaled Dot-Product Attention 의 식을 차원 단위로 추적하고 PyTorch 30줄로 재현한다. Multi-Head Attention 이 한 헤드와 비교해 무엇이 다른지, 헤드 수가 늘면 어디가 비싸지는지 답한다. Sinusoidal·RoPE·ALiBi 세 위치 인코딩의 식과 외삽 성질을 구분한다. 컨텍스트 확장이 왜 \(O(N^2)\)인지, "Lost in the Middle"이 왜 발생하는지 설명한다. 1. 핵심 요약 트랜스포머의 입력은 문자열 이 아니라 정수 ID 시퀀스 다. 토크나이저가 문자열 → ID로 자른다. 임베딩은 정수 ID를 \(d\)차원 벡터로 lookup하는 학습 가능한 테이블이다. Self-Attention은 \(\text{softmax}(QK^\top / \sqrt{d_k}) V\) 한 줄이 핵심이고, 멀티헤드는 같은 연산을 여러 부분 공간에서 병렬화한 것이다. 위치 정보는 임베딩에 직접 더하거나(Sinusoidal), Q·K에 회전을 가하거나(RoPE), 어텐션 스코어에 거리 패널티를 더해서(ALiBi) 주입한다. 컨텍스트 길이 \(N\)에 대해 표준 어텐션은 \(O(N^2)\) 비용을 갖고, 긴 컨텍스트에서는 중간 위...
Read more »

"LLM 핵심 학습 (2/6) — 파인튜닝: LoRA·QLoRA·증류·Adapter"

-
이미지
← 1/6 기본 📚 시리즈 목차 3/6 디코딩과 생성 → 사전학습된 LLM을 내 데이터 에 적응시키는 방법을 비용·메모리·일반화 관점에서 정리한다. Full FT의 한계 → Adapter → LoRA → QLoRA → Distillation 순으로 같은 그림을 점점 확대해 본다. 0. 학습 목표 Full fine-tuning의 메모리 병목을 옵티마이저 상태·그래디언트·가중치·활성화 의 4분할로 설명한다. Adapter(Houlsby 2019)와 LoRA(Hu 2021)의 식 차이를 한 줄로 적는다. LoRA의 \(A, B\) 행렬이 왜 저랭크 이고, rank \(r\) 선택이 무엇을 결정하는지 답한다. QLoRA(Dettmers 2023)의 NF4·double-quant·paged optimizer를 분리해서 설명한다. Catastrophic Forgetting을 분포 시프트 관점에서 정의하고 완화 기법을 두 개 이상 든다. Hinton 2015의 Knowledge Distillation 식을 손으로 유도한다. 1. 핵심 요약 Full FT는 메모리/디스크/시간 모두 비싸다. 7B 모델 full FT는 V100 8장 + A100 1장으로도 큰 부담이다. PEFT(파라미터 효율 파인튜닝) 일가족은 극히 일부 파라미터만 학습 해 같은 효과를 얻는다. LoRA: \(\Delta W = BA\) (rank \(r \ll \min(d_{\text{in}}, d_{\text{out}})\))로 가중치 업데이트를 저랭크 분해. QLoRA: 베이스 모델을 4-bit(NF4)로 양자화한 채 LoRA만 풀-정밀(BF16)으로 학습. Catastrophic Forgetting: 새 분포에 적응하느라 이전 능력이 무너지는 현상. PEFT 자체가 부분 완화책. Distillation: 큰 교사 모델의 soft target 을 학습 신호로 써서 작은 학생 모델 을 만든다. 2. 직관: 왜 사전학습만으로는 부족한가 사전학습은 일반...
Read more »

"ML 기초 학습 (1/9) — 머신러닝과 sklearn: 학습의 좌표계"

-
이미지
(시리즈 시작) 📚 시리즈 목차 2/9 이웃 알고리즘 → 이 시리즈는 신경망과 로컬 LLM으로 가기 전에 손에 익혀 둬야 할 머신러닝 기초 9편이다. 1편은 모든 ML 코드가 공유하는 공통 문법 을 잡는 데 쓴다. sklearn은 그 문법을 가장 일관되게 보여주는 도구다. 이번 편이 끝나면 어떤 모델을 만나도 fit → predict → score → 평가 흐름이 같다는 것이 손에 잡힌다. 0. 학습 목표 이 편을 마치면 다음을 할 수 있어야 한다. 지도학습·비지도학습·강화학습을 한 문장씩 구분해 설명한다. sklearn의 estimator 인터페이스 ( fit , predict , score , transform )를 코드 한 화면 안에서 쓸 수 있다. train/validation/test 분할을 왜 하는지, 어디서 데이터 누수가 생기는지 식과 그림으로 설명한다. 분류·회귀의 핵심 평가 지표(accuracy, precision, recall, F1, MSE, R²)를 정의에서 직접 계산할 수 있다. k-fold 교차검증 을 코드 한 줄로 돌리고, 결과의 평균과 표준편차를 함께 보고할 수 있다. Pipeline 으로 전처리와 모델을 묶어 데이터 누수를 구조적으로 막는 방법을 설명한다. 1. 핵심 요약 머신러닝은 데이터에서 함수 \(f: X \to Y\)를 찾는 작업 이다. 어떤 모델이든 이 본질은 같다. sklearn은 모든 모델을 같은 인터페이스( fit , predict , score )로 통일해, 모델을 바꿀 때 한 줄만 바꾸면 되게 한다. train/val/test 세 분할이 표준이다. 검증으로 하이퍼파라미터를 고르고, 테스트는 마지막에 한 번만 본다. 데이터 누수 (test 정보가 train에 새는 현상)는 ML 입문자가 가장 자주 만드는 실수이며, Pipeline + cross_val_score 조합으로 구조적으로 막을 수 있다. 평가 지표는 문제 유형 (분류/회귀) 과 클래스 불균형...
Read more »