[ AI Agent 시대에 진짜 필요한 것은 똑똑한 Agent 다음이다 ]
@termix_ai x @KaitoAI
한동안 쉬었더니 3만점 미달..
요즘 AI Agent 프로젝트를 보면 대부분 비슷한 이야기를 합니다.
“우리 Agent는 코딩을 할 수 있습니다.”
“데이터를 분석할 수 있습니다.”
“리서치도 할 수 있습니다.”
“다른 서비스를 호출할 수도 있습니다.”
그런데 여기서 한 단계 더 들어가 보면 이상한 질문이 생깁니다.
그래서 Agent가 실제로 다른 Agent에게 일을 맡기고 돈을 지불할 수 있는가?
그리고 더 중요한 질문.
그 Agent가 일을 제대로 했다는 것을 누가 증명하는가?
저는 @termix_ai 를 볼 때 이 지점이 상당히 흥미롭습니다.
TermiX가 만들고 있는 것은 단순한 Agent 디렉토리가 아니라,
Agent → Job → Quote → Execution → Verification → Settlement
라는 경제적 거래 구조입니다.
즉, Agent가 단순히 “무언가를 할 수 있는 프로그램”에서 끝나는 것이 아니라,
서비스를 제공하고 돈을 벌 수 있는 경제적 주체
가 되는 구조에 가깝습니다.
- Agent에게 ‘직업’이 생긴다
기존 AI Agent의 문제는 능력이 있어도 그 능력을 거래할 시장이 부족하다는 것입니다.
예를 들어,
A Agent가 특정 스마트컨트랙트의 보안 감사를 필요로 한다고 생각해보겠습니다.
A Agent가 직접 모든 작업을 수행할 필요는 없습니다.
TermiX에서는 필요한 작업을 Job으로 만들고,
B Agent는
“내가 이 작업을 수행하겠습니다.”
라고 Quote를 제출할 수 있습니다.
그리고 조건이 맞으면 거래가 성립합니다.
이렇게 되면 Agent의 역할은 완전히 달라집니다.
기존에는
AI 모델 → 결과물
이었다면,
Agent 경제에서는
Agent → 서비스 → 가격 → 계약 → 결과물 → 평판 → 수익
이라는 구조가 만들어집니다.
현재 TermiX에서 제공되는 서비스 영역에도 Solidity 감사, 스마트컨트랙트 개발, 온체인 분석, 리서치, 데이터 라벨링, 기술 문서 작성, 리스크 분석, formal verification 등 상당히 다양한 작업이 포함되어 있습니다.
- 그런데 가장 어려운 문제는 ‘신뢰’다
Agent Marketplace가 커지려면 단순히 Agent를 많이 등록하는 것만으로는 부족합니다.
문제는 이것입니다.
“이 Agent가 정말 일을 제대로 했는가?”
사람이 사람에게 일을 맡길 때도 계약서, 중간 검수, 평판, 보증금 등이 필요합니다.
AI Agent끼리 거래한다면 이 문제가 더욱 커집니다.
왜냐하면 Agent는 24시간 자동으로 거래할 수 있기 때문입니다.
따라서 TermiX의 핵심은 Marketplace보다 오히려 Trust Layer에 있다고 볼 수 있습니다.
TermiX의 현재 구조에서는 Quote가 수락되면 대금이 온체인 Escrow에 들어가고, 작업 결과물의 hash가 기록됩니다.
그리고 일정 기간 동안 Challenge가 가능하며, 분쟁이 발생하면 평가 절차를 거쳐 최종 Settlement가 이루어지는 구조입니다.
즉,
“믿고 먼저 돈을 주세요.”
가 아니라
“조건을 먼저 고정하고, 돈을 잠그고, 결과를 검증한 뒤 정산합니다.”
라는 접근입니다.
- 여기서 AACP가 중요해진다
TermiX의 기술적 구조를 더 깊게 보면 AACP(Agent Autonomous Commerce Protocol)가 등장합니다.
AACP는 AI Agent가
작업을 등록하고
입찰하고
실행하고
결과를 평가하고
대금을 정산하는
전체 Commerce Lifecycle을 온체인 경제 구조와 연결하기 위한 프로토콜입니다.
특히 흥미로운 것은 여러 기술을 각각 다른 문제에 배치한다는 점입니다.
ERC-8004 → Agent Identity & Reputation
누가 작업을 수행했는지 식별하고 과거 활동과 평판을 연결합니다.
ERC-8183 → Commerce & Escrow
작업과 결제의 lifecycle을 관리합니다.
TEE → Confidential Execution
민감한 계산이나 데이터를 보호하는 실행 환경을 제공합니다.
zkVM → Verifiable Computation
특정 프로그램이 특정 입력값을 사용해 실제로 어떤 결과를 냈는지 암호학적으로 증명하는 방향입니다.
Staking & Slashing → Economic Accountability
Agent와 평가자가 일정 수준의 경제적 책임을 갖도록 만듭니다.
이걸 하나의 흐름으로 연결하면 상당히 재미있습니다.
Identity
↓
Job
↓
Escrow
↓
Execution
↓
Verification
↓
Challenge
↓
Settlement
↓
Reputation
↓
다음 Job
결국 Agent의 과거 행동이 다음 거래의 신뢰도에 영향을 주는 구조입니다.
- 특히 zkVM을 붙이는 이유
여기서 개인적으로 가장 흥미로운 부분은 zkVM입니다.
AI Agent가
“제가 계산했습니다.”
라고 말하는 것과
“제가 계산한 과정을 검증할 수 있는 증명이 있습니다.”
는 완전히 다른 이야기입니다.
AACP 문서에서는 객관적으로 검증 가능한 작업의 경우 verification program을 zkVM에서 실행하고 그 결과를 증명하는 구조를 설명합니다.
예를 들어 특정 데이터 처리 프로그램이 입력 X를 받아 결과 Y를 만들었다면,
Program + Input → Output
이라는 실행 결과 자체를 검증 대상으로 만들 수 있습니다.
이 구조가 중요한 이유는 Agent의 말을 그대로 믿을 필요를 줄일 수 있기 때문입니다.
물론 모든 AI 작업이 zkVM으로 쉽게 검증되는 것은 아닙니다.
코드 실행이나 특정 계산처럼 결과가 명확한 작업은 상대적으로 검증하기 쉽지만,
“이 글이 좋은가?”
“이 디자인이 더 나은가?”
“이 리서치가 충분히 정확한가?”
같은 작업은 훨씬 어렵습니다.
그래서 AACP 문서에서도 객관적 프로그램 검증과 rubric 기반 평가를 구분하고 있습니다.
이 차이가 굉장히 중요합니다.
AI Agent의 모든 작업을 하나의 검증 방식으로 해결하려는 것이 아니라, 작업의 성격에 따라 검증 방식을 다르게 가져가는 것.
이것이 Agent Commerce Infrastructure에서 중요한 설계 포인트라고 생각합니다.
- Reputation도 단순한 별점이 아니다
일반적인 플랫폼에서는
⭐⭐⭐⭐⭐
같은 별점이 평판의 대부분을 차지합니다.
하지만 Agent 경제에서는 이것만으로 부족합니다.
Agent가
몇 개의 작업을 수행했는지,
어떤 종류의 작업을 했는지,
얼마나 많은 금액을 정산했는지,
분쟁이 얼마나 발생했는지,
Challenge 결과는 어땠는지,
얼마나 오랫동안 활동했는지,
어떤 검증 수준의 작업을 통과했는지
등이 모두 중요해집니다.
TermiX는 .agent 형태의 온체인 Agent Identity를 제공하고, 해당 Identity에 작업 이력과 평판을 연결하는 구조를 사용합니다. Identity는 사용자의 지갑이 보유하는 형태로 설명되어 있습니다.
이것이 제대로 자리 잡는다면 앞으로는
“어떤 AI를 사용하세요?”
보다
“어떤 Agent Identity가 어떤 작업을 수행해 왔나요?”
라는 질문이 중요해질 수도 있습니다.
- 결국 Agent도 ‘경력’을 갖게 된다
이 부분이 TermiX를 바라볼 때 상당히 재미있는 포인트입니다.
사람에게는
이력서
→ 경력
→ 레퍼런스
→ 평판
→ 계약
이 있습니다.
Agent에게도 비슷한 구조가 만들어질 수 있습니다.
Agent ID
→ 수행한 Job
→ 검증된 Deliverable
→ Settlement 기록
→ Reputation
→ 새로운 Job 수주
즉 Agent의 능력이 단순히 모델의 benchmark score로 표현되는 것이 아니라,
실제 경제활동의 기록
으로 표현될 수 있다는 것입니다.
이것이 충분히 발전한다면 Agent는 단순한 소프트웨어 인스턴스가 아니라 하나의 경제적 행위자(Economic Actor)에 가까워질 수 있습니다.
- 더 중요한 변화는 ‘Agent가 Agent를 고용한다’는 것
사람이 AI를 사용하는 현재 구조에서는
Human → AI
가 기본입니다.
하지만 Agent Economy가 발전하면
Human → Agent A → Agent B → Agent C
같은 구조가 자연스럽게 등장할 수 있습니다.
예를 들어,
사용자가
“이번 주 DeFi 시장의 위험도를 분석해줘.”
라고 요청했다고 해봅시다.
상위 Agent가 모든 것을 직접 하지 않아도 됩니다.
① Research Agent
시장 데이터를 수집
↓
② On-chain Analytics Agent
지갑 및 거래 데이터를 분석
↓
③ Security Agent
프로토콜 위험을 분석
↓
④ Report Agent
최종 보고서 작성
이렇게 여러 Agent가 전문적인 역할을 나눠 수행할 수 있습니다.
그리고 각각의 작업이 독립적인 Job이 됩니다.
이것이 중요한 이유는 Agent가 다른 Agent의 능력을 API처럼 구매할 수 있게 되기 때문입니다.
- 그래서 Marketplace보다 ‘Agent-to-Agent Economy’가 핵심
TermiX를 단순히
“AI Agent를 사고파는 곳”
으로 이해하면 범위가 너무 좁습니다.
더 정확하게 보면
Agent가 필요한 능력을 외부 Agent에게 구매할 수 있는 경제 시스템
에 가깝습니다.
그리고 여기서 중요한 것은 자동화입니다.
사람이 매번
“이 Agent가 괜찮을까?”
“가격은 얼마지?”
“돈은 어떻게 보내지?”
“결과물이 마음에 안 들면?”
을 직접 처리하는 것이 아니라,
Identity + Reputation + Escrow + Verification + Arbitration을 프로토콜 레이어에서 처리하려는 것입니다.
- 하지만 해결해야 할 문제도 분명하다
이 구조가 흥미롭다고 해서 모든 문제가 해결된 것은 아닙니다.
오히려 Agent Economy가 커질수록 몇 가지 문제가 중요해집니다.
첫째, 평판 조작 문제
Agent가 서로 작업을 주고받으며 reputation을 인위적으로 올리는 Sybil 또는 collusion 문제가 발생할 수 있습니다.
둘째, 검증 비용
zkVM이나 TEE 기반 검증은 강력하지만 모든 작업에 적용하기에는 비용과 기술적 복잡성이 존재합니다.
셋째, 주관적인 결과물
글쓰기, 디자인, 전략 분석처럼 정답이 하나가 아닌 작업은 완전한 자동 검증이 어렵습니다.
넷째, Agent의 실제 능력과 기록의 차이
과거에 좋은 결과를 냈다고 해서 앞으로의 모든 작업을 잘한다는 보장은 없습니다.
다섯째, 경제적 공격
Staking, Slashing, evaluator incentive가 존재하면 이번에는 이를 공격하거나 악용하려는 새로운 게임이 등장할 수 있습니다.
따라서 Agent Economy의 핵심은 단순히
“AI + Blockchain”
이 아닙니다.
결국 중요한 것은
인센티브 설계 + 검증 + 평판 + 분쟁 해결
입니다.
- 제가 TermiX에서 가장 주목하는 부분
결국 AI Agent 시장의 경쟁이
“누가 더 똑똑한 모델을 가지고 있는가?”
에서
“누가 더 신뢰할 수 있는 경제 시스템을 만들 수 있는가?”
로 이동할 가능성이 있습니다.
모델의 성능은 계속 좋아질 것입니다.
하지만 Agent가 실제 경제활동을 시작하면 새로운 문제가 생깁니다.
누가 누구인지.
무슨 일을 하는지.
얼마를 받을지.
돈은 어디에 보관되는지.
결과는 어떻게 검증되는지.
문제가 생기면 누가 판단하는지.
그리고 그 결과가 다음 거래의 평판에 어떻게 반영되는지.
TermiX와 AACP가 접근하는 영역은 바로 이 부분입니다.
AI Agent에게 두뇌를 주는 것은 이미 많은 프로젝트가 하고 있습니다.
하지만
Agent에게 신원, 계약, 책임, 평판, 검증, 그리고 경제적 거래 능력을 부여하는 것
은 완전히 다른 문제입니다.
그래서 앞으로 Agent Economy가 커질수록 중요한 질문은
“AI가 무엇을 할 수 있는가?”
에서 끝나지 않고,
“AI가 다른 AI와 어떻게 신뢰 없이 거래할 수 있는가?”
가 될 것 같습니다.
그리고 TermiX는 바로 이 질문에 대해
Agent가 Agent를 고용하고, 결과를 검증하고, 온체인에서 정산하는 구조를 실험하고 있다는 점에서 지켜볼 가치가 있는 프로젝트라고 생각합니다.
![[ AI Agent 시대에 진짜 필요한 것은 똑똑한 Agent 다음이다 ] 대표 이미지](/api/thumb?u=https%3A%2F%2Fpbs.twimg.com%2Fmedia%2FHTehRXBbUAAo6m3.jpg&w=640&s=t1-QOnJ3uDrebx_L9IRK7AuV)