실제 기업 업무에서 단일 에이전트 vs 멀티 에이전트 테스트 결과: 단일 에이전트가 10~20배 저렴하고 유일하게 정답을 맞혔다.
We tested single-agent vs multi-agent on a real enterprise task. Single agent was 10-20x cheaper and the only one that got the right answer.
핵심 요약
복잡한 기업 업무에서 멀티 에이전트의 정보 손실 문제를 확인했으며, 적절한 도구를 갖춘 단일 에이전트가 훨씬 효율적이고 정확함.
- 정보 손실 문제 — 멀티 에이전트 시스템은 작업 전달 과정에서 핵심 맥락이 사라져 추론 능력이 저하됨.
- 단일 에이전트 우위 — 적절한 도구와 충분한 컨텍스트가 주어지면 단일 에이전트가 더 저렴하고 정확한 결과를 도출함.
- 멀티 에이전트 한계 — 독립적이지 않은 작업에서 에이전트 간 의존성과 조정 비용이 성능을 저해함.
- 도구의 중요성 — 에이전트 수보다 MCP 서버나 코드 분석 도구 같은 적절한 도구와 컨텍스트 제공이 성공의 핵심임.
나는 오픈소스 멀티 에이전트 프레임워크를 만들고 있으며, 지난 몇 주간 실제 기업 솔루션 설계 작업에 이를 테스트해 보았다. 장난감 같은 벤치마크가 아니라, Jira 댓글, Java 소스 코드, 프로세스 흐름 구성 XML, Confluence 설계 문서를 교차 참조하여 정확한 기술 문서를 생성해야 하는 실제 기업 티켓 작업이었다.
설정은 다음과 같다:
- 4명의 전문 워커 에이전트(Jira 조사원, 코드 분석가, 구성 분석가, 문서 조사원)가 아키텍트 에이전트에 의해 조정되며, 합성 에이전트가 모든 것을 결합함
- 각 워커는 자신의 도메인에 집중된 MCP 도구를 보유
- 며칠에 걸쳐 4가지 다른 멀티 에이전트 구성 시도
멀티 에이전트의 결과(4회 시도):
| 시도 | 핵심 오류 |
|---|---|
| 1 | 존재하지 않는 속성을 지어냄 |
| 2 | 티켓을 완전히 다른 이니셔티브로 잘못 분류함 |
| 3 | 티켓의 실제 의도를 잘못 파악함 |
| 4 | 다른 티켓(이름이 비슷한)의 범위를 가져옴 |
각 시도는 다양한 도구와 에이전트에 걸쳐 30,000~70,000 토큰을 사용했다. 매번 다른 근본적인 오류가 발생했다.
단일 에이전트의 결과:
- 모든 도구(Jira + 코드 + CDT + Confluence + 출력)를 하나의 컨텍스트 윈도우에 넣은 에이전트 하나
- Kimi K2.6 (저렴한 모델, $0.73/1M 입력)
- 총 3,454 토큰만 사용
- 실제 문제를 정확히 식별하고, 올바른 코드 위치를 지정하며, 올바른 Jira 댓글을 인용하고, 수정 사항을 권장한 첫 번째 문서
완벽하지는 않았지만, 솔루션을 작동 가능하게 만드는 데 사소한 수정만 필요했다.
각 에이전트 수준에서 캡처된 모든 에이전트 로그와 추적을 바탕으로, 멀티 에이전트가 실패한 이유를 다음과 같이 이해했다:
이 작업은 여러 소스에 걸쳐 점들을 연결해야 했다. Jira 댓글에 클래스 이름이 언급되면 -> 그 클래스를 읽고 -> 그것이 구성 XML을 참조함을 찾고 -> 그 구성을 가져오고 -> 티켓이 변경하려는 동작을 제어하는 조건을 발견해야 한다. 이러한 추론 체인은 하나의 컨텍스트 윈도우에서 발생해야 한다.
하지만 멀티 에이전트에서는 이런 일이 벌어지고 있었다:
- 워커 A는 Jira 댓글을 찾지만 코드는 모름
- 워커 B는 코드를 읽지만 어떤 Jira 댓글이 중요한지 모름
- 워커 C는 프로세스 흐름 구성 XML을 가져오지만 어떤 코드 경로를 추적해야 할지 모름
- 아키텍트는 각 워커의 요약을 받아 연결하려고 하지만, 요약은 중요한 세부 정보를 잃어버림
정보가 모든 전달 과정에서 파괴되고 있다. 아키텍트는 실제 데이터의 그림자 위에서 추론하고 있으며, 전체 정보가 작업할 단일 컨텍스트에 없었기 때문에 많은 정보가 아예 가져와지지도 않았다.
이 경험을 통해 멀티 에이전트가 작동하지 않는 경우에 대한 통찰을 얻었다:
- 교차 소스 추론이 필요한 모든 것(솔루션 설계, 근본 원인 분석, 디버깅)
