Bubble.io Server-side vs Client-side Workflow 차이｜어떤 작업을 어디서 처리해야 할까?

Bubble.io로 앱을 만들다 보면 Workflow에 기능을 계속 추가하게 됩니다.

버튼을 누르면 데이터를 저장하고, 검색 결과를 보여주고, 이메일을 발송하고, 외부 API까지 호출하는 식입니다.

처음에는 모두 같은 Workflow처럼 보이지만 앱이 커지면 사용자 화면에서 처리할 작업과 서버에서 처리할 작업을 구분해야 하는 상황이 생깁니다.

특히 대량 데이터 처리나 예약 작업, 외부 서비스 연동까지 추가된다면 이 구분이 더 중요해집니다.

이번 글에서는 Server-side와 Client-side를 단순히 정의하는 대신 실제 기능을 어디에 배치하면 좋은지 사례별로 살펴보겠습니다.

먼저 두 방식의 차이부터 이해합니다

간단하게 생각하면 Client-side는 사용자가 보고 있는 화면과 직접 연결된 처리, Server-side는 백엔드에서 처리할 필요가 있는 작업이라고 이해할 수 있습니다.

예를 들어 버튼을 눌렀을 때 팝업을 보여주는 작업은 화면과 직접 관련되어 있습니다.

버튼 클릭
   ↓
팝업 표시

반면 사용자가 페이지를 닫더라도 일정 시간이 지난 후 실행되어야 하는 작업은 Backend Workflow가 더 자연스러운 경우가 있습니다.

주문 생성
   ↓
Backend Workflow 예약
   ↓
30분 뒤 주문 상태 확인

둘 중 어느 방식이 무조건 우수한 것이 아니라 작업의 성격에 따라 선택하는 것이 핵심입니다.

사례 1. 버튼을 누르면 팝업을 보여준다

가장 단순한 상황입니다.

사용자가 상품 자세히 보기 버튼을 눌렀을 때 화면에 팝업을 표시한다고 해보겠습니다.

사용자 버튼 클릭
↓
팝업 표시

이 작업은 사용자가 보고 있는 페이지의 UI를 변경하는 것이 목적입니다.

이런 작업까지 별도의 Backend Workflow로 넘길 이유는 거의 없습니다.

페이지 요소를 표시하거나 숨기는 작업, 입력창을 초기화하는 작업 등 현재 화면에 즉시 반영되어야 하는 UI 작업은 페이지 Workflow에서 처리하는 것이 자연스럽습니다.

사례 2. 사용자가 게시글을 등록한다

이번에는 게시글 작성 버튼을 생각해보겠습니다.

사용자가 제목과 내용을 입력하고 등록을 누릅니다.

기본 구조는 다음과 같습니다.

등록 버튼 클릭
↓
입력값 확인
↓
Post 생성
↓
완료 화면 표시

이 역시 사용자의 행동에 즉시 반응해야 하는 부분이 많습니다.

하지만 글을 등록한 뒤 추가 작업이 여러 개 붙는다면 이야기가 달라집니다.

예를 들어,

Post 생성
↓
관리자 알림
↓
외부 API 호출
↓
이미지 후처리
↓
로그 기록

까지 한 번에 연결되어 있다고 가정해보겠습니다.

모든 후속 작업을 사용자가 기다려야 하는 Workflow에 넣는 것이 적절한지는 다시 검토할 필요가 있습니다.

사용자에게 즉시 필요한 작업과 뒤에서 처리해도 되는 작업을 분리하는 방법을 생각할 수 있습니다.

사례 3. 회원가입 후 이메일을 보낸다

회원가입 직후 환영 이메일을 발송한다고 해보겠습니다.

사용자에게 가장 중요한 것은 계정 생성이 정상적으로 완료되는 것입니다.

구조를 다음처럼 나눠 생각할 수 있습니다.

회원가입
↓
계정 생성 완료
↓
필요한 후속 작업 실행

후속 작업이 단순한 이메일 한 건이라면 구조가 복잡하지 않을 수 있습니다.

하지만 CRM 등록, 관리자 알림, 외부 API 호출, 로그 저장 등 여러 작업이 이어진다면 서버 측 작업으로 분리할 부분이 있는지 검토하는 것이 좋습니다.

중요한 것은 “Server-side가 무조건 빠르다”가 아니라 사용자가 기다려야 할 필요가 없는 작업을 구분하는 것입니다.

사례 4. 매일 오래된 데이터를 정리한다

이번에는 사용자의 버튼 클릭과 관계없는 작업입니다.

예를 들어 매일 일정한 기준을 만족하는 오래된 임시 데이터를 확인해야 한다고 가정해보겠습니다.

이런 작업은 특정 사용자가 페이지를 열고 있을 때만 실행되어서는 곤란합니다.

정해진 시점
↓
Backend Workflow 실행
↓
대상 데이터 검색
↓
조건 확인
↓
필요한 처리

이런 유형은 Server-side 처리를 검토하기 좋은 대표적인 사례입니다.

앞서 7번 글에서 다룬 Backend Workflows의 예약·반복 작업과도 연결되는 부분입니다.

사례 5. 대량 데이터 업데이트

관리자가 고객 데이터 1,000건의 상태를 변경한다고 가정해보겠습니다.

버튼을 누른 뒤 화면 Workflow 하나에서 모든 작업을 처리하도록 만들기 전에 작업량을 생각해야 합니다.

예를 들어,

1,000건 검색
↓
각 데이터 수정
↓
추가 API 요청
↓
완료

처럼 처리해야 한다면 단순한 UI 변경과는 성격이 다릅니다.

대량 작업에서는 처리 대상의 범위를 줄이고 작업을 나누거나 Backend Workflow를 활용할 수 있는지 검토하는 편이 좋습니다.

또 Bubble의 현재 Workflow Units 정책과 실행 제한도 함께 확인해야 합니다.

사례 6. 외부 API를 호출한다

외부 API 연동에서는 보안도 중요한 판단 기준입니다.

API Key나 민감한 인증정보가 필요한 작업이라면 브라우저에 노출될 가능성이 있는 구조인지 확인해야 합니다.

예를 들어 결제 서버, CRM, 내부 관리 API처럼 중요한 인증정보가 필요한 호출이라면 단순히 화면에서 호출할 수 있다는 이유만으로 Client-side에 두는 것은 적절하지 않을 수 있습니다.

민감한 키는 사용자에게 노출되지 않는 방식으로 관리해야 합니다.

즉 Server-side를 선택하는 이유가 단순한 성능 때문만은 아닙니다.

보안과 데이터 접근 방식도 중요한 판단 기준입니다.

로그인은 Client-side인가 Server-side인가?

이 부분도 헷갈리기 쉽습니다.

사용자가 로그인 버튼을 누르는 행위 자체는 페이지에서 시작됩니다.

이메일 입력
↓
비밀번호 입력
↓
로그인 버튼 클릭

하지만 그렇다고 인증과 관련된 모든 보안 처리를 개발자가 브라우저에 직접 구현해야 한다는 뜻은 아닙니다.

Bubble이 제공하는 인증 기능과 Privacy Rules를 적절하게 사용하는 것이 중요합니다.

특히 화면에서 안 보이게 만들었다고 데이터가 보호되는 것은 아닙니다.

민감한 데이터를 다루는 앱이라면 Privacy Rules를 별도로 점검해야 합니다.

화면에서 숨기는 것과 보안은 다릅니다

예를 들어 관리자만 볼 수 있는 고객 목록이 있다고 해보겠습니다.

일반 사용자에게 해당 Repeating Group을 숨겼다고 해서 그것만으로 데이터 접근 보안이 완성됐다고 생각하면 안 됩니다.

UI 표시 여부와 데이터 접근 권한은 별개의 문제입니다.

따라서 다음처럼 생각하는 편이 좋습니다.

화면 표시 제어
≠
데이터 접근 권한

민감한 데이터가 있다면 Privacy Rules와 데이터 구조를 함께 검토해야 합니다.

모든 작업을 Server-side로 옮기는 것도 정답은 아닙니다

Server-side라는 표현 때문에 더 전문적이고 빠른 방식처럼 느껴질 수 있습니다.

하지만 화면에서 바로 끝낼 수 있는 간단한 UI 작업까지 Backend Workflow로 만들면 오히려 구조가 불필요하게 복잡해질 수 있습니다.

예를 들어 다음과 같은 작업입니다.

팝업 열기

탭 변경

입력창 초기화

화면 상태 변경

이런 작업은 현재 페이지와 직접 연결되어 있습니다.

반대로 다음과 같은 작업은 Server-side 처리를 검토할 이유가 있습니다.

예약 실행

반복 작업

대량 데이터 처리

사용자가 페이지를 닫아도 계속되어야 하는 작업

민감한 인증정보를 사용하는 외부 API 처리

작업의 목적부터 구분하는 것이 좋습니다.

선택할 때 사용할 수 있는 기준

저라면 새로운 Workflow를 만들기 전에 다음 질문으로 구분합니다.

질문	검토 방향
현재 화면을 즉시 변경해야 하나?	Client-side
사용자가 기다려야 하는 결과인가?	Client-side 우선 검토
페이지를 닫아도 실행돼야 하나?	Server-side 검토
미래 시점에 실행해야 하나?	Backend Workflow
대량 데이터를 처리하나?	Server-side 구조 검토
민감한 API Key가 필요한가?	Server-side/보안 구조 검토
정기적으로 반복해야 하나?	Backend Workflow

이 표가 절대적인 규칙은 아닙니다.

실제 앱의 데이터 구조와 기능에 따라 달라질 수 있지만 처음 Workflow를 나눌 때 기준을 잡는 데는 도움이 됩니다.

Server-side로 옮겼는데도 느리다면?

작업 위치만 변경한다고 모든 성능 문제가 해결되는 것은 아닙니다.

예를 들어 Backend Workflow 안에서 매번 전체 데이터베이스를 검색한 뒤 불필요한 데이터를 대량으로 처리한다면 여전히 비효율적인 구조가 될 수 있습니다.

이때는 다음 항목을 함께 확인합니다.

검색 범위가 지나치게 넓지 않은가?

같은 데이터를 반복해서 조회하지 않는가?

불필요한 Workflow가 중복 실행되지 않는가?

한 번에 지나치게 많은 데이터를 처리하지 않는가?

외부 API를 필요 이상으로 반복 호출하지 않는가?

즉 성능은 Client vs Server 하나만으로 결정되지 않습니다.

실제로는 둘을 함께 사용합니다

Bubble 앱을 만들 때 Client-side와 Server-side 중 하나만 선택해야 하는 것은 아닙니다.

예를 들어 주문 기능이라면 다음처럼 구성할 수 있습니다.

[Client-side]

주문 버튼 클릭
↓
필수 입력값 확인
↓
주문 생성
↓
주문 완료 화면 표시


[Server-side]

주문 생성 후
↓
후속 Backend Workflow
↓
외부 시스템 처리
↓
필요한 알림
↓
로그 기록

사용자에게 필요한 반응은 빠르게 제공하면서 뒤에서 처리해도 되는 작업은 분리하는 구조입니다.

기능이 많아질수록 이런 역할 구분이 유지보수에도 도움이 됩니다.

마무리

Bubble.io에서 Server-side와 Client-side를 구분할 때 “어느 쪽이 더 빠른가?”만 생각하면 판단하기 어렵습니다.

먼저 작업의 목적을 확인하는 것이 좋습니다.

사용자가 보고 있는 화면을 바로 변경해야 한다면 페이지 Workflow가 자연스럽고, 사용자가 페이지를 닫더라도 처리해야 하거나 미래에 실행해야 하는 작업이라면 Backend Workflow를 검토할 수 있습니다.

그리고 대량 데이터나 외부 API가 포함되어 있다면 성능뿐 아니라 보안, 중복 실행, 실패 처리까지 함께 고려해야 합니다.

결국 좋은 Workflow 구조는 모든 작업을 서버로 옮기는 것이 아니라 사용자가 기다려야 하는 작업과 뒤에서 처리할 작업을 명확하게 나누는 것에서 시작합니다.