swarm-test v0.3.4 — 에이전트 역할 자동 분류 (및 역할에 따라 실패의 의미가 달라지는 이유)

swarm-test v0.3.4는 에이전트 역할 자동 분류 기능을 추가합니다. 이제 이 도구는 그래프 내에서 각 에이전트가 무엇을 하는지 파악하며, 이를 바탕으로 역할별로 리스크를 다르게 해석합니다.

핵심 통찰은 다음과 같습니다: 모든 에이전트의 실패가 동일한 의미를 갖는 것은 아닙니다.

90%의 폭발 반경 (blast radius)을 가진 오케스트레이터 (orchestrator)는 예상된 결과입니다. 그것이 그 역할의 임무입니다. 모든 곳으로 작업을 라우팅 (routing)하므로, 당연히 그 실패는 모든 것에 영향을 미칩니다. 폴백 (fallback)이 필요하겠지만, 높은 폭발 반경 자체가 설계 결함은 아닙니다.

90%의 폭발 반경을 가진 워커 (worker)는 설계상의 결함 (design smell)입니다. 워커는 그렇게 많은 다운스트림 (downstream) 영향을 미쳐서는 안 됩니다. 만약 그렇다면, 무언가 잘못 연결된 것입니다.

동일한 지표이지만, 의미는 정반대입니다. 지금까지 swarm-test는 두 경우를 동일하게 표시했습니다. 이제는 그 차이를 인식합니다.

분류 방식:

swarm-test는 이름 및 역할 힌트와 결합하여 그래프 내 각 에이전트의 위치 — 입차수 (in-degree), 출차수 (out-degree), 매개 중심성 (betweenness centrality), 연결 패턴 — 를 분석합니다. 그리고 다음 중 하나를 할당합니다:

• ORCHESTRATOR — 작업을 라우팅하며, 중심적이고 설계상 폭발 반경이 높음
• WORKER — 작업 수행, 교체 가능해야 함
• VALIDATOR — 출력을 확인/승인하며, 보안에 민감함
• GATEWAY — 진입/진출 지점, 임계 경로 (critical path) 상에 있음
• AGGREGATOR — 많은 에이전트로부터 데이터를 수집 (높은 입차수)
• MONITOR — 시스템을 관찰하며, 임계 경로 밖에 있음
• ROUTER — 중간 홉 (intermediate hop)

각 역할에는 신뢰도 점수 (confidence score)와 리스크 프로필 (risk profile)이 부여됩니다.

저는 저의 14개 에이전트 시스템 (ARE, 여권 사진 처리 파이프라인)에 이를 실행해 보았습니다. 시스템은 다음과 같이 정확하게 식별했습니다:

• ComplianceAgent → VALIDATOR (신뢰도 97%, 보안 민감 항목으로 표시)
• HealthMonitorAgent → MONITOR (87%)
• OrchestratorAgent → ORCHESTRATOR ("높은 폭발 반경 예상"으로 표시)
• 처리 에이전트들 → WORKER / GATEWAY

역할에 따라 조정된 심각도 (role-adjusted severity) 단계에서 이 도구는 진가를 발휘합니다. 컨텍스트 누출 (context leakage)이 발생한 검증기 (validator)의 경우 심각도가 상향 조정됩니다. 데이터를 누출하는 검증기는 단순한 신뢰성 (reliability) 문제를 넘어 보안 (security) 문제입니다. 폭발 반경 (blast radius)이 큰 오케스트레이터 (orchestrator)의 경우, 이것이 '설계상 예상된 사항'이라는 메모가 남으므로, 수치에 당황하기보다는 폴백 (fallback)을 추가하는 데 집중할 수 있습니다.

이는 더 큰 가능성을 열어줍니다. 도구가 역할을 이해하게 되면, 설정 (config)에서 예상 역할을 선언할 수 있으며, 시간이 흐름에 따라 에이전트가 의도된 역할에서 벗어나는 (drift) 경우를 포착할 수 있습니다. 이에 대한 자세한 내용은 곧 다루겠습니다.

CrewAI, LangGraph, AutoGen 및 커스텀 오케스트레이터 (custom orchestrators) 전반에서 작동합니다.

pip install swarm-test --upgrade
GitHub: github.com/surajkumar811/swarm-test