Bubble.io 사용자 권한 관리(RBAC) 구축을 위한 Privacy Rules 세부 가이드

Bubble.io로 사내 관리 도구나 SaaS를 만들다 보면 사용자마다 다른 권한을 부여해야 합니다. 관리자는 모든 데이터를 확인하고 수정할 수 있어야 하지만, 일반 사용자는 자신이 작성한 자료나 소속 조직의 데이터만 볼 수 있어야 합니다.

이때 필요한 구조가 역할 기반 접근 제어, 즉 RBAC(Role-Based Access Control)입니다.

Bubble에서는 별도의 보안 코드를 작성하지 않아도 Privacy Rules로 데이터 접근 범위를 제한할 수 있습니다. 다만 버튼을 숨기거나 관리자 페이지 주소를 감추는 것만으로는 데이터를 보호할 수 없습니다.

화면 요소의 표시 조건은 사용자 경험을 정리하는 기능이고, 실제 데이터 보안은 서버에서 적용되는 Privacy Rules가 담당합니다.

RBAC와 Privacy Rules의 차이

RBAC는 사용자를 역할별로 구분하고 역할에 따라 데이터 조회·수정·삭제 권한을 부여하는 설계 방식입니다.

역할	허용할 작업
Admin	조직 내 모든 데이터 조회·수정·삭제 및 사용자 관리
Manager	담당 프로젝트 조회·수정 및 팀원 업무 확인
Member	자신에게 배정된 업무 조회 및 허용된 항목 수정

Privacy Rules는 이러한 정책을 Bubble 데이터베이스에 실제로 적용하는 기능입니다. 데이터 타입마다 조건을 만들고, 조건을 만족한 사용자에게 검색·필드 조회·첨부 파일 조회·자동 바인딩 등의 권한을 허용합니다.

여기서 중요한 특징은 여러 규칙이 동시에 적용될 경우 권한이 합쳐진다는 점입니다.

어떤 사용자에게 적용되는 규칙 하나라도 특정 접근을 허용하면 해당 사용자는 그 권한을 얻게 됩니다. 따라서 아래쪽 규칙이 위쪽 규칙을 취소해 줄 것이라고 생각하면 안 됩니다.

Bubble의 Privacy Rules는 ‘차단 규칙’보다 ‘조건을 만족한 사용자에게 허용하는 규칙’에 가깝습니다.

1단계: 사용자 역할을 Option Set으로 정의하기

가장 단순한 RBAC는 Option Set으로 역할을 관리하는 방식입니다.

1. Bubble 편집기에서 Data → Option sets로 이동합니다.
2. User Role이라는 Option Set을 만듭니다.
3. Admin, Manager, Member 옵션을 추가합니다.
4. User 데이터 타입에 role 필드를 만듭니다.
5. 필드 타입을 User Role로 지정합니다.

역할 이름을 텍스트로 저장하면 admin, Admin, 관리자처럼 값이 서로 다르게 입력될 수 있습니다. Option Set을 사용하면 선택 가능한 값이 고정되므로 조건식의 오타와 데이터 불일치를 줄일 수 있습니다.

단, Option Set은 앱에 포함되는 정적 데이터입니다. 비밀번호, API 키, 내부 인증값과 같이 노출되면 안 되는 정보는 저장하지 않아야 합니다.

2단계: 데이터 소유권과 조직 관계 설계하기

권한 규칙을 작성하려면 ‘누가 이 데이터를 소유하는가’와 ‘어느 조직의 데이터인가’를 확인할 수 있어야 합니다.

프로젝트 관리 앱이라면 다음과 같은 구조를 사용할 수 있습니다.

데이터 타입	주요 필드	용도
User	role, workspace	사용자 역할과 소속 조직
Workspace	name, owner, members	조직 정보와 구성원 목록
Project	title, workspace, manager	프로젝트의 소속 조직과 담당자
Task	title, project, assignee, creator	업무의 프로젝트·담당자·작성자

규모가 작은 앱이라면 User에 하나의 role과 workspace를 저장해도 충분합니다.

하지만 한 사용자가 여러 조직에서 서로 다른 역할을 가져야 하는 SaaS라면 Membership이라는 데이터 타입을 별도로 만드는 것이 좋습니다.

Membership에는 다음 필드를 저장할 수 있습니다.

• user
• workspace
• role
• status
• joined_date

이 구조를 사용하면 같은 사용자가 A 조직에서는 Admin, B 조직에서는 Member인 상황도 표현할 수 있습니다.

멀티 테넌트 앱에서는 전역 역할만 확인해서는 안 됩니다. 현재 데이터가 속한 조직과 사용자의 멤버십을 함께 확인해야 다른 고객사의 데이터가 노출되는 문제를 방지할 수 있습니다.

3단계: 데이터 타입별 Privacy Rules 설정하기

Privacy Rules는 Bubble 편집기의 Data → Privacy에서 설정합니다. RBAC를 처음 구축할 때는 개인정보나 결제 정보처럼 민감한 데이터 타입부터 적용하는 것이 좋습니다.

Project 데이터 타입 설정 예시

관리자 규칙

• 규칙 이름: Workspace Admin
• 조건 예시: Current User is logged in
• 추가 조건: Current User's role is Admin
• 조직 조건: This Project's workspace is Current User's workspace
• 허용 범위: 필요한 필드 조회, 검색 및 수정 기능

매니저 규칙

• 규칙 이름: Assigned Manager
• 조건 예시: This Project's manager is Current User
• 허용 범위: 프로젝트 검색 및 업무에 필요한 필드 조회
• 직접 수정해야 하는 필드에만 auto-binding 허용

일반 구성원 규칙

• 규칙 이름: Workspace Member
• 조건 예시: This Project's workspace's members contains Current User
• 허용 범위: 검색 및 공개 가능한 프로젝트 필드 조회
• 예산, 내부 메모, 결제 정보 등은 조회 대상에서 제외

Everyone else 규칙

외부에 공개할 이유가 없는 데이터라면 모든 권한을 해제합니다.

특히 Current User's role is Admin 조건만 사용하고 조직 조건을 생략하면 다른 회사의 Admin이 전체 프로젝트를 볼 수 있는 문제가 생길 수 있습니다.

여러 고객사가 같은 앱을 이용하는 구조에서는 항상 ‘사용자 역할’과 ‘데이터의 소속 조직’을 동시에 검사해야 합니다.

4단계: 권한 항목을 최소 범위로 허용하기

Privacy Rules에서 설정할 수 있는 권한은 각각 역할이 다릅니다.

Find this in searches

해당 데이터를 Do a search for의 검색 결과에서 찾을 수 있게 하는 권한입니다.

이 항목을 해제하면 사용자가 일부 필드의 조회 권한을 가지고 있어도 검색 결과에서 해당 레코드를 찾지 못할 수 있습니다. 목록이나 검색 결과에 표시해야 하는 데이터에만 허용하는 것이 좋습니다.

View all fields와 개별 필드

모든 필드를 한꺼번에 공개하기보다 역할별로 필요한 필드만 선택하는 것이 안전합니다.

예를 들어 Member에게 다음 필드는 공개할 수 있습니다.

• 프로젝트 이름
• 담당자
• 시작일
• 마감일
• 진행 상태

반면 다음 필드는 관리자와 매니저에게만 공개할 수 있습니다.

• budget
• internal_note
• billing_email
• contract_file
• customer_phone

View attached files

파일 필드가 존재한다고 해서 첨부 파일 접근까지 자동으로 보호되는 것은 아닙니다.

계약서, 신분증, 정산 자료처럼 민감한 파일을 다룬다면 데이터 레코드의 조회 권한과 첨부 파일 조회 권한을 함께 점검해야 합니다.

Allow auto-binding

입력 요소의 Allow auto-binding 기능을 이용해 데이터를 직접 수정할 수 있도록 허용하는 권한입니다.

설정이 간편하지만 예상하지 못한 필드 변경으로 이어질 수 있으므로 반드시 필요한 필드에만 허용해야 합니다.

프로젝트 상태, 사용자 역할, 결제 정보처럼 중요한 항목은 자동 바인딩보다 워크플로를 사용하고, 워크플로에서 권한 조건을 다시 검사하는 방식이 안전합니다.

5단계: 화면 접근과 데이터 접근 함께 설계하기

관리자 메뉴는 Current User's role is Admin 조건으로 숨길 수 있습니다. 하지만 이것은 실제 데이터 보안 규칙이 아니라 화면 표시 설정입니다.

사용자가 주소를 직접 입력하거나 개발자 도구를 이용해 요청을 변경할 가능성까지 고려해야 합니다.

안전한 구조는 다음 세 단계로 구성할 수 있습니다.

1. 페이지가 로드될 때 권한이 없는 사용자를 다른 페이지로 이동시킵니다.
2. 버튼과 입력 요소를 사용자 역할에 따라 표시하거나 비활성화합니다.
3. 데이터베이스에는 별도의 Privacy Rules를 적용합니다.

워크플로의 Only when 조건도 함께 사용하면 잘못된 작업이 실행되는 것을 줄일 수 있습니다.

다만 Only when 조건만 설정하고 Privacy Rules를 생략해서는 안 됩니다. 화면과 워크플로 조건은 보조 장치이고, 실제 데이터 접근 제한은 Privacy Rules가 담당해야 합니다.

6단계: 관리자 권한 부여 워크플로 보호하기

회원가입 과정에서 사용자가 자신의 역할을 선택하게 만들면 누구나 Admin 권한을 얻을 수 있습니다.

신규 사용자는 기본적으로 Member 역할을 받도록 설정하고, 관리자 승격은 기존 관리자만 실행할 수 있는 서버 측 워크플로로 제한해야 합니다.

다음 항목도 함께 확인해야 합니다.

• 역할 변경 버튼이 관리자에게만 표시되는가?
• 역할 변경 워크플로에 Only when Current User's role is Admin 조건이 있는가?
• 변경 대상 사용자가 관리자와 같은 조직에 속해 있는가?
• 사용자가 자신의 역할을 직접 변경할 수 없게 설정했는가?
• 마지막 관리자 한 명을 실수로 강등하지 못하게 막았는가?
• 누가 언제 역할을 변경했는지 감사 로그를 남기는가?

감사 로그 데이터 타입에는 다음 필드를 저장할 수 있습니다.

• actor
• target_user
• old_role
• new_role
• workspace
• action
• created_date

감사 로그에도 관리자 전용 Privacy Rules를 별도로 적용해야 합니다.

7단계: 백엔드 워크플로와 API 권한 확인하기

백엔드 워크플로나 API를 사용한다면 일반 페이지 이외의 데이터 접근 경로도 확인해야 합니다.

Privacy Rules를 무시하도록 설정된 백엔드 워크플로는 강력한 관리자 권한으로 실행될 수 있으므로 꼭 필요한 작업에만 사용해야 합니다.

Data API는 데이터 타입별 Privacy Rules의 영향을 받지만, Bubble API 토큰을 이용해 관리자 권한으로 인증하면 Privacy Rules가 적용되지 않을 수 있습니다.

따라서 API 토큰은 브라우저, 페이지 요소, Option Set 또는 공개된 워크플로 안에 넣어서는 안 됩니다. 서버에서 안전하게 관리해야 합니다.

Data API를 활성화했다면 Privacy Rules에 표시되는 다음 권한도 확인합니다.

• Create via API
• Modify via API
• Delete via API

해당 권한은 기본적으로 모두 허용하기보다 실제 API 작업에 필요한 역할에만 선택적으로 부여하는 것이 좋습니다.

8단계: 역할별 테스트 계정으로 검증하기

권한 설정은 관리자 계정 하나로만 테스트하면 오류를 발견하기 어렵습니다.

최소한 다음과 같은 테스트 계정을 준비하는 것이 좋습니다.

• 조직 A의 Admin
• 조직 A의 Manager
• 조직 A의 Member
• 조직 B의 Admin 또는 Member
• 로그인하지 않은 사용자

각 계정으로 다음 시나리오를 확인합니다.

테스트 항목	기대 결과
Member가 다른 조직의 Project 검색	검색 결과에 나타나지 않음
Manager가 담당하지 않은 Project 수정	수정되지 않음
Member가 관리자 페이지 URL 입력	다른 페이지로 이동
권한 없는 사용자가 민감 필드 조회	값이 전달되지 않음
일반 사용자가 역할 필드 변경 시도	변경 실패
로그아웃 상태에서 비공개 데이터 검색	결과가 나타나지 않음
다른 조직의 첨부 파일 접근	파일을 열 수 없음

Bubble의 Security Dashboard에서 Privacy Rules 관련 검사를 실행해 공개된 데이터 타입과 필드도 점검합니다.

테스트용 Development 데이터베이스뿐 아니라 실제 서비스를 공개하기 전 Live 환경의 데이터와 설정도 확인해야 합니다.

자주 발생하는 RBAC 설정 실수

1. 관리자 버튼만 숨기는 경우

버튼과 메뉴를 숨기는 것은 화면 제어일 뿐입니다. Privacy Rules가 없다면 데이터가 검색이나 다른 경로를 통해 노출될 수 있습니다.

2. Everyone else 권한을 남겨두는 경우

다른 규칙에서 접근을 제한했다고 생각해도 Everyone else에 검색 또는 전체 필드 조회 권한이 남아 있으면 데이터가 공개될 수 있습니다.

3. 조직 범위를 확인하지 않는 경우

Current User's role is Admin만 확인하면 다른 조직의 관리자가 데이터를 조회할 수 있습니다. 멀티 테넌트 앱에서는 역할과 조직 조건을 반드시 함께 사용해야 합니다.

4. User 데이터의 모든 필드를 공개하는 경우

공개 프로필에는 이름과 프로필 이미지 정도만 노출하고 이메일, 역할, 내부 메모, 결제 정보는 별도로 제한하는 것이 좋습니다.

5. API와 첨부 파일을 점검하지 않는 경우

검색 결과에서 데이터를 숨겼더라도 첨부 파일이나 API 접근 권한이 열려 있으면 정보가 노출될 수 있습니다. 데이터, 파일, 워크플로, API를 하나의 보안 범위로 보고 함께 점검해야 합니다.

실무용 RBAC 점검 체크리스트

• 모든 비공개 데이터 타입에 Privacy Rules가 설정되어 있는가?
• 신규 사용자의 기본 역할이 Member로 지정되는가?
• 사용자 역할과 소속 조직을 동시에 확인하는가?
• Everyone else에 불필요한 권한이 남아 있지 않은가?
• 민감한 필드는 역할별로 별도 제한했는가?
• auto-binding은 필요한 필드에만 허용했는가?
• 역할 변경은 관리자 전용 워크플로에서 처리하는가?
• 백엔드 워크플로의 Privacy Rules 무시 옵션을 확인했는가?
• API 토큰이 클라이언트에 노출되지 않았는가?
• 서로 다른 조직과 역할의 테스트 계정으로 검증했는가?
• Security Dashboard 검사 결과를 확인했는가?
• Development와 Live 환경을 모두 점검했는가?

마무리

Bubble.io에서 RBAC를 안전하게 구축하려면 역할 필드 하나만 추가하는 것으로는 부족합니다.

사용자 역할, 데이터 소유권, 조직 관계를 먼저 설계한 뒤 데이터 타입별 Privacy Rules로 조회와 수정 범위를 제한해야 합니다. 여기에 페이지 이동 조건, 워크플로 조건, API 보안, 역할별 테스트를 더하면 권한 누락으로 인한 데이터 노출 위험을 줄일 수 있습니다.

처음에는 Admin·Manager·Member 세 단계로 단순하게 시작하고, 서비스가 확장되면 Membership 데이터 타입이나 세부 권한 목록을 추가하는 방식이 관리하기 쉽습니다.

가장 중요한 원칙은 모든 권한을 열어놓고 예외를 차단하는 것이 아니라, 기본적으로 닫아둔 상태에서 업무에 필요한 접근만 허용하는 것입니다.