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에서 중요한 것은 지식의 양만 아니라 지식이 얼마나 빨리 살아 움직이느냐일 수 있음.

DAPPOS의 Intelligence Layer에서 MAF와 Bubble Engine은 같이 등장하지만 역할은 같지 않음.

공식 문서상 MAF는 여러 전문 Agent와 도구를 조정해 실제 문제를 처리하는 orchestration 쪽이고, Bubble Engine은 새로운 정보를 받아들이며 intelligence 자체를 적응시키는 learning core에 가깝습니다.

쉽게 보면

MAF
→ 지금 이 문제를 어떻게 풀 것인가

Bubble Engine
→ 앞으로 비슷한 문제를 더 잘 이해하려면 무엇을 배워야 하는가

라는 차이가 있음.

이 구조가 재미있는 이유는 모든 기능을 거대한 하나의 AI 안에 몰아넣지 않기 때문임.

실행하는 시스템과 학습하는 시스템을 역할별로 분리함.

그래서 DAPPOS의 Web3 AI OS는 Agent 수만 많은 구조가 아니라, Agent 뒤에서 지식을 계속 업데이트하는 별도의 adaptive layer를 두고 있음.

Web3에서는 중요한 정보가 공식 문서에서만 나오는 게 아님.

프로젝트 발표, 개발 상황, 파트너십 힌트, 커뮤니티 반응처럼 시장이 중요하게 보는 정보가 X 같은 실시간 채널에서 먼저 움직일 때가 있음.

DAPPOS 공식 문서는 Bubble Engine이 X와 Binance Square 같은 실시간 소스에서 새로운 인사이트를 지속적으로 받아들인다고 설명합니다.

여기서 핵심은 단순히 “AI가 X 검색을 한다”는 것이 아님.

Bubble Engine의 설계상 이런 실시간 정보가 Web3 intelligence를 계속 적응시키는 입력 신호로 사용된다는 점임.

즉,

공식 자료만 보는 AI
vs
실시간 시장 신호까지 계속 추적하는 AI

사이에 정보 반응 속도 차이가 생길 수 있음.

빠르게 변하는 Web3에서는 이 차이가 꽤 중요함.

AI가 최신 웹페이지를 검색하면 최신 정보를 가져올 수 있음.

그런데 매번 정보를 읽는 것과 새로운 Web3 개념을 시스템의 지식으로 흡수하는 것은 조금 다른 문제임.

DAPPOS는 Bubble Engine을 단순 retrieval system이 아니라 continuous RL 기반의 adaptive learning core로 설명하고, 실시간 데이터와 사용자 기여 인사이트를 지속적으로 통합하는 구조를 제시합니다.

쉽게 말하면,

검색
→ 지금 질문에 필요한 정보를 가져옴

적응
→ 새로 등장한 패턴이나 개념을 이후 판단에도 활용할 수 있도록 시스템에 반영함

이라는 차이로 이해할 수 있음.

DAPPOS가 Bubble Engine을 따로 둔 이유도 여기에 있음.

Web3에서 새 정보는 ‘찾아볼 자료’인 동시에 ‘AI가 새로 배워야 할 지식’이 될 수 있기 때문임.

AI가 모든 Web3 사건을 가장 먼저 발견하기는 어려움.

특정 커뮤니티에서 새롭게 등장한 개념이나 현장의 정보를 실제 사용자가 먼저 알고 있을 수도 있음.

DAPPOS는 이를 위해 BubbleUp Tasks라는 지식 기여 방식을 문서화했습니다.

공식 가이드에서는 사용자가 X나 Binance Square에 게시물을 올리고 #BubbleUp 태그를 포함하면 해당 정보가 Bubble Engine의 knowledge base에 들어갈 수 있는 ingestion 후보가 된다고 설명합니다.

즉 지식 흐름이

DAPPOS → 사용자

한 방향만 있는 것이 아님.

사용자 → Bubble Engine

방향도 존재함.

Web3처럼 정보가 여러 커뮤니티에 분산된 환경에서는 이런 community-assisted intelligence 구조가 꽤 흥미로운 기술적 특징임.

보통 프로젝트 해시태그는 홍보나 커뮤니티 참여용으로 생각하기 쉬움.

그런데 DAPPOS의 #BubbleUp은 공식 문서상 조금 다른 역할도 갖고 있음.

사용자가 X 또는 Binance Square에 Web3 관련 정보를 게시하면서 #BubbleUp을 포함하면 Bubble Engine이 받아들일 수 있는 지식 후보가 되는 방식입니다. DAPPOS는 이를 새로운 Web3-specific data를 Engine에 공급하는 과정으로 설명합니다.

게시물 작성
→ #BubbleUp 표시
→ ingestion 후보
→ 검증
→ Engine에 반영 가능

이라는 흐름임.

이 관점에서 보면 해시태그가 단순 분류 태그가 아니라 AI 지식 수집 파이프라인의 입구 역할도 하는 셈임.

소셜 데이터를 AI 학습·적응 시스템과 연결하는 방식이라는 점이 핵심임.

누구나 정보를 넣을 수 있는 AI라면 바로 문제가 생김.

틀린 정보나 루머를 대량으로 넣으면 AI가 오히려 망가질 수 있기 때문임.

그래서 DAPPOS가 설명하는 BubbleUp 구조에는 중요한 단계가 하나 있음.

Verification임.

DAPPOS 공식 Introduction에서는 사용자가 새로운 개념을 Bubble Task를 통해 공급할 수 있지만, 검증된 뒤 시스템에 통합된다고 명시합니다.

즉 구조는

User Contribution → 바로 기억

이 아니라

User Contribution → Verification → Integration

임.

이 단계가 중요한 이유는 Community Intelligence와 misinformation 문제가 항상 같이 따라오기 때문임.

누구나 지식을 추가할 수 있게 만드는 것보다 무엇을 받아들일지를 결정하는 과정이 더 어려울 수도 있음.

커뮤니티가 AI에 지식을 공급할 수 있다고 해도 선의만 기대해서는 품질을 유지하기 어려움.

DAPPOS가 문서화한 Bubble Task Platform은 그래서 incentive mechanism과 정보 품질에 대한 reward/punishment 구조를 함께 설명합니다.

공식 문서 내용에 따르면 고품질 정보에는 보상을 제공하고, 잘못된 정보에는 불이익을 주는 방식을 채택하고 있습니다. 현재 Bubble Task Platform은 internal beta 단계라고 명시돼 있습니다.

기술적으로 보면 꽤 재미있는 구조임.

AI 지식 품질 관리에

검증 시스템

뿐 아니라

경제적 인센티브

까지 붙이는 것임.

Web3의 incentive design을 AI knowledge acquisition에 적용하려는 사례라고 볼 수 있음.

Web3에는 코드와 숫자로 명확하게 표현되는 정보도 있지만 그렇지 않은 정보도 많음.

어떤 파트너십 신호를 시장이 중요하게 보는지, 특정 커뮤니티 이벤트가 왜 큰 반응을 일으키는지처럼 시장 참여자들이 경험적으로 중요하게 판단하는 신호도 있음.

DAPPOS는 BubbleUp 설명에서 사용자가 제공하는 fresh Web3-specific data를 활용해 Bubble Engine이 빠르게 움직이고 불투명한 Web3 환경 및 새로운 개념에 더 잘 적응하도록 하는 목적을 제시합니다.

즉 AI가 공식 백서만 읽는 게 아니라,

온체인 데이터

실시간 소셜 신호
사용자 기여 지식

을 함께 활용하려는 구조임.

Web3 vertical AI가 범용 AI와 다른 방향을 택하는 이유를 보여주는 부분임.

지금까지 내용을 연결하면 Bubble Engine의 지식 업데이트 구조가 보임.

① X·Binance Square 같은 실시간 소스에서 새로운 신호를 받음
② BubbleUp을 통해 사용자도 새로운 Web3 지식을 공급할 수 있음
③ 사용자 정보는 검증 과정을 거쳐 통합됨
④ Bubble Engine은 continuous RL 기반 adaptive core로 새로운 지식에 계속 적응함.

즉 개념적으로는

Real-Time Data
↓
Community Knowledge
↓
Verification
↓
Bubble Engine
↓
Adaptive Web3 Intelligence

라는 하나의 loop로 볼 수 있음.

중요한 건 AI 모델을 한 번 잘 만들어 놓는 것만이 아님.

Web3 자체가 계속 변한다면 AI가 지식을 받아들이는 시스템도 계속 움직여야 함.

DAPPOS의 Continuous RL과 BubbleUp은 바로 그 문제를 해결하려는 기술 구조임.

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 workflow 하나가 그럴듯하게 만들어졌다고 바로 사용자에게 배포하면 문제가 생길 수 있음.

한두 번은 잘되는데 입력이 조금만 달라져도 실패하는 작업법일 수 있기 때문임.

Bubble Engine은 solution variant를 만든 뒤 test harness를 구축해 후보들을 시험하는 과정을 거친다고 공식 문서에서 설명합니다.

Test Harness를 쉽게 표현하면 AI 작업법을 반복해서 시험할 수 있도록 만든 자동 시험장에 가까움.

결과 하나를 보고

“잘됐네”

라고 판단하는 게 아니라 여러 사례를 집어넣고 결과를 비교할 수 있도록 만드는 것임.

AI Agent가 실사용 단계로 갈수록 생성 능력만큼 자동 평가 인프라가 중요해지는 이유임.

어떤 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 시스템이 안정적으로 작동하려면 ‘잘 만드는 기술’과 함께 잘했는지 판정하는 기술도 필요하다는 의미임.