Bubble.io Backend Workflows 활용법｜예약 실행과 반복 작업 자동화 설정

Bubble.io로 서비스를 만들다 보면 사용자가 버튼을 누르는 즉시 모든 작업을 처리할 필요가 없는 경우가 있습니다.

예를 들어 회원가입 직후 3일 뒤 안내 메시지를 보내거나, 결제되지 않은 주문을 일정 시간이 지난 뒤 확인하거나, 매일 새벽 오래된 데이터를 정리하는 작업입니다.

이런 처리를 화면의 일반 Workflow에 계속 넣으면 사용자가 페이지를 열어둔 상태에 의존하거나 프론트 화면과 서버 작업이 뒤섞이기 쉽습니다.

이럴 때 살펴볼 기능이 Backend Workflows입니다.

Backend Workflow는 언제 사용할까?

일반적인 페이지 Workflow는 사용자의 행동과 연결되는 경우가 많습니다.

예를 들어,

사용자가 버튼 클릭
↓
데이터 저장
↓
화면 변경

같은 흐름입니다.

반면 Backend Workflow는 사용자가 해당 페이지를 계속 보고 있지 않더라도 서버 측에서 처리해야 하는 작업을 구성할 때 유용합니다.

예를 들어 주문이 만들어졌다고 가정해보겠습니다.

결제하지 않은 주문을 30분 뒤 다시 확인하고 싶다면 다음처럼 생각할 수 있습니다.

주문 생성
   ↓
30분 뒤 Backend Workflow 예약
   ↓
결제 상태 확인
   ↓
미결제라면 필요한 처리 실행

여기서 중요한 것은 30분 동안 Workflow가 계속 실행되는 것이 아니라 미래 시점에 실행할 작업을 예약한다는 개념입니다.

먼저 Backend Workflows를 사용할 수 있게 설정합니다

Bubble 편집기에서 Backend Workflows를 사용하려면 관련 API/Backend Workflow 기능이 활성화되어 있어야 합니다.

설정 위치나 명칭은 Bubble 업데이트에 따라 달라질 수 있으므로 현재 편집기의 Settings에서 Backend/API Workflow 관련 옵션을 확인합니다.

활성화하면 Workflow 영역에서 Backend Workflows를 구성할 수 있습니다.

처음 테스트한다면 복잡한 자동화부터 만들지 말고 간단한 데이터 변경 작업 하나로 시작하는 편이 좋습니다.

예제 1: 주문 생성 30분 후 상태 확인하기

Order 데이터 타입이 있다고 가정하겠습니다.

속성은 간단하게 구성합니다.

Field	Type
user	User
status	text
created_date	date
payment_complete	yes/no

주문이 생성될 때 payment_complete = no 상태라고 가정합니다.

우리가 원하는 것은 30분 뒤에도 결제가 완료되지 않았다면 주문 상태를 변경하는 것입니다.

Backend Workflow에 예를 들어 다음과 같은 API Workflow를 만듭니다.

check_unpaid_order

Parameter에는 다음을 전달합니다.

order → Order

그리고 Workflow 내부에서 조건을 확인합니다.

Only when
order's payment_complete is "no"

조건을 만족하면

Make changes to order
status → 결제 확인 필요

와 같이 처리할 수 있습니다.

30분 뒤 실행되도록 예약합니다

이제 주문이 생성되는 Workflow로 이동합니다.

주문을 만든 직후 Backend Workflow를 바로 실행하는 것이 아니라 미래 시점으로 예약합니다.

개념적으로는 다음 구조입니다.

Create a new Order
        ↓
Schedule API Workflow
        ↓
Scheduled date =
Current date/time + 30 minutes
        ↓
order = Result of step 1

이렇게 하면 주문을 만든 사용자가 30분 동안 페이지를 열어놓고 있을 필요가 없습니다.

예약된 시간이 되었을 때 Backend Workflow에서 다시 주문 상태를 확인합니다.

여기서 중요한 것은 ‘다시 확인’입니다

30분 뒤 무조건 주문을 미결제로 바꾸면 안 됩니다.

그 사이 사용자가 정상적으로 결제를 완료했을 수 있기 때문입니다.

따라서 예약 작업이 실행되는 시점에 현재 상태를 다시 확인해야 합니다.

잘못 만든 구조는 다음과 같습니다.

주문 생성
↓
30분 뒤
↓
무조건 미결제 처리

더 안전한 구조는 다음과 같습니다.

주문 생성
↓
30분 뒤 Workflow 실행
↓
현재 payment_complete 확인
↓
NO인 경우에만 처리

자동화에서는 예약할 당시의 상황보다 실제 실행되는 시점의 데이터 상태를 다시 확인하는 것이 중요합니다.

예제 2: 3일 뒤 회원에게 안내 처리하기

회원가입 후 일정 시간이 지나면 후속 작업을 실행해야 하는 서비스도 있습니다.

예를 들어 가입 3일 후 아직 프로필을 완성하지 않은 사용자를 확인한다고 해보겠습니다.

구조는 비슷합니다.

회원가입 완료
↓
3일 후 Backend Workflow 예약
↓
프로필 상태 확인
↓
미완성 사용자만 후속 처리

이때도 3일 후 무조건 실행보다는 조건을 다시 확인하는 것이 좋습니다.

3일 사이 사용자가 프로필을 이미 완성했을 수 있기 때문입니다.

반복 작업은 단순 Delay와 다릅니다

여기서 많이 헷갈리는 부분이 있습니다.

한 번만 미래에 실행하는 작업과 계속 반복하는 작업은 구분해야 합니다.

예를 들어,

주문 생성 30분 후 확인

은 특정 이벤트를 기준으로 한 번 예약하는 작업입니다.

반면

매일 오래된 주문 확인

은 반복 작업에 가깝습니다.

개념적으로 보면 다음과 같습니다.

예약 작업
주문 생성 → 30분 후 한 번 실행

반면 반복 작업은

매일 지정된 시점
↓
조건에 맞는 데이터 확인
↓
필요한 작업 실행
↓
다음 실행

처럼 생각할 수 있습니다.

Bubble의 반복 작업을 무조건 ‘Cron Job’이라고 보면 안 됩니다

기존 글 제목에는 Cron Job이라는 표현이 들어가 있습니다.

개념적으로 이해하기 쉽지만 Bubble의 Backend Workflow가 Linux 서버에서 사용하는 crontab과 완전히 동일한 것은 아닙니다.

따라서 글에서는 “서버에서 cron 명령어를 직접 등록한다”는 식으로 설명하지 않는 것이 좋습니다.

Bubble이 제공하는 Backend Workflow 및 예약·반복 실행 기능을 이용해 Cron Job과 비슷한 목적의 정기 작업을 구성한다고 이해하는 편이 정확합니다.

그래서 제목도 다음처럼 바꾸는 것을 추천합니다.

Bubble.io Backend Workflows 활용법｜예약 실행과 반복 작업 자동화 설정

반복 작업을 만들 때 조심할 점

매일 전체 주문을 검사하는 자동화를 만든다고 생각해보겠습니다.

처음에는 주문이 100건뿐이라 문제가 없어 보입니다.

하지만 서비스가 커져 주문이 수만 건이 되었다면 매번 모든 데이터를 검색하고 변경하는 방식이 적절한지 다시 살펴봐야 합니다.

예를 들어 정말 필요한 데이터가

status = 미결제

인 주문이라면 처음부터 필요한 조건으로 검색 범위를 좁힐 수 있는지 검토합니다.

즉,

전체 주문 조회
↓
하나씩 미결제 여부 확인

보다는 가능한 범위에서

처리가 필요한 주문 검색
↓
대상만 처리

하는 구조가 관리하기 좋습니다.

한 번에 너무 많은 데이터를 처리하지 않습니다

Backend Workflow라고 해서 모든 작업을 한 번에 처리하는 것이 항상 좋은 것은 아닙니다.

대량 데이터를 수정해야 한다면 작업량과 Bubble의 현재 실행 정책, Workflow Units 사용량 등을 함께 고려해야 합니다.

특히 반복 작업이 예상보다 자주 실행되거나 검색 범위가 너무 넓으면 비용과 성능에도 영향을 줄 수 있습니다.

따라서 실제 서비스에서는 작은 데이터로 먼저 테스트한 다음 처리 범위를 늘리는 것이 좋습니다.

Backend Workflow가 실행되지 않을 때

설정했는데 아무 일도 일어나지 않는다면 바로 Workflow 전체를 다시 만들기보다 단계별로 확인합니다.

첫 번째는 실제로 예약이 생성됐는지입니다.

두 번째는 실행 조건(Only when)이 만족되는지입니다.

세 번째는 전달한 Parameter가 정상적인 데이터인지입니다.

네 번째는 Privacy Rules나 데이터 접근 조건 때문에 필요한 데이터를 읽지 못하고 있지는 않은지 확인합니다.

그리고 개발 환경과 Live 환경을 혼동하지 않았는지도 살펴봅니다.

테스트에서는 정상인데 실제 서비스에서는 작동하지 않는다면 환경별 데이터와 배포 상태도 확인할 필요가 있습니다.

중복 실행도 반드시 생각해야 합니다

자동화에서 의외로 자주 생기는 문제가 중복입니다.

사용자가 주문 버튼을 두 번 누르거나 다른 Workflow에서도 동일한 Backend Workflow를 예약한다면 같은 주문에 작업이 두 번 실행될 수 있습니다.

예를 들어 포인트 지급 자동화라면 중복 실행이 상당히 큰 문제가 됩니다.

그래서 중요한 작업이라면 데이터에 처리 상태를 기록하는 방법을 생각해볼 수 있습니다.

point_processed = no

Backend Workflow가 실행될 때 먼저 확인하고 정상적으로 처리된 뒤

point_processed = yes

로 변경하는 방식입니다.

이렇게 하면 Workflow가 다시 실행되더라도 이미 처리한 작업인지 확인할 수 있습니다.

실패했을 때 다시 실행해도 괜찮은 구조가 좋습니다

자동화는 항상 성공한다고 가정하면 위험합니다.

네트워크 문제나 외부 API 오류, 데이터 상태 변경 등 예상하지 못한 상황이 발생할 수 있습니다.

그래서 중요한 Backend Workflow는 한 번 실패했다가 다시 실행되어도 데이터가 망가지지 않는 구조인지 생각해야 합니다.

예를 들어 쿠폰을 발급하는 작업이라면

쿠폰 존재 여부 확인
↓
없으면 생성

방식이

실행될 때마다 쿠폰 생성

보다 안전합니다.

이런 방식은 자동화가 커질수록 중요해집니다.

실제 자동화 설계 순서

저라면 Backend Workflow를 만들 때 다음 순서로 확인합니다.

1. 언제 실행해야 하는가?
        ↓
2. 한 번인가, 반복인가?
        ↓
3. 어떤 데이터를 전달할 것인가?
        ↓
4. 실행 시점에 어떤 조건을 다시 확인할 것인가?
        ↓
5. 중복 실행을 어떻게 막을 것인가?
        ↓
6. 실패하면 다시 실행해도 안전한가?

단순히 Schedule 버튼을 사용하는 것보다 이 구조를 먼저 결정하는 것이 중요합니다.

마무리

Bubble.io의 Backend Workflows는 사용자가 화면을 보고 있지 않아도 처리해야 하는 예약 작업이나 반복적인 서버 측 작업을 구성할 때 유용합니다.

하지만 30분 뒤 실행, 매일 실행을 설정하는 것만으로 자동화가 완성되는 것은 아닙니다.

실제 실행 시점의 상태를 다시 확인하고, 같은 작업이 중복되지 않도록 처리하고, 실패 후 재실행되어도 문제가 없는 구조를 만드는 것이 중요합니다.

처음에는 주문 한 건 → 5분 뒤 상태 확인 → 조건에 맞으면 상태 변경 정도의 작은 테스트부터 만들어보세요.

정상적으로 동작하는 것을 확인한 뒤 반복 실행과 대량 데이터 처리로 확장하는 편이 안전합니다.