복잡한 멀티에이전트가 늘 좋은 것은 아니다

제일 먼저 든 생각

요즘 에이전트 워크플로를 설계하다 보면 묘한 압박이 생긴다. 역할을 나누고, 오케스트레이터를 두고, 리뷰어 에이전트를 붙이고, 다시 쓰기 루프를 만들면 더 “진짜 자동화”처럼 보인다. 그런데 이 논문은 그 직감을 한 번 멈춰 세운다. 복잡한 멀티에이전트 구조가 항상 더 좋은 결과를 내는 것은 아니라는 것이다.

연구진은 GitHub 저장소의 README.md 자동 생성을 대상으로 단일 에이전트 RAG, 멀티에이전트 시스템(MAS), 그리고 사람이 계획안을 넣어주는 개발자 가이드 방식(Dev-Plan)을 비교했다. 결론은 단순하지 않다. 단일 에이전트는 비용과 속도에서 강했고, 멀티에이전트는 구조적 완성도에서 장점이 있었으며, 사람이 계획을 넣은 방식은 품질은 가장 좋았지만 비용이 컸다.

이 논문의 실무적 질문은 “에이전트를 몇 개 쓸 것인가”가 아니라 “어느 단계에 구조와 사람의 계획이 필요한가”에 가깝다.

같은 RAG라도 구조가 비용을 바꾼다

논문은 180개 GitHub 저장소를 대상으로 실험했다. 저장소별 코드를 언어 인식 방식으로 나누고, 임베딩과 벡터DB를 통해 README 생성에 필요한 맥락을 검색했다. 비교한 방식은 크게 세 가지다.

• 단일 에이전트 RAG: 검색된 맥락을 하나의 프롬프트에 모아 README를 생성한다.
• 멀티에이전트 RAG: 프로파일러, 플래너, 섹션 작성자, 리뷰어, 집계자 역할을 나눠 README를 만든다.
• Dev-Plan: 멀티에이전트 구조는 유지하되, 플래너 에이전트 대신 사람이 섹션 계획안을 제공한다.

여기서 중요한 것은 멀티에이전트가 “더 인간처럼 보인다”는 인상이 아니라, 구조가 비용과 실패 양상을 바꾼다는 점이다. 멀티에이전트는 섹션별 생성과 리뷰를 반복하므로 토큰과 시간이 늘어난다. 대신 문서 구조를 더 잘 지키는 경향이 생긴다.

단일 에이전트는 생각보다 강하지만, 문서 구조에서 약해진다

“단일 에이전트 방식은 멀티에이전트 품질과 맞먹으면서 토큰을 86% 적게 사용했다.”

Original: “The single-agent approach is the most cost-efficient solution, matching MAS quality while using 86% fewer tokens.”

실험 결과에서 단일 에이전트는 ROUGE-L F1 기준으로 완전 자율 멀티에이전트보다 약간 높았다(0.2007 vs. 0.1964). 평균 토큰 사용량은 단일 에이전트가 7,840개, 멀티에이전트가 56,242개였다. 시간도 단일 에이전트는 평균 40초, 멀티에이전트는 78초였다.

하지만 이 결과만 보고 “그냥 단일 에이전트가 답”이라고 말하면 부족하다. 논문이 별도로 본 구조 평가에서는 단일 에이전트가 필요한 섹션을 빠뜨리는 경향이 있었다. 12개 README 섹션 분류 체계를 기준으로 한 수동 커버리지에서 단일 에이전트의 재현율은 49.2%에 그쳤다. 한 번에 잘 쓰는 능력과 필요한 구조를 빠짐없이 채우는 능력은 다르다.

사람이 계획을 넣으면 품질은 오르지만, 공짜는 아니다

Dev-Plan 결과도 흥미롭다. 사람이 섹션 계획안을 먼저 제공하자 ROUGE-L F1은 0.2323, BERTScore F1은 0.8230으로 가장 높았다. LLM-as-a-Judge 평균 점수도 8.60으로 좋았다. 다만 평균 토큰은 79,196개, 시간은 148초로 더 커졌다.

이 조건에서 보여주는 것은 “사람을 넣으면 무조건 좋다”가 아니다. 사람의 계획은 멀티에이전트의 약한 지점, 특히 초반 구조 설계를 보완할 수 있다. 그러나 그 계획이 더 세밀할수록 검색, 작성, 리뷰 단계가 늘어나고 운영비도 커진다. 품질을 위해 사람을 어디에 넣을지 정해야지, 모든 단계에 사람을 끼워 넣는다고 자동으로 효율이 오르지는 않는다.

원문 첫 페이지. README 생성이라는 좁은 과업을 다루지만, RAG·에이전트 업무 자동화의 설계 비용을 생각하게 만든다.

Deciflow 자동화에 붙여본다면

이 논문은 “에이전트를 많이 붙이는 설계”를 경계하게 만든다. 실무 자동화에서는 먼저 과업의 병목이 무엇인지 봐야 한다.

• 필요한 결과가 짧고 기준이 명확하다면 단일 에이전트 RAG가 충분할 수 있다.
• 결과물의 섹션 누락이 치명적이라면 멀티에이전트나 체크리스트 기반 구조화가 필요하다.
• 초반 기획 품질이 전체 결과를 좌우한다면, 사람은 마지막 검수보다 처음 계획에 들어가는 편이 효과적일 수 있다.
• 비용과 지연 시간이 중요한 반복 업무라면 멀티에이전트 구조가 “좋아 보이는 설계”인지 실제 개선인지 따로 검증해야 한다.

작은 실험으로는 Notes 발행 파이프라인의 한 단계를 골라볼 수 있다. 예를 들어 “논문 원문 → 글의 섹션 계획”만 사람이 제공하고, 나머지는 단일 에이전트가 초안을 만들게 한 뒤, 현재 방식과 누락률·수정시간·토큰비용을 비교한다. 자동화 설계의 기준은 멋진 구성도가 아니라 재작업이 줄었는가여야 한다.

조심해서 읽을 점

이 연구의 대상은 README 생성이고, 평가에는 ROUGE, BERTScore, LLM-as-a-Judge, 수동 섹션 매핑이 함께 쓰였다. 다른 업무 문서나 평가 보고서에 그대로 일반화할 수는 없다. 그래도 이 조건에서 꽤 강하게 시사하는 바는 있다. 에이전트 구조의 복잡성은 품질 보증 장치일 수도 있지만, 비용을 숨기는 장식일 수도 있다. 둘을 가르는 것은 실제 과업 지표다.

원문 정보

• 제목: The Illusion of Agentic Complexity in README.md Generation: Evaluating Single-Agent vs. Multi-Agent RAG Systems
• 저자: Abu Saleh, Tesfay Welegebreal Tesfay, Phuong T. Nguyen, Juri Di Rocco, Muhammad Umar Zeshan, Davide Di Ruscio
• 연도/게시일: 2026
• 게재/출처: arXiv
• arXiv: 2606.30524v1
• PDF: https://arxiv.org/pdf/2606.30524

원문 논문: The Illusion of Agentic Complexity in README.md Generation: Evaluating Single-Agent vs. Multi-Agent RAG Systems