멀티모달이라고 하면 보통 텍스트와 이미지를 함께 이해하는 AI부터 떠올림.

하지만 실제 Agent 시스템에서는 입력을 이해하는 것만으로 부족함.

사진을 받았다면 이미지 처리용 workflow를 호출해야 하고, 시장 질문이라면 데이터 분석용 SOP와 도구를 사용해야 함. 즉 입력 종류뿐 아니라 요청의 목적까지 실행 경로와 연결해야 함.

DAPPOS가 공개한 Multimodal Router 업데이트 역시 실행 이전에 user intent를 식별하고 서로 다른 작업 영역을 분리하는 데 초점이 있습니다.

그래서 여기서 Multimodal의 핵심은

“여러 데이터를 이해함” + “그 데이터에 맞는 작업 시스템으로 보냄”

이라고 보면 이해하기 쉬움.

단순 인식 기술에서 Agent orchestration으로 넘어가는 부분임.

xBubble 구조를 보면 Bubble Engine과 Bubble Pilot이 함께 등장해서 헷갈릴 수 있음.

하지만 역할은 다름.

DAPPOS 공식 문서상 Bubble Engine은 SOP를 훈련하고 개선하는 역할, Bubble Pilot은 준비된 SOP 중 적절한 것을 ​선택하고 실행하는 역할을 담당합니다. SOP 자체는 특정 작업을 수행하기 위한 패키징된 task-specific workflow임.

쉽게 나누면,

Bubble Engine
→ 작업법을 만들고 개선함

SOP
→ 검증된 작업법

Bubble Pilot
→ 지금 어떤 작업법을 사용할지 고르고 돌림

이라는 구조임.

하나의 거대한 AI에게 모든 책임을 몰아주는 대신 학습·작업법·실행 선택을 분리한 설계라고 이해하면 쉬움.

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

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

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

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

결과 하나를 보고

“잘됐네”

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

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가 실제 수요에서 빈 공간을 찾아 확장될 수 있는 구조임.