sy/dev
Tool
13 min read

Solace Agent Mesh: event-driven multi-agent 시스템의 control plane 설계

Solace Agent Mesh를 통해 multi-agent orchestration을 DAG 실행기가 아니라 event fabric과 control plane 문제로 바라본다.

한 줄 요약

Solace Agent Mesh(SAM)는 여러 AI agent를 하나의 request/response 체인으로 엮는 대신, event broker 위에서 agent discovery, delegation, gateway, artifact 공유를 분리해 다루는 multi-agent framework다. 핵심은 “agent를 많이 띄운다”가 아니라 agent 간 통신을 production messaging 문제로 격상한다는 점이다.

다만 첫 문장부터 주의할 점이 있다. GitHub README 기준으로 Python 버전의 Solace Agent Mesh는 deprecated로 표시되어 있고, 신규 버전은 Solace 문서와 desktop app 쪽으로 안내된다. 그래서 이 글은 “지금 이 repo를 그대로 도입하자”가 아니라, event-driven agent mesh가 어떤 운영 문제를 드러내는지를 읽는 초안으로 보는 게 맞다.

왜 DAG 실행기만으로는 부족한가

많은 multi-agent 예제는 대략 이런 구조다.

  1. planner가 작업을 쪼갠다.
  2. specialist agent 몇 개를 순서대로 호출한다.
  3. 결과를 합쳐 final answer를 만든다.

데모로는 충분하다. 하지만 운영 환경에서는 금방 불편해진다.

  • 어떤 agent가 언제 바빠지는지 모른다.
  • 중간 산출물을 어디에 저장하고 누가 소유하는지 애매하다.
  • Slack, REST API, Web UI, 내부 시스템 이벤트가 모두 같은 entry point로 들어오지 않는다.
  • tool latency와 agent latency가 섞여 tail latency를 만든다.
  • 장애가 났을 때 “어느 agent가 어떤 메시지를 보고 어떤 결정을 했는지” 추적하기 어렵다.

즉 multi-agent orchestration은 단순히 graph node를 실행하는 문제가 아니다. 백엔드 관점에서는 message routing, backpressure, lifecycle, observability, 권한 경계가 붙은 distributed system 문제다.

Solace Agent Mesh가 흥미로운 이유는 이 문제를 LLM framework 내부 callback으로 숨기지 않고, Solace Platform Event Broker를 transport로 둔 event-driven architecture로 풀려고 한다는 점이다.

구조: agent runtime과 messaging layer를 분리한다

README 기준 SAM은 Solace AI Connector(SAC), Google Agent Development Kit(ADK), Solace Platform Event Broker를 조합한다.

큰 흐름은 이렇게 볼 수 있다.

  • ADK: LLM 호출, tool 실행, agent logic 담당
  • SAC: broker 연결, 설정 로딩, component lifecycle 담당
  • Solace Event Mesh: agent-to-agent 메시지 전달과 decoupling 담당
  • Gateway: REST API, Web UI, Slack 등 외부 interface 연결
  • Orchestrator agent: 작업 분해와 peer agent delegation 담당
  • Artifact/data tool: 파일, SQL, JQ, visualization, dynamic embed 같은 산출물 처리 담당

이 분리는 꽤 중요하다. agent framework가 모든 것을 “Python 함수 호출”로만 보면 운영 경계가 흐려진다. 반대로 messaging layer를 명시하면 다음 질문을 던질 수 있다.

  • agent capability는 어떻게 discover되는가?
  • delegation 메시지의 schema와 실패 응답은 무엇인가?
  • 같은 작업이 재시도될 때 idempotency key가 있는가?
  • user-facing gateway와 internal agent channel은 분리되는가?
  • artifact는 메시지 payload에 넣는가, 별도 store에 두고 reference만 전달하는가?

이 질문들이야말로 production multi-agent의 실제 설계 포인트다.

Control plane 관점으로 읽기

SAM을 “또 하나의 agent framework”로 보면 별로 새롭지 않을 수 있다. 하지만 control plane으로 보면 배울 점이 많다.

1. Capability routing

agent가 많아질수록 중요한 것은 “누가 답을 잘하나”보다 “어떤 capability를 어떤 조건에서 호출할 것인가”다. Database Agent, MultiModal Agent, report agent처럼 역할이 나뉘면 orchestrator는 자연어 설명만 보고 위임하기보다 capability catalog를 기준으로 route를 골라야 한다.

실무에서는 여기에 version과 policy가 붙어야 한다.

  • 이 agent는 read-only인가, mutation 가능한가?
  • PII가 포함된 artifact를 볼 수 있는가?
  • long-running task를 받을 수 있는가?
  • 실패 시 fallback agent가 있는가?

SAM의 A2A delegation 흐름은 이런 capability routing 문제를 드러내는 좋은 예시다.

2. Gateway는 UX adapter가 아니라 trust boundary다

README는 REST API, Web UI, Slack 같은 gateway를 지원한다고 설명한다. 겉보기에는 interface 선택지처럼 보이지만, 운영에서는 gateway가 trust boundary가 된다.

Slack에서 들어온 요청과 내부 batch job에서 들어온 요청은 같은 권한을 가지면 안 된다. Web UI 사용자가 업로드한 파일과 내부 database query 결과도 같은 artifact policy를 가져서는 안 된다.

그래서 gateway 설계에는 최소한 다음이 필요하다.

  • 사용자/채널 identity 매핑
  • request provenance 기록
  • 허용 tool 범위 제한
  • rate limit과 abuse control
  • 결과를 외부 채널로 내보내기 전 redaction

agent mesh는 gateway가 많아질수록 편해지는 동시에 위험해진다. 이 경계를 명시하지 않으면 “멀티채널 AI”가 아니라 “멀티채널 권한 누수”가 된다.

3. Artifact는 message가 아니라 상태다

multi-agent system에서 중간 산출물은 계속 커진다. SQL 결과, 이미지, CSV, report draft, chart, log bundle을 모두 LLM context에 넣을 수는 없다.

SAM은 file artifact, metadata injection, dynamic embeds 같은 기능을 언급한다. 이 방향은 맞다. agent 간 협업에서 artifact는 단순 텍스트가 아니라 다음 속성을 가진 상태여야 한다.

  • 누가 만들었는가
  • 어떤 input에서 만들어졌는가
  • 현재 버전은 무엇인가
  • 외부로 공유 가능한가
  • 다시 계산할 수 있는가

특히 dynamic embed는 조심해서 써야 한다. 응답 시점에 실시간 데이터나 파일 내용을 resolve하면 편하지만, 재현성은 낮아진다. 감사 가능한 시스템을 만들려면 “표시된 값”과 “나중에 다시 resolve한 값”이 달라질 수 있다는 점을 trace에 남겨야 한다.

Event-driven 설계가 주는 이점

event broker 기반 agent mesh의 장점은 agent 사이의 시간 결합을 약하게 만든다는 것이다.

  • producer는 consumer agent의 내부 구현을 몰라도 된다.
  • agent가 잠깐 느려져도 queue/broker level에서 완충할 수 있다.
  • gateway, orchestrator, specialist agent를 독립적으로 배포할 수 있다.
  • event log를 trace와 replay의 기반으로 쓸 수 있다.

이건 특히 long-running workflow에 유리하다. 예를 들어 데이터 분석 agent가 SQL을 실행하고, visualization agent가 chart를 만들고, report agent가 초안을 작성하고, human approval gateway가 Slack으로 확인을 받는 흐름을 생각해보자. 전부 synchronous call stack으로 묶으면 timeout과 retry가 지옥이 된다. event-driven으로 분리하면 각 단계의 실패와 재시도를 별도 policy로 다룰 수 있다.

그래도 조심해야 할 점

Event-driven이라고 자동으로 production-ready가 되는 것은 아니다. 오히려 새로운 실패 모드가 생긴다.

메시지 중복과 순서

broker 기반 시스템은 중복 전달, out-of-order 처리, 재시도 문제를 반드시 다뤄야 한다. agent action이 read-only면 괜찮지만, ticket 생성, PR comment 작성, 이메일 발송처럼 외부 side effect가 있으면 idempotency key와 approval gate가 필요하다.

관측성 폭발

agent가 많아지면 trace도 많아진다. 단순히 모든 prompt와 response를 저장하면 비용과 privacy 문제가 생긴다. 필요한 것은 raw transcript 저장소가 아니라 다음을 연결하는 trace model이다.

  • request id
  • gateway identity
  • delegation chain
  • tool call id
  • artifact id/version
  • approval decision
  • final output

Orchestrator 단일 장애점

orchestrator agent가 모든 분해와 위임을 맡으면 시스템은 다시 중앙집중화된다. orchestration logic은 좋아 보이지만, 과도하게 똑똑한 orchestrator는 병목과 drift의 원인이 된다. capability registry, policy engine, deterministic router와 LLM planner의 역할을 나눠야 한다.

Deprecated repo 리스크

가장 현실적인 주의점은 이것이다. 현재 GitHub README는 Python 버전이 deprecated이며 새 버전을 보라고 안내한다. 따라서 새 프로젝트에서 이 repo를 직접 dependency로 삼기 전에는 공식 문서의 최신 제품/SDK 방향, 보안 업데이트, 라이선스, 배포 모델을 확인해야 한다.

실무 적용 체크리스트

Event-driven multi-agent를 직접 설계한다면, 프레임워크 선택 전에 아래부터 정하는 편이 낫다.

  • Message contract: agent request/response/error/event schema를 고정했는가?
  • Capability registry: agent가 할 수 있는 일, 권한, 입력 조건을 machine-readable하게 관리하는가?
  • Idempotency: 외부 side effect가 있는 action에 중복 실행 방지가 있는가?
  • Artifact store: 큰 결과물은 payload가 아니라 reference와 metadata로 전달되는가?
  • Gateway policy: Slack/API/Web UI별 identity와 tool 권한이 분리되는가?
  • Backpressure: 특정 agent가 느려질 때 queue depth, timeout, fallback이 정의되어 있는가?
  • Trace model: delegation chain과 tool call, artifact version을 한 request id로 묶을 수 있는가?
  • Human approval: irreversible action 앞에 승인 게이트가 있는가?

내 의견은 단순하다. multi-agent 시스템을 만들 때 첫 선택지는 “어떤 agent framework를 쓸까”가 아니라 어떤 control plane을 둘까여야 한다. framework는 바뀐다. 메시지 계약, 권한 경계, trace 구조는 한 번 잘못 깔면 오래 간다.

다음에 더 볼 것

이 초안에서는 README와 공개 repo 기준으로 architecture 관점만 정리했다. 더 다듬으려면 아래를 추가 확인하면 좋다.

  • 새 Solace Agent Mesh 문서에서 Python repo 이후 구조가 어떻게 바뀌었는지
  • A2A protocol message schema와 error handling 방식
  • gateway별 auth/permission model
  • broker 장애나 agent 재시작 시 replay/retry semantics
  • 실제 sample app에서 artifact와 dynamic embed가 trace에 어떻게 남는지

참고 자료

Comments