개요

30~32편은 에이전트 하나를 잘 만드는 이야기였다. 읽을거리를 주고(30편), 손을 달아주고(31편), 계획을 세우게 했다(32편).

그런데 이번 자료는 시작부터 방향이 다르다. 하나를 더 똑똑하게 만드는 대신, 여러 개를 붙여보자는 것이다.

에이전트를 여럿 두면 뭐가 달라지고, 그 사이는 무엇으로 채워야 하는가?

솔직히 처음엔 시큰둥했다. 하나도 제대로 안 도는데 여러 개를 붙인다고 나아지나 싶었다. 그런데 읽다 보니 예전에 게임 서버 만들면서 고민했던 것들이 그대로 나왔다. 중앙 서버를 둘 것인가, 노드끼리 직접 붙일 것인가. 문제가 판박이였다!

이번 편은 그 이야기다. 다음 편(34편)에서 도구 사용 학습과 추론 최적화를 이어서 다룬다.

교육 자료는 대외비라 슬라이드 이미지나 예제 데이터는 싣지 않는다. 개념만 다시 그려서 쓴다.

1. 왜 하나로는 부족한가 — 위로 못 키우면 옆으로

지금까지 성능을 올리는 방법은 하나였다. 모델을 키운다. 파라미터를 늘리고 데이터를 늘리면 성능이 올랐다.

그런데 그 방식이 슬슬 한계에 부딪혔다. 자료에서 개별 LLM의 본질적 한계로 세 가지를 든다.

한계 무슨 뜻인가
환각 현상 그럴듯한데 틀린 내용을 지어낸다
자기회귀적 성격 앞 단어를 보고 다음 단어를 찍는 구조라, 천천히 곱씹으며 신중하게 생각하지 못한다
스케일링 법칙 둔화 모델을 두 배로 키워도 성능이 두 배가 되지 않는다

세 번째가 핵심이다. 키우는 값이 점점 비싸지는데 얻는 건 점점 적어진다.

그래서 나온 발상이 수평적 확장이다. 하나를 크게 키우는(수직) 대신, 여러 개를 옆으로 붙인다.

서버를 스케일 업 할지 스케일 아웃 할지의 그 고민이, 모델에서 똑같이 반복되고 있었다!

더 쉬운 비유로

혼자서 논문을 쓰면 — 조사도 내가, 작성도 내가, 검토도 내가 넷이서 쓰면 — 조사하는 사람, 쓰는 사람, 번역하는 사람, 검수하는 사람 사람 사회는 이미 후자를 택했다

회사에서 일하는 방식을 생각하면 된다. 아무리 뛰어난 사람이라도 혼자 기획하고 개발하고 디자인하고 QA까지 하지 않는다. 나눠서 하고, 서로 검토한다. 다중 에이전트 시스템은 이걸 그대로 흉내 낸 것이다.

자료의 표현으로는 “개별 에이전트 능력의 총합을 뛰어넘는 집단 지성”을 노린다. 다만 이건 목표지 결과가 아니다. 뒤에서 볼 텐데, 잘못 붙이면 총합보다 못한 것도 쉽게 나온다..

2. 부품 네 개 — 무엇이 있어야 시스템인가

에이전트를 여러 개 띄웠다고 다중 에이전트 시스템이 되는 건 아니다. 자료는 필요한 구성 요소를 네 개로 정리한다.

구성 요소 무엇인가 안 정하면
에이전트 역할·능력·행동·지식 모델을 가진 행위자 누가 무슨 일을 하는지 모른다
환경 에이전트가 존재하고 인식·행동하는 외부 세계 어디서 무슨 일이 벌어지는지 모른다
상호작용 표준화된 프로토콜을 쓰는 에이전트 간 소통 말은 하는데 서로 못 알아듣는다
조직 계층 구조로 관리되거나, 자발적 행동으로 조직됨 결정을 누가 내리는지 모른다

32편에서 봤던 환경이 여기서도 그대로 나온다. 그때는 에이전트 하나가 환경을 어떻게 보느냐(텍스트/이미지/접근성 트리)의 문제였는데, 여기서는 여럿이 같은 환경을 공유한다는 게 추가된다.

내가 보기에 진짜 어려운 건 3번과 4번이다. 1번과 2번은 하나짜리 에이전트를 만들 때도 이미 고민하던 것이고, 여럿이 되면서 새로 생기는 문제는 소통과 조직이다.

부품 넷 중 둘은 원래 있던 것이고, 둘은 여럿이 되면서 새로 생긴 것이다. 그래서 뒤의 세 절이 전부 그 둘 이야기다.

3. 협업 유형 — 편을 먹일 것인가, 붙일 것인가

에이전트 사이를 무엇으로 채우느냐. 자료는 세 가지로 나눈다.

다중 에이전트의 세 가지 협업 유형

① 협력 — 목표를 하나로 맞춘다

각자의 개별 목표를 공동의 집단 목표와 일치시킨다. 학술 문서를 쓰는 시스템이 예시로 나오는데, 조사·작성·번역·검수를 나눠 맡는 식이다.

장점은 명확하다. 각자 자기 전문 분야의 세부 작업에만 집중하면 된다.

단점도 명확하다. 두 가지가 걸린다.

  • 통신 비용 — 에이전트끼리 자주 주고받으면 계산 비용과 복잡성이 같이 오른다
  • 연쇄 오염 — 하나가 틀리면 그 결과를 받은 나머지가 전부 물든다

두 번째가 무섭다. 각 에이전트의 성공률을 $p$라 하고 결과를 이어받는 구조로 $N$개를 붙이면, 전체가 성공할 확률은

$$ p^N $$

이 된다. 개별이 95%짜리여도 다섯을 이어 붙이면 $0.95^5 \approx 0.77$ 이다. 하나하나는 꽤 괜찮은데 붙여 놓으면 넷 중 하나꼴로 망한다.

자료가 든 최악의 사례가 무한 대화 루프와 환각 증폭이다. A가 지어낸 내용을 B가 사실로 받아 쓰고, 그걸 다시 A가 근거로 삼는다. 아무도 안 멈춘다..

협력의 위험은 “일을 못 한다”가 아니라 “틀린 걸 서로 확인해준다”는 데 있다.

② 경쟁 — 일부러 부딪히게 둔다

반대로 각자의 개별 목표를 우선시하게 두는 방식이다. 서로의 목표가 충돌한다. 법정 시뮬레이션이 예시로 나오는데, 검사 역할과 변호인 역할을 각각 맡기는 식이다.

이게 왜 좋은가. 고도의 추론을 강제하기 때문이다. 상대가 내 논리의 허점을 찌르니, 찔리지 않으려면 더 촘촘하게 생각해야 한다. 각 에이전트 능력의 한계를 시험해서 시스템 전체의 적응성을 높인다.

단점은 두 개다.

  • 끝나지 않는 논쟁 — 멈추는 조건을 안 정해두면 영원히 싸운다
  • 가성비 의심 — 자료가 정직하게 적어뒀는데, 경쟁 구조는 프롬프트를 잘 쓴 단일 에이전트에게 따라잡힐 수도 있다

마지막 줄이 인상적이었다. 강의 자료가 자기가 소개하는 방법의 김을 빼는 경우는 잘 없다.

③ 협력 + 경쟁 — 싸우게 두되 결론은 함께

두 개를 섞는다. 특정 작업에서는 협력하고 다른 작업에서는 경쟁하게 만든다. 정책 결정 시스템이 예시다.

여기서 익숙한 이름이 나온다. 전문가 혼합(Mixture-of-Experts, MoE)이다. 여러 전문가 모델이 최종 결과물에 기여하려고 경쟁하고, 게이트 시스템이 입력마다 최적의 전문가를 골라낸다. 협력과 경쟁 관계가 모델 학습 과정에서 먼저 형성되고, 그 과정에서 각자 데이터의 서로 다른 측면에 특화되도록 훈련된다.

MoE를 모델 구조로만 알고 있었는데, 협업 전략의 한 사례로 다시 보니 성격이 달라 보였다.

4. 협업 전략 — 규칙을 줄 것인가, 역할을 줄 것인가

유형을 정했으면 이제 어떻게 붙일지를 정해야 한다. 자료는 두 가지 프로토콜을 든다.

  규칙 기반 역할 기반
미리 정하는 것 주고받는 절차 각자의 직함과 책임
기반 명시적 규칙 도메인 지식
비유하면 회의 진행 규칙서 팀의 직무 분장표
강한 곳 합의 도출, 경로 찾기처럼 절차가 명확하고 변동성이 적은 일 소프트웨어 개발처럼 역할이 이미 나뉘어 있는 일
덤 시스템 동작을 특정 규칙에 연결하기 쉬워 디버깅이 편하다 서로의 결과를 전문가로서 검증할 수 있고, 모듈 재사용이 된다

역할 기반 쪽 대표 사례가 MetaGPT다. 이름 그대로 소프트웨어 회사를 통째로 흉내 낸다. 프로덕트 매니저가 요구사항 문서를 쓰고, 아키텍트가 시스템 설계를 하고, 프로젝트 매니저가 작업을 쪼개고, 엔지니어가 코드를 짜고, QA 엔지니어가 테스트한다. 사람이 넣는 건 한 줄짜리 요구사항 하나다.

재밌는 건 이게 사람 조직의 표준 작업 절차(SOP)를 그대로 옮긴 구조라는 점이다. 새 방법을 발명한 게 아니라 이미 있던 것을 베꼈다.

규칙 기반은 말하는 방법을 정하고, 역할 기반은 말하는 사람을 정한다.

디버깅 관점에서는 규칙 기반이 유리하다고 적혀 있는데, 이건 겪어보면 바로 납득이 된다. 뭔가 이상하게 돌 때 “몇 번 규칙에서 어긋났나”를 볼 수 있는 것과, “쟤가 왜 저랬는지 모르겠다” 사이의 차이다..

5. 커뮤니케이션 구조 — 사장을 둘 것인가

이제 마지막 축이다. 말이 어디를 거쳐 오가느냐.

중앙집중형과 탈중앙화 구조

중앙집중형 — 가운데를 둔다

서비스 에이전트가 참여자들 사이의 소통과 협력을 관리·제어·조율한다. 참여자-서비스 제공자 구조다.

자료에 나온 중앙 에이전트 사례가 둘이다. 하나는 LLM-블렌더 — 한 라운드에서 서로 다른 LLM들을 호출하고, 두 개씩 비교해 순위를 매긴 뒤, 최상위 응답들을 결합한다. 다른 하나는 토론의 판사 에이전트다.

탈중앙화 — 서로 직접 말한다

통제와 의사결정을 분산한다. 각 에이전트는 이웃과의 제한적인 통신과 일부 정보만 가지고 움직인다.

장점은 장애 격리다. 일부 에이전트가 실패해도 시스템이 계속 기능한다. 높은 확장성을 제공하고, 시스템 변화에 자율적으로 적응한다.

단점은 통신량이다. $N$개 에이전트가 서로 직접 붙으면 채널 수가

$$ \frac{N(N-1)}{2} $$

가 된다. 넷이면 여섯 개, 열이면 마흔다섯 개다. 에이전트를 두 배로 늘리면 대화 경로는 네 배가 된다. 그리고 그 정교한 조율을 위한 알고리즘이 따로 필요해진다.

중앙집중형은 가운데가 죽으면 전부 죽고, 탈중앙화는 아무도 안 죽는 대신 아무도 책임지지 않는다.

더 쉬운 비유로

중앙집중형 — 팀장한테 다 보고하고 팀장이 정리해서 나눠준다 탈중앙화 — 팀원끼리 각자 알아서 말한다 팀장이 휴가 가면 어떻게 되는가, 팀원이 열 명이면 단톡방이 몇 개가 되는가

예전에 게임 서버 다중화하면서 겪었던 게 딱 이거였다. 게이트웨이를 하나 두면 관리는 편한데 거기가 터지면 다 터진다. 그래서 여러 대로 늘렸더니 이번엔 서버끼리 상태를 맞추는 게 새 문제가 됐다. 여기서도 똑같은 자리에 똑같은 문제가 있다!

6. 에이전트형 RAG — 여럿을 붙인 가장 가까운 사례

여기까지가 분류였다. 협업 유형이 셋, 전략이 둘, 통신 구조가 둘. 그래서 실제로 뭘 만드는가가 안 나왔다.

자료가 그 자리에 놓는 게 에이전트형 RAG다. 30편에서 본 그 RAG가 맞는데, 한 군데가 바뀌었다.

30편에서 RAG 파이프라인을 세 걸음으로 정리했었다. 검색하고, 붙이고, 생성한다. 순서가 고정돼 있다. 그래서 6절에서 깨지는 지점을 넷이나 봤다. 검색 노이즈가 껴도 그대로 들어가고, 한 번 가져온 게 부실해도 다시 가져올 방법이 없다.

에이전트형 RAG는 그 파이프라인의 각 단계를 에이전트가 조율하게 만든다. 에이전트가 새로 갖게 되는 결정이 넷이다.

결정 고정 파이프라인에서는 에이전트가 쥐면
검색 여부 무조건 검색한다 아는 거면 그냥 답한다
도구 선택 벡터 검색 하나 벡터 검색·웹 검색·계산기·API 중에 고른다
쿼리 생성 사용자 질문 그대로 검색에 맞게 다시 쓴다
결과 평가 없다 부실하면 다시 검색한다

검색이 파이프라인의 한 칸에서 에이전트가 내리는 결정으로 바뀌었다. 30편에서 RAG를 “기억하지 못하는 검색 엔진”이라 불렀던 그 지점이 여기서 풀린다.

그래서 검색기를 몇 개 둘 것인가

단일 라우터형과 멀티 에이전트형 RAG

단일 에이전트형(Router) — 리트리버 에이전트 하나가 도구 전부를 쥔다. 질문을 보고 벡터 검색 A로 갈지, B로 갈지, 웹 검색으로 갈지, 계산기로 갈지 라우팅만 한다. 이름이 라우터인 이유다.

멀티 에이전트형 — 마스터 리트리버 아래에 리트리버 A·B·C를 두고 도구를 나눠 맡긴다. A는 사내 문서 벡터 검색, B는 웹 검색, C는 Slack·Gmail 같은 식이다.

3~5절에서 본 분류를 여기에 대보면 성격이 바로 잡힌다.

축 멀티 에이전트형 RAG는
협업 유형 협력 — 목표는 하나, 정보원을 나눈다
협업 전략 역할 기반 — 각자 맡은 도구가 곧 직함이다
통신 구조 중앙집중형 — 마스터가 조율한다

그리고 3절에서 봤던 위험이 그대로 따라온다. 리트리버 하나가 엉뚱한 걸 가져오면 그 오염이 최종 답까지 간다. 검색기를 나눴다고 검증이 붙는 건 아니다.

다음 편으로 넘어가는 다리

자료가 이 멀티 구조 그림을 띄워놓고 질문을 하나 던진다. 여러 모듈 중 어느 것이 가장 영향력이 큰가? 그러고는 리트리버 에이전트들에 빨간 박스를 친다.

즉, 도구를 나눠 맡기는 것까지는 구조의 문제였는데, 그 하나하나가 적절한 때에 적절한 도구를 부르게 만드는 것은 별개의 문제라는 얘기다.

구조를 잘 짜도 각 에이전트가 도구를 못 쓰면 소용없다. 다음 편(34편)이 정확히 그 이야기다.

7. A2A — MCP가 손을 규격화했다면, 이건 대화를 규격화한다

31편에서 MCP를 봤다. 모델마다 도구 쓰는 형식이 제각각이라 $M$개 앱과 $N$개 도구를 붙이려면 $M \times N$개의 개별 통합이 필요했는데, 가운데 규격을 하나 두어

$$ M \times N \to M + N $$

으로 줄인 것이었다. 그런데 이번 자료에는 그 옆에 처음 보는 게 하나 더 있었다. Agent2Agent(A2A) 프로토콜이다.

MCP와 A2A의 층 차이

목표가 뚜렷하다. 여러 AI 에이전트가 내부 메모리, 사고 과정, 도구를 직접 공유하지 않고 — 맥락, 작업 업데이트, 지시사항, 데이터만 교환해서 협업하게 한다.

이 문장이 이 절의 전부다. 안 주는 것의 목록이 더 중요하다.

  MCP A2A
잇는 대상 에이전트 ↔ 외부 도구 에이전트 ↔ 에이전트
주고받는 것 도구 호출과 그 결과 맥락, 작업 진행 상황, 지시, 데이터
주지 않는 것 — 내부 메모리, 사고 과정, 도구 자체
구성 요소 호스트 / 클라이언트 / 서버 에이전트 서버 / 클라이언트 에이전트 / 라우터

구성 요소를 보면 MCP와 모양이 거의 같다. 에이전트 서버가 개별 에이전트를 호스팅하고, 클라이언트 에이전트가 여러 에이전트 서버로 연결하고, 라우터가 쿼리를 적절한 에이전트로 전달한다.

내가 헷갈렸던 게 여기였다. 둘 다 “표준 규격”이고 구조도 비슷한데 왜 따로 있나. 정리하고 나니 답이 나왔다. 층이 다르다. MCP는 아래(도구)로 내려가는 통로고, A2A는 옆(동료)으로 가는 통로다.

캡슐화를 프로토콜로 못 박은 것이다. 동료에게 결과는 주되 머릿속은 안 보여준다.

이게 왜 중요한가 하면, 안 그러면 3절에서 본 환각 증폭이 그대로 터지기 때문이다. 남의 사고 과정을 통째로 받으면 그 사람의 착각까지 같이 받는다. 결과와 근거만 받으면 최소한 내가 다시 판단할 여지가 남는다.

8. 그래서 좋기만 한가 — 자료가 적어둔 우려

자료 마지막에 “다중 에이전트 시스템에 대한 우려의 시사점”이 붙어 있다. 세 가지다.

  • 확장성 — 성능 저하 없이 더 큰 에이전트 네트워크를 처리하려면 확장 가능한 아키텍처와 알고리즘이 필수다
  • 최적 협업 전략 — 작업 요구사항에 맞는 전략을 고르는 게 주요하다. 아무 전략이나 붙이면 안 된다
  • 적응 가능한 역할·경로 할당 — 환경과 목표가 바뀌면 역할과 협업 경로도 바뀌어야 한다

한 줄로 줄이면 이렇다. 여럿을 붙이는 것 자체는 답이 아니고, 어떻게 붙일지가 답이다.

34편에서 볼 내용을 미리 하나만 당겨오면, 실제 측정치가 이 우려를 뒷받침한다. 단일 에이전트는 표준 질의응답보다 약 4배, 멀티 에이전트는 약 15배 토큰을 쓴다. 성능이 15배 좋아지지는 않는다.

다중 에이전트는 성능 개선 기법이 아니라 비용을 성능으로 바꾸는 환율에 가깝다. 환율이 유리한 작업에서만 써야 한다.

정리

  • 왜 여럿인가 — 모델을 키우는 수직 확장이 둔화되니, 여러 개를 붙이는 수평 확장으로 방향을 틀었다
    • 개별 LLM의 한계 셋 — 환각, 자기회귀적 성격(천천히 신중하게 생각 못 함), 스케일링 법칙 둔화
  • 구성 요소 넷 — 에이전트 / 환경 / 상호작용 / 조직. 뒤의 둘이 여럿이 되면서 새로 생긴 문제다
  • 협업 유형 셋
    • 협력 — 목표를 하나로. 대신 오류가 연쇄되고 무한 루프·환각 증폭 위험
    • 경쟁 — 목표를 충돌시켜 추론을 날카롭게. 대신 끝나지 않는 논쟁, 좋은 단일 프롬프트에 따라잡히기도
    • 협력+경쟁 — 섞는다. MoE가 이 구조의 사례
  • 협업 전략 둘 — 규칙 기반(절차를 정한다, 디버깅이 쉽다) vs 역할 기반(직함을 정한다, MetaGPT가 SOP를 그대로 옮김)
  • 통신 구조 둘 — 중앙집중형(명확하지만 가운데가 병목이자 단일 장애점) vs 탈중앙화(견고하고 확장되지만 채널이 $N(N-1)/2$로 폭발)
  • 에이전트형 RAG — 30편의 고정 파이프라인과 달리 검색 여부·도구 선택·쿼리 생성·결과 평가를 에이전트가 결정한다
    • 단일(Router) — 리트리버 하나가 도구 전부를 쥐고 라우팅만 / 멀티 — 마스터 아래 리트리버들이 도구를 나눠 맡는다
    • 멀티형을 분류에 대보면 협력 + 역할 기반 + 중앙집중형이다. 그래서 오류 연쇄 위험도 그대로 따라온다
  • A2A — 에이전트 사이의 표준. 맥락·작업 상황·지시·데이터만 교환하고 내부 메모리·사고 과정·도구는 공유하지 않는다
    • MCP는 아래(도구)로, A2A는 옆(동료)으로 — 층이 다르다
  • 남은 우려 — 확장성, 최적 전략 선택, 적응 가능한 역할 할당. 붙이는 것 자체가 답이 아니다
  • 겹치는 글 — 검색은 30편, 도구와 MCP는 31편, 계획과 ReAct는 32편

참고 자료

한줄 평

  • 다중 에이전트가 대단한 신기술인 줄 알았는데 뜯어보니 예전에 서버 다중화하면서 겪었던 고민이 그대로 올라와 있어서, 새 걸 배웠다기보다 아는 문제가 다른 층에서 반복되는 걸 확인한 하루였다!