Bubble.io 외부 데이터베이스 연동｜Xano·Supabase 백엔드 분리 설계

2026년 10월 3일 읽는 시간 약 16분

Bubble.io로 서비스를 만들다 보면 어느 순간 데이터베이스를 계속 Bubble 안에 둘지, 외부 백엔드로 분리할지 고민하게 됩니다. 초기 MVP는 Bubble의 내장 데이터베이스만으로도 충분하지만 데이터 구조가 복잡해지고 외부 서비스와의 연동이 늘어나면 다른 선택지가 필요할 수 있습니다.

이때 자주 검토하는 도구가 Xano와 Supabase입니다. 두 서비스 모두 Bubble이 REST API를 통해 데이터를 읽고 수정할 수 있도록 지원하지만 설계 방식과 운영 난이도는 서로 다릅니다. 중요한 점은 외부 데이터베이스를 연결하는 것 자체가 아니라, 어떤 데이터와 로직을 외부로 옮기고 Bubble에는 무엇을 남길지 경계를 정하는 것입니다.

이 글에서는 Bubble을 프런트엔드로 사용하고 Xano 또는 Supabase를 백엔드로 분리하는 구조, 실제 API 연결 흐름, 인증 및 권한 설계, 성능 저하를 피하는 방법을 차례대로 살펴보겠습니다.

외부 백엔드 분리는 무엇이 달라지는가

Bubble 내장 데이터베이스를 사용하는 일반적인 앱에서는 화면, 워크플로우, 사용자 인증, 데이터 저장이 하나의 플랫폼 안에서 처리됩니다. 개발 속도가 빠르고 설정도 단순하다는 장점이 있습니다.

백엔드를 분리하면 역할이 다음처럼 달라집니다.

영역	담당 시스템	주요 역할
화면과 사용자 경험	Bubble	페이지, 입력 폼, 팝업, 반응형 UI
화면 동작	Bubble	버튼 클릭, 조건 분기, API 호출
데이터 저장	Xano 또는 Supabase	회원, 주문, 게시물, 로그 등의 원본 데이터
서버 로직	Xano API 또는 Supabase Function·DB 함수	검증, 계산, 권한 확인, 여러 데이터의 일괄 처리
접근 통제	외부 백엔드	인증 토큰 검증, 역할별 권한, 행 단위 보안

사용자가 Bubble 화면에서 저장 버튼을 누르면 Bubble이 외부 API에 요청을 보내고, 외부 백엔드가 요청을 검증한 뒤 데이터베이스를 변경합니다. 처리 결과는 JSON으로 반환되며 Bubble은 이 값을 화면에 표시하거나 다음 워크플로우에 사용합니다.

즉, Bubble이 데이터베이스에 직접 접근하는 구조가 아니라 정해진 API를 통해서만 데이터가 오가는 구조가 됩니다.

무조건 분리하는 것이 좋은 것은 아니다

외부 백엔드를 사용하면 확장성이 자동으로 좋아진다고 생각하기 쉽지만, 실제로는 관리 대상이 늘어납니다. API 응답 형식, 인증 토큰, 오류 처리, 호출 비용, 데이터 동기화까지 직접 설계해야 하기 때문입니다.

다음과 같은 상황이라면 분리를 검토할 만합니다.

모바일 앱이나 다른 웹 서비스에서도 같은 데이터를 사용해야 하는 경우
복잡한 관계형 쿼리와 집계가 많아 SQL 활용이 필요한 경우
외부 시스템에 공개할 독립적인 API 계층이 필요한 경우
데이터와 비즈니스 로직을 Bubble 바깥에서도 재사용하려는 경우
장기적으로 프런트엔드 교체 가능성을 열어 두려는 경우

반대로 관리자용 도구, 사내 업무 앱, 검증 단계의 MVP처럼 Bubble 안에서 모든 기능을 빠르게 완성하는 것이 중요한 프로젝트라면 내장 데이터베이스가 더 효율적일 수 있습니다. 분리는 유행이 아니라 서비스 요구사항을 기준으로 결정해야 합니다.

Xano와 Supabase의 차이

Xano는 시각적인 방식으로 데이터베이스와 API, 인증, 서버 로직을 구성하기에 적합합니다. 각 API 엔드포인트에서 입력값 검증, 데이터 조회, 조건 분기, 응답 생성을 순서대로 설계할 수 있어 코드 경험이 많지 않아도 백엔드 흐름을 파악하기 쉽습니다.

Supabase는 PostgreSQL을 기반으로 하며 테이블, 관계, 뷰, 함수, 트리거, 인덱스 등 관계형 데이터베이스의 기능을 적극적으로 활용할 수 있습니다. 자동 생성되는 REST API와 인증, Storage, Edge Functions도 함께 사용할 수 있습니다. 대신 SQL과 Row Level Security, 즉 RLS 정책을 정확히 이해해야 안전하게 운영할 수 있습니다.

비교 항목	Xano	Supabase
접근 방식	시각적 백엔드·API 빌더	PostgreSQL 중심 백엔드 플랫폼
진입 난이도	비교적 낮음	SQL과 권한 정책 이해 필요
서버 로직	Function Stack으로 구성	DB 함수·트리거·Edge Functions 활용
권한 관리	API 인증과 엔드포인트 로직	Auth와 RLS 정책 중심
적합한 경우	노코드 방식으로 API를 빠르게 만들 때	관계형 데이터와 SQL 활용도가 높을 때

비개발자 중심 팀이 API 로직을 직접 관리해야 한다면 Xano가 편리할 수 있습니다. 반면 SQL 활용 능력이 있고 복잡한 관계형 데이터 모델을 다뤄야 한다면 Supabase가 자연스러운 선택이 될 수 있습니다.

연동 전에 데이터 소유권부터 정해야 한다

백엔드 분리에서 가장 흔한 실수는 동일한 데이터를 Bubble과 외부 데이터베이스 양쪽에 저장하는 것입니다. 예를 들어 회원 이름과 등급을 두 시스템에 모두 저장하면 어느 값이 최신인지 판단하기 어려워집니다. 한쪽 수정이 실패하면 서로 다른 값이 남는 동기화 문제도 발생합니다.

따라서 데이터마다 원본 시스템을 하나만 정하는 것이 안전합니다.

회원 프로필과 권한의 원본은 외부 백엔드에 둔다.
Bubble에는 화면 표시를 위해 꼭 필요한 최소 정보만 임시로 보관한다.
주문, 결제 상태처럼 중요한 데이터는 외부 백엔드에서만 변경한다.
Bubble의 Custom State는 화면용 임시 상태로만 사용한다.
동일 데이터를 양쪽에 저장해야 한다면 동기화 방향과 실패 복구 기준을 문서화한다.

사용자 식별자도 이메일 대신 변경되지 않는 UUID 또는 외부 백엔드의 고유 ID를 사용하는 편이 좋습니다. 이메일은 사용자가 변경할 수 있고 대소문자나 공백 처리로 비교 오류가 생길 수 있기 때문입니다.

Bubble API Connector 연결 구조

Bubble에서는 일반적으로 API Connector 플러그인을 이용해 Xano 또는 Supabase의 REST API를 호출합니다. 기본 흐름은 다음과 같습니다.

외부 백엔드에서 테이블과 관계를 설계합니다.
목록 조회, 단건 조회, 생성, 수정, 삭제에 필요한 API를 준비합니다.
인증이 필요한 요청에는 Bearer 토큰 또는 백엔드가 요구하는 헤더를 설정합니다.
Bubble API Connector에서 URL, HTTP 메서드, 헤더, 파라미터를 등록합니다.
샘플 요청을 초기화하여 Bubble이 JSON 응답 구조를 인식하게 합니다.
조회 요청은 데이터 소스로, 변경 요청은 워크플로우의 액션으로 사용합니다.

예를 들어 게시물 목록을 불러오는 API는 GET /posts 형태로 만들 수 있습니다. 페이지 번호와 한 번에 가져올 개수를 쿼리 파라미터로 전달하고, 응답에는 목록뿐 아니라 전체 개수와 다음 페이지 존재 여부도 포함하는 것이 좋습니다.

{
  "items": [
    {
      "id": "b7c1...",
      "title": "외부 백엔드 설계",
      "status": "published"
    }
  ],
  "page": 1,
  "page_size": 20,
  "has_next": true
}

응답 구조가 호출할 때마다 달라지면 Bubble에서 필드를 안정적으로 사용하기 어렵습니다. 성공 응답과 오류 응답의 형식을 미리 정하고, 필드 이름과 자료형을 일관되게 유지해야 합니다.

Xano 연동 설계 순서

Xano를 사용할 때는 테이블을 만든 뒤 API Group 안에 엔드포인트를 구성합니다. Bubble이 데이터베이스 테이블을 직접 다루게 하기보다, 용도별 API를 제공하는 방식이 관리하기 쉽습니다.

예를 들어 주문 생성 API는 다음 작업을 서버에서 한 번에 처리할 수 있습니다.

요청한 사용자의 인증 상태를 확인합니다.
상품 ID와 주문 수량의 유효성을 검사합니다.
현재 가격과 재고를 데이터베이스에서 다시 조회합니다.
주문과 주문 상세 데이터를 하나의 처리 흐름에서 생성합니다.
필요한 필드만 골라 Bubble에 반환합니다.

가격이나 권한처럼 조작되면 안 되는 값은 Bubble에서 전달된 내용을 그대로 믿지 말아야 합니다. Bubble은 상품 ID와 수량만 전달하고 실제 가격 계산과 권한 검증은 Xano에서 수행하는 구조가 안전합니다.

또한 목록 API에는 페이지네이션, 검색 조건, 정렬 기준을 서버 측에 넣어야 합니다. 전체 데이터를 Bubble로 가져온 뒤 화면에서 필터링하면 데이터 전송량과 렌더링 시간이 함께 증가합니다.

Supabase 연동 설계 순서

Supabase에서는 테이블을 만들면 REST API를 통해 데이터를 다룰 수 있습니다. Bubble API Connector에서 프로젝트의 REST 주소를 호출하고 필요한 헤더와 필터 조건을 전달하는 방식으로 연결할 수 있습니다.

하지만 연결에 성공했다고 해서 보안 설정이 끝난 것은 아닙니다. 클라이언트에서 접근하는 테이블은 RLS를 활성화하고 사용자가 읽거나 수정할 수 있는 행을 정책으로 제한해야 합니다.

예를 들어 사용자가 자신의 프로필만 조회하도록 설계한다면 정책의 판단 기준은 요청 토큰의 사용자 ID와 행에 저장된 user_id가 같은지 여부가 됩니다. 관리자 권한, 팀 단위 접근, 공개 데이터 조회도 각각 정책을 분리해 명시하는 것이 좋습니다.

Supabase의 secret 또는 service 역할 키처럼 RLS를 우회할 수 있는 키는 브라우저에 전달해서는 안 됩니다. Bubble에서 비밀 키가 필요한 호출은 API Connector의 민감한 값을 private로 설정하고 서버 측에서 실행되도록 구성해야 합니다. 더 안전한 경계가 필요하다면 Edge Function을 중간 API로 두고, Bubble은 해당 함수만 호출하게 만들 수 있습니다.

인증을 한곳에서 책임지게 만들기

Bubble 로그인과 외부 백엔드 인증을 동시에 운영하면 계정 상태가 어긋날 수 있습니다. 회원 가입은 Bubble에서 성공했지만 외부 사용자 생성이 실패하거나, 탈퇴 처리가 한쪽에만 반영되는 상황이 대표적입니다.

가능하면 인증의 기준 시스템을 하나로 정해야 합니다.

Xano Auth 또는 Supabase Auth를 기준으로 사용자를 인증한다.
로그인 성공 후 받은 액세스 토큰을 이후 API 요청에 사용한다.
토큰 만료와 재발급 실패 시 다시 로그인하도록 처리한다.
Bubble에는 비밀번호를 별도로 저장하지 않는다.
관리자 기능은 화면 표시 조건뿐 아니라 외부 API에서도 권한을 다시 검사한다.

버튼을 숨기는 것은 보안이 아닙니다. 공격자는 화면을 거치지 않고 API 주소로 직접 요청할 수 있으므로 생성, 수정, 삭제 권한은 반드시 백엔드에서 판정해야 합니다.

성능을 떨어뜨리는 호출 패턴

외부 데이터베이스를 연결한 뒤 페이지가 더 느려지는 경우도 있습니다. 대부분 데이터베이스 자체보다 API 호출 방식에 문제가 있습니다.

가장 피해야 할 패턴은 Repeating Group의 각 행마다 추가 API를 호출하는 방식입니다. 게시물 20개를 불러온 뒤 작성자 정보를 얻기 위해 20번 더 요청하면 한 화면에서 21번의 네트워크 통신이 발생합니다. 이를 N+1 호출 문제라고 합니다.

해결 방법은 목록 API가 화면에 필요한 작성자명, 카테고리명, 썸네일 주소를 함께 반환하도록 응답을 설계하는 것입니다. Supabase라면 관계 쿼리나 뷰를 활용하고, Xano라면 Addons 또는 서버 측 조회 로직을 이용해 필요한 데이터를 조합할 수 있습니다.

그 밖에도 다음 원칙이 중요합니다.

처음부터 전체 데이터를 내려받지 않고 페이지네이션을 사용한다.
검색과 정렬은 Bubble 화면이 아니라 서버에서 처리한다.
목록 응답에는 화면에 표시하지 않는 큰 텍스트나 내부 필드를 제외한다.
자주 조회하지만 변경이 적은 값은 적절히 캐시한다.
검색, 정렬, 조인에 자주 쓰는 열에는 데이터베이스 인덱스를 검토한다.
여러 데이터를 연속으로 변경할 때는 서버 함수나 트랜잭션으로 묶는다.

오류 처리와 운영 로그 설계

외부 API는 항상 성공한다고 가정하면 안 됩니다. 네트워크 지연, 토큰 만료, 잘못된 입력, 호출 제한, 서버 오류가 언제든 발생할 수 있습니다.

API는 HTTP 상태 코드와 함께 일관된 오류 형식을 반환하도록 설계하는 것이 좋습니다.

{
  "error": {
    "code": "ORDER_OUT_OF_STOCK",
    "message": "선택한 상품의 재고가 부족합니다.",
    "request_id": "req_20260922_001"
  }
}

Bubble에서는 성공했을 때만 다음 단계를 실행하고, 실패 시 사용자에게 이해할 수 있는 안내를 보여줘야 합니다. 결제나 주문처럼 중복 실행이 위험한 작업은 같은 요청을 다시 보내도 한 번만 처리되도록 멱등성 키를 두는 방법도 유용합니다.

운영 로그에는 요청 시각, 사용자 식별자, API 이름, 처리 결과, 요청 ID를 남기되 비밀번호, 전체 액세스 토큰, 결제 정보 같은 민감한 값은 기록하지 않아야 합니다.

단계적으로 이전하는 현실적인 방법

이미 운영 중인 Bubble 앱이라면 모든 데이터를 한 번에 옮기기보다 기능 단위로 이전하는 편이 안전합니다.

첫 단계에서는 새로 추가할 기능 하나를 외부 백엔드로 구현합니다. 두 번째 단계에서는 조회가 많지만 변경이 적은 데이터를 이전하고 응답 속도와 오류율을 확인합니다. 이후 주문이나 권한처럼 중요한 기능을 옮길 때는 충분한 테스트와 롤백 계획을 준비합니다.

이전 기간에는 다음 항목을 확인해야 합니다.

날짜와 시간대가 동일하게 변환되는가
빈 값과 기본값의 처리 방식이 같은가
Bubble의 고유 ID와 외부 UUID를 연결할 기준이 있는가
첨부 파일의 실제 저장 위치와 접근 권한이 명확한가
재시도 시 중복 레코드가 생성되지 않는가
이전 전후의 레코드 수와 핵심 합계가 일치하는가

양쪽 데이터베이스에 동시에 쓰는 이중 쓰기는 가능하면 짧게 운영해야 합니다. 불가피하다면 어느 시스템이 최종 원본인지, 실패한 데이터는 어떤 작업으로 재처리할지 먼저 결정해야 합니다.

배포 전 점검 체크리스트

데이터별 원본 시스템이 하나로 정해져 있는가
API 키와 비밀 토큰이 클라이언트에 노출되지 않는가
모든 생성·수정·삭제 API가 서버에서 권한을 검사하는가
Supabase 테이블의 RLS와 정책을 실제 사용자 토큰으로 테스트했는가
목록 API에 페이지네이션과 서버 측 필터가 적용되어 있는가
Repeating Group에서 행마다 API를 다시 호출하지 않는가
오류 응답 형식과 사용자 안내 문구가 준비되어 있는가
개발용 키와 운영용 키가 분리되어 있는가
백업과 복구 절차를 직접 시험했는가
API 변경 시 기존 Bubble 화면이 깨지지 않도록 버전 관리 기준이 있는가

마무리

Bubble과 Xano 또는 Supabase를 연결하는 일은 API 주소를 입력하는 것만으로 끝나지 않습니다. 안정적인 구조를 만들려면 데이터 소유권, 인증 주체, 서버 측 권한 검증, 응답 규격, 오류 복구 방식을 함께 설계해야 합니다.

시각적으로 서버 로직을 빠르게 구성하고 싶다면 Xano가, PostgreSQL과 SQL의 장점을 적극적으로 사용하고 싶다면 Supabase가 적합할 수 있습니다. 어느 도구를 선택하든 Bubble은 화면과 사용자 상호작용에 집중하고 중요한 데이터 검증과 비즈니스 규칙은 외부 백엔드가 책임지게 만드는 것이 핵심입니다.

처음부터 전체 시스템을 분리하기보다는 독립성이 높은 기능 하나부터 적용해 호출 횟수, 응답 속도, 오류율을 확인해 보세요. 작은 범위에서 검증한 설계가 장기적으로 더 안전하고 관리하기 쉬운 백엔드 구조로 이어집니다.