💡 이번주 뉴스레터에는 이런 내용을 담았어요!

• 멀티에이전트의 Homogeneous, Heterogeneous 구조의 차이를 정리합니다. 

• OneFlow 알고리즘이 최적의 워크플로우를 탐색하는 방식을 요약합니다.

• 단일 LLM 실행이 비용과 지연 측면에서 어떤 결과를 보였는지 실험을 통해 짚어봅니다.

안녕하세요, 에디터 스더리입니다!

지난 몇 달 사이, 실무에서 자주 언급되는 AI 아키텍처 키워드 중 하나는 멀티에이전트(Multi-Agent)입니다. Planner Agent가 계획을 세우고, Critic Agent가 검토하고, Tool Agent가 실행하는 구조는 이제 연구 논문을 넘어 실제 서비스에서도 쓰이고 있습니다. 복잡한 문제일수록 에이전트를 더 붙이면 된다는 인식도 자연스레 자리 잡았죠.

하지만 이러한 흐름 속에서 문득 드는 질문이 하나 있습니다. 정말 에이전트는 많을수록 좋은 걸까요? 최근 Amazon과 UT Austin 연구진이 발표한 논문 Rethinking the Value of Multi-Agent Workflow: A Strong Single Agent Baseline은 바로 이 질문에서 출발합니다. 연구진은 대부분의 멀티에이전트 시스템이 사실상 동일한 LLM을 공유하고 있다는 점에 주목하고, 이를 하나의 LLM이 멀티턴 대화로 “연기”하도록 만들면 성능은 유지하면서도 비용과 지연을 크게 줄일 수 있다고 주장합니다.

개인적으로 이 논문이 흥미로웠던 이유는, 멀티에이전트의 성능뿐 아니라 운영 비용과 시스템 복잡도까지 동시에 겨냥하고 있기 때문입니다. 이번 뉴스레터에서는 논문에서 제안하는 프레임워크 OneFlow와 함께, 단일 LLM이 멀티에이전트를 대체할 수 있는지 살펴보려 합니다.

최근 대형 언어 모델의 성능이 급격히 좋아지면서, 여러 개의 LLM 에이전트가 협업하는 멀티에이전트 시스템에 대한 관심도 함께 커졌습니다. 멀티에이전트 시스템은 여러 사람이 역할을 나눠 협업하듯, 모델도 Planner, Reviewer, Executor 등 여러 에이전트로 복잡한 문제를 해결하는 방법입니다. 실제로 수학 추론, 코드 생성, 툴 사용, 장기 계획 같은 영역에서 멀티에이전트 워크플로우가 좋은 성능을 낸다는 연구 결과도 꾸준히 보고되어 왔습니다. 

 ⓒ deep daiv.

논문에서는 멀티에이전트 시스템을 두 유형으로 나누어 분석합니다. 에이전트마다 서로 다른 언어 모델을 사용하는 Heterogeneous 구조와, 하나의 기반 모델을 여러 역할로 나누어 쓰는 Homogeneous 구조입니다. 요즘 핫한 도구를 예로 들어 보면, Claude Code는 기본적으로는 단일 모델 중심의 Homogeneous 구조에 가깝지만, opusplan 같은 모드에서는 역할별로 서로 다른 모델을 배치하는 Heterogeneous한 구성도 지원합니다. 반면 Oh-My-Opencode처럼 작업 단계별로 모델을 분리해 사용하는 프레임워크는 Heterogeneous한 접근에 더 가까운 사례로 볼 수 있습니다.

연구진이 기존 연구와 사례를 살펴본 결과, 많은 시스템이 이 Homogeneous한 형태에 속한다고 지적합니다. Homogeneous 시스템은 여러 에이전트가 협업하는 형태처럼 보이지만, 실질적으로는 동일한 모델을 반복 호출한다는 점에서 단일 LLM 실행과 비교할 수 있는데요. 연구진은 이러한 역할 분담을 하나의 LLM이 멀티턴 흐름 안에서 순차적으로 수행하도록 재구성하면 성능을 크게 해치지 않으면서도 비용과 지연을 상당히 줄일 수 있다고 설명합니다. 그리고 이 두 방식 사이의 차이를 만들어 내는 핵심 요소로 KV Cache(Key–Value Cache)를 꼽습니다.

트랜스포머 계열 모델에서 x축인 컨텍스트 길이가 늘어날수록 어텐션 계산이 계산과 메모리 비용이 증가하며 이를 빠르게 키우는 이유는 KV Cache에 있음을 보여줍니다.
출처: Medium: Why Large Context AI Is So Expensive (And How Mamba Fixes It)

KV Cache의 개념을 이해하려면 먼저 언어 모델이 문맥을 처리하는 방식부터 살펴볼 필요가 있습니다. 트랜스포머(Transformer) 기반 언어 모델은 새로운 토큰을 생성할 때마다 앞서 등장한 모든 토큰을 다시 참고해 어텐션(Attention) 계산을 수행합니다. 따라서 대화가 길어질수록 계산량이 빠르게 늘어나죠.

KV Cache는 이 과정에서 이미 계산해 둔 중간 결과를 저장해 두었다가, 다음 토큰을 만들 때 그대로 재사용하는 방식입니다. 긴 문서를 다시 읽을 때 매번 처음부터 훑지 않고 책갈피해 둔 부분을 참고하는 것에 비유할 수 있습니다.

다시 본론으로 돌아와 보면, Homogeneous 멀티에이전트 구조에서는 여러 에이전트가 같은 입력과 중간 결과를 반복해서 처리해야 합니다. 반면, 단일 LLM 실행에서는 이러한 계산을 KV Cache를 통해 공유할 수 있습니다. 여기서 단일 LLM 실행이 비용과 지연 측면에서 유리해지는 것이죠.

연구진은 단순히 기존 워크플로우를 하나의 에이전트로 돌리는 제안에 그치지 않고, 단일 에이전트가 실행하기에 가장 최적화된 워크플로우를 자동으로 찾아내는 OneFlow 알고리즘을 제안했습니다. OneFlow의 목표는 주어진 태스크에서 성능과 비용 사이의 균형이 가장 좋은 워크플로우를 데이터 기반으로 탐색하는 데 있습니다.

위 그림은 OneFlow가 워크플로우를 어떻게 점진적으로 개선해 가는지를 한눈에 보여 줍니다. 출발점은 하나의 LLM만 사용하는 단순한 구조이며, 여기에 Chain-of-Thought이나 중간 검증을 담당하는 모듈을 하나씩 추가해 보면서 정확도와 비용 변화를 측정합니다. 어떤 수정은 효과 없이 비용만 늘어나 실패로 기록되고, 어떤 수정은 비교적 적은 비용으로 성능을 끌어올려 다음 탐색 단계로 이어집니다. OneFlow는 이런 결과를 모두 저장해 두고, 성능 대비 효율이 좋아 보이는 방향으로만 탐색을 확장해 나갑니다.

이 과정의 중심에는 Designer와 Critic이라는 두 메타 에이전트가 있습니다. Designer는 현재까지 가장 좋은 구조를 바탕으로 새로운 변형안을 만들고, Critic은 이 제안이 실제로 성능 대비 비용을 개선하는지 검토합니다. 불필요한 단계를 쳐내고, 단일 에이전트 환경에서 효율적으로 돌아가도록 설계를 다듬어 최종안을 만드는 것이죠. 이 때 필요하다면 두 에이전트가 주고받으며 후보 워크플로우를 다듬기도 합니다.

완성된 구조는 곧바로 검증 데이터셋에서 실행되고, 여기서 얻은 성능과 비용 지표가 다시 탐색 과정에 반영됩니다. 그림 속 Workflow 6은 이런 반복 실험을 거쳐 선택된 결과물입니다. 중요한 점은 OneFlow가 특정 형태의 멀티에이전트나 단일 실행을 미리 정답으로 가정하지 않고, 실제 실험을 통해 가장 효율적인 설계를 찾아낸다는 것입니다.

그렇다면 OneFlow는 이 많은 후보 구조를 어떻게 효율적으로 탐색할 수 있었을까요? 그 핵심이 바로 Monte Carlo Tree Search(MCTS)입니다.

Monte Carlo Tree Search (MCTS)

바둑이나 체스 같은 게임 AI에서 널리 쓰이는 탐색 알고리즘으로, 가능한 모든 수를 한 번에 계산하기보다 유망해보이는 선택지를 실제로 시험해보고 그 결과를 누적하면서 탐색 범위를 좁혀가는 방식입니다. 완전 탐색이 불가능할 정도로 경우의 수가 많은 문제에서, 제한된 자원으로도 합리적인 선택을 찾아내는 데 강점이 있습니다.

OneFlow는 이 탐색 전략을 워크플로우 설계 공간에 그대로 적용합니다. 각 노드는 하나의 워크플로우 구조를 의미하고, 브랜치(Branch)는 해당 구조에 어떤 변경을 가할지를 나타냅니다. 에이전트를 추가하거나 검증 단계를 넣거나 특정 모듈을 제거하는 선택이 모두 하나의 확장 방향이 됩니다. OneFlow는 이런 변형을 실제로 실행해 보고, 성능과 비용이라는 두 지표를 동시에 평가한 뒤 그 결과를 다음 탐색 단계에 반영합니다. 이 덕분에 OneFlow는 무작위로 구조를 바꿔 보는 방식이 아니라, 이전 실험에서 얻은 성능과 비용 신호를 바탕으로 유망한 워크플로우만을 선택적으로 발전시켜 나갑니다.

연구진은 OneFlow와 단일 LLM 실행 전략을 코드 생성, 수학 추론, 질의응답, 도메인 특화 추론, 그리고 실제 도구 사용이 포함된 여행 계획 태스크까지 폭넓은 벤치마크에서 평가했습니다. 각 태스크에 맞춰 정확도와 성공률을 측정하는 동시에, 워크플로우 하나를 실행하는 데 드는 토큰 비용도 함께 비교했습니다.

가장 눈에 띄는 결과는 동일한 LLM을 공유하는 Homogeneous 구조에서는 단일 LLM 실행이 기존 멀티에이전트와 거의 같은 성능을 냈다는 점입니다. 자동으로 설계된 워크플로우는 수동으로 만든 구조보다 전반적으로 좋은 성능을 보였고, 이를 하나의 모델이 멀티턴 대화로 실행해도 정확도가 크게 떨어지지 않았습니다. 특히 OneFlow가 찾아낸 구조를 단일 실행으로 돌렸을 때 여러 벤치마크에서 최고 성능 그룹에 속하는 사례가 반복적으로 관찰됐습니다.

비용 측면에서는 차이가 더욱 분명했습니다. 단일 LLM 실행은 멀티에이전트 방식보다 추론 비용이 크게 낮았는데, 이는 앞서 언급한 KV Cache 덕입니다. 여러 에이전트가 같은 문맥을 반복 처리하지 않고 하나의 대화 흐름 안에서 계산 결과를 재사용할 수 있기 때문이죠.

TravelPlanner처럼 실제 도구 사용이 포함된 태스크에서도 단일 실행 방식이 원래의 멀티에이전트 구조와 비슷한 성공률을 유지하면서 훨씬 저렴하게 동작했습니다. 다만 서로 다른 모델을 섞은 Heterogeneous 구성에서는 KV Cache를 공유할 수 없기 때문에 단일 실행의 이점이 줄어들었고, 일부 경우에는 멀티에이전트 구조가 더 경쟁력 있게 나타났습니다. 결국 멀티에이전트가 항상 정답은 아니며, 같은 모델을 쓰는 환경에서는 잘 설계된 단일 LLM 실행이 매우 강력한 기준선이 될 수 있음을 보여 줍니다.

다만 이 논문의 제안이 곧바로 모든 실무 환경에 그대로 적용될 수 있는 것은 아닙니다. 연구에서는 동일한 LLM 인스턴스 안에서 여러 역할을 수행하며 KV Cache를 공유하는 상황을 전제로 하지만, 실제 상용 API 환경에서는 이런 통제가 쉽지 않은 경우가 많습니다. 또한 서로 다른 모델을 섞는 Heterogeneous 구성에서는 KV Cache 공유 자체가 불가능하기 때문에, 단일 LLM 실행 전략의 장점이 제한될 수밖에 없습니다.

그럼에도 앞으로 LLM이 더 많은 서비스에 쓰이게 될수록, 비용과 에너지 사용량은 피할 수 없는 설계 기준이 될 것입니다. 단순히 성능이 좋다는 이유만으로 구조를 쌓아 올리는 방식은 언젠가 ‘정말 필요한 만큼 계산하고 있는지’를 다시 묻게 될지도 모릅니다. 구성 요소를 늘리는 것보다 오케스트레이션을 얼마나 정교하게 설계하느냐가 더 중요해지지 않을까요?