Bubble.io Option Sets 활용법｜반복 DB 조회를 줄이는 캐싱·성능 최적화 전략

2026년 9월 22일 읽는 시간 약 13분

Bubble.io로 서비스를 만들다 보면 카테고리, 회원 등급, 주문 상태처럼 거의 변하지 않는 값을 화면에서 반복해서 불러오는 경우가 많습니다. 이러한 값까지 매번 데이터베이스에서 검색하면 페이지 로딩 속도가 느려지고 Workload Unit(WU) 사용량도 불필요하게 증가할 수 있습니다.

이럴 때 활용할 수 있는 기능이 Option Sets입니다. 변경이 거의 없는 정적 데이터를 Option Sets으로 분리하면 반복적인 DB 조회를 줄이고 앱의 반응 속도를 개선할 수 있습니다.

Option Sets이란?

Option Sets은 데이터베이스와 비슷한 구조로 정적 데이터를 관리하는 Bubble.io의 기능입니다.

일반 데이터 타입과 달리 Option Sets 데이터는 앱의 소스 코드에 포함됩니다. 사용자의 기기에 캐시되기 때문에 값을 불러올 때마다 서버의 데이터베이스를 검색하지 않아도 됩니다.

대표적으로 다음과 같은 데이터에 적합합니다.

회원 등급: 일반회원, 프리미엄, 관리자
주문 상태: 결제 대기, 결제 완료, 배송 중, 배송 완료
상품 카테고리: 식품, 가전, 생활용품
게시물 공개 상태: 공개, 비공개, 임시 저장
요일과 월
색상과 아이콘
앱에서 사용하는 고정 메뉴

반대로 사용자가 직접 추가하거나 자주 수정해야 하는 데이터는 일반 Data Type으로 관리해야 합니다.

반복 DB 조회가 성능에 미치는 영향

예를 들어 상품 등록 페이지의 카테고리 선택창에 다음과 같은 검색식을 사용했다고 가정해 보겠습니다.

Search for Categories

페이지가 열릴 때마다 Category 데이터 타입을 검색해야 합니다. 같은 검색을 여러 페이지나 워크플로에서 반복하면 서버 요청이 늘어납니다.

Bubble은 같은 페이지에 있는 동일한 검색을 한 번으로 통합하기도 합니다. 그러나 새로운 페이지로 이동하거나 페이지를 새로고침하면 해당 검색은 새로운 조회로 처리됩니다. 워크플로 안의 검색 역시 워크플로가 실행될 때마다 다시 수행될 수 있습니다.

카테고리처럼 자주 변경되지 않는 값을 Option Sets으로 옮기면 다음처럼 사용할 수 있습니다.

All Product Categories

이 방식은 데이터베이스를 검색하는 것이 아니라 앱에 포함된 Option Sets 목록을 불러옵니다. 따라서 단순한 선택 항목을 표시하기 위해 반복적인 DB 요청을 발생시키지 않습니다.

Option Sets 만드는 방법

Bubble 편집기에서 다음 순서로 설정할 수 있습니다.

왼쪽 메뉴에서 Data를 선택합니다.
Option sets 탭으로 이동합니다.
New option set을 눌러 이름을 입력합니다.
필요한 Option을 추가합니다.
필요한 경우 Attribute를 추가합니다.

상품 상태를 예로 들면 다음과 같이 구성할 수 있습니다.

Option Set 이름

Product Status

Options

판매 중
품절
판매 중지
출시 예정

Attributes

label: 화면에 표시할 이름
color: 상태별 표시 색상
sort_order: 정렬 순서
is_active: 사용 여부

단순히 텍스트만 저장하는 것보다 색상, 아이콘, 정렬값 등을 Attribute로 함께 관리하면 여러 페이지에서 동일한 디자인 규칙을 재사용하기 편합니다.

Dropdown에 적용하는 방법

상품 상태를 선택하는 Dropdown을 만든다면 다음과 같이 설정합니다.

Choices style: Dynamic choices
Type of choices: Product Status
Choices source: All Product Statuses
Option caption: Current option’s label

기존 Data Type을 사용했다면 Do a search for Product Statuses가 필요하지만, Option Sets에서는 검색 없이 전체 목록을 바로 사용할 수 있습니다.

특정 값만 표시하려면 다음과 같이 필터링할 수 있습니다.

All Product Statuses:filtered

예를 들어 is_active 값이 yes인 상태만 선택창에 나타나도록 만들 수 있습니다. 다만 Option Sets의 항목 수가 지나치게 많으면 브라우저에서 처리해야 할 데이터도 함께 증가하므로 소규모 정적 목록에 사용하는 것이 좋습니다.

Custom State와 함께 사용하는 캐싱 전략

Option Sets이 아닌 일반 데이터까지 모두 Option Sets으로 바꿀 수는 없습니다. 실시간으로 변경되는 상품, 주문, 사용자 정보는 여전히 데이터베이스에서 불러와야 합니다.

이때는 검색 결과를 페이지나 그룹의 Custom State에 저장해 재사용하는 방식이 유용합니다.

예를 들어 페이지가 열릴 때 한 번만 상품 목록을 검색한다고 가정해 보겠습니다.

1단계: Custom State 생성

페이지에 다음 Custom State를 추가합니다.

State 이름: cached_products
State 타입: Product
This state is a list: yes

2단계: 페이지 로딩 시 데이터 저장

Page is loaded 워크플로에서 다음 작업을 실행합니다.

Set state → cached_products = Search for Products

3단계: 여러 요소에서 재사용

각 Repeating Group이나 통계 영역에서 다시 Search for Products를 실행하지 않고 다음 값을 사용합니다.

Page's cached_products

필요한 목록은 기존 상태에서 필터링합니다.

판매 중 상품: Page's cached_products:filtered
상품 개수: Page's cached_products:count
첫 번째 상품: Page's cached_products:first item

이 구조는 같은 페이지 안에서 동일한 데이터를 여러 요소가 사용할 때 효과적입니다.

하지만 Custom State는 브라우저에 임시로 보관되는 값입니다. 데이터베이스 내용이 변경되어도 자동으로 최신 상태가 반영되지 않을 수 있으므로 저장이나 삭제 작업을 마친 뒤에는 State를 다시 설정해야 합니다.

Group을 활용한 데이터 재사용

검색 결과가 한 개의 데이터라면 Custom State 대신 Group의 Data source를 사용할 수도 있습니다.

예를 들어 현재 로그인한 사용자의 회사 정보를 여러 요소에서 사용한다면 상위 Group에 다음과 같이 설정합니다.

Type of content: Company
Data source: Current User’s Company

그룹 내부에서는 별도의 검색 없이 다음과 같이 참조합니다.

Parent group's Company's name

Parent group's Company's plan

Parent group's Company's logo

같은 데이터를 여러 요소에서 개별적으로 검색하는 것보다 상위 Group에서 한 번 받아 하위 요소가 공유하도록 구성하는 편이 관리하기 쉽습니다.

Option Sets과 Data Type 선택 기준

구분	Option Sets	Data Type
데이터 성격	고정된 정적 데이터	변경되는 동적 데이터
DB 검색	필요 없음	필요한 경우가 많음
사용자 수정	불가능	가능
변경 반영	앱 배포 후 반영	저장 즉시 반영
개인정보 저장	부적합	Privacy Rules 적용 가능
적합한 예	등급, 상태, 카테고리	회원, 주문, 상품, 게시물

판단 기준은 간단합니다.

운영자가 가끔 수정하고 모든 사용자에게 동일하게 제공되는 값은 Option Sets, 사용자 행동에 따라 생성·수정되는 값은 Data Type을 사용하는 것이 좋습니다.

자주 발생하는 잘못된 사용 사례

가격이나 재고를 Option Sets에 저장

가격과 재고는 수시로 변경될 수 있으므로 Data Type으로 관리해야 합니다. Option Sets은 사용자가 수정할 수 없으며 변경 내용을 실제 서비스에 반영하려면 다시 배포해야 합니다.

API Key를 Option Sets에 저장

Option Sets은 앱 코드에 포함되며 암호화되지 않습니다. 또한 Privacy Rules의 보호 대상도 아닙니다. 따라서 API Key, 관리자 비밀번호, 내부 인증값과 같은 민감한 정보는 절대 저장하면 안 됩니다.

수천 개의 데이터를 Option Sets으로 등록

Option Sets은 모든 페이지에서 다운로드되거나 기존 캐시 파일을 사용합니다. 항목이 지나치게 많으면 초기 파일 크기가 증가해 오히려 로딩 성능에 영향을 줄 수 있습니다.

Option Sets 변경 후 Live에서 바로 확인

개발 환경에서는 새로고침 후 변경값을 확인할 수 있지만, Live 앱에서는 배포와 페이지 새로고침이 필요합니다.

DB 검색을 추가로 줄이는 방법

Option Sets 적용과 함께 다음 항목도 점검하는 것이 좋습니다.

검색 조건은 처음부터 지정하기

전체 데이터를 가져온 후 :filtered로 처리하기보다 Do a search for의 Constraints에서 조건을 지정하는 편이 효율적입니다.

예를 들어 다음 구조보다

Search for Orders:filtered

다음과 같이 검색 단계에서 조건을 넣는 것이 좋습니다.

Search for Orders where Status = Product Status's 판매 중

Bubble 공식 문서에서도 데이터베이스 단계에서 처리되는 제약 조건이 데이터를 가져온 뒤 적용하는 고급 필터보다 일반적으로 빠르다고 설명합니다.

Repeating Group 셀마다 검색하지 않기

Repeating Group의 각 셀 안에서 Do a search for를 실행하면 화면에 표시되는 셀 수만큼 검색이 반복될 수 있습니다.

가능하면 다음 방식을 사용합니다.

필요한 데이터를 상위 검색에 포함하기
연결된 Thing의 필드를 직접 참조하기
첫 검색 결과를 Custom State에 저장하기
집계 결과를 별도 필드에 미리 저장하기

조건문의 DB 검색은 뒤에 배치하기

워크플로 조건에 로컬 값과 DB 검색이 함께 있다면 빠르게 확인할 수 있는 조건을 앞에 배치합니다.

예를 들면 다음 순서입니다.

Current User is logged in
버튼이 visible 상태인지 확인
필요한 경우에만 DB 검색 실행

앞의 조건이 false라면 뒤의 검색을 확인할 필요가 없어 불필요한 서버 요청을 줄일 수 있습니다.

적용 전후 구조 예시

적용 전

카테고리 Dropdown마다 Category 검색
주문 목록의 각 셀에서 Status 검색
여러 통계 영역에서 동일한 상품 검색 반복
상태 이름과 색상을 개별 조건으로 설정

적용 후

카테고리와 주문 상태를 Option Sets으로 관리
상태 이름·색상·정렬값을 Attribute로 통합
페이지에서 필요한 동적 데이터는 한 번 조회
조회 결과를 Custom State나 상위 Group에서 재사용
사용자 생성 데이터만 Data Type으로 유지

이렇게 구조를 변경하면 단순히 검색 횟수만 줄어드는 것이 아닙니다. 워크플로가 짧아지고 상태값 관리가 일관돼 유지보수도 쉬워집니다.

마무리

Bubble.io 성능 최적화는 모든 검색을 없애는 작업이 아닙니다. 데이터의 성격에 따라 저장 위치와 조회 방식을 구분하는 것이 핵심입니다.

카테고리, 등급, 상태처럼 거의 변경되지 않는 값은 Option Sets으로 관리하고, 실제 사용자 데이터는 Data Type에 저장해야 합니다. 동일 페이지에서 반복 사용하는 검색 결과는 Custom State나 Group의 Data source로 재사용하면 불필요한 DB 요청을 줄일 수 있습니다.

다만 Option Sets은 보안 저장소가 아닙니다. 개인정보나 인증 정보는 넣지 말고, 항목 수가 지나치게 커지지 않도록 관리해야 합니다. 이러한 기준을 적용하면 페이지 로딩 속도와 WU 효율을 함께 개선하면서 더 안정적인 Bubble.io 앱 구조를 만들 수 있습니다.