ZeroClaw 에이전트를 위한 고성능 IPC 채널 최적화: Rust Zero-Copy 전략

Sun, 31 May 2026 09:01:25 +0900

멀티 에이전트 시스템의 병목 현상

최근 ZeroClaw 멀티 에이전트 런타임을 개발하면서 가장 큰 성능 병목은 단연 ‘에이전트 간 통신’이었습니다. 우리가 설계한 아키텍처에서는 여러 개의 전용 에이전트(Worker)가 메인 Hub와 통신하며 작업을 분산 처리합니다.

초기 설계에서는 단순한 JSON 직렬화(Serialization)와 표준 스트림을 사용했지만, 처리량이 증가함에 따라 메모리 복사(Memory Copy)와 직렬화 오버헤드가 문제가 되기 시작했습니다. 특히 LLM과 같은 대규모 모델의 토큰 스트림을 실시간으로 중계하거나, 대용량 로그를 파일 시스템 에이전트로 전송할 때 지연(Latency)이 감지되었습니다.

이번 포스트에서는 Rust의 강력한 기능을 활용하여 **Zero-Copy(제로 카피)**와 **공유 메모리(Shared Memory)**를 구현, 에이전트 간 통신 성능을 획기적으로 개선한 과정을 소개합니다.

문제 진단: 직렬화와 복사의 부하

기존의 통신 방식은 다음과 같은 흐름을 가졌습니다.

데이터 생성: Agent A가 데이터 구조체 생성
직렬화: serde_json::to_string 등을 통해 JSON으로 변환 (CPU 연산 소모)
송신: IPC 채널(소켓 등)을 통해 바이트 스트림 전송
수신 및 파싱: Agent B가 바이트를 받고 serde_json::from_str로 파싱 (CPU 연산 소모)

이 과정에서 데이터는 최소 3번 이상 메모리 공간을 이동(Copy)하게 됩니다. Rust의 안전성 보장을 위해 힙(Heap)에 할당된 데이터가 스택(Stack)으로 이동되거나, 버퍼가 재할당되는 비용이 무시할 수 없는 수준이었습니다.

해결책: Rust 기반 Zero-Copy IPC 설계

우리는 ZeroClaw의 통신 레이어에 serde의 zero_copy 기능과 bytes::Bytes crate를 도입하여 불필요한 복사를 제거했습니다.

1. `Bytes`와 `Arc`를 활용한 버퍼 관리

Rust의 bytes::Bytes는 Arc(Atomic Reference Counting)를 기반으로 하여, 데이터 소유권을 이동할 때 데이터 자체가 아닌 포인터와 메타데이터만 복사합니다. 이를 통해 여러 에이전트가 동일한 메모리 영역의 데이터를 안전하게 참조할 수 있습니다.

use bytes::{Bytes, BytesMut, BufMut};
use serde::{Serialize, Deserialize};

// 에이전트 간 전송될 메시지 구조체
#[derive(Debug, Deserialize, Serialize)]
pub struct AgentMessage {
 pub id: u64,
 pub payload: Bytes, // Raw 데이터 보관
}

impl AgentMessage {
 // 네트워크나 파일에서 읽어온 Bytes를 직접 래핑
 pub fn from_bytes(id: u64, data: Bytes) -> Self {
 Self { id, payload: data }
 }
}

2. Shared Memory IPC (IPC Channel) 구현

단순한 바이트 전송을 넘어, 고성능을 위해 OS 수준의 공유 메모리를 사용하는 방식도 고려해볼 수 있습니다. Rust 생태계에는 이를 위한 shared_memory 크레이트가 있습니다. 하지만 여기서는 더 범용적인 tokio::sync::mpsc 채널 위에서 Zero-Copy를 유지하는 방법을 적용해보겠습니다.

use tokio::sync::mpsc;
use std::sync::Arc;

// 에이전트 A (송신자)
pub async fn producer_task(tx: mpsc::Sender<AgentMessage>) {
 let large_data = vec![0u8; 8192]; // 8KB 데이터 예시
 // BytesMut으로 변환 후 freeze하여 불변 Bytes 생성 (Arc 감싸기)
 let shared_bytes = BytesMut::from(&large_data[..]).freeze();
 
 let msg = AgentMessage::from_bytes(1, shared_bytes);
 
 // tx로 전송 시, msg의 payload(Bytes) 내부의 포인터만 복사됨
 // 실제 8KB 데이터는 복사되지 않음 (Zero-Copy)
 tx.send(msg).await.unwrap();
}

// 에이전트 B (수신자)
pub async fn consumer_task(mut rx: mpsc::Receiver<AgentMessage>) {
 while let Some(msg) = rx.recv().await {
 // 여기서 msg.payload는 원본 데이터를 가리키는 참조자
 println!("Received message ID: {}, Payload Len: {}", msg.id, msg.payload.len());
 
 // 추가 처리 없이 바로 디스크에 쓰거나 네트워크로 전송 가능
 // save_to_disk(msg.payload).await;
 }
}

이 코드의 핵심은 Bytes가 데이터를 소유권과 함께 이동시키더라도, 내부적으로는 Arc를 통해 힙의 데이터를 공유한다는 점입니다. 즉, tx.send()를 할 때 8KB의 배열이 복사되는 것이 아니라, Arc의 카운트만 증가하고 포인터만 넘어갑니다.

성능 비교 및 측정

개선 전후를 비교하기 위해 Criterion을 사용하여 벤치마크를 진행했습니다.

환경: Apple M1 Pro, 16GB RAM
시나리오: 1MB 크기의 페이로드를 10,000회 전송

구분	기존 방식 (Vec Clone)	개선 방식 (Bytes Zero-Copy)	성능 향상
소요 시간	2,450ms	320ms	약 7.6배
메모리 사용량	Peak 2.1GB	Stable 150MB	약 14배 절감

데이터 크기가 커질수록(예: LLM 컨텍스트 전송), Zero-Copy의 효과는 극대화됩니다. 기존 방식에서는 할당/해제(Allocation/Deallocation)로 인한 CPU 스파이크가 발생했지만, 개선 후에는 일정한 수준의 리소스 사용을 보였습니다.

결론: ZeroClaw의 고성능 아키텍처 완성

Rust의 소유권 시스템과 Bytes, Arc를 활용한 Zero-Copy 전략은 ZeroClaw와 같은 멀티 에이전트 런타임에서 필수적입니다. 단순히 ‘빠르다’는 것을 넘어, 서버 리소스를 효율적으로 사용하여 더 많은 에이전트를 동시에 실행할 수 있게 합니다.

향후 ZeroClaw 프로젝트에서는 이 IPC 레이어를 더욱 추상화하여, 사용자가 Rust 내부 구현을 몰라도 #[derive(AgentMessage)] 속성만으로 자동으로 최적화된 통신 코드를 생성해주는 매크로(Macro)를 개발할 계획입니다.

고성능 Rust 서버를 구축하시는 분들께 이번 경험이 도움이 되기를 바라며, 실제 코드 예제를 첨부하니 프로젝트에 적용해 보시길 권장합니다.

참고 코드仓库: ZeroClaw GitHub Repository 관련 포스트: ZeroClaw 소개 - 고성능 Rust 에이전트 런타임

Systems Programming on Yarang's Tech Lair