DAPPOS 스토리텔러 여러 단계짜리 일이 도는 작업실. 공식 문서

공식 문서는 Bubble Computer를 처음부터 끝까지 이어지는 프로젝트 작업 공간이라고 소개합니다.

앞서 나온 Bubble Pilot이 여러 단계가 필요한 일이라고 판단하면 이쪽으로 넘깁니다. 그러면 샌드박스가 하나 열립니다.

샌드박스는 격리된 작업 공간을 뜻합니다. 안에서 무엇을 설치하고 실행하든 바깥에 영향을 주지 않는 별도의 방이라고 보시면 됩니다.

그 안에서 필요한 기능이 그때그때 올라옵니다. 처음부터 모든 도구를 켜두는 대신, 지금 단계에 필요한 것만 불러오는 방식입니다.

한 번 도는 동안 하는 일은 이렇습니다. 주제를 조사하고, 문서를 쓰고, 이미지를 만들고, 내용이 맞는지 확인하고, 최종 결과물까지 냅니다.

보통은 이 과정을 사람이 이어 붙입니다. 조사는 검색으로, 문서는 문서 도구로, 이미지는 이미지 도구로 하고 결과를 손으로 옮깁니다. 옮기는 사이에 맥락이 끊깁니다.

Bubble Computer는 그 이어 붙이는 일을 안으로 넣었습니다. 사용자는 목표를 한 번만 말하고, 어떤 모델을 쓸지와 어떤 도구로 넘길지, 순서를 어떻게 맞출지는 시스템이 정합니다.

🔗 웹사이트 | 트위터 | 텔레그램 | 커뮤니티

#DAPPOS #BubbleComputer #워크스페이스 #스토리텔러

내 컴퓨터 안에서 도는 모드. 공식 문서

DAPPOS 공식 문서에 따르면 Bubble Personal은 로컬 환경, 그러니까 내 기기 안에서 작동하는 모드입니다.

다루는 범위는 내 파일과 브라우저, 앱, 일정입니다. 클라우드에 올라간 자료가 아니라 내 컴퓨터에 있는 것을 대상으로 합니다.

문서가 든 예시는 이렇습니다. 개인 계정이 필요한 사이트 작업을 자동화하거나, 캘린더와 메일함을 읽어 아침 브리핑을 만들거나, 사진을 정리하거나, 밤사이 시장 데이터를 모으는 일입니다.

내 기기를 건드린다는 말은 편리한 동시에 불안한 이야기이기도 합니다. 그래서 실행 방식에 장치를 뒀습니다.

설치나 시스템 변경처럼 무거운 작업은 클라우드 컨테이너 안에서 벌어집니다. 그리고 그 컨테이너는 작업이 끝나면 폐기됩니다.

내 기기에서는 명시적으로 허락한 동작만 실행됩니다. 무거운 연산과 위험한 작업은 바깥에서 처리하고, 정리된 결과만 안으로 돌아오는 구조입니다.

자동화 도구를 쓸 때 가장 걸리는 부분이 권한입니다. 어디까지 손대는지 모르면 쓰기가 꺼려집니다. 실행 위치를 나누고 폐기 시점을 못박은 것은 DAPPOS가 그 불안을 줄이려 택한 설계로 읽힙니다.

🔗 웹사이트 | 트위터 | 텔레그램 | 커뮤니티

#DAPPOS #BubblePersonal #자동화 #스토리텔러

SOP는 예시를 보고 만들어진다. 공식 문서

DAPPOS 공식 문서는 SOP 훈련이 사례를 중심으로 돌아간다고 설명합니다. 규칙을 말로 적어주는 방식이 아니라 결과물을 보여주는 방식입니다.

먼저 사용자가 좋다고 판단한 결과물을 예시로 넣습니다. 예전에 손으로 만든 산출물, 참고할 영상 광고, 따라 하고 싶은 문서 양식 같은 것들입니다.

예시가 부족하면 Bubble Engine이 참고 자료를 찾거나 직접 만들어 채웁니다. 아무것도 없는 상태에서 시작하지 않아도 된다는 뜻입니다.

사례가 확정되면 거기서 요청과 결과의 쌍을 뽑아냅니다. 이런 요청에는 이런 결과가 나와야 한다는 기준표를 만드는 단계입니다.

그다음 코딩 에이전트가 기본 SOP를 바탕으로 전용 SOP를 만듭니다. 만들어진 SOP는 바로 등록되지 않고 시험을 거칩니다.

평가는 두 갈래입니다. 하나는 사용자가 말한 요구사항을 충족했는가이고, 다른 하나는 제시한 예시에 충분히 가까운가입니다. 이 둘은 다릅니다. 요구는 맞췄는데 느낌이 다른 경우가 있기 때문입니다.

더 나아지지 않을 때까지 고친 뒤에야 시스템에 올라갑니다. 이때 적용 범위도 함께 정합니다. 범용 SOP보다 나을 것 같은 상황에서만 추천되도록 하기 위해서입니다.

전용 절차를 아무 데나 들이대면 오히려 결과가 나빠질 수 있다는 점을 감안한 DAPPOS의 설계입니다.

🔗 웹사이트 | 트위터 | 텔레그램 | 커뮤니티

#DAPPOS #SOP #BubbleEngine #스토리텔러

토큰 랭킹 사이트를 통째로 만들어 띄운 사례. 출처

DAPPOS 공식 게시글이 든 사례입니다. Bubble Code로 로빈후드 체인의 토큰 랭킹 사이트를 만들어 실제로 배포했습니다.

가장 중요한 부분은 데이터를 다루는 방식입니다. 토큰 목록을 코드에 직접 적어 넣지 않고 체인 데이터를 그대로 끌어다 씁니다.

이 차이가 큽니다. 목록을 코드에 박아두면 만든 시점의 상태로 굳어버립니다. 새 토큰이 나오거나 순위가 바뀌어도 화면은 그대로입니다.

체인에서 직접 가져오면 시가총액 기준으로 정렬된 순위가 계속 갱신됩니다. 사람이 손대지 않아도 최신 상태를 유지합니다.

들어간 기능은 실시간 데이터 상태 표시, 새로고침, 검색, 필터, 그리고 데이터 출처 확인입니다. 마지막 항목이 있다는 것은 숫자가 어디서 왔는지 사용자가 확인할 수 있다는 뜻입니다.

보기용 화면과 돌아가는 서비스의 차이가 여기서 갈립니다. 갱신되지 않는 목록은 만든 순간부터 낡기 시작하고, 며칠만 지나도 신뢰를 잃습니다.

데모를 만드는 것과 계속 쓸 수 있는 것을 만드는 것은 다른 일입니다. DAPPOS가 이 사례로 보여주려는 지점이 그것입니다.

🔗 웹사이트 | 트위터 | 텔레그램 | 커뮤니티

#DAPPOS #BubbleCode #온체인데이터 #스토리텔러

아마존 클라우드 수장, "잠재적 AI 사업 규모는 그야말로 거대하다"

세계 최대 클라우드 컴퓨팅 및 데이터 서비스 제공업체인 아마존(Amazon)은 지난주 2026년 자본 지출(CapEx)을 당초 전망치였던 2,000억 달러에서 상향 조정하여 2,200억 달러를 지출할 것이라고 밝혔습니다.


아마존의 클라우드 사업부(AWS) 수장은 고객들이 단순히 AI 모델을 학습(Training)시키는 단계에서 벗어나, AI를 자사 비즈니스 시스템에 통합하는 단계로 전환하기 시작했으며, 이는 '추론(Inference)'이라 불리는 과정의 수요를 끌어올리고 있다고 말했습니다.

아마존웹서비스(AWS)의 최고경영자(CEO) 맷 가먼(Matt Garman)은 월요일 블룸버그 텍(Bloomberg Tech) TV 방송에 출연하여 다음과 같이 밝혔습니다.

"여전히 많은 기업이 대규모 학습 클러스터를 이용하고 있습니다. 하지만 이러한 AI 모델들이 점점 더 널리 보급되고 강력해짐에 따라, 더욱 많은 기업이 실제 업무에 추론(Inference) 과정을 통합해 나가고 있습니다."

https://www.bloomberg.com/news/articles/2026-08-03/amazon-cloud-chief-says-potential-ai-business-is-just-massive?taid=6a70f219423cf600011ce2e2&utm_campaign=trueanthem&utm_content=business&utm_medium=social&utm_source=twitter

데모 페이지와 돌아가는 사업의 차이. 공식 문서

DAPPOS 공식 문서는 Bubble Code가 데모 페이지가 아니라 업무 흐름을 겨냥한다고 못 박습니다.

문서의 표현을 빌리면, 데모 페이지는 AI가 코드를 짤 수 있다는 것만 증명합니다. 보기에는 그럴듯하지만 그것으로 장사를 할 수는 없습니다.

실제 사업에 필요한 것은 목록이 깁니다. 화면과 사용자 동선, 로그인, 결제, 뒷단 기록, 서비스 설정, 그리고 나중에 고칠 방법까지 있어야 합니다.

문서가 드는 대표 사례는 웹3 기반 판매입니다. 상품이나 디지털 재화, 서비스 패키지, 행사 입장권, 상담 세션, 커뮤니티 굿즈 같은 것을 파는 경우입니다.

이때 묶어주는 항목은 브랜드 요소, 페이지 구조, 상품 설명과 이미지, 지갑 로그인, 스테이블코인 결제, 주문 기록, 백엔드 관리, 출시 자료입니다.

여기서 지갑 로그인과 스테이블코인 결제가 들어간 점이 눈에 띕니다. 사업자 등록이나 결제대행사 심사 같은 절차 없이도 판매 구조를 세울 수 있는 경로이기 때문입니다.

문서가 마지막에 강조한 문장이 이 접근을 요약합니다. 사용자는 템플릿에서 시작하지 않고 무엇을 팔 것인지에서 시작합니다.

기술 구조를 먼저 고르는 것이 아니라 팔 물건을 정하면 나머지가 따라오는 순서이고, DAPPOS가 코딩 SOP로 겨냥한 지점이 여기입니다.

🔗 웹사이트 | 트위터 | 텔레그램 | 커뮤니티

#DAPPOS #BubbleCode #웹3커머스 #스토리텔러

여러 에이전트가 하나의 상태를 공유한다. 공식 문서

DAPPOS 공식 문서는 멀티 에이전트 프레임워크의 중심에 StateGraph라는 구조가 있다고 설명합니다.

멀티 에이전트란 하나의 AI가 전부 처리하는 대신, 역할이 다른 여러 AI가 나눠 맡는 방식입니다. 사람으로 치면 혼자 하는 일과 팀으로 하는 일의 차이입니다.

팀으로 일할 때 가장 흔한 문제는 정보가 어긋나는 것입니다. 앞사람이 무엇을 왜 그렇게 했는지 뒷사람이 모르면 같은 일을 다시 하거나 반대로 갑니다.

StateGraph는 그 문제를 다루는 장치입니다. 여기에는 에이전트끼리 주고받는 메시지, 작업 계획, 산출물, 사람이 개입하는 지점, 최종 결과, 오류, 조건 분기용 표시가 담깁니다.

이 값들이 단계마다 그대로 넘어가며 판단의 근거가 됩니다. 각 단계가 자기 앞의 맥락을 그대로 물려받는 구조입니다.

문서에 따르면 각 노드가 하나의 에이전트입니다. 그중 컨트롤러 노드는 지금 상태를 보고 다음에 어디로 보낼지 정하고 상태를 갱신합니다.

요청이 들어오면 먼저 작업 계획 노드가 의도를 분류합니다. 정보 수집인지, 전략 실행인지, 기회 탐지인지에 따라 검색이나 디파이 같은 하위 경로로 갈립니다.

판단 근거가 상태에 남기 때문에 왜 그런 결론이 나왔는지 되짚을 수 있습니다. DAPPOS 문서가 설명 가능한 의사결정을 앞세운 이유가 여기 있습니다.

🔗 웹사이트 | 트위터 | 텔레그램 | 커뮤니티

#DAPPOS #멀티에이전트 #MAF #스토리텔러

질문이 바뀌었다, 코드가 아니라 창업. 공식 문서

DAPPOS 공식 문서는 AI 코딩의 첫 단계가 던진 질문을 이렇게 정리합니다. AI가 코드를 쓸 수 있는가.

이 질문에는 이미 답이 나왔습니다. 쓸 수 있습니다. 그래서 문서는 다음 단계의 질문이 다르다고 말합니다.

AI가 더 많은 사람이 사업을 시작하도록 도울 수 있는가. 코드를 짜는 능력이 아니라 결과로 이어지는지를 묻는 질문입니다.

문서는 여기에 두 축을 놓습니다. 웹3는 로그인과 결제, 디지털 소유권에서 마찰을 줄입니다. 계좌를 트고 결제 수단을 심사받는 과정 없이도 거래가 성립하는 구조입니다.

xBubble은 다른 쪽 마찰을 줄입니다. 소프트웨어를 만들고, 서비스를 설정하고, 업무 흐름을 짜는 부분입니다.

그리고 서비스 제공자들이 그 사이의 인프라를 채웁니다. 세 축이 각자 다른 구간의 문턱을 낮추는 그림입니다.

코딩 SOP가 하는 일은 그중에서도 구체적입니다. 불필요한 기술적 복잡함을 감추고, 사용자가 실제로 이해하는 사업상의 결정만 남기는 것입니다.

어떤 데이터베이스를 쓸지는 몰라도 되지만 무엇을 얼마에 팔지는 사용자가 정해야 합니다. 장벽을 0에 가깝게 만든다는 표현이 가리키는 지점이 여기입니다.

DAPPOS가 하는 이야기는 도구의 기능을 늘리는 쪽이 아니라, 만들 수 있는 사람의 범위를 넓히는 쪽입니다.

🔗 웹사이트 | 트위터 | 텔레그램 | 커뮤니티

#DAPPOS #Web3AI #진입장벽 #스토리텔러

DAPPOS는 왜 두 개의 층으로 나뉘어 있나. 공식 문서

공식 문서는 DAPPOS를 웹3 AI 운영체제라고 정의합니다. 크립토와 관련된 일을 조사하고, 계획을 세우고, 실행까지 하는 시스템이라는 설명입니다.

구조는 두 층입니다. 하나는 지능 계층이고 다른 하나는 실행 계층입니다. 생각하는 쪽과 움직이는 쪽을 나눠 놓았습니다.

지능 계층은 멀티 에이전트 프레임워크가 떠받칩니다. 문서에 적힌 규모는 300개에서 400개의 전문 에이전트와 200개가 넘는 통합 도구입니다.

그 중심에 Bubble Engine이 있습니다. 웹3에 맞춘 강화학습 모델로 돌아가며, X와 바이낸스 스퀘어 같은 곳에서 실시간 정보를 받아 계속 갱신됩니다.

실행 계층은 DAPPOS의 인텐트 실행 네트워크입니다. 문서는 이 인프라가 500만 명이 넘는 사용자와 1200만 건이 넘는 거래로 다져졌다고 밝힙니다.

둘로 나눈 이유는 따져보면 분명합니다. 판단이 좋아도 실행이 막히면 결과가 남지 않고, 실행만 빨라도 판단이 얕으면 엉뚱한 곳으로 갑니다.

문서가 내세우는 결과물은 Instant dApps입니다. 자연어 대화만으로 웹3 애플리케이션을 만들어 띄우는 방식입니다. Discover 페이지에서는 다른 사용자가 공유한 인사이트와 실행 계획을 골라 그대로 실행할 수도 있습니다.

🔗 웹사이트 | 트위터 | 텔레그램 | 커뮤니티

#DAPPOS #Web3AIOS #멀티에이전트 #스토리텔러

모델은 좋아졌는데 결과는 사람마다 다른 이유. 공식 문서

DAPPOS 공식 문서는 문제를 이렇게 정리합니다. AI 성능은 빠르게 좋아지고 있지만 쓰기 쉬움은 여전히 병목이라는 것입니다.

같은 모델이 숙련된 사용자에게는 훌륭한 결과를 주고 보통 사용자에게는 실망스러운 결과를 줍니다. 문제를 어떻게 틀 잡았는지, 어떤 도구를 붙였는지, 맥락을 어떻게 넣었는지에 따라 갈립니다.

문서는 이것을 사용성 격차라고 부릅니다. 숙련자는 AI 조작 자체를 하나의 기술로 다룰 수 있지만, 대부분의 사용자는 그러고 싶어 하지 않습니다.

그들이 원하는 것은 문서를 만들고, 슬라이드를 뽑고, 웹사이트를 세우고, 조사를 하고, 업무를 자동화하는 일입니다. 모델 선택자와 프롬프트 엔지니어와 도구 통합자와 품질 검사자를 동시에 겸하고 싶어 하지는 않습니다.

여기서 DAPPOS가 내놓은 답이 저프롬프트 AI입니다. 문서는 오해를 미리 차단합니다. 저프롬프트는 사용자가 아무 정보도 주지 않는다는 뜻이 아닙니다.

의도와 맥락, 예시, 제약, 취향, 필요할 때의 피드백은 여전히 사용자가 냅니다. 줄이려는 것은 정보가 아니라 조작의 양입니다.

문서가 요약한 방향 전환이 핵심입니다. Bubble Engine이 배우고, Bubble Pilot이 쓰고, 사용자는 목표를 말합니다. 보통의 AI 제품에서는 사용자가 도구를 배우지만 여기서는 순서가 반대입니다.

🔗 웹사이트 | 트위터 | 텔레그램 | 커뮤니티

#DAPPOS #저프롬프트 #xBubble #스토리텔러

부품이 세 개뿐인 구조. 공식 문서

DAPPOS 공식 문서는 xBubble의 작동 구조를 세 부품으로 요약합니다. Bubble Engine, Bubble Pilot, 그리고 SOP 시스템입니다.

역할 분담도 한 줄로 정리돼 있습니다. Bubble Engine이 SOP를 만들고 다듬습니다. Bubble Pilot이 그중에서 골라 실행합니다. SOP는 그 둘을 잇는 작업별 해법 묶음입니다.

구조가 이렇게 단순한 것은 우연이 아닙니다. 만드는 쪽과 쓰는 쪽을 분리해두면 각각을 따로 개선할 수 있기 때문입니다.

만드는 쪽이 좋아지면 절차의 품질이 올라가고, 고르는 쪽이 좋아지면 같은 절차라도 더 정확한 곳에 배치됩니다. 둘이 붙어 있으면 한쪽을 고칠 때 다른 쪽이 흔들립니다.

사람 조직에 대보면 이해가 빠릅니다. 매뉴얼을 쓰는 부서와 접수 창구를 나눠둔 것과 같습니다. 창구는 매뉴얼을 새로 쓰지 않고, 매뉴얼 부서는 손님을 직접 받지 않습니다.

이 분리가 DAPPOS가 말하는 저프롬프트를 실제로 가능하게 하는 지점이기도 합니다. 사용자가 어떤 절차를 쓸지 고르지 않아도 되는 이유가 여기 있습니다.

앞으로 부품이 늘어난다 해도 이 세 갈래의 역할은 바뀌지 않을 구조입니다. 만들고, 고르고, 묶는 일이 각각 자기 자리를 갖고 있습니다.

🔗 웹사이트 | 트위터 | 텔레그램 | 커뮤니티

#DAPPOS #xBubble #구조 #스토리텔러

Bubble Engine을 문서는 해법 공장이라 부른다. 공식 문서

DAPPOS 공식 문서가 Bubble Engine에 붙인 표현은 해법 공장입니다. 하나의 정답을 내놓는 자리가 아니라 여러 개를 만들어 걸러내는 자리라는 뜻입니다.

주어진 작업 하나에 대해 하는 일은 이렇습니다. AI 코딩 에이전트를 써서 해법 변형들을 만들고, 시험 장치를 짜고, 후보 모델과 도구를 조합합니다.

그다음 그 결과들을 작업 예시와 품질 기준에 대고 평가합니다. 여기서 가장 좋은 경로만 살아남습니다.

살아남은 경로가 SOP, 즉 표준 작업 절차가 됩니다. 비슷한 요청이 들어올 때마다 다시 꺼내 쓰는 재사용 가능한 해법입니다.

문서가 덧붙인 조건이 중요합니다. SOP로 올리기 전에 Bubble Engine이 그 절차의 범용성을 시험합니다. 한 사례에서만 잘 되는 것을 표준이라고 부르지 않겠다는 뜻입니다.

이 구조가 DAPPOS의 접근을 잘 보여줍니다. 좋은 결과를 한 번 내는 것과, 그 결과를 다음에도 다시 낼 수 있게 만드는 것은 서로 다른 일입니다.

한 번의 성공은 운일 수 있습니다. 여러 변형을 만들어 겨루게 하고 기준으로 재는 절차를 둔 이유가 여기 있습니다.

🔗 웹사이트 | 트위터 | 텔레그램 | 커뮤니티

#DAPPOS #BubbleEngine #SOP #스토리텔러

무료 티켓이벤트도 꼮꼮 확인하시기

빗썸(Bithumb) 공지
[마켓 추가] 메타다오(META2), 글로벌달러(USDG) 원화 마켓 추가
2026-08-04 14:04:51

SOP는 스킬 하나가 아니다. 공식 문서

DAPPOS 공식 문서는 SOP의 구성을 한 줄 식으로 적어두었습니다. 스킬에 실행 환경, API, MCP, 모델 선택을 더한 것이 SOP입니다. 왜 이렇게 묶었는지도 바로 이어집니다. 스킬만으로는 부족하기 때문입니다. 결과는 어떤 환경에서 도는지, 어떤 모델을 쓰는지, 어떤 API와 MCP가 붙어 있는지에 따라 달라집니다.

문서는 일반적인 스킬 마켓과 비교해 세 가지를 앞세웁니다. 첫째는 안정성입니다. SOP는 검증된 범위 안에서 쓰입니다. 사용자의 작업이 그 범위에 들어맞을 때 결과가 더 일정하게 나옵니다.

둘째는 쓰기 쉬움입니다. 입력은 작업 설명 하나면 됩니다. 모델을 고르거나 API를 설정하거나 여러 스킬을 비교하거나 실행 과정을 디버깅할 필요가 없습니다. 고르는 일은 Bubble Pilot이 합니다. 셋째는 SOP를 스스로 만들어낸다는 점입니다. 쓸 만한 스킬 하나를 만들려면 시험과 디버깅과 최적화가 필요한데, 비개발자에게는 이 과정 자체가 벽입니다. Bubble Engine이 이 부분을 대신합니다.

문서는 SOP가 범용일 수도 있고 특정 사용자나 회사의 요구에 맞춘 좁은 해법일 수도 있다고 덧붙입니다. DAPPOS가 조작 부담을 사용자에게서 시스템으로 옮긴다고 말할 때 그 이동이 실제로 일어나는 지점이 SOP입니다.

이 구조가 실제로 통할지는 쓰는 사람이 늘어야 판가름 납니다. 어떻게 보시나요.

#DAPPOS #SOP #xBubble

콜드카드 여파, 2.2만 BTC 거래소로. Laura Shin

: 금요일 이후 약 2만2000 BTC가 거래소로 복귀
: FTX 붕괴 때도 없던 자기보관 이탈이 나타난 흐름
: 하드웨어 지갑 보안 우려가 개인 보관 전제를 흔든 국면

#BTC #콜드카드

염전 마진이 그렇게좋나?
아 100% 순익인가..?

볼츠, AI 해킹 급증에 서비스 무기한 중단. 블록미디어

: 비트코인 스왑 서비스 볼츠가 운영을 무기한 중단
: AI 기반 해킹 시도 급증을 중단 사유로 제시
: 소규모 인프라부터 버티지 못하는 보안 국면

#보안 #인프라

Bubble Code는 별개 제품이 아니다. 공식 문서

DAPPOS 공식 문서는 Bubble Code를 xBubble의 소프트웨어 제작 모드라고 규정합니다. 따로 떨어진 도구가 아니라 xBubble의 SOP 시스템 위에 얹힌 모드입니다. 따르는 철학도 같습니다. 모든 사용자를 능숙한 바이브 코더로 만드는 대신, 복잡한 AI 작업 흐름을 작업별 SOP로 포장한다는 것입니다.

여기서 바이브 코딩은 코드를 직접 짜는 대신 AI에게 말로 설명해 만들어내는 방식을 뜻합니다. 편해 보이지만 잘하려면 결국 요령이 필요합니다. Bubble Code는 그 요령을 사용자에게 요구하는 대신 코딩 SOP 쪽에 담습니다. 문서가 적은 순서는 두 줄입니다. 사용자는 사업 목표를 말하고, Bubble Code는 맞는 코딩 SOP를 돌립니다.

차이가 작아 보이지만 실제로는 큽니다. 프롬프트로 코드를 얻는 방식은 매번 결과가 흔들리고 잘 나온 이유가 개인의 감에 남습니다. 반대로 절차로 굳혀두면 같은 종류의 요청이 같은 품질로 처리됩니다. 잘 쓰는 사람과 못 쓰는 사람의 격차가 줄어드는 쪽입니다.

DAPPOS가 xBubble 전체에 적용한 논리를 소프트웨어 제작과 수정에도 그대로 가져왔다는 점이 이 페이지의 요지입니다.

설계는 그럴듯한데 실사용에서 갈릴 부분입니다. 직접 써보신 분 있으실까요.

#DAPPOS #BubbleCode #SOP