Sprix SAGE Router 소개
Agent2Agent(A2A) 프로토콜 (
Google, AI 에이전트들간의 협업을 위한 A2A(Agent-to-Agent) 프로토콜 공개)처럼 에이전트끼리 서로를 찾아 대화하게 만드는 규격이 자리를 잡으면서, 이제는 "어떤 에이전트가 존재하는가"는 어렵지 않게 알 수 있게 되었습니다. Agent Card로 능력을 선언하고, 메시지와 작업(Task)과 산출물(Artifact)을 주고받는 절차도 프로토콜이 정해 줍니다. 그런데 실제 운영에서 더 자주 부딪히는 질문은 그다음입니다. 어떤 에이전트가 작업을 이미 절반쯤 진행한 상태에서, 그대로 혼자 끝내는 것이 나은지, 부족한 능력을 채워 줄 동료를 불러야 하는지, 아니면 더 잘하는 에이전트에게 통째로 넘겨야 하는지를 프로토콜은 결정해 주지 않습니다.
Sprix SAGE Router는 이 결정을 담당하는 계층으로 설계된 Python 라이브러리입니다. SAGE는 상태 인식 그래프 교환(State-Aware Graph Exchange)의 약자로, 이름 그대로 현재 실행 상태를 판단 재료에 포함시킵니다. 이미 완료된 작업 노드, 지금 배정된 실행자, 누적된 진행률, 실패 이력, 그리고 넘길 때 잃게 되는 맥락의 양까지 하나의 목적 함수(Utility Function)에 넣고, SELF(혼자 계속), COLLABORATE(협업), HANDOFF(인계) 세 경로를 같은 기준으로 비교합니다. 세 경로를 각각 다른 규칙(Heuristic)으로 나눠 판단하지 않는다는 점이 이 프로젝트가 내세우는 핵심 설계입니다.
Sprix SAGE Router는 Python 3.10 이상에서 동작하고 런타임(Runtime) 의존성이 없어 git clone 후 바로 실행할 수 있습니다. 저장소는 屿智同行의 A2A 사업부인 Sprix AI가 공개한 알고리즘 연구 산출물이며, 저자들은 프로젝트 상태를 초기 단계의 연구 프리뷰(Research Preview)로 명시하고 있습니다. 프로토콜 위에서 실제 작업을 전송하고 엔드포인트를 인증하고 서명을 검증하는 일은 이 프로젝트가 하지 않으며, 그 책임은 A2A 클라이언트에 남겨 둡니다.
Sprix SAGE Router가 비교하는 세 가지 경로
SAGE가 다루는 선택지는 다음 세 가지이고, 프로젝트는 각 경로에서 작업의 소유권이 누구에게 남는지를 함께 명시하고 있습니다:
| 경로 | 소유권 | 적합한 상황 |
|---|---|---|
| SELF | 기존 담당 에이전트 | 이미 가진 능력과 누적된 맥락으로 충분할 때 |
| COLLABORATE | 기존 담당 에이전트가 유지 | 작은 보완 팀이 빠진 요구사항을 메울 수 있을 때 |
| HANDOFF | 동료 에이전트가 완전히 인수 | 전문성의 이득이 맥락 이전 손실보다 클 때 |
소유권 열이 중요한 이유는 COLLABORATE와 HANDOFF가 겉보기에 비슷해 보여도 운영상 전혀 다른 사건이기 때문입니다. 협업에서는 기존 에이전트가 계속 작업을 들고 있으면서 일부 요구사항만 다른 실행자에게 배정하고, 인계에서는 작업 자체가 다른 에이전트의 것이 됩니다. 그래서 인계 쪽에는 맥락 이전 손실이라는 비용이 붙고, SAGE의 목적 함수는 그 비용을 명시적인 항으로 뺍니다.
이 세 경로를 고르는 방식에서 프로젝트가 밝히는 차별점도 몇 가지 구체적입니다. 팀을 꾸릴 때 개별 순위가 높은 에이전트를 모으는 것이 아니라 요구사항을 새로 덮는 정도, 즉 한계 커버리지에 보상을 주고, 신뢰도는 하나의 평판 점수가 아니라 에이전트별과 요구사항별로 따로 학습합니다. 코딩에서 잘한 이력이 리서치 능력을 자동으로 보장하지 않는다는 판단입니다. 권한이 맞지 않는 에이전트는 예측 품질이 아무리 높아도 순위 계산에 아예 들어가지 못합니다.
Sprix SAGE Router의 라우팅 파이프라인
Sprix AI가 공개한 위 구조도는 A2A 프로토콜 계층에서 내려온 선언과 실시간 작업 상태가 네 단계를 지나 실행 계획으로 떨어지는 흐름을 보여 줍니다. 첫 단계인 적합성 게이트에서 가용성, 이전 실패, 권한, 위험 보정 비용과 지연이 예산과 마감 안에 들어오는지를 걸러 후보를 줄입니다. 두 번째 단계에서 SELF, HANDOFF, COLLABORATE 각각의 후보 집합을 만들되 예산을 만족하는 접두 조합만 확장하고, 세 번째 단계에서 요구사항별 실행자 배정과 일정을 함께 탐색합니다. 마지막 단계에서 실현 가능한 경로들을 목적 함수로 정렬하는데, 점수가 높다고 해서 앞서 걸린 하드 필터가 다시 열리지는 않습니다.
파이프라인의 오른쪽 끝은 전송 방식에 중립적인 실행 계획입니다. 소유권, 요구사항 배정, 작업의 방향성 비순환 그래프(DAG, Directed Acyclic Graph) 의존성, 통신 위상, 추정 비용과 지연, 그리고 왜 그 경로가 선택됐는지의 근거가 함께 들어갑니다. 실행이 끝나면 요구사항별과 에이전트별 결과가 학습 경로를 타고 되돌아와 맥락별 신뢰도, 짝 효과, 견적 정확도를 갱신합니다. 팀 전체에만 붙은 결과는 낮은 가중치로 처리해서, 함께 있었다는 이유만으로 모든 참여자가 같은 공적을 받지 않게 했습니다.
감사 측면에서 눈에 띄는 것은 route_with_trace 입니다. 이 함수는 선택된 경로만 돌려주지 않고 순위가 매겨진 대안들, 자격을 통과한 에이전트 목록, 그리고 하드 필터에서 탈락한 이유까지 기록으로 남깁니다. 학습된 상태는 버전이 붙은 JSON 스냅샷으로 저장돼 재시작 후에도 이어집니다.
Sprix SAGE Router의 목적 함수
요구사항 r 에 대해 SAGE는 전역 신뢰도와 요구사항별 신뢰도를 합쳐 보정된 역량 q_{a,r} 을 계산하고, 팀 S 의 커버리지를 다음과 같이 정의합니다:
각 에이전트가 독립적으로 그 요구사항을 실패할 확률을 곱해서, 하나라도 성공할 확률을 커버리지로 삼는 형태입니다. 같은 능력을 가진 에이전트를 여럿 모아도 커버리지가 크게 오르지 않는 구조라, 앞서 말한 한계 커버리지 보상이 수식 차원에서 나옵니다.
실현 가능한 모든 경로는 아래 식으로 순위가 매겨집니다:
여기서 m 은 경로 모드, S 는 팀, z 는 역할 배정, E 는 그 배정에서 유도되는 통신 위상입니다. H 가 맥락 이전 손실이고 O 는 조율 비용이며, \mathcal U 와 \mathcal B 는 불확실성을 고려한 탐색에 쓰입니다. 초기 버전의 고정된 성공 확률 식은 정규화된 온라인 예측기 \hat p_\theta 로 대체되었고, 저자들은 이 자리를 나중에 프로덕션 보상 모델(Reward Model)로 교체할 수 있게 열어 두었다고 설명합니다. 전체 설계와 한계는 저장소의 ALGORITHM.md에 정리되어 있습니다.
Sprix SAGE Router 설치와 최소 사용 예시
런타임 의존성이 없어 저장소를 받아 바로 데모를 돌릴 수 있습니다:
git clone https://github.com/wang2122/sprix-sage-router.git
cd sprix-sage-router
python demo.py
검증 스위트와 벤치마크도 같은 방식으로 실행합니다:
python -m unittest -v
python benchmark.py
README가 제시하는 최소 사용 예시는 에이전트 두 개와 의존 관계가 있는 요구사항 두 개로 이루어져 있습니다:
from sprix_sage import Agent, ExecutionOutcome, Requirement, SAGERouter, Task
agents = [
Agent("planner", {"planning": 0.92, "coding": 0.55}, cost=0.08, latency_ms=900),
Agent("coder", {"planning": 0.35, "coding": 0.96}, cost=0.12, latency_ms=1200),
]
task = Task(
"build-feature",
requirements=(
Requirement("planning", 0.4),
Requirement("coding", 0.6, depends_on=("planning",)),
),
value=1.0,
budget=0.30,
deadline_ms=4000,
progress=0.35,
)
router = SAGERouter(agents, incumbent_id="planner")
trace = router.route_with_trace(task)
decision = trace.selected
print(decision.mode, decision.assignments, decision.topology)
print(trace.excluded_agents)
# Feed back the strongest available evidence after execution.
router.record_outcome(
decision,
ExecutionOutcome(
success=0.9,
requirement_scores={"planning": 0.95, "coding": 0.86},
actual_cost=0.19,
actual_latency_ms=1450,
),
)
# Persist learned evidence after validated outcomes.
snapshot = router.export_state()
Task 에 들어간 progress=0.35 가 Sprix SAGE Router의 성격을 잘 보여 주는 인자입니다. 작업이 이미 35% 진행된 상태라는 정보가 라우팅 판단에 직접 들어가고, depends_on 으로 선언된 의존 관계는 요구사항 DAG가 되어 임계 경로 지연을 추정하는 데 쓰입니다. 실행이 끝난 뒤 record_outcome 으로 결과를 되돌려 주면 학습 상태가 갱신되고, export_state 로 그 상태를 파일에 남길 수 있습니다.
A2A 쪽 연동은 저장소의 sprix_a2a.py가 담당합니다. Agent Card의 skills 는 정규화된 능력 벡터로, 보안 요구사항은 권한 자격 필터로, 제공자 견적은 비용과 지연과 확신도를 담은 입찰로 바뀝니다. 이때 선언된 기능 ID를 로컬에 축적된 실행 증거와 대조해 검증한 뒤 실행 계획을 만듭니다.
Sprix SAGE Router의 합성 벤치마크 결과
benchmark.py 는 5개의 결정론적 시드에서 2,500개 작업을 외부 시뮬레이터로 돌립니다. 이 시뮬레이터의 숨은 능력치, 짝 효과, 비선형 품질, 실현 비용과 지연은 SAGE의 예측 모델과 의도적으로 다르게 설정되어 있어서, 라우터가 자기 점수로 자기를 채점하지 못하게 되어 있습니다. Sprix AI가 공개한 시드 간 평균과 모표준편차는 다음과 같습니다:
| 전략 | 품질 | 공통 효용 | 비용 / 예산 | 마감 초과 |
|---|---|---|---|---|
| Incumbent only | 0.507 ± 0.003 | 0.389 ± 0.002 | 0.239 ± 0.005 | 26.4% |
| Advertised-skill solo | 0.558 ± 0.005 | 0.435 ± 0.005 | 0.292 ± 0.004 | 11.9% |
| Feasible solo oracle | 0.553 ± 0.005 | 0.440 ± 0.005 | 0.271 ± 0.005 | 0.0% |
| Static SAGE | 0.584 ± 0.007 | 0.462 ± 0.007 | 0.315 ± 0.005 | 0.0% |
| Online SAGE | 0.631 ± 0.006 | 0.487 ± 0.006 | 0.422 ± 0.008 | 0.4% |
기존 담당 에이전트만 계속 쓰는 Incumbent only 전략은 마감을 26.4% 놓쳤고, 선언된 기능만 보고 단독 실행자를 고르는 Advertised-skill solo는 11.9%였습니다. 제약을 함께 보는 Static SAGE부터 마감 초과가 사라집니다. 학습을 켠 Online SAGE는 품질이 0.631로 가장 높지만 예산 대비 비용도 0.422로 가장 크며, 프로젝트는 이 트레이드 오프(Trade-off)를 능력 점수 하나로 덮지 않고 그대로 드러내 두었습니다. 경로 선택 분포는 HANDOFF가 51%, COLLABORATE가 35%, SELF가 14%로 나타났습니다.
수치를 그대로 옮기면서 함께 옮겨야 하는 것이 저자들이 붙인 단서입니다. 저자들은 이 결과를 학습과 제약 처리를 시험한 합성 증거일 뿐이라고 설명하면서, 실제 환경에서의 우위를 보여주는 근거는 아니라고 *"They are still not evidence of real-world superiority"*라고 적고 있습니다. 발표 가능한 평가에는 실제 실행에 대한 신뢰 구간, 학습된 라우팅 베이스라인, 이질적인 에이전트 벤치마크, 마켓플레이스 추적 재생, 보정 분석, 적대적 조건이 필요하다는 것이 저자들의 판단입니다.
기존 라우팅 연구와 다른 점
LLM 라우팅이라는 말은 보통 모델을 고르는 문제를 가리킵니다. RouteLLM ( [GN⁺] RouteLLM - LLM 라우터 서빙 및 평가를 위한 프레임워크)은 선호 데이터로 비용과 품질을 저울질해 어느 모델에 질의를 보낼지 학습하고, 코딩 작업의 실행 피드백으로 라우팅 정책을 갱신하는 연구도 있습니다 ( Agent-as-a-Router: 실행 피드백으로 진화하는 코딩 작업용 LLM 라우팅에 대한 연구). SAGE가 고르는 대상은 모델이 아니라 실행자 구성입니다. 몇 명이 붙을지, 각 요구사항을 누가 맡을지, 소유권을 넘길지가 한 번에 결정됩니다.
프로젝트가 연구 기반으로 밝힌 목록에도 그 계보가 드러납니다. 작업별로 팀을 동적으로 고르는 DyLAN, 에이전트 시스템을 최적화 가능한 계산 그래프로 보는 GPTSwarm, 워크플로우 탐색을 자동화하는 AFlow, 협업 방식과 역할과 모델을 함께 라우팅하는 MasRouter가 인용되어 있습니다. 이 중 다수가 작업을 시작하기 전에 구조를 정하는 반면, SAGE는 실행이 이미 진행된 시점의 재계획을 정면으로 다룹니다.
Sprix SAGE Router는 누구에게 맞는가
에이전트 마켓플레이스나 다중 에이전트 오케스트레이터를 직접 만들고 있고, 실행 중 재배정 규칙을 손으로 쓴 조건문으로 관리하다 한계에 부딪혔다면 참고할 값어치가 큽니다. 런타임 의존성이 없는 두 개의 Python 파일이 본체이므로 통째로 쓰지 않고 목적 함수 설계와 감사 추적 구조만 읽어도 얻는 것이 있습니다. 요구사항별 신뢰도와 하드 필터 탈락 사유를 남기는 방식은 사람이 개입해 승인하는 게이트를 붙일 때 그대로 쓰입니다.
반대로 지금 당장 프로덕션 A2A 네트워크에 붙여 운영할 라우터를 찾는 팀에게는 Sprix SAGE Router가 아직 적절한 선택지가 아닙니다. 프로젝트가 밝힌 로드맵에 실제 A2A 어댑터, 서명된 Agent Card 수용, 분산 라우터 서비스와 관측이 모두 미완료 항목으로 남아 있고, 벤치마크도 합성 시뮬레이터 결과뿐입니다. 저자들 스스로 프로덕션 배포에는 보정된 평가자, 인증된 신원, 개인정보와 보안 검토, 이벤트 기반 복구, 모니터링이 선행되어야 한다고 적어 두었습니다. 현재 Sprix SAGE Router는 초기 연구 프리뷰 상태이므로 이를 감안해 살펴보시기 바랍니다.
Sprix SAGE Router의 라이선스
Sprix SAGE Router는 MIT 라이선스로 공개되어 있어 개인 및 상업적 목적으로 자유롭게 사용할 수 있습니다.
Sprix SAGE Router 프로젝트 GitHub 저장소
더 읽어보기
이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다. 
이 도구를 직접 설치해 사용해보셨다면, 파이토치 한국 사용자 모임
회원들을 위해 경험이나 팁을 댓글로 남겨주세요! 