💬 NLP

Multi-agent Collaboration with State Management

본 논문은 공유 코드베이스의 일관된 뷰를 보장하면서 코딩 벤치마크에서 기존 작업 공간 격리 기준보다 현저히 우수한 성능을 발휘하도록, 쓰기 시점에 코드 충돌을 감지하고 해결하기 위해 다중 에이전트 상호작용을 중재하는 상태 지향 관리 프레임워크인 STORM 을 소개한다.

원저자: Mengyang Liu, Taozhi Chen, Zhenhua Xu, Xue Jiang, Yihong Dong

게시일 2026-05-21

📖 4 분 읽기☕ 가벼운 읽기

CC BY 4.0

원저자: Mengyang Liu, Taozhi Chen, Zhenhua Xu, Xue Jiang, Yihong Dong

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

다음은 "STORM: State-ORiented Management for multi-agent collaboration"라는 논문에 대한 설명을 창의적인 비유를 사용하여 쉬운 언어로 번역한 것입니다.

큰 문제: "주방 악몽"

네 명의 요리사 (AI 에이전트) 가 거대하고 복잡한 한 끼 식사를 함께 만들어 보려고 분주한 레스토랑 주방을 상상해 보세요. 그들은 모두 같은 재료와 같은 냄비 위에서 일하고 있습니다.

기존 방식 (GitWorktree 라고 함) 에서는 주방 관리자가 각 요리사에게 별도의 사적인 주방을 하나씩 할당합니다.

요리사 A는 주방 A 에서 소스를 만듭니다.
요리사 B는 주방 B 에서 수프를 만듭니다.
그들은 서로가 무엇을 하고 있는지 절대 볼 수 없습니다.

일이 끝나면 관리자는 모든 것을 하나의 거대한 냄비에 합치려고 시도합니다. 재앙입니다! 요리사 A 는 소스에 소금을 넣었지만, 요리사 B 는 수프에 소금을 넣었고, 이제 합쳐진 요리는 너무 짜집니다. 그보다 더 나쁘게, 요리사 A 가 요리사 B 가 필요로 했던 숟가락의 모양을 바꿔버렸을 수도 있습니다. 그들은 요리가 끝난 후에 이 난리를 수리하기 위해 몇 시간을 보내야 합니다. 이를 "사후 병합 (post-hoc merge)"이라고 하는데, 비용이 많이 들고 종종 실패합니다.

새로운 해결책: STORM ("스마트 주방 관리자")

저자들은 STORM이라는 새로운 시스템을 제안합니다. 요리사들에게 사적인 주방을 주는 대신, 모두 하나의 공유 주방에서 일하게 하되, 그들의 어깨 너머에 매우 똑똑한 관리자가 서 있게 합니다.

STORM 이 작동하는 방식은 다음 세 가지 간단한 규칙을 통해 설명됩니다:

1. "신선한 재료" 규칙 (로컬 상태 일관성)

기존 시스템에서는 요리사가 밀가루 한 봉지를 집어 섞기 시작하다가, 그들이 보지 않는 사이에 다른 요리사가 밀가루를 설탕으로 바꿔놓았다는 사실을 깨닫기도 합니다.

STORM 의 해결책: 요리사가 냄비에 무엇을 부을 때 (파일을 작성할 때) 관리자가 확인합니다: "지금 당신이 사용하고 있는 재료를 다른 사람이 건드리지 않았나요?"
답이 아니오라면, 요리사는 요리를 계속합니다.
답이 예라면 (다른 사람이 밀가루를 바꿨다면), 관리자는 즉시 요리사를 멈춥니다. 요리사는 새로운 밀가루를 확인하고 올바른 재료로 다시 섞기 작업을 시작해야 합니다. 이렇게 하면 "짜게 된 수프" 재앙이 발생하기 전에 막을 수 있습니다.

2. "카운터에 붙인 메모" 시스템 (의도 주석)

때로는 두 명의 요리사가 같은 냄비에서 일해야 합니다. 기존 시스템에서는 그들이 실수로 서로의 메모를 덮어쓸 수 있습니다.

STORM 의 해결책: 요리들은 "이곳에 마늘을 추가하고 있습니다. 레시피에 필요하기 때문입니다"라고 적힌 스티커 메모 (의도 주석) 를 카운터에 남겨야 합니다.
다음 요리사가 냄비를 볼 때 그 메모를 봅니다. 그들은 이렇게 알게 됩니다: "아, 요리사 A 가 마늘을 다루고 있으니 나는 그 부분은 건드리지 말아야겠다" 또는 *"요리사 A 가 마늘을 추가한 걸 보니, 나는 내 향신료를 조정해야겠다"*라고요. 이는 끊임없이 멈추고 대화할 필요 없이 협조할 수 있게 해줍니다.

3. "즉시 거부" (작성 시 충돌 제어)

기존 시스템에서는 요리사들이 요리를 끝낸 후에 관리자가 수프와 소스가 섞이지 않았음을 깨닫곤 했습니다. 그때 고치는 것은 악몽이었습니다.

STORM 의 해결책: 요리사가 이미 냄비에 들어있는 내용과 충돌하는 것을 부으려 하면 관리자는 즉시 **"멈춰!"**라고 말합니다. 요리사는 버려질 요리를 완성하는 시간을 낭비하지 않습니다. 그들은 업데이트된 냄비를 받아 계획을 수정하고 즉시 다시 시도합니다.

테스트 결과는 어땠나요?

연구자들은 두 가지 유형의 "요리 도전"에서 이를 테스트했습니다:

Commit0: 기존 소프트웨어 라이브러리의 깨진 코드를 수정하는 도전 (깨진 레시피 책을 고치는 것과 같음).
PaperBench: 복잡한 과학 연구 논문을 처음부터 다시 만들어내는 도전 (미쉐린 스타 요리를 설명만으로 재현하는 것과 같음).

결과:

더 높은 점수: STORM 팀은 "사적인 주방" 팀들보다 훨씬 더 훌륭한 요리를 만들었습니다. 소프트웨어 도전 과제에서 성공률은 약 19 포인트 향상되었고, 연구 도전 과제에서도 더 높은 점수를 받았습니다.
더 저렴하고 빠름: 끝에서 거대한 난리를 수리하는 시간을 낭비하지 않았기 때문에, 성공적인 요리 하나당 실제로 더 적은 돈과 시간을 사용했습니다.
확장성: "사적인 주방" 시스템에 더 많은 요리사 (에이전트) 를 추가하면 혼란스러워지고 실패합니다. 하지만 STORM 에서는 더 많은 요리사를 추가할수록 주방이 더 효율적이 됩니다. 관리자가 충돌을 즉시 발견하여 시스템이 충돌하지 않으면서 모두가 병렬로 일할 수 있기 때문입니다.

결론

이 논문은 **작업 공간을 격리하는 것 (모두에게 별도의 방을 주는 것)**보다 **상태를 관리하는 것 (누가 언제 무엇을 변경했는지 추적하는 것)**이 더 중요하다고 주장합니다.

그룹 프로젝트를 생각해 보세요:

기존 방식: 모두 각자의 노트북에서 일하다가 마지막 순간에 파일들을 병합하려고 합니다. 이는 엉망진창입니다.
STORM 방식: 모두 같은 문서에서 일하지만, 시스템이 당신이 보고 있는 단락을 다른 사람이 편집 중이라면 자동으로 작업을 일시 중지시킵니다. 이는 당신이 입력하기 전에 새로고침하고 다시 읽도록 강제합니다.

그 결과 팀은 더 빠르게 일하고, 실수를 줄이며, 훨씬 더 나은 최종 산물을 만들어냅니다.

기술 요약: STORM - 다중 에이전트 협업을 위한 상태 지향적 관리

문제 정의

최근 다중 에이전트 시스템 (MAS) 의 발전은 여러 대규모 언어 모델 (LLM) 에이전트 간 작업을 분배함으로써 복잡한 과제를 해결할 잠재력을 보여주었습니다. 그러나 여러 에이전트가 공유 코드베이스를 동시에 편집할 때 중요한 병목 현상이 발생합니다. git worktrees를 활용하는 기존 접근법 (예: Geng and Neubig, 2026; Qu et al., 2026) 은 간섭을 방지하기 위해 에이전트를 별도의 작업 공간으로 격리합니다. 이는 즉각적인 덮어쓰기를 방지하지만, 충돌 해결을 사후 병합 단계로 미룹니다. 이러한 지연은 두 가지 주요 문제를 초래합니다:

의미적 충돌 (Semantic Conflicts): 에이전트들이 호환되지 않는 설계 선택 (예: 함수 시그니처 변경) 을 할 수 있으며, 이는 개별적으로는 컴파일되지만 결합 시 실패합니다. 이러한 충돌은 자동으로 감지하고 해결하기 어렵습니다.
비싼 복구 (Expensive Recovery): 병합 도중 충돌이 발견될 때쯤이면 에이전트들의 추론 컨텍스트는 낡아져 있어, 복구가 비용이 많이 들며 종종 통합 실패로 이어집니다.

핵심 과제는 전체 저장소의 고정된 스냅샷을 요구하지 않으면서도, 에이전트가 읽은 특정 파일에 대한 유효한 뷰를 기반으로 편집이 이루어지도록 보장하는 **로컬 일관성 (local consistency)**을 유지하는 것입니다.

방법론: STORM

저자들은 STORM(STate-ORiented Management) 을 제안합니다. 이는 작업 공간 격리를 로컬 상태 일관성으로 대체하는 프레임워크입니다. 에이전트를 격리하는 대신, STORM 은 모든 에이전트를 단일 공유 작업 공간에 배치하고 파일 작업을 중재하여 쓰기 시점에 일관성을 보장합니다.

핵심 메커니즘

로컬 상태 일관성:
- 에이전트의 상태는 관찰된 모든 파일과 관찰 당시의 버전을 기록하는 **읽기 스냅샷 (read snapshot, $S_i$ )**으로 정의됩니다.
- 쓰기 작업은 $S_i$ 내의 모든 파일의 현재 버전이 에이전트가 관찰한 버전과 일치할 때만 유효합니다. 읽은 이후 다른 에이전트에 의해 종속성 파일이 수정된 경우, 해당 쓰기는 낡은 것으로 간주됩니다.
쓰기 시점 충돌 제어:
- 낙관적 동시성 제어 (Optimistic Concurrency Control): Kung and Robinson (1981) 에서 영감을 받아, STORM 은 작업을 차단하지 않고 진행되도록 허용하지만 커밋 전에 유효성을 검증합니다.
- 검증: 쓰기를 수락하기 전에, 시스템은 에이전트의 전체 읽기 스냅샷을 현재 작업 공간 상태와 비교합니다.
- 거부 및 재시도: 충돌이 감지될 경우 (대상 파일에 대한 직접 편집 또는 낡은 종속성), 쓰기는 거부됩니다. 에이전트는 현재 콘텐츠, 통합 diff, 그리고 낡은 종속성 목록을 받아 즉시 올바른 기준선에서 재계획할 수 있습니다.
- 예약: 무한한 교차 거부 루프를 방지하기 위해, 거부된 에이전트에게 대상 파일에 대한 짧은 예약 (排他적 잠금) 이 부여됩니다.
의도 주석 (Intent Annotations):
- 의미적 충돌 (예: 공유 인터페이스에 대한 호환되지 않는 가정) 을 해결하기 위해, 에이전트는 코드에 구조화된 주석 (의도 주석) 을 추가합니다.
- 이러한 주석은 작성자를 식별하고 블록의 목적을 설명합니다. 다른 에이전트가 파일을 읽을 때 이러한 주석을 확인하여 의미를 조정하고 중복되거나 충돌하는 작업을 방지함으로써, 명시적 메시징 없이도 경량의 조정 채널을 효과적으로 생성합니다.

시스템 아키텍처

관리자 에이전트 (Manager Agent): 작업을 분해하고 엔지니어에게 하위 작업을 할당하며, diff 를 검토하고 테스트를 실행하며 변경 사항을 커밋합니다. 저장소에 커밋하는 것은 오직 관리자 에이전트뿐입니다.
엔지니어 에이전트 (Engineer Agents): 공유 작업 공간에서 병렬로 작업하지만, STORM 에 의해 중재되는 file_editor 를 통해서만 파일과 상호작용합니다. 직접 통신하지 않으며, 공유 코드베이스와 의도 주석을 통해 조정이 이루어집니다.

주요 기여

상태 관리의 공식화: 이 논문은 다중 에이전트 상태 관리를 파일 수준 컨텍스트 일관성 문제로 정의합니다. 여기서 에이전트의 쓰기는 관찰된 파일과 종속성이 변경되지 않을 때만 유효합니다.
STORM 프레임워크: 쓰기 시점에 로컬 상태 일관성을 강제하는 아키텍처 중립적 프레임워크입니다. 충돌을 즉시 감지하고 에이전트들이 작업 공간 격리 없이 올바른 기준선에서 재시도할 수 있도록 합니다.
실증적 검증: 세 가지 LLM(Claude Sonnet 4.6, Qwen 3.6 Plus, DeepSeek V4 Pro) 을 대상으로 Commit0-Lite와 PaperBench에서 광범위한 평가를 수행하여, 명시적 상태 관리가 작업 공간 격리보다 우수함을 입증했습니다.

실험 결과

저자들은 STORM 을 Single-Agent 기준선과 GitWorktree(격리된) 기준선에 대해 평가했습니다.

Commit0-Lite(코드 생성) 성능

STORM은 Claude Sonnet 4.6 을 사용하여 가중 통과율 (Scorew) 46.2% 및 매크로 통과율 (Score) **82.5%**를 달성했습니다.
이는 GitWorktree(24.6% / 63.8%) 및 Single-Agent(20.7% / 66.4%) 보다 현저히 우수했습니다.
확장성: 엔지니어 수를 2 명에서 8 명으로 늘리면 점수가 단조롭게 향상되었습니다 (가중치 기준 38.2% 에서 69.7% 로). 병렬 실행으로 인해 벽시계 시간은 일정하게 유지되었습니다.
비용 효율성: STORM 은 충돌을 비용이 많이 드는 병합 단계가 아닌 점진적으로 해결하므로, GitWorktree 와 비교해 동등하거나 더 나은 비용 효율성을 달성했습니다.

PaperBench(연구 재현) 성능

Code-Dev 하위 집합에서 STORM 은 Sonnet 4.6 으로 74.1점을 받아 GitWorktree(72.7) 와 Single-Agent(68.7) 를 능가했습니다.
결합 전략: Single-Agent 와 STORM 중 최상의 결과를 취하는 STORM-Combined 는 모든 모델에서 가장 높은 점수를 기록했습니다 (예: Commit0-Lite 에서 87.6, Sonnet 을 사용한 PaperBench 에서 78.2). 이는 두 접근법이 상호 보완적임을 시사합니다.

실패 모드 분석

높은 결합도 (High Coupling): STORM 의 이점은 파일 간 결합도가 높은 저장소에서 가장 두드러집니다. GitWorktree 는 높은 결합도 작업에서 성능이 붕괴되어 36.3% 로 떨어지는 반면, STORM 은 70.9% 로 견고함을 유지했습니다.
충돌 타이밍: STORM 은 커밋 전 충돌을 표면화하여 에이전트들이 추론 컨텍스트가 신선할 때 재계획할 수 있게 합니다. GitWorktree 는 충돌을 커밋 후 병합 단계로 남겨 최종 통과율을 낮춥니다.
한계점: 논문은 STORM 이 범위 이탈 (할당된 범위를 벗어난 파일 편집) 이나 예산/런타임 제한과 같은 모든 실패를 방지할 수는 없다고 지적합니다. 또한 파일 수준의 세분성은 동일한 파일 내 다른 함수에 대한 편집을 거부하는 오탐 (false positives) 을 유발할 수 있음을 인정합니다.

중요성과 주장

이 논문은 명시적 상태 관리가 작업 공간 격리보다 다중 에이전트 협업에 더 효과적인 기반이라고 주장합니다. 취약한 사후 병합 단계에서 즉각적인 쓰기 시점 검사로 충돌 해결을 전환함으로써, STORM 은 복잡하고 상호 의존적인 코드베이스에서의 신뢰할 수 있는 병렬 협업을 가능하게 합니다.

저자들은 STORM 이 완벽한 작업 분해나 모든 충돌의 제거를 요구하지 않으며, 대신 발생하는 충돌을 우아하고 저렴하게 처리하는 메커니즘을 제공한다고 강조합니다. 이 프레임워크는 플러그 앤 플레이 방식으로 설계되어, 파일 작업을 중재하기 위해 어떤 다중 에이전트 시스템에도 통합될 수 있습니다.

결과는 상당한 파일 간 종속성이 포함된 소프트웨어 엔지니어링 작업의 경우, 로컬 상태 일관성 관리의 오버헤드가 파국적인 통합 실패를 피하고 확장 가능한 병렬화를 가능하게 하는 이점보다 작음을 시사합니다.