멀티 에이전트 시스템 설계 — 역할 분리, 통합 패턴, 그리고 현실적 ROI

-

에이전트를 여러 개 운영할 때 드러나는 아키텍처 원칙 — 어떤 구조가 작동하고, 어떤 구조가 무너지는가

핵심 요약

  • 멀티 에이전트 시스템에서 ROI는 에이전트의 수가 아니라 역할 분리의 명확성에 달려 있다
  • 오케스트레이터 없이 에이전트를 늘리면 관리 부담이 선형이 아닌 지수적으로 증가한다
  • 에이전트 간 시너지는 설계하지 않으면 발생하지 않는다 — 데이터 흐름과 통합 지점을 명시적으로 정의해야 한다

배경

AI 에이전트를 하나 만들면 두 개가 되고, 두 개가 다섯 개가 됩니다. 어느새 여러 에이전트를 동시에 운영하고 있었습니다. 각 에이전트는 나름의 이유로 만들어졌지만, 전체를 조감도로 놓고 보면 패턴이 보입니다. 어떤 에이전트는 매일 가치를 만들고, 어떤 에이전트는 만들어놓고 거의 쓰지 않습니다.

이 글은 멀티 에이전트 시스템을 구성하면서 확인한 역할 분류 체계, 통합 패턴, 그리고 실제 ROI 평가 방법론을 정리합니다.

본문

1. 역할 분류 체계

에이전트를 역할 기준으로 나누면 네 가지 카테고리가 됩니다.

인프라 계층 — 다른 에이전트들의 운영 기반을 담당합니다. 중앙 오케스트레이터, 대시보드, 모니터링이 여기에 속합니다. 이 계층이 없으면 나머지 에이전트들이 고립됩니다.

엔진 계층 — 로컬 AI 처리, LLM 라우팅, 프롬프트 하네스처럼 다른 에이전트에게 기술 기반을 제공합니다. 직접 노출되지 않지만 시스템 전체 성능을 결정합니다.

도메인 계층 — 특정 분야의 작업을 전담합니다. 콘텐츠 작성, 주식 분석, 소설 작성처럼 명확한 산출물이 있는 에이전트들입니다.

앱 계층 — Flutter 앱처럼 사용자와 직접 상호작용하는 결과물을 만드는 에이전트입니다. 개발 단계에서는 ROI가 잠재적이고, 출시 후에야 실현됩니다.

2. ROI 평가 — 어떤 에이전트가 가치를 만들었나

높은 ROI:

  • 콘텐츠 에이전트: 블로그 글 자동 발행, 이미지 자동 생성. 수동으로 했다면 수백 시간이 걸렸을 작업을 자동화했다.
  • 인프라 오케스트레이터: 모든 에이전트의 허브로서 모니터링, 대시보드, 메시지 라우팅을 담당한다. 이 에이전트가 없으면 다른 에이전트들이 고립된다.
  • 프롬프트 하네스: 모든 에이전트의 CLAUDE.md, 스킬, 메모리 구조를 표준화했다. 새 에이전트 생성 시간을 수시간에서 수십 분으로 단축했다.

중간 ROI:

  • 로컬 AI 엔진: 운영 노하우를 축적했다. 가치는 높지만 일상적 사용 빈도는 중간이다.
  • 씽크탱크 에이전트: 의사결정 지원과 확증편향 차단에 가치가 있지만, 정량적 ROI를 측정하기 어렵다. 장기적 가치가 높은 유형이다.
  • 시그널 분석 에이전트: 시그널 수집과 분석을 자동화했다. 실제 성과에 기여하는지는 더 긴 기간의 검증이 필요하다.

낮은 ROI:

  • 일회성 프로젝트 에이전트: 목표를 달성했지만, 완성 후에는 할 일이 없다. 상시 운영이 아닌 프로젝트성 에이전트의 한계다.
  • 중단된 에이전트: 의도적 중단 상태. 현재 ROI는 0이지만, 재개 시 가치가 발생할 수 있다.

판단 보류:

  • 앱 개발 에이전트들: 앱이 완성되어 사용자를 확보하면 ROI가 급등할 수 있지만, 현재는 개발 단계다.

3. 통합 패턴 — 시너지는 설계해야 발생한다

에이전트를 개별적으로 평가하면 놓치는 것이 있습니다. 에이전트 간 통합 패턴입니다.

콘텐츠 파이프라인: 씽크탱크 에이전트 → 콘텐츠 에이전트. 생활 경험이 블로그 소재가 되고, 리서치 결과가 다시 의사결정 참고자료가 됩니다. 양방향 데이터 흐름이 양쪽을 강화합니다.

인프라 허브 패턴: 중앙 오케스트레이터 → 모든 에이전트. 중앙 대시보드가 생기면서 각 에이전트의 상태를 한눈에 파악할 수 있게 되었습니다. 문제 발견 속도가 빨라졌습니다.

공유 기술 스택: 같은 기술 스택을 쓰는 에이전트들은 UI 패턴과 상태관리 패턴을 공유합니다. 한 프로젝트에서 해결한 문제의 패턴이 다른 프로젝트에 바로 적용됩니다.

이 패턴들은 사전에 명시적으로 설계하지 않으면 발생하지 않습니다. "각 에이전트의 산출물이 어느 에이전트의 입력이 되는가"를 초기에 정의하는 것이 통합 설계의 핵심입니다.

4. 실패와 교훈

에이전트가 너무 빨리 늘었다: 초기에는 "필요하면 만들자"는 기준으로 에이전트를 추가했습니다. 일정 수를 넘기니 관리 부담이 급증했습니다. 지금은 "기존 에이전트로 해결 불가능할 때만" 새 에이전트를 만듭니다.

오케스트레이션의 중요성을 늦게 깨달았다: 에이전트가 몇 개일 때는 개별 관리가 가능했습니다. 그 이상이 되면서 중앙 오케스트레이터가 필수적이라는 것을 뒤늦게 깨달았습니다. 오케스트레이터는 마지막이 아니라 가장 먼저 만들어야 합니다.

마이그레이션의 현실: 운영 중인 시스템을 새 아키텍처로 이전하는 작업은 예상보다 복잡합니다. 실제 사례로, OpenClaw에서 Hermes로 이전을 시도했을 때 토큰 폭주 문제가 발생했습니다. OpenClaw로 복귀한 뒤 Hermes를 재설계하는 과정에 있습니다 (검증 중). 기존 시스템 위에서 점진적으로 새 시스템을 검증하는 Strangler Fig 패턴이 필요한 이유입니다.

문서화 부채: 바쁘게 에이전트를 만들면서 "왜 이 결정을 했는가"를 기록하지 않았습니다. 나중에 맥락을 복원하는 데 불필요한 시간을 소비했습니다. 온톨로지와 메모리 시스템이 이 문제의 해결책입니다.

5. 에이전트 수가 아닌 가치를 평가하라

"에이전트는 몇 개가 적정한가"라는 질문을 자주 받습니다. 정직한 답: 정답이 없는 질문입니다.

대신 더 유용한 질문이 있습니다: - 각 에이전트가 만드는 가치가 관리 비용보다 큰가? - 에이전트 간 시너지가 발생하는가, 아니면 고립되어 있는가? - 새 에이전트 대신 기존 에이전트를 강화하는 것이 더 효율적인가?

수가 중요한 것이 아닙니다. 중요한 것은 각 에이전트의 가치를 지속적으로 평가하고, 솔직하게 조정하는 것입니다. 가치가 없는 에이전트를 중단하는 것도 시스템 관리의 일부입니다.

마무리

멀티 에이전트 시스템에서 가장 중요한 교훈: 에이전트는 만드는 것보다 운영하는 것이 어렵습니다. 만드는 데는 짧은 시간이면 충분하지만, 지속적으로 가치를 만들도록 유지하는 것은 끊임없는 평가와 조정을 요구합니다.

완벽한 시스템을 한 번에 설계하려 하지 마세요. 필요한 에이전트부터 만들고, 가치를 평가하고, 조정하세요. 오케스트레이터를 먼저 만들고, 통합 패턴을 명시적으로 설계하고, 마이그레이션은 점진적으로 검증하면서 진행하세요. 이 반복이 시스템을 발전시킵니다.

댓글

댓글 쓰기

이 블로그의 인기 게시물

"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 »