AI Agent가 발전하면 자연스럽게 “사람이 개입하지 않아도 알아서 끝까지 해주는 것”을 떠올리게 됨.

그런데 Web3에서는 분석 결과 하나가 실제 자산 이동이나 온체인 실행으로 이어질 수 있음. 이런 상황에서 처음부터 끝까지 AI에게 무조건 맡기는 것만이 좋은 설계라고 보기는 어려움.

DAPPOS의 MAF는 그래서 AI Interrupt와 Human-in-the-Loop 구조를 포함합니다. 내부 Controller가 작업을 진행하면서 필요한 지점에서는 AI 흐름을 멈추거나 사용자 확인을 받을 수 있도록 설계돼 있습니다. 공식 기술 자료는 이를 자율적인 AI 판단에 자유를 주면서도 오류를 줄이는 safety rail로 설명합니다.

즉 목표는

완전 자동화

하나가 아니라

자동화할 곳은 자동화하고, 중요한 순간에는 사람이 다시 개입할 수 있게 만드는 것

AI Agent가 실제 업무와 자산을 다룰수록 이런 경계 설계가 더 중요해질 수 있음

모든 작업에 사용자의 확인을 받으면 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 작업 진행
↓
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를 두는 기술적 이유를 가장 쉽게 설명하면 이 구조임.