Async on Yarang's Tech Lair

ZeroClaw 에이전트 런타임: 고성능 멀티 에이전트 통신을 위한 TCP/IP 아키텍처 구현

Fri, 26 Jun 2026 09:01:09 +0900

안녕하세요! 최근 오픈소스 AI 및 에이전트 생태계가 급격히 확장되면서, 단일 LLM을 넘어 여러 에이전트가 협력하는 ‘멀티 에이전트 시스템’에 대한 관심이 뜨겁습니다. 이전 포스트에서 ZeroClaw 프로젝트의 아키텍처 설계를 다루었는데요, 이번에는 실제 ZeroClaw 런타임이 내부적으로 어떻게 에이전트 간의 통신을 처리하고, Rust의 강력한 비동기 런타임을 활용해 고성능을 달성하는지 그 구체적인 구현 방법을 소개하고자 합니다.

기존 통신의 문제점과 ZeroClaw의 접근

일반적인 MCP(Model Context Protocol)나 기초적인 에이전트 시스템은 주로 단일 프로세스 내의 메모리 공유나 간단한 로컬 함수 호출로 통신을 처리합니다. 하지만 시스템이 복잡해지고 에이전트가 분산되면서 다음과 같은 문제가 발생합니다.

확장성의 한계: 단일 프로세스 메모리 버퍼는 한정되어 있으며, 수백 개의 에이전트가 동시에 메시지를 주고받을 때 병목이 발생합니다.
결합도(Coupling) 증가: 에이전트 간의 통신이 로직에 강하게 결합되어, 특정 에이전트를 교체하거나 업데이트하기 어렵습니다.
네트워크 분리: 로컬 개발 환경과 클라우드 배포 환경 간의 통신 방식이 달라지면 코드를 수정해야 하는 불편함이 있습니다.

ZeroClaw는 이를 해결하기 위해 **‘파일 기반 아키텍처 설계’**와 **‘TCP/IP 네트워킹 계층’**을 결합한 하이브리드 방식을 채택했습니다. 에이전트는 자신의 상태를 파일 시스템에 선언적으로(Declarative) 기록하며, 실제 메시지 전송은 비동기 TCP 소켓을 통해 처리합니다.

Rust Tokio를 활용한 비동기 서버 구조

ZeroClaw의 핵심은 Rust의 tokio 런타임 위에서 구축된 고성능 네트워크 계층입니다. 각 에이전트는 독립적인 태스크(Task)로 실행되며, 채널(Channel)을 통해 안전하게 메시지를 교환합니다.

다음은 ZeroClaw 런타임의 핵심인 메시지 브로커(Message Broker)의 간소화된 구현 예제입니다.

1. 기본 메시지 구조 정의

먼저, 에이전트 간 주고받을 데이터 구조를 정의합니다. serde를 사용하여 직렬화를 자동화합니다.

use serde::{Deserialize, Serialize};
use std::collections::HashMap;

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct AgentMessage {
 pub source: String, // 송신 에이전트 ID
 pub target: String, // 수신 에이전트 ID (혹은 "broadcast")
 pub payload: PayloadType,
}

#[derive(Debug, Clone, Serialize, Deserialize)]
pub enum PayloadType {
 Text(String),
 Data(HashMap<String, String>), // 유연한 데이터 전달을 위한 Map
 Control(ControlSignal),
}

#[derive(Debug, Clone, Serialize, Deserialize)]
pub enum ControlSignal {
 Start,
 Stop,
 HeartBeat,
}

2. 비동기 TCP 핸들러 구현

실제 통신은 tokio::net::TcpListener를 통해 이루어집니다. 각 연결은 별도의 태스크로 분리되어 처리되므로, 특정 에이전트의 느린 응답이 전체 시스템을 멈추게 하지 않습니다.

use tokio::net::{TcpListener, TcpStream};
use tokio::io::{AsyncReadExt, AsyncWriteExt};
use tokio::sync::mpsc;

#[derive(Clone)]
struct AgentConfig {
 id: String,
}

pub async fn run_agent_server(config: AgentConfig) -> Result<(), Box<dyn std::error::Error>> {
 let listener = TcpListener::bind("127.0.0.1:8080").await?;
 println!("[{}] Agent Server listening on 127.0.0.1:8080", config.id);

 // 메시지 라우팅을 위한 채널 (실제 구현에서는 더 복잡한 라우터 사용)
 let (tx, mut rx) = mpsc::channel::<AgentMessage>(1000);

 // 수신 태스크 (스폰)
 let config_clone = config.clone();
 tokio::spawn(async move {
 while let Ok((mut socket, addr)) = listener.accept().await {
 println!("[{}] Connection from {}", config_clone.id, addr);
 let tx_clone = tx.clone();
 tokio::spawn(async move {
 let mut buf = [0; 1024];
 loop {
 let n = match socket.read(&mut buf).await {
 Ok(n) if n == 0 => return, // 연결 종료
 Ok(n) => n,
 Err(e) => {
 eprintln!("Failed to read from socket; err = {:?}", e);
 return;
 }
 };

 // 메시지 파싱 (간소화된 로직)
 let received_data = &buf[..n];
 // 실제로는 여기서 역직렬화 수행
 println!("Received: {:?}", String::from_utf8_lossy(received_data));
 
 // ... (비즈니스 로직 처리) ...
 }
 });
 }
 });

 // 송신 태스크 예시 (주기적 하트비트)
 tokio::spawn(async move {
 let mut interval = tokio::time::interval(tokio::time::Duration::from_secs(5));
 loop {
 interval.tick().await {
 let hb = AgentMessage {
 source: config.id.clone(),
 target: "broadcast".to_string(),
 payload: PayloadType::Control(ControlSignal::HeartBeat),
 };
 // 실제로는 소켓에 쓰거나 외부로 전송
 println!("[{}] Sending Heartbeat...", config.id);
 }
 }
 });

 Ok(())
}

이 코드는 ZeroClaw 에이전트가 다른 에이전트의 요청을 비동기적으로 수신하고, 자신의 상태를 주기적으로 보고하는 기본 뼈대를 보여줍니다. tokio::spawn을 통해 각 연결이 독립적으로 실행되므로, 수천 개의 동시 연결도 효율적으로 처리할 수 있습니다.

팀 에이전트 통신과 프로토콜 설계

단순한 1:1 통신을 넘어, ZeroClaw는 팀(Team) 단위의 통신을 지향합니다. 이는 이전에 논의된 ‘팀 에이전트 통신 아키텍처’와 연결됩니다.

Pub/Sub 패턴: 특정 주제(Topic)를 구독한 에이전트 그룹에게 메시지를 일괄 전달합니다.
피어 투 피어 (P2P): 중앙 서버를 거치지 않고 에이전트 간 직접 통신하여 대기 시간(Latency)을 최소화합니다.

ZeroClaw의 프로토콜은 TCP 계층 위에서 JSON 또는 바이너리 포맷(성능이 중요할 경우 MessagePack 등)으로 캡슐화되어 전송됩니다. 이를 통해 네트워크 추상화 계층(Network Abstraction Layer)을 형성하여, 상위 비즈니스 로직은 통신이 로컬인지 원격인지 신경 쓰지 않고 로직을 작성할 수 있습니다.

결론: 확장 가능한 에이전트 시스템을 향하여

ZeroClaw는 단순한 LLM 래퍼(Wrapper)를 넘어, 진정한 분산 시스템으로 설계되고 있습니다. Rust의 메모리 안전성과 Zero-cost 추상화, 그리고 tokio의 강력한 비동기 처리 능력을 결합하여, 안정적이고 빠른 에이전트 런타임을 구축하고 있습니다.

다음 포스트에서는 이러한 통신 아키텍처 위에서 LLM이 어떻게 자신의 의사를 결정(Decision)하고, MCP 도구를 통해 실제 행동을 수행하는지 그 플로우를 디버깅해보겠습니다.

참고 코드 및 리소스

ZeroClaw GitHub Repository (오픈소스 준비 중)
The Garbage Collection Handbook: The Art of Automatic Memory Management (2nd Ed) - 최근 뉴스에서 언급되었던 메모리 관리의 고전이자 바이블입니다.

읽어주셔서 감사합니다!

[ZeroClaw] 비동기 에이전트 런타임을 위한 Rust 채널 기반 IPC 설계

Thu, 11 Jun 2026 09:00:42 +0900

[ZeroClaw] 비동기 에이전트 런타임을 위한 Rust 채널 기반 IPC 설계

안녕하세요. 최근 ZeroClaw 프로젝트의 핵심인 ‘멀티 에이전트 아키텍처’를 고도화하면서, 단순한 메시지 전달을 넘어 고성능 비동기 통신(IPC, Inter-Process Communication) 환경을 구축한 경험을 공유하고자 합니다.

기존의 동기적 통신 방식은 에이전트 간 결합도를 높이고, 한 에이전트의 장애가 전체 시스템을 멈추게 만드는 병목 구간(Single Point of Failure)이 되었습니다. 이를 해결하기 위해 Rust의 강력한 동시성 기능인 tokio 런타임과 MPSC(Multi-Producer, Single-Consumer) 채널을 활용하여 이벤트 기반의 느슨한 결합 아키텍처를 설계했습니다.

이번 포스트에서는 에이전트 런타임의 효율성을 극대화하기 위해 채널을 어떻게 설계하고 구현했는지, 실제 코드와 함께 살펴보겠습니다.

1. 기존 아키텍처의 문제점과 비동기 설계의 필요성

이전까지의 ZeroClaw 에이전트는 메시지를 요청(Request)하고 응답(Response)을 기다리는 동기식 RPC 패턴을 주로 사용했습니다. 하지만 에이전트가 수십 개로 늘어나고 복잡한 작업(예: 파일 기반 아키텍처 분석, 대규모 로그 처리)을 수행하게 되면서 다음과 같은 문제가 발생했습니다.

블로킹(Blocking) 문제: A 에이전트가 B 에이전트의 응답을 기다리는 동안, A 에이전트는 다른 작업을 수행할 수 없습니다.
복잡한 에러 전파: 특정 에이전트가 뻗거나 타임아웃이 발생했을 때, 호출 체인 상위에 있는 에이전트들로 에러를 전달하기 복잡했습니다.

이를 해결하기 위해 우리는 **“에이전트는 메시지를 보내고 즉시 다른 작업을 수행한다, 처리된 결과는 이벤트로 수신한다”**는 비동기 패턴을 채택했습니다.

2. Rust의 `tokio::sync::mpsc`를 활용한 이벤트 루프 구조

Rust의 tokio 크레이트가 제공하는 MPSC 채널은 높은 처리량과 낮은 지연 시간을 보장하며, 에이전트 런타임에 최적화되어 있습니다. 각 에이전트는 자신만의 **Task(작업 단위)**를 가지며, 이는 tokio::spawn을 통해 독립적으로 실행됩니다.

핵심 설계 포인트

Message Bus: 각 에이전트는 송신자(tx)와 수신자(rx)를 보유합니다.
Event Loop: 수신자(rx)는 무한 루프(loop)를 돌며 메시지가 도착할 때까지 비동기적으로 대기(recv())합니다.

3. 실전 코드: 구체적인 구현 예제

이제 실제로 ZeroClaw 런타임 내에서 에이전트들이 통신하는 코드를 작성해 보겠습니다.

Step 1: 메시지 프로토콜 정의

먼저 에이전트 간 주고받을 데이터 구조를 정의해야 합니다. 이때 Enum을 사용하여 메시지의 타입을 안전하게 관리하는 것이 좋습니다.

// Cargo.toml dependencies
// [dependencies]
// tokio = { version = "1", features = ["full"] }
// serde = { version = "1", features = ["derive"] }

use tokio::sync::mpsc;
use serde::{Serialize, Deserialize};

#[derive(Debug, Serialize, Deserialize)]
enum AgentMessage {
 TaskAssigned { task_id: String, description: String },
 TaskCompleted { task_id: String, result: String },
 StatusCheck,
}

Step 2: 에이전트 구조체 및 러너(Runner) 구현

각 에이전트는 고유 ID와 수신자(rx)를 가집니다. run 메서드는 에이전트의 생명주기를 관리하는 핵심 함수입니다.

struct Agent {
 id: String,
 rx: mpsc::Receiver<AgentMessage>,
}

impl Agent {
 fn new(id: String, rx: mpsc::Receiver<AgentMessage>) -> Self {
 Self { id, rx }
 }

 async fn run(mut self) {
 println!("[{}] Agent started. Listening for messages...", self.id);
 
 // 메시지 수신 대기 (비동기)
 while let Some(msg) = self.rx.recv().await {
 match msg {
 AgentMessage::TaskAssigned { task_id, description } => {
 println!("[{}] Received task: {} - {}", self.id, task_id, description);
 // 실제 로직 처리 (예: 파일 분석, 외부 API 호출)
 // 여기서는 예시를 위해 1초 대기 후 완료 메시지를 전송한다고 가정합니다.
 }
 AgentMessage::StatusCheck => {
 println!("[{}] Status: Active", self.id);
 }
 _ => {}
 }
 }
 println!("[{}] Agent shutting down.", self.id);
 }
}

Step 3: 메인 런타임 및 채널 연결

메인 함수에서는 여러 에이전트를 생성하고 채널을 연결한 뒤, tokio::spawn을 통해 병렬로 실행시킵니다.

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
 // 1. 채널 생성 (용량 32)
 let (tx, rx) = mpsc::channel::<AgentMessage>(32);

 // 2. 에이전트 생성 및 실행 (비동기 태스크로 분리)
 let agent_handle = {
 let agent = Agent::new("Agent-A".to_string(), rx);
 tokio::spawn(async move {
 agent.run().await;
 })
 };

 // 3. 메인 런타임에서 메시지 송신
 // 다른 에이전트나 API 서버가 이 tx를 사용하여 메시지를 보낼 수 있습니다.
 
 // 작업 할당
 let _ = tx.send(AgentMessage::TaskAssigned {
 task_id: "T-101".to_string(),
 description: "Analyze server logs".to_string(),
 }).await;

 // 상태 확인
 let _ = tx.send(AgentMessage::StatusCheck).await;

 // 4. 에이전트가 작업을 마칠 때까지 대기 (실제 환경에서는 계속 실행됨)
 drop(tx); // 송신자 종료 -> 채널 닫힘 -> 에이전트 루프 종료 조건 성립
 
 agent_handle.await?;
 
 Ok(())
}

4. ZeroClaw 프로젝트 적용 효과

위와 같은 구조를 ZeroClaw 런타임에 적용한 결과 다음과 같은 이점을 얻었습니다.

병렬 처리 성능 향상: 에이전트가 자신만의 tokio 태스크 내에서 실행되므로, CPU 코어를 효율적으로 활용할 수 있었습니다.
결합도 감소: 메인 로직이 특정 에이전트의 내부 구현을 알 필요 없이, 단순히 tx.send만 호출하면 됩니다.
그레이스풀 셧다운(Graceful Shutdown): drop(tx)를 통해 채널을 닫으면, 에이전트는 더 이상 메시지가 오지 않음을 감지하고 자연스럽게 while let 루프를 빠져나와 종료합니다.

마치며

Rust의 소유권(Ownership) 시스템과 tokio의 비동기 추상화는 멀티 에이전트 시스템 구축에 있어 강력한 무기가 됩니다. 다음 포스트에서는 이 에이전트들이 파일 기반 아키텍처와 결합하여 상태를 어떻게 영속화하는지 다루도록 하겠습니다.

ZeroClaw의 고성능 에이전트 런타임 개발은 계속됩니다.

MCP 서버 성능 최적화: Rust로 구축하는 초고속 처리 파이프라인

Wed, 03 Jun 2026 09:00:50 +0900

MCP 서버 성능 최적화: Rust로 구축하는 초고속 처리 파이프라인

최근 LLM(Large Language Model)을 활용한 에이전트 시스템이 개발 생태계의 핫한 이슈가 되면서, 이를 지원하는 인프라인 MCP(Model Context Protocol) 서버의 중요성이 커지고 있습니다. 이전 포스트에서 ZeroClaw와 같은 고성능 런타임을 언급하며 멀티 에이전트 아키텍처를 다루었지만, 오늘은 MCP 서버 자체의 **처리량(Throughput)과 대기 시간(Latency)**을 극적으로 개선하는 Rust 기반의 최적화 기법을 집중적으로 다루고자 합니다.

단순히 “빠르다"는 말만으로는 부족합니다. 수천 개의 Tool Call이 동시에 들어오는 상황에서 서버가 얼마나 효율적으로 리소스를 관리하는지가 핵심입니다. 특히 최근 트렌드인 AI 에이전트들이 RSS 피드나 실시간 데이터를 수집할 때, I/O 바운드 작업이 병목이 되는 경우가 많습니다.

이 글에서는 Rust의 강력한 비동기 런타임인 Tokio를 활용하여 병목 지점을 제거하고, 안전하면서도 빠른 코드를 작성하는 구체적인 방법을 소개합니다.

1. 문제 정의: 단일 스레드 병목

기본적으로 Python이나 Node.js로 작성된 간단한 MCP 서버는 싱글 스레드 이벤트 루프에 의존하는 경우가 많습니다. 이는 I/O 작업이 많을 때 유리하지만, 데이터 가공이나 복잡한 로직이 포함된 MCP 툴을 처리할 때 CPU 코어를 하나만 사용하기 때문에 한계가 명확합니다.

예를 들어, 블로그 자동화 시스템을 구축할 때 대량의 이미지를 처리하거나 로그를 파싱하는 과정에서 CPU 점유율이 100%에 도달하면 다른 요청은 대기열에 쌓이게 됩니다. 우리는 이를 멀티 스레드 비동기 처리로 해결해야 합니다.

2. Rust와 Tokio를 활용한 비동기 처리

Rust는 ‘Zero-cost abstractions’를 통해 안전성과 성능을 모두 잡을 수 있습니다. MCP 서버의 핵심 로직인 툴 실행(Tool Execution) 부분을 tokio::spawn을 이용해 병렬화해 보겠습니다.

기본 설정 (Cargo.toml)

먼저 의존성 파일에 Tokio를 추가합니다.

[dependencies]
tokio = { version = "1", features = ["full"] }
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"

비동기 핸들러 구현 예제

아래 코드는 들어오는 요청을 별도의 태스크(Task)로 분리하여 처리하는 간단한 MCP 서버의 핸들러 구조입니다.

use tokio::net::TcpListener;
use tokio::io::{AsyncReadExt, AsyncWriteExt};
use serde::{Deserialize, Serialize};
use std::sync::Arc;

// MCP 요청 메시지 구조 정의
#[derive(Debug, Deserialize)]
struct McpRequest {
 id: String,
 method: String,
 params: serde_json::Value,
}

#[derive(Debug, Serialize)]
struct McpResponse {
 id: String,
 result: serde_json::Value,
}

// 무거운 작업을 시뮬레이션하는 함수
async fn process_heavy_tool(params: serde_json::Value) -> Result<String, String> {
 // 실제 환경에서는 여기서 DB 조회나 파일 I/O 발생
 // tokio::time::sleep을 통해 비동기 대기 시뮬레이션
 tokio::time::sleep(tokio::time::Duration::from_secs(2)).await;
 Ok(format!("Processed: {}", params))
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error>> {
 let listener = TcpListener::bind("127.0.0.1:8080").await?;
 println!("MCP Server listening on {}", listener.local_addr()?);

 loop {
 let (mut socket, _) = listener.accept().await?;

 // 연결이 들어올 때마다 새로운 태스크 생성 (병렬 처리)
 tokio::spawn(async move {
 let mut buf = [0; 1024];

 loop {
 let n = match socket.read(&mut buf).await {
 Ok(n) if n == 0 => return, // 연결 종료
 Ok(n) => n,
 Err(e) => {
 eprintln!("Failed to read from socket; err = {:?}", e);
 return;
 }
 };

 let req_str = String::from_utf8_lossy(&buf[0..n]);
 
 // JSON 파싱 및 처리 로직 (에러 처리 생략)
 if let Ok(req) = serde_json::from_str::<McpRequest>(&req_str) {
 let req_id = req.id.clone();
 
 // 핵심: 비동기 함수를 spawn하여 블로킹 없이 처리
 let handle = tokio::spawn(async move {
 process_heavy_tool(req.params).await
 });

 // 결과 대기 및 응답 (실제 구현에선 채널 사용 권장)
 if let Ok(Ok(result)) = handle.await {
 let resp = McpResponse {
 id: req_id,
 result: serde_json::json!(result),
 };
 
 if let Ok(serialized) = serde_json::to_string(&resp) {
 let _ = socket.write_all(serialized.as_bytes()).await;
 }
 }
 }
 }
 });
 }
}

이 코드의 핵심은 tokio::spawn을 사용하여 각 요청이 메인 루프를 차단하지 않고 독립적으로 실행된다는 점입니다.

3. 스트리밍(Streaming)을 통한 메모리 최적화

대용량 파일 처리나 로그 전송 시, 모든 데이터를 메모리(RAM)에 올리는 것은 치명적입니다. Rust의 Stream을 활용하면 데이터를 청크(Chunk) 단위로 처리하여 메모리 사용량을 일정하게 유지할 수 있습니다.

특히 앞서 언급된 [blog-api-server] 로깅 개선 사항이나 Cloud Monitor 관련 작업에서 유용하게 쓰일 수 있습니다.

use futures::stream::{Stream, StreamExt};
use std::pin::Pin;

// 가상의 로그 데이터 생성 스트림
fn log_stream() -> Pin<Box<dyn Stream<Item = String> + Send>> {
 Box::pin(async_stream::stream! {
 for i in 0..1000 {
 yield format!("Log entry #{}\n", i);
 tokio::time::sleep(tokio::time::Duration::from_millis(10)).await;
 }
 })
}

// 스트림 처리 예시
async fn process_logs() {
 let mut stream = log_stream();
 while let Some(log_entry) = stream.next().await {
 // 실시간으로 한 줄씩 처리 (파일 쓰기 or 전송)
 println!("Processing: {}", log_entry);
 }
}

4. 결론: ZeroClaw를 향하여

우리가 목표로 하는 ZeroClaw 런타임은 이러한 비동기 처리와 메모리 안전성을 기본으로 제공해야 합니다. 단순히 기존 파이썬 스크립트를 Rust로 포팅하는 것을 넘어, Tokio의 스케줄링과 Zero-copy 직렬화를 적극 활용해야만 수천 개의 에이전트가 동시에 통신하는 환경을 견딜 수 있습니다.

다음 포스트에서는 이러한 고성능 서버 위에서 동작하는 에이전트 간 통신 프로토콜을 설계하는 방법에 대해 다루겠습니다.

Rust로 구현하는 고성능 MCP 서버: ZeroMQ를 활용한 비동기 메시징

Sun, 10 May 2026 09:01:24 +0900

Rust로 구현하는 고성능 MCP 서버: ZeroMQ를 활용한 비동기 메시징

최근 ZeroClaw 프로젝트를 진행하며 MCP(Model Context Protocol) 서버의 성능 한계를 뛰어넘을 필요성이 생겼습니다. 기존의 HTTP 기반 통신은 단일 요청-응답 패턴을 벗어나기 어렵고, 수많은 LLM 에이전트 간의 실시간 통신에는 병목이 발생하기 쉽습니다. 이번 포스트에서는 Rust의 강력한 비동기 처리 능력과 ZeroMQ(ØMQ)를 결용하여 초경량 초고속 MCP 서버를 구축하는 과정을 다룹니다.

왜 ZeroMQ인가? (TCP 소켓의 한계와 비교)

기존 blog-api-server 아키텍처에서는 표준 TCP 스트림을 사용하여 프로토콜을 직접 정의하고 사용했습니다. 하지만 멀티 에이전트 환경에서는 다음과 같은 문제가 발생합니다.

Connection Management(연결 관리) 복잡도: 에이전트가 수십 개씩 늘어날 때, Accept 루프와 소켓 상태 관리를 위한 unsafe 코드나 복잡한 상태 머신(State Machine)이 필요합니다.
Message Enveloping(메시지 봉투): TCP는 바이트 스트림입니다. 메시지의 경계를 구분하기 위해 Length-Prefixing을 직접 구현해야 하며, 이는 버그의 주요 원인이 됩니다.

ZeroMQ는 이러한 하부 소켓 계층의 복잡성을 추상화하면서, TCP보다 빠른 “사용자 공간(User Space)” 전송 계층을 제공합니다. 특히 ipc(Inter-Process Communication) 프로토콜을 사용하면 로컬호스트 통신에서 네트워크 스택 오버헤드를 완전히 제거할 수 있습니다.

아키텍처 설계: ZeroMQ PUB/SUB 패턴

이번 구현에서는 에이전트 간 느슨한 결합을 위해 Publish/Subscribe(PUB/SUB) 패턴을 사용합니다. 하나의 에이전트가 상태를 변경(Publish)하면, 해당 토픽을 구독하는 다른 에이전트들에게 즉시 메시지가 브로드캐스트됩니다.

주요 의존성 (Cargo.toml)

Rust 생태계에서 ZeroMQ는 zmq 크레이트를 통해 사용할 수 있습니다. 비동기 런타임과의 통합을 위해 tokio-zmq를 사용할 수도 있지만, 순수 성능을 위해 zmq의 poll 기능을 활용하는 것이 더 안정적일 때가 많습니다.

[dependencies]
zmq = "0.10"
serde = { version = "1.0", features = ["derive"] }
serde_json = "1.0"
tokio = { version = "1", features = ["full"] }

구현: 고성능 MCP Router

아래 코드는 간단한 메시지 브로커 역할을 하는 MCP Router의 구현 예제입니다. 이는 여러 LLM 에이전트(팀)가 서로 통신할 수 있는 중앙 허브 역할을 합니다.

1. 메시지 프로토콜 정의

먼저, 에이전트 간에 오가는 메시지 형식을 정의합니다. JSON 직렬화를 사용하여 호환성을 확보합니다.

use serde::{Deserialize, Serialize};

#[derive(Debug, Serialize, Deserialize)]
struct McpMessage {
 pub source_id: String,
 pub target_topic: String,
 pub payload: String,
 pub timestamp: i64,
}

2. 비동기 ZeroMQ 컨텍스트 및 소켓 설정

ZeroMQ의 Context는 스레드 안전(Thread-safe)하므로, 애플리케이션 전역에서 하나만 생성하여 공유하는 것이 일반적입니다.

ouse std::time::SystemTime;
use zmq::{Context, Socket, SocketType};

struct McpRouter {
 context: Context,
 frontend: Socket, // Agents connect here
 // 필요시 다른 패턴의 소켓 추가 가능
}

impl McpRouter {
 fn new() -> Result<Self, zmq::Error> {
 let context = Context::new();
 let frontend = context.socket(SocketType::SUB)?;
 
 // 모든 메시지를 수신하도록 설정 (필터링 없음)
 frontend.set_subscribe(b"")?;
 
 Ok(McpRouter { context, frontend })
 }

 fn start(&self, endpoint: &str) -> Result<(), zmq::Error> {
 self.frontend.bind(endpoint)?;
 println!("[ZeroClaw Router] Listening on {}", endpoint);

 let mut msg = zmq::Message::new();
 loop {
 // Non-blocking receive를 위해 poll 사용 가능
 // 여기서는 간단한 blocking receive 예시
 match self.frontend.recv(&mut msg) {
 Ok(_) => {
 let data = msg.as_str().unwrap();
 // 메시지 파싱 및 라우팅 로직
 if let Ok(mcp_msg) = serde_json::from_str::<McpMessage>(data) {
 self.route_message(mcp_msg);
 }
 }
 Err(e) => {
 eprintln!("Receive Error: {}", e);
 }
 }
 }
 }

 fn route_message(&self, msg: McpMessage) {
 // 실제 라우팅 로직 구현
 println!("Routing from {} on topic {}", msg.source_id, msg.target_topic);
 // 예: 데이터베이스 저장, 다른 소켓으로 전달 등
 }
}

3. 에이전트 발행(Publisher) 구현

이제 개별 에이전트가 메시지를 보내는 코드를 작성해 보겠습니다. tokio와 함께 사용할 때는 별도의 스레드에서 ZeroMQ의 blocking 함수를 실행해야 비동기 런타임을 방해하지 않습니다.

use std::thread;

fn spawn_publisher_agent(id: &str, endpoint: &str) {
 let context = Context::new();
 let sender = context.socket(SocketType::PUB).expect("Failed to create PUB socket");
 sender.connect(endpoint).expect("Failed to connect to Router");

 // 별도 스레드에서 실행하여 Tokio 런타임과 분리
 thread::spawn(move || {
 let counter = 0..100;
 for i in counter {
 let msg = McpMessage {
 source_id: id.to_string(),
 target_topic: "general".to_string(),
 payload: format!("Message #{} from agent {}", i, id),
 timestamp: SystemTime::now().duration_since(SystemTime::UNIX_EPOCH).unwrap().as_secs() as i64,
 };

 let json_str = serde_json::to_string(&msg).unwrap();
 // ZeroMQ는 전송 실패 시 자동으로 재시도하거나 큐에 쌓음 (High-water mark 설정 필요 시)
 sender.send(json_str.as_bytes(), 0).expect("Failed to send");
 
 thread::sleep(std::time::Duration::from_millis(100));
 }
 });
}

성능 최적화 및 IPC 활용

Rust ZeroMQ 서버의 진정한 힘은 IPC(Inter-Process Communication) 트랜스포트를 사용할 때 발휘됩니다. TCP를 사용하면 패킷이 네트워크 스택을 거쳐 루프백(Loopback) 되지만, IPC는 Unix Domain Socket이나 Windows Named Pipes를 사용하여 메모리 복사 수준에 가까운 속도로 통신합니다.

ipc 프로토콜을 사용하려면 엔드포인트를 다음과 같이 변경하면 됩니다.

// TCP 대신 IPC 사용
let endpoint = "ipc:///tmp/mcp_router.ipc";
router.start(endpoint);

Bun이나 Zig 같은 최신 언어들이 시스템 레벨 최적화를 통해 주목받는 것처럼, Rust와 ZeroMQ의 조합은 LLM 애플리케이션의 “시스템 버스"를 구축하는 데 있어 가장 강력한 도구입니다.

결론

이번 글에서는 ZeroClaw 프로젝트의 일환으로, Rust와 ZeroMQ를 사용하여 고성능 MCP 서버를 구축하는 방법을 살펴보았습니다. 단순한 HTTP 요청을 넘어, 에이전트 간 실시간 메시징이 필요한 환경에서 이 아키텍처는 확장성과 성능 면에서 큰 이점을 제공합니다.

다음 포스트에서는 이 메시징 시스템에 안정성을 더해주는 Circuit Breaker 패턴과 에러 핸들링 전략을 다루겠습니다.

Async on Yarang's Tech Lair

ZeroClaw 에이전트 런타임: 고성능 멀티 에이전트 통신을 위한 TCP/IP 아키텍처 구현

기존 통신의 문제점과 ZeroClaw의 접근

Rust Tokio를 활용한 비동기 서버 구조

1. 기본 메시지 구조 정의

2. 비동기 TCP 핸들러 구현

팀 에이전트 통신과 프로토콜 설계

결론: 확장 가능한 에이전트 시스템을 향하여

참고 코드 및 리소스

[ZeroClaw] 비동기 에이전트 런타임을 위한 Rust 채널 기반 IPC 설계

[ZeroClaw] 비동기 에이전트 런타임을 위한 Rust 채널 기반 IPC 설계

1. 기존 아키텍처의 문제점과 비동기 설계의 필요성

2. Rust의 tokio::sync::mpsc를 활용한 이벤트 루프 구조

핵심 설계 포인트

3. 실전 코드: 구체적인 구현 예제

Step 1: 메시지 프로토콜 정의

Step 2: 에이전트 구조체 및 러너(Runner) 구현

Step 3: 메인 런타임 및 채널 연결

4. ZeroClaw 프로젝트 적용 효과

마치며

MCP 서버 성능 최적화: Rust로 구축하는 초고속 처리 파이프라인

MCP 서버 성능 최적화: Rust로 구축하는 초고속 처리 파이프라인

1. 문제 정의: 단일 스레드 병목

2. Rust와 Tokio를 활용한 비동기 처리

기본 설정 (Cargo.toml)

비동기 핸들러 구현 예제

3. 스트리밍(Streaming)을 통한 메모리 최적화

4. 결론: ZeroClaw를 향하여

Rust로 구현하는 고성능 MCP 서버: ZeroMQ를 활용한 비동기 메시징

Rust로 구현하는 고성능 MCP 서버: ZeroMQ를 활용한 비동기 메시징

왜 ZeroMQ인가? (TCP 소켓의 한계와 비교)

아키텍처 설계: ZeroMQ PUB/SUB 패턴

주요 의존성 (Cargo.toml)

구현: 고성능 MCP Router

1. 메시지 프로토콜 정의

2. 비동기 ZeroMQ 컨텍스트 및 소켓 설정

3. 에이전트 발행(Publisher) 구현

성능 최적화 및 IPC 활용

결론

참고 자료

2. Rust의 `tokio::sync::mpsc`를 활용한 이벤트 루프 구조