멀티 에이전트 AI에는 채팅방이 아니라 주소 공간(Address Space)이 필요합니다
요약
멀티 에이전트 시스템 구축 시 채팅 기반의 산문 전달 방식 대신, 운영 체제와 유사한 주소 공간(Address Space) 아키텍처를 도입해야 함을 강조합니다. 이를 통해 토큰 폭발과 지연 시간을 방지하고 효율적인 문맥 관리가 가능합니다.
핵심 포인트
- 채팅 기반의 문맥 전달은 비용이 높고 확장성이 떨어짐
- 에이전트 간 통신을 위해 주소 기반의 좌표 시스템 필요
- 기록자(Historian)는 추론 도구가 아닌 빠른 조회(Lookup) 도구여야 함
- 관계 그래프를 통한 범위 지정 전달로 토큰 폭발 방지
멀티 에이전트 (Multi-agent) AI 시스템을 구축하는 대부분의 사람들은 실수로 채팅방을 다시 만들고 있습니다.
에이전트들이 에이전트에게 말을 겁니다. 문맥 (Context)은 산문 (Prose) 형태로 전달됩니다. 메모리는 임베딩 (Embeddings)을 통해 검색됩니다. 이 모든 과정은 막대한 비용이 들고, 정보가 표류하며, 결국 자체적인 무게를 견디지 못하고 붕괴합니다.
다른 아키텍처 (Architecture)가 존재합니다. 그것은 채팅 시스템처럼 보이지 않습니다. 운영 체제 (Operating system)처럼 보입니다.
아무도 이름 붙이지 않은 문제: 문맥에는 주소가 없다
당신의 플릿 (Fleet) 내의 에이전트가 현재 아키텍처를 이해해야 할 때, 에이전트는 다른 에이전트에게 묻거나 (LLM → LLM → 토큰 (tokens) → 지연 시간 (latency)), 벡터 스토어 (Vector store)에서 검색하거나 (임베딩 (embedding) → 스코어링 (scoring) → 청킹 오버헤드 (chunking overhead)), 또는 전체 문맥을 프롬프트 (Prompt)에 쏟아부어야 합니다 (토큰 폭발 (token explosion)).
이 중 어느 것도 확장 가능하지 않습니다. 그리고 모두를 오염시킵니다.
더 깊은 문제는 다음과 같습니다: 문맥에는 주소가 없다. 검색 쿼리 (Retrieval query)를 작성하거나 LLM에게 알아내라고 요청하지 않고서는
A4:WK01은 다음으로 해결(resolve)됩니다:
에이전트 A4의 활성 좌표 (active coordinates)
- 마지막 활성 이후의 주요 결정 사항 (major decisions)
...
LLM 호출 없음. 산문(prose) 없음. 밀리초(milliseconds) 단위로 처리.
레이어 3: 기록자(Historian)는 사고하는 존재가 아니라 조회(Lookup) 도구입니다
타임라인을 요약하고 설명하는 "기록자 에이전트 (Historian agent)"를 구축하려는 본능이 있습니다. 하지만 그 본능은 틀렸습니다.
기록자가 사고하는 존재(thinker)가 되는 순간, 그것은 병목 현상(bottleneck)이 됩니다. 모든 에이전트가 기록자를 기다리게 됩니다. 비용은 비싸지고, 내용은 표류(drift)하게 됩니다.
당신이 실제로 원하는 것은 다음과 같습니다:
에이전트 요청: AA03
해결사(Resolver) 반환: cabinet["AA"][3] ← ARCH.DECISIONS.RETRY, 현재 값
기록자의 역할: resolve(coordinate) → content. 그게 전부입니다.
이름 (Name) → 좌표 (Coordinate) → 위치 (Location) → 내용 (Content)
지능도, 추론(reasoning)도, 요약(summarization)도 없습니다. 그저 멍청하지만 눈부시게 빠른 주소 해결사(address resolver)일 뿐입니다. 기록자가 똑똑해질수록, 전체 시스템은 더욱 취약해집니다.
레이어 4: 관계 그래프 (Relationship Graph) — 범위가 지정된 전달 (Scoped Delivery)
모든 것을 모든 이에게 방송(broadcasting)하는 방식은 토큰 폭발(token explosion)과 범위 확장(scope creep)을 초래하는 지름길입니다. 문맥 분배는 관계 그래프(relationship graph)에 의해 제어됩니다:
CodeAgent: 수신: [architecture, APIs, test_failures, active_PRs]
FrontendAgent: 수신: [UI_specs, component_contracts, design_tokens]
ResearchAgent: 수신: [requirements, external_signals]
...
tune_in()은 role= 파라미터를 허용합니다. 이 파라미터가 제공되면, 관계 그래프는 문맥 팩(context pack)을 반환하기 전에 주파수(frequencies)를 사전 필터링합니다. 에이전트는 자신의 역할에 관련된 내용만을 수신합니다. 즉, 미리 정렬되고 미리 결정되어 있어 무관한 정보에 의한 오염(contamination)이 없습니다.
흐름:
전역 방송 버스 (Global broadcast bus)
↓
관계 그래프 필터 (Relationship graph filter) (role=CodeAgent)
...
이는 토큰 폭발, 우발적인 합의 루프(consensus loops), 범위 확장(scope creep), 그리고 에이전트들이 서로의 문맥을 오염시키는 현상을 방지합니다.
레이어 5: 흔적 보존을 포함한 유의어 트리 (Synonym Tree With Trail Preservation)
대부분의 임베딩(embedding) 시스템은 "startup ≈ initialize ≈ boot ≈ bring online"과 같은 질문에 답하기 위해 존재합니다.
SignalMesh는 유의어 트리(synonym tree)를 통해 이를 처리하지만, 결정적으로 퍼지 흔적(fuzzy trail)을 보존합니다.
"spin it up"
→ 일치 항목: "bring_online"
→ 매핑됨: "initialize"
...
흔적(trail) 그 자체는 대부분의 벡터 데이터베이스(vector databases)가 버려버리는 의미론적 정보(semantic information)입니다. 이는 에이전트 함대(agent fleet) 전반에 걸친 어휘 표류(vocabulary drift), 예상되는 대안적 표현들, 그리고 정형 매칭(canonical match)으로 이어진 의도 경로(intent path)에 대해 알려줍니다.
향후 조회(lookups) 시 체인의 어느 단계에서든 진입하여 동일한 정형 용어(canonical term)로 해결(resolve)될 수 있습니다.
레이어 6: TTL 범위의 일시적 메모리 (TTL-Scoped Fleeting Memory)
좌표(coordinates)와 신호(signals)는 선택 사항인 ttl_ms를 포함합니다. 만료(expiry) 후에는 해당 좌표가 활성 공간(active space)에서 사라집니다. 장기 이벤트 아카이브(long-term event archive)는 영향을 받지 않습니다.
이는 L1 캐시(L1 cache) 개념입니다:
| 레이어 | 내용 | TTL | 비용 |
|---|---|---|---|
| L1 | 에이전트 활성 좌표 | 15분 | ~0 |
| ... |
에이전트는 L1-L2에서 활동합니다. TTL이 만료되면 컨텍스트(context)는 자동으로 축소됩니다. 수동 가비지 컬렉션(garbage collection)이나 표류(drift)의 누적이 필요 없습니다.
전체 아키텍처 (The Full Architecture)
SignalMesh
│
┌──────── Broadcast ────────┐
...
이것이 대체하는 것 (What This Replaces)
| 기존 패턴 | SignalMesh 패턴 |
|---|---|
| LLM이 LLM에게 컨텍스트를 요청함 | 좌표 조회(Coordinate lookup) → 포인터(pointer) |
| ... |
이 중 그 어떤 것도 임베딩(embeddings), 벡터 데이터베이스(vector databases), RAG 청킹(RAG chunking), 검색 점수 산정(retrieval scoring), 또는 반복적인 LLM 간 통신(LLM-to-LLM communication)을 요구하지 않습니다.
핵심적인 변화 (The Core Shift)
대부분의 에이전트 프레임워크(agent frameworks)는 LLM이 LLM과 대화하게 만듭니다:
에이전트 (Agent) → 질문 (Question) → LLM → 답변 (Answer) → 에이전트 (Agent)
이 아키텍처는 LLM이 메모리를 탐색(navigate)하게 만듭니다:
에이전트 (Agent) → 좌표 (Coordinate) → 해결사 (Resolver) → 콘텐츠 (Content) → 에이전트 (Agent)
언어는 가장자리(edges)에서 나타납니다. 포인터(pointers)는 중간에서 움직입니다.
"어떤 메모리가 의미론적으로 유사한가?"라고 묻는 대신,
"이것이 실제로 누구에게 필요한가, 그리고 무엇이 변했는가?"라고 묻게 됩니다.
멀티 에이전트 조정(multi-agent coordination)을 위해서는 이것이 더 중요한 질문일 수 있습니다.
SignalMesh (오픈 소스, MIT): github.com/Ig0tU/SignalMesh
라이브 API (Live API): acecalisto3-signalmesh.hf.space
데모 + 문서 (Demo + docs): kyklos.io
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기