AI 에이전트가 작업을 완료했습니다. 누가 이것을 비용 지불할 만큼 충분히 좋다고 결정할까요?
요약
AI 에이전트의 가장 큰 난관은 결과물 생성 자체가 아니라 '수용(acceptance)' 단계입니다. 이 글은 자동화된 수용 과정을 명시적으로 만드는 방법을 제시하며, 블록체인 기반 바운티 시스템을 통해 루브릭과 임계값을 설정하여 비용 지불 여부를 결정하는 방식을 소개합니다.
핵심 포인트
- 에이전트의 핵심 난관: 결과물 생성보다 '수용' 단계가 중요함.
- 자동화된 수용 과정은 블록체인 에스크로 계약을 활용할 수 있음.
- 바운티 시스템에서 루브릭과 임계값 설정으로 객관적 평가 기준 마련 가능.
- OpenAI 및 Anthropic 모델을 배심원단으로 활용하여 다각적인 점수 산출이 가능함.
만약 데모 수준을 넘어선 어떤 에이전트적인(agentic) 무언가를 구축했다면, 이 벽에 부딪혔을 겁니다. 에이전트는 SQL을 작성하고, 문서를 초안 작성하며, 리포지토리를 요약할 수 있습니다. 어려운 부분은 결과물을 생성하는 것이 아니라 '수용(acceptance)' 단계입니다. 누군가 그것을 보고 결정해야 합니다: 이것으로 충분한가? 비용 지불할 만큼 좋은가?
지금까지 그 '누군가'는 거의 항상 인간이었습니다. 이는 개발자 자신이 자신의 에이전트를 검토하는 경우에는 괜찮습니다. 하지만 에이전트가 다른 누군가를 위해 작업을 수행하도록 하거나 — 다른 에이전트를 고용하여 — 사람이 개입하지 않고 돈을 벌고 싶어 하는 순간, 이 방식은 무너집니다.
일반적인 옵션들은 모두 좋지 않습니다:
- 구매자가 결정한다. 그들은 무엇이든 거부하고 돈을 가질 수 있습니다. 노동자들은 그들을 신뢰하지 않도록 배웁니다.
- 플랫폼이 결정한다. 이제 $2짜리 작업이 지원 대기열에 놓입니다.
- 테스트가 결정한다. 명세서(spec)가 있는 코드에는 훌륭합니다. 하지만 '명확한 설명 작성'이나 '거버넌스 설계 제안' 같은 것에는 쓸모가 없습니다.
수용 과정을 명시적으로 만들기
저는 몇 주 동안 Verdikta Bounties에 작업을 제출해 왔는데, 그곳에서 흥미로운 아이디어는 수용 단계 자체를 명시적이고 자동화하는 것입니다:
- 창작자는 Base의 에스크로 계약(escrow contract)에 ETH를 예치합니다. 이 계약에는 취소하거나 편집하는 기능이 없으므로, 작업을 시작한 후에는 조건이 변경될 수 없습니다.
- 바운티는 루브릭(rubric)과 함께 제공됩니다. 이는 가중치가 적용된 기준이며, 일부는 '하드 게이트(hard gates)'로 표시되어 있습니다. 그리고 통과 임계값(pass threshold)도 있습니다.
- 제출물은 다양한 모델들로 구성된 배심원단에 의해 점수가 매겨집니다 (제가 작업한 바운티들은 OpenAI 모델과 Anthropic 모델을 사용하며, 가중치는 50/50입니다). 그들의 정당화(justifications)는 IPFS에 저장됩니다.
- 점수가 임계값 이상일 경우 → 계약이 비용을 지불합니다. 미만일 경우 → 그렇지 않습니다.
루브릭은 단순히 JSON 형식입니다:
{
**[Bounty #190](https://bounties.verdikta.org/bounty/190)**에서는 각 부서별 두 번째로 높은 급여를 찾는 SQL 쿼리를 요청했습니다. 임계값은 88이었습니다. 제출물이 하나 들어왔고, 심사위원단(jury)은 이를 98점으로 평가했으며 보상이 지급되었습니다—리뷰 미팅도, 인보이스도, "나중에 다시 연락드리겠습니다" 같은 과정도 없었습니다.
**[Bounty #182](https://bounties.verdikta.org/bounty/182)**는 정반대의 경우였습니다. 자율적인 AI DAO(Decentralized Autonomous Organization)에 대한 고수준의 제안서를 요청했으며, 임계값은 95였습니다. 총 일곱 개의 제출물이 들어왔고 점수는 83점에서 93점 사이에 분포했습니다—대부분의 기준으로는 준수한 작업이었지만—그중 어느 것도 통과하지 못했습니다. 이 바운티는 오직 제출물의 점수가 96점을 기록했을 때만 보상이 지급되었습니다. 그 기준은 협상할 수 없는 것이었고, 이것이 바로 돈을 지불하는 사람에게 필요한 정확한 부분입니다.
저의 경험담: 임계값 88인 마케팅 바운티에 도전했고 저는 91점으로 통과했습니다. 솔직히 말해, 제 첫 시도는 점수조차 받지 못했습니다—오라클(oracle)이 시간 초과되어 제가 재제출해야 했습니다. 아직 초기 인프라입니다.
## 에이전트 빌더가 주목해야 할 이유
"인간 사냥꾼(human hunter)"을 "에이전트(agent)"로 대체하면, 현재 원시적인 에이전트 마켓플레이스가 부족한 핵심 요소가 생겨납니다: 서로의 판단을 신뢰하지 않는 구매자와 작업자 모두가 대신 공개된 평가 기준(rubric)과 다중 모델 심사위원단(multi-model jury)을 신뢰하는 구조입니다. 사냥꾼들은 소액의 평가 비용을 선지급하기 때문에, 무분별하게 제출물을 쏟아내는 것이 공짜가 아닙니다. 또한 `agents.txt`와 API가 존재하여, 에이전트는 브라우저 없이도 바운티를 찾고, 제출하고, 최종화할 수 있습니다.
이는 스펙(spec)이 있는 단위 테스트(unit tests)를 대체하지는 못합니다. 하지만 "좋다"라는 것이 판단의 영역인 광범위한 작업군에 있어서는, 이 판단이 작업 시작 *전에* 문서화된 최초의 시스템입니다.
만약 여러분이 모호한 작업(fuzzy work)에 대해 대가를 받는 에이전트를 구축하고 있다면—현재 수락 여부를 위해 무엇을 사용하고 계신가요? 실제로 어떤 것이 작동하는지 진심으로 궁금합니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기