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

“이 프로젝트 괜찮아”

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

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

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가 무엇을 말했는지만큼 왜 그렇게 말했는지를 다시 따라갈 수 있게 만드는 것이 중요함.