Bubble.io Data Architecture: Privacy Rules 및 Option Sets 최적화를 통한 DB 성능 향상

Bubble.io로 서비스를 만들다 보면 초기에는 빠르게 작동하던 앱이 데이터가 늘어나면서 점차 느려지는 경우가 있습니다. Repeating Group의 로딩 시간이 길어지거나, 페이지를 열 때마다 불필요한 데이터 검색이 반복되고, Workload 사용량이 예상보다 빠르게 증가하기도 합니다.

이러한 문제는 단순히 데이터가 많아서 발생하는 것이 아닙니다. 데이터베이스 구조를 어떻게 설계했는지, Privacy Rules를 어떤 조건으로 구성했는지, 고정 데이터를 Data Type과 Option Sets 중 어디에 저장했는지에 따라 성능 차이가 크게 벌어질 수 있습니다.

이번 글에서는 Bubble.io의 Privacy Rules와 Option Sets를 함께 활용해 보안은 유지하면서 데이터베이스 검색 부담을 줄이는 설계 방법을 알아보겠습니다.

---

Bubble.io 앱이 느려지는 주요 원인

Bubble.io에서 데이터 검색은 주로 Do a search for 표현식을 통해 실행됩니다. 검색 자체가 무조건 무거운 작업은 아니지만 다음 조건이 겹치면 속도와 Workload에 영향을 줄 수 있습니다.

• 검색 결과로 너무 많은 레코드를 불러오는 경우
• 같은 검색을 여러 요소와 워크플로에서 반복하는 경우
• 데이터베이스 검색 후 :filtered 또는 :advanced로 다시 필터링하는 경우
• 검색 조건 안에 또 다른 검색이 들어가는 경우
• 페이지를 열자마자 여러 개의 Repeating Group이 동시에 데이터를 요청하는 경우
• 변경되지 않는 분류값까지 매번 데이터베이스에서 검색하는 경우

Bubble 공식 문서에서도 검색 결과의 양, 검색 표현식의 복잡성, 실행 빈도를 주요 성능 요인으로 설명합니다. 특히 결과를 먼저 불러온 뒤 브라우저에서 필터링하는 방식보다 처음 검색할 때 제약조건을 적용하는 편이 효율적입니다.

---

Privacy Rules는 단순한 화면 숨기기 기능이 아니다

Privacy Rules는 사용자가 어떤 데이터를 검색하고, 확인하고, 수정할 수 있는지 서버 단계에서 제한하는 기능입니다.

예를 들어 프로젝트 관리 앱에 다음과 같은 데이터가 있다고 가정해 보겠습니다.

Project 데이터 타입

• name: 프로젝트 이름
• owner: 프로젝트 생성자
• members: 참여 사용자 목록
• status: 프로젝트 상태
• description: 프로젝트 설명
• internal_note: 관리자 메모

화면에서 관리자 메모를 숨겼다고 해서 데이터가 안전하게 보호되는 것은 아닙니다. 요소를 보이지 않게 만드는 조건은 UI 표시만 제어하기 때문입니다. 데이터 자체의 접근을 차단하려면 해당 Data Type에 Privacy Rules를 설정해야 합니다.

Bubble의 Privacy Rules는 조건을 충족하지 못한 사용자에게 서버가 데이터를 전달하지 않도록 제한합니다. 민감하거나 개인적인 정보가 들어 있는 데이터에는 반드시 적용해야 합니다.

---

프로젝트 데이터에 Privacy Rules 적용하기

Bubble 편집기에서 다음 순서로 이동합니다.

Data → Privacy → Project

그다음 사용자 유형에 맞는 규칙을 만듭니다.

규칙 1. 프로젝트 소유자

조건:

This Project's owner is Current User

권장 권한:

• View all fields
• Find this in searches
• Allow auto-binding이 필요한 경우에만 허용
• 첨부파일이 있다면 View attached files 검토

규칙 2. 프로젝트 참여자

조건:

This Project's members contains Current User

권장 권한:

• 업무에 필요한 필드만 표시
• Find this in searches 허용
• 관리자 전용 필드는 비공개

규칙 3. 관리자

조건:

Current User's role is Admin

권장 권한:

• 관리 업무에 필요한 필드
• Find this in searches
• 필요한 수정 권한

Everybody else

로그인하지 않았거나 프로젝트와 관계없는 사용자는 모든 권한을 해제합니다.

이렇게 설정하면 사용자가 페이지 주소를 직접 입력하거나 검색 표현식을 변경하더라도 허용되지 않은 프로젝트 데이터를 받을 수 없습니다.

---

Privacy Rules 조건은 가능한 한 단순하게 설계한다

Privacy Rules에 복잡한 동적 표현식을 사용하면 관리가 어려워질 뿐 아니라 검색 결과가 예상과 달라질 수 있습니다.

예를 들어 다음처럼 여러 단계를 거치는 조건이 있다고 가정해 보겠습니다.

This Project's Company's Owner's Team contains Current User

이 조건은 Project에서 Company로 이동하고, 다시 Owner와 Team을 확인해야 합니다. Bubble 공식 문서에 따르면 여러 단계로 연결된 참조를 Privacy Rule에 사용하면 검색 접근 권한을 부여하는 데 제한이 생길 수 있습니다.

가능하다면 자주 사용하는 접근 기준을 해당 데이터에 직접 저장하는 편이 관리하기 쉽습니다.

예를 들어 Project에 다음 필드를 추가할 수 있습니다.

• owner
• members
• organization
• visibility

그러면 Privacy Rule도 다음과 같이 단순해집니다.

This Project's organization is Current User's organization

다만 성능을 높이기 위해 접근 권한 데이터를 무조건 중복 저장하면 데이터 불일치가 생길 수 있습니다. 조직 변경이나 멤버 탈퇴 시 관련 레코드까지 함께 갱신되도록 워크플로를 구성해야 합니다.

---

Option Sets가 DB 성능을 높이는 이유

Option Sets는 자주 바뀌지 않는 고정값을 저장하는 기능입니다. 일반 Data Type과 비슷하게 속성을 만들 수 있지만 데이터베이스 검색 없이 사용할 수 있다는 차이가 있습니다.

Option Sets는 앱 코드의 일부로 사용자 기기에 내려가 캐시됩니다. 따라서 매번 서버의 데이터베이스를 검색할 필요가 없습니다. 다만 암호화되거나 Privacy Rules로 보호되지 않기 때문에 민감한 정보는 절대 넣으면 안 됩니다.

Option Sets에 적합한 데이터

• 회원 등급: 일반, 프리미엄, 관리자
• 주문 상태: 결제 대기, 결제 완료, 배송 중, 배송 완료
• 프로젝트 상태: 준비, 진행, 완료, 보류
• 게시물 공개 범위: 전체 공개, 회원 공개, 비공개
• 우선순위: 낮음, 보통, 높음
• 요일이나 고정된 카테고리
• 앱 내부에서 사용하는 권한 구분

일반 Data Type이 필요한 데이터

• 사용자가 직접 추가하거나 수정하는 카테고리
• 재고나 가격처럼 자주 변경되는 값
• 관리자가 실시간으로 운영해야 하는 항목
• Privacy Rules로 보호해야 하는 정보
• 주문, 결제, 회원정보 등 민감한 데이터
• 레코드별 변경 이력을 관리해야 하는 정보

---

Data Type과 Option Sets 선택 기준

구분	Option Sets	일반 Data Type
데이터 성격	고정된 값	계속 변경되는 값
데이터 조회	DB 검색 불필요	DB 검색 필요
사용자 수정	불가능	가능
변경 반영	앱 배포 필요	저장 후 바로 반영
Privacy Rules	적용되지 않음	적용 가능
민감정보 저장	부적합	보호 설정 후 가능
주요 용도	상태·등급·분류	회원·주문·게시물

핵심 기준은 간단합니다.

개발자가 정해 놓고 거의 변경하지 않는 값은 Option Sets, 사용자가 만들거나 운영 중 계속 바뀌는 값은 Data Type으로 구성합니다.

---

실제 적용 예제: 프로젝트 상태 최적화

프로젝트 상태를 별도의 Project Status Data Type으로 만들었다고 가정해 보겠습니다.

프로젝트 목록을 표시할 때마다 다음 검색이 필요할 수 있습니다.

Do a search for Project Statuses

상태 이름을 표시하기 위해 관련 데이터를 추가로 참조하면 검색 구조가 복잡해질 수도 있습니다. 하지만 프로젝트 상태가 진행 전, 진행 중, 완료, 보류처럼 고정되어 있다면 별도의 Data Type이 필요하지 않습니다.

Option Set 생성 방법

Data → Data types → Option sets → New option set

이름:

Project Status

Options:

• Pending
• In Progress
• Completed
• On Hold

Attributes:

• label: 사용자에게 표시할 한글 이름
• color: 상태별 색상 코드
• sort_order: 정렬 순서
• is_active: 사용 여부

Project Data Type에는 다음 필드를 만듭니다.

status – Project Status

이후 텍스트 요소에는 다음과 같이 표시할 수 있습니다.

Current cell's Project's status's label

상태를 고르기 위한 Dropdown의 Choices source는 다음처럼 설정합니다.

All Project Statuses

이 방식은 상태 목록을 가져오기 위한 별도의 Do a search for가 필요하지 않습니다.

---

Option Sets를 지나치게 많이 만들면 안 되는 이유

Option Sets가 빠르다고 해서 모든 기준정보를 옮기는 것은 바람직하지 않습니다.

Bubble 공식 문서에 따르면 Option Sets는 특정 페이지에서 사용하지 않더라도 앱에 포함된 전체 항목이 내려갈 수 있습니다. 따라서 수천 개의 상품, 지역, 우편번호 또는 자주 바뀌는 목록을 Option Sets로 구성하면 앱 파일이 불필요하게 커질 수 있습니다.

다음 데이터는 일반 Data Type이 더 적합합니다.

• 전국의 상세 주소 목록
• 수천 개의 상품 카테고리
• 관리자가 수시로 추가하는 태그
• 실시간으로 변경되는 요금제
• 외부 API에서 동기화하는 상태값
• 사용자별로 다르게 제공되는 목록

Option Sets는 ‘작고 고정된 목록’에 사용할 때 가장 효과적입니다.

---

검색 후 필터링보다 검색 조건을 먼저 적용한다

다음과 같은 표현식은 주의가 필요합니다.

Do a search for Projects:filtered

먼저 여러 프로젝트를 불러온 다음 필터링하면 불필요한 데이터가 포함될 수 있습니다. 가능한 조건은 검색창의 Constraints에 직접 넣는 것이 좋습니다.

개선 전

Do a search for Projects:filtered

조건:

This Project's status is In Progress

개선 후

Do a search for Projects

Constraint:

status = In Progress

또한 다음처럼 검색 안에 검색을 넣는 구조도 점검해야 합니다.

Do a search for Projects where owner is Do a search for Users:first item

이미 Current User나 Parent group을 통해 값을 알고 있다면 직접 참조하는 편이 단순합니다.

Do a search for Projects where owner = Current User

Bubble은 필터와 정렬을 원래 검색 단계에 가깝게 적용하는 방식을 권장합니다. :advanced는 특히 많은 레코드를 대상으로 사용할 경우 서버 부담이 커질 수 있습니다.

---

Repeating Group의 데이터 요청 줄이기

Repeating Group은 한 번에 많은 데이터를 표시할 수 있어 성능 문제가 자주 나타나는 요소입니다.

다음 방법으로 초기 데이터 요청량을 줄일 수 있습니다.

첫 화면에 필요한 데이터만 불러오기

페이지에 진입하자마자 전체 데이터를 가져오지 말고 사용자에게 필요한 범위만 검색합니다.

예시:

• Current User가 참여한 프로젝트만 검색
• 최근 30일 데이터만 검색
• 완료되지 않은 업무만 우선 표시
• 검색 버튼을 누른 후 결과 표시
• 탭을 열었을 때 해당 영역의 데이터 로딩

관련 데이터를 직접 전달하기

이미 Parent group에 Project 데이터가 있다면 같은 프로젝트를 다시 검색하지 않습니다.

개선 전:

Do a search for Projects:first item

개선 후:

Parent group's Project

직접 참조를 활용하면 중복 검색을 줄이고 표현식도 이해하기 쉬워집니다.

무거운 계산 결과는 미리 저장하기

주문 합계나 월별 통계처럼 자주 표시되지만 계산이 복잡한 값은 페이지를 열 때마다 다시 계산하지 않는 방법도 있습니다.

예를 들어 다음 필드를 별도로 저장할 수 있습니다.

• total_order_amount
• completed_task_count
• last_activity_date
• monthly_sales_summary

복잡한 집계는 Backend Workflow에서 계산한 후 결과만 화면에 표시하면 페이지 로딩 부담을 줄일 수 있습니다.

---

권장 데이터 구조 예시

User

• name: text
• role: User Role Option Set
• organization: Organization
• account_status: Account Status Option Set

Organization

• name: text
• owner: User
• members: List of Users

Project

• name: text
• organization: Organization
• owner: User
• members: List of Users
• status: Project Status Option Set
• priority: Priority Option Set
• description: text
• created_date: date

Task

• title: text
• project: Project
• assignee: User
• status: Task Status Option Set
• priority: Priority Option Set
• due_date: date

이 구조에서 상태와 우선순위는 고정값이므로 Option Sets로 관리하고, 프로젝트·업무·조직처럼 지속해서 생성되고 변경되는 정보는 Data Type으로 관리합니다.

Privacy Rules는 Project와 Task에 직접 연결된 owner, members, organization을 기준으로 구성할 수 있습니다.

---

최적화 전 확인해야 할 점

데이터 구조를 변경하기 전에 다음 항목을 점검해야 합니다.

• 해당 값이 운영 중 변경될 가능성이 있는가?
• 사용자가 직접 항목을 추가해야 하는가?
• 개인정보나 내부정보가 포함되는가?
• Privacy Rules가 필요한 데이터인가?
• 페이지가 열릴 때 같은 검색이 반복되는가?
• :filtered나 :advanced가 과도하게 사용되고 있는가?
• Repeating Group이 필요 이상의 데이터를 불러오는가?
• 고정된 상태나 등급을 DB에서 매번 검색하고 있지는 않은가?
• Parent group의 데이터를 다시 검색하고 있지는 않은가?
• 복잡한 계산을 페이지 로드 때마다 실행하고 있지는 않은가?

특히 Option Sets 전환 전에는 민감정보 포함 여부를 반드시 확인해야 합니다. Option Sets는 빠르지만 보안 저장소가 아니며 Privacy Rules의 보호를 받지 않습니다.

---

마무리

Bubble.io 앱의 성능은 플러그인을 추가하거나 화면 디자인을 단순화하는 것만으로 해결되지 않습니다. 앱의 기반이 되는 데이터 구조부터 점검해야 근본적인 개선이 가능합니다.

Privacy Rules는 데이터 접근을 서버에서 통제하는 보안 장치이며, Option Sets는 변경되지 않는 고정값에 대한 불필요한 DB 검색을 줄이는 수단입니다. 두 기능은 역할이 다르므로 어느 하나를 대신 사용하는 것이 아니라 함께 설계해야 합니다.

프로젝트 상태, 회원 역할, 주문 단계처럼 작고 고정된 값은 Option Sets로 관리하고, 회원정보나 주문 내역처럼 변경되거나 보호가 필요한 데이터는 일반 Data Type과 Privacy Rules로 관리하는 것이 기본 원칙입니다.

여기에 정확한 검색 Constraints, 직접 데이터 참조, 초기 로딩 범위 제한까지 적용하면 데이터가 늘어나도 비교적 안정적인 Bubble.io 앱 구조를 만들 수 있습니다.