멀티 에이전트 아키텍처, 무작정 쪼개면 망한다
모든 멀티 에이전트 패턴이 같지 않습니다. 서브에이전트, 스킬, 핸드오프, 라우터가 실제로 단일 에이전트를 이기는 시점을 시나리오와 수치로 정리했습니다.
“에이전트를 여러 개로 나누면 더 똑똑해질까?”
답은 “상황에 따라 다르다”입니다. Anthropic 연구에서 멀티 에이전트가 단일 에이전트보다 90% 더 나은 성과를 낸 건 맞지만, 그건 제대로 된 아키텍처를 선택했을 때 얘기입니다. 실무에서는 작업 유형에 따라 성능 차이가 극명하게 갈립니다.
3가지 대표 시나리오로 어떤 패턴이 언제 효율적인지 정리해봤습니다.
4가지 패턴 간단 요약
본론에 들어가기 전, 아키텍처를 빠르게 훑어보겠습니다.
- 서브에이전트(Subagents): 메인 에이전트가 특화 에이전트들을 도구처럼 호출. 병렬 실행에 강하지만 매번 메인을 경유해야 함
- 스킬(Skills): 단일 에이전트가 필요할 때만 전문 프롬프트를 로드. 가볍지만 컨텍스트가 누적됨
- 핸드오프(Handoffs): 단계별로 활성 에이전트를 교체. 순차 플로우에 특화되지만 병렬 실행 불가
- 라우터(Router): 쿼리를 분류한 뒤 병렬 실행하고 결과를 통합. 상태가 없어 대화 맥락을 유지하지 않음
이제 실제 시나리오로 들어가보겠습니다.
시나리오 1: 단발성 요청
“커피 사줘” - 사용자가 한 번만 요청하는 경우입니다. 전문 에이전트가 buy_coffee 도구를 호출할 수 있는 상황이죠.
성능 비교:
- 서브에이전트: 4번 콜 (메인 → 서브 → 도구 실행 → 메인 복귀 → 응답)
- 스킬 / 핸드오프 / 라우터: 3번 콜 (직접 실행)
핵심 인사이트: 단발성 작업은 상태 유지가 필요 없으니 스킬, 핸드오프, 라우터가 가장 효율적입니다. 서브에이전트는 결과가 메인을 거쳐야 해서 콜이 1번 더 발생하고, 이게 레이턴시로 직결됩니다. 단순 작업이면 굳이 멀티 에이전트 구조를 쓸 이유가 없습니다.
실무 적용: FAQ 봇, 단순 커맨드 실행, 일회성 데이터 조회는 단일 에이전트로도 충분합니다. 멀티 에이전트는 오버엔지니어링일 가능성이 높습니다.
시나리오 2: 반복 요청
“커피 또 사줘” - 같은 요청을 두 번 하는 경우입니다. 대화 맥락이 유지되는 상황이죠.
성능 비교 (2번째 턴 기준):
- 서브에이전트: 4번 콜 → 총 8번 (상태 없음, 매번 동일)
- 스킬 / 핸드오프: 2번 콜 → 총 5번 (40% 절감)
- 라우터: 3번 콜 → 총 6번 (25% 절감)
핵심 인사이트: 상태를 유지하는 스킬과 핸드오프가 압도적입니다. 이미 로드한 컨텍스트를 재사용하니까 라우팅이나 초기화 단계를 건너뛸 수 있습니다. 서브에이전트는 상태 없는 설계라 매번 풀 사이클을 돕니다. 대신 컨텍스트 격리는 확실하니, 보안이나 격리가 중요하면 이 오버헤드를 감수할 수 있습니다.
실무 적용: 챗봇, 대화형 도우미, 세션 기반 서비스는 상태 유지 패턴이 필수입니다. “이전에 했던 것처럼” 같은 요청이 잦으면 스킬이나 핸드오프를 우선 고려하세요. 라우터는 상태 유지 에이전트 안에 도구로 감싸면 해결 가능합니다.
시나리오 3: 멀티 도메인 쿼리
“Python vs JavaScript vs Rust 비교해줘” - 여러 전문 영역을 동시에 조회해야 하는 경우입니다. 각 언어당 약 2K 토큰의 참고 문서가 있다고 가정하겠습니다.
성능 비교:
- 서브에이전트: 5번 콜, ~9K 토큰 (각 서브가 격리된 컨텍스트에서 작업)
- 스킬: 3번 콜, ~15K 토큰 (3개 스킬 모두 메인 컨텍스트에 누적)
- 핸드오프: 7번+ 콜, ~14K+ 토큰 (순차 실행만 가능)
- 라우터: 5번 콜, ~9K 토큰 (병렬 실행)
핵심 인사이트: 병렬 실행이 가능한 서브에이전트와 라우터가 압도적입니다. 서브에이전트는 각 언어 문서를 격리된 컨텍스트에서 처리하니까 스킬 대비 토큰을 67% 덜 씁니다(9K vs 15K). 스킬은 콜 수는 적지만 3개 도메인 지식이 전부 메인 컨텍스트에 쌓이면서 토큰 비용이 급증합니다. 핸드오프는 순차 실행만 되니 이런 작업엔 최악입니다.
실무 적용: 리서치 시스템, 멀티 소스 비교 분석, 엔터프라이즈 지식베이스처럼 독립된 도메인 여러 개를 동시 조회해야 하면 서브에이전트나 라우터가 답입니다. 특히 대용량 도메인 지식을 다루면 컨텍스트 격리가 토큰 비용에 직접 영향을 줍니다.
패턴 선택 가이드
| 시나리오 | 추천 패턴 |
|---|---|
| 단발성 작업 | 단일 에이전트로 충분 |
| 반복 요청이 많음 | 스킬 또는 핸드오프 |
| 여러 도메인 동시 조회 | 서브에이전트 또는 라우터 |
| 순차 워크플로우 | 핸드오프 |
실전 팁
처음부터 멀티 에이전트로 가지 마세요. 단일 에이전트에 좋은 프롬프트와 잘 정의된 도구를 붙여서 시작하고, 명확한 한계가 보일 때 위 시나리오 기준으로 패턴을 선택하는 게 정답입니다.
Anthropic 연구의 교훈은 “에이전트가 많을수록 좋다”가 아닙니다. 올바른 작업에 올바른 아키텍처를 적용하는 것이 90% 향상을 만들어냅니다.
뉴스레터 구독하기
최신 프로젝트, 아티클, AI와 웹 개발 실험에 대한 소식을 받아보세요.