멀티에이전트는 에너지를 6.36배 쓴다: 에이전틱 LLM 개발 도구 지속가능성 실측 리뷰

원문 정보

Merve Astekin, Yan Naing Tun, Arda Goknil, Erik Johannes Husom, Lwin Khin Shar, Hasan Sözer, Ratnadira Widyasari, Hui Song, "Engineering Sustainable Agents: A Systematic Comparison of Agentic LLMs for Developer Workflows", arXiv:2610.03010 [cs.SE], 2026-10-02 제출(v1), DOI 10.48550/arXiv.2610.03010. 소속: SINTEF(노르웨이)·싱가포르경영대학교·외즈예인대학교(튀르키예). 원문 전문은 2026-10-05T22:14:44Z 기준 1차 출처 스냅숏(세션 egress 전면 차단 — 10분 간격 3회 재시도 후 폴백)으로 대조했습니다.

동료심사를 거치지 않은 프리프린트입니다. 자금 출처는 유럽연합 호라이즌 유럽 프로그램의 ENFIELD(101120657)·INTEND(101135576) 과제로 명시돼 있고, 특정 LLM 공급사의 연구비나 저자-평가모델 간 이해상충은 확인되지 않습니다 — 평가에 쓴 6개 모델 전부가 오픈웨이트 공개 모델입니다.

연구 개요

질문은 두 가지입니다. 에이전트 수를 늘릴수록 정확도·에너지·지연이 어떻게 바뀌는가, 그 트레이드오프가 과제마다 같은 방향인가입니다. 저자들은 코드 생성(HumanEval 계열)·기술부채 탐지(MLCQ, Java)·취약점 탐지(PrimeVul, C/C++)·로그 파싱·로그 분석(HDFS) 5개 소프트웨어공학 과제에서, 비에이전트 단일 질의(NA)부터 단일 에이전트(SA)·이중 에이전트(DA)·4-에이전트 멀티에이전트(MA)까지 4개 구성을 6개 오픈웨이트 모델(최대 20B)·2개 프롬프트 전략(제로샷/퓨샷)·3개 하드웨어(서버 2종, 워크스테이션 1종)에 걸쳐 반복 측정했습니다. 지표는 과제별 정확도(Pass@1·Macro F1·F1·정확매칭 중 선택)·종단 지연·총 파이프라인 에너지 소비(kWh) 세 축입니다.

핵심 결과

15개 과제-하드웨어 조합·전 모델·전 프롬프트를 평균한 전체 수치입니다(Table 16·20).

최악 사례는 로그 파싱·Workstation-SMU 조합으로, NA 313.1초에서 MA 50,185.8초(약 13.9시간)로 늘어 160배 느려졌습니다. 반면 정확도는 에너지·지연과 같은 방향으로 움직이지 않았습니다.

나머지 세 과제는 구성 간 차이가 좁은 범위에 머물렀습니다 — 코드 생성 Pass@1 94.2~96.8%, 기술부채 탐지 Macro F1 40.0~42.8%, 로그 분석 F1 5.5~7.5%(HDFS의 비정상 세션 비중이 약 3%인 클래스 불균형 탓에 전 구성이 낮음). MA가 유일하게 다른 구성을 앞선 과제는 취약점 탐지뿐이고, 3차원(정확도·에너지·지연) 파레토 최적 조합 66개 가운데 NA 36개(55%)·SA 23개(35%)·DA 6개(9%)·MA 1개(2%)로, NA+SA가 59개(89%)를 차지했습니다.

신뢰도 평가

믿을 근거: 공공 연구비(EU 호라이즌 유럽)로 수행돼 벤더 이해상충이 없고, 평가 모델이 전부 오픈웨이트라 결과 재현이 가능합니다. 온도 0 고정, 반복 3회(대부분 구성), 통계적 유의성 검정을 거쳤고, 하드웨어별 가중치가 한쪽으로 쏠리지 않도록 RQ1 분석에서 모델 간 하드웨어 수를 맞춰 평균했습니다.

감안할 점: 동료심사 전 초고입니다. 가장 중요한 한계는 평가 모델이 전부 최대 20B의 로컬 오픈웨이트 소형 모델이라는 점입니다 — GPT-5·Claude·Gemini 같은 프런티어 호스팅 API 모델에는 에너지·지연 배수가 그대로 적용되지 않을 수 있습니다. GPT-OSS는 하드웨어 1종에서만, 반복 없이 1회 실행됐습니다. 데이터셋도 Python·Java·C/C++에 한정되고 정제된 벤치마크라 실제 저장소의 잡음 섞인 입력과는 다를 수 있습니다. 상반된 증거로, Shu et al.(2024)은 같은 '멀티에이전트 대 단일 에이전트' 비교에서 성공률이 최대 70% 올랐다고 보고해 이 논문과 결론이 엇갈립니다 — 과제 성격(엔터프라이즈 협업·라우팅 대 소프트웨어공학 5과제)과 비용 측정 여부의 차이로 보입니다.

관련 연구

• Shu et al. (2024), "Towards Effective GenAI Multi-Agent Collaboration: Design and Evaluation for Enterprise Applications" — 상반 연구(AWS Bedrock). 엔터프라이즈 협업·라우팅 과제에서 멀티에이전트가 단일 에이전트보다 성공률을 최대 70% 끌어올렸다고 보고합니다. 에너지·지연 비용은 측정하지 않았고 과제 성격도 달라, 이번 논문의 '멀티에이전트 이득은 과제 특정적'이라는 결론과 양립할 수 있습니다.
• Husom et al. (2024), "The Price of Prompting: Profiling Energy Use in Large Language Models Inference" — 선행 연구(저자 일부 중복, NeurIPS 2024 제출). 단일 모델 추론에서 70B급 모델이 소형 모델보다 토큰당 에너지를 최대 두 자릿수 더 쓴다는 MELODI 프레임워크를 제시했습니다. 이번 논문은 같은 에너지 프로파일링 방법을 단일 모델 추론에서 멀티에이전트 파이프라인 전체로 확장합니다.
• Alizadeh et al. (2025), "Language Models in Software Development Tasks: An Experimental Analysis of Energy and Accuracy" — MSR 2025 — 선행·확장 관계. 모델 크기를 키우고 에너지 예산을 늘려도 정확도가 항상 따라 오르지는 않으며, 모든 SE 과제에 맞는 단일 모델은 없다고 보였습니다. 이번 논문은 같은 '더 쓴다고 더 낫지 않다' 패턴을 모델 크기가 아니라 에이전트 아키텍처 복잡도 축으로 재확인합니다.

세 문헌 모두 WebSearch로 독립 식별·확인했으나(egress 차단으로 원문 전문 재열람은 못 함) 이번 논문의 참고문헌 목록과 제목·저자·venue가 일치함을 대조했습니다.

리뷰어 판단

첫째, 멀티에이전트 도입 여부를 "추론이 복잡한 과제인가"로 판단하면 안 된다고 봅니다. 이 논문에서 MA가 유일하게 이긴 취약점 탐지는 서로 다른 관점의 교차검증이 실패를 줄이는 과제이고, 코드 생성·로그 분석처럼 추론 자체가 복잡해도 관점을 나눌 필요가 없는 과제에서는 오히려 손해였습니다. "교차검증이 실패를 줄이는가"가 더 좁고 실무적인 기준이라고 판단합니다.

둘째, 로그 파싱에서 에이전트를 늘릴수록 정확도가 34.5%에서 26.1%로 떨어진 결과가 이 논문에서 가장 저평가된 대목이라고 봅니다. 포맷에 민감한 과제는 에이전트 간 메시지 전달 과정이 출력 형식을 오염시킬 수 있다는 뜻입니다. 같은 과제에서 퓨샷 프롬프트만으로 정확도가 3.4%에서 54.3%로 뛰었다는 저자들의 G3 결과와 겹쳐 보면, 아키텍처를 늘리기 전에 프롬프트 설계부터 점검해야 한다는 근거로 읽힙니다.

실무 적용

• 비에이전트부터 시작 — NA가 5개 과제 전부에서 최소 한 축(정확도·에너지·지연 중 하나)의 최선이었습니다. 에이전트 추가는 가설로 두고 증거가 쌓일 때만 확장합니다.
• 모델 선택이 아키텍처보다 먼저 — 과제별 최적 모델 격차(최대 두 자릿수 에너지 차이)가 에이전트 구성 격차보다 큽니다. 아키텍처를 키우기 전에 모델 매칭을 점검합니다.
• 포맷 민감 과제엔 퓨샷 — 로그 파싱처럼 출력 구조가 중요한 과제는 퓨샷 프롬프트가 에이전트 추가보다 싸고 효과적입니다(이 논문 기준 정확도 +50.9%p, 에너지 24~41% 감소).
• 무거운 워크로드만 하드웨어에 투자 — DA·MA처럼 무거운 구성에서는 서버급 하드웨어가 워크스테이션보다 최대 3.4배 빠릅니다. NA·SA 같은 가벼운 워크로드는 하드웨어 차이가 작아 가용성 기준으로 골라도 됩니다.
• 에너지를 정확도와 함께 보고 — 자체 에이전트 시스템을 벤치마크할 때 정확도만 공개하면 이런 트레이드오프가 드러나지 않습니다. 고정 하드웨어 기준 에너지·지연을 함께 측정합니다.

결론

이 연구는 멀티에이전트 아키텍처가 기본값이 아니라 가설이어야 한다는 것을 다섯 과제·세 하드웨어의 통제된 실측으로 보여줍니다. 평균적으로 4-에이전트 구성은 비에이전트 대비 에너지를 6.36배, 지연을 6.07배 썼지만 정확도 개선은 취약점 탐지 한 과제에 그쳤고, 파레토 최적 조합의 89%는 비에이전트 또는 단일 에이전트였습니다.

다만 평가 모델이 전부 로컬 오픈웨이트 소형 모델이라는 한계가 있어, 프런티어 호스팅 API를 쓰는 조직은 에너지·지연 배수를 그대로 가져다 쓰기보다 자체 벤치마크로 재확인해야 합니다. 에이전트를 추가하기 전에 멈출 근거부터 설계하는 쪽은 정지 규칙 하나가 비용의 63%를 줄였다: 멀티에이전트 메모리 게이팅 운영 가이드에서 이어집니다.

참고 링크

• Engineering Sustainable Agents: A Systematic Comparison of Agentic LLMs for Developer Workflows — arXiv 초록(원문)
• 같은 논문 HTML 전문 — 표·에너지·지연 수치 대조에 사용
• 정지 규칙 하나가 비용의 63%를 줄였다: 멀티에이전트 메모리 게이팅 운영 가이드 — sunny34.com 블로그