멀티 에이전트는 거의 항상 필요 없다 — 9개월의 데이터
"멀티 에이전트 시스템" 이 2026년의 hype. 우리가 시도하고 *부서뜨린* 케이스 5개. *단일 에이전트 + 좋은 도구* 가 거의 항상 답인 이유.
2026년의 AI 에이전트 hype 한 줄 — "멀티 에이전트 시스템". 각자 다른 역할의 에이전트가 협력 해 복잡한 작업을 푸는 패턴.
지난 9개월 동안 우리는 멀티 에이전트 를 5번 시도했고 5번 모두 단일 에이전트로 후퇴. 이 글은 그 5 케이스의 분해와, 멀티 에이전트가 거의 항상 답이 아닌 이유.
5 케이스와 결과
케이스 1 — triage 에이전트 + diagnosis 에이전트 + remediation 에이전트
가설 — 인시던트 응답을 3 단계 에이전트 로 분리. 각자 전문가.
부서진 이유 — 컨텍스트 손실. triage 의 직관 이 diagnosis 에 전달 안 됨. 결국 diagnosis 가 처음부터 다시 분석. 단일 에이전트 + 3 도구 로 합쳐서 더 잘 작동.
케이스 2 — 코드 리뷰 에이전트 + 보안 에이전트 + 성능 에이전트
가설 — PR 검토를 3 영역 분리.
부서진 이유 — 동일 코드를 3번 읽음. 토큰 비용 3배. 그리고 연관 검토 (보안 + 성능 동시 영향) 가 분리되어 못 잡음.
케이스 3 — manager 에이전트 + worker 에이전트들
가설 — manager 가 작업 분해, worker 가 실행.
부서진 이유 — 조정 비용. manager 와 worker 사이 프롬프트 라운드 트립 이 작업의 비용 중 50%. 단일 에이전트가 직접 푸는 것보다 느림.
케이스 4 — plan 에이전트 + execute 에이전트
가설 — plan 단계와 execute 단계 분리.
부서진 이유 — plan 이 너무 추상 또는 너무 구체. 추상이면 execute 가 다시 plan, 구체면 plan 의 가치 X. 단일 에이전트 + system prompt 의 plan-then-execute 지시 가 더 정확.
케이스 5 — 언어별 에이전트 (한국어 vs 영어)
가설 — 한국어 사용자에게 한국어 에이전트, 영어에 영어 에이전트.
부서진 이유 — 번역 손실. 한국어로 정확히 표현된 의도가 영어 에이전트 시스템에 들어가면 부정확. 단일 모델 (다국어 지원) 이 더 정확.
5 케이스의 공통 원인
위 5 케이스 모두에서 멀티 에이전트가 부서진 공통 원인:
에이전트 간 통신 의 손실 + 비용 이 전문화의 가치 를 항상 압도한다.
각 에이전트가 LLM 호출이고, 통신이 자연어 (또는 JSON) 로 일어남. 그 직렬화-역직렬화-재해석 단계에서:
- 암묵적 컨텍스트 손실
- 프롬프트 토큰 곱셈 — 통신 비용
- 불일치한 가정 — A 에이전트와 B 에이전트의 세계관 차이
이 셋이 모두 전문화의 가치보다 큼. 항상.
멀티 에이전트가 답인 드문 케이스
거의 없지만 있긴 있다:
- 물리적 격리 필요 — 한 에이전트는 기밀 환경, 다른 에이전트는 비기밀. 같은 모델이 둘 다 보면 안 됨
- 시간적 분리 — 한 에이전트는 밤 에 동작, 다른 에이전트는 낮. 동일 컨텍스트 공유 안 됨
- 전혀 다른 모델 능력 — 한 에이전트는 코드 전문 모델, 다른 에이전트는 일반 모델. 단일 모델이 둘 다 충분히 잘하지 못함
이 셋 외에는 단일 에이전트 + 좋은 도구 가 답.
우리 답 — toolful agent
우리가 정착한 패턴 — 단일 에이전트가 많은 도구 를 가짐. 도구 = 함수. 함수 호출 = 명시적 transition.
이전 (multi-agent):
triage agent → handoff → diagnosis agent → handoff → remediation agent
이후 (toolful single agent):
agent
.tool(triage)
.tool(diagnose)
.tool(remediate)
.tool(check_history)
...15+ 도구를 가진 단일 에이전트가 3 에이전트보다 더 잘 작동. 6개월 데이터에서 명확.
누가 이 글을 읽으면 좋은가
지금 멀티 에이전트 시스템 을 설계 중 이거나 고려 중 인 모든 팀. 위 5 케이스 와 비슷한 가설이 있으면 멈춤. 단일 에이전트 + 도구 로 먼저 시도. 그게 안 될 때만 멀티 에이전트 검토. 거의 항상 그게 안 될 일이 없음.
비슷한 글
에이전틱 DevOps 12개월 후 — 첫 가설 중 무엇이 *맞았고* 무엇이 *틀렸나*
12개월 전 다음 10년의 DevOps는 에이전틱이다 의 가설들. 12개월의 데이터로 어느 가설이 맞고 어느 게 틀렸는지의 정직한 평가.
백재민
3 pillars 그 후 — 4 추가 신호의 *6개월 후* 운영 노트
3 pillars 가 더 이상 충분하지 않은 이유 발행 후 6개월. 4 추가 신호 (events / user journeys / deploy correlation / similarity) 가 운영에서 어떻게 작동했는지의 후속.
백재민
GitHub Actions vs 자체 호스팅 — *진짜 비용* 비교 (12개월 데이터)
GitHub Actions 가 *비싸 보임* 은 표면. 12개월 자체 호스팅 vs SaaS 비교 — 단순 *분당 비용* 이 아니라 *총 운영 비용* 으로.
백재민