멀티에이전트란 무엇인가 — 한 명의 만능보다 전문가 팀

한 줄 요약

멀티에이전트(Multi-Agent) 는 일을 역할별 전문 에이전트 여러 개에게 나눠 맡기고, 그 위에서 지휘자(Supervisor) 가 누구에게 무엇을 시킬지 정하는 구조입니다. 이 지휘 체계를 설계하고 운영하는 일을 오케스트레이션(Orchestration) 이라고 합니다.

1. 에이전트 하나로 다 하면 안 되나

됩니다. 그리고 처음에는 그렇게 만드는 것이 맞습니다. 이 과정에서도 17장까지는 에이전트 하나를 점점 키워 갑니다.

문제는 일이 늘어날 때 생깁니다. 에이전트 하나에 주문 조회, 재고 조회, 정책 검색, 배송지 변경, 교환 접수, 환불 요청, 상담원 접수, 본인 확인, 개인정보 보호, 말투 규칙을 전부 넣으면 이런 일이 벌어집니다.

지시문이 길어진다. 규칙이 서른 개쯤 되면 모델이 앞의 규칙을 놓치기 시작합니다.
도구가 많아진다. 비슷해 보이는 도구가 열 개쯤 되면 엉뚱한 도구를 고르는 일이 늘어납니다.
고치기가 무섭다. 정책 안내 문구 하나를 고쳤는데 배송 조회가 이상해집니다.
원인을 찾기 어렵다. 답이 틀렸을 때 어느 부분에서 틀렸는지 가려내기 힘듭니다.

사람의 조직도 같습니다. 신입 한 명에게 상담, 창고, 회계, 법무를 전부 맡기지 않습니다. 역할을 나누고, 각자 자기 일만 정확히 하게 합니다.

2. 역할을 나누면 정확해진다

멀티에이전트의 핵심은 각 에이전트가 좁은 일만 맡는다는 것입니다. 하루마켓에서는 전문 에이전트 셋을 둡니다.

전문 에이전트	성격	맡는 일	쓰는 것
주문조회 에이전트	읽기	주문·배송·상품·재고·고객 등급 확인	주문·상품·고객 데이터 조회 도구
정책안내 에이전트	읽기	반품·교환·환불·멤버십 규정에서 근거 조항 찾기	정책 문서 검색
요청처리 에이전트	쓰기	배송지 변경·교환 접수는 직접 처리, 환불·주문 취소는 승인 요청, 처리할 수 없는 일은 상담원에게 넘기기	처리 도구, 티켓 생성 도구

각 에이전트의 지시문은 짧고, 도구는 자기 일에 필요한 것만 들고 있습니다. 그래서 자기 일은 헷갈리지 않고 정확히 합니다. 정책안내 에이전트를 고쳐도 주문조회 에이전트는 영향을 받지 않습니다.

읽기만 하는 에이전트와 처리하는 에이전트를 나눈다

표의 "성격" 칸을 보세요. 앞의 둘은 읽기만 합니다. 몇 번을 불러도 하루마켓의 데이터는 달라지지 않습니다. 셋째만 쓰기를 합니다. 배송지를 바꾸고, 교환을 접수하고, 환불 승인 요청을 올립니다.

이렇게 나누는 이유는 정확도만이 아닙니다. 위험한 도구를 쥔 쪽을 하나로 좁히기 위해서입니다.

주문조회 에이전트와 정책안내 에이전트는 무엇을 잘못 판단해도 데이터를 바꿀 방법이 없습니다. 그런 도구를 받지 않았기 때문입니다.
무언가를 바꿀 수 있는 곳이 요청처리 에이전트 하나뿐이므로, 주의해서 살필 곳도 하나입니다. 처리해도 되는지 따지는 규칙, 처리 기록, 사람의 승인을 모두 이 한 곳에 겁니다.

3. 지휘자 — Supervisor

전문가가 셋 있으면 "이 문의를 누구에게 맡길지" 정하는 역할이 필요합니다. 이 역할을 Supervisor(지휘 에이전트) 라고 합니다.

Supervisor와 전문 에이전트

Supervisor는 직접 데이터를 조회하지 않습니다. 대신 이런 일을 합니다.

고객 문의를 읽고 무엇이 필요한지 판단한다.
알맞은 전문 에이전트에게 일을 맡긴다(이것을 위임이라고 합니다).
돌아온 결과가 충분한지 보고, 모자라면 다른 에이전트에게 또 맡긴다.
결과를 모아 고객에게 할 최종 답변을 만든다.

"지난주에 산 운동화가 불량이에요. 검정 270으로 교환 접수해 주세요."라는 문의 하나에 Supervisor는 세 에이전트를 차례로 부릅니다.

순서	부르는 에이전트	맡기는 일
1	주문조회 에이전트	"지난주에 산 운동화"가 어느 주문인지 찾는다
2	정책안내 에이전트	불량 상품의 교환 규정을 찾는다
3	요청처리 에이전트	그 주문을 검정 270으로 교환 접수한다

그리고 세 결과를 합쳐, 접수했다는 사실과 처리번호를 고객에게 답합니다. 그림에서 요청처리 에이전트 아래에 달린 사람의 승인은 환불·주문 취소처럼 되돌릴 수 없는 요청이 들어왔을 때 거치는 길입니다(23장).

우리가 매일 쓰는 AI 서비스도 안쪽은 이런 구조입니다. 하나의 대화창 뒤에서 검색 담당, 코드 실행 담당, 이미지 담당이 따로 움직이고, 그 위에서 누가 나설지를 정하는 지휘 체계가 있습니다.

4. 멀티에이전트의 대표 구조

멀티에이전트를 엮는 방법은 여러 가지입니다. 이 과정에서는 아래 세 가지를 직접 만들어 봅니다.

구조	생김새	이 과정에서
라우터(Router)	문의를 분류해 한 갈래로 보낸다. 갈림길 하나	19장
플래너-워커(Planner-Worker)	계획 담당이 일을 쪼개고, 실행 담당들이 나눠 처리한다	20장
Supervisor	지휘자가 상황을 보며 전문가를 부르고, 결과를 보고 다시 판단한다	21~22장

그리고 어느 구조든 빠지면 안 되는 것이 하나 더 있습니다.

사람에게 넘기기(Human-in-the-Loop) — 에이전트가 처리할 수 없는 일은 사람에게 넘기고, 되돌릴 수 없는 일은 사람의 승인을 받은 뒤에 실행합니다(23장).

5. 그렇다고 무조건 멀티에이전트가 답은 아니다

멀티에이전트에는 비용이 따릅니다.

느려진다. Supervisor가 판단하고, 전문 에이전트가 일하고, 다시 Supervisor가 정리합니다. LLM 호출이 여러 번 일어납니다.
비싸진다. 호출이 많으니 요금도 그만큼 듭니다.
전달하다가 정보가 빠진다. 사람끼리 인수인계할 때처럼, 에이전트끼리 넘길 때도 내용이 빠지거나 바뀝니다.

그래서 판단 기준은 이것입니다.

에이전트 하나로 충분히 정확하면 하나로 간다. 일이 많아져서 정확도가 떨어지기 시작할 때 나눈다.

이 과정이 처음부터 멀티에이전트를 만들지 않고, 에이전트 하나를 17장까지 키운 다음에 나누는 이유가 이것입니다. 왜 나눠야 하는지를 먼저 겪어 보고 나눕니다.

핵심 정리

멀티에이전트는 일을 역할별 전문 에이전트에게 나눠 맡기는 구조입니다.
하루마켓의 전문 에이전트는 주문조회(읽기), 정책안내(읽기), 요청처리(쓰기) 셋입니다. 읽기와 쓰기를 나눠 위험한 도구를 쥔 쪽을 하나로 좁힙니다.
에이전트 하나에 모든 일을 넣으면 지시문이 길어지고, 도구를 잘못 고르고, 고치기 어려워집니다.
Supervisor는 직접 일하지 않고, 누구에게 맡길지 정하고 결과를 모아 답합니다. 일을 맡기는 것을 위임이라고 합니다.
대표 구조로 라우터, 플래너-워커, Supervisor가 있고, 어디에나 사람에게 넘기는 길이 있어야 합니다.
멀티에이전트는 느리고 비쌉니다. 하나로 부족해질 때 나눕니다.