refactor: remove legacy multi-agent-mux skills and infrastructure, and add Mattermost notification script and collaboration documentation
This commit is contained in:
+120
-16
@@ -99,35 +99,139 @@ AIoT 서비스 환경에서 멀티 에이전트 오케스트레이션(Multi-Agen
|
||||
|
||||
이 네 가지 문제(실행 주기 불일치, 동적 바인딩 및 다유형 메시지 교환, 자원 최적화 위임, 물리 제어 멱등성 결여)는 에이전트와 물리 계층의 경계면에서 공통적으로 발생하며, 에이전트의 상태, 장치 명세, 태스크 생명주기 및 제어 안정성을 유기적으로 공유할 때 비로소 제어가 가능하다. 따라서 이를 개별 기능 단위로 분리하여 접근하기보다는 하나의 단일 통합 인터페이스 모듈(Unified Interface Module)로 설계하여 처리하는 것이 통신 연동의 정합성, 전체 시스템 효율성 및 물리 제어 안정성 확보 측면에서 필수적이다.
|
||||
|
||||
# gRPC-based Unified Interface Module for Multi-Agent Orchestration in AIoT Services [추후 작성]
|
||||
# gRPC-based Unified Interface Module for Multi-Agent Orchestration in AIoT Services
|
||||
|
||||
본 논문에서는 다음과 같은 범용적인 AIoT 서비스 구조에서 사용될 수 있는 Multi-Agent 인터페이스 모듈을 설계 제안한다.
|
||||
본 장에서는 실제 엣지 AIoT 환경의 물리적 제약 하에서 멀티 에이전트 간 협업 및 기기 제어를 안정적으로 중재하기 위한 **gRPC 기반 통합 인터페이스 모듈(gRPC-based Unified Interface Module)**의 상세 구조와 메커니즘을 제안한다.
|
||||
|
||||
## Design Goals and Requirements
|
||||
- 4대 문제 정의(시간·연결·자원·안정성 축)와 설계 요구사항 간의 매핑(Traceability)
|
||||
- 통합 모듈로 설계해야 하는 이유의 아키텍처 수준 재정리
|
||||
|
||||
본 연구에서 설계하는 통합 인터페이스 모듈은 앞서 2장에서 정의한 시간, 연결, 자원, 안정성의 4대 구조적 문제를 해결하기 위해 다음과 같은 설계 목표(Design Goals, DG)를 수립하고, 설계 정합성(Traceability)을 확보한다.
|
||||
|
||||
- **DG-1 (시간 축 해소): execution paradigm mismatch 중재**
|
||||
상시 지속 스트리밍 상태인 AIoT 물리/센싱 계층과 일시적 작업(Job) 단위로 자율 구동되는 LLM 에이전트 간의 주기 격차를 전송 계층(Transport Layer) 수준에서 극복한다. 이를 위해 UDP 기반의 **gRPC over QUIC (HTTP/3)** 프로토콜을 도입하여 패킷 유실 시에도 다른 스트림에 정체를 유발하지 않으며, 단절 후 빠른 복구를 보장한다.
|
||||
- **DG-2 (연결 축 해소): dynamic binding 및 다유형 메시지 교환 지원**
|
||||
이기종 디바이스와 다양한 AI 추론 모델의 입출력 규격을 런타임에 동적으로 매핑하기 위해 **A2A 표준 규격 기반의 Agent Card**를 파싱하고 바인딩하는 인터페이스를 구현한다. 또한 Protobuf를 이용해 텍스트 데이터뿐만 아니라 멀티모달 바이너리, 에러 트레이스 구조체를 단일 스키마 내에 통합 처리한다.
|
||||
- **DG-3 (자원 축 해소): event-driven resource delegation**
|
||||
자원 제약이 극심한 엣지 단말에서 AI 에이전트가 상시 대기하며 연산 및 네트워크 대역폭을 낭비하는 문제를 방지한다. 평소에는 경량 센싱 모니터링 모듈만 구동하다가, 기기 이상 등 트리거 이벤트 포착 시에만 에이전트를 비동기 기동하여 제어권을 위임(Delegation)하고 작업 완료 후 반환받는 생명주기 제어를 구축한다.
|
||||
- **DG-4 (안정성 축 해소): control idempotency assurance**
|
||||
네트워크 일시 단절 및 에이전트 내부 예외로 인한 자율 재시도(Retry) 과정에서 동일한 제어 명령이 물리 장치에 중복 수행되어 오작동이나 안전사고를 일으키는 현상을 원천 방지한다. 제어 명령의 멱등성 여부를 분류하고, **Control Intent Key (CIK)** 및 사전 검증(Pre-flight Check) 인터페이스를 통해 제어 안정성을 보장한다.
|
||||
|
||||
---
|
||||
|
||||
## Overall Architecture
|
||||
- 전체 시스템 구조도: 에이전트 계층 – 통합 인터페이스 모듈 – 물리 기기/추론 모델 계층
|
||||
- 모듈 내부 구성요소 및 상호작용 흐름 개요
|
||||
|
||||
제안하는 통합 인터페이스 모듈은 T1 Cloud Agent Layer, T2 Edge Gateway Layer, T3 Field Device Layer의 3-tier 아키텍처 상에서 중추적인 중재자 역할을 수행하며, 물리적 위치상 **T2 Edge Gateway**에 상주한다.
|
||||
|
||||
```
|
||||
+---------------------------------------------------------+
|
||||
| T1 Cloud Agent Layer |
|
||||
| - A2A Orchestrator (Python) |
|
||||
| - gRPC Python Client (with QUIC / HTTP/2 Fallback) |
|
||||
+---------------------------------------------------------+
|
||||
|
|
||||
| gRPC over QUIC (HTTP/3)
|
||||
v
|
||||
+---------------------------------------------------------+
|
||||
| T2 Edge Gateway Layer |
|
||||
| +---------------------------------------------------+ |
|
||||
| | Unified Interface Module | |
|
||||
| | 1. gRPC-over-QUIC Engine (Go, quic-go) | |
|
||||
| | 2. Agent Card Parser & Discovery (A2A Standard) | |
|
||||
| | 3. Event-Driven Task Delegator | |
|
||||
| | 4. Idempotency Controller (CIK Check, Cache) | |
|
||||
| | 5. Protocol Bridge (MQTT/CoAP <-> gRPC) | |
|
||||
| +---------------------------------------------------+ |
|
||||
+---------------------------------------------------------+
|
||||
|
|
||||
| MQTT v5 / CoAP (RFC 7252)
|
||||
v
|
||||
+---------------------------------------------------------+
|
||||
| T3 Field Device Layer |
|
||||
| - Micro Sensing Agent (C / MicroPython) |
|
||||
| - Actuators & Sensors (GPIO, Modbus) |
|
||||
+---------------------------------------------------------+
|
||||
```
|
||||
|
||||
1. **상호작용 흐름**:
|
||||
- T3 디바이스는 센싱 계층으로서 지속적으로 온도, 습도, 영상 데이터 등을 MQTT를 통해 T2 게이트웨이로 전송한다.
|
||||
- T2 게이트웨이의 `Protocol Bridge`는 센싱 데이터를 정형화된 gRPC 스트림으로 변환해 T1 클라우드로 라우팅한다.
|
||||
- T2의 `Event-Driven Task Delegator`가 기기 온도의 비정상적 과열 등 특정 이상 이벤트를 감지하면, 즉시 T1 클라우드의 자율 에이전트(Control Layer)에 신호를 전송하여 태스크를 위임한다.
|
||||
- 에이전트가 판단한 제어 명령은 gRPC 호출을 통해 T2 게이트웨이로 전달되며, 게이트웨이 내부의 `Idempotency Controller` 검증을 거친 후 최종 T3의 액추에이터 제어 명령(MQTT)으로 변환되어 하향 실행된다.
|
||||
|
||||
---
|
||||
|
||||
## gRPC Communication Backbone
|
||||
- Protobuf 기반 메시지 스키마 정의 (태스크, 이벤트, 제어 명령 규격)
|
||||
- QUIC(HTTP/3) 기반 양방향 스트리밍(RPC별 독립 스트림 매핑)을 통한 상시 연결 계층과 작업 단위 계층의 중재 및 다이얼 실패 기반 HTTP/2 폴백(Fallback) 전송 절차 (시간 축 해소)
|
||||
- Request/Response 및 스트리밍 기반 Pub/Sub 패턴 구현 (과대 주장 방지: N:N 팬아웃 및 보존이 필요한 대규모 통신은 별도 메시지 브로커 연동 필요 제약 명기)
|
||||
|
||||
통합 인터페이스 모듈의 핵심 전송 엔진은 **gRPC over QUIC (HTTP/3)** 프로토콜을 통신 백본으로 삼는다. 이는 공식 gRPC Go 스택이 HTTP/3를 표준 지원하지 않는 한계를 해소하기 위해 `quic-go` 라이브러리를 이용하여 전송 계층을 커스텀 래핑하여 구현되었다.
|
||||
|
||||
### 1) UDP 기반 QUIC 스트림 1:1 매핑 (HOLB 해소)
|
||||
기존 HTTP/2 기반 gRPC는 단일 TCP 커넥션 상에서 멀티플렉싱을 수행하기 때문에, 무선 네트워크 유실 등으로 인해 특정 패킷이 손실될 경우 TCP의 신뢰성 보장 메커니즘으로 인해 전체 스트림의 전송이 일시 정지되는 Head-of-Line Blocking(HOLB) 현상이 일어난다. 제안 모듈은 각 RPC 호출을 UDP 상의 독립적인 QUIC 스트림으로 1:1 매핑한다. 이로 인해 한 스트림에서 패킷 유실 및 지연이 일어나더라도, 다른 에이전트의 제어 스트림 및 미디어 바이너리 스트리밍은 아무런 간섭 없이 정상 통신을 유지한다.
|
||||
|
||||
### 2) Connection Migration 및 0-RTT 재연결
|
||||
이동형 게이트웨이(예: RSU, 자율주행 차량, 스마트 팜 내 이동형 로봇) 환경에서 통신 물리 기지국이 변경되어 IP 주소가 급격히 전환되더라도, QUIC의 Connection ID 기반 세션 유지 특성 덕분에 핸드셰이크 과정을 처음부터 다시 거치지 않고 기존 연결 상태를 지속하는 **Connection Migration**을 지원한다. 또한, 네트워크가 일시적으로 완전히 단절되었다가 복구되었을 때, 0-RTT 재연결 메커니즘을 활용하여 1왕복(1-RTT) 지연 없이 즉시 통신 세션을 회복하고 Resume Token을 통해 유실된 데이터 스트림의 오프셋부터 재조정(Resynchronization)을 개시한다.
|
||||
|
||||
### 3) 다이얼 실패 기반 HTTP/2 Fallback 전송 절차
|
||||
엣지 환경에 구축된 보안 방화벽이나 미들박스(Middlebox)가 UDP 트래픽 또는 특정 QUIC 포트를 명시적으로 차단하는 비표준 예외 상황이 빈번히 발생한다. 이를 위해 게이트웨이 및 클라이언트 다이얼러 모듈 내부에 **Fallback 절차**를 내장한다.
|
||||
1. 최초 연결 시도 시 UDP 상의 gRPC over QUIC 핸드셰이크를 우선 수행한다.
|
||||
2. 지정된 제한 시간(예: 1.5초) 내에 핸드셰이크 응답이 오지 않거나 UDP 소켓 에러가 검출될 경우, 즉시 백그라운드 스레드에서 TCP 기반의 표준 gRPC over HTTP/2 연결을 병렬 다이얼링한다.
|
||||
3. 연결 전송 계층이 하향 전환(Fallback)되었음을 시스템 로깅 및 메타데이터 필드에 기록하여, 상위 에이전트 조율 계층이 이를 인지하고 트래픽 페이로드 크기나 빈도를 최적화할 수 있도록 중재한다.
|
||||
|
||||
---
|
||||
|
||||
## Agent Card-based Dynamic Binding Layer
|
||||
- 에이전트/장치/추론 모델 명세의 Agent Card 규격화 및 서빙 (`/.well-known/agent-card.json`)
|
||||
- 서비스 디스커버리 및 런타임 동적 바인딩 절차 (연결 축 해소)
|
||||
|
||||
이기종 멀티 에이전트 및 다양한 물리 기기가 런타임에 동적으로 규격을 확인하고 바인딩할 수 있도록 **에이전트 카드(Agent Card)** 규격을 도입한다.
|
||||
|
||||
- **표준 메타데이터 제공**: 모든 기기 및 에이전트 노드는 `/.well-known/agent-card.json` 정형 엔드포인트를 노출한다. 이 문서에는 자신의 식별자(UUID), 제공 역할(Sensing/Control), 통신 프로토콜(gRPC, MQTT), 하부 메서드 스키마, 보안 규격(SPIFFE ID 등)이 기입되어 있다.
|
||||
- **런타임 동적 해석**: T2 게이트웨이는 부팅 시 또는 새로운 디바이스가 로컬 네트워크에 조인(Join) 시, 해당 에이전트 카드를 자동으로 스캔 및 분석한다.
|
||||
- **라우팅 테이블 자동 갱신**: 카드 내의 입력 스키마와 gRPC 메서드 매핑 정보를 바탕으로 게이트웨이 내부의 `Dynamic Method Map`을 자동 빌드하여, 소스코드의 수정이나 수동 컴파일 과정 없이 새로운 장치를 플러그 앤 플레이(Plug & Play) 형태로 에이전트 통신 백플레인에 연동한다.
|
||||
|
||||
---
|
||||
|
||||
## Event-Driven Task Delegation and Lifecycle Management
|
||||
- 경량 감시 프로그램과 에이전트의 역할 분리 구조
|
||||
- 이벤트 발생 시 태스크 위임–실행–제어권 회수의 생명주기 관리 (자원 축 해소)
|
||||
- 로드 밸런싱 및 에이전트 상태 감시 (liveness) 연동
|
||||
|
||||
엣지 자원 활용을 극대화하기 위해, 상시 가동되는 센싱 파이프라인과 비동기식 자율 에이전트 가동을 이벤트 기반으로 연계한다.
|
||||
|
||||
- **역할 및 리소스 격리**: 리소스 제약이 심한 현장 노드에는 LLM 추론 엔진이나 무거운 에이전트 코드를 적재하지 않고, 시계열 데이터를 단순 필터링 및 변환하는 경량 센싱 프로그램만 동작시킨다.
|
||||
- **비동기 위임 생명주기**:
|
||||
1. 센싱 계층에서 한계값을 초과하는 이상 징후(예: 토양 수분 급감, 잎사귀 병해 포착) 감지 시, T2 게이트웨이의 `Task Delegator`가 기동되어 T1의 대기 중인 자율 에이전트에 **A2A Task Create** 이벤트를 발행한다.
|
||||
2. 에이전트 엔진이 동적으로 할당되어 해당 이벤트의 컨텍스트(센서값, 장치 카드 등)를 로드하고, 목표 분석 및 제어 계획을 세운다.
|
||||
3. 제어 명령이 안전하게 물리 기기에 송신 및 실행 완료(Control completed)되면, 에이전트는 상태 정보를 저장하고 리소스를 반환(T1 세션 정리)하여 휴면 상태로 진입한다.
|
||||
- **Liveness 감시 통합**: 에이전트가 예외 동작으로 인해 고사(Silent Death)하는 현상을 예방하기 위해 Kubernetes의 gRPC liveness probe 사양을 연동하여, 에이전트 세션의 활성 상태를 주기적으로 모니터링하고 데드락 포착 시 즉시 복구 이벤트를 퍼블리시한다.
|
||||
|
||||
---
|
||||
|
||||
## Idempotent Control Schema
|
||||
- 제어 명령의 멱등/비멱등 분류 명세
|
||||
- Control Intent Key 기반 중복 발행 억제 및 사전 검증(pre-flight check) 절차 (안정성 축 해소)
|
||||
|
||||
자율 에이전트의 재시도 루프 시 물리 계층에 전달되는 비멱등 제어 명령의 중복 실행으로 인한 물리적 파괴 및 오작동을 차단한다.
|
||||
|
||||
### 1) 제어 명령의 멱등/비멱등 분류
|
||||
- **멱등(Idempotent) 명령**: 수차례 호출해도 상태가 동일하게 유지되는 명령 (예: `GetTemperature()`, `SetTargetHumidity(55%)`).
|
||||
- **비멱등(Non-idempotent) 명령**: 실행 횟수가 늘어날수록 물리적 부작용이 누적되는 명령 (예: `SprayPesticide(500ml)`, `OpenValve(30s)`).
|
||||
|
||||
### 2) Control Intent Key (CIK) 메커니즘
|
||||
- 에이전트가 제어를 개시할 때, 동일한 제어 의도(Control Intent)를 식별하기 위한 고유한 결정론적 식별자인 **Control Intent Key (CIK)**를 헤더 또는 페이로드에 동반시킨다.
|
||||
- CIK는 작업 ID(Job ID)와 독립적으로 생성되며, 네트워크 타임아웃 등으로 인해 에이전트가 재시도를 수행하여 신규 Job ID를 생성하더라도 CIK는 원본 제어 의도와 동일한 값을 유지한다.
|
||||
|
||||
### 3) Gateway-side Pre-flight Check 및 중복 억제
|
||||
T2 게이트웨이 내부의 `Idempotency Controller`는 하향 제어 패킷이 수신되었을 때 다음 절차를 밟아 중복을 필터링한다:
|
||||
```
|
||||
[gRPC Control Request 수신]
|
||||
|
|
||||
v
|
||||
[명령이 비멱등(Non-idempotent)인가?]
|
||||
/ \
|
||||
(Yes) (No)
|
||||
/ \
|
||||
[CIK가 캐시에 존재하는가?] [즉시 물리 기기 실행]
|
||||
/ \
|
||||
(Yes) (No)
|
||||
/ \
|
||||
[이전 실행결과 반환] [CIK 캐시 등록 및 물리 기기 실행]
|
||||
(중복 실행 차단)
|
||||
```
|
||||
- 이미 성공적으로 실행 완료된 CIK에 대한 요청인 경우, 하부 기기를 다시 동작시키지 않고 캐시해 둔 이전 완료 상태 코드 및 실행 메트릭을 클라이언트에 즉시 회신한다.
|
||||
- 이를 통해 네트워크 단절 구간 및 에이전트 루프 복구 과정에서의 중복 투여/중복 제어 안전 위협을 완전히 소화한다.
|
||||
|
||||
# Testbed Configuration
|
||||
|
||||
|
||||
@@ -20,7 +20,7 @@
|
||||
* **[S2] AIoT 엣지 환경에 특화된 Resumable/Stateful gRPC 스트리밍 아키텍처 설계**
|
||||
* 단순히 에이전트 통신에 gRPC를 적용하는 일반적 설계를 넘어, 네트워크 연결 유실이 빈번한 AIoT 엣지 연산 제약 환경을 타겟으로 'Resume Token' 기반의 스트림 재개 및 분산 상태 보존 설계를 강점으로 내세우고 있습니다. 기존 연구들이 단순 HTTP/REST나 비영속 웹소켓 통신에 의존한 반면, 본 아키텍처는 가용성을 극대화하기 위한 전송-오케스트레이션 결합 설계를 구체적으로 제안했다는 점에서 차별성을 갖습니다.
|
||||
* **[S3] 검증 가능한 구체적 연구 가설 (Cross-Model Review)**
|
||||
* 자가 검토(Same-Model Review)와 이종 모델 교차 검토(Cross-Model Review, 예: Gemini Flash ↔ Claude Sonnet)의 결과물 신뢰도 향상 및 오류 감지율에 관한 가설은 독립적인 실증 논문으로 구성하기에 충분할 정도로 구체적이고 검증 가능한(Falsifiable) 훌륭한 연구 주제입니다.
|
||||
* 자가 검토(Same-Model Review)와 이종 모델 교차 검토(Cross-Model Review, 예: Gemini Flash ↔ Claude Sonnet)가 결과물의 신뢰도와 오류 감지율에 미치는 영향에 관한 가설은 충분히 구체적이고 검증 가능(Falsifiable)하여, 독립적인 실증 논문으로 발전시킬 수 있는 훌륭한 연구 주제입니다.
|
||||
* **[S4] 현실적인 3계층 하이브리드 네트워크 설계**
|
||||
* 모든 인프라를 gRPC로 획일화하지 않고, 대역폭 및 성능 제약이 극심한 초경량 센서 디바이스는 MQTT/CoAP을 보완적으로 쓰고, 상위 게이트웨이 및 엣지 연산 계층에 gRPC를 배치한 완충 설계(Hedge)는 네트워크 실무와 아키텍처의 트레이드오프를 훌륭히 방어해 냅니다.
|
||||
* **[S5] 최신 프로토콜 표준 동향 반영**
|
||||
|
||||
Reference in New Issue
Block a user