멀티 에이전트의 등장
지난 장 결론은 단순했다 — “한 명에게 다 시키면 망한다.” 그래서 나눈다. 는 그 나누는 행위에 이름을 붙인 것이다. 로 를 풀고, 으로 컨텍스트와 도구를 좁힌다.
단일 vs 멀티 — 아키텍처 한 장 비교
먼저 그림으로 본다. 단일 는 한 모델 + 한 컨텍스트 + 모든 다. 는 여러 모델이 좁은 역할로 쪼개지고, 각자 자기 컨텍스트와 자기 도구만 본다. 사이를 메시지가 흐른다.
한 사람의 머리를 키우는 게 아니라, 팀을 짠다.
분업이 풀어 주는 것
이 가져다 주는 게 무엇인지 한 줄씩 적는다. 셋 다 의 정반대 처방이다.
- 컨텍스트 분리 — 각 의 가 자기 일만 본다. 다른 역할의 흔적이 안 섞이니 가 짧고 정밀하다.
- 도구 분리 — 한 에이전트가 가진 도구가 3~7개로 좁혀진다. 잘못 고를 확률이 급감한다.
- 지시문 분리 — 가 단일 역할만 정의한다. 톤 충돌도 사라진다.
전문화가 정확도를 끌어올리는 메커니즘
는 “이 모델은 코드 리뷰만 한다”, “저 모델은 검색만 한다”처럼 역할을 좁히는 설계 원칙이다. 정확도가 오르는 이유는 두 가지.
- 이 좁아짐 — 가능한 이 적으니 옳은 한 수를 고르기 쉽다.
- 가 집중됨 — “이 한 역할만 잘하라”는 메시지가 명확해 모델이 헷갈리지 않는다.
거기에 컨텍스트가 짧으니 비용도 같이 떨어진다. 정확도와 비용 두 마리를 동시에 잡는다.
가장 단순한 멀티 에이전트 — 슈퍼바이저 한 줄 분배
본격 패턴은 11장에서 다루지만, 의 최소 코드는 의외로 짧다. 의 가장 간단한 형태다. 라우터 하나가 질문 유형을 분류해 좁은 전문가에게 넘긴다.
# Verified against: https://platform.claude.com/docs/en/docs/build-with-claude/tool-use
# Verified at: 2026-06-02
from anthropic import Anthropic
client = Anthropic()
def specialist(system_prompt, question):
"""역할 1개 + 도구 0개의 좁은 전문가 에이전트."""
r = client.messages.create(
model="claude-sonnet-4-6", max_tokens=400,
system=system_prompt,
messages=[{"role": "user", "content": question}],
)
return next(b.text for b in r.content if b.type == "text")
def supervisor(user_goal):
"""라우팅만 한다 — 라우팅도 LLM에 시킨다."""
route = specialist(
"다음 질문을 'research' 또는 'writing' 중 하나로만 답한다.",
user_goal,
).strip().lower()
if "research" in route:
return specialist("너는 사실 조사 전문가. 검색 결과만 요약한다.", user_goal)
return specialist("너는 글쓰기 전문가. 문체와 구조를 다듬는다.", user_goal)
print(supervisor("Transformer 논문의 핵심 기여 3개를 설명해 줘"))라우팅 1번 + 전문가 호출 1번 = 총 2회 호출. 단일 가 한 컨텍스트에 모든 역할을 넣는 것과 전혀 다른 패턴이다.
컨텍스트 효율을 숫자로
같은 작업을 두 아키텍처로 돌릴 때, 각 모델 호출이 보는 컨텍스트 크기가 어떻게 다른지 비교한다.
| 시나리오 | 단일 | (역할 3개) |
|---|---|---|
| 한 호출당 평균 토큰 | 많음 | 적음 |
| 노출 수 | 많음 | 적음 |
| 길이 | 김 | 짧음 |
| 정확도 | 낮음 | 높음 |
체감 비교다. 정량 수치는 도메인·모델·도구셋에 강하게 의존하므로 일반화된 출처를 제시하지 않는다.
호출 횟수는 더 늘지만 호출당 비용과 오류율이 떨어진다. 토큰 총합도 보통 줄어든다 — 같은 정보를 여러 번 안 읽으니까.
에이전트 팀의 형태들
을 짜는 방식은 한 가지가 아니다. 패턴은 11~15장에서 자세히 보지만, 아키텍처의 큰 그림 셋만 미리 본다.
- 슈퍼바이저 — 한 감독이 워커를 디스패치, 결과를 모은다. 가장 흔한 형태.
- 스웜 — 감독자 없이 끼리 핸드오프로 일을 넘긴다.
- 계층형 — 트리 구조 위임. 큰 조직 다이어그램처럼.
세 패턴 모두 역할이 좁다와 메시지로 협업한다 두 원칙은 공유한다. 의 형태만 다를 뿐 본질은 같다.
새로 생기는 비용들
는 공짜가 아니다. 단일 에이전트가 풀던 문제는 풀리지만, 그 자리에 새로운 종류의 문제가 들어선다. 솔직히 적어 둔다.
- 복잡도 — 누가 누구를 부르는지, 결과를 누가 모으는지 그래프가 늘어난다.
- 비용 — 메시지 직렬화·역직렬화, 통신 지연, 실패 처리 — 분산 시스템의 모든 골칫거리가 따라온다.
- 디버깅 난이도 — “왜 잘못된 답이 나왔는가”를 단일 모델 호출이 아닌 분산 트레이스로 봐야 한다.
- 합의 비용 — 두 에이전트가 다른 답을 냈을 때 누가 옳은가를 결정하는 추가 단계가 필요하다.
단일 에이전트의 “한 명이 망친다”가 멀티에선 “팀이 어긋난다”로 바뀐다. 다른 문제다.
협업의 비용을 줄이는 첫 단추
새 비용 중 가장 큰 오케스트레이션 복잡도는 보통 두 가지 손잡이로 줄인다. 두 번째가 다음 장의 주제다.
- 표준 메시지 포맷 — 모든 가 같은 메시지 구조를 쓰면 라우팅이 단순해진다.
- 프로토콜 — 호출·인증·발견을 표준화하면, 각자 다른 프레임워크로 만든 에이전트도 서로 부를 수 있다.
멀티 에이전트가 항상 답은 아니다
새 비용이 있다는 건 작은 문제에는 멀티가 과한 도구일 수 있다는 뜻이다. 단순 Q&A, 한두 개 도구로 끝나는 워크플로는 단일 가 더 빠르고 디버깅도 쉽다.
진짜 효과가 나는 건 이런 조건이 둘 이상 모일 때다.
- 이 넓어 이 임박했다.
- 여러 상충하는 역할이 필요해 가 보인다.
- 외부 시스템·에이전트와 교차 호출이 필요하다.
이 조건이 충족되면 멀티는 단일 대비 정확도·비용·유지보수성 모두에서 빠르게 우위를 잡는다.
의사 결정 체크리스트
설계 시작 단계에서 단일/멀티를 가르는 짧은 체크리스트.
| 질문 | YES → |
|---|---|
| 가 10개 이상인가 | 멀티 검토 |
| 역할이 상충하는가 (작성+비평 등) | 멀티 |
| 외부 를 부르는가 | 멀티 + 표준 프로토콜 |
| 워크플로 단계가 5개 이상인가 | 멀티 |
| 운영 인력이 있는가 | 멀티 가능 |
세 개 이상 YES면 멀티로 시작한다. 아니면 단일로 시작해서 한계 보일 때 쪼개도 늦지 않다.
다음 장으로
가 둘 이상이 되니 곧장 새 질문이 나온다 — 그들은 어떻게 서로에게 말을 거는가. 사내 호출이라면 함수 호출이지만, 회사·프레임워크가 다르면 표준이 필요하다.
다음 장에서는 그 표준의 첫 자리, 프로토콜이 무엇이며 왜 지금 필요해졌는지 살펴본다. 의 출발점이다.