구글·MIT 연구 — 멀티에이전트 도입하면 성능 70% 떨어지는 이유

요즘 AI 개발자들 사이에서 여러 에이전트를 복잡하게 엮는 '그래프 엔지니어링'이 큰 인기를 끌고 있습니다. 랭그래프 같은 도구를 써서 멀티에이전트 시스템을 구축하면 어떤 복잡한 업무든 척척 해결해 줄 것만 같지만, 현실은 조금 다릅니다. 최근 구글과 MIT 공동 연구진은 무작정 에이전트를 늘리는 설계가 오히려 성능을 최대 70%까지 떨어뜨릴 수 있다는 충격적인 결과를 발표했습니다.

구글과 MIT의 경고 — 순차적 고민에는 독이 된다

에이전트가 많을수록 더 복잡하고 어려운 일을 잘해낼 것 같지만, 실제로는 그렇지 않습니다. 구글 리서치와 MIT 미디어랩 공동 연구진이 총 180가지의 에이전트 구성을 설계해 테스트해 본 결과, 설계 방식에 따라 오히려 일의 효율이 극단적으로 떨어질 수 있다는 사실이 밝혀졌습니다.

특히 코딩이나 정밀 기획처럼 앞 단계의 결과가 뒷 단계에 영향을 주는 순차적 추론 작업에서 문제가 심각했습니다. 독립된 여러 에이전트가 차례로 일을 넘겨받는 과정에서 작은 실수가 다음 단계로 넘어가며 눈덩이처럼 불어났기 때문입니다. 그 결과, 단 하나의 에이전트만 쓸 때보다 성능이 최소 39%에서 최대 70%까지 곤두박질쳤습니다.

반면 데이터 수집이나 분산 처리처럼 서로 간섭 없이 독립적으로 처리할 수 있는 병렬 작업에서는 정반대의 결과가 나왔습니다. 각 에이전트에게 역할을 쪼개주고 결과를 한곳으로 모으는 중앙 통제형 그래프 구조를 사용하자, 성능이 무려 81%나 향상되었습니다.

결국 핵심은 무조건 멀티에이전트가 답은 아니라는 점입니다. 내가 해결하려는 문제가 꼼꼼히 한 단계씩 밟아가야 하는 일인지, 아니면 한 번에 펼쳐서 병렬로 처리할 수 있는 일인지에 맞춰 구조를 짜야 합니다.

에이전트 다이어트 — 쓸데없는 대화 줄이기

복잡하게 에이전트 개수를 늘려 구조를 꼬아놓는 대신, 단일 에이전트 내부의 실행 주기를 꼼꼼하게 다듬는 '루프 엔지니어링'이 대안으로 주목받고 있습니다. 에이전트 하나만 똑똑하게 관리해도 웬만한 복잡한 작업은 훨씬 안정적으로 끝낼 수 있기 때문입니다.

이때 핵심 해결사로 꼽히는 것이 바로 '에이전트다이어트(AgentDiet)' 기법입니다. 에이전트가 도구를 쓰고 작동하는 과정에서 쌓이는 불필요한 대화 기록이나 중복된 정보, 만료된 컨텍스트 데이터를 실시간으로 가지치기해 주는 원리입니다. 복잡한 일을 할 때 책상 위에 쌓이는 무의미한 낙서와 서류들을 그때그때 쓰레기통에 버려 집중력을 유지하는 것과 비슷합니다.

실제 학계 벤치마크 결과에 따르면, 이 기법을 적용했을 때 원래 성능은 100% 똑같이 유지하면서도 입력 토큰 사용량을 39.9%에서 최대 59.7%까지 획기적으로 줄였습니다. 덕분에 토큰 비용을 아끼는 것은 물론, 컨텍스트 창이 비대해져 에이전트가 엉뚱한 대답을 내놓는 고질적인 문제까지 깔끔하게 해결할 수 있습니다.

상태 관리와 속도의 거래 — 랭그래프의 지연 시간

많은 개발자가 랭그래프를 사랑하는 이유는 강력한 상태 보존 기능 덕분입니다. 복잡한 멀티에이전트 사이에서 대화 데이터나 작업 상태를 잃지 않고 꼼꼼하게 관리해 주기 때문입니다. 하지만 모든 편리함에는 예상치 못한 성능적 비용이 따르기 마련입니다.

인프라 벤치마크 데이터를 살펴보면, 랭그래프의 내부 조율 오버헤드가 실제 서비스 환경에서 무시할 수 없는 지연 시간을 만드는 것으로 나타났습니다. 가장 느린 케이스를 뜻하는 P95 지연 시간 기준으로 랭그래프는 약 16.8초를 기록한 반면, 러스트 기반의 고성능 에이전트 프레임워크인 오토에이전트(AutoAgents)는 약 9.6초에 불과했습니다.

초당 처리량에서도 차이가 뚜렷합니다. 오토에이전트는 초당 4.97회 요청을 처리하며 랭그래프의 2.70회보다 약 84% 높은 효율을 보여주었습니다. 랭그래프 자체의 기본 작동 오버헤드는 단 몇 밀리초 수준으로 매우 가볍지만, 여러 에이전트의 상태를 매번 추적하고 조율하는 과정이 복잡하게 얽히면 시스템 전체가 무거워집니다.

결국 잘못 설계된 멀티에이전트 그래프는 서비스 전체를 거대하고 느리게 만드는 '분산형 모놀리스'가 될 수 있습니다. 실시간 반응 속도가 중요한 서비스라면 무작정 복잡한 그래프 구조를 고집하기보다, 상태 저장이 꼭 필요한 핵심 흐름에만 랭그래프를 제한적으로 활용하는 균형이 필요합니다.

언제 그래프를 그리고, 언제 루프를 돌릴 것인가

에이전트 시스템을 설계할 때 기억해야 할 기준은 아주 명확합니다. 해결하려는 작업의 성격에 맞춰 구조를 단순화하는 것입니다.

첫 단계의 결과가 다음 단계의 입력이 되는 순차적 추론 작업에서는 단일 에이전트 루프를 최적화하는 편이 훨씬 낫습니다. 한 명의 똑똑한 에이전트가 스스로 질문하고 답을 다듬어 나가도록 꼼꼼하게 조율하는 것이 효율적입니다.

반면 서로 완전히 독립된 하위 업무들을 동시에 실행하고 마지막에 결과만 모으면 되는 병렬형 작업이라면 멀티에이전트 그래프가 활약할 차례입니다.

복잡한 시스템 지도부터 그리기 전에, 하나의 에이전트가 돌리는 루프의 효율을 먼저 극대화해 보는 것은 어떨까요? 때로는 군더더기 없는 단순한 설계가 가장 확실한 성공 공식입니다.