모든 작업에 사용자의 확인을 받으면 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이 필요한 이유임.

사용자가

“브리지하고 싶다”

고 말하는 경우도 있지만, 실제 목적은 그 뒤에 있는 경우가 많음.

다른 체인의 dApp에서 자산을 사용하기 위해 어쩔 수 없이 브리지를 거치는 것임.

Intent-centric 구조에서는 이 차이가 중요함.

DAPPOS는 asset bridging과 dApp contract call을 하나의 상호작용 흐름에서 결합할 수 있도록 설계됐습니다.

그래서 사용자의 목표가

Chain A → Chain B로 토큰 이동

이 아니라

Chain B의 dApp에서 특정 결과 달성

이라면,

브리지는 목적 자체가 아니라 그 Intent를 만족시키기 위한 dependency 해결 단계로 볼 수 있음.

Web3를 쉽게 만드는 방법이 체인을 없애는 게 아니라 체인을 사용자가 직접 신경 써야 하는 횟수를 줄이는 것일 수 있는 이유임.

복잡한 dApp 기능은 버튼 한 번 뒤에서도 여러 상태 변화가 필요할 수 있음.

사용자는 화면에서 하나의 행동처럼 느끼지만 실제 블록체인에서는 자산 준비, 이동, 승인, contract interaction처럼 여러 과정이 연결될 수 있음.

DAPPOS가 Intent-centric dApp Interaction에서 arbitrary steps와 dependencies를 명시적으로 언급하는 이유도 여기에 있습니다.

즉 자동화 대상은

Transaction 1개

보다

최종 결과를 만들기 위한 Transaction sequence

에 가까움.

이런 구조에서는 개별 트랜잭션보다 전체 실행 흐름이 하나의 단위가 됨.

사용자는 한 가지 결과를 요청하지만 뒤에서는 여러 단계가 연결될 수 있다는 것임.

크로스체인 환경에서는 자산이 여러 네트워크에 흩어질 수 있음.

그러면 사용자는

“내 자산이 어디 있지”

부터 생각해야 함.

DAPPOS Unified Account는 여러 블록체인의 자산을 관리하고, DAPPOS와 통합된 dApp에서 사용할 수 있도록 Intent Execution Network와 호환되는 계정 구조​로 설명됩니다.

중요한 건 Unified Account가 단순히 잔액을 한 화면에 보여주는 기능이라는 뜻이 아님.

Intent-centric Interaction과 결합되면서

어떤 체인에 자산이 있는가

보다

이 자산을 지금 원하는 dApp에서 사용할 수 있는가

가 사용자에게 더 중요한 질문이 되는 것임.

Account Layer와 Execution Layer를 함께 묶으려는 이유임.

Intent 시스템이 아무리 좋아도 실제 dApp과 연결되지 않으면 사용 범위가 제한됨.

그래서 계정과 실행 네트워크뿐 아니라 dApp integration layer도 필요함.

DAPPOS 공식 문서는 Unified Account의 자산을 DAPPOS SDK가 통합된 dApp에서 여러 블록체인에 걸쳐 사용할 수 있는 구조로 설명합니다.

즉 구조를 단순화하면

Unified Account
+
Intent Execution Network
+
Integrated dApp

이 서로 연결되는 것임.

사용자가 새로운 dApp을 사용할 때마다 완전히 새로운 자산 관리 방식을 배우는 대신, 공통 실행 계층을 활용하려는 방향임.

Web3에서 UX 표준화가 단순 디자인 문제가 아니라 Account와 Execution의 호환성 문제인 이유임.

Web3를 처음 사용하는 사람이 자주 당황하는 상황이 있음.

자산은 있는데 트랜잭션을 실행할 가스 토큰이 없는 경우임.

결과적으로 원하는 자산과 별개로 특정 네트워크의 수수료 토큰을 따로 준비해야 함.

DAPPOS Unified Account는 공식 문서상 mainstream token을 이용한 fee payment를 지원하도록 구성돼 있습니다.

이것도 Intent UX와 연결됨.

사용자가 원하는 건 보통

“가스 토큰을 먼저 확보하기”

가 아니라

“원하는 작업을 완료하기”

이기 때문임.

즉 DAPPOS가 줄이려는 중간 단계에는 브리징이나 contract call뿐 아니라 수수료 준비 과정도 포함될 수 있음.

작은 기능처럼 보여도 실제 Web3 진입 장벽을 만드는 대표적인 마찰 중 하나임.

Intent 시스템에서는 사용자가 직접 모든 단계를 실행하지 않음.

Service Provider가 사용자 대신 복잡한 실행 경로를 처리할 수 있음.

그렇다면 중요한 문제가 생김.

Service Provider가 필요한 작업을 어떻게 효율적으로 실행할 수 있게 할 것인가.

DAPPOS는 Unified Account를 Intent Execution과 본질적으로 호환되도록 설계해 Service Provider authorization을 원활하게 하는 방향이라고 설명합니다.

즉 계정 시스템과 실행 네트워크가 따로 놀면 안 됨.

Account
→ 자산 관리

Intent
→ 목표 정의

Service Provider
→ 실제 실행

이 세 가지가 연결돼야 함.

Intent 기반 Web3에서 Account Architecture가 중요한 이유가 바로 이 부분임.

이번 기술을 하나로 연결하면 이런 흐름으로 볼 수 있음.

사용자 목표
↓
필요한 dApp Interaction
↓
Contract Calls
+
Asset Bridging
↓
Step Dependency 처리
↓
Unified Account의 Cross-chain Assets
↓
Service Provider Authorization
↓
Fee Abstraction
↓
원하는 결과

DAPPOS는 Intent-centric dApp Interaction을 contract-based wallet 호출과 asset bridging을 결합하고, 여러 중간 단계와 dependency가 있는 dApp 작업을 자동화하는 framework로 설명합니다. Unified Account 역시 Intent Execution Network와 호환되도록 설계돼 있습니다.

여기서 핵심은 블록체인이 실제로 사라지는 게 아님.

체인도 있고,

브리지도 있고,

컨트랙트도 있고,

수수료도 여전히 존재함.

다만 사용자가 그 모든 기술적 중간 단계를 직접 조립해야 하는 필요를 줄이는 것임.

그래서 Intent Architecture를 쉽게 표현하면

복잡한 Web3 실행 방법을 사용자 목표 뒤로 숨기는 기술

이라고 볼 수 있음.

AI에게 기억 기능이 있다고 하면 보통 하나의 거대한 저장소부터 떠올리게 됨.

그런데 Web3에서는 정보의 성격이 완전히 다름.

프로토콜의 기본 구조처럼 비교적 오래 유지되는 지식이 있는 반면, 최근 시장에서 발견한 패턴처럼 시간이 지나면서 가치가 달라지는 정보도 있음.

DAPPOS의 Bubble Engine은 그래서 Compound Memory에서 durable knowledge와 episodic learnings를 함께 다루는 구조를 사용합니다. Durable 쪽에는 core, verified Web3 facts and models가 포함된다고 공식 문서에서 설명합니다.

즉 모든 기억을 똑같이 취급하는 게 아니라

오래 유지할 지식
+
최근 경험에서 얻은 학습

을 서로 다른 성격의 정보로 보는 것임.

AI Memory에서 중요한 것은 얼마나 많이 기억하느냐뿐 아니라 어떤 기억을 어떤 성격으로 보관하느냐일 수 있음.

AI가 잘못된 정보를 한 번 답하는 것도 문제지만, 그 내용을 장기 지식으로 계속 재사용한다면 문제는 더 커짐.

다음 질문에서도 같은 오류가 반복될 수 있기 때문임.

DAPPOS는 Compound Memory의 durable knowledge를 core, verified Web3 facts and models​라고 설명합니다. 즉 오래 사용하는 지식에는 단순히 최근에 발견했다는 이유보다 검증된 핵심 정보라는 성격을 강조하고 있음.

여기서 중요한 단어가 verified임.

장기 기억은 여러 미래 작업에서 다시 쓰일 가능성이 있기 때문에 입력 단계의 품질이 더 중요해질 수 있음.

기술적으로 보면

기억의 수명이 길어질수록 잘못된 정보의 영향 범위도 커질 수 있기 때문임.

그래서 장기 Memory와 정보 검증은 따로 떼어 보기 어려운 문제임.

AI가 어떤 작업을 수행하면서 새로운 패턴을 발견했다고 해보자.

그 경험이 유용할 수는 있지만 곧바로 시스템 전체의 영구적인 진실이라고 보기는 어려움.

DAPPOS의 Compound Memory는 durable knowledge와 함께 episodic learnings를 별도의 층으로 결합합니다. 다른 공식 기술 설명에서는 이를 bubble-driven episodic learnings라고 표현합니다.

쉽게 보면 episodic 쪽은

“세상은 반드시 이렇게 작동한다”

보다는

“최근 이런 상황에서 이런 경험과 학습이 있었다”

에 더 가까운 정보 형태로 이해할 수 있음.

AI가 새로운 경험에서 빠르게 배우면서도 모든 경험을 곧바로 장기 지식과 동일시하지 않는 구조가 필요한 이유임.

RAG와 AI Memory는 비슷해 보여서 헷갈릴 때가 많음.

둘 다 AI에게 추가 정보를 주기 때문임.

하지만 역할은 다름.

DAPPOS는 Bubble Engine에서 Contextual RAG와 Compound Memory를 서로 보완하는 별도의 메커니즘으로 설명합니다. Contextual RAG는 provenance-first 방식으로 필요한 정보를 모으는 쪽이고, Compound Memory는 durable knowledge와 episodic learnings를 결합하는 쪽임.

쉽게 표현하면

RAG
→ 지금 필요한 정보를 찾아옴

Memory
→ 반복적으로 활용할 지식과 학습을 유지함

에 가까움.

좋은 AI가 되려면 매번 최신 정보를 찾아오는 능력과 과거에 이미 배운 것을 다시 활용하는 능력이 둘 다 필요함.

Web3에서는 오늘 맞는 정보가 몇 달 뒤에는 달라질 수 있음.

프로토콜이 업그레이드되고, 새로운 네트워크가 등장하고, 시장 구조도 계속 변하기 때문임.

DAPPOS는 Bubble Engine을 실시간 정보를 받아들이며 계속 적응하는 adaptive learning core로 설명하면서, 동시에 Compound Memory에서 durable knowledge와 episodic learning을 결합합니다.

여기서 durable을 “절대로 변하지 않는 데이터”라고 이해하면 안 됨.

공식 구조를 바탕으로 보면 더 자연스러운 해석은 일회성 경험보다 오래 유지하며 재사용할 가치가 있는 검증된 지식 층에 가까움.

Web3 AI에서는 기억하는 능력만큼 언제 새로운 정보로 기존 이해를 갱신할 것인가도 중요함.

AI가 검색 과정에서 잘못된 자료 하나를 보는 것과 그 자료를 반복적으로 사용하는 기억으로 남기는 것은 위험도가 다름.

기억에 들어간 정보는 이후 여러 판단에 영향을 줄 수 있기 때문임.

DAPPOS는 Bubble Engine의 주요 메커니즘을 설명하면서 Compound Memory와 함께 misinformation handling을 명시적으로 언급합니다. 공식 기술 자료에서는 cross-verification과 Web3 기반 메커니즘을 활용해 정보 품질 문제를 다루는 방향도 제시합니다.

즉 Memory 시스템에서 중요한 질문은

“무엇을 기억할까”

뿐 아니라

“이걸 기억해도 되는가”

임.

기억 능력이 강해질수록 잘못된 정보도 더 오래 살아남을 수 있기 때문에 Memory와 Verification을 함께 설계해야 하는 이유임.