AURA: 구조를 먼저 협상하고, 변경 사항만 전송하라
요약
AURA는 에이전트 간 통신 시 발생하는 중복된 JSON 구조를 최적화하기 위한 프로토콜 인식 데이터 이동 툴킷입니다. AIWire 기술을 통해 구조를 먼저 협상하고 변경된 델타 값만 전송함으로써 통신 효율을 극대화합니다.
핵심 포인트
- 에이전트 트래픽의 반복적인 JSON 구조 문제를 해결
- AIWire를 통한 구조 협상 및 델타(delta) 전송 방식 도입
- 상태 비저장 압축(gzip 등)의 한계인 설정 비용과 이력 손실 극복
- 의미/메시지 차선과 제어/세션 차선으로 분리된 3개 차선 모델 설계
에이전트 트래픽(Agent traffic)에는 기묘한 특성이 있습니다. 거의 모든 바이트가 반복된다는 점입니다. MCP 도구 호출(tool calls), A2A 작업 업데이트, 또는 OpenAI 스타일의 함수 호출(function calls)을 교환하는 두 AI 시스템은 jsonrpc, method, params, trace_id, task_id 및 동일한 스키마(schema) 조각들을 분당 수천 번씩 전송합니다. 값은 변하지만, 구조는 거의 변하지 않습니다.
AURA는 이러한 관찰을 바탕으로 구축된 실험적인 프로토콜 인식(protocol-aware) 데이터 이동 툴킷입니다. 이 툴킷의 핵심 경로는 AIWire입니다. 이는 협상된 구조 사이드 채널(negotiated structure side channel)로, 두 피어(peer)가 메시지 구조에 대해 한 번 합의하면, 전체 JSON 프레임(frame)을 다시 보내는 대신 일반적인 TCP, WebSocket, HTTP 또는 브로커(broker) 링크를 통해 압축된 델타(delta, 차이점)를 전송할 수 있게 합니다.
AIWire가 목표로 하는 정상 상태(steady state)는 "전체 프레임을 더 저렴하게 보내는 것"이 아닙니다. 그것은 바로 "구조를 먼저 협상하고, 그 다음 변경 사항을 보내는 것"입니다.
상태 비저장 압축(Stateless compression)이 많은 것을 놓치는 이유
장황한 JSON에 대한 명백한 해결책은 메시지당 gzip 또는 zlib을 사용하는 것입니다. 그것도 작동하지만, 에이전트 트래픽에 있어서는 두 가지 구조적인 문제가 있습니다.
- 모든 프레임이 설정 비용을 지불합니다. 상태 비저장 압축(Stateless compression)은 각 메시지를 서로 관련 없는 텍스트로 취급하며, 매번 동일한 패턴을 다시 찾아냅니다.
- 이력이 버려집니다. 세션의 4,000번째 프레임은 3,999번째 프레임과 거의 동일해 보이지만, 프레임 단위의 코덱(codec)은 이를 활용할 수 없습니다.
AIWire는 전체 세션 동안 방향별로 라이브 압축 스트림(live compression stream)을 유지하고, 일반적인 AI 프로토콜 필드의 정적 사전(static dictionary)으로 시드(seed)를 제공하며, 피어들이 그 위에 세션별 템플릿(template)을 협상할 수 있도록 합니다. 핸드셰이크(handshake) 이후, 핫 패스(hot path)는 양측이 이미 공유하고 있는 구조에 대해 변경된 내용만을 전달합니다.
3개 차선 모델 (The three-lane model)
제가 가장 흥미롭다고 생각하는 설계 부분은 AIWire가 연결을 하나의 차별화되지 않은 파이프(pipe)로 취급하기를 거부한다는 점입니다. AIWire는 기존에 사용 중인 전송 계층(transport) 위에서 AI 트래픽을 세 가지 논리적 차선으로 분리합니다:
**의미/메시지 차선 (The semantic/message lane)**은 실제 에이전트 메시지인 MCP 도구 호출 (tool calls), JSON-RPC 요청 및 응답, A2A 작업 및 아티팩트 (artifact) 업데이트, 트레이스 (traces), 핸드오프 (handoffs), 결과 등을 전달합니다. 이 차선은 사전 (dictionary), 세션 템플릿 (session templates), 그리고 상태 유지 델타 스트림 (stateful delta stream)에 의해 최적화됩니다.
**제어/세션 차선 (The control/session lane)**은 의미 차선을 안전하게 유지하는 메커니즘인 핸드셰이크 (handshakes), 템플릿 발견 (template discovery), 사전 차이 (dictionary diffs), ACK/NACK, 재개 협상 (resume negotiation), 하트비트 (heartbeats), 그리고 리셋 신호 (reset signals)를 전달합니다. 스펙(spec)에 따르면 제어 메시지는 의미 스트림 (semantic stream)을 팽창시키지 않으면서도 디코딩 가능한 상태를 유지해야 합니다. 만약 압축된 스트림이 재동기화 (resyncing) 중이거나 실패하더라도, 제어 차선을 읽어 복구할 수 있습니다. 운영 경로 (ops path)는 자신이 수정하려고 시도하는 압축 상태 (compression state)의 건전성에 결코 의존하지 않습니다.
**블롭 기술자 차선 (The blob descriptor lane)**은 구조화된 메시지 코덱 (structured-message codec)을 전혀 거쳐서는 안 되는 항목들, 즉 미디어, 텐서 청크 (tensor chunks), 모델 아티팩트 (model artifacts), 로그 아카이브 (log archives)를 처리합니다. 바이트 데이터는 일반적인 블롭 (blob) 또는 파일 전송 계층 (file transport)을 통해 이동합니다. AIWire는 콘텐츠 유형 (content type), SHA-256 다이제스트 (digests), 청크 매니페스트 (chunk manifests), 경로 (route), 우선순위 (priority), 그리고 전송 상태 (transfer status)와 같은 메타데이터를 전달합니다. 수신자는 2 GB 크기의 아티팩트를 메시지 경로를 통해 가져오지 않고도 스케줄링, 검증 및 계측할 수 있으며, 의미 차선의 리셋이 다이제스트 검증이 완료된 전송을 무효화하지도 않습니다.
이러한 분리는 성능 측면뿐만 아니라 안전성 측면에서의 논거이기도 합니다. 혼잡 (congestion) 상황 발생 시, 제어 메시지는 대량의 바이트 데이터보다 우선순위를 갖습니다. 블롭 기술자는 세션 사전 (session dictionary)을 변경하는 것이 금지됩니다. 각 차선은 독립적으로 실패합니다.
계약에 따른 폐쇄형 실패 (Fail closed, by contract)
양측의 의견이 일치하지 않을 경우 공유된 압축 상태 (shared compression state)는 위험하므로, AIWire v1 스펙은 검증에 대해 매우 공격적인 태도를 취합니다:
- 핸드셰이크 (handshake) 과정에서는 정적 사전 (static dictionary)의 SHA-256 및 바이트 크기, 템플릿 해시 (template hashes) 및 개수, 그리고 zlib 파라미터를 비교합니다. 불일치가 발생하면 즉시 차단(fail closed)되거나, 애플리케이션이 명시적으로 허용한 경우에만
raw/zlib방식으로 폴백 (fallback)합니다. - 세션 사전 (session dictionary)의 성장은 추가 전용 (append-only) 방식이며, 에포크 (epoch) 번호가 매겨집니다. 또한 이전 및 다음 상태의 해시, 새로운 논스 (nonce), 디프 아이덴티티 해시 (diff identity hash), 그리고 선택 사항인 HMAC-SHA256 태그를 포함하는 디프 (diffs)를 통해 제안됩니다. 송신자는 일치하는 ACK가 확인될 때까지 새로운 구조에 맞춰 인코딩할 수 없습니다.
- 재개 핸드셰이크 (Resume handshakes)를 통해 클라이언트는 캐시된 사전 상태를 사용하여 재연결할 수 있지만, 이는 수신자가 제안된 상태 해시 중 하나를 실제로 보유하고 있는 경우에만 가능합니다.
- 모든 인플레이트 (inflate) 오류, 해시 불일치, 또는 순서 위반은 중단, 재핸드셰이크, 또는 폴백을 의미합니다. 스펙의 표현을 빌리자면: 피어 (peers)는 불확실한 구조를 대상으로 압축된 델타 (compact deltas)를 계속 전송해서는 안 됩니다.
지표는 비율이 아니라 교환 횟수입니다
AURA의 문서는 압축률 (compression ratio) 단독으로는 잘못된 점수판이라는 점을 명시하고 있습니다. 핵심 질문은 대역폭 (bandwidth), p95 지연 시간 (latency), 그리고 코덱 (codec) CPU 사용량을 고려했을 때, 하나의 링크를 통해 얼마나 많은 검증된 의미론적 교환 (semantic exchanges)이 이루어질 수 있느냐 하는 것입니다.
프로토콜 형태의 요청/응답 트래픽이 모델링된 10 Mbps 링크 환경에서 (네이티브 C++ 백엔드, 2026-07-04):
| 코덱 (Codec) | 교환당 바이트 (Bytes/exchange) | 대역폭 제한 초당 교환 횟수 (Bandwidth-capped ex/s) | raw 대비 이득 (Gain over raw) |
|---|---|---|---|
| raw JSON | 1,177 | 1,756 | 1.00x |
| ... |
64개의 동시 논리 에이전트 (logical agents)와 모든 응답에 대한 SHA-256 검증을 포함하여, 확정된 공개 세션 코퍼스 (public session corpus)를 실시간 TCP 리플레이 (replay)한 결과는 더욱 놀라웠습니다: AIWire는 교환당 평균 45.6 바이트를 기록하며 24배의 대역폭 이득을 얻었고, AIToken + AIWire 결합 경로는 교환당 32.3 바이트를 기록하며 34배의 이득과 97.1%의 바이트 절감 효과를 달성했습니다. 이 시점에서 모델링된 링크는 더 이상 병목 (bottleneck)이 아니었습니다; 런타임 (runtime)이 남은 여유 공간을 채울 만큼 충분한 요청을 처리 중인 상태 (in flight)로 유지할 수 없었습니다.
그 마지막 세부 사항이 이 프로젝트의 솔직한 핵심입니다. 더 작은 프레임(frames)은 시스템에 그들이 만들어낸 여유 공간을 사용할 만큼 충분한 동시 작업(concurrent work)이 있을 때만 의미가 있습니다. AURA는 바로 그 점을 추론하기 위한 외삽(extrapolation) 도구를 제공합니다. 즉, 대역폭(bandwidth), p95 지연 시간(latency), 그리고 에이전트당 윈도우(per-agent window)가 주어졌을 때, 링크를 포화(saturate)시키기 위해 몇 명의 에이전트가 필요한지를 계산합니다.
적용 분야
AURA는 링크의 양 끝단을 모두 제어할 수 있고 트래픽이 반복적인 구조를 가진 상황을 위한 것입니다:
- 멀티 에이전트 요청/응답 루프 (Multi-agent request/response loops). 오케스트레이터(orchestrators), 워커(workers), 리뷰어(reviewers)가 수천 개의 작은 작업, 상태 및 결과 메시지를 교환하는 경우.
- MCP 및 JSON-RPC 도구 트래픽. 도구 호출(tool calls)과 도구 결과(tool results)는 값이 변하면서도 구조는 안정적인 전형적인 사례입니다.
- 로컬 AI 클러스터 및 에지 링크 (Local AI clusters and edge links). 이 리포지토리의 LAN 벤치마크는 Mac을 Z6 워크스테이션 및 Jetson Nano급 보드와 대조하여 실행합니다. 대역폭이 제한된 에지 메시(edge mesh) 환경은 86%에서 97%의 바이트 감소가 텔레메트리(telemetry), 미디어, 재시도(retries)를 위한 여유 공간으로 전환되는 바로 그 지점입니다.
- 구조화된 로그 및 트레이스 (Structured logs and traces). 반복되는 필드 이름, 세션 안정적인 형태(session-stable shapes), 높은 볼륨.
- 바이너리 페이로드 라우팅 (Binary payload routing). 메시지 경로를 통해 바이트를 이동시키지 않고, 다이제스트(digest)를 통해 불투명한 아티팩트(opaque artifacts)를 스케줄링, 검증 및 추적해야 하는 에이전트.
해당하지 않는 분야
README는 한계점에 대해 이례적으로 직설적이며, 이를 다시 한번 강조할 가치가 있습니다. AURA는 gzip, zstd, TLS 또는 메시지 브로커(message broker)를 즉시 대체할 수 있는 도구가 아닙니다. AURA는 전송 보안(transport security), 재시도(retries), 또는 백프레셔(backpressure)를 정의하지 않으며, 이러한 기능은 전송 계층(transport layer)에 머뭅니다. 상태 유지 스트림(stateful stream) 방식은 세션 내에서 프레임의 순서를 변경하거나 누락시킬 수 없음을 의미하므로, 손실 허용 전송(lossy transports) 방식은 자체적인 복구 계층(recovery layer)이 필요합니다. 또한, 이 프로젝트는 프로덕션용(production-ready)이 아닙니다. 이는 작동 가능한 Python 경로, 네이티브 C++ 백엔드, 결정론적인 공개 피스처(deterministic public fixtures), 그리고 재현 가능한 벤치마크 하네스(benchmark harnesses)를 갖춘 프로토타이핑 및 측정용 툴킷입니다.
해당 피스처 코퍼스(fixture corpus)는 언급할 가치가 있습니다. 이 저장소는 MCP, A2A, OpenAI Responses, 트레이스(traces), 핸드오프(handoffs), 그리고 메모리 쓰기(memory writes)를 다루는 합성 공개 세션 코퍼스(synthetic public session corpus)를 제공하며, 이는 강제 핸드셰이크(forced handshake), 템플릿 업데이트(template update), 인증된 딕셔너리 차분(authenticated dictionary diff), ACK, 그리고 재개(resume)로 이어지는 전체 사이드 채널 라이프사이클(side-channel lifecycle)로 감싸져 있습니다. 누구나 정확히 동일한 벤치마크를 재현하고 수치를 확인할 수 있습니다.
사용해 보기
from aura_compression import AIWireSessionEncoder, AIWireSessionDecoder
message = {
...
이 저장소에는 길이 접두사(length-prefixed) TCP, WebSocket, Server-Sent Events를 사용하는 HTTP, 그리고 로컬 브로커(local broker)를 위한 전송(transport) 예시와 함께, 위에서 언급한 수치 산출에 사용된 전체 벤치마크 하네스(benchmark harness)가 포함되어 있습니다.
에이전트 간(Agent-to-agent) 트래픽은 이를 실행하는 링크보다 더 빠르게 성장하고 있으며, 그 중 대부분은 동일한 구조가 반복해서 전송되는 형태입니다. AURA의 전략은 이 해결책이 프레임당 코덱(per-frame codec)이 아닌, 협상된 세션 프로토콜(negotiated session protocol)에 포함되어야 한다는 것입니다. 3-레인 모델(three-lane model), 페일-클로즈드 핸드셰이크 계약(fail-closed handshake contract), 그리고 초당 교환 횟수(exchanges-per-second) 스코어보드가 이 프로젝트를 주목할 만하게 만드는 요소입니다.
AURA는 Apache 2.0 라이선스를 따릅니다. 코드, 사양(spec), 피스처(fixtures) 및 벤치마크 보고서는 다음에서 확인할 수 있습니다: github.com/H-XX-D/AURA.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기