논문 원본 Figure 아카이브
아래는 논문의 핵심 Figure 원본이다. 각 Figure가 본문 어느 섹션에 해당하는지 함께 표기했다.
이 논문은 LLM 기반 멀티에이전트 시뮬레이션을 "어떻게 100만 명의 에이전트를 12분 안에 실행할 수 있는가"라는 공학적 문제로 바라본다 — 액터 모델(actor model)이라는 수십 년 된 분산 컴퓨팅 아이디어를 AI 에이전트 세계에 이식함으로써, 확장성·다양성·관리용이성 세 가지 장벽을 동시에 허문다.
arXiv →LLM의 등장으로 에이전트 기반 시뮬레이션(agent-based simulation)은 새로운 전기를 맞이했다. GPT-4, Qwen2, Llama3처럼 인간의 언어를 이해하고 추론하는 모델이 에이전트의 "두뇌"가 될 수 있다면, 경제학자·사회학자·행동과학자들이 오랫동안 꿈꿔온 대규모 사회 시뮬레이션이 현실이 될 수 있다. 실제로 교육·경제·사회학·교통·의료 등 다양한 분야에서 LLM 에이전트를 활용한 시뮬레이션 연구가 폭발적으로 증가하고 있다.
그러나 논문은 기존 플랫폼들이 "대규모"라는 벽 앞에서 세 가지 치명적인 한계에 부딪힌다고 진단한다.
"We identify several challenges in conducting simulations with multi-agent platforms, particularly when the number of agents becomes extremely large."에이전트 수가 극단적으로 많아질 때, 기존 멀티에이전트 플랫폼의 근본적 한계들이 드러난다.
보충 에이전트 기반 시뮬레이션(ABS)은 본래 수십 년의 역사를 가진 분야다. 그러나 기존의 rule-based ABS는 전문가가 행동 규칙을 일일이 코딩해야 했다. LLM 에이전트는 자연어 프롬프트만으로 인간과 유사한 추론·적응 행동을 보여줄 수 있어, ABS의 패러다임을 근본적으로 바꾸고 있다. 문제는 LLM 호출이 rule 실행보다 수백~수천 배 느리고 비싸다는 점이다.
논문은 세 가지 문제 각각에 대한 해결책을 제시하면서, 동시에 하나의 통합 플랫폼 AgentScope 위에서 이들이 함께 작동하도록 설계했다. 핵심 통찰은 이것이다: 에이전트를 "액터(actor)"로 추상화하면, 에이전트 간 의존 관계가 없는 것들은 자동으로 병렬 실행될 수 있다.
to_dist 함수 하나로 변환할 수 있다는 것이 설계의 핵심이다.
아래 다이어그램에서 에이전트 A가 완료된 후 B와 C가 독립적으로 병렬 실행되는 구조를 확인할 수 있다. 각 블록을 클릭하면 상세 설명이 나타난다.
AgentScope는 기존 플랫폼(LLM 서비스, 메모리 관리, 에이전트 상호작용)의 기본 기능을 토대로, 네 가지 핵심 컴포넌트를 추가했다. 각각이 앞서 진단한 세 가지 한계 중 어느 것을 해결하는지 주목하면서 읽어보자.
액터 모델(actor model)은 Agha(1985)가 제안한 수학적 동시 계산 모델이다. 핵심 원리: 각 액터는 독립적인 연산 단위로, 메시지를 받아 독립적으로 계산한다. AgentScope는 LLM 에이전트를 액터로 추상화함으로써, 에이전트 수준의 병렬 실행(agent-level parallel execution)과 자동 워크플로우 변환(automatic workflow conversion)을 동시에 구현했다.
멀티에이전트 시뮬레이션에서 에이전트 간 상호작용은 "원자화된 패턴(atomized pattern)"을 따른다 — 상호작용은 격리된 소규모 클리크(clique) 내에서 발생한다. 이 패턴은 에이전트 수준 병렬화에 큰 잠재력을 제공한다.
"Agents that do not rely on the outputs of others or whose dependencies have all been satisfied, can be executed in parallel for enhancing efficiency."다른 에이전트의 출력에 의존하지 않거나, 모든 의존성이 이미 충족된 에이전트들은 병렬로 실행될 수 있다.
AgentScope는 두 가지 멀티프로세스 모드를 제공한다:
| 모드 | 에이전트-프로세스 관계 | 적합한 상황 |
|---|---|---|
| 일대일(One-to-One) | 에이전트마다 별도 프로세스 | 연산 집약적 작업. GIL 영향 없이 진정한 병렬 실행. 각 에이전트에 충분한 자원 보장. |
| 다대일(Many-to-One) | 여러 에이전트가 하나의 프로세스 공유 | I/O 대기·원격 API 대기가 많은 LLM 에이전트에 최적. CPU 타임셰어링으로 자원 최대 활용. |
보충 기존 플랫폼(AutoGen, MetaGPT)은 Python의 asyncio 기반 비동기 I/O를 사용한다. 이는 GIL로 인해 실제 병렬 CPU 연산이 불가능하다. Ray 같은 액터 기반 프레임워크는 각 액터마다 새 워커 프로세스를 할당해 대규모 에이전트에서는 자원 낭비가 심하다. 본 논문의 접근법은 많은 에이전트를 하나의 프로세스 안에서 처리할 수 있어 이 문제를 회피한다.
분산 배포의 핵심 장벽은 "기존 코드를 전부 다시 작성해야 한다"는 것이었다. AgentScope는 to_dist 함수 하나로 중앙화된 워크플로우를 분산 워크플로우로 변환한다. 변환 과정은 두 단계로 자동 수행된다:
에이전트끼리의 통신만으로는 부족하다. 실제 시뮬레이션에서 에이전트들은 공유된 환경(shared environment)을 읽고 쓰며 반응해야 한다. 예를 들어 채팅방 시뮬레이션에서는 대화 이력이 환경의 상태이고, 미로 시뮬레이션에서는 에이전트의 위치가 상태다.
AgentScope가 환경에 요구하는 네 가지 조건과 그 해결 방식:
| 요구 조건 | 구현 방식 |
|---|---|
| 고동시성 접근 | 환경을 특수한 에이전트로 추상화 → RPC 통신으로 동시 접근 지원 |
| 다양한 상태 | 사용자 정의 함수(user-defined functions)로 임의의 상태 확장 가능 |
| 양방향 상호작용 | 리스너(listener) 도입: 조건 충족 시 환경이 에이전트에 능동적으로 메시지 전송 |
| 다중 환경 | 환경의 중첩(nesting) 지원: 그룹별 전용 환경 + 전역 환경 계층 구조 |
"We abstract the environment as a special type of agent with rich functionalities, which allows the environment to maintain shared variables as states and to communicate with other agents through Remote Procedure Calls for ensuring high concurrency."환경을 풍부한 기능을 가진 특수한 에이전트로 추상화하여, 공유 변수를 상태로 유지하고 RPC를 통해 고동시성 통신을 보장한다.
보충 리스너 패턴은 이벤트 기반 프로그래밍(event-driven programming)의 고전적 개념이다. 예를 들어 채팅방 환경에서 특정 에이전트의 이름이 언급되면, 환경이 해당 에이전트에 자동으로 알림을 보낼 수 있다. 이를 통해 에이전트가 매 턴마다 환경을 폴링(polling)할 필요 없이 필요한 순간에만 활성화된다.
에이전트 다양성의 핵심 문제: 수천 명의 에이전트에게 다양하고 상세한 배경 설정을 수작업으로 부여하는 것은 사실상 불가능하다. 특히 "전체 인구 중 20%는 대학원 졸업, 30%는 고졸" 같이 정밀한 인구통계 분포를 원할 때는 더욱 그렇다.
AgentScope의 해결책은 두 단계 파이프라인이다:
시뮬레이션 규모가 커질수록 초기화·실행·종료·모니터링이 수동으로는 불가능해진다. AgentScope는 Agent-Manager라는 웹 기반 시각 인터페이스를 제공한다.
"Servers are first launched on all the remote devices, which provide resident services to remotely create, monitor, and stop distributed agents."모든 원격 디바이스에 서버가 먼저 실행되어 분산 에이전트를 원격으로 생성·모니터링·종료하는 상주 서비스를 제공한다.
Agent-Manager의 주요 기능:
평가 논문은 Agent-Manager의 구현 세부사항(사용된 프레임워크, 실시간 업데이트 방식 등)을 자세히 공개하지 않는다. 그러나 대규모 시뮬레이션에서 "무엇이 잘못되고 있는지"를 실시간으로 파악하는 능력은 연구 생산성에 매우 중요하다. 이 기능의 진정한 가치는 실제 복잡한 시뮬레이션에서 디버깅 시간이 얼마나 줄어드는지로 측정되어야 할 것이다.
| 항목 | 세부 사항 |
|---|---|
| 하드웨어 | A100-80G GPU 8개 탑재, 64코어 CPU, 1TB 메모리로 구성된 클러스터 (복수 디바이스) |
| LLM 추론 엔진 | vLLM (고동시성 서비스 요청 처리) |
| 생성 temperature | 1.0 (응답 다양성 극대화) |
| LLM 호출 구조 | 라운드당 2회 LLM 호출: ① 사고 과정 + 숫자 생성, ② 숫자 추출 (형식 오류 방지) |
| 통신 방식 | RPC (Remote Procedure Call); Python 및 C++ 구현 모두 제공 |
| 소스 코드 | GitHub 공개: modelscope/agentscope/examples/paper_large_scale_simulation |
논문은 고전 게임이론 실험인 "평균의 2/3 추측(Guess 2/3 of the Average)" 게임을 테스트베드로 선택했다. 이 선택은 탁월하다: 게임 이론적으로 Nash 균형이 명확히 알려져 있어(모든 에이전트가 0을 보고해야 함), 에이전트의 합리성과 추론 능력을 정량적으로 평가할 수 있다.
"Each player reports a real number between 0 and 100, inclusive. The winner will be the player whose number is the closest to 2/3 of the average of all reported numbers."각 플레이어는 0~100 사이의 실수를 보고하며, 모든 보고 숫자 평균의 2/3에 가장 가까운 숫자를 보고한 플레이어가 승리한다.
보충 이 게임의 Nash 균형이 0인 이유: "최대값은 100이므로 66.7 이하를 선택해야 한다 → 그런데 다들 그렇게 생각하면 새 최대값은 66.7이므로 44.4 이하를 선택해야 한다 → ..." 이 귀납 추론을 무한히 반복하면 0에 수렴한다. 그러나 현실에서는 모든 플레이어가 완전히 합리적이지 않으므로, 0을 보고한다고 항상 이기는 것은 아니다.
더미 모델(에이전트가 1초 대기 후 난수 생성)을 사용하여 LLM 추론 속도의 영향을 제거하고, 순수 플랫폼 병렬 처리 효율만 비교한 결과다.
동일한 게임에서 어떤 프롬프트를 주느냐에 따라 에이전트의 행동이 극적으로 달라진다. 아래 차트는 Qwen2-72B 에이전트가 4가지 프롬프트 유형에서 보고하는 숫자의 중앙값을 비교한다.
Prompt 1(기본)에서 Prompt 4(전략적 추론 유도)로 갈수록 에이전트의 행동이 Nash 균형(0)에 가까워진다. 특히 "모든 플레이어가 합리적이다"라는 정보를 추가하는 것만으로도 큰 변화가 생긴다.
| 교육 수준 | Qwen2-72B 평균 | Llama3-70B 평균 | 패턴 |
|---|---|---|---|
| 초등학교 | 높음 (~40+) | 높음 | 덜 합리적 |
| 고등학교 | 중간 | 중간 | — |
| 학사 | 중간 | 중간 | — |
| 석사 | 낮음 | 낮음 | — |
| 박사(Ph.D.) | 가장 낮음 | 가장 낮음 | 가장 합리적 |
교육 수준이 높을수록 더 낮은 숫자를 보고하는(더 합리적인) 경향이 나타났다. 단, MistralAI-8×22B는 교육 수준에 가장 둔감하여 최대 차이가 3.49에 불과했다. 이는 LLM마다 "캐릭터 배경 설정"에 대한 민감도가 다름을 보여준다.
라운드가 진행될수록 에이전트들이 이전 라운드의 승자 숫자를 참고해 전략을 조정하며, 보고값이 Nash 균형(0)으로 수렴하는 것을 확인했다. Prompt 4를 사용한 Qwen2-72B는 5라운드에서 평균 0.15를 달성했다(Prompt 1 동일 조건에서는 25.16).
이 논문이 여는 가능성은 단순한 플랫폼 개선을 넘어선다. LLM 에이전트를 100만 규모로 실행할 수 있게 되면, 이전에는 불가능했던 연구 질문들이 생긴다:
to_dist 함수 하나로 기존 코드를 분산 실행으로 전환할 수 있다는 점은 진입 장벽을 크게 낮춘다.
이 게임은 세 가지 이유에서 이상적인 테스트베드다. 첫째, Nash 균형(0)이 이론적으로 명확하게 정의되어 있어 에이전트의 합리성을 정량적으로 측정할 수 있다. 둘째, 규칙이 단순해 다양한 배경의 에이전트에게 동일한 조건을 제공한다. 셋째, 게임이론 분야에서 인간 대상 실험 결과(Nagel 1995, Camerer 2004)가 풍부해 LLM 에이전트의 결과를 비교·검증할 수 있다.
"These experimental results are consistent with previous studies in social simulation, which confirms the reliability and significant potential of multi-agent-based simulations."
Ray는 각 액터마다 새 워커 프로세스를 할당하는 방식을 사용한다. 에이전트 수가 수백만에 달하면 프로세스 오버헤드가 막대해진다. AgentScope의 "다대일" 모드는 여러 에이전트가 하나의 프로세스를 공유하므로, LLM API 응답을 기다리는 동안 CPU가 다른 에이전트의 작업을 처리할 수 있다. LLM 에이전트의 특성(대부분의 시간이 LLM 추론 대기)을 고려한 설계다.
평가 논문은 명시하지 않지만, 이 설계 선택은 LLM 에이전트의 I/O 집약적 특성에 최적화된 것이다. 만약 에이전트가 LLM 호출 없이 복잡한 로컬 연산을 수행한다면, 일대일 모드 또는 Ray가 더 유리할 수 있다.
논문은 이 문제를 직접 실험으로 다루었다. 게임 비율을 2/3에서 1/2, 51/100으로 바꾸었을 때 에이전트 행동이 달라지는 것을 관찰하고, 특히 51/100 조건에서는 "이 게임은 '평균의 2/3 추측'의 변형입니다"라는 힌트를 추가했을 때만 에이전트가 합리적으로 행동했다. 이는 LLM이 특정 게임에 대한 사전 지식을 갖고 있음을 시사하며, 연구자들은 새로운 시나리오를 설계할 때 이를 반드시 고려해야 한다.
소스 코드가 GitHub에 공개되어 있으며(modelscope/agentscope), 논문 실험의 전체 예제도 포함되어 있다. to_dist 함수 하나만으로 중앙화된 워크플로우를 분산으로 전환할 수 있어 도입이 비교적 쉽다. 다만 대규모 실험에는 vLLM이 실행 가능한 GPU 클러스터가 필요하다.
논문은 temperature를 0.05, 0.25, 0.50, 1.00으로 바꾸며 1,000명의 에이전트를 테스트했다. 흥미롭게도 temperature가 낮아질수록 표준 편차가 줄어들지만(0.05일 때 6.50, 1.00일 때 8.20), 평균은 크게 변하지 않았다. 즉 temperature는 개별 에이전트의 다양성에 영향을 미치지만, 에이전트 수가 충분히 많을 때 집단 수준의 평균 행동에는 큰 영향을 미치지 않는다. 다양성을 원한다면 temperature를 높게, 재현성을 원한다면 낮게 설정하면 된다.
아래는 논문의 핵심 Figure 원본이다. 각 Figure가 본문 어느 섹션에 해당하는지 함께 표기했다.