AI에게 복잡한 작업을 맡기면 작업 과정에서 여러 파일과 도구, 임시 환경이 생길 수 있음.

이걸 사용자의 PC에 계속 남겨두면 시간이 지날수록 환경이 복잡해질 수 있음.

DAPPOS는 Bubble Personal의 sandbox 구조에서 설치나 시스템 수준 작업이 이루어지는 Cloud Container를 작업 완료 후 폐기하는 방식을 설명합니다.

쉽게 비유하면 AI에게 내 방 전체를 내주는 대신,

필요할 때 별도의 작업실을 하나 만들어주고 일이 끝나면 작업실 자체를 치우는 방식에 가까움.

AI Agent가 더 많은 도구를 사용할수록 이런 격리 구조의 의미도 커질 수 있음.

강한 AI를 만드는 것과 안전하게 일을 시키는 것은 다른 문제이기 때문임.

개인 AI가 로컬 파일과 브라우저를 다룬다면 가장 중요한 질문이 있음.

“AI가 내 컴퓨터에서 어디까지 마음대로 할 수 있나?”

DAPPOS 공식 설명에서는 Bubble Personal이 사용자의 머신에서 explicitly authorized actions만 실행하도록 설계됐다고 밝히고 있습니다.

즉 Personal AI를 구현한다고 해서 사용자의 로컬 환경 전체를 자유롭게 변경하도록 만드는 방향은 아님.

AI가 할 수 있는 일과
사용자가 허용한 일을
구분하려는 구조임.

앞으로 Agent가 브라우저와 파일, 앱까지 직접 다루게 될수록 권한 관리가 AI 성능만큼 중요한 UX가 될 수 있음.

편리함 때문에 통제권까지 포기할 필요는 없기 때문임.

“내 컴퓨터를 사용하는 AI”라고 하면 모든 계산도 내 PC에서 직접 처리한다고 생각하기 쉬움.

그런데 무거운 AI 작업까지 전부 로컬에서 처리하면 성능 문제도 생기고, 위험한 작업 환경까지 사용자 컴퓨터에 만들게 될 수 있음.

DAPPOS는 Bubble Personal에서 heavy compute와 risky operations를 Bubble Cloud 쪽에 유지하고, 처리된 결과를 local workspace로 돌려보내는 구조​를 설명합니다.

즉 역할을 나누는 것임.

내 PC
→ 개인 파일과 실제 사용자 환경

Bubble Cloud
→ 무거운 계산과 격리가 필요한 작업

그리고 필요한 결과만 다시 로컬로 전달함.

Local의 개인화 + Cloud의 연산 능력을 동시에 활용하려는 구조라고 이해하면 쉬움.

Personal AI라고 하면 흔히 “내 취향을 기억해주는 AI”부터 생각함.

그것도 중요하지만 실제 생산성을 바꾸려면 한 단계가 더 필요함.

내 파일을 다루고, 필요한 웹사이트에서 작업하고, 여러 앱과 일정을 연결하고, 결과물을 다시 내가 사용하는 공간에 남길 수 있어야 하기 때문임.

DAPPOS의 Bubble Personal은 그래서 local files, browsers, apps, schedules를 작업 범위로 두면서, 로컬에서는 명시적으로 허용된 행동만 실행하고 무거운 연산이나 위험도가 높은 작업은 Bubble Cloud로 분리하는 방향을 택했습니다.

결국 Personal AI의 다음 단계는

“나를 기억하는 AI”에서
“내가 일하는 환경 안에서 실제 일을 해주는 AI”로 가는 것일 수 있음.

xBubble과 Web3 AI OS가 OS라는 표현을 쓰는 이유를 실사용 관점에서 이해할 수 있는 부분임.

AI에게 “이거 분석해줘”라고 말해도 실제 요청은 완전히 다를 수 있음.

차트 분석일 수도 있고, 사진 수정일 수도 있고, 영상 제작일 수도 있음. 같은 자연어 입력창을 사용한다고 해서 뒤에서 같은 작업 방식으로 처리하면 안 되는 이유임.

DAPPOS는 2026년 5월 xBubble의 Multimodal Router를 업그레이드해 실행이 시작되기 전에 사용자의 Intent를 식별하도록 했다고 밝혔습니다. 이후 요청 종류에 맞춰 서로 다른 작업 영역을 분리하는 구조입니다.

즉 흐름은 단순히

Prompt → AI 답변

이 아니라,

Prompt → 요청 종류 판단 → 맞는 작업 경로 선택 → 실행

에 가까움.

여러 능력을 하나의 AI 안에 넣으려면 “무엇을 할 수 있느냐”만큼 언제 어떤 능력을 꺼낼 것인가가 중요함.

전문 AI를 많이 만든다고 무조건 시스템이 똑똑해지는 건 아님.

중요한 건 맞는 요청에 맞는 전문 작업법을 연결하는 것임.

DAPPOS는 Multimodal Router 업데이트에서 financial analysis와 photo editing처럼 성격이 다른 작업들을 실행 전에 구분하도록 개선했다고 설명했습니다. 같은 업데이트에는 narrative video 작업을 위한 short-drama SOP 개선도 포함됐습니다.

쉽게 말하면 전문가는 많아도 접수창구가 엉망이면 소용없다는 것임.

사진 요청은 사진 작업 경로로,
시장 분석은 분석 경로로,
영상 요청은 영상 제작 경로로 보내야 함.

xBubble의 Router는 바로 이 첫 번째 교통정리를 담당하는 기술이라고 볼 수 있음.

멀티모달이라고 하면 보통 텍스트와 이미지를 함께 이해하는 AI부터 떠올림.

하지만 실제 Agent 시스템에서는 입력을 이해하는 것만으로 부족함.

사진을 받았다면 이미지 처리용 workflow를 호출해야 하고, 시장 질문이라면 데이터 분석용 SOP와 도구를 사용해야 함. 즉 입력 종류뿐 아니라 요청의 목적까지 실행 경로와 연결해야 함.

DAPPOS가 공개한 Multimodal Router 업데이트 역시 실행 이전에 user intent를 식별하고 서로 다른 작업 영역을 분리하는 데 초점이 있습니다.

그래서 여기서 Multimodal의 핵심은

“여러 데이터를 이해함” + “그 데이터에 맞는 작업 시스템으로 보냄”

이라고 보면 이해하기 쉬움.

단순 인식 기술에서 Agent orchestration으로 넘어가는 부분임.

특정 작업에 특화된 SOP가 좋은 성능을 냈다고 해도 모든 질문에 그 SOP를 사용하면 오히려 결과가 나빠질 수 있음.

예를 들어 영상 제작에 최적화된 절차를 시장 리서치에 적용할 이유가 없음.

DAPPOS 공식 문서는 SOP를 시스템에 추가하기 전에 Bubble Engine이 해당 SOP의 applicable scope, 즉 적용 가능한 범위도 정의한다고 설명합니다.

이게 SOP Scope Control의 중요한 부분임.

SOP는 단순히

“이렇게 하면 좋은 결과가 나온다”

만 저장하는 게 아니라,

“이 방식은 어떤 상황에서 사용해야 하는가”

까지 함께 다뤄야 함.

전문 Agent 시스템에서 능력만큼 중요한 게 능력의 사용 범위인 이유임.

어떤 일을 전문적으로 처리하는 SOP가 있다고 생각해보자.

이름만 보면 무조건 그걸 선택하는 게 좋아 보임.

그런데 사용자 요청이 그 SOP의 전문 영역과 살짝만 다르면 범용적인 작업법이 오히려 더 안정적일 수도 있음.

DAPPOS 공식 문서는 Scope를 정의하는 목적을 Bubble Pilot이 specialized SOP가 general SOP보다 더 좋은 결과를 낼 가능성이 있을 때만 해당 전문 SOP를 추천하도록 하기 위한 것이라고 설명합니다.

이 부분이 꽤 중요함.

전문 SOP 존재 → 무조건 호출

이 아니라,

요청 분석 → 적용 범위 확인 → 전문 SOP가 더 적합한지 판단

이라는 구조임.

AI 시스템에서 전문화가 많아질수록 선택 알고리즘의 중요성도 같이 커지는 이유임.

xBubble 구조를 보면 Bubble Engine과 Bubble Pilot이 함께 등장해서 헷갈릴 수 있음.

하지만 역할은 다름.

DAPPOS 공식 문서상 Bubble Engine은 SOP를 훈련하고 개선하는 역할, Bubble Pilot은 준비된 SOP 중 적절한 것을 ​선택하고 실행하는 역할을 담당합니다. SOP 자체는 특정 작업을 수행하기 위한 패키징된 task-specific workflow임.

쉽게 나누면,

Bubble Engine
→ 작업법을 만들고 개선함

SOP
→ 검증된 작업법

Bubble Pilot
→ 지금 어떤 작업법을 사용할지 고르고 돌림

이라는 구조임.

하나의 거대한 AI에게 모든 책임을 몰아주는 대신 학습·작업법·실행 선택을 분리한 설계라고 이해하면 쉬움.