멀티 에이전트는 거의 항상 필요 없다 — 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 케이스 중 하나와 비슷한지 먼저 확인. 비슷하면 멈춤. 단일 에이전트 + 도구로 먼저 시도하고, 그게 안 될 때만 멀티 에이전트 검토. 6개월 데이터 기준, 그게 안 될 일이 거의 없다.
비슷한 글
기획자가 코드를 배포하면, 장애는 누가 책임질까
AI로 제품 담당자가 직접 코드를 만들고 여러 에이전트가 동시에 작업하는 조직에서, 운영에 나가는 변경을 누가 무엇으로 확인해야 하는지. NIST SSDF, SLSA provenance, Google SRE 포스트모템 문화를 근거로 작성자와 분리된 검증·승인·복구의 역할 설계를 정리했다.
백재민
에이전트 시대의 Eclipse 플러그인 — 작업 컨텍스트는 20년 전에도 문제였다
Mylyn 이 2000년대에 풀려던 문제와 지금 에이전트 컨텍스트 문제는 같습니다. 달라진 건 그 컨텍스트를 읽는 쪽에 사람만 있는 게 아니라는 점입니다.
김영상
에이전트 시대의 VS Code 확장 — 개발자는 에디터에서 무엇을 보는가
코드 작성 비용이 무너진 뒤 개발자의 시간은 판단과 승인으로 옮겨갔습니다. 그 일들이 왜 에디터 밖에 있으면 안 되는지, VS Code 확장을 만들며 내린 선택들.
이승백