분산 시스템 관점으로 바라본 LLM 팀(Multi-Agent) 아키텍처
Language Model Teams as Distrbuted Systems
TL;DR Highlight
LLM 여러 개를 팀으로 묶어 쓰는 Multi-Agent 시스템을 설계할 때, 수십 년간 쌓인 분산 컴퓨팅 이론을 원칙적 기반으로 활용하자는 논문이다. '언제 팀이 필요한가', '에이전트를 몇 개 써야 하는가' 같은 실전 질문에 답할 프레임워크가 없던 상황에서 체계적인 접근법을 제시한다.
Who Should Read
LLM Agent 또는 Multi-Agent 시스템을 설계·운영 중인 백엔드/AI 엔지니어, 또는 여러 LLM을 조합한 파이프라인 아키텍처를 평가해야 하는 기술 리더.
Core Mechanics
- Multi-Agent(LLM 팀) 시스템은 현재 '이렇게 해보고 안 되면 저렇게 해보는' 시행착오 방식으로 설계되고 있는데, 논문은 이 방식 대신 분산 컴퓨팅(Distributed Systems) 이론을 원칙적 토대로 쓰자고 주장한다.
- LLM 팀을 운영할 때 생기는 핵심 문제들 — 팀이 단일 에이전트보다 언제 유리한가, 에이전트를 몇 개 써야 하는가, 팀 구조(계층형·병렬형 등)가 성능에 어떻게 영향을 미치는가 — 에 대한 원칙적인 답이 아직 없다는 문제의식에서 출발한다.
- 분산 컴퓨팅에서 오랫동안 연구해온 장단점들(예: 병렬 처리의 이득 vs. 통신 오버헤드, 장애 허용, 일관성 문제)이 LLM 팀에서도 동일하게 나타난다고 주장한다. 즉, 바퀴를 다시 발명할 필요 없이 기존 CS 이론을 빌려올 수 있다.
- 논문은 분산 시스템 개념을 LLM 팀 평가 프레임워크로 활용하면 '이 구조가 왜 동작하는가/안 하는가'를 체계적으로 설명하고 예측할 수 있다고 본다.
- 저자들은 Princeton(Thomas L. Griffiths 연구실) 소속으로, 인지과학·ML 관점에서 멀티에이전트 시스템을 연구하는 팀이다. 2026년 3월 제출 논문이다.
- 논문의 핵심 기여는 새로운 알고리즘이나 벤치마크 숫자보다는, LLM 팀 설계를 위한 개념적·이론적 프레임워크 제공에 있다. 실무자가 팀 구조를 선택할 때 근거 있는 의사결정을 할 수 있도록 돕는 것이 목표다.
Evidence
- 한 댓글은 'Agent Swarm'이나 'Model Team' 트렌드 자체가 과대평가된 유행이라고 비판했다. '다른 에이전트'라는 것도 결국 LLM 쿼리에 다른 컨텍스트를 넣는 것에 불과하고, 에이전트 병렬화는 불필요하게 복잡성만 높인다는 의견이다. VC들이 좋아하는 키워드를 결합한 논문 소재라는 냉소적 시각도 있었다.
- 반면 다른 댓글은 에이전트를 루프로 두 개 이상 돌리는 순간 분산 시스템 문제(메시지 순서 보장, 재시도 로직, 부분 장애 처리 등)가 반드시 생긴다는 점을 지적했다. 그리고 현존하는 에이전트 프레임워크들은 이 문제를 부분적으로만 다루거나 아예 무시하고 있다며, 논문의 문제의식에 공감하는 시각을 보였다.
- 한 실무자는 자신들의 회사(HewesNguyen AI)가 MIS(경영정보시스템) 배경으로 LLM 팀을 설계하는데, Unix Philosophy(각 컴포넌트가 한 가지 일을 잘 하도록)를 팀 구성 원칙으로 쓰고 있다는 경험을 공유했다. 분산 시스템 원칙과 실무 설계가 자연스럽게 연결된다는 실사례다.
- 수학적으로 더 나아가 LLM을 π-calculus(프로세스 대수, 병렬 프로세스 간 통신을 모델링하는 이론)의 Actor/Process로 형식화하자는 아이디어도 반농담처럼 제시됐는데, 이는 분산 시스템 형식 이론과 LLM 팀의 접점에 대한 관심을 반영한다.
How to Apply
- 현재 여러 LLM 에이전트를 루프나 파이프라인으로 연결해 쓰고 있다면, 분산 시스템의 CAP 정리나 장애 허용 패턴(재시도, 타임아웃, 서킷브레이커)을 그대로 적용해볼 수 있다. 에이전트 간 메시지 순서가 보장되는지, 부분 실패 시 전체가 어떻게 동작하는지 점검하면 실제 운영 안정성이 올라간다.
- 새 Multi-Agent 아키텍처를 설계할 때 '에이전트를 몇 개 쓸까'를 직관으로 결정하지 말고, 분산 시스템에서 쓰는 성능 모델(Amdahl의 법칙 등 병렬화 이득 계산)을 참고해 병렬화 이득이 통신/조율 오버헤드보다 큰지 먼저 따져볼 수 있다.
- 에이전트 프레임워크(LangGraph, CrewAI 등)를 선택하거나 평가할 때, 해당 프레임워크가 메시지 순서 보장, 재시도, 부분 장애 격리 같은 분산 시스템 문제를 얼마나 해결하는지를 기준으로 비교하면 운영 중 겪는 디버깅 비용을 줄일 수 있다.
Terminology
Multi-Agent System여러 개의 LLM(또는 AI 에이전트)이 각자 역할을 맡아 협력하거나 병렬로 작업을 처리하는 시스템. 마치 여러 직원이 분업해서 일하는 것과 비슷하다.
Distributed Systems여러 컴퓨터(노드)가 네트워크로 연결돼 하나의 시스템처럼 동작하는 구조. 메시지 순서, 장애, 일관성 문제를 수십 년간 연구해온 CS 분야다.
Agent Swarm수많은 AI 에이전트를 벌떼처럼 동시에 투입해 문제를 푸는 접근. 병렬로 다양한 서브태스크를 처리하지만 조율 복잡도가 급격히 올라간다.
CAP Theorem분산 시스템에서 일관성(Consistency), 가용성(Availability), 분할 허용(Partition Tolerance) 세 가지를 동시에 만족할 수 없다는 이론. LLM 팀에서도 비슷한 트레이드오프가 발생한다.
π-calculus병렬로 동작하는 프로세스들이 서로 메시지를 주고받는 방식을 수학적으로 모델링하는 형식 언어. 멀티에이전트 시스템의 통신 구조를 이론적으로 표현할 수 있다.
Unix Philosophy'각 프로그램은 한 가지 일을 잘 해야 한다'는 설계 원칙. LLM 에이전트 팀 설계에서도 각 에이전트에 명확한 단일 역할을 부여하는 방식으로 응용된다.