대부분의 AI 애플리케이션의 대화는 너무 일찍 멈춘다. 그것들은 "애플리케이션이 생성된" 순간에 멈춘다.

이는 첫 번째 물결에서는 합리적이었다. 1년 전, 한 줄의 프롬프트가 실행 가능한 인터페이스로 변하는 것을 보는 것 자체가 이미 모든 사람의 주목을 받는 일이었다. 오늘날, 구축자들은 자연어가 소프트웨어를 생성할 수 있다는 것을 이해하고 있다. 더 어려운 문제는: 생성된 애플리케이션 이후에 무슨 일이 일어날 것인가이다.

그것이 실제 사용자에게 실행될 수 있는가?
안전하게 작업을 수행할 수 있는가?
비용을 측정하고, 가치에 따라 요금을 청구하며, 증명서를 발급할 수 있는가?
구축자는 그로부터 수익을 얻을 수 있는가?
사용자는 무작정 믿고 있는 무작위 애플리케이션 목록 없이 그것을 발견할 수 있는가?

X-Agent에서는 우리가 반복적으로 돌아가는 바로 이 경계선이다: 생성하는 것은 필요하지만, 단순히 생성하는 것만으로는 에이전트 애플리케이션이 진정한 제품이 되지 않는다. 부족한 그 층은 "구축이 완료된 후" 발생하는 모든 것이다.

요약

다음 플랫폼 수준의 문제는 더 많은 AI 애플리케이션을 생성하는 것이 아니라, 이미 생성된 에이전트 애플리케이션을 실행 가능하고 배포 가능하며 수익을 창출할 수 있는 제품으로 변환하는 것이다. 구축 경로(Build Path)와 실행 경로(Runtime Path)는 두 가지 다른 시스템으로 간주되어야 한다. 전자는 애플리케이션을 생성하고, 후자는 실제 사용자가 그것을 조작하게 한다.

에이전트 애플리케이션의 지불은 실행 자체와 결합되어야 한다------예산, 측정, 확인, 정산, 증명서 및 분쟁 처리 경로를 포함한다. 에이전트 상점과 성장은 선별된 배포와 실제 사용 신호에서 시작해야 하며, 빈 시장 목록에서 시작해서는 안 된다.

구축 경로는 제품의 절반에 불과하다

구축 경로는 현재 대부분의 사람들이 인식하고 있는 부분이다. 창작자 → 스튜디오 → 하네스(실행 프레임워크) → 샌드박스 → 배포된 에이전트 애플리케이션. 창작자는 자신이 원하는 것을 설명하고, 시스템은 이 의도를 해석하여 애플리케이션을 생성하고, 샌드박스에서 미리 보기한 후 배포로 나아간다.

이것은 이미 매우 가치가 있다. 그것은 과거에 비엔지니어와 엔지니어의 구축 작업을 방해했던 것을 제거했다: 저장소 구조, 환경 구성, 미리 보기 루프, 배포 세부 사항 및 첫 번째 라운드의 애플리케이션 스캐폴딩 구축. 그러나 우리가 여기서 멈춘다면, 본질적으로 우리는 "더 나은 공급을 창출하는 방법"을 가진 것에 불과하다. 더 많은 구축자가 더 많은 애플리케이션을 생성하고, 더 많은 아이디어가 데모 단계에 도달하며, 더 많은 프로토타입이 공유되는 것은 "제품"이라는 질문에 대한 답변이 아니다. 생성된 애플리케이션은 여전히 사용자, 작업, 상태, 권한, 가격 책정, 신뢰 및 배포가 필요하다.

이것이 우리가 구축 경로와 실행 경로를 구분하는 이유이다.

실행 시, 애플리케이션이 진정으로 유용해지는 곳

실행 경로는 애플리케이션 배포가 완료된 후 시작된다. 사용자 → 에이전트 애플리케이션 → 에이전트 대화 → 도구/상태/지갑/지불 → 결과. 이 경로는 최종 사용자에게 서비스를 제공하며, 창작자에게는 제공되지 않는다. 배포된 에이전트 애플리케이션은 단순히 AI 레이블이 붙은 정적 페이지가 되어서는 안 된다. 사용자는 이 애플리케이션을 열고, 의도를 표현하고, 세부 사항을 질문하고, 작업 흐름을 촉발하고, 상태를 조회하고, 도구를 호출하며, 작업 결과를 얻어야 한다.

이 말은 명백하게 들리지만, 실제로 그것을 구축하기 시작할 때까지는 그렇지 않다.

구축 시의 에이전트와 실행 시의 에이전트는 두 가지 다른 작업이다. 구축 시 에이전트는 애플리케이션 생성 지원을 담당하고; 실행 시 에이전트는 사용자 애플리케이션 조작 지원을 담당한다. 이 두 역할을 같은 긴 프롬프트에 넣으면, 시스템은 추론하기 어렵고, 안전성을 보장하기 어렵고, 수익을 실현하기 어렵게 된다.

실행 시에는 사용자와 자신만의 "계약"을 구축해야 한다. 이 애플리케이션이 어떤 상태를 읽고 쓸 수 있는지 알아야 하며; 어떤 도구가 사용 가능한지 알아야 하며; 어떤 작업이 저렴하고 되돌릴 수 있는지, 어떤 작업이 비싸고 외부 시스템과 관련되거나 위험이 있는지 알아야 하며; 언제 확인을 요청해야 하는지 알아야 하며; 감사 추적을 남겨야 한다.

이것이 "모델이 답을 제시했다"와 "애플리케이션이 작업을 완료했다" 사이의 차이점이다.

구체적인 예: 리드 분석은 단순한 프롬프트가 아니다

간단한 에이전트 애플리케이션의 예로, 이벤트나 마케팅 캠페인 종료 후의 리드 분석을 들 수 있다. 단순히 프롬프트만으로는 흔히 있는 버전이다: 사용자가 리드 목록을 붙여넣고 모델이 그것들을 정렬하게 한다. 모델은 표를 반환하고, 아마도 점수와 제안된 후속 대화도 포함될 것이다. 유용하지만 불완전하다.

진정으로 실행 가능한 에이전트 애플리케이션은 작업 흐름의 나머지 부분을 처리해야 한다:

양식, 스프레드시트, CRM 또는 이벤트 시스템에서 리드를 가져오기;
원본 출처를 유지하면서 필드를 표준화하기;
모델을 사용하여 분류하고, 선택적으로 강화된 API를 호출하여 데이터 보충하기;
어떤 외부 호출이 비용을 발생시키는지 표시하기;
메시지를 보내거나 CRM에 다시 쓰기 전에 확인 요청하기;
누가 이 작업을 승인했는지 기록하기;
무엇이 청구되었는지, 어떤 자원이 소모되었는지, 어떤 결과가 발생했는지 보여주기;
작업이 실패할 경우, 환불, 재시도 또는 분쟁 처리를 지원하기.

이것이 많은 AI 애플리케이션이 조용히 무너지는 지점이다. 모델은 다음 단계에서 무엇을 해야 하는지 제안할 수 있지만, 제품 수준은 권한 부여, 실행, 비용 및 책임을 져야 한다. 이 제품 능력의 층이 우리가 말하는 "실행 시(Runtime)"이다.

실행에는 계약이 필요하다

우리는 "에이전트 실행"이 모델에 무한한 권한을 부여하는 것을 의미한다고 생각하지 않는다. 더 나은 모델은 더 수렴해야 한다: 사용자 의도 → 모델이 제안하는 솔루션 → 실행 시 검증 → 도구 실행 → 감사 기록. 모델은 이해하고 계획하는 책임이 있고, 실행 시는 검증하고 실행하는 책임이 있다.

실질적인 의미가 있는 모든 작업에 대해, 실행 시는 "실행 계약(Execution Contract)"을 구성할 수 있어야 한다. 이것은 반드시 인터페이스에서 볼 수 있는 문서일 필요는 없으며, 플랫폼에 "다음에 무슨 일이 일어날 것인지"를 알리는 내부 객체이다.

실행 계약은 다음 질문에 답할 수 있어야 한다:

지불자(payer): 누가 지불하는가;
에이전트 애플리케이션(agentapp): 어떤 애플리케이션이 실행되고 있는가; 구축자(builder): 이 애플리케이션은 누가 생성했는가; 작업(task): 어떤 작업이 실행되고 있는가; 가격(pricing): 이 작업은 어떻게 가격이 책정되는가; 예산 상한(budgetcap): 허용되는 최대 비용은 얼마인가;
확인(confirmation): 사용자 확인이 필요한가;
측정(metering): 무엇을 측정해야 하는가;
정산(settlement): 지불은 어떻게 정산되는가;
감사(audit): 실행 과정은 어떻게 추적되는가.

사용자 경험 측면에서는 간단하게 유지할 수 있다:

"이 작업은 최대 0.50달러가 소요될 수 있습니다. 계속하시겠습니까?"

하지만 백엔드는 그렇게 간단할 수 없다. 그것은 사용자가 이 작업을 승인했는지, 얼마나 많은 예산을 예약했는지, 어떤 도구를 호출했는지, 실제 실행 비용이 얼마인지, 작업이 완료되었는지, 어떤 증명서를 발급해야 하는지를 알아야 한다. 이 계약이 없으면, 지불은 단순한 결제 화면일 뿐이다; 그것이 있으면, 지불은 실행 과정의 일부가 된다.

지불은 결제 버튼이 아니다

에이전트 애플리케이션에 대해, 지불은 제품 외부에 강제로 붙어서는 안 된다. 에이전트가 실제로 일을 시작하는 순간, 비용과 가치는 실행 시의 문제로 변한다. 일부 작업은 모델 토큰을 소모하고, 일부는 유료 API를 호출하며, 일부는 계산, 저장, 검색, 데이터 서비스 제공업체, 배포 인프라 또는 제3자 서비스를 사용하고, 일부 작업은 직접적으로 상업적 가치를 창출한다.

따라서 지불 문제는 단순히 "카드로 결제할 것인가, 지갑으로 할 것인가?"가 아니다.

오히려:

누가 이 작업을 시작했는가?
누가 이 예산을 승인했는가?
어떤 자원이 소모되었는가?
결과는 완료되었는가?
얼마나 많은 비용을 청구해야 하는가?
수익은 어떻게 분배되어야 하는가?
작업이 실패하면 어떻게 되는가?
무슨 기록이 발생했는지를 증명할 수 있는가?

이것이 우리가 에이전트 애플리케이션의 지불을 "에이전트 상업층(Agent Commerce Layer)"으로 간주하는 이유이다. 실용적인 "실행-상업" 상태 기계는 대략 다음과 같을 수 있다: 견적 → 승인 → 예약 → 실행 → 측정 → 정산 → 증명서 발급 → 분배 → 환불/분쟁 처리.

대부분의 사용자는 이 전체 메커니즘을 영원히 볼 필요가 없다. 그들은 명확한 비용 경계와 명확한 결과만 보아야 한다. 예를 들어, 리드 분석 에이전트 애플리케이션의 전형적인 가격 책정 전략은 다음과 같을 수 있다:

무료 한도: 처음 10회 실행 무료;
가격 단위: 작업 단위;
작업 가격: 리드 1배치당 3달러;
예산 상한: 각 작업에 허용되는 최대 내부 비용;
외부 비용이 직접 전가되는지 여부: 예/아니오;
확인이 필요한지 여부: 외부 메시지를 보내거나 CRM에 기록하기 전에 필요하다.

(이 숫자는 제품 모델의 예시일 뿐이며, X-Agent가 현재 공개하고 있는 실제 가격이 아니다.)

구축자는 원래의 토큰 비용을 계산할 필요가 없으며, 사용자도 모든 내부 측정 지표를 볼 필요가 없다------플랫폼은 실행 과정을 사용자가 이해할 수 있는 가격으로 번역해야 한다. 초기 단계에서, 실용적인 시작점은 간단하다: 무료 한도 + 사용량 한도 + 작업 SKU. 사용량에 따라 가격을 책정하는 것은 모델 호출, API 호출, 검색, 저장 및 계산에 적합하며; 작업에 따라 가격을 책정하는 것은 리드 분석, 페이지 생성, 애플리케이션 배포, 보고서 생성, 데이터 세트 요약 또는 명확하게 정의된 작업 흐름 실행과 같은 명확한 작업에 적합하다.

세션 또는 구독에 따라 가격을 책정하는 것은 고빈도 사용 도구에 적합하다. 결과에 따라 가격을 책정하는 것은 매력적이지만, 더 나중에 진행해야 한다------대부분의 에이전트 애플리케이션이 상업적 결과에 따라 요금을 청구하기 전에, 귀속, 위험, 신뢰, 책임 인정 및 분쟁 처리 메커니즘이 충분히 강력해져야 한다.

추상화된 지불 채널, 실행 계약 유지

지불 채널은 제품 경험을 정의해서는 안 된다. 사용자가 구매하는 것은 작업 결과이지, 지불 계약 자체가 아니다. 구축자가 알고 싶어하는 것은:

이 에이전트 애플리케이션은 어떻게 가격이 책정되는가?
누가 지불하는가?
비용은 어떻게 통제되는가?
구축자의 수익은 언제 현실이 되는가?
작업이 실패하면 어떻게 되는가?

그들은 기본 채널이 신용 카드, Apple Pay, 플랫폼 포인트, 인보이스, 스테이블코인, 지갑 또는 어떤 에이전트 간의 지불 계약인지에 대해 걱정할 필요가 없다. 제품 측면에서, 이러한 개념은 간단하게 유지되어야 한다: 잔액, 포인트, 인보이스, 지갑.

그리고 하부에서는, 여러 지불 채널이 공존할 수 있다:

주류 사용자에게는 신용 카드나 Apple Pay;
일반적인 유료 작업을 위한 플랫폼 포인트;
기업 고객을 위한 인보이스나 선불 포인트;
Web3 원주율 사용자에게는 지갑이나 스테이블코인 채널;
에이전트 간의 장면을 위한 승인 예산 및 자동 정산.

신흥 인프라의 예로는 에이전틱 지갑(agentic wallet), x402와 유사한 유료 호출 프로토콜, 스테이블코인 정산 및 프로그래머블 지불 시스템이 있다. 이들은 모두 같은 방향을 가리킨다: 소프트웨어는 실행 시 수준에서 작동할 수 있는 지불 채널이 필요하다. 이는 모든 에이전트 애플리케이션이 암호화폐를 사용해야 한다는 것을 의미하지 않으며, 애플리케이션 층은 지불 채널을 추상화하고 그 위에 실행 계약을 유지해야 한다.

다양한 사용자들은 서로 다른 결제 경로가 필요하지만, 계약 자체는 일관성을 유지해야 합니다.

배포는 실행 시간 문제의 일부이기도 합니다.

한 번 생성하는 것이 쉬워지면 배포는 더 어려워집니다. AI 구축자는 애플리케이션의 공급량을 증가시키지만, 이는 사용자가 적합한 애플리케이션을 찾을 수 있다는 것을 의미하지 않으며, 구축자가 자신이 만든 것에서 수익을 얻을 수 있다는 것을 의미하지도 않습니다. 에이전트 애플리케이션 생태계는 단순히 공개된 애플리케이션 목록만으로는 충분하지 않습니다. 발견 메커니즘, 신뢰 메커니즘, 순위 메커니즘, 인센티브 메커니즘, 사용 피드백이 필요하며, 실행 시간 위험을 이해해야 합니다.

일반적인 애플리케이션 스토어는 대략 다음과 같은 질문을 합니다:

이것은 어떤 애플리케이션인가?
누가 개발했는가?
설치할 수 있는가?
평가는 어떤가?

하지만 에이전트 스토어는 더 많은 질문을 해야 합니다:

이 에이전트 애플리케이션은 어떤 작업을 수행할 수 있는가?
어떤 권한이 필요한가?
어떤 도구를 호출할 수 있는가?
사용하는 데 비용이 얼마나 드는가?
어떤 작업을 완료했는가?
실제로 유용하다는 것을 증명할 수 있는 사용 신호가 있는가?
어떤 결제 또는 증명 이력이 존재하는가?
이 구축자의 신뢰도는 어떤가?
누가 배포를 도와주거나 콘텐츠 선별을 하고 있는가?

이는 제품 방향이며, 각 구성 요소가 오늘날 모두 성숙해져야 한다는 것은 아닙니다. 우리의 견해는 에이전트 스토어가 빈 열린 시장을 출발점으로 삼아서는 안 되며, "고품질 에이전트 애플리케이션에 대한 선별된 배포 및 성장 지원의 층"에서 시작해야 한다는 것입니다. 이는 고품질 애플리케이션을 선별하고, 초기 노출, 운영 활동, 실제 사용 상황 검증, 유효한 배포 행동에 대한 보상을 제공하며, 저품질 또는 허위의 활성 데이터를 걸러내는 것을 의미합니다.

성장 메커니즘은 도움이 될 수 있지만, 전제 조건은 그것이 실제 사용과 연결되어야 한다는 것입니다. 추천 보상, 작업 활동, 순위표, 생태계 인센티브 ------ 이러한 메커니즘은 실제로 사용자가 문제를 해결할 수 있는 에이전트 애플리케이션으로 안내할 때만 의미가 있으며, 그렇지 않으면 단순히 트래픽을 생성할 뿐 신뢰를 가져오지 않습니다.

구축자 경제의 플라이휠

상업적 기회는 구축, 실행 시간, 결제 및 배포가 연결될 때 발생합니다.

구축자가 에이전트 애플리케이션을 생성합니다
→ 사용자가 이를 발견하고 사용합니다
→ 실행 시간에 따라 실행 과정을 측정합니다
→ 사용자가 유용한 작업에 대해 비용을 지불합니다
→ 구축자의 수익이 가능해집니다
→ 추천인 또는 콘텐츠 큐레이터가 배포를 도와줍니다
→ 실제 사용 데이터가 순위와 템플릿을 개선합니다
→ 더 많은 구축자가 참여합니다

결제는 제품 사용과 연결되고, 배포는 실행 품질과 연결되며, 구축자 인센티브는 실행 시간 측정과 연결됩니다. 이 메커니즘이 실제로 작동하려면 플랫폼은 궁극적으로 진정한 장부(ledger)가 필요합니다. 의미 있는 결제 실행이 있을 때마다 기록해야 합니다:

총 청구 금액(grosscharge) 모델 비용(modelcost)
도구 비용(toolcost) 인프라 비용(infracost)
결제 수수료(paymentfee) 플랫폼 비용(platformfee)
구축자 수익(builderrevenue) 추천 보상(referrerreward)
환불 금액(refundamount) 정산 상태(settlementstatus)

이 기반이 없으면 수익 분배, 환불, 기업 청구, 반사기 제어, 세무 신고, 송금 및 감사가 매우 취약해집니다. 이를 통해 에이전트 애플리케이션은 진정한 경제 단위가 될 수 있습니다: 구축자는 애플리케이션을 게시할 수 있고, 사용자는 유용한 작업에 대해 비용을 지불할 수 있으며, 콘텐츠 큐레이터는 배포를 도와주고, 플랫폼은 실행 품질에 따라 애플리케이션의 순위를 매길 수 있습니다. 이것이 "애플리케이션 생성"에서 "에이전트 애플리케이션 상업화"로의 전환입니다.

X-Agent의 위치는 어디인가

X-Agent는 "에이전트 애플리케이션 층"으로 구축되고 있습니다.

기본 모델을 대체할 의도는 없으며, 클라우드 서비스 제공자를 대체할 의도도 없고, 지갑 인프라를 대체할 의도도 없으며, 단순히 또 다른 프로그래밍 에이전트도 아닙니다. 우리가 구축하고 있는 기술 스택은 대략 다음과 같습니다:

기본 모델
→ 구축자 / 실행 프레임워크
→ 안전한 실행 시간 / 도구 / 지갑
→ 에이전트 애플리케이션
→ 스토어 / 배포 / 성장

기본 모델은 지능을 제공합니다;
구축자와 실행 프레임워크는 의도를 애플리케이션으로 전환합니다;
안전한 실행 시간, 도구, 지갑 및 결제 시스템은 실행 경계를 정의합니다;
에이전트 애플리케이션은 실제 사용자에게 초점을 맞춥니다;
스토어, 배포 및 성장 시스템은 고품질 에이전트 애플리케이션이 대규모 사용자 채택을 얻도록 돕습니다.

중요한 것은 오늘날 모든 퍼즐 조각이 완료되었다는 것이 아니라, 에이전트 애플리케이션이 다음과 같은 완전한 생애 주기를 경험해야 한다는 것입니다: 생성 → 배포 → 실행 → 측정 → 청구 → 정산 → 배포 → 반복 개선. 만약 플랫폼이 단순히 사람들이 애플리케이션을 생성하도록 돕는다면, 그것은 "애플리케이션 구축기"라는 층에서 경쟁하는 것일 뿐입니다; 만약 그것이 단순히 지갑을 제공한다면, 그것은 단순히 인프라일 뿐입니다; 만약 그것이 단순히 성장 활동을 운영한다면, 그것은 단순한 배포 도구일 뿐입니다.

하지만 에이전트 애플리케이션 층은 이 세 가지를 연결합니다.

생성된 애플리케이션에서 에이전트 상업체로

AI 소프트웨어의 첫 번째 단계는 지능에 초점을 맞추고 있습니다 ------ 대답할 수 있고, 추론할 수 있으며, 생성할 수 있고, 도움을 제공할 수 있는 모델입니다. 다음 단계는 실행에 초점을 맞추고 있습니다 ------ 도구를 사용하고, 상태를 관리하며, 작업을 완료할 수 있는 에이전트 애플리케이션입니다. 그 다음 단계는 경제에 초점을 맞추고 있습니다 ------ 발견되고, 가격이 매겨지고, 비용이 지불되며, 배포되고, 실제 사용을 통해 지속적으로 개선되는 에이전트 애플리케이션입니다.

생성된 애플리케이션은 이 전환 경로의 시작점일 뿐이며, 제품의 끝점이 아닙니다. AI 애플리케이션의 미래는 "얼마나 많은 데모를 생성할 수 있는가"로 정의되지 않고, "얼마나 많은 에이전트 애플리케이션이 실제 작업을 수행하고, 실제 사용자에게 도달하며, 실제 경제 활동을 유지할 수 있는가"로 정의됩니다.

이것이 바로 X-Agent가 구축하고 있는 애플리케이션 층 방향입니다.

만약 당신이 에이전트 애플리케이션, 지능형 지갑 인프라를 구축하고 있거나 AI 네이티브 소프트웨어를 위한 배포 채널을 구축하고 있다면, X-Agent를 주목하여 실행 시간, 상업화 및 배포에 대한 더 많은 구축 노트를 받아보시기 바랍니다.