DAPPOS 입력창에는 모드뿐 아니라 Tag도 있음. 모드가 AI가 어떤 방향으로 일할지를 정한다면, 태그는 특정 기능이나 처리 성향을 추가하는 개념에 가까움.

공식 Quick Start에서 Bubble Tag는 더 지능적이고 적응적인 결과를 위해 premium Bubble Engine을 사용하도록 하는 옵션으로 설명됩니다.

Bubble Engine은 DAPPOS Intelligence Layer에서 지속적인 학습, Contextual RAG, Compound Memory 등을 담당하는 적응형 학습 코어임.

따라서 Bubble은 질문 문장에 단어 하나를 더 붙이는 게 아니라 같은 요청을 Bubble Engine의 강화된 처리 흐름에 태우는 선택지라고 보는 게 가까움.

Web3 프로젝트의 마케팅 콘텐츠를 만들려면 문장만 예쁘게 쓰는 것보다 프로젝트 구조·최근 이슈·사용자 관심사까지 이해해야 할 때가 많음.

DAPPOS Quick Start에는 프로젝트 팀과 KOL의 마케팅 콘텐츠 제작을 위한 Marketing Tag가 별도 옵션으로 제공됩니다.

DAPPOS의 Intelligence Layer 자체가 리서치·시장 인사이트 등을 처리하는 전문 에이전트와 도구를 조정하는 구조이기 때문에, Marketing Tag는 단순 카피 생성보다는 마케팅 목적에 맞게 전체 AI 처리 방향을 지정하는 입력 신호로 볼 수 있음.

예를 들어 같은 프로젝트 자료라도:

기술 분석
초보자 설명
캠페인 콘텐츠

에서는 필요한 결과가 달라짐.

리서치 결과에서 흥미로운 정보를 발견해도 실제로 사용자가 할 수 있는 행동인지 별도로 확인해야 할 때가 있음.

DAPPOS의 Connected Opportunity Tag는 프롬프트와 관련된 실행 가능한 기회를 적극적으로 찾아보도록 AI에 지시하는 옵션으로 설명됩니다. 공식 가이드에는 토큰 구매나 계약 실행 같은 예시가 포함돼 있습니다.

여기서 중요한 건 Opportunity = 매수 추천이라는 의미로 보면 안 된다는 점임.

기술적으로는 분석 결과와 실행 가능한 Web3 행동 사이의 연결 가능성을 추가로 탐색하는 태그에 가까움.

실제 자산을 움직이는 판단은 가격·수수료·컨트랙트·리스크를 별도로 확인해야 함.

자주 하는 작업까지 매번 자연어 프롬프트를 작성한다면 초보자에게는 그것도 진입장벽이 될 수 있음.

그래서 DAPPOS 화면에는 Quick Buttons가 있습니다.

공식 가이드상 Inquiry는 내 포지션이나 잔액처럼 자주 조회하는 작업을 미리 준비된 프롬프트와 통합 도구로 실행하고, Transfer는 DAPPOS Wallet의 입출금 흐름으로 바로 이동하도록 구성됩니다.

즉 자연어 인터페이스만 제공하는 게 아니라,

반복되는 인텐트 → 버튼

으로 바꿔놓은 것임.

AI 사용법을 배우지 않아도 자주 쓰는 작업부터 기능으로 노출하는 UX라고 볼 수 있음.

1~9편을 연결하면 DAPPOS 입력창이 일반 AI의 프롬프트 창과 조금 다른 이유가 보임.

사용자는 먼저 로그인 방식으로 실행 가능 범위를 정하고,

Auto / Analyze / Plan / Light

로 작업의 기본 처리 방향을 고를 수 있음.

여기에

Bubble / Marketing / Connected Opportunity

같은 태그를 추가해 필요한 기능이나 목적을 더 구체화할 수 있고, 반복되는 행동은 Quick Button으로 바로 시작할 수 있습니다.

그 뒤에는 DAPPOS의 Intelligence Layer가 MAF와 Bubble Engine을 통해 리서치·계획·판단을 처리하고, 필요한 경우 Execution Layer로 이어지는 구조임.

즉 입력창의 옵션들이 장식처럼 많은 게 아니라,

“이번 요청을 얼마나 깊게 생각하고, 어떤 목적에 맞추며, 실행까지 얼마나 가까이 가져갈 것인가”

를 사용자가 조절하는 인터페이스라고 볼 수 있음.

AI에게 긴 영상이나 여러 페이지짜리 보고서를 맡기다 보면 중간에 작업이 끊기는 경우가 있음. 단순 질문과 달리 이런 결과물은 자료를 찾고, 만들고, 다시 검토하는 시간이 필요하기 때문임.

DAPPOS는 2026년 5월 Bubble Computer의 단일 실행 시간을 기존 최대 1시간에서 최대 3시간으로 확대했다고 발표했습니다. 공식 업데이트에서는 긴 영상·전문 비주얼·다중 페이지 PPT·PDF 보고서 등을 더 긴 세션으로 처리할 수 있다고 설명했습니다.

중요한 건 단순히 “AI가 오래 켜져 있다”가 아님. xBubble이 여러 단계를 거쳐야 하는 작업을 하나의 흐름 안에서 이어갈 수 있는 시간이 늘어난 것임.

짧은 답변보다 완성된 결과물 자체를 맡기는 방향으로 AI가 바뀌고 있다는 걸 보여주는 업데이트임.

AI로 PPT를 만들어보면 내용은 맞는데 이미지가 어색하거나, 페이지마다 디자인이 따로 노는 경우가 많음. 텍스트 생성과 발표자료 제작은 생각보다 다른 문제이기 때문임.

DAPPOS는 Text-to-PPTX 기능을 3단계 파이프라인으로 발전시켰다고 밝혔습니다. 순서는 자동 에셋 소싱 → 템플릿 매칭 → AI 기반 비주얼 리파인먼트입니다.

즉 먼저 필요한 시각 자료를 확보하고, 내용에 맞는 구조를 선택한 다음, 마지막에 전체 비주얼을 다듬는 방식임.

이 방식이 중요한 이유는 “글 잘 쓰는 AI”와 “발표자료 잘 만드는 AI”를 같은 것으로 보지 않기 때문임. xBubble의 SOP가 결과물의 제작 과정 자체를 세분화하는 사례라고 볼 수 있음.

AI 작업에서 은근히 번거로운 게 파일 전달임. 로컬 폴더에 있는 자료를 찾고, 웹에 업로드하고, 수정본을 다시 내려받는 과정을 계속 반복하게 됨.

DAPPOS는 2026년 4월 업데이트에서 Native macOS MCP integration을 공개하며 로컬 파일시스템을 클라우드 측 인텔리전스와 직접 연결한다고 설명했습니다. 공식 표현상 수동 동기화나 별도의 export 단계를 줄이는 방향입니다.

여기서 MCP는 단순 파일 첨부 기능이라기보다 AI가 외부 환경과 연결되는 통로에 가까움.

결국 Bubble Personal이나 Bubble Computer가 똑똑해지는 것만으로는 부족하고, 사용자가 실제로 가지고 있는 자료에 접근할 수 있어야 실무에 가까워짐. AI와 내 PC 사이의 벽을 낮추려는 시도라는 점이 핵심임.

보통 자동화 도구는 처음 만들어놓은 워크플로를 계속 반복함. 그런데 실제 사용에서는 예상하지 못한 요청과 실패 케이스가 계속 생김.

DAPPOS는 Bubble Engine에 Self-Optimization Loop를 구축해 피드백에서 다시 배포되는 과정까지 end-to-end로 연결했다고 발표했습니다. 공식 개발 업데이트에서는 들어오는 요청을 바탕으로 시스템이 SOP 개선 사이클을 이어가는 구조를 설명합니다.

여기서 재미있는 점은 AI 모델 자체만 바꾸는 게 아니라는 것임.

어떤 도구를 쓰고, 어떤 순서로 실행하고, 무엇을 검사할지를 담은 작업 방법(SOP)​도 개선 대상이 됨.

결국 xBubble의 Bubble Engine은 답변을 한 번 잘 만드는 것보다 같은 종류의 일을 다음번에 더 잘 처리하도록 실행법을 다듬는 데 초점이 있다는 얘기임.

“웹사이트 하나 만들어줘”라고 했는데 화면은 뜨지만 버튼이 안 되거나, 수정할수록 다른 부분이 망가지는 경험이 있음.

DAPPOS는 Bubble Code의 작동 방향을 설명하면서 Code Mode는 one-shot build가 아니라고 명시했습니다. 결과가 기대에 미치지 못하면 Bubble Engine이 기반 Coding SOP를 테스트하고 평가한 뒤 반복적으로 최적화하는 구조라고 설명합니다.

즉 사용자가 매번
“여기 다시 고쳐줘 → 또 테스트해줘 → 오류 찾아줘”
라고 모든 수정 단계를 직접 지시하는 부담을 줄이려는 방식임.

좋은 코딩 AI의 기준이 코드 한 번 생성하는 능력에서 테스트와 개선 루프까지 얼마나 대신 처리하느냐로 이동하고 있다는 사례임.

AI 코딩으로 사이트 하나 만드는 건 점점 쉬워지고 있음. 그런데 프로젝트가 5개, 10개가 되면 “어떤 게 지금 배포 중이지?”부터 헷갈리기 시작함.

DAPPOS는 Bubble Code로 만든 AI 웹사이트를 하나의 Project Workspace에서 관리하는 기능을 소개했습니다. 공식 설명에서는 배포된 프로젝트들을 한곳에서 보고, 실행 중인지 일시정지 상태인지 추적할 수 있다고 밝혔습니다.

이게 중요한 이유는 Bubble Code를 단순한 코드 생성기로 끝내지 않으려는 방향이 보이기 때문임.

만드는 단계뿐 아니라 배포된 결과물을 계속 운영하고 관리하는 단계까지 같은 흐름에 넣는 것임.

AI 코딩이 실사용으로 넘어갈수록 “무엇을 만들 수 있나?”보다 “만든 뒤 어떻게 관리하나?”가 더 중요해질 수 있음.

영상 AI에게 “재미있는 숏드라마 만들어줘”라고만 하면 영상은 만들어도 이야기 흐름이 밋밋할 때가 많음.

DAPPOS는 2026년 5월 Bubble Engine의 영상 SOP 학습을 업데이트하면서 Short-Drama Benchmark SOP를 도입했다고 발표했습니다. 이를 내러티브 영상 생성을 더 빠르게 학습하기 위한 기준점으로 사용한다고 설명했습니다.

즉 영상 모델에게 모든 걸 맡기는 것과는 조금 다름.

“어떤 방식으로 만들면 좋은 결과에 가까워지는가”라는 검증된 제작 절차 자체를 기준으로 두는 구조임.

xBubble이 Low-Prompt를 지향할 수 있는 이유도 결국 사용자가 긴 제작 매뉴얼을 매번 입력하는 대신, Bubble Engine 쪽에서 작업법을 준비하려 하기 때문임.

AI 영상에서 흔히 생기는 문제가 있음. 나레이션은 너무 빠르고, 캐릭터 대사는 부자연스럽고, 장면과 말의 속도가 맞지 않는 경우임.

DAPPOS는 Bubble Engine의 영상 SOP 학습 과정에서 narration과 character speech를 구분하는 더 명확한 훈련·평가 제약 조건을 추가했다고 밝혔습니다. 공식 업데이트에서는 이를 통해 지나치게 빠른 voice-over를 줄이고 음성 결과를 개선하는 방향을 설명했습니다.

여기서 핵심은 “더 좋은 음성 모델 하나”만 쓰는 게 아님.

영상 속 말의 역할을 구분하고 각각 다른 기준으로 평가하는 작업 설계의 문제로 접근한다는 것임.

작은 SOP 차이가 최종 결과의 자연스러움을 크게 바꿀 수 있다는 사례임.

대부분의 AI는 사람이 먼저 대화를 시작해야 움직임. 그래서 매일 반복되는 작업까지 사람이 직접 들어가서 명령해야 하는 경우가 많음.

DAPPOS는 2026년 8월 개발 업데이트에서 BNB Agent Studio와 Scheduled Task Execution System을 함께 제공했다고 발표했습니다. 공식 설명상 예약된 Agent workflow를 실행할 수 있도록 하는 인프라입니다.

이 변화의 의미는 꽤 큼.

AI Agent가 단순히 질문에 답하는 존재가 아니라, 미리 정의된 Intent와 작업 흐름을 정해진 시점에 실행하는 시스템으로 확장될 수 있기 때문임.

Web3 AI OS가 실제 운영 도구에 가까워지려면 이런 “언제 실행할 것인가”라는 시간 개념도 필요함.

AI에게 새로운 일을 시킬 때마다 작업 순서와 도구 사용법을 처음부터 설명해야 한다면 결국 사용자가 AI 사용법을 공부해야 함.

DAPPOS는 2026년 8월 개인 사용자가 1,000개 이상의 Public SOP​에 접근할 수 있도록 확대했다고 밝혔습니다. 공식 안내에서는 Code, Video, Image, Research 등 여러 영역의 SOP가 포함된다고 설명했습니다.

이 구조에서 SOP는 단순한 “추천 프롬프트 모음”으로 보는 것과 차이가 있음.

xBubble은 이미 만들어지고 검증된 작업 경로를 활용해 사용자가 원하는 결과에 더 짧게 접근하려는 방향임.

결국 Low-Prompt AI의 경쟁력은 대화창을 단순하게 만드는 것보다 뒤에 얼마나 많은 실행 노하우가 준비돼 있느냐에서 갈릴 수도 있음.

AI에게 “사이트 하나 만들어줘”라고 하면 코드는 꽤 빨리 나옴.

그런데 실제 서비스를 열려고 하면 갑자기 할 일이 늘어남. 오류를 확인하고, 어떤 구조를 쓸지 결정하고, 외부 서비스를 설정하고, 테스트하고, 마지막에는 배포까지 해야 함.

DAPPOS 공식 문서도 현재 Coding Agent가 비개발자에게 어려운 이유로 이런 과정을 지적합니다. 개발자는 생성된 코드를 읽고 문제를 수정할 수 있지만, 일반 사용자에게는 코드 생성 이후의 기술 작업 자체가 또 하나의 장벽이라는 것임.

그래서 Bubble Code가 노리는 방향은 단순함.

“코드를 만들어주는 AI”가 아니라
“원하는 서비스를 실제로 작동시키는 AI”에 가까워지는 것.

이 차이가 생각보다 큼.

웹서비스를 만든다고 생각하면 보통 화면과 코드부터 떠올림.

하지만 실제 공개까지 가려면 도메인, 서버, 클라우드 호스팅, DNS 같은 것들이 따라옴. 코드를 몰라도 AI가 만들어줬는데, 마지막 단계에서 다시 검색창에
“DNS 연결 방법”
“서버 배포 방법”
을 찾게 되는 이유임.

DAPPOS는 Bubble Code 설명에서 실제 프로젝트에는 domains, servers, cloud hosting, DNS 등 코드베이스 밖의 서비스가 필요하다​고 짚고 있습니다. Bubble Code는 Coding SOP와 AI가 접근할 수 있도록 패키징된 외부 서비스를 함께 묶어 이 간극을 줄이려는 구조입니다.

즉 목표는 코드 파일 하나 전달하고 끝내는 게 아님.

아이디어 → 코드 → 인프라 → 실제 공개

여기까지 한 흐름으로 이어지는 것이 중요함.

쇼핑몰을 만들었다고 해도 결제가 없으면 실제 쇼핑몰로 쓰기 어려움.

예약 서비스를 만들었다면 알림이 필요할 수 있고, AI 서비스를 만든다면 별도의 모델 API를 연결해야 할 수도 있음.

DAPPOS 공식 Bubble Code 문서는 코드 밖에서 필요한 대표적인 서비스로 SMS, payments, model APIs 등을 직접 언급합니다. 그리고 Coding SOP와 함께 이런 제3자 서비스를 AI가 활용할 수 있는 형태로 패키징하는 방향을 설명합니다.

여기서 핵심은 “AI가 API 코드를 써준다”에서 한 단계 더 나아간다는 것임.

사용자는
“결제 붙이고 문자 알림도 넣어줘”
라고 결과를 말하고,

뒤에서는 Bubble Code가 필요한 서비스와 작업 절차를 연결하려는 구조임.

비개발자에게 AI 코딩이 정말 쉬워지려면 이 부분까지 줄어들어야 함.