Bubble.io App Search 최적화: Do a Search for 사용 시 서버 과부하 방지 필터링 기법

Bubble.io로 검색 기능을 구현할 때 가장 자주 사용하는 데이터 소스가 Do a Search for입니다. 사용법은 간단하지만 검색 조건을 잘못 설정하면 필요 이상의 데이터를 불러와 페이지가 느려지고 Workload Unit(WU) 사용량도 증가할 수 있습니다.

특히 데이터가 수천 건 이상 쌓이는 서비스라면 단순히 검색 결과가 나온다는 것보다, 서버가 처리할 데이터 범위를 얼마나 먼저 줄이는지가 중요합니다.

Do a Search for는 어떻게 작동할까?

Do a Search for는 지정한 데이터 타입에서 조건에 맞는 레코드를 서버에서 검색해 목록으로 반환합니다.

예를 들어 상품 검색 화면이라면 다음과 같이 설정할 수 있습니다.

• Type of content: Product
• Data source: Do a Search for Products
• Constraint: status = Published
• Constraint: category = Dropdown Category's value

Bubble 공식 문서에서도 검색 조건인 Constraint를 이용해 반환할 데이터 범위를 좁히는 방식을 기본 검색 구조로 설명합니다.

문제는 조건 없이 모든 Product를 가져온 뒤 브라우저에서 다시 필터링하는 경우입니다.

Do a Search for Products :filtered

이 구조는 데이터베이스에서 많은 데이터를 먼저 불러온 다음 추가 조건을 검사할 수 있어, 레코드가 늘어날수록 처리량과 응답 시간이 증가합니다.

1. 검색 조건은 :filtered보다 Constraint에 먼저 넣기

다음은 성능상 불리할 수 있는 구조입니다.

Do a Search for Products
:filtered
Advanced: This Product's status is "Published"

가능하다면 아래처럼 검색 단계에서 조건을 적용하는 것이 좋습니다.

Do a Search for Products
status = Published

일반 Constraint는 데이터베이스가 검색 범위를 먼저 줄일 수 있도록 도와줍니다. Bubble은 검색 조건을 가능한 한 원본 검색에 가깝게 적용하는 것이 효율적이라고 안내합니다.

핵심 원칙

서버 검색 조건으로 처리할 수 있는 값
→ Do a Search for의 Constraint에 입력

일반 Constraint로 표현하기 어려운 값
→ 범위를 충분히 줄인 후 :filtered 사용

2. 검색할 때 최소 한 개 이상의 범위 조건 사용하기

전체 데이터를 대상으로 검색하지 않도록 상태, 사용자, 카테고리 또는 날짜 조건을 먼저 설정해야 합니다.

비효율적인 검색

Do a Search for Orders

개선된 검색

Do a Search for Orders
user = Current User
status = Paid
created date ≥ Current date/time +(days): -30

이렇게 구성하면 현재 사용자의 최근 30일 결제 완료 주문만 검색합니다. 서버가 검사하고 전송해야 하는 데이터 수가 줄어들어 검색 속도와 WU 사용량을 함께 관리할 수 있습니다.

3. 중첩 검색 피하기

검색 조건 안에 또 다른 Do a Search for를 넣으면 검색이 연속적으로 실행될 수 있습니다.

피해야 할 예시

Do a Search for Orders
customer is in Do a Search for Users

이 구조에서는 사용자 검색을 실행한 후 그 결과를 다시 주문 검색에 사용합니다.

가능하다면 Order 데이터 타입에 검색에 필요한 값을 직접 저장하는 편이 효율적입니다.

Order
- customer
- customer_company
- customer_region
- status

이후 다음처럼 검색합니다.

Do a Search for Orders
customer_company = Current User's company
status = Paid

Bubble의 최적화 지침 역시 다른 검색을 조건으로 사용하는 중첩 검색을 피하고, 가능한 많은 일반 조건으로 검색 범위를 먼저 줄일 것을 권장합니다.

4. 검색창 입력마다 검색을 실행하지 않기

사용자가 검색창에 글자를 입력할 때마다 Do a Search for가 실행되면 짧은 시간 안에 여러 번 서버 요청이 발생할 수 있습니다.

예를 들어 사용자가 “Bubble”을 입력하면 다음 검색이 연속으로 실행될 수 있습니다.

B → Bu → Bub → Bubb → Bubbl → Bubble

이를 줄이는 방법은 다음과 같습니다.

검색 버튼 사용

입력할 때마다 검색하지 않고 사용자가 검색 버튼을 눌렀을 때만 검색어를 Custom State에 저장합니다.

검색 버튼 클릭
→ Set state keyword = Search Input's value

Repeating Group에서는 해당 State를 검색 조건으로 사용합니다.

Do a Search for Articles
title contains Page's keyword

최소 글자 수 설정

검색어가 너무 짧을 때는 검색을 실행하지 않습니다.

Only when Search Input's value:number of characters ≥ 2

한글 키워드 검색이라면 2글자 이상, 영문 검색이라면 2~3글자 이상 입력했을 때 검색하도록 설정하는 방식이 실용적입니다.

5. Ignore empty constraints를 주의해서 사용하기

Ignore empty constraints를 활성화하면 검색값이 비어 있는 조건은 무시됩니다.

예를 들어 다음 조건이 있다고 가정해 보겠습니다.

category = Category Dropdown's value

Dropdown 값이 비어 있고 Ignore empty constraints가 활성화되어 있다면 카테고리 조건 자체가 사라집니다. 다른 제한 조건이 없다면 전체 상품이 검색될 수 있습니다.

Bubble 공식 문서에 따르면 이 옵션을 선택한 상태에서 Constraint 값이 비어 있으면 해당 조건은 무시됩니다.

따라서 다음 중 하나를 함께 적용하는 것이 안전합니다.

• 기본 카테고리값 지정
• 검색 버튼에 Only when 조건 설정
• status = Published 같은 필수 조건 유지
• 검색어가 비어 있으면 Repeating Group 숨김

6. :filtered가 필요한 경우에도 대상을 먼저 줄이기

:filtered를 무조건 사용하면 안 된다는 뜻은 아닙니다. 일반 Constraint만으로 표현하기 어려운 복합 조건에서는 필요할 수 있습니다.

다만 아래처럼 모든 데이터를 먼저 가져오는 구조는 피해야 합니다.

Do a Search for Products
:filtered
Advanced 조건

먼저 일반 조건으로 후보 데이터를 줄인 뒤 Advanced Filter를 적용합니다.

Do a Search for Products
status = Published
category = Selected Category
created date ≥ Current date/time +(months): -3
:filtered
Advanced 조건

Bubble은 :advanced 조건이 서버에 더 많은 부담을 줄 수 있으며, 일반적으로 1만 건이 넘는 데이터에 적용하는 것을 권장하지 않습니다.

단, 이미 브라우저에 불러온 Repeating Group 목록을 추가로 필터링하는 경우에는 클라이언트 측에서 처리될 수 있습니다. 이 경우 새로운 서버 검색과 이미 받은 목록의 화면 필터링을 구분해야 합니다.

7. :first item으로 전체 검색을 해결하려 하지 않기

결과가 한 건만 필요하다고 다음처럼 설정하는 경우가 있습니다.

Do a Search for Users:first item

하지만 :first item은 검색 결과 목록에서 첫 번째 항목을 선택하는 연산자입니다. 검색 범위를 결정하는 Constraint를 대신하지는 않습니다.

특정 사용자를 찾는다면 고유한 값을 조건으로 지정합니다.

Do a Search for Users
unique_id = Target User ID
:first item

이메일이나 외부 서비스 ID를 이용한다면 중복되지 않도록 데이터 생성 단계에서도 검증하는 것이 좋습니다.

8. Privacy Rules를 검색 최적화에 활용하기

Privacy Rules는 보안 설정이지만 검색 가능한 데이터 범위를 제한하는 역할도 합니다.

예를 들어 Project 데이터에 다음과 같은 필드를 구성할 수 있습니다.

Project
- owner
- organization
- status
- title

Privacy Rule은 다음과 같이 설정할 수 있습니다.

When This Project's organization is Current User's organization
→ Find this in searches 허용

그러면 사용자는 자신이 속한 조직의 데이터만 검색할 수 있습니다. 불필요한 데이터 접근을 차단하면서 서버가 반환하는 검색 결과도 줄일 수 있습니다.

Bubble의 Privacy Rules는 서버 측에서 적용되며, Find this in searches 권한을 이용해 해당 데이터가 검색 결과에 포함될 수 있는지를 제어합니다.

단, 권한 조건에 여러 단계의 관계를 연결하면 검색 권한 판정에 제한이 생길 수 있습니다.

Project's Organization's Owner's Role

이처럼 관계를 여러 단계 거치기보다 권한 확인에 필요한 organization, owner 또는 access_level 값을 보호 대상 데이터에 직접 저장하는 구조가 안전합니다.

실전 최적화 예제

상품 검색 페이지를 다음과 같이 구성한다고 가정해 보겠습니다.

Product 데이터 타입

name                 text
search_name          text
category             Category
status               ProductStatus
price                number
seller               User
created_date         date

권장 검색식

Do a Search for Products
status = ProductStatus's Published
category = Category Dropdown's value
seller = Current User
search_name contains Search Keyword State

검색 실행 조건

Search Keyword State is not empty
Search Keyword State:number of characters ≥ 2

추가 최적화

• 검색용 이름을 소문자로 통일해 search_name에 저장
• 상태값은 텍스트보다 Option Set으로 관리
• 검색 결과 정렬 기준을 명확하게 지정
• 페이지 진입과 동시에 불필요한 검색을 실행하지 않기
• 동일한 데이터를 여러 요소에서 반복 검색하지 않기
• 오래된 데이터는 날짜나 상태 조건으로 검색 대상에서 제외

Bubble은 같은 페이지에서 동일한 검색이 여러 번 사용될 경우 이를 하나의 쿼리로 결합해 최적화할 수 있습니다. 그러나 조건이 조금씩 다르면 별도의 검색으로 처리될 가능성이 있으므로 공통 검색 결과를 Repeating Group이나 Custom State에서 재사용하는 편이 관리하기 좋습니다.

검색 최적화 점검표

글을 마무리하기 전에 다음 항목을 확인해 보세요.

• Do a Search for에 최소 하나 이상의 Constraint가 있는가?
• 전체 데이터를 가져온 뒤 :filtered로 거르고 있지는 않은가?
• 검색 조건 안에 또 다른 검색이 들어가 있지 않은가?
• 입력할 때마다 서버 검색이 실행되고 있지는 않은가?
• 빈 검색값 때문에 전체 데이터가 반환될 가능성은 없는가?
• Advanced Filter 적용 대상이 지나치게 크지 않은가?
• Privacy Rules에서 검색 가능 범위를 제한했는가?
• 권한 확인에 필요한 필드를 데이터에 직접 저장했는가?
• 동일한 검색을 여러 요소에서 불필요하게 반복하고 있지는 않은가?

마무리

Bubble.io의 검색 성능은 Do a Search for 자체보다 검색 범위를 어떻게 설계했는지에 따라 크게 달라집니다. 가장 중요한 원칙은 서버가 전체 데이터를 가져오기 전에 일반 Constraint로 후보를 최대한 줄이는 것입니다.

검색 입력 횟수를 제한하고, 중첩 검색과 과도한 :filtered 사용을 줄이며, Privacy Rules까지 함께 설계하면 데이터가 늘어나도 비교적 안정적인 검색 환경을 유지할 수 있습니다.