탈루스 v2: 에이전트 실행에 신뢰를 심다

Key Takeaways

• Talus v2는 에이전트의 권한, 예산, 검증, 스케줄링을 단일 온체인 실행 모델(Execution Model)로 통합한다. 무거운 연산과 외부 데이터 수집은 오프체인에 남겨두되, 툴 권한, 실행 증명, 예산 결제 및 환불 기록은 온체인에 저장하여 누가 어떤 권한으로 무엇을 실행했고 얼마를 지불했는지 명확히 추적하고 정산한다.
• 예산은 실행 전에 확정되는 구조로, 각 정점(Vertex)의 비용을 먼저 잠근(Lock) 뒤 검증을 통과한 결과에 대해서만 정산하며, 시작 시점의 가격 스냅샷과 미사용 예산 환불 정책으로 실행 중 가격 변동 및 작업 실패 리스크를 통제한다. 검증은 기본 기록, 등록 서명 키, 외부 무브(Move) 컨트랙트(ZK Proof 포함)의 세 가지 경로로 제공되어 정점마다 다른 수준의 신뢰성을 적용할 수 있다.
• v2 메인넷은 리더 보증금, 툴 본드, 우선순위 수수료를 $US 토큰으로 단일화하여 실행 기록과 토큰 이코노미를 동일 정산 레이어로 일치시킴으로써 탈루스의 가치는 에이전트 수나 일회성 데모가 아닌, 동일 업무가 반복적으로 유료 호출과 정산을 창출하는 구조에서 증명된다.

인공지능(AI) 에이전트가 단순한 답변을 생성할 때는 답이 틀리거나 사용자 의도를 반영하지 못하면 버리고 다시 질의할 수 있다. 그러나 에이전트가 외부 응용 프로그램 인터페이스(API)를 호출하거나 자산을 이전하고 다른 에이전트에게 업무를 위임하는 순간, 사소한 오류도 곧바로 수수료 발생이나 자산 손실로 이어질 수 있다. 에이전트의 행동 범위가 넓어질수록 누가 어떤 권한으로 무엇을 실행했고, 그 결과 얼마가 지급됐는지를 검증할 인프라가 필요해진다. 결국 에이전트는 누군가 실제 업무를 위임할 때에만 가치를 만들며, 위임에는 신뢰가 필요하다. 신뢰할 수 있는 에이전트일수록 더 많은 일을 맡길 수 있다.

탈루스 v2는 권한과 예산, 검증, 일정을 하나의 실행 모델(Execution Model)에 결합해 이 문제를 다룬다. 무거운 연산과 외부 데이터 수집은 오프체인(offchain)에 남겨두되, 실행 틀(harness)과 도구 권한, 결과 증거, 예산 지급, 자산 처리, 반환 기록은 온체인(onchain)에 저장한다. 이를 통해 프로토콜은 여러 도구를 거치는 하나의 실행을 추적하고 정산할 수 있다.

이 글에서는 먼저 권한이 실행 틀에 어떻게 담기는지 살펴본다. 이어서 예산이 실행 전에 고정된 뒤 어떤 생애주기를 거치는지, 체인이 어떤 검증 경로를 통해 오프체인 결과를 수용하는지 차례로 따라간다.

1. 탈루스 v2: 권한과 예산을 담는 실행 틀

탈루스 프로토콜(Talus Protocol)은 하나의 작업을 여러 정점(vertex)으로 나누고 앞선 결과에 따라 다음 도구를 호출하는 방향성 비순환 그래프(DAG) 기반 작업 흐름 엔진(workflow engine)이다. 각 정점은 오프체인 HTTP 서비스나 온체인 무브(Move) 모듈로 구현된 도구이며, 실행할 때마다 상호 배타적인 여러 출력 변형(output variant) 중 하나로 끝난다. 예를 들어 시장 가격을 확인하고 조건이 맞으면 매수 주문을 제출하는 작업은 가격 조회, 조건 평가, 주문 제출이라는 세 정점으로 나눌 수 있다. 가격 조회 도구의 각 실행은 성공 또는 오류 변형 중 하나로 끝난다.

출력 변형은 다음 분기를 결정한다. 필요하면 실행 경로(Walk)를 여러 갈래로 나눠 병렬로 진행하거나, 사전에 정한 규칙에 따라 일부 구간을 반복할 수 있다. 블록체인은 그래프의 상태 전이를 기록하는 조정 계층(coordination layer)이며, 실행 조정자(Leader)는 온체인 이벤트를 구독하고 필요한 도구를 호출해 연산을 수행한다.

프로토콜 v2는 v1에서 도입한 도구 등록부(Tool Registry)와 담보 예치, 서명형 HTTP(Signed HTTP), 예약 실행을 토대로 한다. 여기에 호출자와 허용 도구, 자금 출처, 검증 방식을 각 정점에 직접 연결한다. 그 결과 단순한 호출 순서였던 그래프가 자체 권한과 비용을 지닌 실행 단위로 바뀐다.

따라서 같은 작업 흐름을 따르는 두 작업이라도 온체인 상태가 각기 다르게 입력되면 실행 경로와 결과가 달라질 수 있다. 오프체인 인공지능 모델이나 지갑 접근 권한을 신뢰하는 대신, 온체인 코드가 모든 자산 작업을 통제한다. 외부 개발자는 지난 7월 수이(Sui) 테스트넷에 공개된 v2 프리뷰를 통해 이 구조를 시험할 수 있다.

이 글은 v2.0.0 메인넷 릴리스를 기준으로 한다. 규격은 계속 개발 중이며, 이후 버전에서 일부 세부 사항이 달라질 수 있다.

v2가 말하는 에이전트의 의미를 이해하려면 온체인에 기록되는 구조부터 살펴봐야 한다.

v2에서 에이전트는 하나 이상의 스킬(skill)을 지닌 온체인 주체다. 이 에이전트는 탈루스 프로토콜 스마트 계약이 스킬별 행동 한계를 적용하는 온체인 객체다. 각 스킬은 어떤 작업 흐름을 어떤 도구와 조건으로 실행할지 정의한다. 에이전트 등록부(Agent Registry)는 각 기능 레코드(capability record)의 활성 상태와 연결 그래프, 필수 도구, 인터페이스 개정판, 예약 작업 수를 관리한다. 인터페이스 개정판은 규격이 갱신될 때 변경된다.

검증자(Verifier)는 도구가 제출한 결과를 사전에 정한 조건에 따라 평가한다. 각 도구의 검증자 설정은 내장 등록 키 방식과 외부 무브 계약 중 어느 방식을 쓰는지, 호출 대상과 필수 공유 객체, 성공 및 오류 결과에 지원하는 제출 유형과 함께 도구 등록부에 기록된다. 등록된 서명 키는 네트워크 인증 등록부에서 관리한다. 이를 통해 시스템은 적절한 검증 로직을 찾을 수 있다.

권한 관리는 에이전트 기능이 도구 등록부의 식별자와 이름을 고정 도구(fixed tools)로 선언하는 데서 시작한다. 시스템은 기능을 등록할 때 이 목록을 도구 등록부와 대조한다. 실행 시점에는 권한 객체(permission object)가 기능 식별자와 인터페이스 개정판, 그래프, 현재 정점을 하나로 묶는다. 이로써 승인 범위가 한 번의 실행이나 특정 예약 작업으로 제한된다.

에이전트가 여러 기능을 보유해도 해당 실행에는 허용된 도구 집합만 적용된다. 예약 작업이 포괄적이고 장기적인 권한을 공유하는 일도 없다. 대신 작업 식별자에 연결된 승인이 매 회차 생성되는 실행 객체에 복사된다.

실행이 시작되면 실행 객체에는 선택된 그래프와 호출자, 에이전트 기능 및 개정판, 예약 작업, 회차가 기록된다. 실행 경로와 정점별 평가, 각 실행 경로의 마지막 상태인 성공&실패&합류&중단&취소가 하나의 실행 식별자 아래 쌓인다. 이를 통해 특정 기능 개정판이 만든 결과를 추적할 수 있다.

프로토콜 상태는 모든 루트 객체(root object)에서 버전으로 관리되며, 각 실행은 생성 시점에 포착한 불변 패키지 구성(immutable package configuration)을 고정한다. 따라서 프로토콜은 가동 중인 에이전트를 깨뜨리지 않고 업그레이드할 수 있고, 기존 도구와 에이전트 레코드는 새 패키지 버전으로 이전된다. 물론 프로토콜이 갱신된 뒤에도 과거 실행의 권한과 결과를 재구성할 수 있어야 하므로, 등록부의 기능 개정판은 실행 시점에 포착한 참조와 온체인에서 연결돼야 한다.

2. 실행 전에 예산을 고정하여 비용 통제를 구현한다

이 절에서는 프로토콜이 비용을 다루는 방식을 살펴보겠다. 간략하게 이야기하면, 예산을 실행 전에 고정하고 각 단계의 지출을 기록하는 구조다.

에이전트 기능은 사용할 도구와 함께 자금 조달 및 일정 정책을 선언한다. 실행 비용은 사용자나 에이전트가 부담할 수 있다. 자체 조달형(self-funded)에서는 에이전트가 사전에 충전한 전용 계정인 금고(Vault)를 지급원으로 지정하고 기능별 최대 예산을 설정한다.

비용 처리는 두 단계로 이뤄진다. 시스템은 먼저 실행할 정점의 예산을 잠그고, 결과가 확정된 뒤 도구에 비용을 지급한다. 각 정점 뒤의 도구에는 캐셔(cashier)가 있으며, 캐셔는 필수 고정 SUI 가격과 선택형 유한 크레딧(finite credit) 및 시간 패스(time pass) 상품을 관리한다. 고정 가격이 0이면 공개 접근을 뜻한다. 도구는 에이전트나 사용자에게 크레딧 또는 패스를 할당할 수 있다. 실행이 시작되면 프로토콜은 도구가 지원하는 수단 가운데 비용이 가장 낮은 방식을 선택하고, 호출 비용을 잠근 뒤에만 실행한다. 각 실행에는 작업 준비금에서 넘어온 예산을 보관하는 온체인 실행 지급 객체(execution payment)가 있다. 고정 SUI 가격이 선택되면 이 지급 객체가 자금 출처가 된다.

스냅샷 가격(snapshot price)은 실행 도중 도구가 가격을 바꿔도 그대로 적용된다. 실행 시작 뒤 가격이 달라지는 위험을 막는 장치다. 유한 크레딧과 시간 패스는 도구 소유자가 에이전트와 사용자에게 판매하거나 부여할 수 있는 선불 이용권이다. 시간 패스에는 만료 시점이 있고 유한 크레딧에는 사용 횟수 제한이 있으며, 둘 중 어느 수단을 사용해도 실행 예산을 차감하지 않고 정점을 정산한다.

가격 조회 뒤 모델 호출이 실패하거나 거래가 만료되면, 시스템은 이미 발생한 비용만 정산하고 사용하지 않은 잠금 예산은 해제한다. 따라서 회계 기록에는 실패가 발생한 정점이 그대로 반영된다.

반복 실행은 작업(Task), 일정(Schedule), 실행 회차(Occurrence)의 세 계층으로 관리된다. 일회성 작업은 대기열에 들어가고, 반복 작업은 시작 시점과 반복 간격이 정해진 주기 정책에 따라 다음 회차를 만든다. 예약 작업에는 회차별 예산과 남은 준비금이 기록된다. 작업에는 $US로 표시한 우선 수수료(priority fee)를 붙일 수도 있으며, 이 경우 해당 회차는 실행 조정자 배정에서 우선권을 얻는다. 실행 조정자는 이후 우선 수수료 금고에서 자신의 $US 몫을 인출한다.

회차가 시작되면 준비금 일부가 실행 예산으로 전환된다. 완료 뒤에는 금액이 정산되거나 반환되고, 남은 잔액은 다음 회차로 이월된다. 준비금 객체는 각 회차의 이력을 보관해 같은 예산이 두 번 배정되는 일을 막는다. 운영자는 준비금을 보충하거나 남은 일정을 취소할 수 있어 장기 작업의 예산을 회차 단위로 통제할 수 있다.

탈루스는 결과 전달과 대금 지급도 분리한다. 도구가 결과를 제출해도 검증이 끝난 뒤에야 정산 또는 만료 처리가 이뤄진다. 실행 지급 객체는 정점별 최대 잠금 예산과 실제 지출, 반환 내역을 기록한다. 실행이 끝난 뒤에도 누구나 어떤 도구가 얼마를 썼고 얼마가 돌아왔는지 추적할 수 있다.

3. 검증 경로로 온체인 상태와 오프체인 연산을 연결한다

블록체인은 오프체인에서 만들어진 결과를 받아들일지 어떻게 결정할까? 체인이 직접 연산하는 것은 아니다. 체인은 실행 순서와 권한, 비용 상태를 동기화하는 조정 계층으로 남는다. 따라서 신뢰는 오프체인 결과가 어떤 경로로 제출되고 어떤 증거가 붙는지에 달려 있다.

앞서 살펴본 실행 조정자는 온체인과 오프체인 구성 요소를 잇는 조정자다. 온체인 이벤트를 감지하고 다음 정점을 배정하며, 지정된 도구를 호출한 뒤 결과를 체인에 다시 제출한다. 최신 버전에서 실행 조정자는 온체인에 등록하고 $US 토큰을 예치해야 하며, 프로토콜은 위반 시 이 예치금을 삭감할 수 있다. 각 실행 요청에는 주 실행 조정자와 예비 실행 조정자가 지정돼, 주 조정자가 응답하지 않으면 예비 조정자가 이어받는다.

오프체인 결과를 체인에 제출하는 경로는 세 가지다:

• 제출된 결과를 그대로 기록하는 기본 경로다.
• 사전에 등록한 서명 키로 요청과 응답을 서명해 제출하는 경로다.
• 무브 계약이 사전에 정한 조건을 검사하는 외부 검증 경로다.

서명 경로는 제출된 출력이 정당한 입력을 바탕으로 등록된 도구에서 계산됐다는 무결성을 증명한다. 외부 검증 계약은 보조 데이터와 온체인 상태를 대조해 출력을 검사한다. 이 방식은 계산된 영지식 증명(zero-knowledge proof)을 온체인 커밋먼트(onchain commitment)와 대조해 도구를 검증할 수 있으며, 사용자가 지정한 다른 제약 조건으로도 도구 출력의 정확성을 보호할 수 있다. 검증자 설정은 수락 또는 거절 결과와 그 판단 이유를 요약한 해시를 반환한다. 따라서 같은 그래프 안에서도 정점마다 서로 다른 수준의 검증을 적용할 수 있다.

검증자가 결과를 수락하면 다음 정점이 그 데이터를 전달받는다. 결과가 거절되거나 만료되면 시스템은 실패를 처리하고 사용하지 않은 예산을 반환한다. 검증 판정이 정산을 직접 통제하는 구조다.

판정과 정산은 모두 수이 트랜잭션으로 기록된다. 거래 해시와 실행 식별자가 있으면 제3자도 특정 실행의 어느 정점에서 어떤 결과가 나왔는지 확인할 수 있다.

4. 탈루스/acc가 증명한 것들

Source: Talus

탈루스는 수이 재단(Sui Foundation), 시카다 캐피털(Cicada Capital)과 함께 탈루스/acc 첫 기수를 4주간 운영하고 7월 수상팀을 발표했다. 이 프로그램은 온체인 인공지능 에이전트 프레임워크와 실행 중심 활용 사례를 결합한 팀을 지원했다. 실물자산(RWA), 인공지능, 디파이(DeFi), 게임 분야에서 전 세계 50개가 넘는 팀이 지원했고 7개 팀이 데모 데이(Demo Day)에 진출했다. 상위 세 팀은 다음과 같다:

• 1위 슈퍼스테이크(SuperStake, @superstakefun): 인공지능 에이전트가 실시간으로 게임을 자율 생성하고 플레이하는 에이전트 게임 엔진(Agentic Game Engine)이다. 인간 관객은 경기를 지켜보며 결과를 예측하거나 베팅한다.
• 2위 아가마(Agama, @agamafinance): 실물자산 토큰용 수익 인프라 계층이다. 인수 심사를 거친 신용 금고와 합성 달러를 제공해 사모 신용 시장과 디파이 수요를 연결한다.
• 3위 누들스 파이낸스(Noodles Finance, @NoodlesFi): 시장 조회와 포지션 진입, 수익률 추적 기능을 제공하는 수이 생태계용 디파이 애플리케이션이다.

이 프로젝트들은 가격 조회와 의사결정, 자산 배치, 게임 상태 변경으로 이어지는 일련의 행동을 탈루스가 통제할 수 있는지 확인하는 첫 시험대다. 다만 이 코호트는 v2가 아닌 v1을 사용했으므로, 이 프로젝트들이 v2의 권한 및 예산 체계로 완전히 이전해 의미 있는 메인넷 사용량을 만들어내는지는 지켜봐야 하지만, v2로 향하는 생태계 이전은 지금 진행중에 있다.

5. 결국 반복 실행이 탈루스의 가치를 결정한다

탈루스 v2는 에이전트의 권한과 예산, 검증, 일정을 하나의 온체인 상태와 모델에 결합한다. 허용된 행동은 실행 전에 고정된다. 예산 잠금과 정산은 지출을 제한하고, 증거와 검증 판정은 결과를 수용한 근거를 기록한다.

v2 메인넷 릴리스는 실행 조정자 예치금과 도구 담보, 우선 수수료를 탈루스의 $US 토큰으로 표시하고, 모든 실행 요청이 스케줄러라는 단일 진입점을 거치게 한다.

실행 그래프는 프로토콜의 구조를 정하고, $US 토큰은 예치와 우선 수수료를 정한다. 이로써 탈루스의 실행 기록과 토큰 경제가 같은 정산 계층에 놓인다. 이는 프로토콜의 궤적을 압축해 보여준다. v1은 모델이 작동한다는 점을 증명했고, v2는 이를 프로덕션급 인프라로 만들며, 예치금과 담보, 수수료가 하나의 토큰으로 수렴하는 구조는 다음 단계인 탈중앙 경제 엔진의 토대가 된다.

남은 질문은 이 구조가 데모를 넘어 반복 실행으로 스스로를 증명할 수 있느냐다. 에이전트를 만드는 비용이 낮아질수록 등록된 에이전트 수나 시제품 수는 실제 인프라 사용을 보여주는 약한 지표가 된다. 더 중요한 지표는 같은 작업이 여러 회차에 걸쳐 유료 호출과 검증 판정, 정산을 얼마나 자주 만들어내는지다. 실제 비용을 내는 에이전트와 수익을 받는 도구가 같은 작업 안에서 얼마나 자주 상호작용하는지도 중요하다.

정점별 성공률과 반환률, 외부 검증 계약을 거친 실행 비중, 독립 실행 조정자의 수와 예치금 분포를 함께 보면 단순 등록과 실제 사용을 가려낼 수 있다.

인프라는 같은 작업이 일회성 데모로 끝나지 않고 매일 안정적으로 실행될 때 가치를 증명한다. 반복 회차가 얼마나 오래 이어지는지, 유료 정점이 얼마나 자주 실행되는지, 운영자가 준비금을 계속 보충하는지가 핵심 지표다.

메인넷 v2는 현재 가동 중이며 규격은 앞으로도 계속 발전할 것이다. 탈루스는 이제 프로덕션 사용으로 설계를 검증해야 하는 단계에 들어섰다. 이 실행 틀에서 반복되는 실행의 규모와 지속 기간이 탈루스를 중심으로 온체인 인공지능 에이전트 생태계가 형성될 수 있는지를 보여줄 것이다.