[비교분석 🙄] 버블 vs 플러터플로우

2024. 3. 13.

이 메일이 잘 안보이시나요?

내 비즈니스 아이디어를 실현하는데 있어 개발이 필요해 난처하다면, 노코드 빌딩이 해결책이 될 수 있습니다. 모두의 노코드를 활용해 노코드 빌딩을 시작하고 커뮤니티의 노코드 빌더들과 함께 성장해요!

버블 vs 플러터플로우

by 박재은 🫧

최근 제가 프로젝트 하나를 마무리지었는데요. 노코드 빌더^^로서 독특하고 또 나누면 도움이 될만한 경험이어서 오랜만에 글을 씁니다.

참고로 저는 많은 개발자들과 함게 실개발로 서비스를 런칭하고 시리즈 A 단계까지 투자를 받았었어요.
그리고 지금은 노코더로 돌아와있다는 점을 참고하시면 이 글이 도움이 될 것 같습니다.

최근 진행한 프로젝트는 한국용은 아니고 일본용이었습니다.
서비스는 CMS(Contents Management System)라고 하여 디지털 사이니지에 영상을 원격으로 송출, 관리(스케줄, 트리거에 따라 영상 변화)하고 실시간 유동인구 데이터를 분석해 그에 맞는 맞춤형 영상을 실시간으로 트리거하는 서비스입니다.

일본 회사와 합작으로 개발을 한거지만 약 80%정도는 제가 진행했습니다.

실제로 여기에 사용된 툴은,
버블, 플러터플로우, 플러터, Node.js, PHP, AWS, Supabase가 되겠습니다.
복잡합니다만 다 나름의 이유가 있었습니다.

처음은 버블로 시작했습니다.
다만, DB와 스토리지는 일본회사의 요청에 따라 AWS tokyo region으로 시작했습니다.
AWS와는 API로 연결했어요. 버블은 프론트와 schedule trigger를 위한 용도로 사용했습니다.
서비스를 위에 설명한 것처럼 리눅스 기반의 하드웨어인 셋톱박스와 통신을 해야했고
스트리밍 방식으로 영상을 송출하고 실시간 데이터에 따라 실시간으로 영상 송출, 변화를 관리해야 했기에
버블을 썼어도 상당히 복잡한 로직과 설계를 가진 서비스입니다.
플러그인도 여러 테스트를 거쳐가며 사용했고,
버블에서 도저히 구현이 안되는 것들은 javascrip를 구현해서 포함시켰습니다.
어쨌든 적어도 프론트는 100% 버블로만 작업했습니다.

그러던 어느 날,
합작 일본 회사가 투자를 중간에 받게 되었는데 이 투자사의 조건이 프로그램의 모든 소스를 외부가 아닌 내부 서버(즉, AWS)에서 관리해야 한다는 것이었습니다.
보안 이슈, 그리고 사후 관리 이슈라니 이해는 했지만 이미 3개월에 걸쳐 만든 것을...

출시는 얼마 남지 않았고 이걸 다 다시 코드로 옮기자니 도저히 출시날짜를 맞출 수는 없었어요.
버블은 코드 출력이 되질않고 버블의 서버도 물론, AWS이지만 다른 백엔드 서비스처럼 리전을 설정할 수 없다는게 여기서 치명타가 되어버리고 말았죠.
딱 한시간정도를 고민했습니다.
출시까지 남은 시간은 한달도 안 남았고 개발자를 동원해서 한다고 해도 시간상 도저히 가능한 일정이 나오지 않았습니다.
그래서 플러터플로우를 쓰기로 결심했습니다.
이유는 딱 하나입니다.
플러터플로우로 만들면 코드출력이 가능해서 플러터에서 약간의 수정 후 빌드만 하면 바로 웹서버로 올려 서비스를 할 수 있다는 점이었습니다.

그나마 다행인건 디자인은 피그마로 만들어져 있었어요. (버블은 피그마 임포트가 정말 최악의 경험.....!!)
플러터플로우를 만져봤기에 망정이지^^
피그마는 아주 완벽하게 임포트가 되어서 디자인은 거의 건드릴 부분이 없었고, 그저 버블의 모든 워크플로우를 플러터플로우의 액션으로 대체하는 작업을 시작했습니다.
제가 아래에 버블과 플러터플로우 비교를 경험에 비추어 써 드리겠습니다^^

일주일 정도 걸려 플러터플로우로 완성이 되었고 코드 출력 후 플러터에서 불러와서 빌드하기위한 수정을 했습니다.
이건 정말 몇 시간 안 걸리더군요. 그 후 빌드를 하고 그대로 웹서버에 올렸고 모든 것이 정상으로 동작했습니다.
결국 모든 코드가 웹서버에 올라간거죠.
Supabase를 쓰는 이유는 AWS만으로 불안해서 서브 서버로 쓰기 위해 모든 api동작이 두 서버로 나누어서 가게 해 놓았습니다.
플러터플로우가 Firebase 아니면 Supabase와는 찰떡궁합이니까요.

지금 버블은 열심히 작업한 흔적만 잘 남아있습니다. 개인적으로는 아쉬움이 많아요.
사실 자랑스럽게 이거 버블로 다 만든거다 이런 자랑을 하고 싶었는데 말이죠.
PHP는 일본 개발자가 작업한 툴이었고 Node.js는 웹서버에 백엔드 서버를 구축하는데 썼습니다.

이제 버블과 플러터플로우를 순전히 제 경험관점에서 비교해 보겠습니다.

에디터 디자인은 플러터플로우가 더 좋습니다. 직관성은 둘 다 비슷하나 뭔가 디자인스러움은 버블이 좀 떨어집니다. 이건 중요한 비교점은 아니고요^^

생각을 쉽게 표현해주는 건 버블이 한수위입니다. 버블은 어떤 로직을 구현할 때 그저 에디터에서 그 후에는 나오는 operator를 선택하고 그에 맞는 조건만 넣어주면 되기에 타자만 잘 친다면 마우스조차 안 만져도 될 정도로 잘 되어 있습니다. 플러터플로우는 조건식 하나를 넣으려 해도 하부 창이 열려서 마우스와 키보드를 여러 번 왔다갔다 해야하고 어느 순간에는 내가 지금 어느 정도 depth에 있는지도 헷갈립니다. 디자인은 좋아요 ㅎㅎ 하지만 디자인이 기능을 감추었어요.

구현력은 둘이 비슷합니다. 둘 다 웬만한 상상한 것들을 어떤 식으로든 구현이 가능합니다.

버블이 구현 옵션이 더 좋습니다.
버블은 이런저런 방법을 쓸 수 있고 필요할 때는 플러그인을 가져다 쓰면 됩니다.
플러터플로우는 코드를 넣으면 됩니다 ㅡ.ㅡ 노코드 툴인데 커스텀 코드를 넣으라고 당당히 홍보합니다.
다만, 최신 버전의 플러터플로우는 코드 생성을 AI가 해줍니다.
그래서 조금 쉬운면도 있었습니다.
API로 불러온 필드가 string(문자열) 타입인데 버블은 API 커넥터에서 response에서 타입을 바꾸어주면 되는데 플러터 플로우는 이런 옵션이 없습니다. 그래서 커스텀 코드를 만들어서 해결했습니다..

버블의 에디터는 시간이 지날수록 점점 느려지죠. 아니어도 좀 느립니다.
앱을 열 때도 느리고 다른 탭을 누를 때도 작업량이 많아지면 계속 느려집니다.
쉰다고 생각하고 브라우저 새로고침을 해 보지만 그래도 기다림이 계속됩니다.
플러터플로우도 에디터가 약간 무언가 버벅댄다는 느낌을 지울 수는 없지만 버블보다는 낫습니다.
적어도 에디터에서 기다림은 없습니다.

하지만 다른 곳에서 기다려야 합니다.
버블은 작업 중간마다 프리뷰를 눌러 작업결과물을 볼 수 있습니다. 이 과정이 몇 초 정도면 됩니다.
플러터플로우는 작업 결과물 프리뷰가 세 가지가 있습니다.
프리뷰모드, 테스트모드, 런모드.
프리뷰모드는 말 그대로 프리뷰인데 그냥 디자인만 보는 곳입니다. 액션이 안 먹습니다. ㅡ.ㅡ
프리뷰와 런모드는 액션이 다 가능한 모드인데 이게 한번 여는 데 1~2분이 걸립니다.
코드를 빌드하고 빌드한 걸 보여주느라 그렇습니다. 문제는 테스트 모드는 30분이 제한 시간입니다.
30분이 지나면 또 1~2분을 기다려 다시 열어야 합니다. 작업 결과물을 보는 데 인내가 필요합니다.
마치 서버에 올려 보는 느낌입니다. 게다가 테스트모드는 디자인 결과가 실제와 좀 다릅니다 ㅡ.ㅡ
색감이라든가, 위치라든가. 런모드는 또 이상없습니다. 이게 제일 힘들었습니다.

>>>> 제가 이 글을 올리고 불과 몇 시간만에 플러터플로우에서 새 업데이트 공지가 왔는데 로컬런모드를 출시했네요. 플러터플로우 앱을 다운받고 flutter SDK를 쓰는 방식입니다. 로딩 시간, 시간제한이 없어졌습니다. 플러터플로우가 공격적으로 업데이트한다는 소문이 사실인가봅니다.

플러터플로우는 모바일 지원 기능이 아주 강력합니다. 버블은 이것이 한계입니다.
버블에서는 새로 네이티브 모바일 지원을 하겠다고 발표하고 준비중이라고 하지만 기다려봐야합니다.
플러터플로우에는 모바일 앱을 만들기 위한 대부분의 기능이 탑재되어 있습니다.
그렇다고 플러터플로우가 모바일만 되는것은 아닙니다. 오리지널 플러터처럼 웹, 앱이 모두 가능한 크로스플랫폼입니다.
반응형도 쉽게 보고 쉽게 만들 수 있습니다.
모바일 네이티브 기능은 기본적으로 모두 가지고 있습니다. 그래서 모바일 빌드가 아주 쉽습니다.
버블은 래핑이라는 과정을 거쳐야 하지만 플러터플로우는 바로 앱 출시가 가능합니다. 웹뷰 방식의 빌드가 아니고,
실제로 플러터의 dart코드로 빌드하는 것이기에 네이티브로 출시가 가능합니다.

버블은 요금제에 db, 스토리지, 백엔드 스케줄, API 등이 모두 포함되어 있습니다.
플러터플로우는 백엔드, db, 스토리지를 별도로 제공하지 않습니다.
Firebase나 Supabase와는 바로 연동이 되고 내부에서 CRUD가 아주 쉽습니다.
API도 당연히 지원합니다.
하지만 별도의 백엔드를 써야해서 요금이 이중으로 나갑니다.
이미 서버를 쓰고 있는게 있다면야 문제가 없겠지만 비용계산을 잘 하셔야 합니다.
또한, 스케줄러나 recurring 같이 백엔드에서 수행해야 할 작업을 플러터플로우는 지원하지 않습니다.
이건 별도의 백엔드 서비스를 이용해서 구축해야 합니다.

페이지 로딩속도는 당연 플러터플로우가 훨씬 빠릅니다.
별도의 웹서버를 쓰지 않는 이상 플러터플로우도 도메인을 연결하여 쓸 수 있습니다.
똑같은 페이지를 만들어 로딩을 해 보면 초기 로딩이나 웹, 앱의 반응속도는 플러터플로우가 빠릅니다.
버블로 만든 웹을 개발자도구로 열어보면 기본적으로 장착된 버블의 코드들이 많습니다.
이런 것들이 속도를 저하시키는 요인이 되기도 합니다. 이건 버블측에서도 인정한 사실입니다.
그래서 최근에 js 코드를 최적화하여 속도를 개선했다는 공지도 있었습니다.
플러터플로우도 비슷한 방식이지만 여기는 아예 코드 자체를 빌드하여 퍼블리싱을 하기에
조금 더 네이티브하다고 볼 수 있습니다.

지금까지 제 경험에 비추어 썼습니다. 어느 쪽을 더 옹호하는 건 아니니 오해 마시기 바랍니다^^
결론은, 결국 내가 어떤 서비스를 어느 단계에서 어떻게 할 것이냐에 따라 결정을 하면 좋겠습니다.
이 결정에는 자금력, 서비스를 이용하는 동접자수, 서비스의 형태에 따라 다 다르기에
이게 더 좋다라는 건 어렵습니다. 저희는 두 가지를 경우에 맞추어서 다 쓰고 있습니다.
저희도 구독 서비스이지만 B2B이다보니 구축형을 원하는 경우가 있어 이런 경우는 코드출력이
가능한 플러터플로우로 구축하고요, 구독형은 버블에서 서비스하고 있습니다.

시간날 때 한번씩 써 보시고 경험해 보시면 좋겠습니다.

개인적으로 둘 다 학습곡선은 꽤 있습니다^^

더 읽어볼 만한 글 ✍🏻

한 주 동안 올라온 흥미로운 이야기 🫧

Q. 여기어때 같은 펜션,숙소 예약+결제 플랫폼을 제작하려고 하는데 버블로 가능할까요?

아직 기획이 다 된건 아니지만
구현하고 싶은 플랫폼은 아래와 같습니다.

[버블박스] 클립보드 복사 플러그인

플러그인 한 줄 요약
특정 내용을 클립보드로 카피해 사용할 수 있게 하는 플러그인입니다.

버블 요금제 시뮬레이션 엑셀tool

오늘은 버블 개발이 잘 안 되어서;;; 스트레스 받다가...
유저가 얼마나 방문한다면 요금제를 바꿔야할까?
라는 생각에
시뮬레이션용 엑셀을 만들어 보았습니다

Q. 데이터 베이스 구성 고민

스포츠 클럽을 만들고 클럽원들의 신청을 받아서 허가해주고, 클럽원들의 매치 기록을 남기는 서비스를 가볍게 제작하려고 합니다.
현재 고민중인 부분은 클럽을 누구나 만들 수 있는데, 생성된 A클럽의 데이터 베이스 구조를 어떻게 가져가야할지 고민입니다.

모두의노코드 구경가기