AI 한 대보다 여러 대를 팀으로 묶으면 결과가 더 좋을 것 같지만, 실제 데이터는 정반대였다. 이탈리아 라퀼라대학교(University of L’Aquila)와 핀란드 아보아카데미대학교(Åbo Akademi University) 공동 연구진이 2026년 공개한 논문에 따르면, 여러 AI가 역할을 나눠 협업하는 멀티 에이전트 AI는 한 대가 통째로 처리하는 단일 에이전트보다 계산 비용을 훨씬 더 쓰고도 결과물 품질은 거의 같았다. 멀티 에이전트 AI란 기획, 작성, 검토 같은 역할을 여러 AI가 나눠 맡아 협업하는 구조를 말한다. 이 발견은 복잡하게 조합할수록 AI가 더 똑똑해진다는 업계 통념을 정면으로 반박한다.

단일 에이전트, 토큰 86% 아끼고 속도는 두 배

연구진의 핵심 결론은 단일 에이전트 방식이 멀티 에이전트와 비슷한 품질을 내면서 토큰을 86% 적게 썼다는 것이다. 실험 대상은 깃허브(GitHub) 저장소의 리드미(README) 파일 자동 생성이었다. 리드미란 개발자가 자신이 만든 소프트웨어의 목적과 설치 방법, 사용법을 정리해 두는 사용 설명서 격 파일이다. 이 문서를 AI에게 대신 쓰게 하는 실험에서, 여러 AI가 협업한 방식이나 한 대가 처리한 방식이나 완성된 설명서의 수준 차이는 크지 않았다.

토큰은 AI가 글을 읽고 쓸 때 소비하는 계산량의 단위이자 곧 사용료다. 토큰을 86% 아꼈다는 말은 같은 문서 한 건을 만드는 데 드는 비용이 7분의 1 수준으로 줄었다는 뜻이다. 저장소 하나를 처리할 때는 사소해 보이지만, 기업이 수천 개 저장소의 문서를 자동으로 관리한다면 이 차이는 곧 서버 비용과 처리 시간의 격차로 누적된다. 게다가 단일 에이전트는 멀티 에이전트보다 약 두 배 빠르게 작동했다. 복잡한 구조가 성능을 담보하지 않는다는 사실을 비용과 속도 양쪽에서 보여준 셈이다.

그림1. 멀티 에이전트 AI(56,242개)와 단일 에이전트(7,840개)의 총 토큰 사용량 비교. (출처: 해당 논문 Figure 4)

네 가지 방식 비교, 숫자로 드러난 반전

연구진은 단일 에이전트, 멀티 에이전트, 그리고 사람이 목차를 짜 준 개발자 주도 방식(Dev-Plan)을 기존 최고 성능 기술인 라치(LARCH), 그리고 사람이 직접 쓴 원본 리드미와 나란히 비교했다. 모든 실험에는 동일하게 gpt-5.1 모델을 사용했고, AI가 이미 학습해 둔 문서를 그대로 베끼지 못하도록 2025년 8월 이후 새로 만들어진 저장소만 대상으로 삼았다. 단일 에이전트와 멀티 에이전트는 모두 기존 기술인 라치보다 나은 문서를 만들어냈다.

품질 점수만 놓고 보면 방식별 우열이 뚜렷하게 갈렸다. 사람이 목차를 설계한 개발자 주도 방식이 10점 만점의 AI 심사에서 8.60점으로 가장 높았고, 멀티 에이전트가 7.55점, 단일 에이전트가 7.25점으로 뒤를 이었다. 항목을 빠뜨리지 않고 형식을 지키는 구조 정확도에서는 멀티 에이전트가 98.2%로 단연 앞섰고, 단일 에이전트는 77.6%에 그쳤다.

정작 눈에 띄는 대목은 사람이 직접 쓴 원본 리드미였다. 원본은 구조 정확도 72.4%에 실패율 17.5%로, 자동화 방식 가운데 어느 쪽보다도 낮았다. 사람이 쓴 설명서에는 설치 조건이나 사전 준비 사항 같은 필수 항목이 자주 빠져 있었기 때문이다. 사람의 손길이 항상 더 꼼꼼하리라는 기대가 데이터 앞에서 뒤집힌 지점이다.

협업 AI가 비싼 진짜 이유, 기획 단계의 병목

멀티 에이전트가 비용만 더 쓴 원인을 연구진은 기획 단계에서 찾았다. 여러 AI가 협업하는 구조에서는 맨 앞에 있는 기획 담당 AI가 먼저 문서의 목차와 방향을 짠다. 그런데 이 AI가 저장소의 특성을 제대로 반영하지 못한 뻔한 목차를 내놓으면, 그 뒤에 붙은 작성 AI와 검토 AI가 아무리 열심히 일해도 처음의 부실한 설계를 넘어서지 못했다. 잘못된 밑그림 위에서 이어지는 작업이 오류를 계속 물고 늘어지는 구조였다.

이 가설을 확인하려고 연구진은 기획 담당 AI를 빼고 그 자리에 사람이 직접 짠 목차를 넣어 봤다. 결과는 명확했다. 사람이 목차를 설계한 개발자 주도 방식은 필요한 항목을 빠뜨리지 않고 담아낸 비율인 재현율이 75.0%로 가장 높았고, LLM 심사에서도 8.60점으로 모든 방식 가운데 최고 품질을 기록했다. 구조적 실패는 1.25%까지 거의 사라졌다. 자율적인 AI 기획이 전체 시스템의 발목을 잡는 진짜 병목이었다는 뜻이다. 다만 이 방식은 사람이 세밀하게 짠 목차 탓에 검색과 작성, 검토가 더 많이 일어나 평균 79,196 토큰과 148초를 소비했다. 최고 품질에는 그만한 대가가 따랐다.

사람은 설계자, AI는 실행자라는 역할 분담

이 논문이 던지는 함의는 AI를 얼마나 복잡하게 쌓느냐가 아니라 사람이 어디에 개입하느냐가 품질을 가른다는 데 있다. 값비싼 멀티 에이전트 구조를 통째로 돌리기보다, 사람이 방향만 잡아 주고 실행은 AI에게 맡기는 조합이 가장 완성도 높은 문서를 만들어냈다. 다만 사람이 짠 세밀한 목차 탓에 계산 비용은 오히려 가장 많이 들었다. 연구진은 이를 사람이 전략적 설계자 역할을, AI가 실행 엔진 역할을 맡는 협업 모델이라고 표현했다.

다만 이 결과를 곧바로 모든 상황에 적용하기에는 아직 신중할 필요가 있다. 이번 실험은 오픈소스 저장소를 중심으로 이뤄졌고, 개발자 주도 방식은 사람이 매번 목차를 손수 만들어야 한다는 부담을 전제로 한다. 기업 내부의 폐쇄형 대규모 코드나 문서 특성이 크게 다른 분야에서도 같은 결론이 나올지는 더 지켜볼 필요가 있다. 그럼에도 무작정 구조를 복잡하게 만들기 전에 정말 그 복잡성이 값을 하는지 따져 봐야 한다는 메시지는, 문서 생성을 넘어 여러 AI 자동화 현장에 두루 통하는 질문으로 남는다.

FAQ( ※ 이 FAQ는 본지가 리포트를 참고해 자체 작성한 내용입니다.)

Q. 멀티 에이전트 AI와 단일 에이전트 AI는 무엇이 다른가요?
단일 에이전트는 AI 한 대가 작업 전체를 처리하는 방식이고, 멀티 에이전트는 기획, 작성, 검토처럼 역할을 나눈 여러 AI가 협업하는 방식입니다. 이번 연구에서는 멀티 에이전트가 형식은 더 정확했지만 비용이 훨씬 많이 들었습니다.

Q. 리드미(README) 파일이 왜 중요한가요?
리드미는 소프트웨어의 목적과 설치, 사용법을 정리한 설명서로, 다른 개발자가 그 프로그램을 이해하고 활용할 수 있게 해 주는 첫 관문입니다. 잘 정리된 리드미는 소프트웨어의 재사용과 협업을 크게 높입니다.

Q. 그렇다면 AI 자동화는 복잡할수록 좋은 건가요?
꼭 그렇지는 않습니다. 이번 연구는 구조를 복잡하게 만든다고 품질이 비례해 오르지는 않으며, 사람이 방향을 잡아 주는 개입이 오히려 비용과 품질을 함께 개선했다는 점을 보여줍니다.

기사에 인용된 리포트 원문은 arXiv에서 확인할 수 있다.
리포트명: The Illusion of Agentic Complexity in README.md Generation: Evaluating Single-Agent vs. Multi-Agent RAG Systems
이미지 출처: AI 생성 콘텐츠
해당 기사는 챗GPT와 클로드를 활용해 작성되었습니다.