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에게 모든 책임을 몰아주는 대신 학습·작업법·실행 선택을 분리한 설계라고 이해하면 쉬움.

사용자가 긴 프롬프트를 쓰지 않는다면 누군가는 빠진 정보를 대신 처리해야 함.

예를 들어 사용자가

“이 사진 좀 더 자연스럽게 수정해줘”

정도만 말했다고 해보자.

어떤 작업 유형인지, 어떤 SOP가 맞는지, 어떤 도구를 써야 하는지를 사용자가 하나씩 지정하지 않음.

DAPPOS는 Low-Prompt 구조에서 사용자는 목표를 제시하고, Bubble Pilot이 적절한 SOP를 사용하는 방향을 설명합니다. 여기에 Multimodal Router의 intent 식별과 SOP Scope Control이 결합됩니다.

즉 사용자 프롬프트를 짧게 만들려면 뒤에서는

분류 → 범위 확인 → SOP 선택 → 실행

이 더 정확해져야 함.

Low-Prompt가 단순 UI 기능이 아니라 라우팅 기술과 연결되는 이유임.

전문 Agent는 특정 분야에서 강함.

하지만 전문성이 강하다고 해서 모든 상황에서 사용하는 게 좋은 것은 아님.

DAPPOS가 SOP를 등록하기 전에 적용 범위를 정의하고, specialized SOP가 general SOP보다 더 적합할 가능성이 있을 때 추천하도록 설계한 것도 이 문제와 연결됩니다.

여기서 하나의 기술적 의미를 추론할 수 있음.

Scope Control은 단순 분류 기능뿐 아니라 전문 작업법이 자신의 영역 밖으로 잘못 확장되는 것을 줄이는 일종의 guardrail 역할도 할 수 있음. 이는 공식 문서의 Scope 설계 목적에서 자연스럽게 따라오는 해석임.

AI가 더 많은 능력을 갖게 될수록

“무엇을 할 줄 아는가”보다
“무엇을 언제 하지 말아야 하는가”

도 중요해짐.

처음에 작업법이 3개뿐이라면 무엇을 사용할지 고르기 어렵지 않음.

그런데 분석, 이미지, 영상, 코딩 등 서로 다른 분야의 전문 SOP가 계속 늘어난다면 이야기가 달라짐.

DAPPOS는 xBubble에서 Bubble Engine이 task-specific SOP를 훈련·개선하고, Bubble Pilot이 이를 선택해 실행하는 구조를 사용합니다. 동시에 2026년 5월에는 실행 전 intent를 분류하는 Multimodal Router와 SOP Scope Control을 강화했습니다.

여기서 중요한 시스템 설계 문제가 생김.

능력의 개수가 늘어나는 것과
그 능력을 정확히 찾아 쓰는 것은 별개의 문제임.

전문 SOP가 많아질수록 Router와 Scope Control이 병목이 될 수도 있는 이유임.

좋은 AI OS는 기능 목록만 많은 게 아니라 맞는 기능을 자동으로 골라야 함.

리서치 AI, 이미지 AI, 영상 AI가 각각 따로 있다면 사용자가 어떤 서비스를 열지 직접 선택하면 됨.

하지만 DAPPOS가 말하는 Web3 AI OS처럼 하나의 시스템에서 다양한 작업을 처리하려면 상황이 달라짐.

사용자는 목표만 말하고, 시스템이 요청을 이해한 뒤 맞는 작업 경로를 결정해야 함.

DAPPOS는 이를 위해 xBubble에서 실행 전 Intent를 식별하는 Multimodal Router, SOP별 applicable scope, 그리고 적절한 SOP를 선택·실행하는 Bubble Pilot 구조를 사용하고 있습니다.

그래서 이번 시리즈를 한 줄로 정리하면 이거임.

AI가 많은 능력을 갖는 것이 1단계라면,
사용자가 설명하지 않아도 그중 맞는 능력을 찾아내는 것이 2단계임.

Multimodal Router와 SOP Scope Control은 xBubble이 Low-Prompt AI로 가기 위해 필요한 ‘능력 선택 계층’​이라고 이해하면 가장 쉬움.

일반적인 지식은 며칠 늦게 알아도 큰 문제가 없는 경우가 많음.

하지만 Web3에서는 상황이 다름.

새로운 프로토콜이 등장하고, 프로젝트 관계가 바뀌고, 커뮤니티 분위기와 시장의 관심이 빠르게 이동함. 그래서 한 번 학습한 지식을 오래 들고 있는 AI만으로는 대응하기 어려울 수 있음.

DAPPOS는 이 문제를 위해 Intelligence Layer 내부에 Bubble Engine이라는 Web3 특화 adaptive learning core를 두고 있습니다. 공식 문서에서는 Bubble Engine이 continuous reinforcement learning(RL)을 기반으로 새로운 Web3 정보에 지속적으로 적응한다고 설명합니다.

즉 핵심은

한 번 학습 → 계속 사용

이 아니라

새로운 신호 → 학습·적응 → 다시 활용

이라는 구조임.

Web3 AI에서 중요한 것은 지식의 양만 아니라 지식이 얼마나 빨리 살아 움직이느냐일 수 있음.

AI 결과가 별로면 보통 더 좋은 모델로 바꾸는 것부터 생각함.

그런데 실제 작업에서는 모델 하나보다 어떤 도구를 붙이고, 어떤 순서로 사용하고, 어떤 단계에서 결과를 검사하는지가 품질을 크게 좌우할 수 있음.

DAPPOS의 Bubble Engine은 그래서 특정 작업을 받았을 때 답변 하나를 바로 만드는 대신, 여러 AI 솔루션 후보를 만들어 비교하는 구조를 사용합니다.

공식 설명에서는 Bubble Engine을 일종의 solution factory로 표현하며, AI coding agent를 이용해 여러 solution variant를 생성한다고 설명합니다.

즉 경쟁 대상이

모델 A vs 모델 B

정도가 아니라

모델 + 도구 + 작업 순서를 포함한 전체 실행 방법이 되는 것임.

DAPPOS가 Bubble Engine을 별도의 기술 계층으로 두는 이유를 이해하기 좋은 부분임.

사람도 새로운 업무를 자동화할 때 첫 번째 방법이 항상 최선이라는 보장은 없음.

A 방식은 빠르지만 정확도가 낮을 수 있고, B 방식은 느리지만 결과가 더 안정적일 수도 있음.

Bubble Engine은 비슷하게 특정 task를 위한 여러 solution variant를 생성하는 방식을 사용합니다. 공식 문서에서는 이 과정에 AI coding agents가 활용된다고 설명합니다.

예를 들어 같은 리서치 작업이라도 개념적으로는

검색 → 정리 → 작성

이라는 단순 흐름과

검색 → 교차검증 → 추가검색 → 정리 → 최종검사

같은 흐름이 경쟁할 수 있음.

어떤 방식이 실제로 더 좋은지는 미리 단정하기 어려움.

그래서 Bubble Engine은 하나의 작업법을 바로 정답으로 채택하기보다 후보를 만들어 경쟁시키는 구조에 가까움.

AI가 결과물을 생성하는 게 아니라 AI의 ‘일하는 방법’을 생성한다는 점이 재미있는 기술임.

어떤 AI 모델이 제일 좋냐는 질문을 자주 보게 됨.

그런데 실제 업무에서는 하나의 모델이 모든 단계를 가장 잘할 필요가 없음.

검색에 강한 도구가 따로 있을 수 있고, 이미지 작업에 적합한 모델이 따로 있을 수 있으며, 결과 검증에는 또 다른 방식이 유리할 수 있음.

DAPPOS 공식 문서상 Bubble Engine은 solution을 만들면서 candidate models와 tools를 조합합니다.

즉 탐색 대상이

Best Model

하나가 아니라

Model A + Tool B + Model C + Workflow D

같은 조합이 될 수 있다는 것임.

AI 기술이 발전할수록 모델 개수도, 도구 개수도 늘어남.

그때 중요한 기술은 모든 기능을 직접 사용하는 능력보다 어떤 조합이 특정 task에서 가장 잘 작동하는지를 찾아내는 능력일 수 있음.

AI 결과를 사람이 보면 쉽게 이런 말을 하게 됨.

“이쪽이 조금 더 좋아 보이는데”

하지만 자동으로 수많은 solution을 비교하려면 이런 감각적인 평가만으로는 부족함.

DAPPOS는 Bubble Engine이 후보 solution의 결과를 task examples와 quality criteria를 기준으로 평가한다고 설명합니다.

여기서 중요한 건 먼저

“이 작업에서 좋은 결과란 무엇인가”

라는 기준을 세우는 것임.

그래야 서로 다른 모델과 도구 조합을 같은 조건에서 비교할 수 있음.

즉 Bubble Engine의 역할에는 단순 생성뿐 아니라

생성 → 테스트 → 평가

가 함께 들어감.

AI Agent 시스템이 안정적으로 작동하려면 ‘잘 만드는 기술’과 함께 잘했는지 판정하는 기술도 필요하다는 의미임.

여기까지 흐름을 연결하면 Bubble Engine이 SOP를 만드는 과정이 조금 더 선명해짐.

특정 task를 잡고,

여러 solution variant를 만들고,

test harness에서 시험하고,

모델과 도구 조합을 비교하고,

quality criteria를 기준으로 평가함.

그리고 충분히 재사용 가능한지까지 테스트한 뒤 가장 강한 실행 경로를 SOP로 패키징합니다. 공식 문서도 SOP를 특정 종류의 task를 위한 reusable solution으로 설명하고 있습니다.

그래서 xBubble의 SOP를 단순히

“잘 만든 프롬프트”

라고 보면 구조를 너무 작게 보는 셈임.

그 안에는 어떤 모델과 도구를 어떤 방식으로 사용할 것인지에 대한 검증된 실행 경로가 들어갈 수 있음.

SOP가 많아져도 세상의 모든 요청을 미리 준비할 수는 없음.

처음 등장하는 업무나 아주 특이한 요청은 기존 SOP와 맞지 않을 수 있음.

이때 잘못된 전문 SOP를 억지로 적용하는 것보다 다른 경로가 필요함.

DAPPOS 공식 문서에 따르면 Bubble Pilot은 사용자의 task를 확인한 뒤 적절한 SOP가 있으면 해당 경로를 사용하지만, 맞는 SOP가 없으면 general-purpose agent로 fallback할 수 있습니다.

즉 시스템이

전문 SOP 또는 실패

두 가지로만 구성된 게 아님.

Specialized SOP
↓ 없으면
General Agent

라는 안전망이 존재함.

전문화된 AI와 범용 AI가 경쟁하는 게 아니라 서로 빈 공간을 메우는 구조라는 점이 핵심임.

이번 시리즈를 하나로 연결하면 Bubble Engine의 기술 구조가 보임.

Task
↓
Solution Variants 생성
↓
Test Harness
↓
Model + Tool 조합
↓
Quality Evaluation
↓
Versatility Test
↓
SOP
↓
Bubble Pilot 실행
↓
Fallback Pattern
↓
새로운 SOP 후보

DAPPOS는 Bubble Engine을 AI solution을 만드는 solution factory, Bubble Pilot을 이를 실제 요청에 사용하는 runtime dispatch layer로 설명합니다.

여기서 핵심은 더 강한 LLM 하나를 만드는 경쟁과 조금 다름.

이미 존재하는 여러 모델과 도구를 특정 작업에 가장 잘 맞는 실행 시스템으로 조립하고, 테스트하고, 다시 재사용하는 것​임.

그래서 xBubble의 기술적 경쟁력은 모델 숫자만으로 설명하기 어려움.

어떤 AI를 가지고 있느냐보다, 그 AI들을 어떻게 일하게 만드느냐.

Bubble Engine이 해결하려는 문제가 바로 이쪽임.

AI가 인터넷에서 100개의 자료를 찾았다고 해서 답변 품질이 자동으로 좋아지는 건 아님.

같은 내용을 복사한 기사도 있을 수 있고, 질문과 거의 상관없는 자료도 섞일 수 있으며, Web3에서는 소셜 데이터와 온체인 데이터가 서로 다른 이야기를 할 수도 있음.

DAPPOS의 Bubble Engine은 그래서 검색 결과를 그대로 생성 모델에 넣는 방식이 아니라 provenance-first context layer를 구성하도록 설계됐습니다. 웹, 내부 문서, 온체인·오프체인 신호를 수집한 뒤 여러 단계로 정제하는 구조임.

쉽게 표현하면

많이 찾기 → 바로 답변

이 아니라

찾기 → 걸러내기 → 비교하기 → 증거 구성 → 답변

에 가까움.

AI 검색에서 진짜 기술은 정보를 찾는 것뿐 아니라 무엇을 믿고 남길지 결정하는 과정에도 있음.