💻 computer science

S-Bus: Automatic Read-Set Reconstruction for Multi-Agent LLM State Coordination

본 논문은 에이전트 SDK 변경 없이 동시 다중 에이전트 LLM 시스템에서 구조적 레이스 컨디션을 방지하기 위해 서버 측 DeliveryLog 를 활용하여 에이전트 읽기 집합을 자동으로 재구성하고 관찰 가능한 읽기 격리 (ORI) 를 강제하는 HTTP 미들웨어인 S-Bus 를 소개합니다.

원저자: Sajjad Khan

게시일 2026-05-19

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Sajjad Khan

원본 논문은 CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/) 라이선스로 제공됩니다. ✨ 이것은 아래 논문에 대한 AI 생성 설명입니다. 저자가 작성하거나 승인한 것이 아닙니다. 기술적 정확성을 위해서는 원본 논문을 참조하세요. 전체 면책 조항 읽기

다음은 "S-Bus: Multi-Agent LLM 상태 조정을 위한 자동 읽기 세트 재구성"이라는 논문을 쉬운 언어와 일상적인 비유를 사용하여 설명한 내용입니다.

큰 문제: "침묵 있는 덮어쓰기"

네 명의 AI 에이전트 팀이 복잡한 소프트웨어 버그를 수정하기 위해 함께 일한다고 상상해 보세요. 그들은 현재 상황을 이해하기 위해 같은 공유 노트 (상태) 를 모두 읽고 있습니다.

에이전트 A는 노트를 읽어 "데이터베이스 X 사용"이라는 계획을 보고 이를 바탕으로 솔루션 작성을 시작합니다.
에이전트 B는 정확히 같은 시간에 노트를 읽어 "데이터베이스 X"를 보고 이를 바탕으로 다른 솔루션 작성을 시작합니다.
에이전트 C는 끼어들어 노트를 "데이터베이스 Y 사용"으로 변경하고 저장합니다.

여기서 재앙이 발생합니다: 에이전트 A 와 B 는 에이전트 C 가 노트를 변경했다는 것을 모릅니다. 그들은 이전 정보 ("데이터베이스 X") 를 바탕으로 작업을 완료하고 파일을 저장합니다. 그들의 작업은 새로운 현실 ("데이터베이스 Y") 과 모순되기 때문에 침묵 속에서 손상됩니다. AI 에이전트 세계에서는 이를 구조적 레이스 컨디션이라고 합니다. 기존 도구들은 종종 최종 결과가 쓰레기가 될 때까지 아무도 이 상황을 알아차리지 못하게 허용합니다.

해결책: S-Bus (기억력이 있는 "교통 경찰")

저자들은 S-Bus라는 도구를 개발했습니다. 이는 AI 에이전트와 그들의 공유 노트 사이에 서 있는 똑똑한 교통 경찰과 같습니다.

에이전트에게 "무엇을 읽었나요?"라고 묻는 대신 (그들이 거짓말을 하거나 잊어버릴 수 있으므로), S-Bus 는 **DeliveryLog(전송 로그)**라는 특별한 기능을 갖추고 있습니다.

DeliveryLog 비유: 에이전트가 노트의 한 페이지를 열어 읽을 때마다, 교통 경찰이 페이지 번호와 시간을 찍은 영수증을 발급한다고 상상해 보세요.
체크포인트: 에이전트가 최종 작업을 제출할 준비가 되면, S-Bus 는 그들이 가진 영수증 더미를 확인합니다. "당신은 5 페이지를 버전 1 일 때 읽었군요. 좋습니다. 하지만 잠깐, 누군가 변경했으므로 5 페이지는 이제 버전 2 입니다."라고 확인합니다.
결과: S-Bus 는 "멈추세요! 당신은 오래된 정보로 작업하고 있습니다."라고 말합니다. 에이전트를 강제로 해당 페이지를 다시 읽게 하고, 현재 버전을 바탕으로 솔루션을 다시 작성하게 합니다.

이 과정은 자동으로 발생합니다. AI 에이전트들은 코드 변경이나 감시받음을 알 필요가 없습니다. S-Bus 는 단지 교통을 감시하고 모두가 같은 페이지에 있도록 할 뿐입니다.

"특별 규칙" (S-Bus 가 할 수 있는 것과 할 수 없는 것)

이 논문은 **관측 가능 읽기 격리 (Observable-Read Isolation, ORI)**라는 개념을 사용하여 이 작동 방식에 대해 세 가지 매우 구체적인 주장을 합니다.

1. "영수증 기반" 안전망

S-Bus 는 볼 수 있는 것 (HTTP 요청) 을 기반으로 실수를 잡는 데 매우 뛰어납니다.

주장: 에이전트가 데이터 조각을 읽으면 S-Bus 는 이를 기록합니다. 에이전트가 작업을 완료하기 전에 그 데이터가 변경되면, S-Bus 는 에이전트를 중단시킵니다.
증거: 저자들은 엄격한 수학적 증명 (초강력 논리 퍼즐 해결사와 같은) 을 사용하고 수백만 건의 시뮬레이션을 실행했습니다. 시스템이 규칙을 따를 경우, 다른 사람이 이미 변경한 데이터 버전을 기반으로 에이전트가 작업을 제출하는 일은 절대 일어나지 않는다는 것을 증명했습니다.
주의점: S-Bus 는 에이전트가 네트워크를 통해 요청한 것만 볼 수 있습니다. 에이전트가 이전 대화에서 기억하는 것이 있지만 다시 요청하지 않으면, S-Bus 는 그것이 오래된 것임을 놓칠 수 있습니다. 그러나 논문은 S-Bus 의 기억 (DeliveryLog) 이 과거 요청을 기억하는 데 매우 뛰어나 일반적인 세션에서 관련 정보의 약 **99.8%**를 포착한다고 밝혔습니다.

2. 모두가 자신의 책상을 가질 때 가장 잘 작동함

논문은 S-Bus 를 어디서 사용해야 하는지에 대한 중요한 규칙을 발견했습니다.

좋은 시나리오 (전용 샤드): 모두가 자신의 책상에서 작성하지만, 중앙 게시판에서 모두 읽는 팀을 상상해 보세요. S-Bus 는 여기서 완벽합니다. S-Bus 는 모두가 자신의 책상에 쓰기 전에 최신 게시판 업데이트를 읽도록 보장합니다. 그 결과는 조화롭고 충돌 없는 프로젝트입니다.
나쁜 시나리오 (공유 책상): 모두가 같은 종이에 동시에 쓰려고 하는 상황을 상상해 보세요. S-Bus 는 모든 충돌하는 아이디어를 유지하도록 강요하여 messy 하고 모순된 혼란을 초래합니다. 이 경우, 논문은 S-Bus 가 실제로 상황을 악화시킨다고 말합니다. 한 사람이 주도권을 잡게 하는 대신 모든 충돌하는 의견을 보존하기 때문입니다. 이 시나리오의 경우, 논문은 대신 간단한 "한 번에 한 사람" 접근 방식을 사용할 것을 제안합니다.

3. 은행만큼 안전하지만 사용하기 더 쉬움

저자들은 S-Bus 를 은행에서 돈 오류를 방지하기 위해 사용하는 무거운 데이터베이스 시스템 (PostgreSQL 등) 과 비교했습니다.

결과: S-Bus 는 "침묵 있는 덮어쓰기"를 방지하는 데 있어 이러한 은행 시스템만큼 안전합니다.
이점: S-Bus 는 AI 에이전트가 "데이터베이스 언어"를 말할 필요가 없기 때문에 훨씬 더 빠르고 설정이 쉽습니다. AI 에이전트가 이미 사용하는 "웹 트래픽 (HTTP)"만 말하면 됩니다.

"마법"의 요약

문제: 함께 일하는 AI 에이전트들은 데이터가 변경된 것을 알지 못해 서로의 작업을 덮어쓰는 경우가 많습니다.
해결책: S-Bus 는 기억을 유지하는 교통 경찰 역할을 합니다. 모든 읽기에 대해 영수증을 찍고 쓰기 전에 이를 확인합니다.
보장: 수학적으로 에이전트가 요청한 오래된 정보를 기반으로 작업을 제출할 수 없음을 증명합니다.
한계: 에이전트들이 자신의 개인 작업 공간을 가지고 공개 참조를 공유할 때 가장 잘 작동합니다. 그들이 단일 작업 공간을 두고 싸운다면, 이는 올바른 도구가 아닙니다.

이 논문은 S-Bus 가 올바른 환경에서 일할 경우, AI 팀이 실수로 서로를 방해하지 않도록 하는 견고하고 수학적으로 입증된 방법이라고 결론 내립니다.

기술 요약: S-Bus: 다중 에이전트 LLM 상태 조정을 위한 자동 읽기 세트 재구성

1. 문제 정의

가변적인 자연어 (NL) 상태를 공유하는 동시 실행 대규모 언어 모델 (LLM) 에이전트들은 **구조적 레이스 컨디션 (Structural Race Conditions, SRCs)**에 취약합니다. 이는 두 에이전트가 버전 $v$ 의 동일한 샤드 (shard) 를 읽은 후 독립적인 델타 (delta) 를 생성하고, 중간에 다시 읽지 않은 채로 모두 커밋할 때 발생하며, 그 결과 한 에이전트가 다른 에이전트의 작업을 조용히 덮어쓰게 됩니다.

기존의 다중 에이전트 프레임워크 (예: LangGraph, CrewAI, AutoGen) 는 공유 상태에 대한 쓰기 소유권 (write-ownership) 시맨틱스를 제공하지 않습니다. 충돌은 사후에 감지되거나 아예 감지되지 않는 경우가 많아 에이전트 출력의 조용한 손상을 초래합니다. 핵심적인 어려움은 LLM 에이전트가 "블랙박스"로 작동하여 명시적으로 읽기 세트 (read sets) 를 선언하지 않기 때문에, 침습적인 SDK 변경 없이 기존 낙관적 동시성 제어 (Optimistic Concurrency Control, OCC) 메커니즘을 적용할 수 없다는 점입니다.

2. 방법론: S-BUS 및 DeliveryLog

본 논문은 에이전트가 코드 수정이나 읽기 세트 선언 없이 다중 에이전트 시스템에 대해 OCC 를 가능하게 하는 HTTP 미들웨어인 S-BUS를 제시합니다.

핵심 메커니즘: DeliveryLog

S-BUS 는 에이전트가 발행한 모든 HTTP GET 작업을 기록하는 서버 측 DeliveryLog(첨부 전용 로그) 를 도입합니다.

자동 재구성: 커밋 시점에 서버는 DeliveryLog 의 항목들을 집계하여 에이전트의 읽기 세트 ( $\hat{R}$ ) 를 재구성합니다.
검증: 샤드 $k$ 에 델타를 커밋하기 전에, 접근 제어 프로토콜 (Access Control Protocol, ACP) 은 에이전트의 DeliveryLog 에 기록된 모든 다른 샤드 $k'$ 의 버전들이 GET 요청 이후로 진전되지 않았음을 검증합니다.
충돌 처리: 샤드 간 버전 불일치가 감지되면 (구식 읽기 표시), 커밋은 HTTP 409 (CROSSSHARDSTALE) 로 거부됩니다. 에이전트는 구식 샤드를 다시 읽고, 델타를 재생성하며 재시도해야 합니다.

일관성 모델: 관찰 가능 읽기 격리 (Observable-Read Isolation, ORI)

S-BUS 가 제공하는 일관성 속성은 **관찰 가능 읽기 격리 (ORI)**라고 명명됩니다.

정의: ORI 는 에이전트 읽기 세트의 HTTP-관찰 가능 투영 (HTTP-observable projection)( $R_{obs}$ ) 에 대해 부분적 인과적 일관성을 제공합니다.
범위: 이는 $R_{obs}$ 에 대한 G2-item 이상 (write-skew) 을 방지하지만, HTTP GET 없이 LLM 대화 기록 내에서 암시적으로 이루어진 샤드 참조 ( $R_{hidden}$ ) 에 대해서는 일관성을 보장하지 않습니다.
위치: Adya 의 격리 격자 (isolation lattice) 에서 ORI 는 관찰 가능 읽기 세트에 투영될 때 읽기 완료 (Read-Committed) 와 스냅샷 격리 (Snapshot Isolation) 사이에 엄격하게 위치합니다.

3. 주요 기여

(C1) 형식적 보장을 갖춘 자동 읽기 세트 재구성

본 논문은 DeliveryLog 메커니즘을 도입하고 ORI 를 형식화했습니다. 추상 알고리즘의 안전성은 3 단계 기계화 증거 스택을 통해 검증되었습니다.

TLAPS: 임의의 $N$ 개 에이전트에 대한 증명 (READSETSOUNDNESS: 기록된 읽기의 단조성 및 ORICOMMITSAFETY: 커밋 시 샤드 간 동등성) 을 수행했습니다. 687 개의 의무 사항이 (하나의 기본 타입 공리 제외) 실패 없이 처리되었습니다.
TLC: $N=3$ 인 경우 2,080 만 개, $N=4$ 인 경우 280 만 개의 서로 다른 상태를 포괄적으로 모델 체킹하여 0 개의 불변성 위반을 확인했습니다.
Dafny: 추상 알고리즘에 대해 9 개의 귀납적 안전성 보조 정리 (19 개 의무 사항) 를 기계 검증했습니다.

(C2) 생산용 OCC 와의 경험적 안전성 동등성

S-BUS 는 생산 수준의 OCC 백엔드인 PostgreSQL 17 (SERIALIZABLE) 과 Redis 7 (WATCH/MULTI) 에 대해 평가되었습니다.

결과: 공유 샤드 경쟁 하의 427,308 건의 활성 충돌을 포함한 884,110 건의 커밋 시도 전반에 걸쳐, S-BUS, PostgreSQL, Redis 모두 **0 건의 1 형 손상 (Type-I corruptions)**을 보였습니다.
성능: S-BUS 는 프로세스 내 조정과 LLM 네이티브 계약으로 인해 이 특정 워크로드에서 PostgreSQL 보다 13~~15 배, Redis 보다 1.8~~1.9 배 빠른 낮은 지연 시간을 보여주며 운영의 단순성을 입증했습니다.

(C3) 토폴로지 조건부 운영 범위

본 논문은 워크로드 토폴로지에 따른 ORI 의 의미적 영향을 규명했습니다.

전용 샤드 토폴로지 (에이전트가 고유한 샤드를 소유): ORI 는 의미적으로 중립적입니다. 모순을 도입하지 않고 모든 에이전트 기여를 보존합니다. 이는 주요 사용 사례입니다.
단일 샤드 협업 작성 (모든 에이전트가 하나의 샤드에 작성): ORI 는 의미적으로 해롭습니다. 모든 에이전트를 재시도 및 커밋하도록 강제함으로써 동일한 샤드에 상호 모순되는 패치들이 누적됩니다. 이 영역에 대해서는 순차적 조정 또는 병합 기반 프로토콜을 권장합니다.

4. 실험 결과

구조적 충돌 방지

SWE-bench 워크로드: 전용 샤드 구성에서 S-BUS 는 CrewAI 보다 크게 우세하며 LangGraph 와 동등한 작업 성공률을 유지하면서 0 의 구조적 충돌을 유지했습니다.
비코드 워크로드 (데이터 파이프라인 계획): 8 개 도메인의 교차 도메인 실험에서 S-BUS 는 ORI-ON 상태에서 0/638건의 분기된 커밋을 방지한 반면, 베이스라인 (ORI-OFF) 은 590/639건의 분기된 커밋을 허용했습니다 ( $\chi^2 = 1094.98, p < 10^{-240}$ ).

커버리지 분석

관찰 가능 읽기 vs 숨겨진 읽기: 주요 다중 에이전트 워크로드에서 읽기의 **26.1%**만이 HTTP GET 을 통해 직접 관찰 가능 ( $R_{obs}$ ) 했습니다. 나머지 **73.9%**는 숨겨져 있었습니다 ( $R_{hidden}$ ).
세션 누적: 이전 단계의 GET 을 유지하는 세션 범위 내 DeliveryLog 누적이 대부분의 간극을 메우는 것으로 확인되었으며, 자기 보고 참조의 총 구조적 커버리지를 **99.8%**까지 높였습니다.
의미 추출: 분석가 LLM 을 사용한 의미 추출 메커니즘은 자기 보고에 대해 0.59 의 재현율 (recall) 을 달성했으나, 논문은 자기 보고 자체가 29~37% 만큼 사용량을 과장한다고 지적합니다.

백본 일반화

안전성 동등성은 GPT-4o-mini, Anthropic Haiku 4.5, Google Gemini 2.5 Flash 의 세 가지 LLM 백본에 대해 확인되었습니다.

5. 중요성 및 주장

본 논문은 S-BUS 가 기존 프레임워크가 결여하고 있는 다중 에이전트 조정을 위한 **구조적 원시 (structural primitive)**를 제공한다고 주장합니다. 그 중요성은 다음과 같습니다.

제로-SDK 통합: 에이전트 코드 변경 없이 표준 HTTP 트래픽에서 읽기 세트를 재구성함으로써 LLM 에이전트에 대한 OCC 를 가능하게 합니다.
형식적 검증: LLM 조정 메커니즘에 대해 형식적 안전성 보장 (TLAPS/TLC/Dafny 를 통해) 을 제공하는 최초의 사례이며, 구체적으로 관찰 가능 읽기 투영에 대한 구조적 레이스 컨디션 방지를 증명합니다.
운영 단순성: 무거운 트랜잭션 데이터베이스 (PostgreSQL) 와 안전성 동등성을 달성하면서도 LLM 네이티브 워크플로우에 대해 훨씬 낮은 지연 시간과 배포 복잡성을 제공합니다.

한계 및 정직한 범위:

의미적 정확성: 본 논문은 구조적 레이스를 방지하는 것이 의미적 일관성 (2 형 오류) 을 보장하지 않는다고 명시적으로 밝힙니다.
숨겨진 읽기: 형식적 보장은 $R_{obs}$ 에만 적용됩니다. $R_{hidden}$ 비율은 세션 누적 또는 향후 프록시 기반 의미 추출에 의존합니다.
토폴로지 제약: 이 메커니즘은 단일 샤드 협업 작성에는 해롭습니다. 전용 샤드 토폴로지를 위해 설계되었습니다.
분산 안전성: 리더 장애 조치에 대한 경험적 검증을 거쳤으나, 분산 Raft 계층의 완전한 TLAPS 기계화는 향후 과제로 남아 있습니다.

본 논문은 S-BUS 가 전용 샤드 토폴로지 내 공유 NL 상태에 대한 동시 작성으로 인해 발생하는 특정 유형의 실패에 대한 표적 솔루션이며, 현재 다중 에이전트 프레임워크에서 일반적인 "마지막 작성자 승리 (last-writer-wins)" 또는 사후 검증 전략에 대한 검증 가능한 대안을 제공한다고 결론지었습니다.