리서치 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 검색에서 진짜 기술은 정보를 찾는 것뿐 아니라 무엇을 믿고 남길지 결정하는 과정에도 있음.