멀티 에이전트 시스템
여러 에이전트가 역할을 나눠 협업하는 멀티 에이전트 시스템의 환경·협업 유형·협업 전략·통신 구조를 구분하고, 단일 에이전트보다 나은 경우와 비용을 따진다.
- 멀티 에이전트 시스템(multi-agent system): 여러 LLM 에이전트가 각자 역할·도구·컨텍스트를 갖고 메시지를 주고받으며 하나의 작업을 함께 처리하는 구조.
- 11주 자율 에이전트가 "한 명의 직원"이라면 이번 주는 "팀"을 설계하는 문제. 에이전트를 나누면 컨텍스트도 나뉨.
슈퍼 에이전트와 전문가 팀
- 모든 일을 혼자 하는 "슈퍼 에이전트"의 문제: 지시문·도구가 많아져 선택 실수, 중간 결과가 쌓여 컨텍스트가 길어짐.
- 대안: 사람의 조직처럼 하위 작업을 전담 에이전트에게 맡김. 에이전트마다 역할·도구·지시문이 단순해지고, 서로의 실수를 잡을 수 있음.
| 비교 항목 | 단일 에이전트 | 멀티 에이전트 |
|---|---|---|
| 장점 | 단순함, 정보 손실 없음, 싸고 빠름 | 전문화, 병렬 처리, 상호 검토, 컨텍스트 분리 |
| 단점 | 긴 컨텍스트, 역할 과부하 | 토큰 비용, 조정 비용, 오류 전파 |
| 잘 맞는 작업 | 단계가 얽힌 작업(대부분의 코딩) | 나눠서 따로 할 수 있는 작업(넓은 조사), 독립 검토 |
분류
| 기준 | 유형 | 설명 |
|---|---|---|
| 환경 인터페이스 | 샌드박스(sandbox) | 가상 환경. 예: 코드 인터프리터, 게임 규칙 |
| 물리적(physical) | 실제 물체와 상호작용. 예: 로봇 | |
| 무 환경(none) | 에이전트끼리의 대화만 있음. 예: 토론 | |
| 협업 유형 | 협력(cooperative) | 같은 목표를 위해 정보 교환 |
| 토론(debate) | 각자 관점을 내고 방어해 더 나은 답을 찾음 | |
| 경쟁(competitive) | 각자 자기 목표 추구. 예: 경매, 협상 | |
| 협업 전략 | 규칙 기반(rule-based) | 정한 규칙(예: 돌아가며 발언). 예측 가능하지만 복잡한 과제에 약함 |
| 역할 기반(role-based) | 관리자·개발자 등 역할 수행. 모듈성이 좋지만 경직되고 에이전트 간 연결에 의존 → 역할 분담 | |
| 모델 기반(model-based) | 모델이 상황에 따라 결정. 유연하지만 설계가 어렵고 비쌈 → 오케스트레이션 |
출처: Guo 외(2024), Large Language Model based Multi-Agents: A Survey of Progress and Challenges, Tran 외(2025), Multi-Agent Collaboration Mechanisms: A Survey of LLMs
커뮤니케이션 구조
| 구조 | 방식 | 특징 |
|---|---|---|
| 계층(layered) | 같은 계층이나 인접 계층과 주로 통신 | 큰 조직에 적합 |
| 분산(decentralized) | 다대다 직접 통신 | 유연하지만 메시지 수가 에이전트 수의 제곱으로 늘고 종료가 어려움 |
| 중앙 집중(centralized) | 관리자를 거쳐 통신 | 이해·디버깅이 쉽지만 관리자가 병목 |
| 공유 메시지 풀(shared message pool) | 모두 게시하고 필요한 것만 구독 | 직접 대화 없이 산출물 공유 |
설계와 제약
-
설계 순서: 작업 분해 → 역할 정의 → 입출력 형식(구조화된 출력) → 순서·종료 조건 → 검증 단계.
-
토큰 비용: Anthropic의 조사 시스템에서 에이전트는 채팅보다 약 4배, 멀티 에이전트는 약 15배의 토큰을 씀. 단일 에이전트보다 90.2% 높은 성능이었지만 차이의 80%를 토큰 사용량이 설명 → 작업의 가치가 비용을 정당화할 때만 사용.
- 출처: Anthropic(2025), How we built our multi-agent research system
-
맥락 공유: 플래피 버드를 "배경"과 "새"로 나눠 맡겼더니 서로 어울리지 않는 결과가 나옴. 하위 에이전트의 행동에 담긴 암묵적 결정이 충돌하지 않게 맥락을 공유해야 함.
- 출처: Walden Yan(2025), Don't Build Multi-Agents
-
그 밖에: 디버깅이 어려움, 앞 단계의 오류가 뒤로 전파, 어느 에이전트의 책임인지 불분명.
-
적용 기준: 작업을 독립적으로 나눌 수 있을 때(병렬화), 독립 검토가 필요할 때, 한 에이전트가 맡은 역할·도구가 너무 많을 때.
이번 주에 다룰 내용
| 문서 | 주제 |
|---|---|
| 오케스트레이터와 하위 에이전트 | 관리자가 하위 에이전트를 도구처럼 호출, 병렬화, 컨텍스트 격리 |
| 토론과 합의 | 여러 에이전트가 답을 비교하고 고쳐 합의 |
| 역할 분담과 SOP | 기획자·개발자·리뷰어가 구조화된 문서로 일을 넘김 |
| LLM으로 사람 흉내내기 | 프로필을 준 에이전트로 설문 시뮬레이션 |
| 에이전트 기반 시뮬레이션 | 여러 에이전트의 상호작용에서 나타나는 사회 현상 |
퀴즈
복잡한 작업에서 단일 '슈퍼 에이전트' 대신 멀티 에이전트를 쓰는 주된 이유는?
퀴즈를 풀려면 대화형 기능을 불러와야 합니다.