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를 단순히

“잘 만든 프롬프트”

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

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

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