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

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 코딩이 정말 쉬워지려면 이 부분까지 줄어들어야 함.

AI에게 토큰 순위 사이트를 만들어달라고 하면 가장 쉬운 방법은 예시 숫자를 화면에 넣는 것임.

보기에는 그럴듯함.

하지만 가격과 순위가 바뀌어도 그대로라면 결국 데모에 가까움.

DAPPOS는 2026년 7월 Bubble Code 시연에서 Robinhood Chain의 실제 체인 데이터를 사용해 토큰 랭킹 웹사이트를 만들고 배포하는 사례를 공개했습니다. 공식 설명에서도 hard-coded token data가 아니라 chain data를 사용한다는 점을 강조했습니다.

즉 중요한 건 페이지 모양만 만드는 게 아님.

실시간 데이터 → 처리 → 화면 → 배포

이 연결이 되어야 웹사이트가 계속 살아 움직이는 서비스가 됨.

Bubble Code가 단순 UI 생성기와 달라지려는 지점 중 하나임.

AI 웹사이트 제작 도구가 쉬운 이유 중 하나는 미리 준비된 구조를 많이 활용하기 때문임.

문제는 내가 원하는 기능이 템플릿에 없을 때임.

예를 들어 특정 데이터를 계산하고, 조건을 판단한 다음, 그 결과에 따라 다른 행동을 실행해야 한다면 단순한 화면 조립으로는 부족할 수 있음.

DAPPOS가 2026년 7월 공개한 Bubble Code 사례에서는 custom functions, real-time data, deployable execution​을 함께 강조했습니다. 즉 고정된 페이지를 만드는 것뿐 아니라 사용 목적에 맞는 기능을 넣고 실제 실행 가능한 형태까지 연결하려는 방향임.

결국 AI 코딩에서 중요한 건
“예쁜 사이트를 만들 수 있나?”보다

“내가 원하는 로직을 실제 기능으로 만들 수 있나?”

일 수 있음.

AI 덕분에 웹서비스 하나 만드는 시간이 줄어들면 새로운 문제가 생김.

프로젝트가 많아지는 것임.

어떤 사이트가 현재 실행 중인지, 어떤 프로젝트를 잠깐 멈췄는지, 무엇을 배포했는지 하나씩 찾아다니면 결국 관리 도구가 또 필요해짐.

DAPPOS는 Bubble Code로 만든 AI 웹사이트들을 하나의 Project Workspace에서 관리하도록 하는 기능을 공개했습니다. 공식 설명에서는 배포된 프로젝트들을 한곳에서 확인하고 running 또는 paused 상태를 추적할 수 있다고 설명합니다.

이게 의미 있는 이유는 Bubble Code의 범위가

만들기 → 배포하기 → 운영 상태 관리하기

까지 넓어지고 있기 때문임.

AI 시대에는 “얼마나 빨리 만드나”만큼 “만든 것을 얼마나 쉽게 관리하나”도 중요해질 수 있음.

소개 페이지 하나 만드는 것과 실제 서비스를 운영하는 건 다름.

실제 비즈니스라면 상품이나 콘텐츠가 있고, 사용자가 행동하고, 경우에 따라 결제하거나 예약하고, 그 뒤의 처리까지 이어져야 함.

DAPPOS의 2026년 7월 개발 업데이트에서는 Bubble Code의 Full-Stack Commerce + Service Flows를 강화했다고 밝혔습니다. 같은 업데이트에서 Bubble Engine이 유료 콘텐츠 상품과 서비스 예약 등을 다루는 Paid Content + Booking SOP를 반복 학습·개선하는 내용도 공개했습니다.

즉 방향은
“홈페이지 하나 생성”이 아니라

사용자가 들어와 실제 행동을 완료하는 전체 흐름을 만드는 쪽에 가까움.

AI 코딩이 비즈니스 도구가 되려면 결국 여기까지 와야 함.

AI 코딩에서 흔한 장면이 있음.

처음 결과를 보고
“거의 맞는데 뭔가 부족한데…”
싶어서 프롬프트를 계속 수정하는 것임.

DAPPOS는 Bubble Code의 Code Mode를 설명하면서 “one-shot build가 아니다”​라고 명시했습니다.

결과가 사용자의 제품 목표와 충분히 맞지 않을 경우 Bubble Up을 제출하면, Bubble Engine이 기반 Coding SOP를 테스트하고 평가하면서 개선하도록 설계됐다고 설명합니다.

즉 개선 대상이 생성된 코드 하나만이 아님.

그 코드를 만들어내는 작업 방법 자체도 다시 평가하는 구조임.

한 번 잘 찍어내는 AI보다
반복하면서 제작법까지 좋아지는 AI를 노린다는 얘기임.

대부분의 AI는 사용자가 메시지를 보내야 일을 시작함.

그런데 실제 서비스에서는
매일 오전에 실행하거나,
정해진 시간마다 데이터를 갱신하거나,
특정 업무를 반복해야 할 수도 있음.

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

이 변화가 중요한 이유는 AI Agent가 단순한 대화 상대에서 벗어나기 때문임.

만들기 → 배포하기 → 정해진 시간에 다시 실행하기

까지 연결되면 하나의 운영 시스템에 가까워짐.

Web3 AI OS에서 ‘시간’도 실행 조건이 되는 셈임.