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

특정 예제 하나에서 1등한 AI workflow가 있다고 해도 바로 재사용 가능한 작업법이라고 보기는 어려움.

그 예제에만 우연히 잘 맞았을 수도 있기 때문임.

DAPPOS 공식 문서에서는 여러 후보 중 강한 실행 경로를 찾은 뒤에도 Bubble Engine이 versatility를 테스트한 후 SOP로 만든다고 설명합니다.

이 부분이 중요함.

SOP는 특정 프롬프트 하나를 해결한 기록이 아니라, 비슷한 종류의 요청에 다시 사용할 수 있어야 하는 reusable solution이기 때문임.

쉽게 말하면

한 문제 잘 풀기
→ 데모

비슷한 문제도 계속 잘 풀기
→ SOP 후보

라고 볼 수 있음.

AI workflow를 일회성 성공에서 재사용 가능한 시스템으로 바꾸는 단계임.

여기까지 흐름을 연결하면 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가 경쟁하는 게 아니라 서로 빈 공간을 메우는 구조라는 점이 핵심임.

General Agent로 fallback했다고 해서 그 요청이 그대로 끝나는 것은 아님.

비슷한 요청이 계속 나타난다면 중요한 신호가 됨.

DAPPOS 공식 문서는 반복적으로 발생하는 fallback 요청이 Bubble Engine이 다음에 무엇을 만들지 결정하는 데 활용되며, 반복 패턴은 새로운 SOP 후보가 된다​고 설명합니다.

이 구조가 재미있는 이유는 새로운 기능을 만드는 기준이 단순 개발팀의 예상만이 아니기 때문임.

사용자들이 실제로 계속 요청하는데 전문 SOP가 없는 영역

↓

반복되는 fallback pattern

↓

새로운 SOP 후보

라는 흐름이 만들어짐.

즉 Bubble Engine의 solution library가 실제 수요에서 빈 공간을 찾아 확장될 수 있는 구조임.

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

검색에는 서로 다른 장점이 있음.

예를 들어 사용자가 정확한 프로젝트명이나 토큰명을 입력했다면 키워드가 중요함.

반대로 표현은 다르지만 의미가 비슷한 자료를 찾으려면 단순 문자열 검색만으로 부족할 수 있음.

DAPPOS의 Bubble Engine은 그래서 Dense Retrieval과 Sparse Retrieval을 결합한 Hybrid Retriever를 사용한다고 설명합니다. Dense는 의미적 유사성을 찾는 데 강하고, Sparse는 키워드 기반 매칭에 유리한 방식임.

즉

Semantic Search
+
Keyword Search

를 하나만 선택하지 않고 함께 활용함.

Web3처럼 프로젝트 이름, 티커, 프로토콜 용어와 자연어 설명이 뒤섞인 환경에서는 한 종류의 검색 방식만 고집하지 않는 것이 중요한 이유임.

“이 프로젝트 괜찮아”

라는 짧은 질문 하나에도 필요한 정보는 여러 종류임.

프로젝트 공식 정보도 필요하고, 시장 반응도 봐야 하고, 온체인 데이터가 중요할 수도 있음.

Bubble Engine의 Contextual RAG는 domain-specific routing을 사용해 sub-query를 적절한 정보 영역으로 분배하는 구조를 설명합니다.

쉽게 보면 하나의 거대한 검색창에서 무작정 자료를 긁는 게 아니라,

프로젝트 정보
→ 관련 데이터 영역

시장 분위기
→ 소셜·시장 영역

온체인 상태
→ 블록체인 데이터 영역

처럼 질문을 나눠 처리하는 개념임.

검색 기술도 Agent와 비슷함.

질문 하나를 어디에 물어봐야 하는지 먼저 알아야 좋은 답을 얻을 수 있음.

뉴스 검색을 하다 보면 여러 사이트가 사실상 같은 내용을 반복해서 올리는 경우가 많음.

AI 입장에서는 이걸 그대로 넣으면 문제가 생길 수 있음.

같은 주장 10개가 복제돼 있다는 이유만으로 마치 서로 다른 10개의 근거가 있는 것처럼 보일 수 있기 때문임.

DAPPOS의 공식 기술 설명에서는 Contextual RAG가 검색 결과를 처리하면서 redundant results를 deduplicate하는 단계를 거친다고 설명합니다.

쉽게 말하면

기사 10개 = 근거 10개

라고 단순 계산하지 않는 것임.

중복된 정보를 걷어내야 실제로 서로 다른 근거가 얼마나 존재하는지 더 명확하게 볼 수 있음.

특히 루머가 빠르게 복제되는 Web3에서는 꽤 중요한 과정임.

검색 엔진에서 위에 나온 자료가 항상 최종 답변에 가장 중요한 자료인 것은 아님.

검색 단계에서는 관련 있어 보였지만 질문을 자세히 보면 다른 자료가 더 직접적인 근거일 수도 있음.

DAPPOS는 Hybrid Retriever로 가져온 결과들을 정리한 뒤 Cross-Encoder를 이용해 relevance 기준으로 다시 reranking한다고 설명합니다.

흐름을 단순화하면

1차 검색
↓
후보 자료 확보
↓
질문과 자료를 다시 비교
↓
중요도 재정렬

임.

즉 Retrieval에서 끝나는 것이 아니라 검색된 자료를 다시 심사하는 단계가 하나 더 존재하는 것임.

좋은 AI 검색 시스템은 자료를 많이 찾는 것보다 찾은 자료 중 무엇을 위에 놓느냐도 중요함.

AI에게 자료를 많이 주면 무조건 좋아질 것 같지만 DAPPOS의 접근 방식은 조금 다름.

Bubble Engine은 검색된 자료를 정제한 뒤 질문에 필요한 minimal sufficient evidence pack, 즉 최소한으로 충분한 증거 묶음을 구성하도록 설명돼 있습니다.

핵심은 minimal과 sufficient가 같이 붙는다는 것임.

너무 적어서 근거가 부족하면 안 되고,

그렇다고 관련 없는 정보까지 전부 넣을 필요도 없음.

결국 목표는

“얼마나 많은 자료를 넣었나”가 아니라
“답을 뒷받침하는 데 필요한 증거가 충분히 들어갔나”

에 가까움.

AI가 사용할 Context 자체를 하나의 최종 결과물처럼 정제하는 단계임.

AI 답변에서 가장 위험한 것 중 하나가 그럴듯한 출처를 붙이는 것임.

본문은 자연스럽지만 실제 자료를 열어보면 해당 내용이 없거나, 아예 존재하지 않는 근거를 인용할 수도 있음.

DAPPOS는 Bubble Engine의 생성 과정을 citation-locked 방식으로 설명합니다. 공식 자료에 따르면 근거가 제한된 경우에는 fallback을 두면서, 확보된 Evidence를 바탕으로 inline reference를 생성하도록 설계돼 있습니다.

즉 앞 단계에서 Evidence Pack을 만드는 이유가 여기서 연결됨.

Evidence
↓
Answer
↓
Citation

이 서로 따로 움직이는 게 아니라 연결되는 구조임.

AI가 무엇을 말했는지만큼 왜 그렇게 말했는지를 다시 따라갈 수 있게 만드는 것이 중요함.