AI가 “이 전략이 좋아 보입니다”라고 분석하는 것과 실제 자산을 움직이는 것은 다른 문제임.

그래서 DAPPOS의 DeFi Subgraph는 시장 데이터를 가져오고 strategy_generator가 계획을 만든 뒤 strategy_validator를 거치도록 구성돼 있습니다.

공식 백서는 이 Validator가 위험을 평가하고, 결과를 시뮬레이션하며, 필요한 경우 사용자 선택까지 반영한다고 설명합니다.

흐름은 대략

Market Data
↓
Strategy Generation
↓
Risk Check
↓
Simulation
↓
Validation

임.

즉 Intelligence Layer에서 좋은 아이디어를 만드는 것과 실행 가능한 계획으로 승인하는 것을 분리함.

Web3 AI에서 “생각을 잘하는 Agent”와 “실제로 실행해도 되는 판단” 사이에 하나의 검증 계층이 필요한 이유임

DeFi 전략은 논리적으로 그럴듯해 보여도 실제 실행 조건에서는 결과가 달라질 수 있음.

시장 상태가 달라질 수도 있고, 위험 요소가 예상보다 커질 수도 있음.

DAPPOS의 strategy_validator는 계획을 검증할 때 risk assessment와 outcome simulation을 수행하도록 공식 기술 자료에 설명돼 있습니다.

이 과정의 의미는 간단함.

AI가 계획을 만들었다고

Plan → Execute

로 바로 넘어가는 대신,

Plan
→ Risk Check
→ Simulation
→ Validated Plan
→ Execution

이라는 단계를 두는 것임.

실행 가능한 AI에서 중요한 것은 좋은 계획을 많이 만드는 능력만이 아님.

틀린 계획을 실제 행동으로 옮기기 전에 잡아낼 수 있는 구조도 같이 필요함.

모든 작업에 사용자의 확인을 받으면 AI 자동화의 장점이 사라짐.

반대로 어떤 작업이든 AI가 마음대로 실행하게 만들면 통제 문제가 생길 수 있음.

DAPPOS는 이 사이에서 optional UI interrupt를 통한 user approval 구조를 설명합니다.

특히 Tool-Augmented Plan Generation 과정에서 Validator Node가 risk parameter를 교차 확인하고, 필요한 경우 사용자 승인을 받는 UI Interrupt를 넣어 Intelligence에서 Execution으로 넘어가는 흐름을 제어합니다.

즉 모든 단계에서

“계속할까요”

를 묻는 게 아니라,

중요한 경계에서만 통제권을 사용자에게 넘길 수 있는 방식임.

자동화 수준이 높아질수록 이런 selective approval이 UX에서 더 중요해질 수 있음.

사용자가 항상 완벽한 프롬프트를 입력할 수는 없음.

예를 들어

“내 상황에 맞게 포트폴리오 구성해줘”

라고 했는데 기간이나 위험 선호도처럼 중요한 정보가 빠져 있을 수도 있음.

DAPPOS 공식 백서에서는 사용자의 질문이나 제공된 정보가 정확한 분석을 하기 부족할 경우 AI가 실행을 일시정지하고 targeted question을 통해 추가 정보를 요청하는 구조를 설명합니다.

이게 꽤 중요한 차이임.

정보 부족
→ AI가 임의로 가정
→ 결과 생성

이 아니라,

정보 부족
→ Interrupt
→ 필요한 항목 질문
→ 답변 수신
→ 작업 계속

이라는 방식임.

Low-Prompt AI라고 해서 무조건 사용자의 입력을 짧게 받아 추측하는 것이 아니라, 꼭 필요한 정보만 다시 물어볼 수 있어야 함.

AI가 10초 정도 생각하는 작업이라면 기다려도 큰 문제가 없음.

그런데 여러 Agent가 검색하고 분석하고 검증하는 장기 작업이 몇 분 이상 이어지면 사용자는 지금 AI가 정상적으로 일하고 있는지 알기 어려움.

DAPPOS의 MAF는 이를 위해 long-running task 동안 메시지를 streaming해 진행 상황을 실시간으로 사용자에게 전달하는 구조를 포함합니다.

Streaming은 단순히 로딩 화면을 예쁘게 만드는 기능만은 아님.

사용자가 작업 흐름을 보고 있다가 필요하면 개입할 수 있다는 점에서 Interrupt 구조와 함께 Human-in-the-Loop를 가능하게 하는 인터페이스가 됨.

자동화가 길고 복잡해질수록

“끝나면 알려줘”

만큼이나

“지금 어디까지 진행됐는지 보여줘”

가 중요해지는 이유임.

이번 기술을 한 흐름으로 연결하면 이렇게 볼 수 있음.

사용자 요청
↓
AI 작업 진행
↓
Search Confidence Check
↓
정보 부족 시 Clarification Interrupt
↓
Strategy 생성
↓
Risk Validation + Simulation
↓
필요 시 UI Approval
↓
Validated Plan
↓
Execution Layer

장시간 작업에서는 중간 진행 상황도 Streaming으로 전달됨. DAPPOS는 이런 구조를 composable autonomy와 safety rails를 결합하는 방식으로 설명하며, 최신 공식 문서에서도 HCI Interrupt, streaming progress, safety rail을 MAF의 human-in-the-loop 요소로 제시합니다.

결국 강한 AI Agent는 무조건 사람 없이 끝까지 움직이는 시스템일 필요는 없음.

확실할 때는 스스로 진행하고,
불확실하면 더 검증하고,
정보가 부족하면 질문하고,
중요한 행동 앞에서는 사람에게 결정권을 돌려주는 것.

DAPPOS가 AI Interrupt를 두는 기술적 이유를 가장 쉽게 설명하면 이 구조임.

사용자가 원하는 건 의외로 단순함.

“이 자산으로 저 dApp을 사용하고 싶다.”

그런데 실제 Web3에서는 어떤 체인에 자산이 있는지 확인하고, 필요하면 브리지하고, 컨트랙트를 호출하고, 다음 트랜잭션까지 순서대로 처리해야 할 수 있음.

DAPPOS의 Intent-centric dApp Interaction은 이런 여러 작업을 사용자가 하나씩 수행하는 대신 최종적으로 원하는 결과를 중심으로 실행을 구성하는 방식입니다. 공식 문서에서는 contract-based wallet의 contract call과 asset bridging을 하나의 흐름 안에서 처리하며, 중간 단계와 의존성이 복잡한 경우도 지원하도록 설계됐다고 설명합니다.

즉 바꾸려는 것은 단순 UI가 아님.

사용자가 실행 순서를 설계

하는 방식에서

사용자는 결과를 지정
→
시스템이 필요한 실행 단계를 처리

하는 방식으로 책임을 이동시키는 것임.

일반적인 크로스체인 사용에서는 브리지가 하나의 작업이고 dApp 사용이 또 다른 작업처럼 느껴짐.

먼저 자산을 옮기고,

도착을 확인하고,

다시 dApp에 접속한 뒤,

컨트랙트를 실행하는 식임.

DAPPOS의 Intent-centric dApp Interaction은 contract call과 asset bridging을 함께 구성할 수 있는 구조를 설명합니다.

이 관점에서는 브리지가 사용자의 최종 목적이 아닐 수도 있음.

예를 들어 목표가 특정 dApp에서 자산을 사용하는 것이라면 브리징은 그 결과를 만들기 위해 필요한 내부 실행 단계 중 하나가 되는 것임.

Web3 UX에서 꽤 중요한 변화임.

사용자가 프로토콜의 모든 중간 단계를 이해해야 하는 구조에서 목적과 실행 방법을 분리하는 구조로 가기 때문임.

여러 온체인 작업이 필요하다고 해서 전부 동시에 실행할 수 있는 것은 아님.

A 작업의 결과가 있어야 B 작업을 시작할 수 있는 경우가 있기 때문임.

예를 들어 자산이 다른 체인에 있다면 자산 이동이 완료된 뒤에야 그 자산을 사용하는 컨트랙트 호출이 가능할 수 있음.

DAPPOS는 Intent-centric dApp Interaction이 arbitrary steps and dependencies가 존재하는 상황에서도 contract call과 bridging을 처리하도록 설계됐다고 설명합니다.

즉 중요한 것은 작업 목록만 만드는 게 아님.

무엇을 해야 하는가

와 함께

무엇이 먼저 완료돼야 다음 작업을 할 수 있는가

도 실행 시스템이 다뤄야 함.

복잡한 Intent를 자동화하려면 결국 dependency-aware execution이 필요한 이유임.